Refonte de site : les contrôles SEO avant, pendant et après la bascule

Avant : inventorier et décider. Pendant : tester la version livrée. Après : vérifier et mesurer. Illustration de méthode, pas un cas client ; ce schéma ne documente aucune migration réelle ni un résultat SEO.

Une refonte se voit d'abord à l'écran. Sa recette doit aussi répondre à des questions moins visibles : les anciennes adresses conduisent-elles au bon endroit, les contenus utiles sont-ils encore présents, les pages publiques sont-elles accessibles aux moteurs, et les demandes de contact fonctionnent-elles ?

Voici une méthode en trois moments. Chaque contrôle associe une action, sa raison, une preuve datée et une personne qui valide. Selon le projet, une même personne peut remplir plusieurs rôles. La méthode limite les oublis ; elle ne promet ni conservation exacte des positions ni absence de fluctuation. Google indique qu'un changement important de site peut entraîner des variations pendant la nouvelle exploration et indexation (guide de migration Google).

Avant la bascule : décider ce qui doit rester accessible

1. Inventorier les URL et les pages utiles

• Action : relever les adresses du site actuel au moyen d'un crawl, du sitemap, du CMS et des pages qui reçoivent visites ou liens connus. Noter statut HTTP, titre, contenu principal, liens internes et rôle de chaque page. Un crawl seul peut manquer des URL orphelines ou anciennes.
• Pourquoi : on ne peut pas vérifier une page disparue si personne ne sait qu'elle existait.
• Preuve à demander : inventaire daté avec URL, source de découverte et décision provisoire « conserver / déplacer / fusionner / retirer ». Pour les pages importantes, garder un relevé Search Console de référence et sa période.
• Responsable : référent SEO ou technique prépare ; responsable du site valide les pages à préserver.
• Erreur fréquente : ne relever que le menu visible et oublier une ressource encore visitée depuis Google ou un lien externe. Google recommande plusieurs sources pour retrouver les anciennes URL (documentation sur le mapping).

2. Valider la correspondance et les contenus avant de développer

• Action : associer chaque ancienne URL à une page finale de même intention si l'adresse change ; conserver l'URL lorsqu'elle reste pertinente. Pour une suppression sans remplaçant, décider explicitement du traitement. Relire les réponses utiles, informations métier et appels à l'action des pages prioritaires.
• Pourquoi : une redirection ne répare pas une destination sans rapport, et un nouveau design ne compense pas un contenu devenu incomplet.
• Preuve à demander : tableau « ancienne URL → décision → nouvelle URL ou retrait motivé », plus une comparaison courte des contenus importants avant/après.
• Responsable : référent contenu et SEO préparent ; propriétaire du site approuve fusions et retraits.
• Erreur fréquente : envoyer toutes les anciennes pages vers l'accueil. Google déconseille les destinations non pertinentes et prévoit 404 ou 410 pour du contenu retiré sans remplacement (guide de migration).

3. Définir le contrôle technique et le retour arrière

• Action : préciser les URL publiques attendues, les pages à exclure volontairement, les canonical, le sitemap, le robots.txt, les métadonnées et le comportement de l'environnement de test. Écrire ce qui bloque la mise en ligne et qui décide d'une correction ou d'un retour arrière technique.
• Pourquoi : un noindex de préproduction laissé sur le site public ou un sitemap pointant vers les anciennes adresses peut contredire le plan de bascule.
• Preuve à demander : grille de recette par URL, version de la configuration à déployer, résultat attendu de chaque test et responsable de décision.
• Responsable : développeur prépare la configuration ; référent SEO et responsable de mise en ligne valident.
• Erreur fréquente : traiter robots.txt, noindex et canonical comme trois façons équivalentes de cacher ou sélectionner une page. Google précise qu'une directive noindex doit pouvoir être découverte par exploration et qu'une canonical reste un signal, pas un ordre garanti (directives robots, canonicalisation).

4. Figer une référence de mesure et les parcours essentiels

