Google AI Overviews et AI Mode reformulent les résultats locaux en synthèses contextuelles. Une page locale qui ranke en position 3 sur une requête classique peut être totalement absente de la réponse générée par le LLM. Le problème n'est presque jamais le contenu lui-même — c'est l'architecture technique qui empêche le modèle d'extraire, de vérifier et de citer l'information locale.
Pourquoi les pages locales classiques échouent dans l'AI Search
Le modèle de génération derrière AI Overviews ne "lit" pas une page locale comme un humain. Il procède par extraction d'entités, vérification croisée entre sources, et sélection de fragments citables. Une page locale typique — nom de ville en H1, paragraphe générique sur le service, carte Google Maps embed, formulaire de contact — ne fournit rien de tout ça.
Le problème du template local dupliqué
Le pattern le plus répandu chez les entreprises multi-sites : un template identique déployé sur 50, 200 ou 2 000 villes, avec comme seule variation le nom de la localité injecté dynamiquement. Google sait détecter ce pattern depuis des années (voir les guidelines sur les doorway pages). Mais dans le contexte AI, le problème est plus profond.
Un LLM qui grounding sa réponse a besoin de signaux de différenciation sémantique entre les pages. Si 200 pages partagent 90% du même contenu et que seul le nom de ville change, le modèle n'a aucune raison de préférer l'une à l'autre — et il ne citera probablement aucune d'entre elles. Il ira chercher une source qui offre une information spécifique à la localité : un annuaire local, un article de presse régionale, un avis Google Business détaillé.
Ce que le grounding attend d'une page locale
Le processus de grounding — la façon dont un LLM vérifie et ancre ses affirmations dans des sources — repose sur la correspondance entre des claims (affirmations factuelles) et des passages structurés dans les documents sources. Pour le local, ça signifie :
- Des affirmations factuelles vérifiables (adresse, horaires, services spécifiques à cette localité)
- Un balisage sémantique qui rend ces faits extractibles par machine
- Une cohérence entre le contenu on-page et les données structurées off-page (Google Business Profile, annuaires, NAP)
Si vous voulez comprendre en profondeur comment le grounding diffère de l'indexation classique, l'analyse de ce que Bing a révélé sur le grounding est un bon point de départ.
Architecture technique d'une page locale AI-ready
Voici l'architecture que nous recommandons pour une page locale qui doit performer à la fois en search classique et en AI Search. Le principe : chaque fait local doit exister à trois niveaux — HTML visible, données structurées JSON-LD, et métadonnées sémantiques.
Le squelette HTML sémantique
Chaque page locale doit contenir des sections clairement identifiables par un crawler ou un modèle. Pas de div générique — utilisez des éléments sémantiques HTML5 avec des attributs itemscope et itemtype en backup du JSON-LD.
<article itemscope itemtype="https://schema.org/LocalBusiness">
<header>
<h1 itemprop="name">Plomberie Durand — Intervention à Lyon 3e</h1>
<p itemprop="description">
Service de plomberie d'urgence dans le 3e arrondissement de Lyon.
Intervention sous 45 minutes, 7j/7, depuis notre dépôt rue Paul Bert.
</p>
</header>
<section aria-labelledby="address-heading">
<h2 id="address-heading">Zone d'intervention et accès</h2>
<address itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
<span itemprop="streetAddress">127 rue Paul Bert</span>,
<span itemprop="postalCode">69003</span>
<span itemprop="addressLocality">Lyon</span>,
<span itemprop="addressRegion">Rhône</span>
</address>
<p>Quartiers couverts en moins de 30 minutes : Part-Dieu, Villette,
Montchat, Sans Souci, Dauphiné. Accès direct via le boulevard
Vivier-Merle — stationnement dédié véhicule d'intervention.</p>
</section>
<section aria-labelledby="services-heading">
<h2 id="services-heading">Services spécifiques Lyon 3e</h2>
<ul itemprop="hasOfferCatalog" itemscope
itemtype="https://schema.org/OfferCatalog">
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/Offer">
<span itemprop="name">Débouchage canalisations immeuble haussmannien</span>
<meta itemprop="priceCurrency" content="EUR"/>
<span itemprop="price" content="120">à partir de 120 €</span>
</li>
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/Offer">
<span itemprop="name">Remplacement colonne montante copropriété</span>
<meta itemprop="priceCurrency" content="EUR"/>
<span itemprop="price" content="2500">à partir de 2 500 €</span>
</li>
</ul>
</section>
<section aria-labelledby="hours-heading">
<h2 id="hours-heading">Horaires d'intervention Lyon 3e</h2>
<time itemprop="openingHours" datetime="Mo-Fr 07:00-21:00">
Lundi – Vendredi : 7h – 21h
</time>
<time itemprop="openingHours" datetime="Sa-Su 08:00-18:00">
Samedi – Dimanche : 8h – 18h
</time>
</section>
</article>Trois choses à noter dans cette structure :
- Chaque section a un heading sémantique lié par
aria-labelledby. Le LLM et les crawlers peuvent identifier le sujet de chaque bloc sans parser le contenu. - Les prix sont balisés avec
Offer— c'est un signal de spécificité locale. Un template générique ne contient jamais de prix localisés. - La zone d'intervention est décrite en texte libre avec des noms de quartiers réels, pas juste "Lyon". Ça fournit des entités géographiques granulaires pour le grounding.
JSON-LD complet pour le local
Le microdata dans le HTML ne suffit pas. Ajoutez un bloc JSON-LD complet qui consolide toutes les informations et ajoute des propriétés que le HTML ne peut pas porter proprement :
{
"@context": "https://schema.org",
"@type": "Plumber",
"@id": "https://plomberie-durand.fr/lyon-3e/#business",
"name": "Plomberie Durand — Lyon 3e",
"url": "https://plomberie-durand.fr/lyon-3e/",
"telephone": "+33472XXXXXX",
"email": "[email protected]",
"address": {
"@type": "PostalAddress",
"streetAddress": "127 rue Paul Bert",
"postalCode": "69003",
"addressLocality": "Lyon",
"addressRegion": "Auvergne-Rhône-Alpes",
"addressCountry": "FR"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 45.7578,
"longitude": 4.8715
},
"areaServed": [
{
"@type": "City",
"name": "Lyon",
"sameAs": "https://www.wikidata.org/wiki/Q456"
},
{
"@type": "AdministrativeArea",
"name": "Lyon 3e arrondissement"
}
],
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "07:00",
"closes": "21:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday","Sunday"],
"opens": "08:00",
"closes": "18:00"
}
],
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "183"
},
"sameAs": [
"https://www.google.com/maps/place/...",
"https://www.pagesjaunes.fr/..."
]
}Le point critique : la propriété sameAs et le lien Wikidata dans areaServed. Ces références permettent au modèle de résoudre l'entité géographique sans ambiguïté. "Lyon 3e" peut être interprété de multiples façons — le lien Wikidata lève l'ambiguïté. C'est exactement le type de signal que le grounding exploite, comme l'explique l'article sur la visibilité AI qui commence avant la recherche.
Contenu localement différencié : la clé du grounding
Le balisage technique ne fait que rendre l'information extractible. Encore faut-il que cette information soit unique et spécifique à la localité.
Ce qui différencie vraiment une page locale
Voici les types de contenu qui créent une différenciation suffisante pour que le LLM sélectionne votre page plutôt qu'une autre :
Données factuelles locales vérifiables. Pas "nous intervenons à Lyon" mais "temps d'intervention moyen de 38 minutes depuis notre dépôt de la rue Paul Bert vers le quartier Part-Dieu, mesuré sur 247 interventions en 2025". Ce type d'affirmation est vérifiable par croisement avec votre Google Business Profile et vos avis clients.
Contexte géographique technique. Pour un plombier : "Les immeubles du quartier Villette (construits entre 1960 et 1975) utilisent majoritairement des colonnes en fonte — nos techniciens sont équipés de caméras d'inspection et de furets motorisés adaptés à ce type de réseau." Ce n'est pas du contenu marketing — c'est de l'information technique spécifique à une zone.
Références croisées locales. Mentionner des entités locales vérifiables : "Partenaire de la régie Alliade Habitat pour la maintenance des 1 200 logements du parc HLM du 3e arrondissement." Ce type de claim crée un lien d'entité que le LLM peut vérifier via d'autres sources.
Le piège du contenu "localisé" par IA générative
Beaucoup d'équipes SEO utilisent maintenant des LLM pour générer du contenu localisé à grande échelle. Le problème : un LLM qui génère du contenu sur "Lyon 3e" produit des généralités tirées de son training data, pas des faits spécifiques à votre business dans cette zone. Google détecte et pénalise le contenu scalé de faible qualité — et les AI Overviews ne le citent tout simplement pas.
La seule approche viable : un template technique solide (la structure HTML/JSON-LD ci-dessus) + un contenu éditorial qui ne peut venir que de données internes (CRM, historique d'interventions, témoignages clients localisés).
SSR et rendu : les pages locales doivent être crawlables sans JavaScript
Si vous utilisez un framework JavaScript pour vos pages locales — React, Vue, Angular — le rendu côté serveur n'est pas optionnel. C'est un prérequis absolu.
Pourquoi le CSR tue vos pages locales dans l'AI Search
Google peut techniquement exécuter du JavaScript pour le rendering. Mais les bots d'AI Search — y compris les crawlers qui alimentent les modèles de grounding — n'ont pas forcément cette capacité. Le bot authorization standard que Google teste montre bien que l'écosystème de crawl se fragmente : vous ne savez plus exactement qui crawle quoi, et avec quelles capacités de rendering.
Vérifiez le rendu de vos pages locales avec un test simple dans Chrome DevTools :
# Désactivez JavaScript et observez le résultat
# Chrome DevTools > Settings > Debugger > Disable JavaScript
# Ou testez avec curl pour voir ce que reçoit un bot sans JS
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
"https://plomberie-durand.fr/lyon-3e/" | \
grep -c "127 rue Paul Bert"
# Si le résultat est 0, votre adresse n'est pas dans le HTML initial
# Le grounding ne la verra probablement pasSi votre adresse, vos horaires, votre JSON-LD ou vos prix n'apparaissent pas dans le HTML initial (avant exécution JavaScript), vous avez un problème. Les leçons de JavaScript SEO tirées du e-commerce s'appliquent intégralement aux pages locales.
Configuration SSR pour les pages locales Next.js
Pour les sites construits avec Next.js (le cas le plus fréquent en 2026 pour les sites multi-locations), utilisez getServerSideProps ou le App Router avec des Server Components pour garantir que les données locales sont dans le HTML initial :
// app/locations/[city]/page.tsx — Next.js App Router
import { Metadata } from 'next'
import { getLocationData } from '@/lib/locations'
import { LocalBusinessJsonLd } from '@/components/LocalBusinessJsonLd'
interface Props {
params: { city: string }
}
// Génération statique des pages locales au build
export async function generateStaticParams() {
const locations = await getAllLocations()
return locations.map((loc) => ({ city: loc.slug }))
}
// Metadata dynamique par localité
export async function generateMetadata({ params }: Props): Promise<Metadata> {
const location = await getLocationData(params.city)
return {
title: `${location.businessName} — ${location.cityName}`,
description: location.metaDescription,
alternates: {
canonical: `https://plomberie-durand.fr/${params.city}/`,
},
}
}
// Page component — rendu côté serveur, zéro JS requis pour le contenu
export default async function LocationPage({ params }: Props) {
const location = await getLocationData(params.city)
return (
<article itemScope itemType="https://schema.org/Plumber">
<LocalBusinessJsonLd data={location} />
<header>
<h1 itemProp="name">
{location.businessName} — {location.cityName}
</h1>
<p itemProp="description">{location.localDescription}</p>
</header>
<section aria-labelledby="area-heading">
<h2 id="area-heading">Zone d'intervention {location.cityName}</h2>
<address itemProp="address" itemScope
itemType="https://schema.org/PostalAddress">
<span itemProp="streetAddress">{location.street}</span>,
<span itemProp="postalCode">{location.postalCode}</span>
<span itemProp="addressLocality">{location.cityName}</span>
</address>
<p>{location.areaDescription}</p>
<ul>
{location.neighborhoods.map((n) => (
<li key={n.slug}>{n.name} — {n.avgResponseTime} min</li>
))}
</ul>
</section>
<section aria-labelledby="services-heading">
<h2 id="services-heading">
Services spécifiques {location.cityName}
</h2>
{location.localServices.map((service) => (
<div key={service.id} itemProp="hasOfferCatalog" itemScope
itemType="https://schema.org/Offer">
<h3 itemProp="name">{service.name}</h3>
<p>{service.localContext}</p>
<p>À partir de <span itemProp="price"
content={service.price}>{service.priceFormatted}</span>
<meta itemProp="priceCurrency" content="EUR" />
</p>
</div>
))}
</section>
</article>
)
}L'avantage de generateStaticParams : les pages sont pré-rendues au build. Le HTML complet, incluant le JSON-LD et toutes les données locales, est servi instantanément. Pas de waterfall, pas de client-side fetch, pas de skeleton screen que le bot voit à la place du contenu.
Scénario concret : migration de 340 pages locales
Un réseau de cliniques vétérinaires avec 85 établissements en France. Avant migration : un SPA React avec les données locales chargées via API après le premier rendu. 340 pages locales (85 villes × 4 services par ville).
État initial
- Trafic organique local : 12 400 visites/mois
- Pages indexées dans Search Console : 340 soumises, 187 indexées (55%). Les 153 autres en "Crawled — currently not indexed" ou "Discovered — currently not indexed".
- Présence dans AI Overviews : 0 citations détectées sur un échantillon de 200 requêtes locales monitorées.
- Temps de rendu complet (mesuré via Screaming Frog en mode JavaScript rendering) : 4,2 secondes en moyenne.
Actions techniques
- Migration vers Next.js App Router avec SSR statique (ISR toutes les 6 heures pour les données dynamiques comme les horaires exceptionnels).
- Ajout du JSON-LD LocalBusiness avec
@type: VeterinaryCare,areaServedavec liens Wikidata,aggregateRatingtiré de Google Business Profile via l'API. - Contenu différencié : chaque page a reçu un paragraphe de contexte local rédigé par le vétérinaire responsable (espèces les plus traitées dans la zone, partenariats avec les refuges locaux, particularités du parc animalier de la ville).
- Maillage interne local : chaque page de ville lie vers les pages de services spécifiques et vers les 2-3 villes les plus proches géographiquement.
- Monitoring des régressions : un outil comme Seogard a été configuré pour alerter si le JSON-LD disparaît d'une page locale (ça arrive plus souvent qu'on ne le pense lors des déploiements), si un canonical est mal généré, ou si le SSR casse sur un subset de pages.
Résultats après 14 semaines
- Pages indexées : 327/340 (96%)
- Trafic organique local : 28 700 visites/mois (+131%)
- Citations AI Overviews détectées : 23 requêtes locales sur l'échantillon de 200 (11,5%). Principalement sur des requêtes de type "vétérinaire urgence [ville]" et "clinique vétérinaire ouverte dimanche [ville]".
- Temps de rendu : 0,3 secondes (HTML statique).
Le facteur déterminant n'a pas été le contenu seul, ni le balisage seul. C'est la combinaison : HTML sémantique crawlable immédiatement + données structurées complètes + contenu localement unique + cohérence avec les signaux off-page (Google Business Profile, NAP dans les annuaires).
Signaux off-page et cohérence des entités
Le balisage on-page ne suffit pas si vos signaux off-page contredisent vos données. Le grounding effectue une vérification croisée : si votre JSON-LD dit "ouvert le dimanche 8h-18h" mais que votre Google Business Profile dit "fermé le dimanche", le modèle a un signal contradictoire — et il ne citera ni l'un ni l'autre.
NAP consistency à l'ère du grounding
La cohérence NAP (Name, Address, Phone) est un classique du local SEO. Dans le contexte AI, elle prend une dimension supplémentaire : le modèle ne regarde plus seulement si l'information existe, mais si elle est cohérente entre les sources.
Vérifiez systématiquement :
- Google Business Profile vs contenu on-page vs JSON-LD : les trois doivent être identiques, caractère par caractère pour l'adresse et le téléphone.
- Annuaires tiers (PagesJaunes, Yelp, TripAdvisor selon le secteur) : même logique.
- Wikidata si votre business y est référencé : la propriété
sameAsdans votre JSON-LD doit pointer vers la bonne entité.
Le suivi des métriques géographiques en 2026 montre que la cohérence inter-sources est devenue un KPI à part entière, pas un nice-to-have.
Les avis comme source de claims pour le grounding
Les avis Google Business Profile servent de source de vérification pour le LLM. Quand un utilisateur demande "est-ce que le plombier Durand à Lyon 3e est fiable ?", le modèle synthétise les avis — pas votre page "À propos".
Implication technique : encouragez des avis qui contiennent des claims factuels ("intervention en 30 minutes pour un dégât des eaux", "remplacement d'un ballon d'eau chaude en 2 heures"), pas juste "super service 5 étoiles". Ces claims factuels alimentent le grounding et renforcent les affirmations de votre page locale.
Monitoring et détection des régressions locales
Les pages locales sont particulièrement vulnérables aux régressions silencieuses. Un déploiement qui casse le SSR sur 15% des pages, un changement de template qui supprime le JSON-LD, un redirect chain qui s'installe entre l'ancienne et la nouvelle URL d'une ville — ces problèmes passent inaperçus pendant des semaines si vous ne monitorez pas activement.
Ce qu'il faut surveiller
JSON-LD présent et valide sur chaque page locale. Utilisez Screaming Frog en mode liste (importez toutes vos URLs locales) avec l'extraction personnalisée pour vérifier la présence du @type: LocalBusiness dans le HTML brut.
Canonical auto-référent. Chaque page locale doit avoir un canonical qui pointe vers elle-même. Un canonical qui pointe vers la mauvaise ville — ça arrive avec les templates dynamiques — détruit l'indexation de la page.
Temps de réponse serveur. Les pages locales générées dynamiquement peuvent avoir des temps de réponse variables selon la charge. Un TTFB > 800ms sur une page locale est un signal d'alerte.
Cohérence entre le sitemap et les pages réellement accessibles. Si votre sitemap liste 340 URLs mais que 20 d'entre elles retournent un 404 ou un soft 404, vous gaspillez du crawl budget et risquez un effondrement de trafic.
Un outil de monitoring continu comme Seogard détecte automatiquement ce type de régression — la disparition d'un bloc JSON-LD, un canonical modifié, un changement de statut HTTP — et alerte avant que l'impact SEO ne se matérialise dans vos données Search Console, qui arrivent toujours avec plusieurs jours de retard.
Au-delà des AI Overviews : préparer les pages locales pour AI Mode
Google AI Mode (accessible via Chrome) va plus loin que les AI Overviews : il permet des conversations multi-tours où l'utilisateur affine sa requête locale. "Trouve un plombier à Lyon 3e" → "Lequel est ouvert le dimanche ?" → "Combien coûte un débouchage ?" Chaque étape est une opportunité de citation — ou d'exclusion.
Pour que vos pages locales survivent à ce parcours conversationnel, chaque fait doit être atomique et extractible : un prix dans une balise Offer, un horaire dans OpeningHoursSpecification, une zone dans areaServed. Le LLM ne va pas parser un paragraphe de 200 mots pour en extraire un horaire noyé dans le texte.
L'évolution des liens dans les AI Overviews et AI Mode confirme que Google augmente progressivement les citations de sources dans les réponses générées. Les pages qui fournissent des données structurées granulaires et vérifiables sont celles qui captent ces citations.
La construction de pages locales performantes dans l'AI Search n'est pas un exercice de création de contenu — c'est un exercice d'ingénierie de l'information. Le contenu doit être spécifique et vérifiable, la structure doit être extractible par machine, et la cohérence entre sources doit être maintenue en continu. Les équipes qui traitent leurs pages locales comme un problème technique — et non comme un problème éditorial — sont celles qui captent les citations dans les réponses AI.