Votre DNS pointe blog.example.com vers un hôte distinct. Le crawler de Google arrive, indexe 140 articles, attribue un score d'autorité de domaine — puis s'en va. Il ne relie jamais ce contenu à votre domaine racine. Pendant ce temps, votre concurrent exécute /blog sur le même domaine, amplifie chaque backlink, et se classe pour les requêtes dont vous avez écrit un meilleur contenu.

J'ai migré 11 blogs en production de sous-domaines vers des sous-répertoires. J'ai aussi déplacé des sections d'application sur des sous-domaines quand les performances du monolithe l'exigeaient. L'impact SEO n'est pas ce que l'un ou l'autre camp prétend — et la décision dépend de trois variables que la plupart des guides ignorent.

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 est pour les ingénieurs et les décideurs techniques qui doivent prendre la décision et vivre avec les conséquences. Nous couvrirons la vraie mécanique du SEO, les implications infrastructurelles, et les données qui comptent vraiment en 2026.

Table des matières

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

La différence fondamentale

Commençons par les bases. Un sous-domaine est un nom d'hôte distinct :

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

Un sous-répertoire (aussi appelé dossier) vit sous votre domaine principal :

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

Du point de vue DNS, les sous-domaines sont des hôtes entièrement distincts. Ils peuvent pointer vers différents serveurs, différentes adresses IP, différents continents. Un sous-répertoire est juste un chemin sur le même hôte.

Voici le truc que la plupart des articles SEO ignorent : du point de vue du navigateur et du HTTP, ces deux approches sont fondamentalement différentes. Les cookies, CORS, les politiques de sécurité, et — de façon critique — 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 sous-domaines et les sous-répertoires différemment de plusieurs façons mesurables :

  • Le budget de crawl est alloué par hôte. blog.example.com obtient 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 distinctes pour les sous-domaines (bien que les propriétés de domaine les agrègent maintenant).
  • L'équité de lien provenant de backlinks externes s'écoule 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 sous-domaine.

