Migration de domaine WordPress sans perte SEO : 301, canonicals, sitemaps et zéro drame

Ce que vous changez réellement (et pourquoi le SEO s’irrite)

Une migration de domaine n’est pas « mettre à jour le DNS et cliquer sur Enregistrer ». C’est un échange d’identité coordonné pour chaque URL que votre site a jamais publié. Les moteurs de recherche ne classent pas votre installation WordPress. Ils classent vos URL et leurs signaux : liens, contenu, performance, données structurées, et la promesse implicite que cette URL sert constamment cette chose.

Quand vous changez de domaine, vous demandez à Google et aux autres de transférer la confiance des anciennes URL vers les nouvelles. Ce transfert se fait via une chaîne de preuves :

• Redirections HTTP (typiquement 301) qui mappent les anciennes URL vers leurs équivalents.
• Balises canoniques qui indiquent « l’URL préférée pour cette page est ici ».
• Sitemaps XML qui listent les nouvelles URL et facilitent la découverte.
• Liens internes mis à jour pour cesser de s’auto-saboter avec des références vers l’ancien domaine.
• Comportement de réponse cohérent (codes d’état, cacheabilité, contenu) qui ne ressemble pas à une tromperie.

Si vous faites bien cela, la migration n’est pour la plupart qu’une oscillation temporaire. Si vous le faites mal, vous créez du contenu dupliqué, des pièges de crawl, des boucles de redirection et une confusion d’indexation durable — généralement pendant que votre équipe marketing rafraîchit des tableaux de bord comme si c’était un moniteur cardiaque.

Faits et contexte qui expliquent les aspects étranges

Un peu d’histoire et de mécanique concrète. Ce ne sont pas des anecdotes ; elles expliquent pourquoi certaines « astuces intelligentes » sont un mauvais choix de carrière.

1. 301 vs 302 était autrefois interprété plus littéralement qu’aujourd’hui. Pendant des années, un 302 pouvait bloquer le transfert de signaux ; les moteurs sont devenus plus malins, mais le 301 reste le choix par défaut pour un déplacement permanent.
2. Google a introduit rel=canonical en 2009. Il a été conçu pour réduire l’indexation en double quand le même contenu existe à plusieurs URL — exactement ce que vous créez pendant une migration.
3. Les sitemaps XML sont devenus courants au milieu des années 2000. Ils n’« augmentent » pas le classement, mais réduisent le temps de découverte et vous aident à voir plus vite les erreurs de couverture.
4. WordPress a toujours différencié « Site Address (URL) » et « WordPress Address (URL) ». Mal comprendre cette séparation cause la moitié des pannes auto-infligées lors des changements de domaine.
5. Les navigateurs ont renforcé les règles de contenu mixte dans les années 2010. Un nouveau domaine HTTPS avec des assets en HTTP peut casser silencieusement le rendu et le suivi.
6. HTTP/2 (standardisé en 2015) a changé le modèle de coût en performance. Les chaînes de redirection restent coûteuses, mais moins que l’ancienne ère « une connexion par ressource » — ce n’est toujours pas gratuit.
7. Les CDN ont popularisé la mise en cache agressive des redirections. Un mauvais 301 peut être mis en cache à la périphérie et survivre à votre correctif, ce qui est enthousiasmant de la même manière qu’un pager l’est.
8. Les moteurs de recherche considèrent les longues chaînes de redirection comme un problème de qualité et d’efficacité. Ils peuvent cesser de suivre après trop d’étapes, et le budget de crawl est fini.

Une idée paraphrasée à garder en tête, car elle s’applique directement ici : l’espoir n’est pas une stratégie ; mesurez, automatisez et vérifiez. — Gene Kim (idée paraphrasée)

Non négociables : ce qui doit être vrai au moment du cutover

Avant de toucher aux TTL DNS ou aux paramètres WordPress, clarifiez ces invariants. Ce ne sont pas des « agréables à avoir ». Ils séparent « dip temporaire » de « pourquoi sommes-nous désindexés ».

1) Chaque ancienne URL renvoie un seul 301 direct vers son équivalent

Pas « la page d’accueil pour tout », pas un 302 « pour l’instant », pas une chaîne comme ancien → http nouveau → https nouveau → www nouveau. Un seul saut. Restez ennuyeux.

2) Les nouvelles pages se canonisent elles-mêmes vers le nouveau domaine

Quand un crawler atteint le nouveau domaine, la balise canonique doit pointer vers le nouveau domaine. Si les canonicals référencent encore l’ancien domaine, vous dites à Google de préférer les anciennes URL… alors que vous redirigez aussi ces URL. C’est un conflit, et les conflits ne se classent pas.

3) Les liens internes cessent de pointer vers l’ancien domaine

Les redirections sont pour l’extérieur. Votre propre site ne devrait pas en avoir besoin. Les liens internes vers l’ancien domaine gonflent le gaspillage de crawl et masquent les problèmes de contenu.

4) Sitemaps et robots.txt reflètent la nouvelle vérité

