La redirection 301 est le geste le mieux documenté du SEO technique. On change une URL, on laisse une instruction permanente à l'ancienne adresse, le moteur suit, le classement passe. Trente ans de pratique, une documentation officielle limpide, aucune controverse.

Ce consensus a été construit pour un agent qui revient. Googlebot recrawle l'ancienne URL, lit le code 301, met son index à jour. Un moteur génératif, lui, fonctionne sur deux couches, et une seule des deux revient. La couche de récupération se comporte comme n'importe quel client HTTP et suit la redirection. La couche de mémoire, celle où l'URL a été apprise pendant l'entraînement, ne recrawle jamais rien.

J'ai voulu savoir ce que cette asymétrie coûte concrètement. Le 3 septembre 2026, j'ai demandé à trois modèles, sans accès au web, les URL exactes de huit pages de la documentation Google. Sur les 13 adresses distinctes obtenues, 9 répondaient 200, une répondait 301, et trois étaient mortes. Voici ce que ce relevé change à la façon de traiter une migration.

Ce que la SERP « redirection 301 » raconte, et ce qu'elle omet

Relevé du 3 septembre 2026 sur Google France, requête « redirection 301 », 590 recherches par mois. La page de résultats porte un Aperçu IA en position 1, un bloc « Autres questions posées » de quatre entrées, un panneau de connaissances, et neuf résultats organiques.

Ces neuf résultats sont d'une homogénéité remarquable. Alsacréations, Pilot'in, AntheDesign, One.com, redirection-web.net, Wikipédia, IONOS, la documentation Google et MDN. Tous définissent le code HTTP, expliquent le .htaccess et opposent le 301 au 302. Leurs dates s'étalent de juillet 2015 à juillet 2026. Aucun des neuf ne traite le versant génératif, ni les Aperçus IA, ni ChatGPT, ni la question de savoir ce que devient une citation quand l'URL change. Le sujet est saturé côté définition et vide côté moteur génératif.

Un détail de cette SERP mérite d'être relevé pour lui-même. L'Aperçu IA de Google s'appuie sur six références : Wikipédia, Alsacréations, redirection-web.net, Pilot'in, Redacteur.com et One.com. La documentation de Google n'y figure pas. Elle est bien présente sur la page, au huitième rang organique, mais le moteur a composé son explication des redirections à partir de six pages tierces plutôt qu'à partir de celle que Google publie lui-même. Le même phénomène que celui relevé sur la cannibalisation SEO : le rang et la citation sont deux arbitrages distincts.

Ce que dit cet Aperçu IA sur le fond est exact mais partiel. Il affirme que « les moteurs de recherche comme Google remplacent l'ancienne URL par la nouvelle dans leurs résultats de recherche ». C'est vrai de l'affichage. Google écrit autre chose de son index.

Ce que la documentation de Google écrit vraiment

La page crawling-indexing/301-redirects, récupérée et aplatie ce jour, fait 18 937 caractères de texte utile. Elle contient 115 occurrences de « redirect », 6 de « 301 » et 4 de « 302 ». Deux passages comptent.

Le premier qualifie la nature de l'instruction : « Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical. » Une redirection 301 est donc un signal, pas un ordre. La même réserve que celle qui pèse sur la balise canonique, déjà traitée dans notre article sur le contenu dupliqué.

Le second est plus utile encore, et il contredit l'idée reçue du remplacement : « When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical ; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL. »

Google conserve l'ancienne adresse dans sa représentation du web, rétrogradée au rang de « nom alternatif » de l'URL canonique. La redirection la subordonne. Retenez ce point, c'est exactement ce qui permet à une 301 de rattraper une adresse périmée bien après la migration.

Sur la durée à tenir, la page consacrée aux déplacements de site est explicite : « Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs. » Nous y reviendrons, parce que cette recommandation est calibrée sur deux processus qui, eux, se terminent.

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

J'ai récupéré le même jour les pages de documentation robots d'OpenAI, de Perplexity et d'Anthropic, puis appliqué les mêmes comptages qu'à la documentation Google. Chaîne de traitement identique pour les cinq documents : suppression des balises, aplatissement des retours à la ligne, normalisation d'encodage avant tout comptage.

Documentation                   "redirect" "301" "302"
------------------------------------------------------
Google, redirections d'URL             115     6     4
Google, fonctionnalites IA              3*     0     0
OpenAI, presentation des robots          0     0     0
Perplexity, robots                       0     0     0
Anthropic, robot d'indexation            0     0     0

* Les trois occurrences de « redirect » dans la page « fonctionnalités IA » de Google se trouvent toutes dans le menu latéral de navigation. Zéro dans le corps du texte. Vérification faite occurrence par occurrence, conformément à la règle que je m'applique avant d'annoncer un zéro.

