Combien de refontes de sites institutionnels ont dégradé la visibilité IA du site sans que personne ne s’en aperçoive avant plusieurs mois ? La question s’est posée concrètement pour un site institutionnel d’une collectivité, dont la refonte technique était prévue pour migrer vers un thème basé sur l’éditeur de site complet, avec un nouvel hébergement et une nouvelle arborescence d’URL. L’enjeu n’était pas seulement de préserver le référencement Google classique — déjà bien documenté par des checklists de migration éprouvées — mais de préserver aussi la visibilité du site auprès des moteurs de réponse IA, un sujet encore jeune et pour lequel peu de retours d’expérience existaient au moment de préparer cette refonte.
La checklist qui suit a été construite en croisant les enseignements de plusieurs migrations suivies en parallèle et les recommandations techniques disponibles début 2026, avec un principe directeur : ne rien vérifier après la mise en ligne, tout valider avant, sur l’environnement de préproduction lui-même.
Accès et découvrabilité des robots
Premier point de contrôle, et souvent le plus critique : vérifier que le nouveau robots.txt n’exclut aucun robot IA légitime par erreur de copier-coller depuis l’environnement de préproduction, un piège classique lors d’une bascule de nouvel hébergement.
- Comparer explicitement l’ancien et le nouveau
robots.txt, ligne par ligne, avant bascule. - Vérifier la présence ou l’absence volontaire des directives concernant les robots des moteurs de réponse (GPTBot, ClaudeBot, PerplexityBot notamment), selon la politique choisie par le site.
- Confirmer que le nouveau sitemap XML est généré et accessible à la même URL que l’ancien, ou qu’une redirection propre est en place si l’URL change.
- Tester la résolution de
/llms.txtsi ce fichier existait sur l’ancien site, pour s’assurer qu’il a bien été migré et non oublié dans le nouveau thème.
Conservation des signaux d’autorité et d’entité
Un site institutionnel tire une part importante de sa crédibilité, aux yeux d’un moteur de réponse comme d’un moteur de recherche classique, de la cohérence de ses entités déclarées : l’organisation, ses responsables, ses publications officielles. Une refonte de thème est un moment à risque pour ces signaux, souvent gérés par un plugin de balisage dont la configuration ne se transfère pas automatiquement d’un thème à l’autre.
- Vérifier que le balisage
Organization(nom, logo, description) reste strictement identique après bascule, sans changement de nom légal ou de logo par erreur de migration de contenu. - Confirmer que chaque page d’auteur ou de responsable conserve son balisage
Person, souvent perdu lors d’un changement de thème qui gère différemment les métadonnées d’auteur. - Réexaminer les URL canoniques déclarées sur les pages clés (page d’accueil, pages de mission, pages de contact officielles), qui doivent rester stables ou être redirigées en 301 sans exception.
Rendu tel qu’un robot IA le perçoit
Un point trop souvent négligé lors d’une refonte : vérifier le rendu du contenu tel qu’il apparaît à un robot qui n’exécute pas nécessairement le JavaScript de la même façon qu’un navigateur humain. Un nouveau thème basé sur l’éditeur de site complet peut introduire des blocs interactifs (accordéons, onglets) dont le contenu texte n’est présent dans le DOM qu’après une interaction, ce qui le rend invisible à un robot qui ne simule pas ce clic.
curl -A "Mozilla/5.0 (compatible; GPTBot/1.0)" https://exemple-collectivite.fr/mission/ | grep -o "<p>.*</p>" | wc -lComparer le nombre de paragraphes récupérés via une requête sans exécution JavaScript, avant et après refonte, donne un signal rapide d’alerte si le nouveau thème dissimule une part du contenu textuel derrière une interaction obligatoire.
Stabilité de la structure d’URL et redirections
Une refonte technique s’accompagne presque toujours d’une tentation de « nettoyer » la structure d’URL. Pour un site institutionnel dont certaines pages sont citées depuis des années par d’autres administrations, des associations partenaires, ou déjà reprises par des moteurs de réponse IA, ce nettoyage doit être traité avec la même rigueur qu’une migration de domaine complète.
| Contrôle | Méthode |
|---|---|
| Cartographie complète des URL existantes | Export du sitemap actuel + crawl complet avant bascule |
| Plan de redirection 301 exhaustif | Table de correspondance ancienne URL → nouvelle URL, testée avant mise en ligne |
| Vérification post-bascule | Échantillon aléatoire de 50 anciennes URL testées en environnement réel |
Contenu de référence à ne jamais perdre dans la bascule
Certaines pages d’un site institutionnel jouent un rôle disproportionné dans sa citation par les moteurs de réponse : pages de définitions officielles, comptes rendus publics, documents de référence. Il est utile de dresser, avant refonte, une liste explicite de ces pages à haute valeur de citation, identifiées via l’historique des citations IA suivies les mois précédents si un tel suivi existe, et de leur appliquer une vigilance renforcée durant tout le processus de migration de contenu.
Une refonte réussie sur le plan Google et ratée sur le plan GEO passe souvent inaperçue pendant des mois : la checklist doit couvrir les deux dès la préproduction, pas seulement après coup.
Pour aller plus loin
Cette checklist de quatorze points de contrôle n’a pas vocation à remplacer un audit technique classique de migration, mais à le compléter sur la dimension spécifique des moteurs de réponse IA, encore absente de la plupart des procédures standard début 2026. L’essentiel tient en une discipline simple : traiter la visibilité GEO comme un critère de validation de la refonte au même titre que les Core Web Vitals ou le maintien des positions Google, avec des vérifications faites en préproduction et non découvertes après coup, une fois l’ancien site déjà démonté et les comparaisons devenues impossibles.