Publiez des sitemaps listant uniquement les nouvelles URL. robots.txt ne doit pas interdire accidentellement des chemins importants parce que quelqu’un a copié une règle de staging.

5) Le suivi et les intégrations critiques survivent

Analytics, callbacks de paiement, URI de redirection OAuth, webhooks, en-têtes CSP, modèles d’email et pixels marketing sont sensibles au domaine. Listez-les dès le départ.

Blague n°1 : Une migration de domaine sans carte de redirections, c’est comme changer d’adresse de bureau puis faire semblant d’être surpris quand le courrier arrive à « Résident inconnu ».

Mode d’urgence pour diagnostic rapide (vérifiez dans cet ordre)

Quand le trafic ou l’indexation semblent anormaux, ne paniquez pas. Exécutez un court triage répétable qui trouve rapidement le goulot d’étranglement.

Première étape : les redirections sont-elles correctes et en un saut ?

• Choisissez 20 URL à fort trafic depuis l’analytics et testez les codes d’état, les en-têtes Location et le nombre de sauts.
• Confirmez que HTTP→HTTPS et non-www→www ne créent pas de sauts supplémentaires.
• Confirmez que l’ancien domaine ne sert rien d’autre que des redirections (sauf peut‑être les challenges ACME).

Deuxième étape : les canonicals sont-ils cohérents ?

• Sur le nouveau domaine, affichez la source et confirmez que le canonique pointe vers le nouveau domaine.
• Vérifiez que les archives paginées, pages de catégories et produits utilisent des règles canoniques cohérentes.
• Confirmez qu’aucun plugin ne réécrit les canonicals vers l’ancien hôte.

Troisième étape : les crawlers peuvent-ils découvrir et récupérer efficacement les nouvelles URL ?

• Vérifiez que les sitemaps se chargent, ne sont pas bloqués et listent l’hôte correct.
• Vérifiez robots.txt : pas d’interdiction accidentelle, directive sitemap pointant vers le nouveau domaine.
• Confirmez la stabilité des réponses serveur : pas de pics 5xx, pas de blocages WAF pour Googlebot.

Quatrième étape : dupliquez-vous accidentellement le site sur plusieurs hôtes ?

• Assurez-vous qu’un seul hôte « préféré » est indexable (www vs apex). Les autres hôtes doivent 301.
• Assurez-vous que l’ancien domaine ne sert pas de pages 200 OK via une contournement (IP d’origine, vhost oublié).

Cinquième étape : les caches vous mentent-ils ?

• Purgez les caches CDN pour les redirections et le HTML.
• Vérifiez si un « mauvais 301 » a été mis en cache avec de longs TTL.
• Confirmez que le cache de pages WordPress ne sert pas d’anciennes balises canoniques.

Checklists / plan étape par étape (pré‑vol à post‑vol)

Phase 0 : Décidez ce que signifie « même URL »

Si vous changez uniquement le domaine (oldsite.com → newsite.com) tout en gardant les chemins identiques, la vie est plus simple. Si vous changez aussi la structure des permaliens, fusionnez des catégories ou « nettoyez le contenu », arrêtez. Séparez en deux projets. La migration de domaine est déjà assez risquée.

Phase 1 : Inventaire et cartographie

• Exportez une liste des URL indexées (Search Console), des pages d’atterrissage principales (analytics) et des URL du sitemap (ancien).
• Créez une carte de redirections : ancienne URL → nouvelle URL, en incluant les cas particuliers (slash final, majuscules, assets legacy).
• Décidez de l’hôte préféré : apex ou www. Choisissez-en un et tenez-vous-y.

Phase 2 : Construisez le nouveau site en parallèle

• Mettez en place le nouveau domaine en staging avec HTTPS.
• Définissez les Home/Site URLs de WordPress sur le nouveau domaine de manière contrôlée.
• Mettez à jour les liens internes, les URLs médias si nécessaire, et le comportement des canonicals.
• Générez les nouveaux sitemaps et vérifiez qu’ils listent uniquement les URL du nouvel hôte.

Phase 3 : Vérifications pré‑cutover

• Lancez un crawl du domaine de staging/nouveau et vérifiez canonicals, codes d’état et distribution des hôtes dans les liens internes.
• Testez les règles de redirection sur un échantillon d’anciennes URL avant que le monde ne les voie.
• Baissez le TTL DNS suffisamment à l’avance (pas cinq minutes avant le cutover).

Phase 4 : Cutover

• Activez les redirections sur l’ancien domaine (niveau serveur préféré).
• Basculez le DNS ou le routage du load balancer pour le nouveau domaine.
• Vérifiez les certificats (anciens et nouveaux si l’ancien sert des redirections HTTPS).
• Surveillez les logs et les taux d’erreur comme si votre vie en dépendait.

Phase 5 : Nettoyage post‑cutover (72 premières heures)

