Un SEO technique capable de résister aux analyses d'IA, aux refontes « Headless » et à votre prochaine mise à jour d'algorithme.

Le référencement technique (SEO technique) correspond à l'ensemble des interventions qui déterminent si les moteurs de recherche et les assistants IA peuvent explorer, afficher et considérer vos pages comme fiables, avant même que le contenu ou les liens retour n'aient le moindre effet. Il englobe le comportement HTTP, la sémantique HTML, les données structurées, l'attribut hreflang, la canonicalisation, les Core Web Vitals et le rendu JavaScript. Si vous vous trompez sur ce point, le reste de votre investissement ne servira à rien.

En 2026, cette définition s’est élargie. Deux changements ont contribué à cette évolution. Premièrement, les résumés générés par l’IA et la recherche alimentée par ChatGPT s’interposent désormais entre la plupart des utilisateurs et les pages sous-jacentes, ce qui signifie que la facilité de citation revêt désormais autant d’importance que le classement. Deuxièmement, le site modal n’est plus une installation WordPress, mais une variante de front-end « Headless » extrayant du contenu depuis Sanity, Strapi, Payload, Storyblok, Contentful ou un back-end WordPress « Headless ». Chacune de ces architectures présente ses propres risques techniques en matière de SEO, que l’ancien guide ne couvre pas.

Ma définition pratique pour les clients en 2026 : le référencement technique (SEO) englobe tout ce qui ressort d’un test Lighthouse, d’un rapport d’exploration de Search Console, d’une vérification des citations via AI Overview et d’une notification du validateur de schéma, et ce pour chaque locale, chaque modèle et chaque chemin de rendu. Si l’un de ces quatre indicateurs présente un problème sur une URL représentative, c’est là que commence notre intervention.

Sur un site « Headless » ou Jamstack, le rendu est géré par votre framework front-end tandis que le contenu relève de votre CMS, ce qui peut créer une lacune en matière de SEO entre les deux. Le modèle classique WordPress + Yoast reposait sur un principe unique : un serveur, un moteur de rendu, un moteur de règles. Lorsque vous transférez du contenu depuis WordPress vers Next.js ou Astro, vous ne bénéficiez automatiquement d’aucun de ces éléments.

Des empilements purement modernes

Une solution Next.js + Sanity, une solution Astro + Storyblok, une solution Nuxt + Strapi, une solution Next.js + Payload : toutes font l’impasse sur WordPress. Le travail de référencement technique consiste désormais à s’assurer que le schéma de votre CMS modélise les champs SEO dont le front-end a besoin (remplacement de l’URL canonique, carte de redirection, groupe hreflang, JSON d’extension de schéma), et à veiller à ce que la revalidation à la demande se déclenche lorsque le contenu change. L’empoisonnement du cache ISR est un tueur silencieux : une page reste obsolète pendant des heures après sa publication parce que revalidatePath n’a jamais été configuré.

Qu'est-ce qui casse en premier, en réalité ?

Sur les quelque 200 audits « Headless » que nous avons réalisés, le problème le plus fréquent entraînant une interruption de la production est le conflit de URL canoniques : le front-end génère une URL canonique, tandis que les métadonnées du CMS ou le plan du site en génèrent une autre. Google en choisit une, presque toujours celle que vous ne souhaitiez pas, et c'est l'URL erronée qui se retrouve dans l'index. Nous détectons ce problème à l'aide d'un linter intégré à la phase de compilation qui compare, pour un échantillon de pages, l'URL canonique générée par le modèle à celle stockée dans le CMS, et qui fait échouer la compilation en cas de non-correspondance.

WordPress vous offre une puissance de plug-ins inégalée, mais aussi une multitude de façons de vous tirer une balle dans le pied. La stratégie de SEO technique sur un site WordPress classique repose principalement sur la soustraction : supprimer les balises canoniques en double, mettre fin aux conflits de schéma entre Yoast et RankMath et un troisième plug-in dont personne ne se souvient avoir installé, dompter les constructeurs de pages qui génèrent 2 Mo de CSS, et nettoyer les chaînes de redirection qui se sont accumulées au fil de huit années.