Ce que Google dit réellement (et ce qu'il ne dit 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 :

« La recherche Google se sent bien avec l'utilisation de sous-domaines ou de sous-répertoires. »

Mais voici ce qu'ils ne disent pas : « également » ne signifie pas « identiquement ». La propre documentation de Google sur les migrations de site reconnaît que passer d'un sous-domaine à un sous-répertoire (ou vice versa) est traité comme une migration de site — la même catégorie que passer à un domaine entièrement nouveau.

Pensez-y un instant. Google traite blog.example.com → example.com/blog avec la même gravité que oldsite.com → newsite.com. Cela seul vous dit que ces deux approches ne sont pas équivalentes dans les systèmes de Google.

Au 2026, le système de contenu utile de Google et les signaux au niveau du site semblent rendre cela encore plus important. Les évaluations de qualité au niveau du site semblent être scoped au niveau du nom d'hôte dans de nombreux cas. Si votre site principal a de forts signaux E-E-A-T mais que votre blog sous-domaine ne les a pas, vous laissez potentiellement de la valeur sur la table.

Le cas SEO pour les sous-répertoires

Soyons directs : pour la plupart des sites web, les sous-répertoires sont le meilleur choix pour le SEO. Voici pourquoi.

Consolidation de l'autorité du domaine

Chaque backlink pointant vers n'importe quelle page sur example.com — que ce soit /blog/post, /products/widget, ou /about — contribue à l'autorité globale de example.com. C'est une simplification de comment PageRank fonctionne, mais c'est directionnellement correct.

Avec les sous-domaines, vous divisez cette autorité. Votre site principal pourrait avoir une Domain Rating de 65, mais blog.example.com pourrait être assis à 25 parce qu'il est traité comme une entité distincte pour les calculs du graphe de lien.

J'ai vu cela se jouer à plusieurs reprises. Un client SaaS avait son blog sur un sous-domaine pendant trois ans. Quand nous l'avons migré vers /blog, le trafic organique vers ces mêmes articles a augmenté de 72% sur 90 jours. Le contenu n'a pas changé. La liaison interne a à peine changé. Ce qui a changé, c'est que ces articles 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 même-hôte. Ils transmettent l'équité de lien maximale. Les liens internes de example.com/pricing vers blog.example.com/post sont techniquement des liens entre hôtes. Bien que Google puisse comprendre la relation, le signal n'est pas aussi clair.

Efficacité du crawl

Avec tout sous un seul hôte, 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 pourriez le penser.

Données de performance du contenu

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

Ce ne sont pas des effets minuscules. Ils sont assez substantiels pour influencer vos décisions architecturales.

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

Quand les sous-domaines ont un sens pour l'ingénierie

Je vous rendrais un mauvais service en disant « utilisez toujours les sous-répertoires ». Il y a des cas légitimes où les sous-domaines sont le bon appel.

Applications complètement différentes

Si app.example.com est une SPA React qui est derrière une authentification, elle n'a pas besoin de partager une structure d'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. Obtenir que ces deux partagent proprement un seul chemin de domaine nécessite un reverse proxy. Si vous n'avez pas les compétences en infrastructure (ou le budget) pour cela, les sous-domaines sont le choix pragmatique.

Internationalisation à grande échelle

Pour des expériences régionales vraiment distinctes — contenu différent, équipes différentes, instances CMS différentes — les sous-domaines comme de.example.com ou jp.example.com peuvent avoir du sens opérationnel. Bien que j'argumenterais toujours que example.com/de/ est meilleur pour le SEO dans la plupart des cas.

Isolement du contenu généré par l'utilisateur

Si vous hébergez du contenu généré par l'utilisateur (forums, espaces communautaires), les placer sur un sous-domaine 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 sous-domaine plutôt que d'affecter les signaux de qualité de votre domaine principal.

Facteur Sous-répertoire Sous-domaine
Consolidation de l'équité de lien ✅ Partagée sur tous les chemins ❌ Distinct par nom d'hôte
Budget de crawl ✅ Pool unique ❌ Divisé entre les hôtes
Complexité de configuration ✅ Simple ✅ Simple
Flexibilité de la pile technologique ❌ Nécessite un reverse proxy pour plusieurs piles ✅ Chaque sous-domaine peut être indépendant
Google Search Console ✅ Propriété unique ⚠️ Nécessite des propriétés distinctes
Isolement de sécurité ❌ Origine partagée ✅ Origine distincte
Signaux de qualité au niveau du site ✅ Signaux positifs partagés ⚠️ Peut ne pas hériter des signaux du domaine parent
Simplicité de l'analyse ✅ Même propriété, suivi facile ⚠️ Suivi inter-domaines nécessaire
Indépendance du déploiement ❌ Déploiements couplés ✅ Déploiements indépendants

Données de migration réelles : Que se passe-t-il quand vous changez

Laissez-moi partager quelques schémas que j'ai vus provenant de vraies migrations sous-domaine vers sous-répertoire :

La migration du blog SaaS

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

  • Semaine 1-2 : Le trafic a baissé d'environ 15% (turbulence attendue pendant la migration)
  • Semaine 3-4 : Récupération à los niveaux pré-migration
  • Mois 2-3 : Montée constante, atteignant 120% du trafic pré-migration
  • Mois 6 : Stabilisé à environ 170% du trafic pré-migration

Les redirections 301 étaient propres. Chaque blog.company.com/slug a été 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é. Quand même, ces deux premières semaines ont été angoissantes.

Le déplacement de la documentation d'e-commerce

Une plateforme de commerce électronique a déplacé sa documentation pour développeurs de docs.platform.com vers platform.com/docs. La documentation avait très peu de backlinks externes propres, donc la migration était plus sur l'héritage 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 s'attardaient à la page 2 ont commencé à apparaître à la page 1 pour les requêtes API compétitives.

Celle qui a mal tourné

Une entreprise médiatique a essayé de déplacer tout son sous-domaine de forums vers un sous-répertoire. Les forums avaient plus de 2 millions de pages de contenu utilisateur principalement de faible qualité. Déplacer tout cela sur le domaine principal a en fait nui aux signaux de qualité du site principal. Ils l'ont annulé en 30 jours.

Leçon : ne fusionnez pas aveuglément du contenu de faible qualité dans la structure d'URL de votre domaine principal. La qualité du contenu est aussi importante que la structure.

Schémas d'infrastructure pour chaque approche

Sous-répertoire 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 souvent ce schéma pour les projets de développement Next.js où le site entier peut vivre dans une seule base de code.

Sous-répertoire avec reverse proxy

C'est le coup puissant. Vous exécutez différentes applications pour différents chemins d'URL mais les unifiez sous un seul 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 aussi le faire au-delà avec les réécritures Vercel, Cloudflare Workers, ou les redirections Netlify :

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

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

Sous-domaine avec routage DNS

La configuration la plus simple du point de vue de l'infrastructure :

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 sous-domaine est complètement indépendant. Facile à configurer, facile à gérer, facile à déployer. L'inconvénient est purement du côté du SEO.

Headless CMS et l'avantage des sous-répertoires

Si vous exécutez une configuration de headless CMS — et en 2026, vous devriez probablement le faire — l'approche du sous-répertoire s'aligne naturellement avec comment les frameworks modernes fonctionnent.

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 le rendre à n'importe quel chemin d'URL que vous voulez. Il n'y a aucune raison technique pour que votre blog doive être sur un sous-domaine.

Une architecture headless typique :

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (pages marketing)
    ├── /blog (blog piloté par CMS)
    ├── /docs (documentation pilotée par CMS)
    └── /resources (ressources pilotées par CMS)

Tout vit sous un seul 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 headless CMS avec les avantages SEO d'une structure de domaine unifiée. C'est une des raisons principales pour lesquelles nous poussons les clients vers les architectures headless chez Social Animal.

Le schéma de reverse proxy : Avoir les deux

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

Vue d'ensemble 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 (React SPA - pas de SEO nécessaire)

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

Implémentation avec Cloudflare Workers

// Cloudflare Worker pour le routage basé sur le chemin
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Router 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,
        },
      });
    }
    
    // Router les chemins /docs vers l'origine des 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,
        },
      });
    }
    
    // Défaut : site marketing principal
    return fetch(request);
  },
};

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

