Une SEO technique qui résiste aux Aperçus IA, aux reconstructions sans tête et à votre prochain changement d'algorithme.

Le SEO technique est la couche de travail qui détermine si les moteurs de recherche et les assistants IA peuvent crawler, renderer et faire confiance à vos pages, avant que le contenu ou les backlinks aient un effet. Elle couvre le comportement HTTP, la sémantique HTML, les données structurées, hreflang, la canonicalisation, les Core Web Vitals, et le rendu JavaScript. Si vous vous trompez, tout le reste de votre investissement devient du poids mort.

En 2026, la définition s'est élargie. Deux changements l'ont poussée. D'abord, les AI Overviews et la recherche alimentée par ChatGPT se situent maintenant entre la plupart des utilisateurs et les pages sous-jacentes, ce qui signifie que la citabilité compte autant que le classement. Deuxièmement, le site modal n'est plus une installation WordPress, c'est une sorte de front-end headless tirant du contenu de Sanity, Strapi, Payload, Storyblok, Contentful, ou un backend WordPress headless. Chacune de ces stacks introduit ses propres modes d'échec en SEO technique que l'ancien playbook ne couvre pas.

Ma définition de travail pour les clients en 2026 : le SEO technique, c'est tout ce qu'une exécution Lighthouse, un rapport de crawl Search Console, une vérification de citation AI Overview, et un validateur de schéma remarquent, dans chaque locale, chaque template, chaque chemin de rendu. Si l'un de ces quatre signaux échoue sur une URL représentative, c'est par là que l'engagement commence.

Sur un site headless ou Jamstack, votre framework front-end gère le rendu et votre CMS gère le contenu, et le SEO peut tomber dans l'écart entre eux. Le modèle classique WordPress + Yoast supposait un serveur, un renderer, une règle engine. Sortez le contenu de WordPress vers Next.js ou Astro et vous n'héritez d'aucun de cela automatiquement.

WordPress headless associé à Next.js ou Astro

La configuration la plus courante que nous voyons en 2026 : WP REST ou WPGraphQL exposant les posts et pages, Next.js App Router ou Astro les tirant au moment du build ou via ISR. Les gains sont réels, les pages se déploient sans bloat de plugin, les Core Web Vitals sont faciles à garder au vert, et les éditeurs conservent un admin familier. Les pièges sont aussi réels. Les canonicals Yoast et les méta descriptions doivent être transportés à travers la limite API ; les redirects définis dans WordPress doivent atterrir dans vercel.json ou Netlify _redirects ; les sitemaps doivent généralement être régénérés au build du front-end, pas du côté WordPress ; et la vérification Search Console doit se faire sur l'origine publique, pas le domaine wp-admin.

Stacks modernes purs

