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

La SEO technique est la couche de travail qui détermine si les moteurs de recherche et les assistants IA peuvent crawler, afficher 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. Faites erreur et le reste de votre investissement est du lest mort.

En 2026 la définition s'est élargie. Deux changements l'ont poussée. D'abord, les Aperçus IA et la recherche alimentée par ChatGPT se situent désormais entre la plupart des utilisateurs et les pages sous-jacentes, ce qui signifie que la citabilité compte autant que le classement. Ensuite, le site modal n'est plus une installation WordPress — c'est une version quelconque d'interface sans tête tirant le contenu de Sanity, Strapi, Payload, Storyblok, Contentful ou un backend WordPress sans tête. Chacune de ces piles introduit ses propres modes de défaillance SEO technique que l'ancien playbook ne couvre pas.

Ma définition de travail pour les clients en 2026 : la SEO technique est tout ce qu'un passage Lighthouse, un rapport d'exploration Search Console, une vérification de citation Aperçu IA et un validateur de schéma remarquent — sur chaque locale, chaque template, chaque chemin de rendu. Si l'un de ces quatre signaux échoue sur une URL représentative, l'engagement commence là.

Sur un site headless ou Jamstack, votre framework front-end gère le rendu et votre CMS gère le contenu — et l'SEO peut tomber dans le vide entre les deux. Le modèle classique WordPress + Yoast supposait un serveur, un moteur de rendu, un moteur de règles unique. Extrayez le contenu de WordPress vers Next.js ou Astro et vous n'hériterez d'aucun de ces mécanismes automatiquement.

WordPress headless associé à Next.js ou Astro

La configuration la plus courante que nous voyons en 2026 : WP REST ou WPGraphQL expose les articles et pages, Next.js App Router ou Astro les récupère au moment de la compilation ou via ISR. Les gains sont réels — les pages se déploient sans surcharge de plugins, les Core Web Vitals restent faciles à maintenir au vert, et les éditeurs gardent un admin familier. Les pièges sont aussi réels. Les canoniques Yoast et les méta-descriptions doivent être transportés au-delà de la limite de l'API ; les redirections définies dans WordPress doivent se retrouver dans vercel.json ou Netlify _redirects ; les sitemaps doivent généralement être régénérés à la compilation front-end, pas du côté WordPress ; et la vérification de la Search Console doit se faire sur l'origine publique, pas le domaine wp-admin.

Stacks modernes purs

