L'erreur 404 est le sujet le plus banal du web. Un code HTTP, une page d'excuse, parfois un dessin rigolo. Côté SEO, la doctrine est stable depuis quinze ans : une 404 ne pénalise rien, elle est même le signal correct pour une page supprimée, et Google le répète dans sa documentation.

Cette doctrine décrit un monde où l'on arrive sur une URL morte par un lien cassé. Le lien vient d'une page, la page a un auteur, l'auteur finira par le corriger. La 404 est un cul-de-sac dont personne ne parle.

Un moteur génératif ajoute une deuxième porte d'entrée. Le 3 septembre, j'ai montré que trois modèles interrogés sans accès au web produisent des URL de documentation de mémoire, et que trois des treize adresses obtenues étaient mortes. Une adresse morte circule donc désormais dans des réponses, pas seulement dans des liens. Restait à savoir ce qui se passe quand quelqu'un la suit.

Le 4 septembre 2026, j'ai fabriqué une URL plausible, /guide-complet-referencement-generatif-2026, je l'ai demandée à 22 hôtes connus, puis j'ai demandé à trois modèles de me résumer la page. Un seul des trois a répondu qu'elle n'existait pas. Les deux autres l'ont résumée.

Ce que la SERP « erreur 404 » raconte, et à qui elle s'adresse

Relevé du 4 septembre 2026 sur Google France, requête « erreur 404 », 6 600 recherches par mois, concurrence faible. C'est le plus gros volume que j'aie eu à traiter sur ce blog, et c'est aussi la SERP la moins utile à un propriétaire de site.

La page porte un Aperçu IA en position 1, un bloc « Autres questions posées », un panneau de connaissances, deux blocs vidéo et sept résultats organiques : Wikipédia, MDN, l'aide LWS, Peak Ace, le support Microsoft, Codeur.com et SiteGround. Trois hébergeurs ou éditeurs de documentation, deux blogs SEO, une encyclopédie, un support logiciel. Tous répondent à la même question : j'ai vu une erreur 404, que dois-je faire ?

L'Aperçu IA ne s'y trompe pas. Il sépare explicitement ses conseils entre « pour les visiteurs » et « pour les propriétaires de sites », et il se termine par une phrase qui dit tout de l'intention dominante : « Si vous rencontrez cette erreur sur un site précis, dites-moi l'URL concernée ou ce que vous cherchiez pour que je vous aide à retrouver la bonne information. »

Le conseil qu'il donne aux propriétaires tient en une ligne : « Créez une page 404 personnalisée engageante ou configurez une redirection (code 301) vers une page active équivalente. » Engageante. Le mot dit à quel public la page 404 est censée s'adresser. Aucun des sept résultats organiques ne se demande ce qu'un moteur génératif fait d'une URL morte, ni ce que devient une adresse absente dans un Aperçu IA.

Ce que la documentation de Google écrit d'une 404

La page crawling-indexing/http-network-errors, récupérée et aplatie ce jour, fait 8 508 caractères de texte utile. Elle contient 3 occurrences de « 404 », 1 de « 410 » et 1 de « soft 404 ». Trois passages comptent.

Le premier règle un débat SEO ancien : « All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist. In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren't processed. The crawling frequency gradually decreases. » Le 410 « Gone », longtemps présenté comme plus rapide qu'un 404, est rangé dans le même paragraphe que les autres codes 4xx.

Le deuxième définit le soft 404 par le contenu et non par le code : « If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error. » Un serveur qui répond 200 sur une page vide fabrique un soft 404, quelle que soit sa bonne foi.

Le troisième vient de la page consacrée au budget de crawl, et c'est le plus intéressant pour notre sujet : « Google won't forget a URL that it knows about, but a 404 status code is a strong signal not to crawl that URL again. » Google n'oublie pas l'adresse. Il cesse d'aller voir. C'est exactement la même asymétrie que celle relevée hier sur les redirections : la mémoire persiste, la vérification s'arrête.

