Retour au blog
3 octobre 2025Sergei Solod5 min de lecture

Yandex a crawlé mon blog sans /en. Mes redirections 308 ont évité les 404

Après avoir ajouté environ 3 000 pages /en/blog/... à mon sitemap, j’ai vu Yandex tenter les chemins correspondants en /blog/.... Les redirections 308 déjà en place ont empêché ces requêtes de finir en 404. La vraie leçon n’est pas que Yandex aurait « cassé » mon sitemap, mais qu’une couche de redirection propre rend une architecture d’URL beaucoup plus robuste.

SEOYandexSitemapRedirection 308SEO techniqueCrawl

J’ai déployé une mise à jour du sitemap avec environ 3 000 nouvelles pages sous /en/blog/.... Peu après, Yandex Webmaster m’a montré un comportement inattendu : Yandex essayait d’explorer les chemins correspondants sous /blog/..., donc sans le préfixe /en.

Si ces URLs avaient simplement renvoyé 404, j’aurais pu me retrouver avec des milliers de tentatives de crawl inutiles vers des chemins inexistants. Heureusement, j’avais déjà configuré des redirections 308 permanentes des routes sans préfixe de langue vers les vraies URLs anglaises.

Cette petite couche de routage défensif s’est révélée bien plus utile que je ne l’imaginais.

Ce que j’ai réellement observé

  1. J’ai publié un sitemap contenant environ 3 000 nouvelles pages au format /en/blog/....
  2. Ensuite, Yandex Webmaster a montré que Yandex tentait d’explorer les URLs correspondantes en /blog/....
  3. Ces chemins alternatifs étaient déjà couverts par des 308.
  4. Au lieu d’aboutir à une 404, les requêtes étaient envoyées vers les bonnes URLs /en/blog/....

Je dois cependant corriger un point de ma formulation initiale : je ne peux pas prouver que Yandex « a mal parsé le sitemap ». J’ai observé ces chemins inattendus après la mise à jour, mais la chronologie ne suffit pas à établir la cause interne. Un moteur de recherche peut découvrir une URL par plusieurs signaux ou sources historiques. Sans preuve supplémentaire, la formulation rigoureuse est simplement que Yandex a exploré des chemins que je n’attendais pas.

La nuance est importante. Voir un crawler demander une URL étrange est une observation. Expliquer précisément pourquoi il l’a demandée est une autre affirmation.

Pourquoi les redirections 308 ont été utiles

Ma règle considérait en pratique le chemin court comme un alias permanent de l’URL localisée :

/blog/example-post  -> 308 ->  /en/blog/example-post

Ainsi, même si le crawler arrivait par l’URL inattendue, il atteignait quand même la page que je voulais réellement servir.

308 Permanent Redirect est une redirection HTTP permanente qui conserve la méthode et le corps de la requête. Pour un GET classique de crawler, la conservation de méthode n’est généralement pas le point principal ; ici, l’intérêt était surtout le caractère explicitement permanent. La documentation actuelle de Yandex Webmaster classe 301 et 308 parmi les redirections permanentes.

Documentation officielle de Yandex Webmaster sur les redirections.

Cela ne veut pas dire que 308 est automatiquement meilleur que 301 pour le SEO. Dans mon cas, les 308 existaient déjà et ont rempli leur rôle : une URL inattendue n’est pas devenue une impasse.

Une redirection est un filet de sécurité, pas un correctif de sitemap

Les redirections ont limité les conséquences, mais elles ne rendent pas le crawl inutile souhaitable. Chaque redirection ajoute une requête et un saut. Une règle trop large peut aussi masquer un bug de génération d’URL si on cesse de chercher l’origine des mauvaises adresses.

Si le sitemap contient lui-même des URLs obsolètes ou redirigées, il faut corriger le sitemap et y mettre les URLs finales. Les redirections doivent absorber les anciens chemins, les variantes légitimes ou les URLs découvertes accidentellement, pas servir d’excuse à des données d’URL imprécises.

Dans mon cas, le sitemap contenait déjà /en/blog/.... Les 308 ont seulement rendu le site plus tolérant lorsqu’un crawler arrivait par /blog/....

Ce que je vérifierais aujourd’hui

  1. Ouvrir le sitemap réellement déployé. Vérifier le fichier final et quelques URLs, pas seulement le code qui le génère.
  2. Tester les réponses finales. Les URLs destinées à l’indexation devraient idéalement aboutir directement à la bonne page.
  3. Tester les chemins alternatifs prévisibles. Si une ancienne URL a une destination permanente, le mapping doit être explicite et un-à-un.
  4. Éviter les chaînes. A -> B -> C est plus difficile à contrôler que A -> C.
  5. Comparer les rapports du crawler aux données serveur quand c’est possible. Les outils Webmaster sont utiles, mais ils n’indiquent pas toujours où une URL a été découverte.
  6. Ne pas déduire le ranking du crawl. Crawling, indexation, ranking et trafic sont des étapes différentes.
curl -I https://example.com/blog/example-post

HTTP/2 308
location: https://example.com/en/blog/example-post

Cet exemple est illustratif : l’idée est de vérifier le status exact et le Location exact au lieu de supposer que la règle fonctionne.

Ce que je peux conclure, et ce que je ne peux pas

Je peux confirmer que mes 308 déjà en place ont empêché les requêtes inattendues vers /blog/... de finir en 404 et les ont envoyées vers les URLs voulues.

Je ne peux pas confirmer que le parser de sitemap de Yandex en était la cause. Je n’ai pas non plus mesuré de gain de ranking, de gain d’indexation ou un volume précis de trafic « sauvé ». Ce serait aller plus loin que mes données.

La leçon que je garde est plus limitée et plus utile : une architecture d’URL doit pouvoir absorber les erreurs prévisibles à ses frontières. Un sitemap propre reste la première ligne de défense. Une couche précise de redirections permanentes est la seconde.

Avec les deux, un chemin de crawl inattendu a beaucoup moins de chances de se transformer en milliers d’URLs mortes.