• Action : noter les périodes comparables dans Search Console, les événements réellement mesurés, les formulaires et leur destination. Prévoir un test de contact interne autorisé, avec nettoyage des données de test si nécessaire. Vérifier la gestion du consentement des traceurs dans la nouvelle version.
• Pourquoi : après la mise en ligne, une baisse apparente peut venir d'une mesure cassée, d'un périmètre de dates différent ou d'un parcours qui ne transmet plus les demandes.
• Preuve à demander : export daté et périmètre de la référence, plan de mesure, résultat de recette du formulaire et contrôle acceptation/refus des traceurs pertinents.
• Responsable : référent mesure et responsable du traitement préparent ; responsable du site accepte le protocole de test.
• Erreur fréquente : supposer qu'un outil de mesure est toujours exempté de consentement. La CNIL soumet cette exemption à des conditions et à la configuration réelle de l'outil (fiche CNIL).

Pendant la bascule : vérifier la version livrée

Ces tests se préparent sur une version de recette, puis se répètent sur les URL publiques dès l'ouverture du nouveau site. Un résultat « OK en préproduction » n'est pas une preuve que la Production répond de la même façon.

5. Tester les réponses HTTP et les redirections

• Action : lancer la liste des anciennes URL contre le site final. Pour chaque adresse déplacée, vérifier une redirection permanente (301 ou 308) vers la bonne page, sans chaîne inutile. Pour une page réellement retirée sans équivalent, vérifier le statut décidé.
• Pourquoi : les visiteurs, moteurs et anciens liens doivent atteindre une destination utile.
• Preuve à demander : export daté « ancienne URL / statut / destination finale / statut final / anomalie » et correction des lignes en échec.
• Responsable : développeur implémente ; référent SEO valide la destination, pas seulement le code HTTP.
• Erreur fréquente : accepter une redirection vers la page d'accueil parce qu'elle renvoie 200, ou tester seulement trois URL faciles. Google recommande les redirections serveur permanentes et la destination finale directe (guide de migration).

6. Lire les pages finales, pas seulement leur statut

• Action : contrôler les titres, descriptions, H1, contenu principal, liens, images importantes et version mobile des pages prioritaires. Vérifier le HTML reçu et, si la page dépend de JavaScript, son rendu effectif.
• Pourquoi : une page peut répondre 200 tout en ayant perdu son texte, sa navigation ou une information essentielle.
• Preuve à demander : comparaison datée de quelques pages représentatives, extraits HTML/rendu et liste des écarts à corriger.
• Responsable : référent contenu valide le sens ; développeur corrige le rendu ; QA confirme la lecture mobile.
• Erreur fréquente : confondre « page chargée dans mon navigateur » avec « contenu disponible au moment de l'exploration ». Google distingue exploration, rendu et indexation (documentation JavaScript).

7. Aligner canonical, sitemap, robots et liens internes

• Action : vérifier que les pages destinées à la recherche pointent vers leurs URL finales cohérentes ; le nouveau sitemap actif doit lister les URL finales indexables, pas les anciennes URL redirigées. Un ancien sitemap distinct peut rester soumis temporairement dans Search Console pour suivre la migration, à condition de documenter cette exception. Relire les liens internes et préserver les exclusions volontaires des espaces privés. Une page légale publique doit rester accessible ; un éventuel noindex motivé est une décision distincte, pas une mise en privé.
• Pourquoi : des signaux contradictoires rendent le nouveau parcours moins clair pour les visiteurs et les moteurs.
• Preuve à demander : relevé par page « URL / canonical / directive robots / présence sitemap / liens entrants internes », avec les exceptions motivées.
• Responsable : développeur génère ; référent SEO contrôle ; propriétaire du site confirme ce qui doit rester non public.
• Erreur fréquente : publier dans le nouveau sitemap une ancienne adresse pendant que la canonical suggère la nouvelle. Google traite ces éléments comme des signaux de forces différentes, dont la cohérence compte (documentation canonical). L'ancien sitemap éventuellement conservé pour le suivi est une exception temporaire distincte (guide de migration).

8. Recetter la prise de contact et décider du feu vert