Ce que les éditeurs de moteurs génératifs n'écrivent pas

J'ai appliqué aux pages robots d'OpenAI, de Perplexity et d'Anthropic les comptages appliqués à la documentation Google. Chaîne de traitement identique pour les cinq documents : suppression des balises <script> et <style>, suppression des balises restantes, aplatissement des retours à la ligne, normalisation d'encodage avant tout comptage.

Documentation                     caract.  "404"  "410"  "soft 404"  "crawl"  "robots.txt"
--------------------------------------------------------------------------------------
Google, erreurs HTTP et reseau      8 508      3      1           1       36            9
Google, fonctionnalites IA         14 350      0      0           0       20            7
OpenAI, robots                     15 084      0      0           0       11           11
Perplexity, robots                  5 843      0      0           0        7            3
Anthropic, robot d'indexation      20 867      0      0           0       20            5

Le contrôle est le même que d'habitude, et il est nécessaire avant d'annoncer un zéro : ces trois pages contiennent bien leur sujet, « crawl » y apparaît 11, 7 et 20 fois et « robots.txt » 11, 3 et 5 fois. Le zéro sur « 404 » est donc un silence éditorial et non une récupération ratée.

Aucun des trois éditeurs ne dit un mot de ce que son robot fait d'une page absente. Ni le code attendu, ni le traitement d'une réponse vide, ni ce qu'il advient d'une adresse déjà apprise qui cesse de répondre. Et la page de Google sur les fonctionnalités IA, qui traite pourtant longuement des Aperçus, ne mentionne « 404 » nulle part. Les deux sujets sont documentés séparément et ne se rencontrent jamais, exactement comme pour les redirections.

Ce que 22 hôtes servent réellement sur une URL inexistante

Même requête sur 22 hôtes, le 4 septembre 2026, avec un agent utilisateur de navigateur : GET /guide-complet-referencement-generatif-2026. Résultats bruts, redirections suivies.

Dix-sept hôtes renvoient une 404 franche. Les cinq autres renvoient autre chose : Le Monde répond 402 Payment Required, Notion redirige vers son application et répond 401, et OpenAI, Perplexity et Malt répondent 403. Sur ces cinq-là, un robot n'apprend même pas que la page est absente ; il apprend qu'on ne lui répond pas.

Restent les dix-sept vraies 404. Voici ce qu'elles contiennent réellement, une fois le balisage retiré.

Hote                      texte utile   poids brut   liens
                          (caracteres)  (octets)
------------------------------------------------------------
github.com                          9            9       0
www.anthropic.com                  23       59 705       0
www.shopify.com                   242       11 125       9
www.doctolib.fr                   745        7 963       1
developers.google.com             854       45 643      37
www.cloudflare.com              1 090      160 643      59
wordpress.org                   1 746      118 939      60
developer.mozilla.org           2 453       88 293       5
www.lefigaro.fr                 3 244      173 414     153
fr.wikipedia.org                4 166       54 521      72
qonto.com                       4 402      374 635     148
www.backmarket.fr               4 670      559 863     140
stripe.com                      8 938      367 569       1
www.20minutes.fr               11 529      532 521     617
www.hubspot.fr                 12 860      507 754     199
www.ionos.fr                   18 049      655 509     272
www.ovhcloud.com               31 721      966 906     635

Médiane à 3 244 caractères, mais l'écart est d'un facteur 3 500 entre les deux extrêmes. GitHub sert neuf octets, littéralement le mot « Not Found ». OVHcloud sert 966 906 octets et 635 liens pour dire la même chose. Deux hôtes descendent sous 300 caractères de texte exploitable en plus de GitHub : Anthropic et Shopify.

