Comment récupérer des positions après une refonte WordPress ?

Votre site a été refondu, les URL n’ont pas bougé, et pourtant les positions sont parties. Les guides vous renverront tous vers les redirections 301 : sur une refonte à URL constantes, ce n’est presque jamais le vrai sujet. La cause la plus fréquente, et la moins documentée, c’est la fonte du contenu décidée pour le design. Elle se mesure page par page, en comparant les captures d’archive.org d’avant et d’après, et c’est ce contenu qu’on restaure en priorité.

Refonte ou migration : ce n’est pas le même incident

Le mot « refonte » recouvre deux situations que Google ne traite pas de la même façon. Distinguer laquelle vous concerne détermine tout le reste du diagnostic.

La refonte garde les URL, la migration les change

Une migration modifie les adresses : nouveau domaine, passage en HTTPS, changement de structure de permaliens, slugs réécrits, catégories fusionnées. Le risque principal est alors la chaîne de redirections : chaque ancienne URL qui recevait du trafic doit renvoyer en 301 vers son équivalent. Si c’est votre cas, la priorité absolue est ailleurs, et notre article sur la perte de positions après une migration WordPress traite ce scénario en détail.

Une refonte au sens strict garde les mêmes URL. On change le thème, les gabarits, la charte, parfois le constructeur de page, souvent le volume de texte. Les adresses répondent toujours en 200, aucune redirection n’est nécessaire, et c’est justement ce qui trompe : puisque « rien n’est cassé » côté technique, on cherche la panne au mauvais endroit.

Pourquoi la distinction change tout le diagnostic

Sur une migration, Google perd temporairement le fil entre ancienne et nouvelle adresse : le symptôme est une chute large, rapide, corrélée à des erreurs d’exploration dans la Search Console. Sur une refonte à URL constantes, l’URL est toujours là, toujours indexable, mais son contenu a changé de nature. Google réévalue la page sur ce qu’elle contient désormais, pas sur ce qu’elle contenait avant. La chute est souvent plus progressive, page par page, et elle ne laisse aucune trace dans les rapports d’erreurs. C’est un incident de pertinence, pas un incident de plomberie.

Ce qui fait chuter un site après une refonte à URL constantes

Cinq mécanismes reviennent, du plus fréquent au plus discret. Ils se cumulent presque toujours.

La fonte du contenu, la cause la plus fréquente et la moins citée

Une refonte est pilotée par le design. Les maquettes sont respirées, aérées, avec de grands visuels et peu de texte. Au moment de couler l’ancien contenu dans les nouveaux gabarits, on coupe : un paragraphe d’introduction jugé trop long, une section « en savoir plus » qui alourdit la page, un bloc de questions réponses qui ne rentre pas dans la grille. Page après page, le volume de contenu utile baisse de 30 à 60 %. Or c’est ce texte qui portait les signaux sémantiques sur lesquels Google classait la page. Moins de contenu pertinent, c’est mécaniquement moins de raisons de bien classer la page.

Ce phénomène est presque toujours absent des diagnostics parce qu’il ne déclenche aucune alerte : la page répond en 200, elle est indexable, elle est jolie. Seule une comparaison avant après le révèle.

Les gabarits SEO réinitialisés : titles et meta en série

Le nouveau thème, ou la remise à plat de l’extension SEO, réécrit les modèles de balise title et de meta description. Les valeurs par défaut reviennent : {titre de la page} {séparateur} {nom du site}. Les titles retravaillés à la main sur des dizaines ou des centaines de pages sont écrasés d’un coup. Page par page, c’est invisible. Sur un export global des balises title, l’uniformité saute aux yeux.

Le maillage interne redessiné par le nouveau thème

Un thème, c’est un en-tête, un pied de page, une barre latérale et des blocs récurrents. En changer redéploie du jour au lendemain toute la distribution des liens internes du site. Des pages qui étaient à un clic de l’accueil passent à trois. Un menu simplifié pour l’esthétique retire les accès directs vers les pages de second niveau. Le bloc « articles liés » de l’ancien thème a disparu. Google redécouvre une hiérarchie d’importance différente, et certaines pages perdent le soutien interne qui les maintenait.

Hn aplaties, contenu masqué, données structurées perdues

Trois dégâts plus techniques, dans le même sac. Le nouveau gabarit transforme les anciens H2 en simples paragraphes en gras, ou multiplie les H1 : la structure logique de la page se brouille. Des blocs de texte passent en onglets ou en accordéons repliés : le contenu reste dans le code, mais son poids perçu baisse. Enfin, si l’ancien thème premium injectait son propre balisage schema.org, il part avec lui, sans que l’extension SEO ne signale quoi que ce soit. Ce point précis est détaillé dans notre article sur la perte de trafic après un changement de thème WordPress.

Figer l’état et dater la bascule

Avant de corriger quoi que ce soit, deux gestes. D’abord, figer l’état actuel : exportez la liste des URL indexées, un crawl complet du site en ligne, et un relevé des positions du moment. Vous en aurez besoin comme point de comparaison dans quatre semaines.

Ensuite, datez la mise en ligne de la refonte à la journée près. La date de bascule est le pivot du diagnostic : si la chute de la Search Console commence exactement là, la refonte est en cause ; si elle commence trois jours plus tôt ou deux semaines plus tard, cherchez autre chose. Sur WordPress, si aucun journal d’activité n’était installé, les horodatages des fichiers du thème actif dans wp-content/themes donnent la date de déploiement à la minute. La méthode complète est décrite dans notre guide pour diagnostiquer une chute brutale de trafic organique.

Mesurer la fonte de contenu avec archive.org

