Sitemap et CMS
Ils donnent la structure publiée : pages, articles, catégories, fichiers et contenus encore administrés.
Refonte de site internet : comment ne pas perdre son SEO
Une refonte de site peut tout améliorer,mais Google peut perdre vos anciennes URL. Faisons mieux.
Le nouveau site est plus beau. Google, lui, ne le retrouve plus. Le problème n'est pas la nouvelle maquette : ce sont les anciennes URL disparues, les liens envoyés vers la page d'accueil et le noindex de préproduction resté actif le jour du lancement. Une refonte réussie transmet l'existant avant d'ajouter du nouveau.
Une refonte est aussi une migration, même si le domaine ne change pas
Changer le design paraît visible. Changer les URL l'est beaucoup moins. Pourtant, pour Google, /services/creation-site et /expertises/site-web sont 2 adresses différentes. Si l'ancienne disparaît sans redirection, son historique ne suit pas automatiquement la nouvelle.
Le même risque existe quand on change de CMS, de structure de catégories ou de format d'URL. Une nouvelle page peut reprendre le même sujet, les mêmes mots et le même objectif commercial : elle reste une nouvelle adresse tant que l'ancienne ne lui transmet rien.
C'est la raison pour laquelle je traite la refonte d'un site internet comme un chantier de design et comme un chantier de continuité. Les 2 doivent être prêts avant la bascule.
- 1 inventaire Les URL connues avant la refonte
- 1 destination Une nouvelle page pertinente par ancienne URL
- 0 oubli L'objectif avant la mise en ligne
Le design change en 1 nuit. L'historique SEO, lui, doit traverser la nuit.
Olivier Beining
Commencez par inventorier ce que Google et vos visiteurs connaissent déjà
Google recommande de constituer la liste des anciennes URL avant une migration complexe. Le sitemap ne suffit pas toujours : il faut croiser plusieurs sources.
Search Console et analytics
Ils révèlent les URL qui reçoivent des impressions, des clics ou des visites, y compris celles qui ne figurent plus dans la navigation.
Liens et journaux serveur
Ils retrouvent les anciennes adresses encore appelées par des backlinks, des campagnes, des robots ou des favoris.
Testez votre matrice ancienne URL vers nouvelle URL
Le document central tient en 2 colonnes : l'ancienne URL et sa destination définitive. Chaque ancienne page doit rejoindre la nouvelle page qui répond le mieux à la même intention. Quand aucun équivalent n'existe, une vraie réponse 404 peut être plus honnête qu'une redirection artificielle vers l'accueil.
Le vérificateur ci-dessous contrôle la cohérence du fichier avant intégration. Il signale les champs manquants, les URL invalides, les anciennes URL dupliquées, les boucles, les chaînes et les destinations envoyées vers l'accueil. Tout reste dans votre navigateur.
Résultat du contrôle
- Lignes
- 0
- Valides
- 0
- Alertes
- 0
- Erreurs
- 0
| Ligne | Ancienne URL | Destination | Diagnostic |
|---|
301, canonical et liens internes doivent raconter la même histoire
Pour un déplacement définitif, Google recommande une redirection permanente côté serveur, généralement 301 ou 308. Cette redirection indique que la nouvelle URL doit devenir la version canonique. Une 302 décrit au contraire un déplacement temporaire.
La nouvelle page doit aussi déclarer sa propre URL canonique, les liens internes doivent pointer directement vers elle et le nouveau sitemap doit la contenir. Une redirection dit une chose, un canonical ou un menu qui revient vers l'ancienne URL en dit une autre. Google finit par arbitrer, mais vous lui faites perdre du temps.
Les chaînes ajoutent encore un détour : ancienne page vers page intermédiaire, puis vers destination finale. Googlebot peut les suivre, mais Google conseille de rediriger directement et de garder les chaînes aussi courtes que possible. La documentation officielle détaille les types de redirections.
-
Déplacement permanent
L'ancienne URL envoie directement vers sa nouvelle destination définitive.
-
Canonical cohérent
La nouvelle page se déclare elle-même comme URL canonique, sans contredire la redirection.
-
Liens mis à jour
Menus, contenus, sitemap et campagnes pointent vers la destination finale, sans détour.
Le site de test doit rester invisible, puis devenir indexable au bon moment
Une préproduction publique doit être protégée de l'indexation. La balise noindex, une authentification ou une restriction réseau évitent que Google découvre une copie du futur site avant sa sortie.
Le piège arrive le jour J : le nouveau site prend la place de l'ancien, mais le noindex reste dans le HTML ou un blocage subsiste dans robots.txt. Le lancement semble réussi pour les humains tandis que Google reçoit l'ordre de ne rien conserver.
La vérification finale doit donc porter sur le HTML réellement servi en production, pas seulement sur un réglage du CMS. Contrôlez aussi les canonicals, le fichier de validation Search Console, le sitemap et les réponses HTTP.
Pendant la fabrication Préproduction protégée et non indexable
Avant la bascule 301, canonicals, sitemap et robots testés
Après la bascule Noindex retiré et URL inspectées dans Search Console
Une bascule se déroule dans un ordre vérifiable
Le lancement n'est pas un bouton magique. C'est une séquence courte dont chaque étape laisse une preuve.
- Étape 1
Geler les changements
Dernier export des URL, contenus et formulaires. Le plan de redirections est figé pour éviter qu'une page change pendant la bascule.
- Étape 2
Publier le nouveau site
Le domaine sert la nouvelle version avec les balises d'indexation, les canonicals et les fichiers de validation attendus.
- Étape 3
Activer les redirections
Chaque ancienne URL rejoint directement sa destination finale avec un statut permanent.
- Étape 4
Tester les parcours réels
Navigation, formulaires, pages stratégiques, anciennes URL, médias et réponses 404 sont vérifiés depuis l'extérieur.
- Étape 5
Soumettre et surveiller
Le nouveau sitemap part dans Search Console. Les erreurs, l'indexation et le trafic sont ensuite suivis pendant plusieurs semaines.
Le lancement n'est terminé que lorsque les anciennes URL ont bien transmis
Google indique qu'un petit ou moyen site peut demander plusieurs semaines pour que la majorité de ses pages soit transférée. Des fluctuations temporaires sont normales. Une chute durable, un pic de 404 ou des pages exclues ne doivent en revanche pas être rangés dans la catégorie des choses qui finiront bien par passer.
Je surveille 3 surfaces : Search Console pour l'exploration et l'indexation, les journaux serveur pour voir les anciennes URL encore appelées, et les données de trafic pour repérer une page stratégique qui décroche. Les redirections restent en place durablement ; on ne les retire pas dès que la nouvelle page apparaît dans Google.
Cette surveillance fait partie du coût réel d'un projet. Le sujet dépasse le prix affiché sur un devis : voici comment je calcule le vrai coût d'un site sur la durée.
- 3 sources Search Console, logs serveur et analytics
- 404 HTTP Le signal à suivre après la bascule
- 1 sitemap Mis à jour avec les nouvelles URL
Prévoir le retour arrière n'est pas douter du nouveau site
Un plan de retour arrière précise ce qui déclenche l'arrêt : formulaires indisponibles, redirections massivement incorrectes, pages stratégiques non indexables ou erreur serveur persistante. Il indique aussi qui décide et comment remettre l'ancienne version en service sans perdre les données reçues entre-temps.
Cette préparation permet d'agir vite sans improviser sous pression. Elle n'empêche pas le lancement ; elle évite de laisser une erreur visible pendant plusieurs heures parce que personne ne sait revenir en arrière.
Une refonte peut améliorer le design, la vitesse et l'édition du contenu. Elle n'a aucune raison d'effacer l'actif déjà construit. C'est aussi le principe appliqué quand je reprends un site WordPress devenu lent ou lorsque je reconstruis les projets présentés dans les réalisations Menschhh.
Une refonte réussie ne repart pas de zéro. Elle sait exactement ce qu'elle reprend.
Olivier Beining
Refonte de site et SEO : les réponses avant de basculer
Une refonte de site fait-elle forcément perdre des positions Google ?
Non. Des fluctuations temporaires peuvent apparaître pendant que Google explore la nouvelle version, mais une perte durable n'est pas une conséquence obligatoire. Le risque augmente surtout lorsque les URL changent sans plan de redirections, que les canonicals se contredisent ou que le nouveau site bloque l'indexation.
Faut-il conserver exactement les mêmes URL pendant une refonte ?
Quand une URL est claire, pertinente et déjà connue de Google, la conserver réduit le nombre de signaux à retraiter. Une URL peut néanmoins changer si la nouvelle structure le justifie. Dans ce cas, l'ancienne adresse doit rediriger directement vers la nouvelle page équivalente.
Doit-on rediriger toutes les anciennes pages vers l'accueil ?
Non. Une redirection doit conduire vers la page qui répond le mieux à la même intention. Envoyer des dizaines d'anciennes pages sans rapport vers l'accueil peut être interprété comme une mauvaise correspondance et produire des soft 404. Quand aucun équivalent n'existe, une vraie réponse 404 ou 410 peut être plus cohérente.
Quelle différence entre une redirection 301 et 302 ?
Une 301 indique un déplacement permanent et aide Google à traiter la destination comme nouvelle URL canonique. Une 302 décrit un changement temporaire : Google peut continuer à conserver l'ancienne URL comme référence. Pour une refonte définitive, la redirection permanente côté serveur est généralement le bon choix.
Combien de temps faut-il surveiller le SEO après la mise en ligne ?
Le contrôle doit être quotidien pendant les 7 premiers jours, puis régulier pendant plusieurs semaines. Google précise qu'un petit ou moyen site peut demander plusieurs semaines pour que la majorité des pages soit transférée. Les grands sites prennent davantage de temps.
Le vérificateur de redirections teste-t-il réellement les URL ?
Non. Il contrôle localement la cohérence du fichier : champs manquants, formats, doublons, boucles, chaînes possibles et destinations vers l'accueil. Le test des statuts HTTP doit ensuite être réalisé sur le site de préproduction ou après la bascule avec un crawler ou un script serveur.
Et pour votre site web ?
30 minutes en visio pour regarder votre site ensemble, identifier ce qui freine, chiffrer ce qui vaut la peine d’être fait. Sans engagement, sans relance commerciale. Si on s’entend, on continue.
Et pour votre site web ?
30 minutes en visio pour regarder votre site ensemble, identifier ce qui freine, chiffrer ce qui vaut la peine d’être fait. Sans engagement, sans relance commerciale. Si on s’entend, on continue.