• Soumettez les nouveaux sitemaps, demandez l’indexation des pages clés.
• Surveillez les 404 et les boucles de redirection ; corrigez les lacunes de cartographie.
• Mettez à jour les intégrations tierces et les domaines autorisés.
• Laissez les redirections de l’ancien domaine en place à long terme (pensez 12 mois+ ; plus longtemps est acceptable).

Tâches pratiques avec commandes, sorties et décisions (12+)

Ce sont des contrôles de niveau production. Chacun a : commande → sortie typique → ce que cela signifie → décision suivante. Exécutez-les depuis un shell ayant accès réseau à votre site et, si nécessaire, à vos serveurs.

Task 1: Verify a single URL does a clean one-hop 301

cr0x@server:~$ curl -I https://old.example.com/products/widget
HTTP/2 301
date: Sat, 27 Dec 2025 10:11:02 GMT
location: https://new.example.com/products/widget
cache-control: max-age=3600

Signification de la sortie : HTTP 301 est correct ; Location pointe vers l’URL exacte nouvelle ; aucun saut intermédiaire n’apparaît ici.

Décision : Si Location pointe vers la page d’accueil ou un mauvais chemin, votre carte de redirection est incomplète ou trop générique. Corrigez les règles avant le cutover ou avant que des dommages d’indexation ne se propagent.

Task 2: Measure redirect hop count (chains kill efficiency)

cr0x@server:~$ curl -s -o /dev/null -w "%{url_effective} %{num_redirects} %{http_code}\n" -L https://old.example.com/products/widget
https://new.example.com/products/widget 1 200

Signification de la sortie : Une redirection puis un 200 sur l’URL finale.

Décision : Si num_redirects > 1, réduisez les sauts en consolidant les règles (par ex., combinez http→https et la normalisation d’hôte en une seule redirection lorsque possible).

Task 3: Confirm the old domain never serves 200 content

cr0x@server:~$ curl -I https://old.example.com/
HTTP/2 301
location: https://new.example.com/

Signification de la sortie : L’ancien domaine est strictement un redirecteur.

Décision : Si vous voyez HTTP 200 avec du HTML, vous exécutez deux copies indexables. C’est du contenu dupliqué et de la confusion canonique. Faites en sorte que l’ancien domaine ne serve que des redirections.

Task 4: Spot-check canonical tags on the new domain

cr0x@server:~$ curl -s https://new.example.com/products/widget | grep -i -m1 canonical

Signification de la sortie : Le canonique pointe vers le nouvel hôte et le bon chemin.

Décision : S’il pointe vers old.example.com, vous dites aux crawlers de préférer l’ancien domaine. Corrigez les réglages WordPress, la config du plugin SEO et tout comportement codé en dur dans le thème.

Task 5: Detect mixed content (common after HTTPS migration)

cr0x@server:~$ curl -s https://new.example.com/ | grep -Eo 'src="http://[^"]+' | head
src="http://old.example.com/wp-content/uploads/2023/hero.jpg

Signification de la sortie : Le HTML inclut des URLs d’assets en HTTP (et sur l’ancien domaine).

Décision : Remplacez en base de données et/ou forcez la réécriture du contenu. Le contenu mixte peut casser le rendu des pages et dégrader silencieusement les signaux SEO.

Task 6: Confirm sitemap lists the new host

cr0x@server:~$ curl -s https://new.example.com/sitemap_index.xml | head -n 12



https://new.example.com/post-sitemap.xml

Signification de la sortie : L’index de sitemap existe et référence des sitemaps du nouveau domaine.

Décision : Si les entrées loc pointent vers l’ancien domaine ou http, corrigez les paramètres du générateur de sitemap et purge des caches.

Task 7: Validate robots.txt isn’t blocking the new site

cr0x@server:~$ curl -s https://new.example.com/robots.txt
User-agent: *
Disallow:
Sitemap: https://new.example.com/sitemap_index.xml

Signification de la sortie : Pas d’interdiction globale ; le sitemap pointe correctement.

Décision : Si vous voyez Disallow: / ou des règles de staging, corrigez immédiatement. Un seul robots.txt mauvais peut rendre vos belles redirections inutiles.

Task 8: Ensure WordPress Home/Site URLs are correct via WP-CLI

cr0x@server:~$ wp option get home
https://new.example.com
cr0x@server:~$ wp option get siteurl
https://new.example.com

Signification de la sortie : WordPress pense vivre sur le nouveau domaine pour les deux valeurs.

Décision : Si celles-ci sont sur l’ancien domaine (ou ne correspondent pas), corrigez avec WP-CLI et videz les caches. Home/siteurl mismatched crée des boucles de redirection et des sessions admin cassées.

Task 9: Search for old-domain strings in the database (dry run)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --dry-run --all-tables
+-----------------------+--------------+--------------+
| Table                 | Column       | Replacements |
+-----------------------+--------------+--------------+
| wp_posts              | post_content | 812          |
| wp_postmeta           | meta_value   | 144          |
| wp_options            | option_value | 19           |
+-----------------------+--------------+--------------+
Success: 975 replacements to be made.