C’est l’étape que personne ne décrit, et c’est elle qui révèle la première cause de perte sur une refonte à URL constantes. Le principe : comparer, pour chaque page qui a décroché, ce qu’elle contenait avant la refonte et ce qu’elle contient aujourd’hui.

La méthode, capture avant contre version en ligne

Faites-le sur un échantillon d’abord, cinq pages. Si l’écart est systématique, vous tenez la cause principale et vous pouvez étendre à toute la liste.

Le seuil d’alerte et ce qu’on restaure d’abord

Une page qui passe de 1 200 mots à 500 mots a perdu l’essentiel de ce qui la faisait ranker. En dessous de 20 % de contenu retiré, l’effet est généralement mineur ; au-delà de 40 %, il est probablement la cause dominante. Priorisez la restauration par le trafic perdu : la page qui rapportait le plus avant la refonte et qui a le plus fondu passe en premier. Vous ne réécrivez pas, vous remettez le texte qui existait, adapté à la nouvelle grille : rien n’interdit de le présenter autrement, tout interdit de le supprimer.

Lire la Search Console dans le bon ordre

La Search Console confirme ou infirme chaque hypothèse. Encore faut-il ouvrir les rapports dans un ordre utile.

Le rapport Performances, par page et par requête

Étendez la période à seize mois pour voir les cycles. Comparez ensuite les trois mois qui suivent la refonte aux trois mois qui précèdent. Deux lectures : si impressions et clics baissent ensemble, le problème est de fond, contenu ou technique ; si les impressions tiennent et que seuls les clics baissent, regardez d’abord les titles et les meta descriptions. Descendez ensuite au niveau des requêtes pour les pages les plus touchées : une page qui perd sur ses requêtes principales a un problème de pertinence ; une page qui ne perd que sur la longue traîne a un problème de structure ou de contenu retiré.

Indexation des pages et résultats enrichis

Le rapport Indexation des pages doit rester stable sur une refonte à URL constantes. S’il montre une hausse soudaine de pages « exclues par une balise noindex » ou « bloquées par robots.txt », le nouveau thème ou une extension a poussé une directive de trop : c’est à corriger avant tout le reste. Le rapport Résultats enrichis, lui, révèle la perte de données structurées : une chute nette du nombre d’éléments valides à la date de bascule signe un balisage parti avec l’ancien thème.

Le plan de récupération, dans l’ordre

La séquence compte : on rend d’abord aux pages ce qu’elles ont perdu, on nettoie ensuite, on redemande l’exploration en dernier.

1. Lever les blocages d’indexationBalise noindex parasite, règle robots.txt ajoutée par le thème, case « décourager les moteurs » : si le rapport Indexation en montre, on corrige immédiatement.
2. Restaurer le contenu fonduSur les pages priorisées par le trafic perdu, on remet les sections coupées, adaptées à la nouvelle maquette. C’est le geste à plus fort effet.
3. Re-remplir les gabarits SEOOn restaure les modèles de title et de meta, puis on repasse sur les pages qui avaient une balise retravaillée à la main.
4. Reconstruire le maillage prioritaireOn rétablit les liens internes vers les pages de second niveau qui ont décroché : menu, blocs de contenu, liens contextuels dans les articles.
5. Corriger le techniqueHiérarchie Hn, contenu sorti des accordéons repliés si possible, réinjection du schema.org, contrôle de la vitesse si le constructeur de page a alourdi les gabarits.
6. Redemander l’explorationSitemap re-soumis, inspection d’URL et demande d’indexation sur les vingt à trente pages les plus stratégiques, pas plus.

Si l’ampleur dépasse une poignée de pages, ou si la refonte a été livrée sans plan SEO, faire reprendre le chantier par un consultant refonte et migration WordPress évite de corriger à l’aveugle pendant des semaines.

Combien de temps avant que les positions reviennent

Le compteur ne démarre pas à la correction, il démarre au moment où Googlebot re-explore la page corrigée. Comptez ensuite deux à quatre semaines pour que Google réévalue une page dont le contenu a été restauré, et quatre à huit semaines pour le retour des positions si la correction est complète et rapide. Une refonte corrigée trois mois après coup met plus longtemps à se rétablir qu’une refonte corrigée en dix jours : plus la page passe de temps dans son état dégradé, plus Google a de signaux sur cette version. C’est la raison pour laquelle dater la bascule et agir vite change le résultat.

Suivez la reprise par cohortes : regroupez les pages restaurées la même semaine et comparez leur position moyenne, leurs impressions et leurs clics au fil des semaines suivantes. Une cohorte qui remonte pendant qu’une autre stagne vous dit quelle correction a porté.

Quand ce n’est pas la refonte

Trois cas où la refonte est un faux coupable. Une mise à jour d’algorithme tombée la même semaine : vérifiez les dates des Core Updates, une coïncidence de calendrier arrive. Une saisonnalité : comparez à l’année précédente sur la même période avant de conclure. Une cannibalisation introduite par la refonte : si elle a créé de nouvelles pages proches de pages existantes, deux URL se disputent désormais la même requête et aucune ne rank correctement. Pour démêler ces scénarios, la forme de la courbe de trafic et la revue des causes classiques d’une perte de positions donnent le premier tri.

Restaurer d’abord, réécrire ensuite

Une refonte à URL constantes ne casse pas la technique, elle change ce que vos pages disent à Google. La récupération passe par un ordre simple : lever les blocages, rendre aux pages le contenu qu’on leur a retiré, restaurer les balises et le maillage, puis seulement corriger le reste et redemander l’exploration. La tentation, quand rien ne remonte au bout de quinze jours, est de refondre encore. C’est l’inverse qu’il faut faire : mesurer, restaurer, attendre le recrawl, comparer par cohortes. Les positions reviennent quand la page redevient au moins aussi complète qu’avant.