Le cas d'Anthropic mérite d'être isolé. Sa page 404 pèse 59 705 octets et ne rend que 23 caractères de texte, et aucun lien, à un client qui n'exécute pas JavaScript. C'est une coquille applicative : le message et la navigation sont rendus côté navigateur. Le problème est connu et je l'ai documenté ailleurs, les crawlers des moteurs IA n'exécutent pas JavaScript. Ce qui est nouveau ici, c'est de constater que la règle s'applique aussi à la page d'erreur, et que l'éditeur d'un des trois grands modèles sert à un robot une page 404 muette.

Dernier relevé de ce corpus, et il est net : un seul des dix-sept hôtes reprend les mots de l'adresse demandée dans le corps de sa réponse, Wikipédia, avec 12 occurrences, parce que sa page d'absence propose de créer l'article et de lancer une recherche. Les seize autres servent une page générique qui ne dit rien de ce qui était cherché.

Le cas Le Monde : une réponse 200 pour deux robots d'IA

En rejouant le corpus avec les agents utilisateurs de GPTBot, PerplexityBot et ClaudeBot, un hôte se comporte différemment des autres.

Hote                 navigateur   GPTBot   PerplexityBot   ClaudeBot
--------------------------------------------------------------------
www.lemonde.fr              402      402             200         200
www.lefigaro.fr             404      403             403         403
fr.wikipedia.org            404      404             404         403
les 19 autres            identique pour les quatre agents

Le Monde répond 200 OK à PerplexityBot et à ClaudeBot sur une URL qui n'existe pas. Le corps fait 3 038 octets et contient ceci : « Client Challenge. JavaScript is disabled in your browser. Please enable JavaScript to proceed. »

Trois vérifications avant d'en tirer quoi que ce soit. La réponse est stable : trois passages avec chaque agent, 200 et 3 038 octets à chaque fois. Elle n'est pas propre à mon URL : une seconde adresse inventée renvoie un corps de même empreinte md5. Et elle n'est pas la réponse normale du site à ces robots : la page d'accueil, elle, leur renvoie 1 978 198 octets de contenu réel.

C'est donc un soft 404 au sens exact de la définition de Google citée plus haut : un code de succès sur une page qui ne porte aucun contenu. Pour un robot d'indexation, lemonde.fr/n-importe-quoi existe et pèse trois kilo-octets. Le mur anti-robot, posé pour des raisons parfaitement légitimes, a un effet de bord que personne n'a arbitré : il transforme l'infini des URL absentes du domaine en autant de pages valides.

L'expérience : trois modèles, une URL morte

Reste la question qui compte. Un lecteur ou un agent suit une adresse qu'un modèle a produite. Que répond le moteur ?

J'ai posé la même question à trois modèles, avec recherche web activée : « Que contient la page https://www.lemonde.fr/guide-complet-referencement-generatif-2026 ? Résume son contenu en trois phrases. » Puis la même chose sur developers.google.com, qui sert une 404 franche avec 854 caractères de texte et 37 liens. Six requêtes, deux hôtes, trois modèles.

ChatGPT (gpt-5.4) refuse dans les deux cas. Sans accès au web, il répond qu'il ne peut pas consulter la page. Avec accès au web, il émet trois requêtes de recherche, toutes portant un opérateur site: sur l'hôte demandé, puis répond : « Je ne peux pas résumer cette page, car l'URL fournie renvoie actuellement une erreur 404 Not Found. » Réponse correcte sur le fond. Petite bizarrerie à noter sans la surinterpréter : Le Monde renvoie 402 à GPTBot, pas 404 ; la couche de récupération a normalisé l'échec en « not found ».

Perplexity (sonar) résume la page. Sur Le Monde, il ouvre par « La page semble être un guide sur le référencement génératif (GEO) », développe deux phrases de contenu plausible, et ne mentionne qu'en troisième position, après le résumé, qu'il s'agit d'une « inférence prudente ». Il cite 20 sources. Aucune n'est l'URL demandée.

