SEO, GEO et moteurs IA en 2026 : ce qui change vraiment pour un site professionnel

SEO, GEO et AEO : trois termes, un socle commun

Les termes décrivent des objectifs voisins, pas trois algorithmes universels.

Le SEO organise la découverte, l’exploration, l’indexation et la pertinence d’un site dans les moteurs de recherche. Le GEO, pour Generative Engine Optimization, s’intéresse à la manière dont une source peut être retrouvée et utilisée dans une réponse générative. L’AEO, pour Answer Engine Optimization, vise plus largement les réponses directes, qu’elles soient générées ou non.

Ces définitions sont utiles pour répartir le travail, mais elles ne créent pas une méthode identique chez tous les éditeurs. Google explique dans son guide officiel, mis à jour le 10 juillet 2026 que ses fonctionnalités génératives restent ancrées dans ses systèmes de classement et de qualité. Les pratiques SEO solides restent donc pertinentes.

La bonne question n’est pas « quel acronyme choisir ? », mais « l’information est-elle accessible, originale, attribuable et utile à la bonne intention ? ». Une page techniquement parfaite mais générique apporte peu. Une excellente analyse bloquée par le serveur reste invisible. Le travail doit tenir les deux côtés.

Ce qui change dans Google et ce qui ne change pas

Les réponses génératives ajoutent une présentation et des parcours, sans abolir les conditions d’éligibilité de Search.

Google décrit une recherche augmentée par récupération : ses systèmes peuvent retrouver des pages de l’index, explorer plusieurs sous-questions et présenter des liens de soutien. Pour un propriétaire de site, cela renforce l’importance d’un contenu indexable, autorisé à produire un extrait, bien relié et suffisamment distinct pour répondre à une partie précise du besoin.

Le même guide déconseille de poursuivre des « hacks » propres au GEO sans preuve. Il cite notamment le découpage artificiel, les fichiers spéciaux supposés indispensables ou les mentions inauthentiques. Une page peut rester simple : un titre honnête, une réponse directe, une structure lisible, des preuves, des limites et une prochaine étape.

En juin 2026, Google a annoncé des rapports dédiés à la visibilité dans les fonctionnalités génératives de Search Console, d’abord déployés auprès d’un sous-ensemble de sites. Il faut donc vérifier la disponibilité réelle dans la propriété concernée. En leur absence, les rapports Search classiques, les pages d’arrivée et les conversions restent nécessaires.

Comment ChatGPT et Perplexity peuvent découvrir une page

Chaque éditeur documente des agents distincts ; robots.txt et le pare-feu doivent être lus ensemble.

OpenAI distingue OAI-SearchBot, utilisé pour faire apparaître des sites dans les fonctions de recherche de ChatGPT, de GPTBot, associé à l’exploration susceptible de contribuer aux modèles de fondation. Les réglages robots.txt sont indépendants. Autoriser la recherche n’impose donc pas d’autoriser le même choix pour l’entraînement.

Perplexity documente PerplexityBot comme un robot destiné à faire émerger et lier des sites dans ses résultats. Sa documentation publie aussi des plages IP et distingue Perplexity-User, déclenché dans le contexte d’une action utilisateur. Ces précisions peuvent évoluer ; elles doivent être revérifiées avant toute règle de pare-feu.

Un fichier robots.txt permissif ne suffit pas si un CDN, un WAF, une extension de sécurité, une limite de débit ou une erreur serveur refuse la requête. Inversement, une réponse HTTP 200 à un user-agent écrit à la main ne prouve pas l’identité du robot. Une procédure complète doit aussi vérifier les plages IP officielles, les journaux serveur et les règles du pare-feu.

Cas pratique OAI-SearchBot : protocole en attente d’investigation serveur

Cette section prépare le protocole sans transformer un test curl en preuve concernant le véritable robot OpenAI.

Le 12 juillet 2026, un essai HTTP/1.1 a déclaré le user-agent OAI-SearchBot depuis une adresse IP qui n’a pas été vérifiée comme appartenant aux plages officielles d’OpenAI. La connexion a été réinitialisée avant l’obtention d’un code HTTP. Cette observation décrit seulement le comportement de cette requête ; elle ne permet pas de conclure que le véritable robot OpenAI est bloqué.

Le cas pratique restera méthodologique tant que les journaux o2switch, l’adresse source, la règle ayant provoqué le reset et un nouveau test après éventuelle correction n’auront pas été examinés. Aucune modification d’hébergement ou de pare-feu n’est attribuée à ce contenu.

Les prérequis techniques à contrôler avant d’écrire davantage

L’audit commence par les accès et les URL de référence, pas par un volume supplémentaire de contenu.

