Erreurs SEO à éviter lors d'une refonte

Les dix erreurs et l'endroit où elles se voient

Les dix erreurs expliquées

Les anciennes URL renvoient un 404

C'est l'erreur la plus fréquente et la plus coûteuse. Chaque ancienne adresse que Google connaît, et vers laquelle des sites tiers pointent, doit répondre par une redirection permanente vers son équivalent sur le nouveau site. Sans elle, la page sort de l'index en quelques jours à quelques semaines et sa remplaçante repart sans historique. La détection se fait en une fois. Exportez la liste complète des anciennes URL avant la bascule, depuis un crawl et depuis la Search Console, puis recrawlez cette liste en mode liste le jour J. Toute ligne en 404 est une correspondance à ajouter au fichier de redirections.

Les redirections mènent toutes à l'accueil

Rediriger d'un bloc les anciennes pages vers la page d'accueil ou vers une catégorie est rapide à mettre en place et ne transmet rien. La documentation de Google sur les déplacements de site demande explicitement de ne pas rediriger de nombreuses anciennes URL vers une seule destination sans rapport, parce que ces redirections peuvent être traitées comme des erreurs 404 déguisées. Le même crawl en mode liste montre la destination de chaque redirection dans une colonne. Si cinquante lignes atterrissent sur la même adresse, la correspondance est à refaire page par page.

Les redirections s'enchaînent

Un site qui a connu deux ou trois refontes accumule des redirections en cascade. L'adresse de 2018 renvoie vers celle de 2022, qui renvoie vers celle d'aujourd'hui. Chaque saut ralentit l'exploration et fragilise la transmission, et une chaîne finit souvent par un maillon cassé. Screaming Frog produit un rapport dédié aux chaînes de redirections. La correction consiste à faire pointer chaque ancienne adresse, même la plus vieille, directement vers la destination finale.

La préproduction a été indexée

Un site de test accessible sans mot de passe finit par être découvert, souvent par un lien laissé dans un ticket, un mail ou un outil. Google se retrouve alors avec deux versions du même contenu et doit choisir. Une recherche site: sur le sous-domaine de préproduction suffit à le vérifier. La protection fiable est un mot de passe HTTP, parce qu'une balise noindex a deux défauts, elle laisse l'environnement visible à tout le monde et elle risque d'être copiée en production. Le sujet est détaillé sur la page préproduction et référencement.

Le noindex a suivi le site en production

C'est le miroir de l'erreur précédente et il désindexe un site entier en quelques jours. Le contrôle prend une minute et se fait dans l'heure qui suit la bascule. Ouvrez le code source de la page d'accueil et de deux pages profondes et cherchez la chaîne noindex, puis lisez le fichier robots.txt en entier. L'outil Inspection d'URL de la Search Console confirme ensuite que la page est explorable et indexable. Sur WordPress, la case « Demander aux moteurs de recherche de ne pas indexer ce site » des réglages de lecture est l'endroit où cette erreur se cache le plus souvent.

Des pages qui faisaient du trafic ont disparu

Pendant une refonte, des pages sont jugées inutiles parce qu'elles sont anciennes, mal présentées ou hors de la nouvelle charte. Certaines d'entre elles font pourtant du trafic depuis des années. Avant toute suppression, la liste des pages avec des clics sur les 16 derniers mois dans la Search Console est la référence. Une page présente dans cette liste se garde, ou se redirige vers le contenu qui répond à la même question. Une page absente de la liste et sans lien externe peut disparaître, avec un vrai 404 ou un 410, ce qui est plus propre qu'une redirection artificielle.

Le contenu a été raccourci

Un texte de 1 500 mots ramené à 300 pour « alléger la page » perd les passages qui le positionnaient sur des dizaines de requêtes secondaires. La perte se voit dans le rapport Requêtes plutôt que dans le rapport Pages, ce qui la rend difficile à relier à sa cause. Le contrôle est mécanique. Un crawl avant et un crawl après donnent le nombre de mots de chaque page, et un tri sur l'écart fait remonter en quelques secondes les pages amputées. Sur les pages qui se positionnent, le texte se garde tel quel, le design change autour.

