purge --tag=redirect:categorie-outillage. Cette seule ligne, lancée après une modification de règle sur un site e-commerce B2B vendant du matériel professionnel, a évité qu’un lot de deux mille URL continue de rediriger vers une ancienne arborescence pendant plusieurs jours.
Le scénario qui a motivé ce schéma est classique : une règle de redirection au niveau du serveur d’origine est modifiée pour corriger une erreur de mapping, mais la couche de cache Edge en amont continue de resservir l’ancienne réponse à chaque visiteur et à chaque robot, parfois plusieurs heures après la correction. Pour un budget de crawl déjà serré, ce délai peut suffire à figer une redirection périmée dans l’index.
Pourquoi le cache Edge complique les redirections
Un cache Edge stocke la réponse HTTP complète d’une requête, code de statut compris. Une redirection 301 ou 302 est donc mise en cache au même titre qu’une page 200, avec sa propre durée de vie définie par les en-têtes Cache-Control ou par une règle de politique de cache côté fournisseur. Tant que cette entrée n’expire pas ou n’est pas explicitement invalidée, chaque point de présence répond avec l’ancienne redirection, indépendamment de ce qui a changé côté origine.
Le piège le plus fréquent survient quand une redirection A → B est corrigée en A → C sur le serveur d’origine, mais que le cache Edge continue de répondre A → B pendant sa durée de vie résiduelle. Un robot qui explore A pendant cette fenêtre suit alors une destination qui n’est plus la bonne, ce qui peut créer une chaîne de redirection involontaire si B redirige lui-même vers C.
Schéma d’invalidation ciblée
Plutôt qu’une purge complète du cache, qui force la reconstruction de l’intégralité des réponses et surcharge temporairement le serveur d’origine, l’architecture retenue repose sur un système de tags associés à chaque règle de redirection. Chaque URL redirigée porte un tag correspondant à sa catégorie de mapping, ce qui permet une invalidation limitée au périmètre réellement modifié.
redirections/
├── regles/
│ ├── categorie-outillage.json (tag: redirect:categorie-outillage)
│ ├── categorie-visserie.json (tag: redirect:categorie-visserie)
│ └── fiches-produit-archivees.json (tag: redirect:produits-archives)
├── cache-edge/
│ ├── entree A -> tag redirect:categorie-outillage
│ ├── entree B -> tag redirect:categorie-visserie
│ └── entree C -> tag redirect:produits-archives
└── webhook-deploiement/
└── declenche purge par tag apres validation de la regle
À chaque déploiement d’une nouvelle règle, un webhook déclenche une purge limitée au tag concerné, pas à l’ensemble du cache. Le délai mesuré entre le déploiement et la disparition complète des anciennes réponses en cache est descendu sous la minute sur ce projet, contre plusieurs heures avec une purge manuelle globale déclenchée à la main.
Vérifier que l’invalidation a bien fonctionné
Une invalidation qui échoue silencieusement est pire qu’une absence d’invalidation, car elle donne une fausse impression de correction. La vérification systématique passe par l’inspection de l’en-tête indiquant l’état du cache sur la réponse.
curl -I https://exemple-b2b.fr/ancienne-url-categorie
# Rechercher l'en-tête retourné par le CDN, par exemple :
# CDN-Cache-Status: MISS
# Location: https://exemple-b2b.fr/nouvelle-url-categorie
Un statut MISS ou équivalent juste après le déploiement confirme que la couche Edge a bien reconstruit la réponse à partir de l’origine. Un statut HIT à cet instant précis signale une invalidation manquée, à corriger avant que Googlebot ne recroise l’URL.
Ce que le budget de crawl a à y gagner
Pour un catalogue B2B de plusieurs milliers de références, chaque redirection périmée explorée inutilement consomme une part du budget de crawl qui aurait pu servir à découvrir une fiche produit réellement nouvelle ou une mise à jour de prix. L’effet cumulé de centaines de redirections mal invalidées se traduit, dans les journaux serveur, par une proportion anormalement élevée de requêtes sur des statuts 301 ou 302 par rapport aux statuts 200.
- Suivre dans les logs la part de requêtes Googlebot renvoyant un statut de redirection plutôt qu’un contenu.
- Comparer cette part avant et après la mise en place de l’invalidation ciblée par tag.
- Alerter automatiquement si un tag de redirection reste invalidé plus d’un certain seuil de temps après un déploiement.
Sur ce type d’architecture, on préfère toujours une granularité de tag légèrement trop fine à une purge globale : le coût de reconstruction d’une catégorie ne concerne jamais l’ensemble du catalogue.
En résumé
Un cache Edge qui ignore les changements de règles de redirection peut prolonger artificiellement la durée de vie d’une erreur corrigée côté origine. Le tagging par périmètre de redirection, couplé à une invalidation déclenchée au déploiement et vérifiée par en-tête, permet de garder un délai de propagation compatible avec le rythme d’exploration d’un robot, sans sacrifier la performance globale du cache sur le reste du catalogue.