Un build Next.js + Sanity, un build Astro + Storyblok, un build Nuxt + Strapi, un build Next.js + Payload, tous contournent entièrement WordPress. Le travail de SEO technique se déplace vers la certitude que votre schéma CMS modélise les champs SEO dont le front-end a besoin (canonical override, redirect map, hreflang group, JSON d'extension de schéma), et que la revalidation à la demande se déclenche quand le contenu change. L'empoisonnement du cache ISR est le tueur silencieux, une page est servie stale pendant des heures après la publication parce que revalidatePath n'a jamais été branchée.

Ce qui casse vraiment en premier

Sur environ 200 audits headless que nous avons réalisés, le problème de production le plus courant est le conflit canonical, le front-end émettant une URL canonical tandis que les métadonnées CMS ou le sitemap en émet une autre. Google en choisit une, presque toujours pas celle que vous vouliez, et la mauvaise URL se retrouve dans l'index. Nous l'attrapons avec un linter au moment du build qui compare canonical-émis-depuis-le-template par rapport à canonical-stocké-dans-le-CMS pour un échantillon de pages et échoue le build en cas de décalage.

WordPress vous donne la plus grande puissance de plugin et la plupart des façons de vous tirer une balle. Le playbook de SEO technique sur un site WordPress classique consiste surtout à soustraire, en supprimant les canonicals dupliqués, en tuant les conflits de schéma entre Yoast et RankMath et un tiers plugin dont personne ne se souvient d'avoir installé, en apprivoisant les page builders qui livrent 2 MB de CSS, et en nettoyant les chaînes de redirects qui se sont accumulées pendant huit ans.

Le stack par défaut que nous recommandons en 2026 : un seul plugin SEO (RankMath ou Yoast, jamais les deux), un hébergement géré avec bon caching edge (Cloudways, Kinsta, WP Engine), Bricks Builder pour les nouvelles compilations où la performance compte ou Gutenberg natif avec Kadence ou Blocksy, un gestionnaire de redirection qui exporte dans un format portable, et Perfmatters ou FlyingPress pour le nettoyage des assets. Le travail d'audit consiste à déterminer laquelle de ces décisions a été prise différemment sur votre site et à défaire les conséquences.

Du côté headless, le travail passe de la soustraction à la construction. Il n'y a pas de Yoast, donc la limite de méta doit être construite. Il n'y a pas de schéma de plugin, donc du JSON-LD doit être templé. Il n'y a pas de sitemap intégré, donc il doit être généré et streamisé. Le volume de code que nous ajoutons à un projet headless pour le SEO est généralement trois à cinq fois ce qu'un site WordPress vous donne déjà gratuitement, mais ce code est possédé, versionné, testable, et ne casse pas à la mise à jour du plugin suivant.

GEO et AEO sont les noms de deux façons différentes dont les fonctionnalités IA consomment le trafic de recherche. AEO (Answer Engine Optimisation) est le terme plus ancien, il couvre les fonctionnalités Google comme les Extraits en vedette, Questions similaires et Panneaux de connaissances qui extraient un passage de votre page et l'affichent comme réponse. GEO (Generative Engine Optimisation) est le terme plus récent, optimisant pour les Aperçus IA, ChatGPT search, Perplexity et Bing Copilot, où l'assistant génère un paragraphe et cite votre page comme source.

Ce que cela signifie structurellement

Les deux surfaces veulent la même chose : un passage prêt à être cité. Les règles structurelles qui gagnent sur tous les fronts sont les mêmes. Utilisez une question comme titre H2, pas une étiquette de sujet. Mettez la réponse dans les une ou deux premières phrases après le titre. Gardez cette réponse sous 250 mots. Assurez-vous que la réponse est rendue côté serveur, pas à l'intérieur d'un composant JavaScript qui s'hydrate après le chargement de la page. Les crawlers IA et les extracteurs Google n'exécutent généralement pas JavaScript, si votre réponse a besoin de JS pour apparaître, vous êtes invisible.

Où GEO diverge d'AEO

Trois choses importent davantage pour GEO spécifiquement. L'autorité d'entité, Google et les LLM construisent un graphe de qui est autorisé à parler de quoi, et les mentions de marque non liées l'alimentent. Schema avec des tableaux about et mentions, ils rendent votre page analysable comme faisant partie d'un graphe d'entité plutôt que comme un mur de texte. Et llms.txt, un fichier standard émergent à /llms.txt qui donne aux outils IA une carte curée de votre site, de la même façon que robots.txt et sitemap.xml aident les crawlers de recherche. Nous déployons llms.txt sur chaque site que nous construisons et le mettons à jour chaque fois qu'une page majeure arrive.

Vous avez besoin de moins de types de schema que la plupart des plugins émettent, mais ceux que vous livrez doivent être valides et cohérents. Une courte liste couvre neuf projets sur dix.

• Organization, un seul graphe sitewide dans votre mise en page, avec logo, sameAs (uniquement les vrais comptes sociaux), adresse et contactPoint. Ne dupliquez jamais ceci par page.
• WebSite, une seule fois, dans la mise en page, avec potentialAction pour la recherche de sitelinks si vous disposez d'une recherche sur site.
• BreadcrumbList, sur chaque page non-accueil, avec des URL locale-correct (une page française doit pointer vers les ancêtres /fr/, pas /en/).
• Article ou BlogPosting, sur le contenu long-forme, avec des tableaux about et mentions pour le renforcement du graphe d'entité.
• Service, sur les pages commerciales, avec serviceType, provider, areaServed, audience et offers.priceSpecification quand vous pouvez publier une gamme de prix.
• Product, sur l'e-commerce, avec offers.priceCurrency, availability et aggregateRating uniquement si vous avez de vrais avis.
• FAQPage, quand il y a au moins deux questions véritables sur la page. Inventer des FAQ pour gagner du balisage de schéma est le déclencheur d'action manuelle le plus courant que nous nettoyons.
• LocalBusiness ou l'un de ses sous-types, sur les pages de localisation physique, avec coordonnées géographiques et openingHoursSpecification.

Trois choses tuent le schéma en production. Inventer des propriétés que schema.org ne définit pas. Inventer des valeurs pour sameAs (fausses URL LinkedIn, comptes Twitter abandonnés). Et déployer des graphes Organization en conflit provenant de plusieurs plugins. Nous exécutons des validateurs de schéma dans le linter de build et échouons le build sur l'un de ces trois modèles.

Hreflang échoue à grande échelle parce que la contrainte est bidirectionnelle et l'ensemble de données est clairsemé. Chaque variante locale d'une page doit s'auto-référencer, doit référencer chaque autre variante, et doit être référencée en retour par chaque autre variante. Manquez une direction sur une page dans une locale et Google rétrograde silencieusement le cluster.

Le modèle qui scale

Stockez un content_group_id (ou équivalent) sur chaque ligne traductible. Chaque variante de locale d'une page partage un ID. L'émetteur hreflang, l'émetteur sitemap et l'émetteur canonical dérivent tous leur cluster de cet ID. Ne calculez jamais hreflang à partir de la correspondance de motif d'URL seule, cela s'effondre sur les cas limites (une page espagnole qui n'a pas de traduction en hindi casse le cluster si votre code suppose « si pageX existe en locale A, elle existe en locale B »).

Ce qui tue hreflang en pratique

Trois motifs que nous voyons régulièrement. Classement des regex de locale, placer « zh » avant « zh-Hant » dans votre regex de détection de locale, qui capture la mauvaise locale et écrit un hreflang cassé. Oublier x-default, chaque cluster a besoin d'un fallback x-default, généralement pointant vers la version anglaise. Déviation d'ID de cluster, une traduction obtient un nouvel ID au lieu d'hériter de l'ID source, divisant silencieusement un seul cluster en deux clusters non apparentés, dont aucun n'a un ensemble réciproque complet.

Nous ajoutons toujours un linter hreflang au moment du build qui crawle un échantillon de pages, parcourt les clusters hreflang qu'elles référencent, et échoue le build si un cluster est incomplet ou asymétrique.

Le SEO programmatique génère des milliers de pages à partir d'une source de données structurées plus un template, des répertoires, des pages de comparaison, des pages de localisation, des pages de glossaire. Fait correctement, cela peut atteindre la longue traîne à une échelle qu'un contenu d'auteur unique ne peut pas égaler. Fait incorrectement, cela déclenche une action manuelle et supprime la plupart de vos pages indexées du jour au lendemain.

Ce qui sépare un build programmatique propre d'un contenu mince

Trois choses. Des données réelles par page, chaque URL a au moins un fait, un nombre ou un détail unique à elle ; les pages programmatiques fines partagent 95 % de leur contenu. Un template significatif, le template ajoute du contexte, de la comparaison, de la recommandation ou de l'agrégation autour des données uniques, pas juste un wrapper optimisé pour la recherche. Et la gestion de la qualité, les pages avec des données uniques insuffisantes sont maintenues en dehors de la sitemap, bloquées de l'index ou conservées en état de brouillon jusqu'à ce que la couche de données se remplisse.

Ce que nous avons appris en exploitant cela à l'échelle

J'ai construit HostList.io comme plateforme de SEO programmatique avec environ 28 000 pages de sociétés d'hébergement web sur Next.js plus Supabase. Les pages qui ont survécu à deux ans de mises à jour Google étaient celles avec au moins trois points de données uniques par URL plus un template qui comparait, notait ou recommandait en plus de ces données. Les pages que nous avons désindexées étaient celles où les données uniques n'étaient que un nom et un prix. Le coût de retirer les pages fines de l'index était faible ; le coût de les laisser était une pénalité de classement à l'échelle du site quand la mise à jour contenu utile de mars 2024 est arrivée.

Nous apportons ce playbook d'exploitation aux constructions programmatiques des clients, front-end Next.js ou Astro, données Supabase ou Postgres, un pipeline d'ingestion qui évalue les pages sur leur unicité avant publication, une sitemap qui s'écoule par chunks parce que plus de 50 000 URL ne peuvent pas tenir dans un seul sitemap.xml, et un graphe de lien interne qui tire chaque feuille dans un cluster thématique.

Passer les Core Web Vitals au 75e percentile des données de terrain, pas dans une exécution Lighthouse contrôlée en laboratoire. Les données de terrain de CrUX sont ce que Google utilise ; Lighthouse est un outil de débogage. Les deux divergent souvent de 30 % ou plus sur les sites réels.

OÙ VA RÉELLEMENT LE BUDGET

LCP est presque toujours l'image du héros et presque toujours résolu en réencodant vers WebP à 80 % de qualité, en dimensionnant aux dimensions d'affichage réelles plus 2x retina, en ajoutant une balise preload dans la head et en définissant fetchpriority="high". Une image héros de 1 MB devenant un WebP de 30 KB est le changement à l'impact unique le plus élevé sur la plupart des projets. CLS provient d'images et de publicités sans dimensions explicites, des attributs width et height explicites sur chaque image, des emplacements de publicité à hauteur fixe et de l'espace réservé pour tout widget côté client. INP provient d'un JavaScript lourd sur interaction, généralement un gestionnaire de balises tiers ou une bibliothèque d'analyse trop zélée. La correction consiste à débouncer, lazy-loader ou remplacer par un équivalent plus léger.

OÙ LA PLUPART DES PROJETS ÉCHOUENT

Deux motifs. Premièrement, une image LCP à l'intérieur d'un composant Carousel ou une mise en page pilotée par JavaScript, l'image ne s'affiche qu'après l'exécution du JS, et votre LCP est le skeleton de chargement du carousel, pas la photo. Deuxièmement, les polices web chargées sans font-display: swap et sans preload, le texte est invisible pendant 200-400 ms pendant le téléchargement des polices, et votre LCP est repoussé au-delà du seuil de 2,5 s bien que l'image soit rapide. Les deux sont détectés par un examen des données de champ CrUX, pas une seule exécution de Lighthouse.

Un linter SEO au moment de la build est un script qui s'exécute à la fin de votre build, échantillonne une tranche de fichiers HTML rendus depuis le répertoire de sortie, et fait échouer la build s'il trouve des patterns qui dégradaient le SEO en production. C'est l'habitude à plus haut impact unique que nous ajoutons aux codebases clients.

Ce que nos vérifications contrôlent

• Chaque page a exactement une balise H1.
• La meta description sur chaque URL indexable fait entre 120 et 155 caractères.
• L'attribut html lang correspond au chemin de la locale (une page /fr/ a lang="fr").
• Les clusters hreflang sont complets et bidirectionnels sur les routes traduisibles.
• Le JSON-LD sur chaque page est valide selon les définitions de schema.org.
• Aucun motif de contenu interdit, fausses URL de réseau social dans sameAs, texte d'espace réservé de test codé en dur, mots de copywriting génériques interdits.
• L'URL canonique émise par le template correspond à l'URL canonique stockée dans le CMS.
• Contrôle WebP et dimensions explicites sur un échantillon de templates.

Le linter s'exécute à la dernière étape de npm run build. Toute violation échoue la compilation, ce qui échoue le déploiement. Sans lui, chaque régression, une meta description qui a augmenté au-delà de la limite, un champ SEO que quelqu'un a oublié de définir, un émetteur de schema qui s'est cassé quand une propriété a été renommée, s'expédie silencieusement. Avec lui, la régression est détectée avant de quitter l'ordinateur portable du développeur.

Faites-vous citer en rédigeant chaque page pertinente comme une pile de passages prêts à être cités. Un passage prêt à être cité est un H2 sous forme de question, une réponse directe d'une ou deux phrases immédiatement après, des nuances de soutien pour les 100-200 mots suivants, et zéro contenu rendu en JavaScript dans le bloc de réponse. Les extracteurs IA récupèrent cette première phrase et citent la page.

Ce qui aide au-delà de la structure des passages

• Autorité d'entité, présence Wikipedia, schéma organisation cohérent, comptes sameAs authentiques, mentions de marque sur l'ensemble du web ouvert.
• llms.txt à la racine du site, une carte organisée du site pour les outils IA, distincte du robots.txt et du sitemap.xml qui servent les crawleurs traditionnels.
• Schéma avec about et mentions dans le contenu long format, qui déclare le graphe d'entité dans lequel la page s'inscrit.
• Liste de permissions robots.txt pour crawleurs IA, autoriser explicitement GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot et Anthropic-AI. Bloquer ne serait-ce qu'un seul de ces bots provoque une perte de citations auto-infligée.
• Propriété schéma speakable sur les sections riches en réponses des pages long format, un signal aux extracteurs vocaux et IA indiquant que c'est un passage citable.

Le suivi des citations est la partie que la plupart des équipes ignorent. Otterly, Profound et AthenaHQ suivent la part des citations d'Aperçu IA et Perplexity par domaine. Nous ajoutons un suivi hebdomadaire des citations en plus de chaque engagement et le signalons aux côtés du trafic organique. Si vous ne mesurez pas les citations, vous ne pouvez pas dire si votre travail GEO fait quelque chose.

Les crawlers IA ne peuvent lire votre site que si votre robots.txt autorise explicitement leur user-agent et que votre couche d'hébergement ne les bloque pas à la périphérie du réseau. Les deux vérifications doivent réussir. Les paramètres Cloudflare par défaut, les règles WAF Vercel par défaut et les plugins de sécurité WordPress par défaut bloquent régulièrement les bots IA sans avertissement.

La liste d'autorisation robots.txt que nous fournissons

GPTBot et ChatGPT-User et OAI-SearchBot pour les produits ChatGPT et OpenAI search. PerplexityBot et Perplexity-User. ClaudeBot et Claude-Web et anthropic-ai. Google-Extended pour Bard et AI Overviews. Applebot-Extended. CCBot pour Common Crawl, qui alimente de nombreux modèles open source. Cohere-AI. Meta-ExternalAgent. Bytespider, le crawler de TikTok, généralement bloqué car agressif et la plupart des projets ne veulent pas que TikTok reprenne leur contenu.

Ce que vous devez également faire

Robots.txt est nécessaire mais insuffisant. Trois autres vérifications. Mode bot fight Cloudflare et bot management, désactiver ceux qui bloquent les agents IA, ou les ajouter à la whitelist par IP et user-agent. Vercel WAF et Edge Middleware, s'assurer qu'ils ne correspondent pas aux user-agents IA sur une regex générique. Plugins de sécurité WordPress comme Wordfence, ils livrent souvent des règles qui bloquent GPTBot et PerplexityBot par défaut ; ajouter explicitement à la whitelist. Tester en effectuant un curl de chaque user-agent contre trois URLs représentatives et confirmer une réponse 200.

Nous construisons des fondations de SEO technique alignées sur le UK Government Digital Service Standard et le GOV.UK Design System. Le GDS Service Standard est l'ensemble le plus rigoureusement documenté de principes de qualité pour les services numériques dans le domaine public : amélioration progressive, accessibilité WCAG 2.2 AA, performance, HTML sémantique et dégradation élégante en cas d'échec de JavaScript. Nous le respectons à chaque engagement de SEO technique chez Seahawk.

Pourquoi cela compte spécifiquement pour le SEO : les sites alignés sur GDS passent les Core Web Vitals de manière cohérente, se classent bien en recherche organique classique, et sont particulièrement bien adaptés aux AI Overview citations, car la clarté structurelle exigée par GDS est la même clarté structurelle que les extracteurs de contenu IA utilisent. Le standard précède l'ère de la recherche par IA mais s'y adapte parfaitement.

Pour les clients du secteur public britannique, les entreprises et les industries réglementées, l'alignement GDS est un vrai signal d'appels d'offres. Pour tous les autres, c'est un marqueur de qualité qui distingue le travail des agences qui livrent à un standard inférieur.

Trois à dix semaines, trois phases, tarif fixe. La phase un est l'audit, crawl complet, examen GSC et Ahrefs, validation JSON-LD, vérification du cluster hreflang, extraction des données de terrain Core Web Vitals, ligne de base des citations IA. La phase deux est la correction, nous déployons les fixes, votre équipe ou la nôtre. La phase trois est la couche linter et monitoring qui prévient les régressions.

Les livrables de la phase d'audit

• Crawl complet Screaming Frog en CSV plus un brief écrit sur les problèmes importants, classés par impact.
• Export Search Console, rapport de couverture, requêtes, performances au niveau des pages, avec annotations sur ce qui est anormal.
• Passage du validateur de schema sur un échantillon de templates et une note écrite sur chaque type qui est cassé ou absent.
• Rapport d'intégrité du cluster hreflang sur les routes traduisibles.
• Extraction de données terrain des Core Web Vitals depuis CrUX avec un graphique des 25 dernières semaines par métrique.
• Ligne de base AI Overview et Perplexity citations, part actuelle, analyse des lacunes par rapport à trois concurrents nommés.

La phase de correction

Travail à périmètre fixe. Chaque ticket a un état avant et un état après bien définis. Nous les livrons par ordre de priorité et vous pouvez arrêter l'engagement à n'importe quel jalon si le budget s'épuise. Le premier lot que nous livrons concerne toujours les éléments qui échouent au linter de build, car ils offrent le chemin le plus court vers la valeur puisqu'ils régresseront continuellement sans le linter, et une fois que le linter est en place, chaque correction reste stable.

La phase de monitoring

Linting automatisé hebdomadaire sur staging et production, rapport Core Web Vitals mensuel, suivi des citations IA mensuel, et un canal Slack tenu actif où je réponds à tout ce que Google ou votre équipe signale. Nous vous transférons les tableaux de bord à la fermeture afin que vous conserviez la visibilité que vous la renouveliez ou non.