J'ai migré des blogs de subdomains vers des subdirectories plus de fois que je ne peux le compter. J'ai aussi fait l'inverse -- déplacé des sections entières d'applications sur des subdomains quand l'architecture l'exigeait. Et voici ce que j'ai appris après des années d'observation des classements : la réponse n'est pas aussi simple que l'un ou l'autre camp veut vous le faire croire.

La position officielle de Google n'a pas beaucoup changé -- ils disent qu'ils peuvent gérer les deux. Mais ce que Google dit et ce qui se passe réellement dans les SERPs sont deux choses différentes. Ce guide s'adresse aux ingénieurs et aux décideurs techniques qui doivent faire le choix et vivre avec les conséquences. Nous couvrirons la vraie mécanique du SEO, les implications infrastructurelles, et les données qui importent réellement en 2026.

Table des matières

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

La Différence Fondamentale

Mettez de côté les bases. Un subdomain est un hostname séparé :

blog.example.com
shop.example.com
app.example.com

Une subdirectory (aussi appelée dossier) se trouve sous votre domaine principal :

example.com/blog
example.com/shop
example.com/app

D'un point de vue DNS, les subdomains sont entièrement des hosts différents. Ils peuvent pointer vers des serveurs différents, des IPs différentes, des continents différents. Une subdirectory est juste un chemin sur le même host.

Voici ce que la plupart des articles SEO contournent : d'un point de vue navigateur et HTTP, ces deux approches sont fondamentalement différentes. Les cookies, CORS, les politiques de sécurité, et -- critiquement -- comment les moteurs de recherche allouent le budget de crawl diffèrent tous entre les deux approches.

Comment les Moteurs de Recherche Les Traitent Différemment

Malgré les assurances de Google, leurs propres systèmes traitent les subdomains et les subdirectories différemment de plusieurs façons mesurables :

  • Le budget de crawl est alloué par host. blog.example.com reçoit son propre budget de crawl séparé de example.com.
  • L'opérateur site: les traite séparément. Essayez site:blog.example.com vs site:example.com/blog -- vous verrez un comportement d'indexation différent.
  • Google Search Console nécessite des propriétés séparées pour les subdomains (bien que les propriétés de domaine les agrègent maintenant).
  • L'équité des liens des backlinks externes circule différemment. Un lien vers example.com/blog/great-post renforce directement le domaine racine. Un lien vers blog.example.com/great-post renforce... le subdomain.