Signification de la sortie : Les références à l’ancien domaine sont embarquées dans le contenu/méta/options.

Décision : Planifiez l’exécution réelle dans une fenêtre de maintenance, avec une sauvegarde d’abord. Si les remplacements sont massifs, considérez les données sérialisées et fiez‑vous au traitement sûr de WP-CLI (il gère la sérialisation).

Task 10: Execute the replacement (after backup)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --all-tables --precise
Success: Made 975 replacements.

Signification de la sortie : Les références en base de données ont été mises à jour.

Décision : Purgez immédiatement le cache de pages et l’object cache. Puis re-vérifiez les balises canoniques et les hôtes des liens internes avec un crawl rapide ou un échantillonnage grep.

Task 11: Find top 404s in NGINX access logs after cutover

cr0x@server:~$ sudo awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
48 /wp-content/uploads/2019/legacy-logo.png
31 /category/old-campaign/
19 /products/widget-pro/

Signification de la sortie : Ces chemins sont demandés et renvoient 404.

Décision : Ajoutez des redirections ciblées ou restaurez les assets manquants. Pour les pages de contenu, mappez vers les meilleurs équivalents. Pour les assets, servez-les ou redirigez vers leur nouvelle location ; évitez de rediriger chaque fichier manquant vers la page d’accueil.

Task 12: Confirm TLS cert coverage for both domains

cr0x@server:~$ echo | openssl s_client -servername old.example.com -connect old.example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = old.example.com
issuer=CN = R3, O = Let's Encrypt
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar  9 23:59:59 2026 GMT

Signification de la sortie : L’ancien domaine a un certificat valide, ce qui compte s’il redirige en HTTPS.

Décision : Si le certificat de l’ancien domaine est invalide/expiré, les navigateurs et les crawlers peuvent ne pas suivre les redirections de manière fiable. Renouvelez‑le et automatisez le renouvellement ; ne laissez pas l’ancien domaine dépérir.

Task 13: Validate host normalization (www vs apex) behaves as planned

cr0x@server:~$ curl -I https://new.example.com/ | sed -n '1,5p'
HTTP/2 301
location: https://www.new.example.com/

Signification de la sortie : new.example.com redirige vers l’hôte canonique choisi (www dans cet exemple).

Décision : Assurez-vous que chaque hôte non préféré 301 vers le préféré. Ensuite, assurez‑vous que WordPress génère lui‑même l’hôte préféré dans les liens et les canonicals.

Task 14: Identify redirect loops quickly

cr0x@server:~$ curl -I -L --max-redirs 5 https://old.example.com/wp-admin/ 2>&1 | tail -n 6
curl: (47) Maximum (5) redirects followed

Signification de la sortie : Une boucle existe — souvent causée par des redirections conflictuelles entre WordPress, le serveur web et un CDN.

Décision : Inspectez où la redirection change d’hôte/protocole/chemin. Puis choisissez une couche pour gérer la normalisation (préférez l’edge/serveur web) et configurez WordPress pour s’aligner.

Stratégie de redirection : 301 qui ne s’effondrent pas

Les redirections sont l’épine dorsale de la migration. Si elles sont mauvaises, tout le reste devient un pansement sur un fémur cassé.

Principes qui tiennent la route

• Utilisez des redirections au niveau serveur, pas un plugin WordPress. Vous voulez que les redirections fonctionnent même si PHP est en panne, et vous voulez qu’elles soient rapides.
• Préférez des mappages exacts pour les pages clés. Pour la longue traîne, une règle générale suffit (même chemin sur le nouveau domaine), mais ne devinez pas pour les pages à forte valeur.
• Évitez les chaînes de redirection. Un saut est l’objectif. Deux sont tolérables en urgence. Trois, et vous passerez des mois à déboguer « pourquoi Google ne le voit pas ».
• Ne redirigez pas tout vers la page d’accueil. C’est un pattern de soft-404 et cela jette les signaux de pertinence.
• Laissez les redirections actives longtemps. Les liens externes et les favoris n’expirent pas parce que votre feuille de route le dit.

Exemple Nginx : ancien domaine vers nouveau, préserver le URI

cr0x@server:~$ sudo nginx -T | sed -n '1,40p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# ...snip...
server {
    listen 443 ssl http2;
    server_name old.example.com;

    return 301 https://www.new.example.com$request_uri;
}

Signification de la sortie : Le test de configuration Nginx a réussi ; le bloc server renvoie un 301 unique en préservant le chemin et la query string.

Décision : Si vous avez aussi besoin de normalisation d’hôte sur le nouveau domaine, faites‑le prudemment pour que old→new reste un saut. Cela signifie souvent rediriger l’ancien directement vers l’hôte préféré du nouveau domaine.

Exemple Apache : ancien vers nouveau dans un vhost ou .htaccess

Apache fonctionne bien ; évitez simplement d’empiler les règles d’une façon qui crée des boucles ou des sauts supplémentaires. Si vous pouvez placer les redirections dans la config du vhost plutôt que dans .htaccess, faites‑le pour la performance et la clarté.

