Deux consultants associent chaque ancienne page imprimée à sa destination avant un changement de CMS

Changement de CMS · SEO

Changer de CMS sans perdre son référencement

Le CMS peut changer. Les URL utiles, les réponses recherchées et les preuves qui gagnent des liens doivent rester reconnaissables.

Sur cette page

Exporter l’état de départ

Sans référence avant migration, une baisse devient une opinion.

On conserve les URL indexées, clics, impressions, pages d’entrée, liens externes, conversions, URL canoniques et règles d’indexation.

La mesure IA reste séparée : Google expose les impressions AI Overviews et AI Mode par page, pays, appareil et date ; Bing expose des citations et un échantillon de requêtes d’ancrage. Ces métriques ne se comparent pas entre elles.

  • Search Console et Bing
  • Impressions Google et citations Bing séparées
  • Analytics et formulaires
  • Codes HTTP et URL canoniques

Décider URL par URL

Une redirection générale vers l’accueil ressemble à un rangement, mais elle perd l’intention.

Chaque URL conservée garde son adresse ou reçoit le successeur le plus proche. Les doublons peuvent converger vers une page plus forte ; les suppressions sans équivalent répondent honnêtement en 404 ou 410.

Les liens internes, les menus, les plans de site et les campagnes utilisent directement les nouvelles URL.

  • Conserver
  • Fusionner
  • Rediriger
  • Supprimer volontairement

Ne pas confondre migration et réécriture totale

Changer la technologie, les URL, la structure et le message le même jour rend le diagnostic impossible.

On protège d’abord la réponse qui fonctionne : titre, informations, médias, preuves et liens utiles. Les améliorations éditoriales peuvent suivre par lots mesurables.

Google recommande de changer une chose à la fois quand le projet le permet. C’est moins spectaculaire et beaucoup plus lisible.

  • Contenu utile préservé
  • Changements séquencés
  • Métadonnées comparées
  • Données structurées fidèles

Surveiller les deux côtés

Les robots doivent revoir les anciennes et les nouvelles URL avant que la migration soit réellement digérée.

On garde les anciennes propriétés accessibles, soumet le nouveau plan de site et inspecte les destinations prioritaires.

On vérifie aussi le contrôle « Search generative AI » sur chaque propriété ancienne et nouvelle, ainsi que son héritage depuis une propriété parente. Un robots.txt correct ne prouve pas que l’inclusion IA est active.

Les paramètres gclid, gbraid, wbraid, _gl et utm_* traversent les redirections. La mesure multidomaine et le consentement sont testés avant la bascule, sans recréer artificiellement une session.

On distingue les URL de pages qui changent des identifiants d’entité qui doivent durer : Organization conserve BCE/TVA, iso6523 et sameAs. Search Console, Bing et IndexNow sont vérifiés séparément sur chaque hôte autorisé.

  • Anciennes URL accessibles aux robots
  • Nouveau plan de site
  • Contrôle IA et héritage vérifiés
  • Demandes métier comparées
  • Paramètres de campagne préservés
  • Mesure multidomaine testée
  • Identifiants Organization stables
  • IndexNow validé par hôte

Contrôler les surfaces que le crawl HTML ne voit pas

Les PDF, variantes linguistiques et tags tiers peuvent diverger alors que les pages HTML semblent correctes.

Les PDF, documents bureautiques et autres fichiers indexables exposent un en-tête HTTP Link canonique absolu cohérent avec le plan de redirection. Leur ancien et leur nouvel hôte sont testés directement, sans déduire leur état depuis la balise canonique d’une page HTML.

Chaque langue possède une URL explorable sans cookie ni interaction. Si Accept-Language, la géolocalisation ou un cookie adapte la réponse, la clé CDN et l’en-tête Vary empêchent une variante française, néerlandaise ou anglaise d’être servie sur la mauvaise URL.

Les scripts tiers et conteneurs de tags sont figés et versionnés pendant la comparaison. Pour chaque tag, on nomme le propriétaire, la finalité, les données lues, les destinations et la règle de consentement ; la mesure est contrôlée dans le navigateur, pas seulement dans le code déployé.

  • Link canonique sur les fichiers non HTML
  • URL linguistiques explorables sans état
  • Cache CDN séparé par variante réelle
  • Tags tiers inventoriés et gelés