Chaque page importante doit répondre correctement, avoir une canonical cohérente, rester accessible sans connexion et exposer son contenu principal dans un HTML interprétable. Le sitemap facilite la découverte, mais il ne corrige pas une page bloquée, dupliquée ou vide. Le noindex, les en-têtes X-Robots-Tag et les règles du serveur doivent être examinés séparément de robots.txt.

Les liens internes donnent un contexte. Une page de service devrait renvoyer vers un guide qui explique le problème ; le guide devrait proposer une suite naturelle vers la page de service, l’auteur et des contenus complémentaires. Cette circulation sert d’abord le lecteur et évite les articles orphelins.

Les images importantes doivent être accessibles, dimensionnées et accompagnées d’un texte alternatif fidèle. Le mobile, le clavier, les titres et les formulaires font partie de la qualité de la page. Ces points améliorent l’usage ; il serait excessif de prétendre qu’un contrôle isolé déclenche une citation.

• HTTP 200 sur l’URL canonique et absence de chaîne de redirection.
• Robots meta, X-Robots-Tag et robots.txt cohérents.
• Contenu principal et liens présents sans interaction obligatoire.
• Sitemap limité aux URL réellement publiées et indexables.
• Journaux serveur consultables pour diagnostiquer les refus.
• Performance et accessibilité vérifiées sur mobile.

Construire un contenu original dont l’auteur est identifiable

Une source utile apporte plus qu’une reformulation et permet de vérifier qui assume le contenu.

Google recommande des contenus utiles, fiables et destinés d’abord aux personnes. Pour un site professionnel, l’originalité peut prendre une forme modeste mais concrète : une checklist issue d’un audit, un test daté, un exemple de code exécuté, une comparaison expliquée ou une erreur documentée. Ajouter des paragraphes génériques n’augmente pas automatiquement la valeur.

L’auteur doit être visible avec une page distincte de la présentation de l’agence. Une page auteur répond à « qui écrit et selon quelle méthode ? » ; la page L’agence répond à « qu’est-ce que WeWorkWeb et comment travaille-t-elle ? ». Les articles relient la signature à une même entité Person au moyen d’un identifiant stable.

Les données structurées Article, Person et Organization rendent ces relations explicites si elles correspondent au contenu affiché. Elles ne doivent contenir ni qualification inventée, ni profil non confirmé, ni résultat absent de la page. Une page auteur utile expose ce modèle dans le contenu visible sans confondre balisage et preuve.

Mesurer la visibilité sans réduire le sujet au trafic

Une impression, une citation, une session et une demande sont quatre événements différents.

Search Console renseigne la présence dans Google, avec des rapports génératifs lorsque ceux-ci sont disponibles. L’analytics décrit les sessions et les actions observées sur le site. Les journaux serveur montrent certaines requêtes techniques. Un suivi manuel de questions peut enfin documenter une citation, à condition de conserver la date, la formulation, le produit et le lien affiché.

OpenAI indique dans sa FAQ destinée aux éditeurs que les liens de référence ChatGPT Search incluent automatiquement utm_source=chatgpt.com. Ce signal facilite une partie de l’analyse, mais toutes les visites issues d’une application, d’une copie d’URL ou d’une redirection ne seront pas nécessairement attribuées de la même façon.

Le tableau mensuel devrait relier les pages d’arrivée aux clics vers une offre, aux formulaires commencés et aux formulaires envoyés. Il doit aussi conserver la définition des sources observées et les changements d’instrumentation. L’objectif est de décider quoi améliorer, pas de fabriquer un score unique.

Un plan d’action réaliste pour un site professionnel

On corrige d’abord l’éligibilité et les pages décisives, puis on publie et on observe.

Pour partir d’un état réel plutôt que d’une promesse, l’audit de visibilité WeWorkWeb peut servir à prioriser la structure, les accès et les pages qui comptent dans le parcours.

1. 1. Cartographier les intentions utilesLister les questions de découverte, de comparaison et de décision auxquelles le site doit répondre. Associer chaque intention à une page existante ou réellement nécessaire.
2. 2. Corriger les accèsVérifier les codes HTTP, canonicals, directives d’indexation, robots, pare-feu, rendu mobile et liens internes avant de produire davantage.
3. 3. Renforcer trois pages prioritairesAméliorer la page d’offre, une page preuve et un guide : réponse directe, auteur, sources, exemple original, limites et CTA.
4. 4. Instrumenter les actionsSuivre la source, la page d’arrivée, les clics vers les services et les formulaires, dans le respect du consentement déjà en place.
5. 5. Revoir les résultats à date fixeComparer les évolutions, consigner les changements de documentation et mettre à jour seulement ce qui est devenu inexact ou incomplet.