Contrôler le balisage SEO d’un thème avant de le livrer à forte audience

Un thème qui s’affiche parfaitement peut malgré tout casser silencieusement le référencement d’un site à forte audience : titre dupliqué sur toutes les pages, balise canonical pointant vers la mauvaise URL, ou balise noindex oubliée depuis l’environnement de recette. Ces régressions ne provoquent aucune erreur visuelle, ce qui les rend particulièrement dangereuses sur un site où chaque jour d’indexation dégradée compte.

Voici une checklist de revue technique à passer systématiquement avant toute mise en production d’un nouveau thème ou d’une évolution majeure, pour attraper ces régressions avant qu’elles n’affectent un trafic organique établi. Cette liste ne couvre pas les tests d’intégration continue eux-mêmes, qui relèvent d’un processus distinct.

Vérifications sur le head de chaque type de page

1. Le titre de la page (<title>) change bien d’une page à l’autre, sans valeur statique héritée d’un test
2. La balise canonical pointe vers l’URL réelle de la page, jamais vers la page d’accueil ou une URL de préproduction
3. Aucune balise <meta name="robots" content="noindex"> ne subsiste depuis l’environnement de recette
4. Le fichier robots.txt ne contient plus de règle de blocage global héritée du site de recette

Vérifications sur les données structurées

1. Le JSON-LD généré est syntaxiquement valide sur chaque type de page concerné (article, produit, page)
2. Les champs obligatoires du type de balisage utilisé sont bien renseignés, sans valeur vide ni placeholder
3. Aucun balisage en double ne se superpose entre le thème et une éventuelle extension SEO active

Vérifications sur le sitemap et les URL

1. Le sitemap XML est accessible et référence bien les URL de production, pas celles de l’environnement de recette
2. Les URL générées par le thème ne contiennent aucun paramètre de session ou de débogage laissé par erreur

Pourquoi ces contrôles échappent souvent à la recette fonctionnelle

Une équipe de recette valide généralement l’affichage, la navigation et les fonctionnalités visibles du thème. Le balisage technique, invisible à l’écran, n’entre que rarement dans son périmètre de test, sauf mention explicite. C’est pourquoi une régression de canonical peut franchir toutes les étapes de validation fonctionnelle sans être détectée, et n’apparaître qu’une fois le trafic organique commence à baisser.

# Exemple de commande pour extraire rapidement le head de plusieurs URL
for url in $(cat urls-a-verifier.txt); do
  curl -s "$url" | grep -A1 "<title>\|canonical\|robots"
done

Un exemple de régression fréquente entre recette et production

Un cas typique : l’environnement de recette impose un blocage global via une ligne Disallow: / ajoutée automatiquement par l’hébergeur ou le système de déploiement, pour éviter que ce site de test ne soit indexé par erreur. Lors de la mise en production, cette ligne est parfois recopiée par mégarde dans le fichier définitif, ou reste active si le mécanisme de bascule automatique entre environnements est mal configuré. Le site de production se retrouve alors entièrement fermé à l’exploration, sans qu’aucun test fonctionnel ne le révèle puisque l’affichage reste parfaitement normal pour un visiteur humain.

Ce qu’il faut inspecter en priorité sur un site à fort trafic

• Les pages qui génèrent le plus de trafic organique actuellement, en priorité absolue
• Les gabarits de page partagés par de nombreuses URL, où une régression a un effet multiplié
• Les pages où une extension SEO tierce interagit avec le thème, source fréquente de conflits de balisage

Le repère qu’on applique en revue avant mise en production : ce que l’œil ne voit pas doit être vérifié avec autant de rigueur que ce qu’il voit, car c’est justement ce qui échappe aux tests classiques.

En résumé

Une régression de balisage SEO ne se voit pas à l’écran, ce qui la rend particulièrement coûteuse sur un site à forte audience où chaque jour d’indexation dégradée se traduit directement en perte de trafic. Passer systématiquement cette checklist de revue technique avant chaque mise en production permet d’attraper ces régressions au moment où elles coûtent le moins cher à corriger, avant qu’elles n’atteignent l’index des moteurs de recherche.