Un contrôle s'impose avant de conclure d'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 « redirect » est donc un silence éditorial et non une récupération ratée.

Le résultat est net des deux côtés. Aucun des trois éditeurs de moteurs génératifs ne dit un mot du traitement des redirections par ses robots. Ni le code, ni le nombre de sauts suivis, ni la durée de conservation d'une ancienne adresse. Un éditeur qui migre son site n'a aucune indication officielle sur ce que GPTBot, PerplexityBot ou ClaudeBot feront de ses anciennes URL.

Le résultat côté Google est plus intéressant encore. Sa documentation sur les redirections ne mentionne l'IA nulle part dans son corps : les 7 occurrences de « AI » y sont toutes des entrées de menu ou de pied de page. Symétriquement, sa page sur les fonctionnalités IA, qui contient 14 occurrences de « AI Overview », ne dit rien des redirections. Google documente longuement les deux sujets et ne les fait se rencontrer nulle part, sinon dans la colonne de navigation commune, qui range « Redirects » sous « Crawling and indexing » et « AI features » sous « Ranking and search appearance ».

Ce que j'ai mesuré : les URL que trois modèles produisent de mémoire

Le blog a déjà utilisé deux fois le chiffre de l'étude Vercel et Merj de décembre 2024, à propos du maillage interne et du rendu JavaScript : 34,82 % des récupérations de ChatGPT aboutissent sur une 404 contre 8,22 % pour Googlebot, et 14,36 % de ses requêtes suivent une redirection contre 1,49 % pour Googlebot. Ces deux articles en tiraient la même phrase, que ces robots naviguent à partir d'URL mémorisées ou reconstituées. Je reprends ce constat plutôt que de le présenter comme neuf, et cet article est le développement qu'il n'avait pas reçu.

Cette étude mesure le comportement d'un robot au niveau de la requête HTTP. Elle ne dit pas quelle chaîne de caractères un modèle produit quand on lui demande une adresse. C'est cette couche que j'ai mesurée.

Protocole. Un prompt unique, en français, identique pour les trois modèles, demandant les URL exactes de huit pages de documentation Google Search Central sur des sujets stables et anciens : robots.txt, redirections, balise canonique, données structurées, sitemaps, rendu JavaScript, titres de page, Aperçus IA. Recherche web désactivée, pour n'interroger que la mémoire d'entraînement. Modèles interrogés : gpt-5.4, claude-sonnet-4-5 et gemini-2.5-flash. Chaque URL produite a ensuite été appelée en HTTP avec un agent utilisateur fixe, celui de PerplexityBot, sans suivi automatique des redirections, puis avec suivi pour obtenir la destination finale.

Vingt-quatre émissions, treize URL distinctes.

Modele              200 direct 301 vers 200 404 vivantes
--------------------------------------------------------
gpt-5.4                      8            0   0      8/8
claude-sonnet-4-5            7            0   1      7/8
gemini-2.5-flash             5            1   2      6/8
--------------------------------------------------------
Total, 24 emissions         20            1   3    21/24

Sur les treize adresses distinctes, neuf répondent 200 directement, une répond 301, et trois répondent 404. Les trois 404 ont été vérifiées comme de vrais codes 404 et non comme des pages d'erreur servies en 200.

L'écart entre modèles est net et il n'est pas du bruit. J'ai rejoué gemini-2.5-flash dans les mêmes conditions : la réponse est revenue identique caractère pour caractère, les mêmes huit URL dans le même ordre. Le stock d'adresses d'un modèle est stable, ce qui est précisément le problème.

Un cas résume tout le mécanisme. Les trois modèles ont produit trois adresses différentes pour la page consacrée aux Aperçus IA, et ces trois adresses sont dans trois états différents.

Modele            URL produite pour les Apercus IA       Etat
-------------------------------------------------------------
gpt-5.4           /appearance/ai-features                 200
gemini-2.5-flash  /appearance/ai-overviews                301
claude-sonnet-4-5 /appearance/google-search-ai-overviews  404

La même page, trois souvenirs. Google a renommé ce document : /search/docs/appearance/ai-overviews renvoie un HTTP/2 301 avec un en-tête location: /search/docs/appearance/ai-features. L'adresse que gemini a mémorisée est l'ancienne, et c'est la redirection 301 laissée par Google qui transforme ce souvenir périmé en citation valide. Sans elle, gemini enverrait sur une 404, exactement comme claude sur une adresse que personne n'a jamais redirigée.

C'est le résultat central de ce relevé. La redirection n'a pas corrigé la mémoire du modèle, elle ne le peut pas. Elle a rattrapé son erreur au moment où elle sortait.

