Prompt Research : nouvelle couche stratégique SEO et GEO

Le keyword research ne suffit plus

Pendant 20 ans, la recherche de mots-clés a été le socle de toute stratégie SEO. Vous extrayiez des volumes de recherche depuis Google Keyword Planner, vous classiez par intention, vous mappiez sur des pages. Ce workflow reste pertinent pour le search classique. Mais il est aveugle à un canal qui capte désormais une part croissante du trafic informationnel : les interfaces conversationnelles — ChatGPT, Perplexity, Google AI Overviews, Copilot.

Le problème est structurel. Un mot-clé comme "meilleur CMS headless e-commerce" génère une SERP traditionnelle. Mais dans ChatGPT, la même intention s'exprime sous forme de prompt conversationnel : "Je gère un catalogue de 8 000 SKUs sur Shopify, je veux migrer vers un CMS headless avec SSR Next.js. Quels sont les trade-offs entre Sanity, Contentful et Strapi pour le SEO ?". Ce prompt contient un contexte métier, des contraintes techniques, une comparaison multi-critères. Il ne matche aucun mot-clé de votre keyword research classique. Et pourtant, la réponse de l'IA va citer — ou ignorer — votre contenu.

C'est exactement ce que recouvre le concept de prompt research : l'analyse systématique des patterns de prompts que les utilisateurs soumettent aux LLM, pour comprendre comment le contenu est sélectionné, reformulé et présenté dans les réponses génératives. Ce n'est pas une mode. C'est la couche manquante entre le keyword research traditionnel et l'optimisation pour la Generative Engine Optimization (GEO).

Anatomie d'un prompt : ce que les LLM voient que Google ignore

La différence structurelle entre query et prompt

Une query Google est atomique. Elle capture une intention en 2 à 5 mots. Un prompt est un micro-brief. Il contient des couches d'information que les modèles de langage exploitent pour filtrer, pondérer et synthétiser les sources.

Décomposons un prompt réel capturé sur un forum de développeurs :

Prompt utilisateur (ChatGPT, mars 2026) :

"Mon site e-commerce Next.js 14 (App Router) a 12 000 pages produit.
Depuis la migration de getServerSideProps vers les Server Components,
Googlebot rend correctement le HTML mais les pages ne sont plus indexées
depuis 3 semaines. Les logs montrent que le crawl rate a chuté de 60%.
Que vérifier en priorité ?"

Ce prompt contient au minimum 6 dimensions exploitables :

Technologie : Next.js 14, App Router, Server Components
Échelle : 12 000 pages produit
Symptôme : pages non indexées malgré un rendu correct
Contexte temporel : post-migration, 3 semaines
Donnée quantitative : crawl rate en baisse de 60%
Type de réponse attendu : checklist de diagnostic priorisée

Un keyword research classique aurait capturé "pages non indexées Next.js" ou "crawl budget e-commerce". Le prompt, lui, donne au LLM suffisamment de contexte pour sélectionner des sources qui traitent spécifiquement de la migration Server Components et de son impact sur l'indexation.

Ce que le LLM fait avec ces dimensions

Les modèles comme GPT-4o ou Claude ne font pas de recherche par mot-clé. Ils effectuent une retrieval augmentée (RAG) ou s'appuient sur leur corpus d'entraînement pour identifier les documents les plus pertinents par rapport à l'ensemble du contexte. Un article qui traite isolément du crawl budget sera moins bien classé qu'un article qui croise migration Next.js + Server Components + indexation + diagnostic.

C'est un changement fondamental : la granularité du matching passe du mot-clé à la combinaison de contraintes contextuelles.

Construire un workflow de prompt research

Étape 1 : collecter les patterns de prompts réels

Vous ne pouvez pas deviner comment vos utilisateurs formulent leurs prompts. Il faut les observer. Trois sources concrètes :

Les forums et communautés techniques. Reddit (r/SEO, r/webdev, r/nextjs), les discussions GitHub, les channels Discord de frameworks — c'est là que les développeurs et les SEO copient-collent les prompts qu'ils soumettent aux LLM, souvent avec la réponse obtenue.

Les logs de votre propre chatbot / support. Si vous avez un chatbot interne ou un système de tickets, les questions posées par vos utilisateurs sont des prompts en puissance. Un site e-commerce de 15 000 pages qui reçoit 200 tickets/mois sur des problèmes de visibilité produit a une mine d'or de prompt patterns.