Query strings : conservez‑les sauf raison contraire

Les paramètres de campagne et de tracking doivent être conservés. Les supprimer peut simplifier les logs, mais vous perdrez de la visibilité pendant les semaines où vous en avez le plus besoin pour l’attribution.

Blague n°2 : Un 301 mis en cache au bord du CDN, c’est comme des paillettes : une fois que c’est mauvais, c’est mauvais partout et pour toujours.

Canonicals : l’assassin silencieux de vos classements

Si les redirections sont la colonne vertébrale, les canonicals sont le système nerveux. Ils n’apparaissent pas toujours dans les « vérifications de base », mais ils contrôlent quelle URL obtient le crédit.

À quoi doivent ressembler les balises canoniques pendant et après la migration

• Sur le nouveau domaine : le canonique pointe vers la nouvelle URL (canonique auto‑référentielle normale).
• Sur l’ancien domaine : idéalement vous ne servez jamais de pages 200, uniquement des redirections. Si vous devez servir du contenu temporaire, les canonicals doivent quand même pointer vers le nouveau domaine — prudemment et de façon cohérente.
• Choisissez une variante d’hôte : www ou apex. La balise canonique doit correspondre exactement.
• HTTPS partout : le canonique doit être en https si c’est votre schéma canonique.

Où les canonicals échouent dans WordPress

• Configuration du plugin SEO figée sur l’ancien URL du site. Certains plugins stockent des URLs absolues dans les réglages ou les caches.
• Canonique codé en dur dans les templates du thème. Quelqu’un a « optimisé le SEO » en 2018 et laissé une mine antipersonnel.
• Cache de page servant de l’ancien HTML. Vous avez corrigé la base de données, mais le cache sert encore de vieux canonicals.
• Multisite et bizarreries de mapping de domaine. La génération des canonicals peut dépendre des IDs de site et des tables de mapping ; un simple search‑replace peut être insuffisant.

Canonique vs redirection : lequel l’emporte ?

En pratique, les moteurs combinent plusieurs indices. Si votre redirection dit « allez ici » mais que votre canonique dit « préférez l’ancien », vous créez un débat. Les crawlers aiment les instructions claires. Ils sont moins enthousiastes face aux disputes familiales.

Sitemaps : rendez le travail de Google ennuyeux

Les sitemaps ne sont pas de la poussière magique pour le classement. Ce sont des outils opérationnels pour l’indexation. Dans une migration, c’est exactement ce dont vous avez besoin : découverte plus rapide, reporting clair, moins « d’inconnues inconnues ».

Règles pour les sitemaps après un changement de domaine

• Générez des sitemaps qui listent uniquement des URL du nouveau domaine.
• Exposez l’index de sitemap à un emplacement stable (le défaut courant convient).
• Assurez‑vous que les sitemaps retournent un 200 OK, ne sont pas derrière une authentification et ne sont pas bloqués par des challenges WAF.
• Conservez les anciens sitemaps accessibles s’ils sont demandés, mais ils devraient 301 vers les nouvelles locations de sitemap ou être remplacés par des références au nouveau domaine.

Sitemaps d’images et de vidéos

Si votre business dépend de la recherche d’images ou des résultats enrichis, n’oubliez pas les entrées d’image dans les sitemaps. Une migration de domaine peut « fonctionner » pour le HTML tandis que la découverte des médias s’effondre silencieusement parce que les URLs d’images sont encore sur l’ancien hôte ou bloquées par des règles anti‑hotlink.

Search Console et analytics : prouvez que ça a marché

C’est l’endroit où vous transformez « je pense que c’est bon » en preuves. Vous avez besoin de deux types de preuves : la correction côté crawler et le comportement côté utilisateur.

Essentiels Search Console

• Ajoutez et vérifiez la nouvelle propriété de domaine (niveau domaine si possible).
• Soumettez les nouveaux sitemaps.
• Utilisez l’outil de changement d’adresse si applicable à votre configuration (lorsque vous déplacez entre domaines sous la même propriété vérifiée).
• Surveillez les rapports de couverture : pics d’« Excluded », « Crawled – currently not indexed » ou « Duplicate, Google chose different canonical » sont des signaux actionnables.

Essentiels Analytics

• Mettez à jour les paramètres d’URL par défaut si nécessaire (selon la solution analytics utilisée).
• Vérifiez les exclusions de référents et le suivi cross‑domain, surtout si vous avez des flux de checkout.
• Annotez le temps de migration et les corrections majeures (changement de règles de redirection, resoumission de sitemap).

La vérification par logs bat les impressions de tableau de bord

Les tableaux de bord indiquent des résultats. Les logs indiquent des causes. Pendant la première semaine, vous voulez les deux, mais ce sont les logs où vous verrez les patterns de fetch des bots, les boucles de redirection et les grappes de 404 avant qu’un rapport ne les agrège en un vague « baisse ».

Caching/CDN et effets secondaires de performance

