Servir un blog depuis un CDN externe sans perdre le SEO

Héberger le blog ailleurs que le site principal est une décision d'infrastructure courante. Elle devient une décision SEO au moment où l'on choisit comment les visiteurs et les crawlers y accèdent : sous-domaine, sous-répertoire, ou sous-répertoire servi par un proxy.

Trois configurations, trois profils de risque

La troisième ligne est le meilleur compromis : les URL restent sur le domaine principal — donc dans le même périmètre d'autorité — tandis que l'application qui rend les pages est entièrement découplée.

La chaîne complète d'une requête

Googlebot
  → GET https://client.com/blog/mon-article
  → rewrite au niveau de l'hébergeur du domaine client
  → GET https://cdn.exemple.app/blog/mon-article
       en-tête ajouté : x-forwarded-host: client.com
  → l'application SSR lit x-forwarded-host
  → elle génère canonical = https://client.com/blog/mon-article
  → HTML rendu côté serveur, renvoyé sous l'URL d'origine

Tout repose sur la troisième étape. Si l'application ignore x-forwarded-host et se fie à l'en-tête host, elle produit un canonical vers le CDN. Google indexe alors le CDN et le domaine client ne reçoit rien.

Résoudre le domaine dans le bon ordre

domaine = x-forwarded-host
       || x-original-host
       || parametre ?domain=
       || host

domaine = retirer_www(retirer_port(minuscules(domaine)))

L'ordre importe : la valeur la plus fiable en tête, le repli le plus générique en fin. La normalisation finale évite de traiter www.client.com, client.com:443 et Client.com comme trois domaines différents — source classique de canonicals éclatés, comme décrit dans canonical et duplicate content.

Les six vérifications avant mise en production

1. Le HTML est-il rendu côté serveur ? Vérifier le code source brut, pas l'inspecteur du navigateur qui affiche le DOM après exécution du JavaScript.
2. Le canonical pointe-t-il vers le domaine client ? C'est la vérification qui invalide le plus de configurations.
3. Le sitemap est-il servi sous le domaine client ? Un sitemap listant des URL d'un autre hôte est ignoré pour ces URL.
4. Le robots.txt du CDN bloque-t-il l'indexation directe ? Sinon les deux versions coexistent en index.
5. Les codes de statut sont-ils propagés ? Une page inexistante doit renvoyer un 404 réel, pas une page d'erreur en 200.
6. Les liens internes sont-ils relatifs ? Un lien absolu vers le CDN fait sortir le crawler du domaine client.

Mise en cache : le paramètre qui change tout à l'échelle

Sur un blog dont le contenu bouge peu, une politique de cache agressive au niveau du CDN allège la charge et stabilise les temps de réponse — ce qui agit directement sur le budget d'exploration.

Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400

La directive stale-while-revalidate autorise le CDN à servir immédiatement une version légèrement périmée tout en la rafraîchissant en arrière-plan. Pour un crawler, cela signifie une réponse rapide et constante, ce qui est exactement le signal recherché — voir budget de crawl.

Le cas multi-domaines

Une même application peut servir plusieurs domaines clients, à condition que trois éléments soient dérivés du domaine résolu et non codés en dur : le canonical, l'URL du sitemap, et le filtrage des articles renvoyés. Une valeur codée en dur à l'un de ces trois endroits fait fuiter le contenu d'un client sur le domaine d'un autre — un incident dont la correction implique des désindexations manuelles.