Perte de trafic après le changement d’un thème WordPress

Changer de thème WordPress ne casse presque jamais le site de façon visible : les pages s’affichent, le design est propre, rien n’alerte dans l’administration. C’est justement ce qui rend la perte de trafic qui suit si difficile à comprendre. Un dégât en particulier passe systématiquement sous le radar, y compris de votre plugin SEO.

Le point que personne ne vérifie : le balisage caché dans l’ancien thème

La plupart des guides sur le changement de thème WordPress partent du principe que les données structurées (schema.org) sont gérées par votre plugin SEO, donc à l’abri d’un changement de thème. C’est vrai la plupart du temps, mais pas toujours : certains thèmes premium et certains constructeurs de page (Elementor Pro via son Theme Builder, Divi, Avada) injectent eux-mêmes une partie du balisage structuré directement dans leurs templates, en plus ou à la place de ce que fait votre plugin SEO. Tant que ce thème reste actif, tout fonctionne : Yoast ou Rank Math tournent normalement, ne remontent aucune erreur, parce qu’ils n’ont jamais eu la responsabilité de ce balisage-là.

Le problème survient au changement de thème : le nouveau thème n’a aucune raison de reproduire un balisage que l’ancien injectait de façon propriétaire. Le plugin SEO, lui, continue de tourner sans erreur, puisque son propre balisage n’a pas bougé. Résultat : la disparition progressive des résultats enrichis (avis, prix, FAQ visibles dans les résultats Google) dans les semaines qui suivent, sans qu’aucun message d’erreur n’apparaisse nulle part dans l’administration. Le seul endroit où le signal remonte est le rapport « Résultats enrichis » de Google Search Console, dans la section correspondant au type de contenu concerné (produit, article, FAQ, avis) : c’est là qu’il faut regarder en premier après un changement de thème, avant de chercher du côté du contenu ou des liens.

Les dégâts collatéraux les plus fréquents

Images et vignettes qui se transforment en erreurs 404

Chaque thème définit ses propres tailles de vignettes (thumbnail, medium, large). Un changement de thème modifie ces dimensions, mais les fichiers correspondant aux anciennes tailles restent référencés dans le contenu déjà publié sous forme d’URL du type mon-image-300x200.jpg. Ces références pointent alors vers des fichiers qui n’ont jamais été régénérés aux nouvelles dimensions : la vignette casse, l’image originale reste accessible mais mal affichée. Un site d’actualité a ainsi perdu 20 % de son trafic après un changement de thème, uniquement à cause de vignettes cassées sur les pages de catégorie. La régénération des vignettes via un plugin dédié (Regenerate Thumbnails ou équivalent) doit faire partie du protocole standard, pas d’un correctif après coup.

Shortcodes qui s’affichent en texte brut

Certains thèmes fournissent leurs propres shortcodes ([recette], effet de lettrine, grilles de mise en page). Ils cessent de fonctionner dès que le thème qui les a créés est désactivé : le code s’affiche tel quel dans le contenu, en clair, ou le contenu disparaît purement et simplement. Un blog culinaire a ainsi vu ses formats de recettes entièrement cassés après un changement de thème, avec le shortcode de lettrine supprimant la première lettre de chaque paragraphe au lieu de la styliser. Un audit de tous les shortcodes utilisés dans le contenu existant, avant de désactiver l’ancien thème, permet d’éviter la découverte a posteriori.

Maillage interne dilué par la disparition des widgets

Un nouveau thème ne reprend pas automatiquement la disposition des widgets de l’ancien : une barre latérale « articles populaires » ou « à lire aussi » peut simplement disparaître avec le changement, sans que personne ne s’en aperçoive visuellement. Ces widgets pesaient pourtant dans le maillage interne vers les pages stratégiques. Leur perte dilue silencieusement le poids SEO de ces pages, sans qu’aucune erreur ne soit détectable ailleurs que dans un audit de maillage.

Pages fantômes issues du contenu de démonstration

Les thèmes premium « clé en main » s’installent souvent avec un import de contenu de démonstration : pages d’exemple, articles au texte de remplissage, portfolios fictifs. Une partie de ce contenu reste indexable si personne ne le supprime explicitement après l’installation. Un audit a ainsi révélé plus de 50 pages fantômes toujours indexées chez un client, plusieurs mois après un changement de thème : elles diluaient la pertinence thématique du site aux yeux de Google sans qu’aucun signal d’alerte n’apparaisse. Passez le rapport de couverture de Search Console au crible des URLs inconnues après tout changement de thème premium, supprimez ou passez en noindex ce qui n’a pas vocation à rester en ligne.

Le poids mort d’un thème surchargé

Un thème « tout-en-un » embarque parfois plusieurs dizaines de fichiers CSS et JavaScript, dont la majorité ne sert à aucune fonctionnalité réellement utilisée sur le site. Ce poids mort dégrade les Core Web Vitals, qui pèsent directement dans le classement. La bascule vers un thème plus léger améliore au contraire ce signal ; c’est l’un des rares dégâts de changement de thème qui joue en réalité dans le bon sens, à condition de vérifier les temps de chargement avant/après avec un outil comme PageSpeed Insights plutôt que de le supposer.

Le protocole de vérification post-changement

1. Contrôlez le rapport Résultats enrichis de Search ConsoleComparez le nombre de pages valides avant/après sur les 30 jours suivant le changement, par type de contenu.
2. Régénérez toutes les vignettes d’imageUtilisez un plugin de régénération après tout changement de thème, avant de considérer la migration terminée.
3. Passez le code source au crible des shortcodes orphelinsRecherchez les motifs entre crochets restés visibles en clair sur les pages existantes.
4. Vérifiez la hiérarchie des balises HnUn nouveau thème peut générer sa propre structure de titres en plus de celle du contenu, créant des H1 multiples ou des sauts de niveau.
5. Recensez les widgets et menus perdusComparez la configuration de zones de widgets avant/après pour identifier les blocs de maillage disparus.
6. Traquez les pages de contenu de démonstrationPassez le rapport de couverture Search Console au crible des URLs inconnues, surtout après l’installation d’un thème premium clé en main.

Restaurer ce qui a été perdu sans tout annuler

Résultats enrichis et données structurées

Si le rapport Search Console confirme une perte de résultats enrichis, la solution n’est pas de réinstaller l’ancien thème mais de faire reprendre ce balisage précis par votre plugin SEO ou un plugin de schema dédié, en configurant manuellement le ou les types concernés (Product, Article, FAQPage, Review). C’est un chantier ciblé de quelques heures, pas une remise en cause du nouveau thème.

Maillage interne et liens cassés

Reconstruisez le maillage perdu dans le contenu lui-même plutôt que dans un widget, pour ne plus dépendre du thème actif : des liens contextuels insérés directement dans le corps des articles stratégiques survivent à n’importe quel futur changement de thème, contrairement à une barre latérale.

Anticiper avant le prochain changement de thème

La méthode qui limite le plus les dégâts reste la même, quel que soit le thème visé : installer le nouveau thème sur un environnement de test, y recenser tous les shortcodes, URLs et types de balisage structuré utilisés par l’ancien thème, planifier les ajustements nécessaires, tester en profondeur (rendu mobile, structure HTML, performance) avant la bascule, et préparer une sauvegarde de restauration rapide en cas de problème bloquant. Le point de contrôle spécifique à ajouter à cette liste standard, souvent absent des checklists génériques : vérifier explicitement si l’ancien thème injecte lui-même du balisage structuré propriétaire, en inspectant son code source ou sa documentation, avant de considérer que le plugin SEO couvre tout.