Les migrations de domaine impliquent souvent un changement de CDN, de terminaison TLS ou « tant qu’on y est, ajoutons un WAF ». C’est acceptable. C’est aussi comme ça qu’on introduit par inadvertance des blocs de crawler et des bugs de cache.

Cache des redirections : utile jusqu’à ce que ce ne le soit plus

Un 301 est cacheable par les navigateurs et les intermédiaires. C’est une fonctionnalité. C’est aussi pourquoi vous devez tester les règles de redirection avant la mise en production. Si vous déployez un mauvais 301 avec un cache-control généreux, vous avez distribué votre erreur à chaque edge et agent utilisateur qui l’a rencontrée.

Cache de pages et object cache

Après avoir changé de domaine, vous devez purger :

• Le cache full-page (plugin, reverse proxy, CDN).
• Le object cache (Redis/Memcached) car options et fragments rendus peuvent être mis en cache.
• Le cache d’opcode si vous avez déployé une nouvelle config qui affecte la génération d’URL (moins courant, mais ne présumez pas).

Règles WAF et comportement des bots

Les WAF aiment les faux positifs pendant les migrations parce que les patterns de trafic changent : plus de fetchs de bots, plus de probes 404, plus de rafales. Assurez‑vous que votre WAF autorise les crawlers légitimes et ne leur sert pas de challenges JavaScript.

Stockage, sauvegardes et rollback : traitez le contenu comme des données

Les migrations WordPress sont des migrations de données. Le domaine est juste l’élément le plus visible.

Sauvegardez la base et les uploads comme si votre job en dépendait

Vous avez besoin d’un snapshot cohérent à un instant T de :

• La base de données (cohérente au niveau des transactions si possible).
• wp-content/uploads (et tous les répertoires de contenu personnalisés).
• La configuration : wp-config.php, vhosts du serveur web, règles CDN, enregistrements DNS.

Plan de rollback : simple, testé et pas théorique

Un rollback pour une migration de domaine est généralement une inversion DNS + routage plus la désactivation des règles de redirection. Mais cela ne fonctionne que si :

• L’ancien site peut encore servir le contenu original correctement.
• Vous n’avez pas muté la base de données d’une manière qui casse l’ancien domaine (par ex., remplacements irréversibles sans snapshot).
• Vous pouvez réémettre rapidement des certificats valides pour les deux domaines.

Cas limite de stockage : protection anti‑hotlink et assets legacy

Beaucoup de sites ont une protection anti‑hotlink liée au référent ou à l’hôte. Quand vous déplacez le domaine, cette protection peut bloquer vos propres pages de charger des images si les règles n’ont pas été mises à jour. Si vos assets sont stockés dans un object storage derrière un CDN, validez les en‑têtes Host et le comportement des signed URLs.

Trois mini‑histoires d’entreprise issues des tranchées de migration

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

L’entreprise était en plein rebranding. Nouveau domaine, nouveau logo, même WordPress. Quelqu’un a dit, confiant : « Nous allons juste définir le nouveau domaine dans WordPress et il gérera les redirections. » Cela semblait plausible. WordPress redirige certains flux admin et essaie d’être serviable. Serviable n’est pas synonyme de correct.

La nuit du cutover s’est bien passée jusqu’au matin où le trafic est arrivé. Les campagnes payantes pointaient vers l’ancien domaine et étaient redirigées… parfois. D’autres fois, les visiteurs obtenaient un 200 OK sur l’ancienne page d’accueil parce qu’un vhost Apache oublié servait encore du contenu sur l’ancien hôte quand la requête arrivait sans SNI lors d’une mauvaise configuration TLS. Pendant ce temps, les pages produit du nouveau domaine avaient des canonicals pointant vers l’ancien domaine parce que le plugin SEO avait mis en cache les URLs du site.

Le résultat fut une parfaite tempête de « deux sites, un même contenu ». Les crawlers voyaient des duplications. Les utilisateurs constataient un comportement incohérent. Les équipes internes se disputaient car chacun testait une URL différente et obtenait une réalité différente.

La correction fut ennuyeuse : forcer l’ancien domaine à rediriger à la périphérie pour toutes les requêtes, renouveler correctement le certificat de l’ancien domaine, purger les caches et régénérer les canonicals. Ensuite, ils ont passé deux semaines à nettoyer la longue traîne de redirections manquantes découvertes dans les logs.

La leçon : ne supposez pas que la couche applicative possède la migration. Faites du serveur web ou du CDN la source de vérité pour old→new, et faites en sorte que l’application génère des canonicals cohérents pour le nouvel hôte.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait que la migration soit « rapide pour les crawlers ». Leur plan : laisser l’ancien site servir du 200 OK pendant un mois tout en ajoutant rel=canonical vers le nouveau domaine, pensant préserver l’expérience utilisateur et « transitionner Google progressivement ». Ils utilisaient aussi des redirections 302 pour certains chemins « au cas où il faudrait revenir en arrière ».