• Action : essayer le parcours essentiel sur mobile et ordinateur, avec un protocole de test interne autorisé. Vérifier l'affichage, la validation du formulaire, la confirmation et la notification prévues, ainsi que la mesure dans les conditions de consentement retenues. Conserver une version de retour arrière technique prête si un défaut bloquant est découvert.
• Pourquoi : une refonte accessible dans Google peut tout de même empêcher un visiteur de contacter l'entreprise.
• Preuve à demander : procès-verbal court « cas testé / résultat attendu / résultat observé / date / version / anomalie », puis décision explicite GO, GO avec réserve documentée ou STOP. Une réserve ne doit pas masquer un formulaire cassé.
• Responsable : QA exécute ; responsable du site ou de mise en ligne tranche. Le référent SEO vérifie les points d'indexabilité.
• Erreur fréquente : basculer sur la seule foi d'une capture visuelle ou laisser un test créer des données commerciales sans les identifier.

Après la bascule : constater, corriger, mesurer

9. Refaire immédiatement les contrôles sur le site public

• Action : relire les pages prioritaires, anciennes URL, redirections, formulaires et fichiers robots.txt/sitemap sur le domaine réel. Comparer les résultats à la grille de recette, version et heure incluses.
• Pourquoi : configuration, cache ou domaine final peuvent différer de la préproduction.
• Preuve à demander : relevé HTTP/HTML public daté, anomalies classées et corrections vérifiées ; décision de retour arrière technique si le seuil convenu est franchi.
• Responsable : référent technique surveille ; responsable de mise en ligne décide ; référent SEO valide les URL critiques.
• Erreur fréquente : écrire « validé » parce que la homepage s'ouvre, alors que des pages secondaires gardent un noindex ou une redirection erronée.

10. Suivre l'exploration et l'indexation sans les confondre

• Action : examiner les rapports de pages, les sitemaps et l'inspection de quelques URL représentatives dans Search Console. Si des URL ont changé, fournir le nouveau sitemap selon le plan ; enregistrer séparément toute demande d'indexation justifiée. Suivre les 404 inattendus et les anciennes adresses encore appelées.
• Pourquoi : accessibilité HTTP, exploration, indexation et visibilité sont quatre états différents.
• Preuve à demander : état GSC daté par URL, dernier crawl connu, motif d'exclusion éventuel et ticket de correction. « Indexable » ne vaut pas « indexé ».
• Responsable : référent SEO relève ; développeur corrige les causes techniques ; propriétaire du site arbitre les retraits de contenu.
• Erreur fréquente : relancer l'inspection ou la demande d'indexation en boucle au lieu de corriger la cause. Google précise que soumettre plusieurs fois la même URL n'accélère pas son exploration (demander une nouvelle exploration).

11. Comparer des périodes complètes avant de conclure

• Action : comparer dans Search Console des fenêtres de même longueur et de même périmètre, par pages et requêtes utiles ; noter la date de bascule et les autres changements simultanés. Vérifier séparément les demandes de contact et leur attribution réellement disponible.
• Pourquoi : un ou deux jours de données incomplètes ne démontrent ni une perte durable ni un gain dû à la refonte.
• Preuve à demander : tableau daté avant/après avec impressions, clics, position, fenêtre, filtres, pages et limites d'interprétation ; journal de corrections et nouvelle vérification après chacune.
• Responsable : référent mesure prépare ; responsable du site interprète et décide de la suite.
• Erreur fréquente : additionner des lignes de pages ou rapprocher deux périodes non comparables. Search Console précise que ses agrégations diffèrent selon les dimensions et que les données récentes peuvent être préliminaires (aide officielle).

Le livrable à demander : une fiche de recette datée

Une checklist cochée ne suffit pas si l'on ignore sur quelle version elle a été testée. Pour chaque point décisif, gardez l'URL ou le parcours, l'attendu, l'observé, la preuve datée, le responsable et le statut (OK, À corriger ou Non contrôlé). Une case vide reste non contrôlée. Les retraits et exceptions doivent avoir un motif validé.

Une refonte se valide donc en trois temps : une correspondance claire avant, une recette de la version livrée pendant, et des observations datées après. Les fluctuations de visibilité restent possibles ; elles appellent des vérifications, pas une promesse de « zéro perte ».

Vous préparez ce changement à Marseille ? Découvrez le périmètre de notre accompagnement en refonte de site.