Pourquoi un tableau de bord censé suivre 80 sites indépendants affiche-t-il soudain la même dégradation, le même jour, sur des comptes Search Console qui n’ont rien en commun sinon un thème parent ? C’est la question posée par une agence gérant un parc de sites vitrines pour des indépendants et petites entreprises, tous construits sur la même base de thème enfant dérivée d’un thème parent maison, mis à jour en bloc chaque trimestre.
Le signal d’alerte n’est pas venu de Search Console directement, mais d’un score de crawl agrégé, calculé maison à partir des logs serveur mutualisés : nombre de requêtes de Googlebot ayant reçu une réponse 200 sur du contenu réellement indexable, divisé par le nombre total de requêtes de Googlebot sur la période. Ce ratio, suivi jour par jour sur l’ensemble du parc, était resté stable autour de 78 % pendant des mois, avant de chuter à 61 % en l’espace de quatre jours, sur la quasi-totalité des 80 sites en même temps.
Écarter les fausses pistes une par une
La première réaction a été de suspecter un problème par site : plugin mal configuré, faux positif d’un outil de cache, ou une campagne de scraping ciblée déguisée en trafic Googlebot. Ces pistes ont été écartées rapidement pour deux raisons. D’abord, la simultanéité : une cause par site indépendante n’explique pas un décrochage synchronisé sur 80 domaines différents, hébergés sur des infrastructures différentes, gérés par des clients différents qui n’ont rien changé de leur côté. Ensuite, la vérification via grep sur un échantillon de logs bruts a confirmé que le trafic identifié comme Googlebot correspondait bien à des IP appartenant aux plages officielles publiées par Google, validées par résolution DNS inverse.
Le seul événement commun aux 80 sites sur la fenêtre concernée était le déploiement automatique d’une mise à jour mineure du thème parent, poussée via un système de mise à jour privé basé sur un dépôt Git et un webhook de déploiement continu. C’est cette piste qu’il fallait creuser, en traitant le thème comme une variable unique plutôt que 80 sites comme 80 cas isolés.
Isoler la régression par diff plutôt que par site
La méthode qui a fonctionné n’a pas consisté à auditer chaque site un par un — un travail de plusieurs semaines à 80 exemplaires — mais à comparer directement le code du thème avant et après la mise à jour, à la recherche de tout changement pouvant affecter la crawlabilité :
git log --oneline v3.4.0..v3.4.1 -- functions.php inc/seo/
git diff v3.4.0..v3.4.1 -- functions.phpLe diff a révélé le coupable en quelques minutes : une fonction ajoutée pour « optimiser » le chargement des pages d’archive avait introduit un wp_redirect() conditionnel mal borné, qui redirigeait vers la page d’accueil toute URL d’archive de catégorie ne contenant aucun article publié dans les trente derniers jours — une logique pensée pour éviter d’afficher des pages vides aux visiteurs humains, mais appliquée sans distinction aux robots, et sans code de statut adapté (une redirection 302 générique au lieu d’un 410 ou d’un simple contenu vide avec noindex).
function theme_redirect_empty_archives() {
if ( is_category() && ! have_posts() ) {
wp_redirect( home_url( '/' ) );
exit;
}
}
add_action( 'template_redirect', 'theme_redirect_empty_archives' );Sur des sites vitrines à faible volume de publication, un grand nombre de catégories restent naturellement sans article récent pendant plusieurs semaines : c’est un usage légitime, pas une anomalie. La fonction a donc généré des redirections en masse vers la page d’accueil, exactement le type de signal qui dégrade la confiance d’un moteur dans la structure du site et fait chuter le taux de crawl utile, puisque chaque page d’archive visitée par Googlebot renvoyait la même URL cible.
Confirmer la cause avant de généraliser le correctif
Avant de déployer un correctif sur les 80 sites, la cause a été confirmée sur un échantillon de trois sites représentatifs, avec un test isolé : désactivation temporaire du hook template_redirect concerné via un mu-plugin, suivie d’une observation du taux de crawl sur cinq jours. Le retour à la normale a été net et rapide, ce qui a validé l’hypothèse sans attendre un correctif complet sur l’ensemble du parc.
Grille de diagnostic retenue pour la suite
- Un décrochage simultané sur plusieurs sites indépendants pointe presque toujours vers un composant partagé : thème, plugin mutualisé, CDN, ou configuration serveur commune.
- Comparer le code par diff de version est plus rapide que d’auditer chaque site individuellement quand la cause est probablement centralisée.
- Toute redirection conditionnelle ajoutée à un thème doit être testée spécifiquement sur le comportement des robots, pas uniquement sur l’expérience visiteur humain.
- Un score de crawl agrégé, suivi quotidiennement, détecte une régression bien avant qu’elle ne se traduise en perte de position visible dans les rapports classiques.
Sur un parc mutualisé, la première question à se poser face à une anomalie synchronisée n’est jamais « que s’est-il passé sur ce site », mais « qu’est-ce que tous ces sites ont en commun ».
| Piste | Simultanéité expliquée | Retenue |
|---|---|---|
| Plugin mal configuré par client | Non | Non |
| Faux trafic Googlebot | Non | Non |
| Mise à jour du thème parent | Oui | Oui |
En résumé
Une régression SEO technique qui touche un parc entier de sites au même moment n’est presque jamais une coïncidence multiple : c’est le symptôme d’un composant partagé qui a changé. La méthode la plus efficace consiste à traiter la cause comme une variable unique — ici un thème versionné — et à comparer les diffs de code plutôt que de multiplier les audits individuels. Un score de crawl agrégé, calculé sur les logs bruts plutôt que sur des rapports lissés, reste l’un des meilleurs signaux d’alerte précoce disponibles pour ce genre d’incident.
