Une page disparaît de Google. Pas de message dans la Search Console, pas d’e-mail, rien. Le trafic s’effondre en quelques jours et l’éditeur découvre le problème en comparant ses courbes. On cherche alors la cause du côté des balises, des contenus, parfois d’un en-tête HTTP mal configuré dont personne ne parle jamais. Sauf que l’explication la plus répandue ne tient pas debout, et c’est précisément là que les ennuis commencent pour qui veut réparer.
L’en-tête From n’est pas le coupable qu’on décrit
Commençons par le malentendu. L’en-tête de requête HTTP From contient une adresse e-mail d’administrateur, celle de la personne qui pilote un agent automatisé. MDN le dit clairement : si vous faites tourner un robot d’indexation, cet en-tête doit être envoyé pour qu’on puisse vous joindre en cas de problème. Sa syntaxe est simple, du type From: webmaster@example.org, et il est reconnu par tous les navigateurs depuis juillet 2015.
Voilà pour le portrait officiel. Sauf que la même documentation classe From comme en-tête de requête interdit, et précise qu’il ne sert ni au contrôle d’accès ni à l’authentification. Un en-tête que les navigateurs bloquent ne peut donc pas, à lui seul, faire tomber des centaines de pages de l’index. Si vous cherchez encore pourquoi votre site a plongé, il faut regarder ailleurs, par exemple du côté des mohedaltrad2020.fr et de leurs dossiers techniques, qui traitent justement des erreurs de crawl et des URL.
Ce décalage entre la théorie et la pratique mérite qu’on s’y arrête. Beaucoup de guides recopient la définition de l’en-tête sans jamais vérifier ce qu’un serveur en fait réellement. Or c’est le serveur qui décide, pas la spécification. Une configuration ratée côté réponse HTTP pèse bien plus lourd qu’un champ de requête oublié.
Comprendre l’indexation avant d’accuser un champ
L’indexation, c’est le moment où un moteur enregistre une page dans sa base après l’avoir lue et jugée digne d’apparaître dans les résultats. Tant que ce passage n’a pas eu lieu, la page n’existe pas pour lui : elle peut être en ligne, accessible aux humains, et totalement invisible pour la recherche. Le robot doit donc pouvoir la récupérer sans obstacle.
Un robot qui reçoit un code d’erreur ne classe rien. Il note, passe à la suivante, et revient plus tard. Si le même code revient plusieurs fois, la page sort de l’index, et le propriétaire du site ne reçoit aucune alerte : les moteurs ne préviennent pas, ils constatent. C’est ce silence qui piège les équipes, parce qu’il laisse croire que tout va bien alors que le crawl échoue depuis des semaines.
Une page peut aussi ne pas être indexée pour des raisons moins techniques. Contenu trop proche d’une autre URL, balise bloquante oubliée après une mise en production, redirection qui boucle, paramètres qui multiplient les adresses. Le résultat est identique : rien dans l’index, et personne pour le signaler.
Les erreurs HTTP qui font vraiment disparaître une page
Quand on parle d’erreur HTTP, il s’agit du code à trois chiffres que le serveur renvoie pour dire ce qui s’est passé avec la requête. Un 200 annonce que tout va bien, un 404 que la ressource n’existe pas, un 500 qu’un programme a planté. Ces codes sont la vraie langue du crawl, et c’est là que se jouent les désindexations massives.
Ce que le robot reçoit et ce qu’il en fait
Un serveur mal réglé peut renvoyer une erreur alors que la page est parfaitement valide. Une règle de pare-feu trop large, un certificat expiré, une limite de requêtes atteinte par le robot lui-même : la réponse est mauvaise, la page est considérée comme indisponible. Voici les cas qui reviennent le plus souvent dans les journaux serveur.
- Le 403 Forbidden, quand le serveur refuse l’accès au robot sans que personne n’ait touché au fichier de configuration depuis des mois.
- Une réponse 500 déclenchée par une extension défaillante, souvent sur une seule catégorie du site.
- Le 429, cette limite de requêtes que le serveur applique à tous les visiteurs, robots compris.
- Une redirection qui repart en boucle et finit par épuiser les tentatives du crawler, jusqu’à l’abandon.
- Et le 404 provoqué par une URL modifiée sans redirection, celui qu’on ne voit jamais arriver quand on renomme une section entière.
Chacun de ces codes produit le même effet : la page cesse d’être récupérable, donc d’être indexable. Aucun n’a besoin de l’en-tête From pour se produire. Le problème vient de la réponse, pas de la requête, et c’est le point que la plupart des articles sur l’indexation sautent allègrement. Sur ce point, voir aussi notre article sur sitemap indexation audit.
Pourquoi aucune alerte ne vous prévient
La raison est simple et un peu vexante : les moteurs de recherche ne sont pas un service de surveillance. Ils indexent ce qu’ils peuvent, quand ils peuvent, et ne doivent rien à personne. Un site qui renvoie des erreurs à répétition est simplement moins visité par le robot, puis plus du tout, sans qu’aucun message ne parte.
Les outils côté éditeur, eux, ne regardent que ce qu’on leur donne. Un sitemap déclaré ne sera pas relu si le serveur bloque son accès, et le rapport de couverture affichera parfois des données anciennes pendant des jours. Franchement, il faut se méfier de cette impression de calme : une absence de nouvelles n’est pas une bonne nouvelle en matière de crawl.
La seule parade sérieuse reste la surveillance active des codes de réponse. Un contrôle régulier des URL importantes, avec un relevé des statuts renvoyés aux robots, repère une dérive avant qu’elle ne coûte des semaines de trafic. Ça demande un peu d’huile de coude au départ, puis ça tourne tout seul.
Le vrai chantier, c’est la configuration serveur
Réparer une désindexation massive commence presque toujours par une plongée dans les journaux. On y trouve les codes renvoyés, l’agent utilisateur qui les a reçus, et l’heure exacte du basculement. Cette chronologie vaut mieux que n’importe quel diagnostic théorique sur les en-têtes, parce qu’elle montre ce qui s’est réellement passé sur le serveur.
La leçon tient en une phrase : un champ de requête documenté, classé interdit dans les navigateurs, ne peut pas expliquer à lui seul la disparition de centaines de pages. Les causes plausibles sont dans les réponses HTTP, dans les règles d’accès, dans les redirections oubliées. Chercher du côté de la requête, c’est regarder le mauvais bout de la chaîne.
Un dernier point qui compte : la réindexation n’est jamais immédiate après correction. Le robot doit repasser, et il ne se précipite pas. Comptez sur la patience, et surtout sur un suivi des statuts pour vérifier que la correction a bien été prise en compte.
Ce qu’il faut retenir de cette histoire
Une page peut disparaître de l’index sans un mot, et ce n’est pas un en-tête From mal réglé qui provoque ça. Les vrais responsables portent des noms ternes : 403, 500, 429, boucles de redirection, règles de pare-feu trop zélées.
Les corriger demande de lire les journaux serveur et de surveiller les codes renvoyés aux robots, semaine après semaine. Le silence des moteurs n’est pas une preuve de santé, juste une absence de nouvelles. Combien de temps laisseriez-vous votre site sans regarder ce qu’il répond vraiment ?