Les suggestion de Perplexity et les AI Overviews. Perplexity affiche les "Related questions" après chaque réponse. Ces questions sont des reformulations de prompts adjacents. Les AI Overviews de Google montrent les sources citées — et vous pouvez reverse-engineer le type de prompt qui a déclenché cette citation.

Voici un script Python pour extraire et catégoriser des prompts depuis un export de tickets support :

import json
import re
from collections import Counter

def extract_prompt_dimensions(ticket_text: str) -> dict:
    """
    Extrait les dimensions exploitables d'un ticket/prompt utilisateur.
    Adapté pour un site e-commerce / SaaS technique.
    """
    dimensions = {
        "technologies": [],
        "scale_indicators": [],
        "symptoms": [],
        "timeframe": None,
        "expected_output": None
    }

    # Technologies mentionnées
    tech_patterns = [
        r"(Next\.js|Nuxt|React|Vue|Angular|Shopify|WordPress|Magento)",
        r"(SSR|CSR|ISR|SSG|Server Components|App Router|Pages Router)",
        r"(Googlebot|Bingbot|GPTBot|ClaudeBot|PerplexityBot)"
    ]
    for pattern in tech_patterns:
        matches = re.findall(pattern, ticket_text, re.IGNORECASE)
        dimensions["technologies"].extend(matches)

    # Indicateurs d'échelle
    scale_matches = re.findall(
        r"(\d[\d\s]*(?:pages?|URLs?|SKUs?|produits?|articles?))",
        ticket_text, re.IGNORECASE
    )
    dimensions["scale_indicators"] = scale_matches

    # Symptômes SEO
    symptom_keywords = [
        "non indexé", "désindexé", "crawl", "baisse", "chute",
        "page blanche", "404", "redirect", "canonical", "duplicate"
    ]
    for kw in symptom_keywords:
        if kw.lower() in ticket_text.lower():
            dimensions["symptoms"].append(kw)

    # Timeframe
    time_match = re.search(
        r"depuis\s+(\d+\s+(?:jours?|semaines?|mois))", ticket_text, re.IGNORECASE
    )
    if time_match:
        dimensions["timeframe"] = time_match.group(1)

    return dimensions


# Exemple d'utilisation sur un batch de tickets
with open("support_tickets_export.json", "r") as f:
    tickets = json.load(f)

all_symptoms = []
all_techs = []

for ticket in tickets:
    dims = extract_prompt_dimensions(ticket["body"])
    all_symptoms.extend(dims["symptoms"])
    all_techs.extend(dims["technologies"])

print("Top symptômes :", Counter(all_symptoms).most_common(10))
print("Top technologies :", Counter(all_techs).most_common(10))

Ce script est un point de départ. En production, vous l'enrichiriez avec un classifieur d'intention (informationnel, diagnostic, comparatif, transactionnel) et un clustering par embedding pour regrouper les prompts sémantiquement proches.

Étape 2 : mapper les prompt clusters sur votre contenu existant

Une fois vos prompt patterns identifiés, confrontez-les à votre contenu. L'objectif : repérer les gaps de couverture contextuelle — les combinaisons de dimensions qu'aucune de vos pages ne traite ensemble.

Prenez un site SaaS de monitoring (500 pages de documentation + 80 articles de blog). Le prompt research révèle un cluster dominant : "migration framework JS + perte d'indexation + diagnostic automatisé". Votre blog a un article sur SSR vs CSR et un autre sur pourquoi Google voit une page blanche. Mais aucun article ne croise ces deux sujets avec un angle post-migration + monitoring continu. C'est un gap que les LLM détectent : ils n'ont pas de source complète à citer, donc ils synthétisent des fragments de plusieurs sources — et votre site n'est mentionné dans aucun.

Étape 3 : prioriser par "citability score"

Tous les prompt patterns ne méritent pas un article. Le critère discriminant n'est pas le volume de recherche (il n'existe pas pour les prompts). C'est la probabilité de citation par le LLM. Trois facteurs la déterminent :

Spécificité technique : plus le prompt est précis, plus le LLM a besoin d'une source spécifique. Un prompt générique ("c'est quoi le SEO") sera traité par le corpus général du modèle. Un prompt précis ("impact des chaînes de redirections sur le crawl budget d'un site 30 000 pages sous Magento") va chercher une source experte.
Absence de consensus : quand les sources disponibles se contredisent, les LLM citent plus souvent pour justifier leur réponse. Les sujets avec trade-offs (comme les redirections 301 vs 302) sont des cibles privilégiées.
Fraîcheur de la donnée : un prompt qui mentionne une version spécifique (Next.js 14, Core Web Vitals 2025) pousse le LLM à chercher du contenu récent.