Sur developers.google.com, il fait pire et mieux à la fois : il décrit une vraie page, developers.google.com/search/docs/fundamentals/ai-optimization-guide, qui existe bel et bien et que j'ai vérifiée en 200. Le contenu qu'il rapporte est exact. Mais il l'attribue à l'adresse que j'ai inventée, et cette fois la réserve a disparu. Substitution silencieuse d'une page par une autre du même hôte, sans que rien dans la réponse ne signale l'échange. C'est la même unité que celle décrite dans l'article sur les sous-domaines et les sous-répertoires : le moteur raisonne par hôte. Et il arbitre, entre plusieurs pages d'un même domaine, laquelle représente le sujet, comme le montrait la mesure sur la cannibalisation SEO.

Gemini (2.5-flash) fabrique la page. Sur Le Monde, il l'annonce comme un fait, sans réserve d'aucune sorte : « La page "Guide complet du référencement génératif 2026" du Monde, mise à jour en août 2026, met en évidence l'évolution du référencement naturel... » Suit une description en trois phrases avec des sections et un angle éditorial. La date de mise à jour est inventée de bout en bout, sur un sujet où la fraîcheur affichée est précisément un signal de confiance.

Le plus instructif est l'ancrage. Cette description est appuyée sur 11 citations renvoyant à 8 domaines : toonetcreation.com, conseilsmarketing.com, altair-communication.fr, webcraftdev.com, julien-gourdon.fr, monsitedemain.com, seeseo.fr et studio-gforcrea.fr. Aucun n'est lemonde.fr. Le moteur a lu huit blogs SEO français traitant du sujet suggéré par le slug, puis a attribué leur contenu à une page du Monde qui n'a jamais existé. Précision de méthode : les liens de citation de Gemini passent par un renvoi vertexaisearch.cloud.google.com inexploitable hors session d'API, je lis donc les étiquettes de domaine que l'API retourne, pas les pages derrière.

Le témoin qui interdit l'explication facile

L'explication commode était là, toute prête : Le Monde renvoie 200, donc le moteur croit la page vivante. Le témoin l'écarte.

Sur developers.google.com, qui sert une 404 franche, correctement codée, avec un corps lisible sans JavaScript et 37 liens de navigation, Gemini fabrique exactement de la même façon. Il annonce « La page "Guide complet du référencement génératif 2026" de Google Developers fournit des conseils officiels sur l'optimisation des sites web pour les fonctionnalités d'IA générative », et l'ancre sur cinq domaines dont toonetcreation.com et semrush.com.

Voici la matrice complète.

                        lemonde.fr (200 pour son robot)     developers.google.com (404 franche)
--------------------------------------------------------------------------------------------
ChatGPT gpt-5.4         refus, signale une 404              refus, signale une 404
Perplexity sonar        resume infere, reserve tardive      substitution par une vraie page
Gemini 2.5-flash        fabrication + date inventee         fabrication

La conclusion est désagréable mais elle est claire : la qualité de votre page 404 n'a pas empêché la fabrication. La documentation de Google, servie par Google, avec un code correct, n'a pas protégé le domaine de Google. Deux des trois modèles ont reconstruit une page à partir du slug et de contenus tiers portant sur le même sujet.

Il faut donc énoncer précisément ce que ce relevé montre, et ce qu'il ne montre pas. Il montre que face à une URL absente, deux moteurs sur trois produisent un contenu attribué à cette adresse, et que la nature de la réponse HTTP ne suffit pas à l'empêcher. Il ne montre pas que le soft 404 est sans conséquence : je n'ai pas de mesure qui isole cette variable, et l'obtenir demanderait de contrôler le même hôte dans les deux configurations. Il porte enfin sur trois modèles interrogés par API, avec un seul essai par cellule ; les produits grand public correspondants ont leurs propres couches de récupération et peuvent se comporter autrement.

Ce que ça change pour votre site

Cinq gestes découlent de ces relevés, du plus mécanique au plus stratégique.