Cela semblait prudent. Ce ne l’était pas. Ils ont créé trois signaux contradictoires : contenu 200 OK sur les anciennes URL, parfois des 302, et des canonicals pointant ailleurs. Les crawlers ont répondu en hésitant : indexation des deux versions, choix de canonicals par eux‑mêmes, et report de la consolidation parce que rien ne paraissait autoritaire.

Puis le CDN a « aidé » en mettant en cache un sous‑ensemble des 302 avec de longs TTL. Certains clients ont vu l’ancien domaine pendant des semaines ; d’autres ont basculé immédiatement. Les tickets support sont devenus bizarres car les utilisateurs étaient littéralement dans des univers différents selon l’état du cache.

Après avoir couru après des fantômes, ils sont passés à des 301 cohérents pour toutes les anciennes URL, ont rendu l’ancien domaine uniquement redirigeant et ont supprimé la complexité de la transition douce. L’indexation s’est stabilisée. Les classements ont récupéré.

La leçon : les migrations ne sont pas un endroit pour l’ambiguïté des signaux. Si le déplacement est permanent, utilisez des 301, pas des demi‑mesures.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe a réalisé une migration de domaine si discrète que personne en dehors de l’ingénierie ne l’a remarquée. C’est le meilleur compliment qu’on puisse recevoir.

Ils ont commencé par une carte de redirections construite à partir de trois sources : sitemaps existants, pages d’atterrissage principales et logs serveur des 30 derniers jours. Ils ont catégorisé les URLs en : « doit être mappée exactement », « peut être mappée par règle » et « retirée intentionnellement ». Les pages retirées ont reçu des redirections réfléchies vers les équivalents les plus proches — pas la page d’accueil — sauf si elles n’avaient vraiment pas de remplaçant, auquel cas elles retournaient un 410.

Ils ont testé les redirections en staging en rejouant une liste d’anciennes URL et en vérifiant automatiquement les codes d’état et les en-têtes Location. Ils ont aussi contrôlé les balises canonicals et les hostnames des sitemaps avec un petit script et n’ont pas coupé tant que le nombre d’erreurs n’était pas zéro.

Au cutover, ils avaient déjà abaissé le TTL DNS quelques jours avant, les certificats étaient émis, et les caches configurés avec des TTL raisonnables pour les redirections. La salle de crise post‑cutover consistait principalement à surveiller des graphs rester ennuyeux et à répondre à une petite liste de 404 pour des assets legacy obscurs.

La leçon : les pratiques d’ingénierie ennuyeuses — inventaire, automatisation et vérification — ne sont pas de la bureaucratie. Ce sont les moyens d’éviter des réunions d’urgence avec trop de monde.

Erreurs fréquentes : symptômes → cause racine → correction

1) Forte chute de classement qui persiste après deux semaines

Symptômes : Nouvelles pages indexées lentement ; anciennes pages persistent ; augmentation de « Duplicate, Google chose different canonical ».

Cause racine : Signaux contradictoires : redirections non cohérentes, canonicals pointant encore vers l’ancien domaine, ou plusieurs variantes d’hôte renvoyant 200.

Correction : Rendez l’ancien domaine uniquement redirigeant. Assurez une seule variante d’hôte préférée sur le nouveau domaine. Auditez les canonicals sur tout le site et purgez les caches. Réduisez les chaînes de redirection à un seul saut.

2) Tout redirige vers la page d’accueil

Symptômes : Les utilisateurs se plaignent « les liens n’amènent pas au bon produit » ; Search Console montre des soft 404 ; le trafic longue traîne disparaît.

Cause racine : Règle de redirection trop large sans préservation du chemin ou table de mapping manquante.

Correction : Implémentez une redirection préservant le chemin. Ajoutez des redirections explicites pour les sections déplacées/renommées. Utilisez les logs pour prioriser les 404 à fort volume et corrigez itérativement.

3) Boucles de redirection infinies

Symptômes : Le navigateur affiche « trop de redirections » ; curl atteint max-redirs ; login admin cassé.

Cause racine : Normalisation conflictuelle entre CDN, serveur web et WordPress home/siteurl ; enforcement mixte HTTP/HTTPS.

Correction : Choisissez une couche pour appliquer le schéma et l’hôte (préférez l’edge/serveur web). Réglez home et siteurl de WordPress sur le canonique final. Assurez-vous que X-Forwarded-Proto soit correct derrière un proxy.

4) Le nouveau site se charge mais images/CSS cassés

Symptômes : Styles manquants, images cassées, erreurs console ; métriques SEO en baisse.

Cause racine : Contenu mixte (assets http), URLs d’assets codées en dur sur l’ancien domaine, ou protection anti‑hotlink liée à l’ancien domaine.

Correction : Search‑replace en base pour les anciens hostnames ; mettez à jour CDN/règles anti‑hotlink ; assurez des URLs d’assets en HTTPS. Purgez les caches.

5) Search Console indique « Submitted URL blocked by robots.txt »

Symptômes : Sitemap soumis mais URLs exclues ; crawl bloqué.