Optimiser le contenu pour la citation par les LLM (GEO)

Structurer pour le retrieval, pas seulement pour le crawl

Les moteurs de recherche classiques s'appuient sur le rendu HTML, les balises sémantiques et les signaux de liens. Les systèmes RAG des LLM fonctionnent différemment : ils découpent vos pages en chunks (généralement 500-1500 tokens), génèrent un embedding vectoriel pour chaque chunk, et matchent ces embeddings avec l'embedding du prompt utilisateur.

La conséquence pratique est majeure : un article qui traite correctement un sujet mais le dilue sur 3 000 mots avec des introductions, des transitions et des conclusions génériques va produire des chunks de faible densité informationnelle. Le même contenu condensé en sections autonomes et auto-suffisantes produit des chunks hautement spécifiques qui matchent mieux les prompts.

Concrètement, appliquez ces règles de structuration :

<!-- MAUVAIS : chunk dilué, faible densité -->
<section>
  <h2>Les redirections et leur impact</h2>
  <p>Les redirections sont un élément important du SEO technique.
  Il existe plusieurs types de redirections, chacun ayant ses propres
  caractéristiques. Dans cette section, nous allons examiner comment
  les redirections peuvent affecter votre référencement.</p>
  <p>La redirection 301 est une redirection permanente...</p>
  <!-- 800 mots avant d'arriver au point technique -->
</section>

<!-- BON : chunk dense, auto-suffisant, citable -->
<section>
  <h2>Redirection 301 post-migration : impact sur le crawl budget</h2>
  <p>Une chaîne de redirections 301 de plus de 2 sauts réduit le
  crawl rate effectif de 15 à 40% sur les sites dépassant 10 000 URLs.
  Le mécanisme : Googlebot suit les redirections mais décompte chaque
  saut de son budget de crawl alloué à votre domaine.</p>

  <h3>Diagnostic avec les logs serveur</h3>
  <p>Filtrez les requêtes Googlebot avec un statut 301 et comptez
  les chaînes :</p>
  <pre><code>
  cat access.log | grep "Googlebot" | grep " 301 " \
    | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
  </code></pre>

  <h3>Seuil d'action</h3>
  <p>Au-delà de 5% de vos URLs crawlées retournant une chaîne de
  2+ redirections, consolidez les chaînes en redirections directes
  vers la destination finale.</p>
</section>

Le second exemple produit un chunk qui répond directement à un prompt comme "comment les chaînes de redirections 301 affectent le crawl budget après une migration de site avec 10K+ pages". Le premier ne serait même pas sélectionné par le retriever.

Les éléments qui augmentent la probabilité de citation

L'analyse des réponses de ChatGPT, Perplexity et Gemini sur des requêtes techniques révèle des patterns récurrents dans les sources citées :

Les tableaux comparatifs structurés. Quand un prompt demande une comparaison ("Next.js vs Nuxt pour le SEO"), les LLM cherchent en priorité des tableaux avec des critères explicites. Structurez-les en HTML sémantique avec des <th> clairs.

Les snippets de code fonctionnels. Un prompt de développeur ("comment configurer le robots.txt pour bloquer GPTBot mais pas Googlebot") va citer la source qui contient le bloc de code prêt à copier. Votre article sur le robots.txt est un candidat naturel pour ce type de citation, à condition que les blocs de code soient isolés dans des sections auto-suffisantes.

Les chiffres contextualisés avec des conditions. Les LLM évitent de citer des statistiques brutes mais citent volontiers des données conditionnelles : "sur un site de X pages, Y se produit quand Z condition est remplie".

Scénario concret : un média de 8 000 articles face à la cannibalisation par les AI Overviews

Prenons un cas réaliste. Un média tech français (8 200 articles publiés, 2,4 millions de sessions organiques/mois) observe une baisse de 18% de son trafic informationnel sur 6 mois. Google Search Console montre que les impressions restent stables, mais le CTR a chuté de 4,2% à 3,1% sur les requêtes informationnelles. L'explication : les AI Overviews captent les clics en apportant une réponse directe.

Phase 1 : audit des prompt patterns (semaine 1-2)