La configuration par défaut que nous recommandons en 2026 : un seul plugin SEO (RankMath ou Yoast, jamais les deux), un hébergeur géré avec une mise en cache en périphérie adéquate (Cloudways, Kinsta, WP Engine), Bricks Builder pour les nouveaux sites où les performances sont primordiales ou Gutenberg natif avec Kadence ou Blocksy, un gestionnaire de redirections permettant l’exportation vers un format portable, et Perfmatters ou FlyingPress pour le nettoyage des ressources. Le travail d’audit consiste à identifier les choix qui ont été différents sur votre site et à en corriger les conséquences.

Du côté « Headless », le travail passe de la soustraction à la construction. Il n’y a pas de Yoast, il faut donc développer la gestion des balises méta. Il n’y a pas de plugin Schema, il faut donc créer des modèles JSON-LD. Il n’y a pas de plan du site intégré, il faut donc le générer et le diffuser. Le volume de code que nous ajoutons à un projet « Headless » pour le SEO est généralement trois à cinq fois supérieur à ce qu’un site WordPress vous offre déjà gratuitement, mais ce code nous appartient, est géré par un contrôle de version, peut être testé et ne risque pas de cesser de fonctionner lors de la prochaine mise à jour d’un plugin.

GEO et AEO désignent deux façons différentes dont les fonctionnalités d’IA captent le trafic de recherche. GEO (Google Enhanced Experience) est le terme le plus ancien ; il englobe les fonctionnalités de Google telles que les « Featured Snippets », « People Also Ask » et les « Knowledge Panels », qui extraient un passage de votre page et l’affichent comme réponse. GEO (Generative Engine Optimisation) est le terme le plus récent ; il désigne l'optimisation pour les « AI Overviews », la recherche ChatGPT, Perplexity et Bing Copilot, où l'assistant génère un paragraphe et cite votre page comme source.

Ce que cela implique sur le plan structurel

Ces deux plateformes ont le même objectif : un passage prêt à être cité. Les règles structurelles qui s'imposent sur l'ensemble d'entre elles sont les mêmes. Utilisez une question comme titre H2, et non un titre thématique. Placez la réponse dans la ou les deux premières phrases suivant le titre. Limitez cette réponse à 250 mots maximum. Assurez-vous que la réponse soit générée côté serveur, et non à l'intérieur d'un composant JavaScript qui s'affiche après le chargement de la page. Les robots d'indexation basés sur l'IA et les extracteurs de Google n'exécutent généralement pas de JavaScript ; si votre réponse nécessite du JS pour s'afficher, vous serez invisible.

En quoi le GEO diffère-t-il de l'AEO ?

Trois éléments revêtent une importance particulière pour le GEO. L’autorité des entités : Google et les grands modèles de langage (LLM) construisent un graphe indiquant qui est autorisé à parler de quoi, et les mentions de marque non liées viennent l’alimenter. Le schéma, avec ses tableaux « about » et « mentions », permet à votre page d’être analysée comme faisant partie d’un graphe d’entités plutôt que comme un simple bloc de texte. Et « llms.txt », un fichier standard émergent situé à l’adresse /llms.txt, qui fournit aux outils d’IA une carte organisée de votre site, de la même manière que les fichiers robots.txt et sitemap.xml aident les robots d’indexation. Nous déployons le fichier llms.txt sur chaque site que nous développons et le mettons à jour dès qu’une page importante est mise en ligne.

Vous avez besoin de moins de types de schéma que ce que la plupart des plugins génèrent, mais ceux que vous fournissez doivent être valides et cohérents. Une liste succincte couvre neuf projets sur dix.