Une compilation Next.js + Sanity, une compilation Astro + Storyblok, une compilation Nuxt + Strapi, une compilation Next.js + Payload — toutes contournent WordPress entièrement. Le travail d'SEO technique se déplace vers l'assurance que votre schéma CMS modélise les champs SEO dont le front-end a besoin (override canonical, carte de redirection, groupe hreflang, JSON d'extension schema), et vers l'assurance 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 périmée pendant des heures après la publication parce que revalidatePath n'a jamais été câblée.

Ce qui casse vraiment en premier

Au cours d'environ 200 audits headless que nous avons menés, le problème de production le plus courant est le conflit de canonical — le front-end émettant une URL canonical alors que les métadonnées CMS ou le sitemap en émettent une autre. Google en choisit une, presque jamais celle que vous vouliez, et la mauvaise URL finit par être indexée. Nous détectons cela avec un linter au moment de la compilation qui compare le canonical émis par le template par rapport au canonical stocké dans le CMS pour un échantillon de pages et échoue la compilation en cas de divergence.

WordPress vous confère la plus grande puissance de plugins et le plus de façons de vous tirer une balle. La stratégie d'SEO technique sur un site WordPress classique consiste surtout à soustraire — supprimer les canoniques dupliqués, éliminer les conflits de schema entre Yoast et RankMath et un troisième plugin dont personne ne se souvient l'avoir installé, dompter les page builders qui livrent 2 MB de CSS, et dégager les chaînes de redirection 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 limitation des meta doit être construite. Il n'y a pas de schema de plugin, donc JSON-LD doit être templé. Il n'y a pas de sitemap intégré, donc il faut le générer et le streamer. 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 est possédé, versionné, testable, et ne casse pas à la prochaine mise à jour de plugin.

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 ancien — il couvre les fonctionnalités Google comme les Extraits vedettes, Les gens demandent aussi, et les Panneaux de connaissances qui extraient un passage de votre page et l'affichent comme la réponse. GEO (Generative Engine Optimisation) est le terme nouveau — optimiser pour AI Overviews, 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 pour citation. Les règles structurelles qui gagnent sur tous les fronts sont les mêmes. Utilisez une question comme votre H2, pas une étiquette de sujet. Mettez la réponse dans la première ou deuxième phrase 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 ne lancent 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 spécifiquement pour GEO. L'autorité d'entité — Google et les LLMs 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 qu'un mur de texte. Et llms.txt — un fichier standard émergent à /llms.txt qui donne aux outils IA une carte organisé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 graphe unique au niveau du site dans votre mise en page, avec logo, sameAs (uniquement les vrais comptes sociaux), address, 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 avez une recherche sur site.
• BreadcrumbList — sur chaque page non-accueil, avec des URL correctes selon la locale (une page française doit pointer vers les ancêtres /fr/, pas /en/).
• Article ou BlogPosting — sur le contenu long format, avec les tableaux about et mentions pour le renforcement du graphe d'entités.
• Service — sur les pages commerciales, avec serviceType, provider, areaServed, audience, et offers.priceSpecification quand vous pouvez publier une plage de prix.
• Product — sur l'e-commerce, avec offers.priceCurrency, availability, et aggregateRating seulement si vous avez de vrais avis.
• FAQPage — quand il y a au moins deux questions authentiques sur la page. Inventer des FAQ pour remporter le 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 les 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 traduisible. Chaque variante locale d'une page partage un seul ID. L'émetteur hreflang, l'émetteur de sitemap et l'émetteur de canonical dérivent tous leur cluster de cet ID. Ne calculez jamais hreflang à partir du seul appariement de motifs d'URL — cela s'effondre sur les cas limites (une page espagnole qui n'a pas de traduction hindi casse le cluster si votre code suppose « si pageX existe dans la locale A, elle existe dans la locale B »).

Ce qui tue hreflang en pratique

Trois motifs que nous voyons se répéter régulièrement. L'ordre des regex de locale — mettre « zh » avant « zh-Hant » dans votre regex de détection de locale, ce 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. Cluster ID drift — une traduction reçoit un nouvel ID au lieu d'hériter de l'ID source, divisant silencieusement un seul cluster en deux indépendants, 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 consiste à générer des milliers de pages à partir d'une source de données structurées plus un template — annuaires, pages de comparaison, pages de localisation, 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 chiffre ou un détail qui lui est unique ; les pages programmatiques minces 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, et non juste une enveloppe optimisée pour la recherche. Et un contrôle de qualité — les pages avec des données uniques insuffisantes sont exclues du 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 opérationnel aux constructions programmatiques clients — front-end Next.js ou Astro, données Supabase ou Postgres, un pipeline d'ingestion qui note les pages sur l'unicité avant la publication, un sitemap qui stream par chunks parce que plus de 50 000 URLs ne peuvent pas tenir dans un seul sitemap.xml, et un graphique 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 de héros et presque toujours résolu par un ré-encodage en WebP à 80 % de qualité, dimensionné aux dimensions réelles d'affichage plus 2x retina, ajout d'une balise preload dans le head, et définition de fetchpriority="high". Une image de héros de 1 MB devenant 30 KB de WebP est le changement à plus haut impact unique sur la plupart des projets. CLS provient des images et des annonces sans dimensions explicites — attributs width et height explicites sur chaque image, emplacements d'annonces à hauteur fixe, et espace réservé pour tout widget côté client. INP provient du JavaScript lourd à l'interaction — généralement un gestionnaire de balises tiers ou une bibliothèque d'analytics trop enthousiaste. La correction est le debouncing, le lazy-loading, ou le remplacement par un équivalent plus léger.

OÙ LA PLUPART DES PROJETS ÉCHOUENT

Deux patterns. Première, une image LCP dans un composant Carousel ou une mise en page pilotée par JavaScript — l'image ne s'affiche que après l'exécution du JS, et votre LCP est le squelette de chargement du carousel, pas la photo. Deuxième, des web fonts chargées sans font-display: swap et sans preload — le texte est invisible pendant 200-400 ms pendant le téléchargement des fonts, et votre LCP est poussé au-delà du seuil de 2,5 s même si l'image est rapide. Les deux sont détectés par un examen des données de terrain de CrUX, pas une seule exécution 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 URLs de réseaux sociaux dans sameAs, texte d'espace réservé en dur pour les tests, mots de copywriting générique 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 arrête la compilation, ce qui arrête le déploiement. Sans lui, chaque régression — une meta description qui a dépassé la limite, un champ SEO que quelqu'un a oublié de remplir, un émetteur de schema qui s'est cassé quand une propriété a été renommée — se déploie silencieusement. Avec lui, la régression est détectée avant de quitter l'ordinateur 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 d'organisation cohérent, vrais comptes sameAs, 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, séparée du robots.txt et du sitemap.xml qui servent les crawlers traditionnels.
• Schéma avec about et mentions sur le contenu long format — déclare le graphe d'entité dans lequel la page s'insère.
• Liste d'autorisation robots.txt pour les crawlers IA — autorisez explicitement GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot et Anthropic-AI. Bloquer ne serait-ce qu'un seul d'entre eux est une panne de citation auto-infligée.
• Propriété speakable schema sur les sections riches en réponses des pages long format — un indice pour les extracteurs vocaux et IA selon lequel c'est le 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é parce qu'il est agressif et que la plupart des projets ne veulent pas que TikTok réutilise leur contenu.

Ce que vous devez également faire

Robots.txt est nécessaire mais insuffisant. Trois autres vérifications. Mode de lutte contre les bots Cloudflare et gestion des bots — désactivez ceux qui bloquent les agents IA, ou créez une liste blanche par IP et user-agent. WAF Vercel et Edge Middleware — assurez-vous 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 ; créez une liste blanche explicitement. Testez en interrogeant chaque user agent sur trois URL représentatives et en confirmant 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.Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

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 de GSC et Ahrefs, validation JSON-LD, vérification du cluster hreflang, extraction des données de terrain Core Web Vitals, baseline de citation IA. La phase deux est la remédiation — nous livrons les corrections, 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, performance au niveau de la page — 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.
• Vue d'ensemble IA et référence de citation Perplexity — 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 initial et un état final clairement définis. Nous les déployons 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 déployons concerne toujours les éléments qui échouent la vérification du linter — ils ont le chemin le plus court vers la valeur parce qu'ils vont régresser sans le linter, et une fois le linter 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.