Refonte et référencement
Une refonte ne conserve pas le référencement par magie. Elle le protège en traitant chaque adresse, chaque lien et chaque signal avant la mise en ligne, puis en surveillant ce que Google recrawle réellement.
La réponse courte
Pour limiter les pertes évitables, il faut inventorier les URL actuelles, décider lesquelles conserver, fusionner ou supprimer, établir une correspondance vers chaque nouvelle adresse, poser des redirections permanentes directes, mettre à jour les liens et balises internes, puis suivre l’exploration et les clics dans Search Console. Une fluctuation temporaire reste possible pendant le recrawl : aucun prestataire sérieux ne peut promettre zéro mouvement.
Le risque réel
Le design n’est pas le problème en soi. Le risque apparaît quand la nouvelle version modifie la façon dont les contenus sont adressés, reliés, rendus ou accessibles aux moteurs.
Une page qui recevait des clics, des liens ou des impressions disparaît. Sans destination équivalente et sans redirection permanente, le nouveau site repart avec une adresse que Google doit découvrir et évaluer comme si le lien entre les deux versions n’existait pas.
Une maquette peut sembler plus claire tout en supprimant les réponses, exemples, preuves ou variantes de vocabulaire qui permettaient à la page de répondre à une recherche. Le contrôle compare donc le contenu ancien et nouveau, pas seulement les gabarits.
Un lien interne qui pointe encore vers une ancienne adresse ajoute une redirection à chaque passage. Une canonical, une annotation hreflang ou un sitemap resté sur l’ancien plan envoie également des signaux contradictoires.
Une page peut paraître correcte à l’écran et rester bloquée par noindex, robots.txt, une réponse serveur inattendue ou un rendu incomplet. La recette doit vérifier ce qu’un crawler reçoit, et pas seulement ce qu’un humain voit.
Avant la mise en ligne
Le document central n’est pas une liste de pages à fabriquer. C’est une table de décision qui relie l’existant, la nouvelle architecture et la preuve ayant conduit à chaque choix.
Croisez le sitemap, le crawl, les pages vues dans l’analytics, les clics et impressions Search Console, les journaux serveur si vous les avez, et les liens externes connus. Une URL absente du menu peut encore porter du trafic ou un backlink utile.
Conserver une page signifie garder son adresse et son rôle. Fusionner suppose une destination réellement équivalente qui reprenne l’information utile. Retirer est légitime quand aucun contenu de remplacement n’existe : une réponse 404 ou 410 claire vaut mieux qu’une redirection vers une page hors sujet.
Testez les gabarits, les données structurées, les liens, les canonical, les hreflang, les performances et le rendu mobile avant l’ouverture. Un environnement de préproduction peut rester en noindex, mais la liste de ce qui doit être retiré au lancement doit être écrite et testable.
Plan de redirections
Chaque ligne relie une ancienne adresse à son traitement. Les cas sans équivalent ne sont pas masqués : ils reçoivent une décision explicite et une personne responsable.
| Décision | Ce que la table contientpreuve et destination | Contrôle de recettece qui doit être vrai |
|---|---|---|
| URL conservée | Ancienne URL = nouvelle URL, contenu et intention comparés. | Réponse 200, canonical propre, liens internes directs. |
| URL déplacée | Ancienne URL, nouvelle URL équivalente, motif du déplacement. | Redirection permanente côté serveur, en un seul saut. |
| Pages fusionnées | Toutes les sources, une destination qui reprend leur information utile. | Chaque source redirige vers la destination, sans chaîne ni boucle. |
| Contenu retiré | Motif, absence d’équivalent, trafic et liens vérifiés. | 404 ou 410 réelle ; aucune redirection vers une page non pertinente. |
Google recommande les redirections permanentes côté serveur, notamment 301 ou 308, et demande de mettre les liens internes à jour vers les nouvelles URL. Une redirection n’est pas une raison pour laisser le site continuer à l’emprunter.
Jour J
Le lancement doit pouvoir être vérifié par une autre personne que celle qui a configuré la migration. La checklist ci-dessous porte sur les réponses réelles du site public.
01
Retirer les noindex et blocages temporaires prévus, puis vérifier robots.txt sur le domaine public. Les espaces privés et les pages non indexables restent bloqués selon leur propre règle.
02
Tester un échantillon de chaque règle, puis le fichier complet : statut permanent, destination finale correcte, absence de boucle, de chaîne et de redirection hors sujet.
03
Contrôler canonical, hreflang, liens internes, données structurées, images et réponses serveur. Le sitemap nouveau ne doit annoncer que les URL que vous souhaitez voir dans les résultats.
04
Soumettre le nouveau sitemap. Utiliser l’outil Changement d’adresse seulement lors d’un changement de domaine ou de sous-domaine, pas pour une simple refonte qui garde le même domaine.
Après le lancement
Trente jours constituent un premier cycle de contrôle, pas une date de fin garantie. Google précise qu’une migration avance URL par URL et qu’un site moyen peut demander plusieurs semaines avant que la majorité de ses pages soient retraitées.
| Signal | Jours 0–2erreurs bloquantes | Jours 3–14recrawl et couverture | Jours 15–30+tendance et écarts |
|---|---|---|---|
| Serveur et crawl | 5xx, boucles, chaînes, robots et noindex inattendus. | 404 nouvelles, anciennes URL encore demandées, rythme de crawl. | Erreurs persistantes, ressources oubliées et anciennes URL actives. |
| Indexation | Inspection d’un échantillon prioritaire. | Pages découvertes dans le sitemap et motifs d’exclusion. | Anciennes URL qui baissent, nouvelles qui entrent dans l’index. |
| Visibilité | Point zéro conservé, pas de conclusion sur quelques heures. | Impressions, clics et requêtes comparés par groupes de pages. | Écart par gabarit et intention, pas seulement un total de domaine. |
| Comportement | Analytics et événements critiques encore reçus. | Pages d’entrée, formulaires et parcours comparés. | Conversion et qualité du trafic vérifiées avec la visibilité. |
Conservez les redirections au moins un an selon Google, et si possible plus longtemps pour les utilisateurs et les anciens liens. Le suivi ne s’arrête pas parce qu’un tableau est vert : il s’arrête quand les anciennes et nouvelles URL racontent une transition cohérente.
Application à votre site
Un audit de pré-refonte utile ne se contente pas d’un score global. Il doit rendre l’inventaire exploitable : les URL qui reçoivent encore des impressions, les pages enfouies, les liens cassés, les canonical incohérentes et les gabarits qui créent le même défaut en série.
La décision reste humaine. L’outil rassemble les constats et les preuves ; l’agence confronte ensuite la migration à l’offre, aux contraintes du CMS, aux contenus à préserver et au rythme de validation disponible.
Pour cadrer le point de départ et l’exécution : voir ce que contrôle l’audit SEO, voir les étapes de notre refonte.
Pour préparer l’inventaire et le maillage : les 12 points à vérifier avant de refaire le site, repérer les pages enfouies dans l’arborescence.
Sources primaires
Les recommandations volatiles de cette page ont été recoupées le 12 août 2026 avec la documentation officielle de Google Search Central.
Inventaire, mapping, redirections permanentes, mise à jour des liens, sitemap et suivi Search Console.
Cas distinct où le DNS et la capacité de l’infrastructure deviennent les sujets principaux.
Rôle des redirections permanentes, des canonical et du sitemap dans le choix de l’URL principale.
Non. Une fluctuation temporaire peut arriver pendant que Google recrawle et réindexe les nouvelles URL, mais une baisse durable n’est pas une fatalité. Les pertes évitables viennent surtout d’URL non mappées, de contenus retirés, de redirections incorrectes ou de signaux techniques contradictoires.
Avant la première redirection
L’audit donne un point zéro avant que la nouvelle architecture ne masque les anciennes erreurs — et les pages qui portaient déjà votre visibilité.