Ce que Google Dit Réellement (Et Ce qu'Ils Ne Disent Pas)

John Mueller a répété plusieurs fois que Google peut gérer les deux et les traite à peu près également. Voici la citation exacte qui circule :

"Google Web Search va bien avec l'utilisation de subdomains ou de subdirectories."

Mais voici ce qu'ils ne disent pas : "à peu près également" ne veut pas dire "identiquement". La documentation propre de Google sur les migrations de sites reconnaît que passer d'un subdomain à une subdirectory (ou vice versa) est traité comme une migration de site -- la même catégorie que de passer à un domaine entièrement nouveau.

Réfléchissez à cela une seconde. Google traite blog.example.com → example.com/blog avec la même gravité que oldsite.com → newsite.com. Cela seul vous dit que ces approches ne sont pas équivalentes dans les systèmes de Google.

Au 2025-2026, le système de contenu utile de Google et les signaux au niveau du site rendent cela encore plus important. Les évaluations de qualité au niveau du site semblent être limitées au niveau du hostname dans de nombreux cas. Si votre site principal a des signaux E-E-A-T forts mais que votre blog subdomain ne les a pas, vous laissez potentiellement de la valeur sur la table.

Le Cas SEO pour les Subdirectories

Soyez direct : pour la plupart des sites web, les subdirectories sont le meilleur choix pour le SEO. Voici pourquoi.

Consolidation de l'Autorité de Domaine

Chaque backlink pointant vers n'importe quelle page sur example.com -- qu'elle soit /blog/post, /products/widget, ou /about -- contribue à l'autorité globale de example.com. C'est une simplification de la façon dont PageRank fonctionne, mais c'est directionnellement correct.

Avec les subdomains, vous divisez cette autorité. Votre site principal pourrait avoir un Domain Rating de 65, mais blog.example.com pourrait être assis à 25 parce qu'il est traité comme une entité séparée pour les calculs de graphe de liens.

J'ai vu cela se jouer à plusieurs reprises. Un client SaaS avait son blog sur un subdomain pendant trois ans. Quand nous l'avons migré vers /blog, le trafic organique vers ces mêmes posts a augmenté de 72% en 90 jours. Le contenu n'a pas changé. La liaison interne a à peine changé. Ce qui a changé, c'est que ces posts pouvaient maintenant bénéficier de l'autorité existante du domaine.

Liaison Interne Simplifiée

Les liens internes de example.com/pricing vers example.com/blog/post sont des liens du même host. Ils passent une équité de lien maximale. Les liens internes de example.com/pricing vers blog.example.com/post sont techniquement des liens cross-host. Bien que Google puisse comprendre la relation, le signal n'est pas aussi clair.

Efficacité du Crawl

Avec tout sous un seul host, Googlebot peut découvrir et crawler votre contenu plus efficacement. Un robots.txt. Une structure de sitemap. Un pool de budget de crawl. Pour les grands sites avec des milliers de pages, cela compte plus que vous ne le penseriez.

Données de Performance du Contenu

Une étude de 2024 d'Ahrefs analysant 10 000+ sites a trouvé que les pages sur les subdirectories surclassaient les pages subdomain équivalentes 60% du temps, en contrôlant la qualité du contenu et les backlinks. Une analyse similaire de Semrush au début de 2025 a montré que les articles de blog en subdirectory avaient, en moyenne, 20-30% plus de trafic organique que les articles de blog en subdomain comparables.

Ce ne sont pas de petits effets. Ce sont des effets assez importants pour influencer vos décisions architecturales.

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026 - architecture

Quand les Subdomains Ont Du Sens Techniquement

Je vous rendrais un mauvais service si je disais "utilisez toujours des subdirectories". Il y a des cas légitimes où les subdomains sont le bon appel.

Applications Complètement Différentes

Si app.example.com est une SPA React qui est derrière l'authentification, il n'a pas besoin de partager une structure URL avec votre site marketing. Il n'y a aucun bénéfice SEO à avoir votre tableau de bord à example.com/app -- Google ne devrait pas l'indexer de toute façon.

Piles Technologiques Différentes Qui Ne Peuvent Pas Partager l'Infrastructure

Parfois votre site marketing est sur Next.js et votre documentation est construite avec Docusaurus. Faire en sorte que ces deux partagent un chemin de domaine unique et proprement nécessite un reverse proxy. Si vous n'avez pas les compétences infrastructurelles (ou le budget) pour cela, les subdomains sont le choix pragmatique.

Internationalisation à Grande Échelle

Pour des expériences régionales vraiment séparées -- contenu différent, équipes différentes, instances CMS différentes -- les subdomains comme de.example.com ou jp.example.com peuvent avoir du sens opérationnel. Bien que je soutiendrais toujours que example.com/de/ est mieux pour le SEO dans la plupart des cas.

Isolation du Contenu Généré par l'Utilisateur

Si vous hébergez du contenu généré par l'utilisateur (forums, espaces communautaires), le placer sur un subdomain fournit un pare-feu naturel. Si ce contenu est frappé par une attaque de spam ou des problèmes de qualité, les dégâts sont contenus au subdomain plutôt que d'affecter les signaux de qualité de votre domaine principal.

Facteur Subdirectory Subdomain
Consolidation de l'équité des liens ✅ Partagée sur tous les chemins ❌ Séparée par hostname
Budget de crawl ✅ Pool unique ❌ Divisé sur les hosts
Complexité de la configuration ✅ Simple ✅ Simple
Flexibilité de la pile technologique ❌ Nécessite un reverse proxy pour les piles multiples ✅ Chaque subdomain peut être indépendant
Google Search Console ✅ Propriété unique ⚠️ Nécessite des propriétés séparées
Isolation de sécurité ❌ Origine partagée ✅ Origine séparée
Signaux de qualité au niveau du site ✅ Signaux positifs partagés ⚠️ Peut ne pas hériter des signaux du domaine parent
Simplicité de l'analytique ✅ Même propriété, suivi facile ⚠️ Suivi cross-domain nécessaire
Indépendance du déploiement ❌ Déploiements couplés ✅ Déploiements indépendants

Données Réelles de Migration : Ce Qui Se Passe Quand Vous Changez

Laissez-moi partager certains modèles que j'ai vus à partir de migrations réelles de subdomain vers subdirectory :

La Migration du Blog SaaS

Une entreprise SaaS B2B a déplacé son blog de blog.company.com vers company.com/blog en Q2 2024. Le blog avait environ 400 posts et générait environ 15 000 sessions organiques par mois.

  • Semaine 1-2: Le trafic a chuté ~15% (turbulence attendue pendant la migration)
  • Semaine 3-4: Récupération aux niveaux pré-migration
  • Mois 2-3: Montée régulière, atteignant 120% du trafic pré-migration
  • Mois 6: Stabilisé à ~170% du trafic pré-migration

Les redirects 301 étaient propres. Chaque blog.company.com/slug a redirigé vers company.com/blog/slug. Les balises canoniques ont été mises à jour. L'outil de changement d'adresse de Google Search Console a été utilisé. Néanmoins, ces deux premières semaines ont été stressantes.

Le Déplacement de Documentation E-Commerce

Une plateforme e-commerce a déplacé sa documentation des développeurs de docs.platform.com vers platform.com/docs. La documentation avait très peu de backlinks externes qui lui sont propres, donc la migration parlait plutôt d'hériter de l'autorité du domaine principal.

Résultats : La position de classement moyenne pour les pages de documentation s'est améliorée de 4,2 positions en 60 jours. Les pages qui avaient été flottantes à la page 2 ont commencé à apparaître à la page 1 pour les requêtes API compétitives.

Celle Qui S'Est Mal Passée

Une société de médias a essayé de déplacer son intégralité de forums subdomain vers une subdirectory. Les forums avaient 2 millions+ de pages de contenu utilisateur principalement de faible qualité. Déplacer tout cela sur le domaine principal a en fait blessé les signaux de qualité du site principal. Ils ont annulé la modification en 30 jours.

Leçon : ne fusionnez pas aveuglément du contenu de faible qualité dans la structure URL de votre domaine principal. La qualité du contenu compte autant que la structure.

Modèles Infrastructurels pour Chaque Approche

Subdirectory avec Hébergement Monolithique

L'approche la plus simple. Votre site entier -- pages marketing, blog, docs -- s'exécute sur une seule application ou framework.

# Application Next.js unique
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

Cela fonctionne bien pour les petits sites. Nous utilisons ce modèle fréquemment pour les projets de développement Next.js où le site entier peut vivre dans une base de code unique.

Subdirectory avec Reverse Proxy

C'est le déplacement puissant. Vous exécutez différentes applications pour différents chemins URL mais les unifiez sous un domaine en utilisant un reverse proxy.

# Configuration du reverse proxy Nginx
server {
    server_name example.com;
    
    # Site marketing principal (Next.js sur Vercel)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # Blog (Astro sur Netlify)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # Docs (Docusaurus sur son propre serveur)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

Vous pouvez également le faire au edge avec les réécriture Vercel, les Cloudflare Workers, ou les redirections Netlify :

// vercel.json rewrites
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

Ce modèle vous donne les bénéfices SEO des subdirectories avec la flexibilité d'ingénierie des déploiements indépendants. C'est comment nous abordons la plupart des projets de développement de headless CMS où le contenu vit dans un système mais l'architecture frontale s'étend sur plusieurs applications.

Subdomain avec Routage DNS

La configuration la plus simple du point de vue infrastructurel :

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

Chaque subdomain est complètement indépendant. Facile à configurer, facile à gérer, facile à déployer. Le compromis est purement du côté SEO.

Headless CMS et l'Avantage Subdirectory

Si vous exécutez une configuration headless CMS -- et en 2026, vous devriez probablement le faire -- l'approche subdirectory s'aligne naturellement avec le fonctionnement des frameworks modernes.

Avec des outils comme Astro, Next.js, ou Nuxt, vous pouvez récupérer du contenu de votre CMS (Sanity, Contentful, Strapi, peu importe) et l'afficher à n'importe quel chemin URL que vous voulez. Il n'y a aucune raison technique pour que votre blog soit sur un subdomain.

Une architecture headless typique :

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (pages marketing)
    ├── /blog (blog conduit par CMS)
    ├── /docs (documentation conduite par CMS)
    └── /resources (ressources conduites par CMS)

Tout vit sous un domaine. Un déploiement. Un ensemble d'optimisations de performance. Un score d'autorité de domaine.

La beauté de cette approche est que vous obtenez la flexibilité de gestion de contenu d'un CMS headless avec les bénéfices SEO d'une structure de domaine unifiée. C'est l'une des principales raisons pour lesquelles nous poussons les clients vers les architectures headless chez Social Animal.

Le Modèle Reverse Proxy : Obtenir Les Deux

Laissez-moi parcourir le modèle que nous utilisons le plus souvent pour les clients de taille moyenne à entreprise qui ont besoin de déploiements indépendants et d'un SEO unifié.

Aperçu de l'Architecture

Cloudflare (Edge)
    ├── example.com/* → Vercel (site marketing Next.js)
    ├── example.com/blog/* → Vercel (blog Astro)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (SPA React - pas de SEO nécessaire)

Notez que app.example.com est toujours un subdomain. C'est intentionnel -- c'est une application authentifiée que les moteurs de recherche ne devraient pas indexer. Tout ce qui a besoin de SEO vit sous le domaine principal.

Implémentation avec Cloudflare Workers

// Cloudflare Worker pour le routage basé sur les chemins
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Acheminer les chemins /blog vers l'origine du blog
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Acheminer les chemins /docs vers l'origine docs
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Par défaut : site marketing principal
    return fetch(request);
  },
};

Cela s'exécute au edge, ajoute une latence minimale (généralement <5ms), et vous donne un contrôle complet sur le routage. Chaque équipe peut déployer indépendamment tout en présentant un domaine unifié aux moteurs de recherche.

Pièges à Surveiller

  • Chemins d'actifs: Assurez-vous que le CSS, JS et les images de votre blog utilisent des chemins relatifs ou sont servis du préfixe de subdirectory correct.
  • Barres obliques finales: Soyez cohérent. Mélanger /blog et /blog/ causera des boucles de redirection ou des problèmes de contenu dupliqué.
  • En-têtes de cache: Le proxy edge doit respecter et transmettre correctement les en-têtes de cache.
  • Certificats HTTPS: Votre couche edge a besoin d'un certificat valide pour le domaine principal. Les origines backend peuvent utiliser des certificats différents.

Erreurs Courantes Qui Tuent les Classements

Erreur #1 : Oublier les Redirects 301 Pendant la Migration

Cela semble évident, mais j'ai vu cela se produire plus de fois que je ne voudrais l'admettre. Chaque ancien URL a besoin d'une redirection 301 vers son nouveau lieu. Pas un 302. Pas une méta actualisation. Une redirection 301 appropriée.

Erreur #2 : Mélanger les Canoniques Subdomain et Subdirectory

Si blog.example.com/post et example.com/blog/post se résolvent tous deux, vous avez besoin de balises canoniques pointant vers l'un ou l'autre. Avoir les deux en vie sans canoniques signifie que Google en choisit un, et ce ne sera peut-être pas celui que vous voulez.

Erreur #3 : Ignorer la Migration de Google Search Console

Quand vous passez d'un subdomain à une subdirectory, utilisez l'outil de changement d'adresse dans Google Search Console. Cela dit explicitement à Google de la migration et accélère le processus de réindexation.

Erreur #4 : Déplacer du Contenu de Faible Qualité Sur Votre Domaine Principal

Comme l'exemple de la société de médias l'a montré, consolider le contenu de faible qualité ou fin sur votre domaine principal peut en fait faire du mal. Auditez la qualité du contenu en premier. Élaguez ou améliorez les pages faibles avant la migration.

Erreur #5 : Ne Pas Mettre à Jour les Liens Internes

Après la migration, grep votre base de code entière et CMS pour n'importe quelles références aux anciens URLs. Les liens internes pointant vers les anciens URLs subdomain qui redirigent 301 fonctionnent, mais ce n'est pas idéal. Les liens directs sont toujours mieux que les chaînes de redirection.

Cadre de Décision pour 2026

Voici le cadre que j'utilise quand je conseille les clients. Ce n'est pas compliqué, mais ça marche.

Utilisez les subdirectories quand:

  • Le contenu est destiné à conduire le trafic de recherche organique
  • Le contenu est de haute qualité et reflète bien votre marque
  • Vous pouvez gérer l'infrastructure (même si cela signifie un reverse proxy)
  • Le SEO est un canal de croissance primaire pour votre entreprise

Utilisez les subdomains quand:

  • L'application est derrière l'authentification (aucune valeur SEO)
  • Le contenu est généré par l'utilisateur et potentiellement de faible qualité
  • Les exigences réglementaires ou de sécurité demandent l'isolation
  • Le contenu cible un public/langue complètement différent ET vous avez les ressources pour construire l'autorité pour ce subdomain indépendamment

L'approche hybride (la plus courante):

  • Contenu critique pour le SEO → subdirectories (/blog, /docs, /resources)
  • Applications → subdomains (app., dashboard.)
  • Staging/dev → subdomains (staging., preview.)
  • Support/communauté → évaluez au cas par cas

Si vous êtes incertain, optez par défaut pour les subdirectories. Le coût d'ingénierie d'un reverse proxy est un investissement unique. Le bénéfice SEO se compose au fil du temps.

Voulez-vous de l'aide pour figure la bonne architecture pour votre site ? Nous travaillons à travers exactement ces sortes de décisions pendant nos engagements de développement de headless CMS et développement Next.js. Vous pouvez aussi vérifier nos tarification ou nous contacter directement pour discuter de votre situation spécifique.

FAQ

Google traite-t-il les subdomains comme des sites web séparés ?

Pas exactement, mais d'assez près. Google a confirmé que les subdomains sont traités comme des hosts séparés dans Google Search Console et pour l'allocation du budget de crawl. Bien que Google comprenne la relation entre blog.example.com et example.com, l'équité des liens et les signaux de qualité ne circulent pas entre eux de la manière qu'ils le font dans la structure de subdirectory d'un single host.

Vaut-il la peine de migrer mon blog d'un subdomain vers une subdirectory ?

Dans la plupart des cas, oui -- surtout si la recherche organique est un canal de trafic significatif pour vous. Les données montrent de manière cohérente que les blogs en subdirectory font mieux dans la recherche que les blogs en subdomain, toutes choses égales par ailleurs. Cependant, la migration elle-même comporte des risques à court terme (2-4 semaines de fluctuation du trafic), donc planifiez-la soigneusement avec les redirects 301 appropriées et la migration de Google Search Console.

Puis-je utiliser les réécriture Vercel au lieu d'un reverse proxy ?

Absolument. Les rewrites de Vercel dans vercel.json ou next.config.js fonctionnent comme un reverse proxy au edge. C'est une excellente solution si votre site principal est déjà sur Vercel. Vous pouvez rediriger les chemins /blog vers une application complètement séparée hébergée ailleurs, et du point de vue de Google, cela ressemble à un site unifié.

Combien de temps faut-il pour que Google reconnaisse une migration de subdomain vers subdirectory ?

Généralement 2-8 semaines pour que la plupart des URLs soient réindexées à leur nouveau lieu. Les sites plus grands avec plus de pages prennent plus longtemps. Utiliser l'outil de changement d'adresse dans Google Search Console et soumettre un sitemap mis à jour peut accélérer cela. Attendez-vous à une baisse de classement temporaire dans les semaines 1-2, suivie d'une récupération et souvent d'une amélioration.

Les subdomains affectent-ils les scores Core Web Vitals ?

Les Core Web Vitals sont mesurés par origine (protocole + hostname + port). Donc blog.example.com a des scores CWV complètement séparés de example.com. Cela peut être un avantage si votre blog est rapide mais que votre site principal est lent, ou l'inverse. Avec les subdirectories, vos pages bonnes et mauvaises contribuent toutes à l'évaluation CWV de la même origine.

Que diriez-vous d'utiliser à la fois des subdomains et des subdirectories pour des objectifs différents ?

C'est en fait le modèle le plus courant et recommandé en 2026. Mettez tout le contenu critique pour le SEO dans les subdirectories (/blog, /docs, /resources). Utilisez les subdomains pour les applications, les environnements de staging, et tout contenu que vous ne voulez explicitement pas associer aux signaux de qualité de votre domaine principal. La clé est d'être intentionnel sur le lieu où va le contenu.

Le choix entre subdomain et subdirectory affecte-t-il la vitesse de page ?

Non intrinsèquement. La vitesse de page dépend de votre hébergement, de l'optimisation du code, et de la livraison des actifs -- pas de votre structure URL. Cependant, les subdirectories servies à travers un reverse proxy ajoutent une petite quantité de latence (généralement 1-10ms) pour le hop du proxy. C'est négligeable dans la pratique. Le facteur de vitesse de page plus important est si vous utilisez un framework approprié -- quelque chose comme Astro pour les sites riches en contenu sera supérieur à une SPA lourde indépendamment de la structure URL.

Que disent les données sur le SEO de subdomain vs subdirectory en 2025-2026 ?

Plusieurs analyses à grande échelle pointent dans la même direction. L'étude de 2024 d'Ahrefs de 10 000+ sites a montré que les pages en subdirectory surclassaient les pages en subdomain équivalentes 60% du temps. La propre migration de HubSpot d'un blog en subdomain vers une subdirectory a entraîné une augmentation significative du trafic organique. Bien que la corrélation ne soit pas la causalité, le modèle est assez cohérent sur différentes études et études de cas pour que les subdirectories soient le par défaut plus sûr pour le contenu concentré sur le SEO.