La recherche web n'a pas corrigé la mémoire

Restait à vérifier l'hypothèse évidente : un moteur qui cherche sur le web avant de répondre devrait produire des URL à jour. J'ai rejoué le prompt sur gemini-2.5-flash avec la recherche web activée.

gemini-2.5-flash      200 direct 301 vers 200 404 vivantes
----------------------------------------------------------
memoire seule                  5            1   2      6/8
recherche web activee          4            0   4      4/8

La recherche web a dégradé le résultat. Six adresses vivantes sur huit de mémoire, quatre sur huit avec la recherche activée. Les quatre adresses mortes de la version connectée sont /crawling-indexing/robots/robots-txt, /crawling-indexing/redirects, /appearance/title-links au pluriel, et /appearance/generative-ai/overview. Toutes plausibles, toutes en 404.

L'explication tient à ce que la recherche web fournit. La réponse connectée porte huit annotations de sourcing, une par ligne, et le modèle a bien lancé huit requêtes de recherche distinctes. La couche de récupération lui a donc apporté de quoi répondre sur le fond. Elle ne lui a pas imposé la chaîne de caractères de l'URL, que le modèle a continué de composer lui-même, et il l'a composée un peu plus mal en reformulant qu'en récitant.

Je ne généralise pas ce résultat au-delà de ce qu'il est : un modèle, un prompt, deux configurations. Il suffit cependant à écarter l'idée rassurante selon laquelle l'activation de la recherche web garantirait des URL à jour. Sur ce relevé, elle ne l'a pas fait.

Détail annexe, mais parlant. Les huit annotations de la réponse connectée pointent toutes vers vertexaisearch.cloud.google.com/grounding-api-redirect/. La couche d'ancrage de Google sert ses propres citations à travers un service de redirection.

Pourquoi « au moins un an » n'est pas le bon horizon

Reprenons la recommandation officielle. Google conseille de garder les redirections « as long as possible, generally at least 1 year », et il en donne la raison : ce délai permet de transférer les signaux vers les nouvelles URL, « including recrawling and reassigning links on other sites ».

Cette justification est solide, et elle est bornée. Le recrawl se termine : quand Googlebot a revisité chaque ancienne URL, le transfert est fait. La réattribution des liens externes se termine aussi, plus lentement, à mesure que les sites tiers mettent à jour leurs pages. Un an est un ordre de grandeur raisonnable pour ces deux processus.

La mémoire d'un modèle n'est ni l'un ni l'autre. Elle est figée à la date de fin d'entraînement, aucun recrawl ne la met à jour, et sa durée de vie utile dépend du calendrier de l'éditeur plutôt que du vôtre : le temps que le modèle reste en production, plus le temps que les modèles suivants continuent d'hériter des mêmes corpus. Un modèle entraîné en 2024, mis en service en 2025 et encore interrogé en 2027 porte l'URL de 2024 pendant trois ans, quelle que soit la propreté de votre migration.

Le calcul change donc de nature. Sur une migration ou une refonte de site, la question n'est plus seulement « combien de temps Google met-il à transférer les signaux », mais « combien de temps une adresse de mon site va-t-elle continuer à sortir de la mémoire d'un modèle ». La première a une réponse d'environ un an. La seconde n'a pas de terme connu.

Une nuance honnête s'impose ici. Le coût réel d'une 404 côté génératif n'est pas symétrique de celui d'une 404 côté SEO. Un lien mort dans une réponse d'assistant coûte un lecteur déjà convaincu, celui qui a lu votre nom et qui clique, là où une 404 classique coûte un rang. C'est un volume plus faible qu'en recherche classique, comme le rappelait notre relevé sur le trafic référent des moteurs IA, mais c'est un volume qualifié.

Ce qu'il faut faire

Ne supprimez jamais une redirection parce qu'un an est passé. C'est la conséquence directe du relevé. Le seuil d'un an couvre le recrawl de Google, pas la mémoire des modèles. Une règle de purge annuelle des redirections, courante dans les migrations bien tenues, est le geste qui transforme un souvenir périmé rattrapable en 404 définitive. Le coût de conservation d'une entrée de redirection est proche de zéro.

Redirigez vers la page équivalente, pas vers l'accueil. Une redirection de masse vers la racine satisfait le crawler et détruit la citation : le modèle avait mémorisé une adresse qui répondait à une question précise, et le lecteur arrive sur une page d'accueil qui n'y répond pas. C'est le même raisonnement que celui de l'article sur le maillage interne, où le lien mort coûte une occasion de citation plutôt qu'un peu de budget de crawl.