Tester les limites réelles du crawl en 2026

Un navigateur qui affiche la page ne prouve pas que Google reçoit les mêmes octets, le même statut ou la même identité.

Googlebot ne récupère que les 2 premiers Mo d’une URL, en-têtes compris. Le titre, la balise canonique, les règles robots et les données structurées essentielles restent donc tôt dans un HTML sobre. Le contenu mobile est équivalent à la version de bureau et le contenu différé apparaît dans la zone visible : Google ne clique ni ne scrolle, et un défilement infini garde des URL paginées persistantes.

Les pages indexables répondent 200 avec leur contenu et leurs liens utiles déjà présents ; Google peut ignorer le rendu JavaScript d’un statut non-200. Le robots.txt reste sous 500 Kio et sa fin n’abrite aucune règle critique. Sa bascule est testée séparément, car après un 5xx Google peut suspendre le crawl puis réutiliser l’ancienne version valide pendant plusieurs semaines.

Les campagnes suivent la migration : URL finales, URL mobiles, modèles de suivi et redirections entre domaines Google Ads sont corrigés ensemble. Pour une boutique, le nouveau domaine Merchant Center est revendiqué et les flux de produits, images, prix et disponibilité sont réémis. La nouvelle propriété Search Console démarre son propre export BigQuery avant la bascule ; son premier export ne reconstitue pas l’historique.

Les sections éditoriales tierces, annuaires et pages en marque blanche sont inventoriés selon la politique de réputation Google mise à jour le 28 août 2026. Une nouvelle adresse est aussi vérifiée séparément dans Sources préférées : seuls les domaines et sous-domaines sont éligibles, et aucun transfert automatique des choix utilisateurs n’est promis.

  • HTML critique avant 2 Mo
  • Parité mobile et contenu sans clic
  • 200 rendu côté serveur et robots.txt borné
  • Ads, Merchant Center et export BigQuery migrés
  • Réputation et Sources préférées réévaluées

Décider avant la bascule

Changer le moteur sans perdre la route

  1. Mesures SEO et IA exportées
  2. Table URL validée
  3. Contenu critique gelé
  4. Redirections testées
  5. Contrôle IA vérifié sur les deux propriétés
  6. Attribution et graphe d’entités comparés
  7. En-têtes HTTP canoniques des documents comparés
  8. Cache FR/NL/EN testé à froid et à chaud
  9. Conteneur de tags signé et approuvé
  10. HTML et rendu mobile inspectés par Google
  11. Statuts et robots.txt testés depuis l’ancien et le nouvel hôte
  12. Comptes Ads, Merchant et BigQuery migrés si applicables
  13. Contenus tiers et Sources préférées réévalués

Sources officielles

Google · migrations avec changement d’URLWordPress · migrer un siteGoogle · performance dans les fonctions IAGoogle · contrôle d’inclusion dans les fonctions IAGoogle · optimiser pour les fonctions IA générativeBing · performance dans les réponses IAGoogle · mesure multidomaineIndexNow · protocoleGoogle · données structurées OrganizationVercel · configurer CORSLet’s Encrypt · IPv6Let’s Encrypt · CAAMDN · TLS et HSTSWHATWG · stockage web par origineCNIL · données personnelles en environnement de testCloudflare · contrôler le DNS avant migrationEDPB · responsable et sous-traitantGoogle · en-tête HTTP canonique des documentsGoogle · pages adaptées aux paramètres régionauxMDN · en-tête de variation du cacheOWASP · JavaScript tiersGoogle · limite de 2 Mo de GooglebotGoogle · contenu chargé progressivementGoogle · indexation mobile-firstGoogle · JavaScript et statuts HTTPGoogle · spécification robots.txtGoogle · URL finales des annoncesGoogle · export massif Search ConsoleGoogle · domaine Merchant CenterGoogle · politique sur la réputation du siteGoogle · sources préférées

Votre visibilité · 02:00

Chiffrez la prochaine étape, pas une promesse vague.

Indiquez votre situation et voyez le périmètre conseillé avant de parler budget.