Une refonte se juge d'habitude sur trois indicateurs : le trafic organique est revenu au bout de six semaines, les positions sont stables, aucune 404 dans la Search Console. Le chantier est classé réussi.

Puis quelqu'un pose à ChatGPT la question qui amenait le plus de prospects, et la marque n'est plus dans la réponse. Elle y était avant. Rien dans le tableau de bord SEO ne signale quoi que ce soit.

L'explication tient à une différence de nature qu'on oublie facilement. Pour un moteur de classement, une URL est une adresse : elle désigne un emplacement, et une redirection suffit à mettre à jour cet emplacement. Pour un moteur génératif, une URL est un identifiant. C'est ce qui a été mémorisé, c'est ce qui est réinterrogé, et c'est ce qui s'affiche sous la réponse. Un 301 déplace une page. Il ne réécrit ni ce qu'un modèle a appris, ni ce que votre page raconte encore d'elle-même.

Pour mesurer l'écart, nous avons relevé le 25 août 2026 les URL que Perplexity cite réellement sur huit questions d'achat françaises, puis nous les avons vérifiées une par une. Le résultat n'est pas celui que nous attendions.

Le relevé : 147 URL citées, vérifiées une à une

Nous avons interrogé Perplexity (modèle sonar-pro, recherche web activée, via l'API DataForSEO) sur huit questions couvrant huit secteurs différents : mutuelle santé pour indépendant, logiciel de facturation pour TPE, aides à l'isolation des combles, banque professionnelle pour SASU, voiture électrique familiale d'occasion, avocat en droit du travail à Lyon, crème solaire pour peau sensible, CRM pour PME industrielle.

Les huit réponses citent 147 URL. Nous avons appelé chacune d'elles avec un agent de navigateur, relevé le code HTTP au premier appel, suivi les redirections, puis récupéré le HTML pour lire ce que la page déclare de sa propre identité.

Premier tableau, les codes de réponse au premier appel.

Réponse au premier appel Nombre Part
200 (la page répond) 132 89,8 %
403 (accès refusé) 11 7,5 %
301 (redirection permanente) 1 0,7 %
404 / 410 (page supprimée) 2 1,4 %
502 (erreur serveur) 1 0,7 %

Le lien mort n'est pas le problème. Trois URL sur 147 ne renvoient plus rien d'exploitable, soit 2 %. Sur un corpus de pages commerciales françaises citées par une IA en août 2026, la pourriture des liens est marginale. Nous nous attendions à trouver un cimetière, nous avons trouvé un web qui répond.

Les 11 réponses en 403 méritent une note. Elles proviennent de cinq domaines qui refusent l'accès à un agent de navigateur ordinaire, pare-feu applicatif ou détection de robot. Ces pages sont citées par Perplexity et inaccessibles à notre relevé : c'est un sujet en soi, que nous avons traité sous l'angle de l'accès dans notre article sur les crawlers IA et le robots.txt.

Le problème est ailleurs, et il ne se voit pas dans un code HTTP.

Six pages sur 139 ne s'appellent pas comme le moteur les appelle

Sur les 147 URL, 139 ont renvoyé un HTML lisible. Nous y avons cherché les deux balises par lesquelles une page déclare qui elle est, rel="canonical" et og:url, en prenant soin d'écarter celles qui se trouvent à l'intérieur d'un commentaire HTML : une balise commentée ne déclare rien du tout.

Ce que la page déclare Nombre sur 139
Toutes ses balises d'identité désignent l'URL citée 133
Au moins une balise désigne une autre URL 6

Trois autres relevés complètent le tableau. D'abord, 17 pages ne portent aucune balise canonical et 37 aucun og:url : ce n'est pas une faute, ces balises ne sont obligatoires nulle part. Ensuite, et c'en est une, 3 pages servent plusieurs canonical à la fois, dont deux avec des valeurs qui se contredisent. La première hésite entre http et https. La seconde fait l'objet du cas 2 ci-dessous.

Ce sont les six pages divergentes qui racontent quelque chose. Elles se répartissent en trois cas de figure, un pour la première, quatre pour le deuxième, une pour le troisième, et chacun correspond à un moment précis d'une refonte.

Cas 1 : le domaine a changé, le moteur cite toujours l'ancien

Une seule des 147 URL renvoie une redirection au premier appel, et c'est celle-ci :

https://tribecrm.fr/blog/quels-sont-les-meilleurs-outils-crm-...
  301 -> https://tribecrm.eu/fr/blog/quels-sont-les-meilleurs-outils-crm-...

La migration est propre. Redirection permanente, même chemin, canonical du fichier d'arrivée cohérent, la racine tribecrm.fr renvoie elle aussi vers tribecrm.eu/fr/. C'est exactement ce que prescrit la documentation, et c'est fait correctement.

Perplexity cite malgré tout tribecrm.fr. Sous la réponse, le lecteur voit l'ancien domaine, avec le nom de marque associé au .fr que l'entreprise n'utilise plus. Un utilisateur qui clique arrive au bon endroit. Un utilisateur qui lit sans cliquer, c'est-à-dire le cas majoritaire sur une surface générative, retient l'ancienne adresse.

Une redirection propre garantit que le visiteur arrive. Elle ne garantit pas que le moteur cite la bonne adresse. Les deux choses étaient confondues tant que le clic était le seul aboutissement d'une recherche.

Cas 2 : la balise que personne ne met à jour

Sur les six pages divergentes, cinq le sont sur leur og:url et trois sur leur canonical, deux d'entre elles cumulant les deux défauts. C'est le déséquilibre le plus instructif du relevé. Tout le monde entretient sa balise canonical. Presque personne n'entretient son og:url, qui reste à la valeur que le gabarit portait le jour de sa mise en place.

Le cas le plus net est celui d'un comparatif de crèmes solaires publié par Futura Sciences, cité par Perplexity. La page sert six balises d'identité :

<link rel="canonical" href="https://www.futura-sciences.com/conso/comparatifs/meilleure-creme-solaire-comparatif/" />
<meta property="og:url" content="https://www.futura-sciences.com/conso/comparatifs/meilleure-creme-solaire-comparatif/" />
<meta property="og:url" content="https://www.futura-sciences.com/">
<link rel="canonical" href="https://www.futura-sciences.com/">
<meta property="og:url" content="https://www.futura-sciences.com/">
<link rel="canonical" href="https://www.futura-sciences.com/">

La première paire est correcte. Les deux paires suivantes déclarent que la version canonique de cet article est la page d'accueil du site. Nous avons rechargé la page à plusieurs reprises : le motif est stable, il ne s'agit pas d'un aléa de cache. La signature est celle d'un gabarit dans lequel deux blocs d'en-tête se superposent, ce que produit couramment une reprise de thème ou une refonte partielle.

Les trois autres divergences sont du même genre, en plus discret. Le blog de Lookfantastic sert un article de conseil dont l'og:url désigne la racine du domaine. Le site d'un cabinet d'avocats lyonnais, cité sur sa page d'accueil, y déclare un og:url pointant vers une page interne de présentation. Un article de La Provence déclare un og:url identique à son URL, à un paramètre ?id= près, ce qui suffit à en faire deux chaînes différentes.

Une précision honnête s'impose ici, parce qu'elle limite la portée du constat. og:url est une balise du protocole Open Graph, destinée au partage social ; ce n'est pas une directive de canonicalisation, et Google ne s'en sert pas pour choisir une URL canonique. Aucun moteur génératif ne documente ce qu'il en fait, et nous n'affirmons pas qu'ils la lisent.

Ce qu'elle vaut, c'est autre chose, et c'est ce qui la rend utile ici : une og:url périmée est le témoin le plus fiable d'une migration mal finie. C'est la valeur que personne ne pense à corriger, donc celle qui trahit le gabarit d'origine. Quand le même gabarit touche aussi la balise canonical, comme chez Futura Sciences, la conséquence cesse d'être théorique.

La documentation de Google sur la consolidation des URL dupliquées qualifie la balise canonical de « a strong signal that the specified URL should become canonical », et précise qu'aucune de ces méthodes n'est obligatoire : « none of them are required ; your site will likely do just fine without specifying a canonical preference ». Un signal fort, pas une instruction. Face à trois canonical contradictoires, Google arbitre.

Rien n'indique qu'un moteur génératif dispose du même arbitrage. Ce n'est pas une preuve qu'il en manque, c'est une absence de documentation, et nous nous gardons d'en faire une règle. Mais l'asymétrie de risque est claire : sur une balise fausse, le moteur de classement a un filet, le moteur génératif n'en a pas de connu. Le même raisonnement vaut pour vos balisages structurés, sujet que nous détaillons dans notre article sur schema.org et le GEO.

Cas 3 : le fichier a été remplacé au lieu d'être mis à jour

Sur la question des aides à l'isolation, Perplexity cite trois PDF de l'Agence nationale de l'habitat. Trois versions du même document, publiées à trois mois différents :

URL du guide des aides Réponse
.../2026-01/202601_guide-aides-financieres_WEB.pdf 404
.../2026-02/Anah-FR-Guide_des_aides_Fev2026_WEB_20260224.pdf 200
.../2026-03/202602_guide-aides-financieres_WEB.pdf 200

Le moteur ne sait pas qu'il s'agit du même document sous trois millésimes. Il les cite comme trois sources indépendantes, dont une supprimée sans redirection. Personne ne s'en est aperçu, parce qu'un PDF déposé dans un répertoire daté ne figure dans aucun plan de redirection.

Le motif est plus courant qu'il n'y paraît. Chaque grille tarifaire, chaque livre blanc, chaque plaquette versionnée dans un répertoire par date crée une nouvelle URL et abandonne l'ancienne. Sur les surfaces génératives, chaque version abandonnée est une citation qui se périme sans prévenir. Le lien entre cette mécanique et la manière dont les moteurs traitent l'actualisation d'un contenu est développé dans notre article sur la fraîcheur des contenus.

Le millésime dans l'URL : 30 pièges sur 147

Un chiffre du relevé n'est pas un incident, c'est une bombe à retardement. Trente des 147 URL citées, soit une sur cinq, contiennent une année dans leur chemin.

.../comparatif-banques-pro-2026-guide-complet-classement, .../voiture-electrique-occasion-2026, .../meilleur-crm-industrie-manufacturiere-france-2026. Chacune de ces adresses porte une date de péremption inscrite dans sa propre identité.

Le réflexe, en janvier, est de créer la version suivante à une nouvelle URL et de rediriger l'ancienne. C'est précisément l'opération que ce relevé montre coûteuse. Deux sites de notre échantillon ont fait l'inverse, et c'est visible dans les données :

URL citée Titre de la page en août 2026
velux.fr/magazine/aide-isolation-combles-2025 « Aides isolation combles 2026 : MaPrimeRénov', CEE & cumul »
miin-cosmetics.fr/blog/...-cremes-solaires-en-2025/ « Quelles sont les meilleures crèmes solaires en 2026 ? »

Ces deux pages ont un slug en 2025 et un contenu en 2026. L'URL est restée, le contenu a été refait. Du point de vue d'un rédacteur, c'est une incohérence gênante. Du point de vue d'un moteur génératif, c'est la seule décision correcte : l'identifiant mémorisé reste valide, et le contenu qu'il désigne est à jour. Les deux pages sont citées.

La règle qui en découle est simple à énoncer et impopulaire à appliquer : ne mettez pas de millésime dans une URL que vous comptez rééditer chaque année. Le millésime a sa place dans le titre, dans le H1, dans la date de mise à jour, dans le corps du texte. Partout où il se corrige sans changer d'identifiant.

Ce que ChatGPT fait de votre nom de domaine

Une observation annexe éclaire l'enjeu d'un changement de domaine. Elle ne fait pas partie du relevé : c'est un seul appel, la même question sur les CRM posée à ChatGPT (gpt-5.4, recherche activée) pour comparer. À prendre comme une illustration, pas comme une mesure.

Là où Perplexity cite vingt blogs comparatifs, ChatGPT cite huit URL provenant de quatre domaines, tous éditeurs des logiciels recommandés. Surtout, les requêtes de recherche que le modèle a lui-même formulées avant de répondre sont visibles, et elles sont toutes de cette forme :

site:odoo.com CRM manufacturing official Odoo 2026 France
site:sellsy.com/fr CRM PME industrie France official 2026
site:pipedrive.com fr manufacturing CRM official 2026

Huit requêtes, huit opérateurs site: pointant vers un nom de domaine. Le modèle ne cherche pas « un CRM français », il va chercher chez des marques qu'il connaît déjà par leur domaine. Une requête site: sur un domaine que vous avez abandonné ne renvoie rien, et aucune redirection ne corrige cela : l'opérateur filtre sur le domaine, pas sur la destination finale. Cette dépendance des moteurs à ce que d'autres disent de vous, plutôt qu'à ce que vous dites, est le sujet de notre article sur les sources tierces.

Détail supplémentaire, dans le même relevé : les URL citées par ChatGPT portent un paramètre ?utm_source=openai ajouté par le moteur, et l'une d'elles a conservé un identifiant de session publicitaire, ?msockid=34b7d17b..., ramassé au passage. L'adresse que le moteur mémorise n'est déjà pas rigoureusement la vôtre.

Ce que Google documente, et ce que personne d'autre ne documente

La documentation de Google sur le changement d'adresse avec modification des URL donne deux repères chiffrés que tout le monde connaît côté SEO : « Keep the redirects for as long as possible, generally at least 1 year », et pour le délai de traitement, « A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer ».

Un an de redirections, quelques semaines de traitement. Ces deux nombres structurent tous les plannings de refonte depuis dix ans.

Nous avons cherché l'équivalent du côté des moteurs génératifs. La documentation d'OpenAI sur ses robots décrit OAI-SearchBot, OAI-AdsBot, GPTBot et ChatGPT-User, leurs plages d'adresses IP et la manière de les autoriser ou de les bloquer. Elle ne dit rien des redirections, des URL déplacées, des balises canoniques ni des changements de domaine. Nous n'avons trouvé aucune consigne publiée sur ce que devient une citation quand l'URL citée déménage.

L'anecdote vaut d'être relevée, parce qu'elle est involontairement démonstrative : l'URL historique de cette documentation, platform.openai.com/docs/bots, renvoie elle-même un 301 vers developers.openai.com/api/docs/bots. La page qui devrait expliquer comment gérer un déménagement d'URL a déménagé sans l'expliquer.

Nous n'en tirons pas que les redirections sont ignorées. Nous en tirons ce qui est vérifiable : aucun délai, aucune garantie et aucune procédure ne sont publiés pour les surfaces génératives. Là où le SEO travaille avec un cadre documenté, une refonte travaille à l'aveugle sur tout ce qui n'est pas Google. Le seul moyen de savoir est de mesurer avant et après, ce que nous décrivons dans notre article sur les quatre sources de données de la visibilité IA.

Le protocole de refonte, côté IA

Voici ce que ce relevé change concrètement dans un cahier des charges de refonte. Rien ici ne remplace le plan de redirection classique : tout s'y ajoute.

Avant de toucher à quoi que ce soit. Relevez les URL de votre domaine que les moteurs citent aujourd'hui. C'est un panel de questions posées à ChatGPT, Perplexity, Gemini et aux AI Overviews, et la liste des adresses qui apparaissent sous les réponses. Cette liste ne se reconstitue pas après coup, et elle ne recoupe pas votre top de trafic organique : ce sont rarement les mêmes pages.

Traitez ces URL comme intouchables. Sur une refonte, chaque URL déjà citée par une IA a une valeur qui ne se transfère pas par redirection. Si le chemin peut être conservé, il doit l'être, même au prix d'une incohérence avec la nouvelle nomenclature. Une arborescence parfaitement logique n'a jamais été citée par personne.

Vérifiez les balises d'identité page par page après la bascule. Le cas des trois domaines montre que ce contrôle ne se déduit pas d'un code HTTP correct : la page répondait 200, servait le bon contenu, et se déclarait ailleurs. Une seule balise canonical par page, pointant vers l'URL réellement servie, og:url cohérent, aucune valeur héritée du gabarit d'origine. Sur les sites rendus par JavaScript, ce contrôle doit se faire sur le HTML initial et non dans l'inspecteur du navigateur, pour les raisons détaillées dans notre article sur le rendu JavaScript.

Gardez les redirections plus longtemps que Google ne le demande. Un an est le minimum documenté pour un moteur de classement dont on connaît le rythme de recrawl. Pour des systèmes dont le rythme de rafraîchissement n'est pas publié, et dont une partie des associations vient d'un corpus d'entraînement figé, il n'existe aucune raison de raccourcir ce délai. Nous recommandons de ne jamais retirer une redirection qui a un jour servi une URL citée.

Recomptez à trente, soixante et quatre-vingt-dix jours. Le même panel de questions, relevé aux mêmes intervalles. C'est la seule façon de distinguer un décrochage lié à la refonte d'une variation ordinaire des réponses, qui est importante d'un jour à l'autre.

Ce que ce relevé ne dit pas

Trois limites, à poser franchement.

Il porte sur 147 URL issues de huit questions, choisies pour couvrir des secteurs différents, pas pour constituer un échantillon représentatif du web français. Les proportions décrites ici valent pour ce corpus et ne s'extrapolent pas.

Il photographie un seul jour, le 25 août 2026, et un seul moteur pour la partie quantitative. Les réponses d'une IA varient d'une exécution à l'autre, y compris à question identique. Les URL citées demain ne seront pas exactement celles-là.

Enfin, l'URL fournie par un moteur dans ses annotations peut avoir été normalisée avant affichage. Nous avons vérifié ce que renvoie l'adresse telle qu'elle est citée, ce qui est la seule chose observable de l'extérieur, et ce que voit un lecteur qui clique.

Ce qu'il faut retenir

Une refonte a toujours consisté à préserver de la valeur pendant qu'on change la structure. La valeur mesurée était la position, et l'outil de préservation était la redirection.

Sur les surfaces génératives, la valeur mesurée est la citation, et la redirection ne la préserve pas. Elle préserve le trajet du visiteur, ce qui n'est pas rien, mais ce n'est plus la même chose. Ce qui compte désormais, c'est la stabilité de l'identifiant, et un identifiant stable est un identifiant qu'on ne change pas : ni de domaine, ni de chemin, ni de millésime.

Les trois cas décrits ici ne sont pas des accidents rares. Ils sont sortis d'un relevé de huit questions ordinaires, en une matinée. Chacun se vérifie sur votre propre site en quelques minutes : le premier avec un curl sur vos anciennes URL, le deuxième en lisant le HTML de vos pages les plus citées, le troisième en listant vos fichiers versionnés par date.

Si vous préparez une refonte, l'ordre des opérations compte plus que le budget : le relevé des URL citées se fait avant les maquettes, pas après la mise en ligne.

Deux prolongements selon votre situation. Si vous voulez d'abord savoir quelles URL de votre domaine sont citées aujourd'hui, avant de figer une arborescence, c'est l'objet d'un audit GEO, dont le relevé porte sur ChatGPT, Perplexity, Gemini et les AI Overviews de Google, et dont nous publions les fourchettes de prix. Si le sujet est de mesurer ce que la bascule a coûté ou rapporté, mois par mois, c'est ce que couvre notre suivi de visibilité IA. Le cadre complet est décrit sur nos pages agence de référencement IA et agence SEO et GEO, où le principe de traiter une réécriture de page comme une migration est déjà posé.