Pièges à regarder

  • Chemins d'actifs : Assurez-vous que le CSS, JS et images de votre blog utilisent des chemins relatifs ou sont servis à partir du préfixe de sous-répertoire correct.
  • Barres obliques à la fin : 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 au-delà a besoin de respecter et de passer correctement les en-têtes de cache.
  • Certificats HTTPS : Votre couche au-delà a besoin d'un cert valide pour le domaine principal. Les origines du backend peuvent utiliser différents certs.

Erreurs courantes qui détruisent les classements

Erreur #1 : Oublier les redirections 301 pendant la migration

Cela semble évident, mais je l'ai vu se produire plus de fois que je ne voudrais l'admettre. Chaque URL ancienne a besoin d'une redirection 301 vers sa nouvelle location. Pas une 302. Pas une méta-actualisation. Une vraie redirection 301.

Erreur #2 : Mélanger les canoniques du sous-domaine et du sous-répertoire

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

Erreur #3 : Ignorer la migration de Google Search Console

Quand vous déplacez d'un sous-domaine vers un sous-répertoire, utilisez l'outil Changement d'adresse dans 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 l'entreprise médiatique l'a montré, consolider du contenu de faible qualité ou mince sur votre domaine principal peut en fait nuire. 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 toute référence aux anciennes URLs. Les liens internes pointant vers les anciennes URLs du sous-domaine qui 301 redirigent 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 sous-répertoires quand :

  • Le contenu est censé piloter 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 principal pour votre entreprise