Cherchez vos anciennes URL dans vos logs, pas seulement dans votre plan de migration. Un plan de migration liste les URL que vous connaissez. Vos logs serveur listent celles que les robots réclament, y compris des adresses que vous aviez oubliées ou qui n'ont jamais existé sous cette forme. C'est la méthode détaillée dans notre article sur l'analyse des logs de crawlers IA, et c'est le seul moyen de découvrir qu'un modèle réclame une adresse que vous ne saviez pas avoir publiée.

Testez ce que les modèles produisent comme URL de votre site. Le protocole de cet article est reproductible en quelques minutes : demandez à deux ou trois assistants l'adresse de vos pages principales, recherche web désactivée puis activée, et appelez chaque réponse en HTTP. Vous saurez si votre domaine sort avec des adresses vivantes. La commande tient en une ligne.

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' <URL>

Traitez la 404 comme un incident de visibilité, pas comme une erreur technique. Une page qui répond 404 à un robot génératif ne perd pas un rang, elle sort du jeu. Surveillez le taux de 404 par agent utilisateur plutôt qu'en global, puisque les robots IA arrivent avec un stock d'adresses vieilli que Googlebot n'a pas.

Sur une refonte, gardez la structure d'URL quand elle est déjà propre. Le gain esthétique d'une arborescence réécrite est réel pour vous et nul pour un moteur. Chaque URL modifiée est une adresse mémorisée de plus qui dépendra d'une ligne de configuration pour rester citable.

Ce que cet article n'établit pas

Le relevé porte sur un domaine unique, developers.google.com, choisi parce que sa documentation est ancienne, très citée et réorganisée à plusieurs reprises. Rien ne garantit que le taux d'adresses mortes soit du même ordre sur un site commercial ordinaire, et il y a de bonnes raisons de penser qu'il serait plus élevé, faute d'une politique de redirection aussi tenue.

L'échantillon est petit : huit sujets, trois modèles, vingt-quatre émissions. Il montre un mécanisme et une amplitude. Établir un taux d'erreur généralisable demanderait un échantillon bien plus large.

Je n'ai pas mesuré ce que font les robots des moteurs face à une redirection, seulement ce que les modèles produisent comme adresses. La question du nombre de sauts suivis par GPTBot ou PerplexityBot, et de leur comportement sur une chaîne de redirections, reste ouverte, et aucune documentation d'éditeur n'y répond.

Enfin, je n'ai pas testé les codes 302, 307 et 308, ni les redirections en JavaScript ou par meta refresh, qui posent au moins la même question et probablement une question plus difficile.

Ce qu'il faut retenir

Sur les neuf résultats organiques de la requête « redirection 301 » en France, aucun ne traite du versant génératif, et l'Aperçu IA qui les surplombe est composé à partir de six sources tierces sans la documentation de Google, présente pourtant au huitième rang. Cette documentation dit deux choses que le consensus simplifie : une redirection permanente est un « signal » et non un ordre, et Google « keeps track of both » l'ancienne et la nouvelle adresse, la première devenant un nom alternatif de la seconde.

Du côté des moteurs génératifs, les documentations robots d'OpenAI, de Perplexity et d'Anthropic contiennent zéro occurrence de « redirect », « 301 » et « 302 ». Chez Google, la page qui traite des redirections ne mentionne l'IA que dans son menu, et la page qui traite de l'IA ne mentionne les redirections que dans le sien.

Le relevé du jour donne la mesure qui manquait. Sur treize adresses produites de mémoire par trois modèles, trois étaient mortes et une n'a survécu que grâce à une redirection 301, celle qui mène de /appearance/ai-overviews à /appearance/ai-features. Les trois modèles avaient chacun un souvenir différent de cette même page, l'un juste, l'un périmé, l'un faux. Activer la recherche web n'a pas amélioré le résultat, il est passé de six adresses vivantes sur huit à quatre.

La conclusion tient en une phrase. Une redirection 301 a désormais deux métiers distincts : transférer un classement, ce qu'elle fait en quelques mois, et rattraper les adresses périmées que les modèles continueront d'émettre pendant des années. Le premier métier justifie de garder la redirection un an. Le second justifie de ne jamais la retirer. Une migration réussie côté génératif se juge donc à un critère unique : aucune adresse ayant existé publiquement ne doit jamais répondre 404.

C'est cet inventaire des adresses vivantes et mortes de votre domaine que nous établissons dans notre audit GEO. Sur la découverte des URL réclamées par les robots, voir l'analyse des logs de crawlers IA, et sur la façon de vérifier ce qui vous est cité, le suivi des citations IA. Pour le vocabulaire employé ici, notre glossaire GEO.