J’ai acheté un domaine vieux de 25 ans : 1 000+ requêtes par jour visaient des URL mortes

J’ai acheté un domaine enregistré pour la première fois en 2000. Sur le papier, cette ancienneté ressemblait plutôt à un avantage. Puis j’ai mis mon nouveau site en ligne et les logs serveur ont commencé à se remplir de requêtes vers des pages que je n’avais jamais créées.

Plus de 1 000 requêtes par jour visaient des URL inexistantes dans le nouveau projet. Dans les analytics, cela apparaissait comme un gros pic de direct traffic avec presque aucun engagement. En parallèle, le crawler de Yandex revenait sur d’anciens chemins, recevait des 404 Not Found, et Yandex Webmaster a accumulé plus de 900 erreurs en une seule nuit.

Ma première explication était simple : d’anciens bots frappent des URL mortes, Yandex voit cette activité et continue donc à les crawler. C’est ainsi que la chronologie apparaissait de mon côté. Mais mes données ne suffisaient pas à prouver cette causalité.

Ce que je pouvais réellement confirmer

J’avais trois observations distinctes. Premièrement, le serveur recevait beaucoup de requêtes vers des URL héritées de la vie précédente du domaine. Deuxièmement, ce trafic ne produisait presque aucun engagement utilisateur réel. Troisièmement, le crawler de Yandex demandait lui aussi d’anciens chemins, et Webmaster signalait plus de 900 erreurs en une nuit.

Sur le plan opérationnel, c’était bien un problème : logs bruyants, requêtes inutiles et rapport d’erreurs à nettoyer. Mais ces faits ne prouvent pas que les bots tiers ont déclenché le crawl de Yandex, ni que ces erreurs ont directement dégradé le classement ou le trafic organique. Crawl n’est pas indexation, indexation n’est pas ranking, et un rapport d’erreurs n’est pas la preuve d’une pénalité.

Ce que j’avais trop simplifié sur 404 et 410

Au départ, je résumais la différence ainsi : 404 veut dire « introuvable pour l’instant », 410 veut dire « supprimé définitivement ». C’est une intuition pratique, mais elle n’est pas techniquement exacte.

404 Not Found signifie que le serveur ne peut pas fournir de représentation actuelle de la ressource demandée ; le statut ne précise pas si cette situation est temporaire ou permanente. 410 Gone est plus spécifique : il convient quand le serveur sait que la ressource n’est plus disponible et que cet état est censé être permanent.

Cette nuance compte aussi pour le SEO. Les moteurs de recherche peuvent retirer des URL qui répondent en 404 comme en 410. Je ne présente donc plus le 410 comme un statut magiquement « plus fort pour le SEO », ni le 404 comme une erreur systématique pour une page supprimée.

Pourquoi des 410 ciblés restaient pertinents dans mon cas

Les anciens chemins n’étaient pas une panne temporaire. Ils appartenaient au contenu précédent du domaine et n’avaient aucune place dans le nouveau projet. Je savais que ces URL précises avaient disparu définitivement. 410 Gone décrivait donc correctement leur état.

J’ai configuré des réponses 410 uniquement pour les chemins legacy connus, au lieu de transformer toute URL inconnue en 410. Après ce changement, le bruit de crawl et de reporting autour de ces anciennes routes a diminué et la situation dans les outils webmaster s’est nettement assainie.

Je reste prudent sur la causalité. Je peux dire que l’amélioration a suivi ce changement et que 410 correspondait sémantiquement à l’état des URL. Je ne peux pas prouver que 410, à lui seul, a arrêté tous les bots. Un bot tiers peut ignorer la signification d’un statut HTTP et continuer à requêter le même chemin indéfiniment.

La règle de décision que j’utilise maintenant

La bonne question n’est pas « 410 est-il meilleur que 404 ? », mais « qu’est-il réellement arrivé à cette URL ? »

• Il existe un remplacement clair : utiliser une redirection permanente comme 301 vers la nouvelle URL réellement équivalente.
• La ressource est définitivement supprimée et n’a aucun remplacement : 410 Gone est un choix précis.
• L’URL est simplement inconnue, mal saisie ou n’a jamais existé : un 404 Not Found normal convient.

J’éviterais en revanche de rediriger toutes les URL mortes vers la page d’accueil uniquement pour faire disparaître les erreurs. Cela masque l’état réel de la ressource et peut être moins clair pour l’utilisateur comme pour le crawler.

Comment j’auditerais aujourd’hui un ancien domaine avant le lancement

Si je réutilise un domaine avec de l’historique, je traiterai son passé URL comme une partie de la migration, même si je ne migre pas l’ancien site lui-même.

1. Examiner l’ancienne empreinte. Rechercher avant le lancement les URL historiques et les sections legacy évidentes.
2. Surveiller les access logs dès le premier jour. Des requêtes répétées vers des chemins que vous n’avez jamais créés montrent que le domaine conserve une mémoire externe.
3. Séparer humains, crawlers de moteurs de recherche et bots aléatoires. Un pic de direct traffic et une erreur de crawler sont deux signaux différents ; il ne faut pas en faire automatiquement une cause unique.
4. Classer les URL mortes récurrentes. Pour chaque motif important, décider consciemment entre 301, 404 et 410.
5. Mesurer séparément. Fréquence des requêtes, rapports de crawl et indexation sont des dimensions différentes ; je préfère éviter de tout réduire à une vague « santé SEO ».

C’est peu de travail comparé à la découverte du problème une fois que les logs et les outils webmaster sont déjà noyés dans le bruit.

Ce que 410 ne résout pas

410 est une déclaration HTTP sur l’état d’une ressource. Ce n’est ni un firewall, ni un rate limiter, ni un système de blocage de bots. Si un scraper continue d’envoyer des requêtes après un 410, le serveur doit toujours les recevoir et y répondre. Si le vrai problème est un volume abusif de requêtes, c’est un problème d’infrastructure distinct.

Ce n’est pas non plus un boost SEO. Le bon statut aide un crawler à comprendre ce qui est arrivé à une URL ; il n’améliore pas à lui seul le classement du nouveau site.

La leçon que j’ai gardée

Le plus surprenant n’était pas qu’un vieux domaine ait de vieilles URL. C’était la vitesse à laquelle cette histoire invisible est redevenue visible après le lancement : plus de 1 000 requêtes par jour vers des pages inexistantes chez moi, presque aucun engagement et plus de 900 erreurs Yandex Webmaster en une nuit.

Un ancien domaine n’est pas un namespace vide. Liens, crawlers, scripts et bots peuvent se souvenir de chemins des années après la disparition du contenu original. Ma règle actuelle est simple : auditer cette histoire, renvoyer le statut qui correspond à la réalité et séparer le trafic opérationnel des bots des conclusions sur les moteurs de recherche.

L’historique peut être un actif. C’est aussi un état que l’on hérite.