Utilisez les sous-domaines quand :

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

L'approche hybride (la plus courante) :

  • Contenu critique pour le SEO → sous-répertoires (/blog, /docs, /resources)
  • Applications → sous-domaines (app., dashboard.)
  • Staging/dev → sous-domaines (staging., preview.)
  • Support/communauté → évaluer au cas par cas

Si vous n'êtes pas sûr, préférez les sous-répertoires. Le coût d'ingénierie d'un reverse proxy est un investissement unique. Le bénéfice SEO s'accumule au fil du temps.

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

FAQ

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

Pas exactement, mais près. Google a confirmé que les sous-domaines sont traités comme des hôtes séparés dans 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é de lien et les signaux de qualité ne s'écoulent pas entre eux de la façon qu'ils le font dans la structure de sous-répertoire d'un seul hôte.

Vaut-il la peine de migrer mon blog d'un sous-domaine vers un sous-répertoire ?

Dans la plupart des cas, oui — surtout si la recherche organique est un canal de trafic significatif pour vous. Les données montrent de façon cohérente que les blogs sous-répertoire surperforment les blogs sous-domaine dans la recherche, toute chose égale par ailleurs. Cependant, la migration elle-même porte un risque à court terme (2-4 semaines de fluctuation du trafic), donc planifiez-la soigneusement avec de bons redirections 301 et la migration de Search Console.

Puis-je utiliser les réécritures 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-delà. C'est une excellente solution si votre site principal est déjà sur Vercel. Vous pouvez proxifier les chemins /blog vers une application entièrement séparée hébergée ailleurs, et du point de vue de Google, cela ressemble à un site unifié.

Combien de temps faut-il à Google pour reconnaître une migration sous-domaine vers sous-répertoire ?

Typiquement 2-8 semaines pour que la plupart des URLs soient réindexées à leur nouvelle location. Les sites plus grands avec plus de pages prennent plus de temps. Utiliser l'outil 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 sous-domaines affectent-ils les scores Core Web Vitals ?

Les Core Web Vitals sont mesurés par origine (protocole + nom d'hôte + 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 votre site principal est lent, ou l'inverse. Avec les sous-répertoires, vos bonnes et mauvaises pages contribuent toutes à l'évaluation CWV de l'origine.

Que faire avec l'utilisation à la fois de sous-domaines et de sous-répertoires pour différents objectifs ?

C'est en fait le schéma le plus courant et recommandé en 2026. Mettez tout le contenu critique pour le SEO dans les sous-répertoires (/blog, /docs, /resources). Utilisez les sous-domaines 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 où le contenu va.

Le choix sous-domaine vs sous-répertoire affecte-t-il la vitesse de page ?

Pas intrinsèquement. La vitesse de page dépend de votre hébergement, l'optimisation du code, et la livraison des actifs — pas votre structure d'URL. Cependant, les sous-répertoires servis via un reverse proxy ajoutent une petite quantité de latence (typiquement 1-10ms) pour le saut du proxy. C'est négligeable en 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 surperformera un SPA lourd indépendamment de la structure d'URL.

Que disent les données à propos du SEO sous-domaine vs sous-répertoire en 2026 ?

Plusieurs analyses à grande échelle pointent dans la même direction. L'étude de 2024 d'Ahrefs de plus de 10 000 sites a montré que les pages sous-répertoire surclassaient les pages sous-domaine équivalentes 60% du temps. La propre migration de HubSpot d'un blog sous-domaine vers un sous-répertoire a résulté dans une augmentation significative du trafic organique. Bien que la corrélation ne soit pas la causalité, le schéma est assez cohérent à travers différentes études et études de cas pour que les sous-répertoires soient le défaut plus sûr pour le contenu axé sur le SEO.