Les balises ont été remplacées par celles du gabarit

Un nouveau thème génère souvent ses propres balises title à partir du nom de la page et du nom du site, et laisse la meta description vide. Les titres travaillés pendant des années disparaissent d'un coup, et le taux de clic dans les résultats baisse sans que la position ait bougé. L'onglet des titres du crawl, filtré sur les doublons et sur les balises manquantes, montre le problème en une vue. La correction consiste à réimporter les balises depuis l'export de l'ancien site, champ par champ, au moins sur les pages à trafic.

Le balisage, les images et les fichiers ont été oubliés

Trois éléments sont régulièrement laissés de côté parce qu'ils ne se voient pas à l'écran. Les données structurées du thème précédent ne sont pas reprises, et les résultats enrichis disparaissent, ce que le rapport Améliorations de la Search Console signale. Les adresses des images changent, et les positions dans Google Images partent avec, ce que le filtre « Image » du rapport Performances mesure. Les PDF et autres fichiers téléchargeables reçoivent parfois des liens externes et méritent leurs redirections comme n'importe quelle page.

Personne ne regarde après la mise en ligne

La refonte est livrée, l'équipe passe à autre chose, et les erreurs précédentes s'installent pendant des semaines. Le suivi minimal tient en trois gestes. Soumettre le nouveau sitemap dans la Search Console le jour même, lire le rapport Indexation des pages chaque jour pendant quatre semaines pour voir les 404, les soft 404 et les pages exclues par noindex, et comparer les clics de chaque semaine à la même semaine de l'année précédente plutôt qu'à la semaine d'avant. La page perte de trafic après refonte donne l'ordre dans lequel vérifier si la courbe décroche.

Pourquoi ces erreurs reviennent

Une refonte est pilotée par des équipes design et développement, dont le travail consiste précisément à changer ce qui existe. Les URL changent parce que la nouvelle structure est plus propre, le contenu est réécrit parce qu'il ne correspond plus à l'image de marque, les pages anciennes sont retirées parce qu'elles font désordre. Aucune de ces décisions n'est absurde, et chacune retire une partie de ce que Google a appris du site en plusieurs années. Le référencement n'est pas oublié par malveillance, il est absent de la liste des livrables. La solution tient donc moins à une compétence qu'à un document, la liste des adresses et des contenus qui doivent survivre, remise avant le premier jour de développement.

Deux contrôles qui attrapent l'essentiel

Sur les dix erreurs, six se détectent avec deux manipulations qui prennent moins d'une heure et ne demandent que la version gratuite de Screaming Frog, limitée à 500 URL, ce qui suffit pour les pages qui comptent.

1. Le crawl de la liste des anciennes URL

   Avant la bascule, exportez toutes les adresses de l'ancien site depuis un crawl complet, et ajoutez celles du rapport Performances de la Search Console sur 16 mois ainsi que celles du rapport Liens. Le jour J, chargez cette liste dans Screaming Frog en mode liste et lancez le crawl. Vous obtenez pour chaque ancienne adresse son code de réponse, sa destination finale et le nombre de sauts. Les 404, les redirections vers l'accueil et les chaînes apparaissent dans la même vue.

2. La comparaison des balises et des longueurs de texte

   Un crawl de l'ancien site et un crawl du nouveau, rapprochés page à page dans un tableur sur l'adresse finale, donnent l'écart de nombre de mots, la balise title avant et après, et la présence de la meta description. Un tri sur l'écart de mots fait remonter les pages amputées, un filtre sur les titles identiques fait remonter le gabarit qui a écrasé les balises travaillées. Ce contrôle se fait sur la préproduction, avant la mise en ligne, et se refait sur la production après.

Ces deux contrôles ne remplacent pas un plan de refonte, qui est détaillé sur la page refonte de site web, ni le calendrier de la checklist refonte SEO. Ils sont ce que je vérifie en premier quand un site arrive après une refonte qui a mal tourné, et ce que je ferais faire à n'importe quelle équipe avant de basculer.

Questions fréquentes