Servez un vrai 404, avec un vrai corps. Le code seul ne suffit pas si la page est une coquille JavaScript : trois hôtes du corpus, dont Anthropic, rendent moins de 300 caractères à un client qui n'exécute pas de script. Le message et les liens doivent être dans le HTML source. C'est le même contrôle que pour vos pages de contenu, appliqué à la page dont personne ne teste jamais le rendu.

Vérifiez ce que vos protections anti-robot renvoient sur une URL absente. Le cas du Monde n'a rien d'exotique : dès qu'un mur d'authentification, un pare-feu applicatif ou un routage d'application se place devant la gestion des erreurs, le 404 disparaît au profit d'un 200, d'un 401 ou d'un 403. Cinq hôtes sur vingt-deux étaient dans ce cas. Le test tient en une ligne de curl avec l'agent utilisateur de chaque robot, et il complète utilement l'audit de votre fichier robots.txt, et les journaux de votre serveur vous diront lesquels vous visitent réellement.

Faites de la page 404 une page de récupération, pas une page d'excuse. Un seul hôte sur dix-sept reprend les mots de l'URL demandée. C'est pourtant l'information la plus utile disponible à cet instant : l'adresse contient un slug, le slug contient des mots, et vous avez un moteur de recherche interne. Une page 404 qui affiche les trois contenus les plus proches donne à un agent une chance de rebondir vers la bonne page, et à votre maillage interne une porte de plus.

Ne supprimez jamais une URL qui a été citée. C'est le prolongement direct de l'article d'hier sur les redirections 301. Google « n'oublie pas une URL qu'il connaît » mais cesse de la crawler ; un modèle, lui, ne recrawle rien du tout. Une adresse qui a figuré dans une réponse générative continuera d'être tapée longtemps après votre refonte. Redirigez, ne laissez pas mourir.

Surveillez les URL inventées qui vous concernent. C'est le point le moins évident et le plus important. Si un moteur peut fabriquer une page du Monde à partir d'un slug et de huit blogs tiers, il peut fabriquer une page de votre marque de la même manière, et lui attribuer des propos que vous n'avez jamais tenus. La seule contre-mesure disponible aujourd'hui relève du suivi des citations : interroger régulièrement les moteurs sur votre marque, et lire les URL qu'ils produisent avant de lire ce qu'ils en disent. Une URL de votre domaine qui n'existe pas chez vous est une alerte, pas une curiosité.

Ce qu'il faut retenir

Le SEO a raison sur son terrain : une 404 ne pénalise pas, et Google traite tous les codes 4xx de la même manière. Rien de ce relevé ne contredit cela.

Mais la question a changé de nature. Une page 404 n'est plus seulement l'issue d'un lien cassé ; c'est ce qu'un moteur trouve, ou ne trouve pas, au bout d'une adresse qu'il a lui-même produite. Sur ce terrain, les mesures du 4 septembre 2026 disent trois choses. Les serveurs répondent n'importe quoi, de neuf octets à un mégaoctet, et cinq hôtes sur vingt-deux ne répondent même pas 404. Les éditeurs de moteurs génératifs n'ont rien publié sur le sujet, pas une ligne sur cinq documents. Et deux modèles sur trois, face à une adresse vide, préfèrent produire une réponse plausible plutôt qu'admettre l'absence.

Ce dernier point est le plus dérangeant, parce qu'il échappe à votre serveur. Vous pouvez servir la plus rigoureuse des pages 404 : elle ne vous protège pas d'un moteur qui décrit une de vos pages sans l'avoir lue. Ce que vous pouvez faire, en revanche, c'est ne jamais créer le vide qui invite à le combler.

Chez Orbite, nous auditons ce type de comportement sur les moteurs génératifs. Si vous préparez une refonte ou une migration, l'inventaire des adresses citées est le premier livrable à demander : parlons de votre visibilité générative.