Rank Math : quand un update de sitemap déclenche une réindexation de 8 400 pages
Mercredi 10h15. L'équipe contenu d'un éditeur média français pousse la mise à jour automatique de Rank Math SEO, version 1.0.233. Rien dans le changelog ne mentionne un changement structurel. Aucune alerte, aucun warning dans le dashboard WordPress. Le site tourne sur un WordPress 6.7 avec WP Rocket, 8 400 pages indexées, 1.2 million de clics organiques par mois. Quatre jours plus tard, Search Console affiche un pic de crawl jamais vu. Le lundi suivant, le trafic organique chute de 34 %.
Lundi 9h02 — Le mail de Search Console
Le responsable SEO ouvre sa boîte. Un mail Search Console, envoyé dimanche soir : « Augmentation significative du nombre de pages explorées ». Le graphique de crawl dans les paramètres d'exploration montre un bond de 1 200 requêtes/jour à 9 800 requêtes/jour sur les trois derniers jours.
Premier réflexe : vérifier si un déploiement a eu lieu. L'historique Git du thème ne montre rien depuis onze jours. Aucun push, aucun merge. Le cache WP Rocket n'a pas été purgé manuellement.
Deuxième réflexe : le fichier robots.txt. Toujours en place. Pas de Disallow suspect. Le Sitemap: pointe bien vers https://example.fr/sitemap_index.xml.
Troisième réflexe : ouvrir le rapport de couverture. Et là, le tableau se fige. 6 200 pages en statut « Découverte, actuellement non indexée ». Des pages qui étaient indexées depuis des mois — des catégories, des articles piliers, des fiches auteur. Google les traite comme si elles venaient d'apparaître.
L'équipe vérifie l'onglet Performance. Sur les sept derniers jours :
- Clics : 196 000 (vs 288 000 la semaine d'avant)
- Impressions : −41 %
- CTR moyen : stable à 3.2 %
- Position moyenne : passée de 14.8 à 22.3
La chute n'est pas liée à une pénalité. Les pages ne sont pas désindexées. Elles sont repassées en file d'attente. Google les redécouvre.
Le CTO est appelé à 9h40. Il vérifie les logs serveur Apache. Le constat est immédiat : Googlebot a frappé le sitemap index 847 fois en 72 heures. En temps normal, c'est 4 à 6 fois par jour. Chaque sitemap enfant — post-sitemap1.xml, post-sitemap2.xml, etc. — a été re-crawlé intégralement.
À 10h15, l'hypothèse « attaque de crawl » est écartée. L'User-Agent est bien Googlebot. Les IP sont confirmées via reverse DNS (crawl-*.googlebot.com). Ce n'est pas un bot parasite.
À 10h30, quelqu'un pose la question : « C'est quoi ce update Rank Math de mercredi ? ».
Le bug : un changement de format que Google interprète comme un nouveau sitemap
L'équipe compare le sitemap actuel avec une version cachée par WP Rocket datant d'avant la mise à jour. Le diff révèle le problème.
Avant la mise à jour (Rank Math 1.0.232)
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.fr/guide-seo-technique/</loc>
<lastmod>2026-05-18T09:14:22+00:00</lastmod>
<changefreq>weekly</changefreq>
<priority>0.8</priority>
<image:image>
<image:loc>https://example.fr/wp-content/uploads/guide-seo.jpg</image:loc>
</image:image>
</url>
</urlset>Après la mise à jour (Rank Math 1.0.233)
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.fr/guide-seo-technique/</loc>
<lastmod>2026-06-11T00:00:00+00:00</lastmod>
</url>
</urlset>Trois changements majeurs, tous silencieux.
1. Le namespace image a disparu. Rank Math 1.0.233 a déplacé les image sitemaps dans un fichier séparé. Les URLs dans le sitemap principal ne portent plus le sous-élément <image:image>. Le namespace XML change. Pour Google, la structure du document est différente.
2. Les balises <changefreq> et <priority> ont été retirées. Google les ignore depuis des années, mais leur suppression modifie le hash du document. Tout outil de diffing côté crawler voit un fichier modifié.
3. La valeur <lastmod> a été régénérée. C'est le point critique. Rank Math 1.0.233 a recalculé le lastmod de chaque URL en utilisant la date de dernière modification du post WordPress (post_modified_gmt), mais tronquée à minuit (T00:00:00). Pour une page modifiée le 18 mai à 09:14:22, le nouveau lastmod affiche le 11 juin à 00:00:00 — la date de régénération du cache sitemap.
Pour Googlebot, chaque <lastmod> signale une modification récente. 8 400 URLs affichent un lastmod du 11 juin. Google fait exactement ce qu'il doit faire : il recrawle tout.
Pourquoi personne n'a rien vu
L'équipe SEO vérifie le sitemap via navigateur. Le rendu XSL (la feuille de style visuelle de Rank Math) affiche toujours un tableau propre avec les URLs. Visuellement, rien ne change. Il faut regarder le source XML brut pour voir la différence.
Screaming Frog, lancé en post-mortem, confirme le diagnostic :
# Crawl du sitemap avec Screaming Frog CLI
$ screamingfrog --crawl-sitemap https://example.fr/sitemap_index.xml \
--export-tabs "Sitemaps:All" \
--output-folder ./sf-export/
# Résultat : 8 412 URLs dans le sitemap
# 8 412 avec lastmod = 2026-06-11T00:00:00+00:00
# 0 URL avec un lastmod antérieurChaque URL a le même timestamp. C'est un signal d'alerte qu'un crawler humain repère en dix secondes. Mais personne ne crawle le sitemap après un update de plugin.
La vérification via curl montre le problème brut :
$ curl -s https://example.fr/post-sitemap1.xml | grep -c "<lastmod>2026-06-11"
500
$ curl -s https://example.fr/post-sitemap2.xml | grep -c "<lastmod>2026-06-11"
500Tous les sitemaps enfants. Chaque page. Même date.
Le mécanisme côté Google
Quand Google détecte un sitemap avec des lastmod massivement mis à jour, il entre en mode redécouverte. Le scheduler de crawl priorise ces URLs. Elles sont recrawlées, retraitées, et leur position dans l'index est temporairement instable.
Ce n'est pas une pénalité. C'est un recalcul. Google doit vérifier que le contenu n'a pas changé. En attendant, les pages perdent leur stabilité de ranking. Les URLs qui étaient solidement positionnées en page 1 oscillent entre page 1 et page 3 pendant que le recalcul s'opère.
Le phénomène est amplifié sur les gros sites. Avec 8 400 URLs signalées comme modifiées, le budget de crawl est saturé. Les pages réellement mises à jour (nouveaux articles, corrections) passent en file d'attente basse. Le site perd en fraîcheur réelle.
Un parallèle direct avec ce qui se passe quand un sitemap Astro pointe vers un mauvais domaine : le sitemap est techniquement valide, mais les données qu'il transmet induisent Google en erreur.
Le fix — Restaurer les lastmod et stabiliser le format
Étape 1 : Régénérer les lastmod corrects
Le correctif immédiat passe par un filtre Rank Math qui force le lastmod à utiliser la vraie date de modification du post, sans troncature.
<?php
/**
* Plugin: Must-Use plugin (wp-content/mu-plugins/fix-sitemap-lastmod.php)
* Force le lastmod du sitemap Rank Math à utiliser
* la date de modification réelle du post, au format ISO 8601 complet.
*/
add_filter('rank_math/sitemap/entry', function ($entry, $type, $post) {
if (!isset($post->ID)) {
return $entry;
}
$modified = get_post_modified_time('c', true, $post->ID);
if ($modified) {
$entry['lastmod'] = $modified;
}
return $entry;
}, 10, 3);
/**
* Désactiver le cache interne du sitemap Rank Math
* pour forcer la régénération avec les bonnes dates.
*/
add_filter('rank_math/sitemap/enable_caching', '__return_false');Ce mu-plugin se déploie sans activer/désactiver Rank Math. Il est chargé avant les plugins classiques. La désactivation du cache sitemap est temporaire — elle sera retirée une fois les sitemaps régénérés correctement.
Étape 2 : Purger et régénérer
# Purger le cache sitemap de Rank Math via WP-CLI
$ wp transient delete --all --url=https://example.fr
# Purger le cache objet si Redis/Memcached est actif
$ wp cache flush
# Purger le cache WP Rocket (qui cache aussi les XML)
$ wp rocket clean --confirm
# Vérifier la régénération
$ curl -s https://example.fr/post-sitemap1.xml | head -20Après purge, chaque URL affiche son vrai lastmod :
<url>
<loc>https://example.fr/guide-seo-technique/</loc>
<lastmod>2026-05-18T09:14:22+00:00</lastmod>
</url>Étape 3 : Resoumettre le sitemap
Dans Search Console, l'équipe supprime puis resoumet le sitemap index. Cela force Google à relire la version corrigée. Le ping direct est aussi envoyé :
$ curl -s "https://www.google.com/ping?sitemap=https://example.fr/sitemap_index.xml"Étape 4 : Surveiller la récupération
Les métriques de crawl reviennent à la normale en 48 heures. Le volume d'exploration redescend à 1 400 requêtes/jour (légèrement au-dessus de la baseline de 1 200, le temps que Google finisse ses vérifications).
Le trafic organique met plus de temps. Chronologie observée :
- J+2 : le crawl se calme.
- J+5 : les pages piliers (top 20 par trafic) retrouvent leurs positions.
- J+9 : 70 % du trafic perdu est récupéré.
- J+18 : retour à la baseline. Les 6 200 pages « Découverte, non indexée » repassent en « Indexée ».
- J+21 : les impressions dépassent légèrement le niveau pré-incident, probablement grâce au recrawl frais.
Le même schéma de récupération lente — une régression SEO silencieuse causée par un changement technique sans impact visuel — s'observe régulièrement. L'incident rappelle la désactivation accidentelle de Yoast SEO après un update, où un plugin SEO qui dysfonctionne silencieusement peut coûter des semaines de trafic.
Étape 5 : Prévention
L'équipe met en place trois garde-fous :
Un test automatisé post-deploy. Un script cron qui compare les lastmod du sitemap avec les post_modified_gmt en base. Si plus de 10 % des URLs ont un écart supérieur à 24 heures, une alerte Slack part.
#!/bin/bash
# check-sitemap-lastmod.sh — exécuté via cron toutes les 6h
SITEMAP_URL="https://example.fr/post-sitemap1.xml"
THRESHOLD=50 # nombre max d'URLs avec lastmod "aujourd'hui"
TODAY=$(date -u +%Y-%m-%d)
COUNT=$(curl -s "$SITEMAP_URL" | grep -c "<lastmod>${TODAY}")
if [ "$COUNT" -gt "$THRESHOLD" ]; then
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"⚠ Sitemap alert: ${COUNT} URLs avec lastmod du jour (seuil: ${THRESHOLD}). Vérifier Rank Math.\"}" \
"$SLACK_WEBHOOK_URL"
fiUn freeze des mises à jour auto pour les plugins SEO. Rank Math, comme Yoast, ne se met plus à jour automatiquement. Chaque update passe par un staging où le sitemap XML est diffé avec la production.
Un snapshot hebdomadaire du sitemap. Chaque dimanche, un cron télécharge les sitemaps XML et les commit dans un repo Git privé. Le diff est reviewable en cas d'incident.
Ces mesures auraient aussi évité des situations similaires lors de migrations CDN où les redirects sont oubliés — le principe est le même : ce qui n'est pas monitoré finit par casser silencieusement.
Ce qu'on en retient
Un plugin SEO qui met à jour son format de sitemap n'est pas un bug. C'est une décision produit légitime. Le problème, c'est l'absence de signal. Pas de warning dans le dashboard. Pas de mention dans le changelog. Pas de migration progressive.
Le lastmod est le seul signal que Google prend au sérieux dans un sitemap. Le corrompre — même involontairement — revient à demander un recrawl complet. Sur 500 pages, ça passe. Sur 8 400, c'est trois semaines de turbulences.
La leçon opérationnelle tient en une phrase : chaque composant qui génère du XML pour Google doit être monitoré comme une route de production. Un outil de monitoring continu type Seogard détecte ce type de dérive — un lastmod uniforme sur 100 % des URLs — en quelques minutes, pas en dix-huit jours.
Les plugins SEO sont de l'infrastructure. Il est temps de les traiter comme telle.