L'équipe SEO identifie les 200 queries avec le plus fort écart impressions/clics dans Search Console. Pour chacune, ils formulent 3 variantes de prompt conversationnel et les soumettent à ChatGPT, Perplexity et Gemini. Résultat : le site est cité dans 12% des réponses de Perplexity, 6% des AI Overviews, et 3% des réponses ChatGPT. Les concurrents (blogs de développeurs anglophones, documentation officielle) sont cités 3 à 5 fois plus souvent.

Phase 2 : analyse des gaps (semaine 3)

Le diagnostic révèle trois problèmes :

Fragmentation du contenu. Le sujet "données structurées pour l'e-commerce" est couvert par 7 articles distincts (FAQ Schema, Product Schema, JSON-LD généraliste). Aucun n'est suffisamment complet pour être cité seul. Les LLM préfèrent une source unique qui couvre le sujet en profondeur.
Absence de contexte technique actionable. Les articles existants expliquent quoi faire mais pas comment le diagnostiquer ni quel est l'impact mesuré. Les prompts utilisateurs demandent presque toujours un diagnostic ou un impact chiffré.
Métadonnées pauvres pour le retrieval. Les balises meta et les données structurées sont optimisées pour Google, pas pour le retrieval par les LLM. Les descriptions sont marketing, pas techniques.

Phase 3 : restructuration orientée prompt (semaine 4-8)

L'équipe fusionne les 7 articles sur les données structurées en 2 articles piliers : un guide complet Product Schema enrichi avec des blocs de diagnostic, et un article FAQ Schema recentré sur les cas d'usage GEO. Chaque section est réécrite comme un chunk auto-suffisant.

Ils ajoutent un fichier llms.txt à la racine du site — une convention émergente qui fournit aux crawlers des LLM un résumé structuré du contenu du site :

# llms.txt - media-tech-fr.com
# Dernière mise à jour : 2026-03-10

## À propos
Média technique français couvrant le développement web,
le SEO technique et les architectures JavaScript modernes.
8 200+ articles. Mis à jour quotidiennement.

## Contenus piliers
- /guides/seo-technique-nextjs : Guide complet SSR/SSG/ISR pour le SEO
  avec Next.js 14+. Inclut diagnostics, code, benchmarks.
- /guides/donnees-structurees-ecommerce : Product Schema, FAQ Schema,
  Breadcrumb. Implémentation JSON-LD avec validation.
- /guides/migration-site-seo : Checklist technique complète.
  Redirections, crawl budget, monitoring post-migration.

## Politique de citation
Contenu sous licence CC BY 4.0. Citation avec lien source appréciée.

## Crawl
User-agent: GPTBot
Allow: /guides/
Allow: /articles/
Disallow: /compte/
Disallow: /api/

User-agent: PerplexityBot
Allow: /guides/
Allow: /articles/

Phase 4 : résultats à 3 mois

Après restructuration, les citations dans Perplexity passent de 12% à 31% sur les requêtes cibles. Les AI Overviews citent le site sur 14% des requêtes (contre 6%). Le trafic via les liens de citation Perplexity génère 45 000 sessions/mois — un canal qui n'existait pas. Le trafic organique classique récupère 8 points de CTR grâce à des title tags réécrits avec un angle "actionable" plutôt que "informationnel".

Monitorer votre visibilité dans les réponses IA

Le problème du tracking

Contrairement au search classique, il n'existe pas encore de Search Console pour les LLM. Vous ne savez pas combien de fois votre contenu est cité dans ChatGPT. Perplexity envoie du trafic référent traçable dans vos analytics, mais ChatGPT et Gemini ne génèrent pas systématiquement de clic vers la source.

Trois approches pour combler ce gap :

Monitoring des crawlers IA dans vos logs. GPTBot, ClaudeBot, PerplexityBot et Google-Extended laissent une trace dans vos access logs. L'évolution de leur crawl rate est un proxy de votre visibilité.

#!/bin/bash
# Monitoring hebdomadaire des crawlers IA
# À intégrer dans un cron job + dashboard Grafana

LOG_FILE="/var/log/nginx/access.log"
REPORT_FILE="/tmp/ai_crawler_report_$(date +%Y%m%d).csv"

echo "bot,requests,unique_urls,avg_response_time" > "$REPORT_FILE"