• Organisation : un seul graphique valable pour l'ensemble du site dans votre mise en page, comprenant le logo, le champ « sameAs » (uniquement pour les comptes sociaux réels), l'adresse et le « contactPoint ». Ne le dupliquez jamais d'une page à l'autre.
• Site Web : une fois, dans la mise en page, avec l'action « potentialAction » pour la recherche via les liens annexes si vous disposez d'une fonction de recherche sur le site.
• Une liste de fil d'Ariane, sur toutes les pages autres que la page d'accueil, avec des URL adaptées à la langue (une page en français doit pointer vers des pages de niveau supérieur situées dans le répertoire /fr/, et non dans /en/).
• Article ou billet de blog, portant sur du contenu long-form, avec des tableaux « À propos » et « Mentions » destinés à renforcer le graphe d'entités.
• Service, sur les pages commerciales, avec les champs « serviceType », « provider », « areaServed », « audience » et « offers.priceSpecification » (qui permet de publier une fourchette de prix).
• Produit, sur le site de commerce électronique, avec les offres, le prix (en devise), la disponibilité et la note globale (uniquement si vous disposez d'avis authentiques).
• Page FAQ, lorsqu'elle contient au moins deux questions authentiques. La création de fausses FAQ dans le but d'obtenir un balisage Schema est le motif le plus courant de mesures manuelles que nous traitons.
• « LocalBusiness » ou l'un de ses sous-types, sur les pages consacrées à un lieu physique, avec des coordonnées GEO et une spécification des horaires d'ouverture.

Trois éléments compromettent la validité du schéma en production : l'invention de propriétés non définies par schema.org ; l'invention de valeurs pour l'attribut « sameAs » (fausses URL LinkedIn, identifiants Twitter inactifs) ; et la transmission de graphes « Organization » contradictoires provenant de plusieurs plugins. Nous exécutons des validateurs de schéma dans le linter de compilation et interrompons la compilation dès qu'un de ces trois cas se présente.

Hreflang échoue à grande échelle car la contrainte est bidirectionnelle et l'ensemble de données est clairsemé. Chaque variante linguistique d'une page doit s'auto-référencer, doit référencer toutes les autres variantes et doit être référencée en retour par toutes les autres variantes. Il suffit qu'une seule direction fasse défaut sur une page dans une langue donnée pour que Google dégrade discrètement le cluster.

Le modèle évolutif

Enregistrez un « content_group_id » (ou équivalent) sur chaque ligne traduisible. Chaque variante linguistique d’une page partage un seul identifiant. L’émetteur hreflang, l’émetteur de plan du site et l’émetteur canonique dérivent tous leur cluster de cet identifiant. Ne calculez jamais l’attribut hreflang uniquement à partir de la correspondance de modèles d’URL, car cela ne fonctionne pas dans les cas limites (une page en espagnol qui n’a pas de traduction en hindi rompt le cluster si votre code part du principe que « si la page X existe dans la variante linguistique A, elle existe dans la variante linguistique B »).

Qu'est-ce qui nuit à l'efficacité de l'attribut hreflang dans la pratique ?

Trois erreurs que l'on observe régulièrement. L'ordre des expressions régulières de locale : placer « zh » avant « zh-Hant » dans votre expression régulière de détection de locale, ce qui capture la mauvaise locale et génère une balise `hreflang` erronée. Oublier `x-default` : chaque cluster doit disposer d'une solution de secours `x-default`, pointant généralement vers la version anglaise. Dérive de l’ID de cluster : une traduction se voit attribuer un nouvel ID au lieu d’hériter de l’ID source, ce qui divise silencieusement un cluster unique en deux clusters sans lien entre eux, dont aucun ne dispose d’un ensemble réciproque complet.

Nous intégrons systématiquement un outil de validation « hreflang » au niveau de la compilation, qui analyse un échantillon de pages, explore les groupes « hreflang » auxquels elles font référence et interrompt la compilation si un groupe s'avère incomplet ou asymétrique.

Le SEO programmatique consiste à générer des milliers de pages à partir d'une source de données structurée, d'un modèle, de répertoires, de pages de comparaison, de pages de localisation et de pages de glossaire. Bien mené, il permet de cibler la « longue traîne » à une échelle que le contenu rédigé par un seul auteur ne peut égaler. Mal mené, il déclenche une action manuelle et supprime du jour au lendemain la plupart de vos pages indexées.

Qu'est-ce qui distingue une structure programmatique soignée d'une structure au contenu pauvre ?

Trois points. Des données réelles par page : chaque URL contient au moins un fait, un chiffre ou un détail qui lui est propre ; les pages programmatiques « maigres » partagent 95 % de leur contenu. Un modèle pertinent : le modèle apporte du contexte, des comparaisons, des recommandations ou des agrégations autour des données uniques, et ne se limite pas à une simple enveloppe optimisée pour le référencement. Et un contrôle de qualité : les pages dont les données uniques sont insuffisantes sont exclues du plan du site, bloquées d’indexation ou conservées à l’état de brouillon jusqu’à ce que la couche de données soit complétée.

Ce que nous avons appris en mettant cela en œuvre à grande échelle

J’ai développé HostList.io, une plateforme de SEO programmatique comprenant des pages consacrées à plus de 30 000 hébergeurs web, sur Next.js et Supabase. Les pages qui ont résisté à deux ans de mises à jour de Google étaient celles qui comportaient au moins trois données uniques par URL, ainsi qu’un modèle permettant de comparer, de noter ou de recommander des services à partir de ces données. Les pages que nous avons désindexées étaient celles dont les données uniques se limitaient à un nom et à un prix. Le coût lié au retrait de ces pages pauvres en contenu de l’index était minime ; en revanche, les laisser dans l’index aurait entraîné une pénalité de classement à l’échelle du site lors de la mise en place de la mise à jour « Contenu utile » de mars 2024.

Nous appliquons ce guide opérationnel aux développements programmatiques de nos clients : front-end Next.js ou Astro, données Supabase ou Postgres, un pipeline d’ingestion qui évalue l’unicité des pages avant leur publication, un plan du site diffusé par tranches car plus de 50 000 URL ne peuvent pas tenir dans un seul fichier sitemap.xml, et un graphe de liens internes qui regroupe chaque page « feuille » au sein d’un cluster thématique.

Réussissez les Core Web Vitals au 75e centile des données de terrain, et non lors d'un test Lighthouse réalisé en laboratoire dans des conditions contrôlées. Google utilise les données de terrain issues de CrUX ; Lighthouse est un outil de débogage. Sur les sites réels, ces deux sources présentent souvent des écarts de 30 % ou plus.

Où va réellement l'argent du budget ?

Le LCP correspond presque toujours à l’image principale et est presque toujours résolu en réencodant au format WebP avec une qualité de 80 %, en ajustant la taille aux dimensions réelles de l’écran plus un facteur 2x pour les écrans Retina, en ajoutant une balise « preload » dans l’en-tête et en définissant « fetchpriority="high" ». Une image principale de 1 Mo réduite à 30 Ko au format WebP constitue le changement le plus impactant sur la plupart des projets. Le CLS est dû aux images et aux publicités sans dimensions explicites, à l’absence d’attributs « width » et « height » explicites sur chaque image, aux emplacements publicitaires à hauteur fixe et à l’espace réservé pour tout widget côté client. L’INP est dû à un JavaScript lourd lors des interactions, généralement un gestionnaire de balises tiers ou une bibliothèque d’analyse trop zélée. La solution consiste à appliquer un débouncing, un chargement différé ou à remplacer ces éléments par des équivalents plus légers.

Là où la plupart des projets échouent

Deux cas de figure. Premièrement, une image LCP intégrée à un composant « Carousel » ou à une mise en page pilotée par JavaScript : l’image ne s’affiche qu’une fois le code JavaScript exécuté, et votre LCP correspond alors au squelette de chargement du carrousel, et non à la photo. Deuxièmement, les polices Web chargées sans `font-display: swap` et sans préchargement : le texte reste invisible pendant 200 à 400 ms pendant le téléchargement des polices, et votre LCP dépasse le seuil de 2,5 s même si l’image s’affiche rapidement. Ces deux cas sont détectés lors d’une analyse des données de terrain CrUX, et non lors d’une simple exécution de Lighthouse.

Un linter SEO de compilation est un script qui s'exécute à la fin de votre compilation, échantillonne une partie des fichiers HTML rendus dans le répertoire de sortie et fait échouer la compilation s'il détecte des schémas susceptibles de nuire au SEO en production. C'est la pratique la plus efficace que nous intégrons aux bases de code de nos clients.

Ce que nous vérifions

• Chaque page comporte exactement une balise H1.
• La méta-description de chaque URL indexable comporte entre 120 et 155 caractères.
• L'attribut « lang » du code HTML correspond au chemin d'accès à la version locale (une page /fr/ a pour attribut lang="fr").
• Les groupes hreflang sont complets et bidirectionnels sur les itinéraires traduisibles.
• Le code JSON-LD présent sur chaque page est conforme aux définitions de schema.org.
• Pas de modèles de contenu interdits, pas de fausses URL de réseaux sociaux dans l'attribut « sameAs », pas de texte de remplacement de test codé en dur, pas de mots génériques interdits dans les textes publicitaires.
• L'URL canonique générée par le modèle correspond à l'URL canonique enregistrée dans le CMS.
• Vérification des images au format WebP et des dimensions explicites sur un échantillon de modèles.

Le linter s'exécute lors de la dernière étape de la commande « npm run build ». Toute infraction entraîne l'échec de la compilation, ce qui provoque à son tour l'échec du déploiement. Sans lui, chaque régression, chaque méta-description dépassant la limite autorisée, chaque champ SEO que quelqu'un a oublié de définir, chaque émetteur de schéma qui ne fonctionne plus suite au renommage d'une propriété, est déployée sans que personne ne s'en aperçoive. Grâce à lui, la régression est détectée avant même de quitter l'ordinateur portable du développeur.

Pour que votre page soit citée, rédigez chaque page pertinente sous forme d'une succession de passages prêts à être cités. Un passage prêt à être cité se compose d'un titre de niveau H2 formulé sous forme de question, d'une réponse directe d'une ou deux phrases qui suit immédiatement, de nuances explicatives sur les 100 à 200 mots suivants, et d'aucun contenu généré par JavaScript dans le bloc de réponse. Les outils d'extraction basés sur l'IA extraient cette phrase d'introduction et citent la page.

Ce qui aide au-delà de la structure du texte

• Autorité de l'entité, présence sur Wikipédia, schéma d'organisation cohérent, comptes « sameAs » réels, mentions de la marque sur l'ensemble du Web ouvert.
• Le fichier « llms.txt », situé à la racine du site, est une carte structurée du site destinée aux outils d'IA, distincte des fichiers « robots.txt » et « sitemap.xml » qui s'adressent aux robots d'indexation traditionnels.
• Le schéma, qui comprend les informations « À propos » et les mentions relatives au contenu long-form, définit le graphe d'entités dans lequel s'inscrit la page.
• Liste blanche du fichier robots.txt pour les robots d'indexation basés sur l'IA : autorisez explicitement GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot et Anthropic-AI. Bloquer ne serait-ce qu'un seul de ces robots entraîne une interruption de référencement dont vous seriez vous-même responsable.
• Propriété de schéma « Speakable » sur les sections riches en réponses des pages longues, indiquant aux extracteurs vocaux et d’IA qu’il s’agit d’un passage pouvant être cité.

Le suivi des citations est l'étape que la plupart des équipes négligent. Otterly, Profound et AthenaHQ suivent la part des citations d'AI Overview et de Perplexity par domaine. Nous ajoutons un suivi hebdomadaire des citations à chaque action d'engagement et le présentons parallèlement au trafic organique. Si vous ne mesurez pas les citations, vous ne pouvez pas savoir si votre travail de GEO porte ses fruits.

Les robots d'indexation basés sur l'IA ne peuvent lire votre site que si votre fichier robots.txt autorise explicitement leur agent utilisateur et si votre hébergeur ne les bloque pas au niveau de la périphérie du réseau. Ces deux conditions doivent être remplies. Les paramètres par défaut de Cloudflare, les règles par défaut du WAF de Vercel et les plugins de sécurité par défaut de WordPress bloquent systématiquement les robots d'IA sans avertissement préalable.

La liste blanche du fichier robots.txt que nous fournissons

GPTBot, ChatGPT-User et OAI-SearchBot pour les produits de recherche ChatGPT et OpenAI. PerplexityBot et Perplexity-User. ClaudeBot, Claude-Web et anthropic-ai. Google-Extended pour Bard et les synthèses d’IA. Applebot-Extended. CCBot pour Common Crawl, qui alimente de nombreux modèles open source. Cohere-AI. Meta-ExternalAgent. Bytespider, le robot d'indexation de TikTok, généralement bloqué car il est agressif et que la plupart des projets ne souhaitent pas que TikTok récupère leur contenu.

Ce que vous devez également faire

Le fichier robots.txt est nécessaire mais pas suffisant. Trois autres vérifications s’imposent. Mode « Bot Fight » et gestion des bots de Cloudflare : désactivez ceux qui bloquent les agents IA, ou ajoutez-les à la liste blanche par IP et user-agent. WAF et Edge Middleware de Vercel : assurez-vous qu’ils ne bloquent pas les user-agents IA sur la base d’une expression régulière générique. Plugins de sécurité WordPress tels que Wordfence : ils intègrent souvent par défaut des règles bloquant GPTBot et PerplexityBot ; ajoutez-les explicitement à la liste blanche. Testez en envoyant chaque agent utilisateur via curl vers trois URL représentatives et en vérifiant que la réponse est 200.

Nous construisons des fondations de SEO technique qui s'alignent sur la Norme de Service Numérique du Gouvernement britannique et le Système de Design GOV.UK. La Norme de Service GDS est l'ensemble le plus rigoureusement documenté de principes de qualité des services numériques dans le domaine public : amélioration progressive, accessibilité WCAG 2.2 AA, performance, HTML sémantique et dégradation gracieuse en cas d'échec de JavaScript. Je la suis dans chaque engagement de SEO technique.

Pourquoi cela est-il particulièrement important pour le référencement naturel (SEO) ? Les sites conformes à la norme GDS respectent systématiquement les indicateurs Core Web Vitals, obtiennent un bon classement dans les résultats naturels classiques et sont particulièrement bien adaptés aux citations dans les aperçus générés par l'IA, car la clarté structurelle exigée par la norme GDS correspond exactement à celle sur laquelle s'appuient les extraits générés par l'IA. Cette norme est antérieure à l'ère de la recherche par IA, mais s'y adapte parfaitement.

Pour les entreprises britanniques, le secteur public et les clients issus des secteurs réglementés, la conformité aux normes GDS constitue un véritable critère d'achat. Pour tous les autres, il s'agit d'un gage de qualité qui distingue ce travail de celui des agences se contentant d'un niveau d'exigence moindre.

De trois à dix semaines, trois phases, prix fixe. La première phase consiste en un audit : exploration complète du site, analyse via GSC et Ahrefs, validation JSON-LD, vérification des clusters hreflang, collecte de données sur le terrain concernant les Core Web Vitals et établissement d’une base de référence des citations par IA. La deuxième phase est consacrée à la correction : nous mettons en œuvre les corrections, que ce soit par votre équipe ou par la nôtre. La troisième phase porte sur le linter et la couche de surveillance qui empêche les régressions.

Les livrables de la phase d'audit

• Une analyse complète de Screaming Frog au format CSV, accompagnée d'un rapport écrit sur les problèmes importants, classés par ordre d'impact.
• Exportation depuis Search Console, rapport de couverture, requêtes, performances au niveau des pages, avec des annotations sur les anomalies.
• Le validateur de schéma analyse un échantillon de modèles et génère une note écrite pour chaque type qui présente une erreur ou qui est manquant.
• Rapport sur l'intégrité des groupes hreflang concernant les routes traduisibles.
• Données de terrain relatives aux Core Web Vitals issues de CrUX, accompagnées d'un graphique présentant les 25 dernières semaines pour chaque indicateur.
• Présentation générale de l'IA et référence en matière de perplexité : part de marché actuelle et analyse des écarts par rapport à trois concurrents désignés.

La phase de remise en état

Travail à périmètre défini. Chaque ticket présente clairement un état « avant » et un état « après ». Nous les livrons par ordre de priorité et vous pouvez mettre fin à la mission à n’importe quelle étape si le budget est épuisé. Le premier lot que nous livrons comprend toujours les éléments qui échouent au linter de build ; ce sont ceux qui apportent le plus rapidement de la valeur, car sans le linter, ils continueront à présenter des régressions, et une fois le linter en place, chaque correction est définitive.

La phase de suivi

Une analyse automatisée hebdomadaire des linting sur les environnements de préproduction et de production, un rapport mensuel sur les Core Web Vitals, un suivi mensuel des mentions liées à l'IA, ainsi qu'un canal Slack « maintenu actif » où je réponds à tout ce que Google ou votre équipe signale. Nous vous transférons les tableaux de bord à la fin du contrat afin que vous conserviez une visibilité, que vous renouveliez ou non.