Cause racine : robots.txt de staging déployé en prod ou plugin réglé pour décourager l’indexation.

Correction : Corrigez robots.txt et le réglage WordPress « Discourage search engines ». Demandez un re‑crawl et resoumettez les sitemaps.

6) Les redirections fonctionnent pour les humains mais les crawlers sont bloqués

Symptômes : Dans les logs, Googlebot reçoit 403/429 ; indexation ralentie ; dashboards WAF montrent des blocages.

Cause racine : WAF/protection bots non ajustés pour le comportement des crawlers ; limites de taux trop strictes ; pages de challenge servies.

Correction : Autorisez les IPs vérifiées des crawlers où approprié (avec précaution), réduisez les faux positifs et assurez que les bots puissent récupérer les sitemaps et le HTML sans challenges JS.

7) L’ancien domaine se classe encore au lieu du nouveau domaine

Symptômes : SERP montrent les anciennes URLs ; nouvelles URLs apparaissent sporadiquement ; les backlinks semblent « ne pas transférer ».

Cause racine : Les anciennes URLs renvoient 200 ou ont des canonicals vers elles‑mêmes ; les redirections sont 302 ou incohérentes.

Correction : Passez à des 301 cohérents. Éliminez les réponses 200 de l’ancien domaine. Assurez que les nouvelles URLs se canonisent elles‑mêmes. Laissez les redirections stables à long terme.

FAQ

1) Combien de temps dois‑je garder les redirections de l’ancien domaine ?

Au moins 12 mois. Plus longtemps est plus sûr. Les liens externes, favoris et crawlers lents continueront de toucher les anciennes URLs pendant des années.

2) Dois‑je utiliser un plugin pour les redirections dans WordPress ?

Non pour une migration à l’échelle du domaine. Faites les redirections au niveau web server ou CDN. Utilisez les redirections WordPress seulement pour un petit nombre de corrections éditoriales où vous avez besoin de la commodité UI.

3) Dois‑je changer la structure des permaliens pendant le déplacement de domaine ?

Ne le faites pas. Séparez les projets. Si vous changez à la fois le domaine et les chemins d’URL, le débogage devient de l’archéologie.

4) Quelle est la meilleure redirection : 301 ou 308 ?

Les deux sont permanents. Le 308 préserve strictement la méthode ; le 301 est universellement compris et conventionnel pour le contenu web. Utilisez 301 sauf raison solide de faire autrement.

5) Dois‑je mettre à jour les liens internes si les redirections fonctionnent ?

Oui. Les liens internes pointant vers l’ancien domaine gaspillent le budget de crawl et masquent des problèmes. Mettez‑les à jour pour que le site navigue directement vers les URLs canoniques.

6) Et www vs non‑www ?

Choisissez un hôte préféré et appliquez‑le partout : redirections, canonicals, sitemaps et réglages WordPress. L’incohérence ici crée des URLs dupliquées qui se concurrencent.

7) Y aura‑t‑il une baisse de trafic quoi qu’il arrive ?

Il y a généralement une oscillation à court terme. L’objectif est de minimiser la durée et l’amplitude en fournissant des signaux cohérents et en évitant les inefficacités de crawl (chaînes, duplications, ressources bloquées).

8) Puis‑je supprimer immédiatement le contenu de l’ancien site après la migration ?

Supprimez le contenu oui. Supprimez l’infrastructure de l’ancien domaine qui sert des redirections, non. Gardez l’ancien domaine servant des redirections rapides et fiables en HTTPS avec des certificats valides.

9) Comment gérer les pages retraitées sans équivalent ?

Si aucun équivalent significatif n’existe, retourner 410 peut être approprié. S’il existe une alternative proche, redirigez‑y. Évitez de rediriger tout vers la page d’accueil ; cela ressemble à un soft 404.

10) Dois‑je resoumettre des fichiers de désaveu ou quelque chose de ce genre ?

C’est spécifique au cas et peu courant de nos jours. Concentrez‑vous d’abord sur les redirections, les canonicals et la correction des sitemaps — ce sont les leviers qui influencent les résultats de façon fiable.

Prochaines étapes pratiques

Si vous voulez une migration de domaine qui ne devienne pas une réunion récurrente, faites trois choses maintenant :

1. Élaborez une carte de redirections à partir de données réelles (sitemaps, analytics, logs) et testez‑la avec curl avant le cutover.
2. Auditez les canonicals et les liens internes sur le nouveau domaine, puis purgez chaque couche de cache qui peut servir de l’ancien HTML.
3. Opérationnalisez la vérification : surveillez les logs pour des grappes de 404, confirmez les redirections en un seul saut et maintenez la TLS et les redirections de l’ancien domaine en bonne santé à long terme.

Le SEO lors d’une migration consiste surtout à réduire l’ambiguïté. Donnez aux crawlers une histoire claire, servez‑la de façon cohérente et n’essayez pas de « trop optimiser » au point de vous mettre dans une impasse.