for BOT in "GPTBot" "ClaudeBot" "PerplexityBot" "Google-Extended" "Bytespider"; do
  REQUESTS=$(grep -c "$BOT" "$LOG_FILE")
  UNIQUE_URLS=$(grep "$BOT" "$LOG_FILE" | awk '{print $7}' | sort -u | wc -l)
  AVG_TIME=$(grep "$BOT" "$LOG_FILE" \
    | awk '{print $NF}' \
    | awk '{sum+=$1; count++} END {if(count>0) printf "%.3f", sum/count; else print "0"}')
  echo "$BOT,$REQUESTS,$UNIQUE_URLS,$AVG_TIME" >> "$REPORT_FILE"
done

echo "Rapport généré : $REPORT_FILE"
cat "$REPORT_FILE" | column -t -s ','

# Alerte si crawl rate GPTBot chute de plus de 50%
CURRENT=$(grep "GPTBot" "$REPORT_FILE" | cut -d',' -f2)
PREVIOUS=$(cat "/tmp/ai_crawler_report_previous.csv" 2>/dev/null \
  | grep "GPTBot" | cut -d',' -f2)

if [ -n "$PREVIOUS" ] && [ "$PREVIOUS" -gt 0 ]; then
  DROP=$(( (PREVIOUS - CURRENT) * 100 / PREVIOUS ))
  if [ "$DROP" -gt 50 ]; then
    echo "ALERTE : crawl GPTBot en chute de ${DROP}%" | \
      mail -s "AI Crawler Alert" [email protected]
  fi
fi

cp "$REPORT_FILE" "/tmp/ai_crawler_report_previous.csv"

Requêtes de test automatisées. Soumettez vos prompt patterns cibles aux APIs de Perplexity et ChatGPT de manière hebdomadaire, et parsez les réponses pour détecter la présence de vos URLs. C'est l'équivalent d'un rank tracker pour l'IA générative.

Monitoring des régressions techniques. Un problème de SSR, une meta canonical cassée ou une chaîne de redirections qui se forme silencieusement peut faire disparaître votre contenu du corpus des LLM. Un outil de monitoring comme SEOGard détecte ces régressions en continu, avant qu'elles n'affectent votre citabilité.

Prompt research et SEO classique : complémentarité, pas remplacement

Le prompt research ne remplace pas le keyword research. Les deux capturent des signaux différents sur le même spectre d'intention utilisateur :

Dimension	Keyword Research	Prompt Research
Unité d'analyse	Query (2-5 mots)	Prompt (1-5 phrases avec contexte)
Source de données	Search Console, Ahrefs, SEMrush	Forums, tickets support, APIs LLM
Métrique de priorisation	Volume, difficulté, CPC	Citability score, fréquence de pattern
Optimisation cible	Position SERP, CTR, featured snippets	Citation dans réponse IA, trafic référent LLM
Horizon temporel	Stable (volumes mensuels moyennés)	Volatile (prompts évoluent avec les capacités des LLM)

Le workflow intégré ressemble à ceci : le keyword research identifie les sujets à couvrir. Le prompt research révèle comment les couvrir pour maximiser la visibilité dans les deux canaux. Vous optimisez vos meta tags et vos title tags pour le CTR SERP classique, et vous structurez le body content en chunks denses et auto-suffisants pour le retrieval par les LLM.

Les sites qui ont compris cette complémentarité ne se demandent plus s'il faut bloquer ou autoriser GPTBot dans leur robots.txt. Ils l'autorisent stratégiquement sur leur contenu pilier — celui qui est structuré pour être cité — et bloquent les pages transactionnelles à faible valeur informationnelle.

Le prompt research comme avantage concurrentiel structurel

La fenêtre d'opportunité est ouverte maintenant. La majorité des équipes SEO n'ont pas encore intégré le prompt research dans leur workflow. Celles qui le font constatent un avantage disproportionné : être cité par un LLM crée un effet de renforcement (le contenu cité est davantage consulté, donc davantage lié, donc mieux classé dans le search classique aussi).

L'investissement technique n'est pas massif. Il s'agit de collecter les prompt patterns, d'auditer la structure de vos contenus existants pour la densité informationnelle par chunk, et de monitorer votre présence dans les réponses IA avec la même rigueur que vous surveillez vos positions SERP. SEOGard intègre précisément ce type de monitoring en détectant automatiquement les régressions techniques qui affectent à la fois votre indexation classique et votre citabilité par les LLM — parce qu'une page qui n'est pas indexée par Google n'a aucune chance d'être citée par Perplexity.