Quand une 410 vaut mieux qu'une 404 (et comment la mettre en place vraiment)

Une 410 n'est pas juste une 404 plus fâchée

Dans notre article 301 ou 404, la 410 apparaissait sur une seule ligne d'une liste de décision, comme l'alternative plus forte à la 404 pour un contenu disparu pour de bon. Elle mérite sa propre explication, parce que c'est le seul des quatre codes de statut (301, 302, 404, 410) qui exige une certitude, et pas seulement un constat. Une 404 est presque toujours la réponse automatique par défaut d'un serveur ou d'une application quand quelque chose ne répond pas : personne ne la « choisit » activement ligne par ligne, elle arrive simplement quand rien ne correspond. Une 410, en revanche, doit toujours être déclarée volontairement, par une règle que quelqu'un a délibérément posée en construisant le site, parce qu'elle communique une chose que le serveur ne peut pas savoir tout seul : pas seulement « il n'y a rien ici pour l'instant » (une 404 le dit déjà), mais « il n'y aura plus jamais rien ici, et nous le savons avec certitude ».

Cette différence a une conséquence pratique sur le comportement des moteurs de recherche : un robot qui tombe sur une 404 garde ouverte la possibilité que l'URL revienne (une erreur temporaire, un déploiement à moitié fait, un produit de retour en stock) et continue généralement de revérifier cette URL pendant un certain temps avant de la retirer réellement de l'index. Une 410 est un signal délibéré de suppression définitive, et Google a lui-même indiqué à plusieurs reprises qu'il a tendance à la traiter plus vite pour retirer une URL des résultats, même si aucun des deux cas n'est instantané. La différence n'est donc pas « la gravité de l'erreur », c'est « à quel point vous êtes certain que plus rien ne vivra jamais à cette adresse ».

Quand une 410 fait vraiment des dégâts

Justement parce qu'une 410 communique une certitude, l'utiliser quand cette certitude n'existe pas est l'erreur la plus coûteuse des quatre codes. Deux cas typiques où elle se retourne contre vous :

• Contenu saisonnier ou temporairement suspendu. Un produit abandonné pour de bon est un bon candidat pour une 410. Un produit en rupture de stock qui reviendra dans deux mois ne l'est pas : une 410 décourage le moteur de recherche de revérifier cette URL justement au moment où, quelques semaines plus tard, vous voudriez qu'il le fasse. Dans ce cas, le bon outil reste une 404 (ou, si c'est vraiment temporaire avec une date connue, une 302 vers une page d'information), pas une 410.
• Des règles trop larges. Une 410 posée sur un motif générique ou sur une condition de query string doit être écrite avec le même soin qu'une règle de pare-feu : une condition trop générique peut déclencher la 410 sur des URL légitimes qui ne partagent qu'une partie du motif, fermant définitivement la porte à du vrai trafic au lieu du seul trafic que vous vouliez arrêter. Contrairement à une 301, où une erreur de destination envoie quand même le visiteur quelque part, une 410 erronée ferme simplement la porte, et si ce n'était pas la bonne porte, le seul à s'en apercevoir est celui qui se cogne dedans.

À quoi ressemble vraiment une 410 bien mise en place

Dans notre propre module de redirections, la 410 se choisit dans le menu du type de règle, à côté de la 301 et de la 302, et pour ce type de règle l'adresse de destination n'est pas nécessaire et elle est ignorée : il n'y a pas de « où envoyer » le visiteur, seulement un « il n'y a plus rien ici, définitivement ». La partie techniquement intéressante, c'est l'endroit où la réponse est générée : elle doit partir le plus tôt possible dans le cycle de vie de la requête, avant que l'application ne construise le thème, ne récupère le produit dans la base de données ou ne prépare le rendu de la page, sinon vous avez quand même gaspillé tout le travail qu'une 410 est censée éviter. Une réponse correcte comprend trois éléments souvent oubliés quand une 410 est écrite à la main dans un fichier de configuration :

• Un vrai statut HTTP 410 Gone, et non un 200 avec un texte « produit indisponible » (la même erreur de soft 404 déjà traitée dans l'article précédent, qui s'applique ici à l'identique).
• Un en-tête X-Robots-Tag: noindex, qui renforce le signal pour les robots qui lisent cet en-tête indépendamment du code de statut.
• Un corps de page minimal, traduit dans la langue du visiteur, plutôt qu'une page blanche : une 410 reste une réponse sur laquelle une vraie personne peut arriver en cliquant sur un ancien lien, pas seulement quelque chose que voit un robot.

Un cas réel : un robot qui tournait en boucle sur un paramètre empoisonné

Sur notre propre boutique, un robot (celui de Meta) tournait en boucle sur des URL de la forme /login?back=... qui contenaient encore, dans la valeur du paramètre, l'ancien domaine de la boutique d'avant un changement d'adresse : plus de 36 000 requêtes en une seule nuit, plus de 90 % de tout le trafic reçu par le serveur, chacune servie avec une réponse 200 et un rendu complet de la page, c'est-à-dire le même coût CPU qu'une vraie requête. Le problème n'était pas l'URL elle-même (/login est une adresse parfaitement légitime), c'était la combinaison avec cette valeur de paramètre précise, qu'aucun vrai visiteur ne produirait jamais.

Nous avons vérifié qu'une seule règle 410 avec une condition sur la query string règle exactement ce cas, sans toucher au serveur web et sans toucher au trafic légitime : la règle ne se déclenche que lorsque le paramètre back contient l'ancien domaine, pas sur chaque requête vers /login. Résultats des tests, sur trois versions différentes de PrestaShop :

• /login?back=http%3A%2F%2Fold-domain.example%2Fx renvoie 410
• /login?back=https%3A%2F%2Fold-domain.example%2Flogin renvoie 410
• /login?back=/my-account (trafic légitime) renvoie toujours 200, sans changement

C'est l'exemple le plus clair de ce qui distingue une 410 bien construite d'une 410 faite à la hâte : la règle ne dit pas « bloquer /login », elle dit « bloquer uniquement la combinaison exacte dont nous savons qu'elle pose problème », et elle vérifie cette condition avant de construire la moindre ligne de la page.

En bref

La 404 est presque toujours une valeur par défaut, la 410 est toujours un choix délibéré, et elle ne doit être utilisée que lorsqu'il existe une vraie certitude que l'URL ne reviendra jamais. Bien faite, c'est un vrai statut HTTP généré le plus tôt possible dans le cycle de vie de la requête, avec l'en-tête robots correspondant, sans gaspiller le travail qu'elle doit éviter ; faite avec une règle trop large, elle peut fermer définitivement la porte à un trafic qui était légitime. Pour qui veut gérer ces règles sans toucher à la configuration du serveur, un module comme cll_seoredirect est une option, mais le critère pour décider quand une 410 est le bon choix reste le même quel que soit l'outil.

Guide d'installation et de configuration du module

Redirections SEO - Gestion 301/302/404 (SEO Redirects)Gérez les redirections 301/302 (simples, wildcard ou regex sécurisées), surveillez les 404 et co…49,99 €Voir le produit