# Référencement Internet Web - Full Content
> SEO, marketing digital et référencement naturel. Stratégies concrètes, outils testés et retours d'expérience pour gagner en visibilité sur Google.
This file contains the full text of all 275 published articles for LLM indexing.
For a lightweight index, see [llms.txt](https://www.referencement-internet-web.com/llms.txt).
---
## aipref : le chantier IETF encore bloqué à deux catégories
- URL: https://www.referencement-internet-web.com/ietf-aipref-vocabulaire-preferences-ia-2026/
- Author: Guillaume P.
- Published: 2026-09-07T06:00:00
- Categories: seo
Tapez « aipref IETF » en français et vous ne trouverez rien. Zéro article, zéro guide. La niche a pourtant un nom et un dossier : c'est un chantier de l'IETF, l'organisme qui a écrit le standard robots.txt lui-même, en train de redéfinir comment un site déclare ce qu'une IA a le droit de faire de son contenu. Sauf que ce chantier n'a rien d'un standard fini. J'ai lu les deux textes source plutôt que les résumés qui en parlent, et l'écart entre les deux est le sujet de cet article.
**En clair** : aipref est un travail en cours à l'IETF, pas un standard publié. Au 3 septembre 2026, deux Internet-Drafts existent (`vocab-07`, `attach-05`), zéro RFC. Le vocabulaire ne définit que deux catégories d'usage, `train-ai` et `search`, encodées via un en-tête HTTP `Content-Usage` ou une règle du même nom dans robots.txt. La section qui les définit porte elle-même la mention « pas de consensus ».
## Ce que aipref essaie de résoudre
Le problème que l'IETF a mis sur la table est concret. Officiellement, le motif tient en une phrase du billet fondateur du groupe de travail : « les vendeurs d'IA utilisent un ensemble confus de signaux non standard dans robots.txt et ailleurs pour guider leurs décisions de crawl et d'entraînement ». Chaque plateforme a inventé son propre jeton, sa propre syntaxe, sa propre logique. Résultat : un éditeur qui veut autoriser l'entraînement mais refuser le grounding se retrouve à jongler avec des directives incompatibles selon le bot en face.
La réalité du terrain, je l'ai vue en épluchant des robots.txt publics ces derniers mois : des blocs entiers de `Disallow` empilés user-agent par user-agent, sans logique d'usage derrière, juste une [liste de bots recopiée d'un guide à l'autre](/crawl-ia-bots-gptbot-claudebot-robots-txt-editeurs-2026/). C'est exactement le symptôme que l'IETF dit vouloir traiter. Le groupe de travail aipref a été chartré le 7 janvier 2025, avec Mark Nottingham et Suresh Krishnan comme présidents, sous l'autorité de zone Web and Internet Transport.
## La chronologie, et pourquoi elle compte
Voici l'histoire du vocabulaire, version par version. Personne ne la raconte en français, et elle explique à elle seule pourquoi le sujet reste flou.
| Version | Date | Catégories | Détail |
| ------- | ---------- | ---------- | ------------------------------------------------------------------------------------------------------------------- |
| v03 | 2025-09-05 | 4 | Automated Processing (`bots`), AI Training (`train-ai`), Generative AI Training (`train-genai`), Search (`search`) |
| v04 | 2025-10-28 | 4 | Automated Processing (`bots`), Foundation Model Production (`train-ai`), AI Output (`ai-output`), Search (`search`) |
| v05 | 2025-12-01 | 2 | Foundation Model Production (`train-ai`), Search (`search`) |
| v06 | 2026-04-27 | 2 | AI Model Training (`train-ai`), Search (`search`) |
| v07 | 2026-08-19 | 2 | AI Model Training (`train-ai`), Search (`search`) |
Quatre catégories à la version 03, deux à la version 05, et ça n'a plus bougé depuis. `bots` (traitement automatisé générique) et `ai-output` sont passés à la trappe entre v04 et v05. `train-genai` a disparu dès la v04, remplacé par `ai-output` avant de disparaître à son tour. Le libellé de la catégorie d'entraînement, lui, a changé deux fois : « AI Training », puis « Foundation Model Production », puis « AI Model Training ». Si vous avez lu un article qui parle encore de quatre catégories dont `train-genai`, il décrit un état périmé depuis la version 04, c'est-à-dire depuis fin octobre 2025.
## Deux catégories, pas trois
Le point qui mérite d'être dit sans détour : le vocabulaire courant ne couvre que deux usages.
**`train-ai`** (AI Model Training) désigne l'utilisation d'un contenu pour modifier les paramètres appris d'un modèle qui génère du contenu synthétique. **`search`** désigne une application dont la finalité première est de sélectionner des ressources et de diriger l'utilisateur vers elles, avec une exclusion explicite : la génération de résumés n'entre pas dans cette catégorie.
Ce que ça laisse dehors, c'est l'usage après entraînement : le [RAG, le grounding](/contenu-citable-ia-rag-passages-autonomes-geo/), l'inférence à la volée qu'un modèle fait sur votre page au moment de répondre à une requête. L'omission n'a rien d'un oubli de rédaction : elle traduit un désaccord ouvert. Selon les minutes de la réunion IETF 126 du 24 juillet 2026, le périmètre de cet usage reste en débat, et aucun WG Last Call n'était annoncé à cette date. On croise régulièrement l'idée que aipref distinguerait déjà trois usages, entraînement, recherche et un troisième pour l'après-entraînement. C'est faux à la date de cet article, et la nuance vaut la peine d'être posée noir sur blanc : c'est précisément l'absence de cette troisième catégorie qui bloque le groupe.
Chaque préférence prend l'une de trois valeurs : `allowed`, `disallowed`, `unknown`, avec `unknown` par défaut en l'absence de déclaration. Dans le protocole, elles s'encodent en un seul caractère, `y` pour allow et `n` pour disallow. L'exemple donné par le draft lui-même : `train-ai=y, search=n`.
## Où on l'écrit : header HTTP ou robots.txt
Le second draft, `attach-05`, définit comment attacher ces préférences à un contenu accessible en HTTP. Deux canaux, et seulement deux : un en-tête de réponse `Content-Usage`, et une règle `Content-Usage` ajoutée à robots.txt. Ce draft met à jour le [RFC 9309](/rfc-9309-robots-txt-conformite-crawlers-ia-2026/), le standard qui régit robots.txt depuis 2022, sans le remplacer.
En en-tête HTTP, ça donne :
```
Content-Usage: train-ai=n
```
Dans robots.txt, la règle peut cibler un chemin précis, ce que le header seul ne permet pas :
```
Content-Usage: train-ai=n
Content-Usage: /ai-ok/ train-ai=y
```
Deux autres canaux sont évoqués dans le texte du draft, des métadonnées embarquées directement dans le fichier et un registre externe, mais aucun des deux n'est spécifié. Ils sont cités comme pistes, pas comme mécanismes disponibles. Ne construisez rien dessus aujourd'hui, il n'y a rien à construire.
## Ce qui est bloqué, très concrètement
Voici le point que je trouve le plus révélateur, et que le SERP anglophone lui-même sous-représente. Le calendrier du groupe prévoyait de soumettre les deux drafts à l'IESG au 31 août 2026. Au 3 septembre 2026, cette échéance n'est pas tenue : les deux documents restent à l'état `I-D Exists`, aucun n'a franchi l'étape suivante. Ce n'est pas le premier report. L'échéance initiale, fixée dans la charte approuvée en janvier 2025, était le 31 août 2025 ; elle avait déjà été repoussée d'un an par le directeur de zone en septembre 2025.
Il y a mieux : un appel à consensus (WG Last Call) avait été ouvert sur les deux textes le 4 septembre 2025. Il a été annulé, les documents renvoyés au statut « WG Document », le 3 novembre 2025. Aucun nouvel appel n'a été rouvert depuis. Le draft de vocabulaire porte lui-même, en toutes lettres, un avertissement à ses lecteurs : il ne reflète pas le consensus du groupe de travail, ni en tout ni en partie. Et la section qui définit les catégories, celle qui concentre tout l'enjeu, porte sa propre note distincte disant la même chose. Un texte qui s'auto-désavoue à ce point ne s'adopte pas. Il se suit, comme une base de discussion.
## Ce qui est réellement applicable aujourd'hui
Soyons honnêtes sur ce que vous pouvez faire avec ça maintenant, par opposition à ce qui reste un projet.
Techniquement, rien ne vous empêche de poser dès aujourd'hui un en-tête `Content-Usage` ou une règle du même nom dans votre robots.txt : la syntaxe est publique, documentée, stable depuis plusieurs versions. Le problème est ailleurs. À la date du 3 septembre 2026, aucun opérateur de crawler majeur, Google, OpenAI, Anthropic, Meta ou Perplexity, ne déclare publiquement respecter cet en-tête ou cette règle en production. Ce n'est pas une preuve que personne ne le fait en coulisses : c'est l'état exact des déclarations publiques à cette date, et c'est la seule chose que je peux affirmer avec certitude.
Ce que les opérateurs font réellement aujourd'hui, ce sont leurs propres grammaires, incompatibles entre elles. Google-Extended couvre d'un seul geste l'entraînement des futurs modèles Gemini et le grounding, sans les distinguer, et n'a aucun effet sur le classement dans Google Search. OpenAI sépare la granularité par bot plutôt que par catégorie déclarée : GPTBot pour l'entraînement, OAI-SearchBot pour la recherche, [chacun identifiable à sa propre documentation officielle](/verifier-authenticite-crawlers-ia-ip-ranges-2026/) plutôt qu'à une déclaration d'usage. Cloudflare, de son côté, a publié sa propre grammaire le 24 septembre 2025, `Content-Signal`, avec trois signaux (`search`, `ai-input`, `ai-train`), distincte de celle de l'IETF, et diffusée par son robots.txt managé, que plus de 3,8 millions de domaines avaient activé à cette date selon Cloudflare. Cloudflare dit explicitement attendre l'aboutissement de la proposition IETF pour aligner son propre mécanisme dessus. C'est le signe le plus net que même les gros acteurs du web considèrent que ce n'est pas encore arrivé à maturité.
Deux autres initiatives circulent dans le même espace, à ne pas confondre : [llms.txt](/llms-txt-standard-robots-txt-ia-generative-2026/), une proposition individuelle de Jeremy Howard, informelle, qui n'a jamais porté sur le contrôle d'usage mais sur le fait d'aider un agent à comprendre un site ; et RSL (Really Simple Licensing), lancée le 10 septembre 2025 par un collectif d'éditeurs, qui ajoute des termes de licence lisibles par machine là où robots.txt ne connaît que l'autorisation ou l'interdiction, dans le même esprit de réservation de droits que [le mécanisme TDMRep de réservation de fouille de textes et de données](/tdmrep-w3c-reservation-legale-tdm-ia-2026/). Aucune des deux n'est un travail de l'IETF.
Sur le fond, j'hésite encore à trancher si un éditeur a intérêt à poser `Content-Usage` dès maintenant, en pari sur l'adoption future, ou à attendre qu'un opérateur déclare réellement le lire. L'argument du pari, c'est que la syntaxe ne coûte rien à écrire. L'argument de l'attente, c'est qu'aucune plateforme majeure ne s'engage encore dessus, et que le texte qui la définit annonce lui-même qu'il peut changer. Les deux se défendent, et je ne vois pas d'argument décisif pour trancher entre les deux à cette date.
## FAQ
### aipref est-il un standard officiel de l'IETF ?
Non, pas au 3 septembre 2026. Ce sont deux Internet-Drafts de groupe de travail, `draft-ietf-aipref-vocab-07` et `draft-ietf-aipref-attach-05`, aucun RFC publié. Le draft de vocabulaire porte lui-même la mention qu'il ne reflète pas le consensus du groupe.
### Combien de catégories d'usage aipref définit-il ?
Deux, dans la version 07 : `train-ai` (entraînement de modèle IA) et `search` (recherche, qui exclut explicitement la génération de résumés). Une troisième catégorie, l'usage après entraînement comme le RAG ou le grounding, reste en débat selon les minutes de la réunion IETF 126 de juillet 2026 et n'a pas de définition dans le vocabulaire actuel.
### Comment déclarer une préférence avec Content-Usage ?
Deux canaux sont définis : un en-tête HTTP (`Content-Usage: train-ai=n`) ou une règle robots.txt du même nom, qui peut cibler un chemin précis (`Content-Usage: /ai-ok/ train-ai=y`). Les valeurs possibles sont `allowed`, `disallowed` et `unknown`, ce dernier s'appliquant par défaut en l'absence de déclaration.
### Les crawlers IA respectent-ils déjà Content-Usage ?
À la date du 3 septembre 2026, aucun opérateur de crawler majeur ne déclare publiquement respecter cet en-tête ou cette règle en production. C'est l'état des déclarations publiques connues à cette date, ni une preuve que personne ne le fait, ni une confirmation que quelqu'un le fait.
### aipref remplace-t-il robots.txt ?
Non. Le draft d'attachement met à jour le RFC 9309, le standard qui régit robots.txt depuis 2022, il ne le remplace pas. Le RFC 9309 continue de régir l'accès des crawlers ; aipref y ajoute une couche de préférence d'usage, sur un mécanisme distinct.
### Pourquoi le calendrier de aipref a-t-il déjà pris deux ans de retard ?
L'échéance initiale de la charte, fixée en janvier 2025, était le 31 août 2025. Elle a été repoussée une première fois au 31 août 2026 par le directeur de zone en septembre 2025, puis un appel à consensus ouvert en septembre 2025 a été annulé en novembre 2025 sans qu'un nouveau soit rouvert depuis. Au 3 septembre 2026, la seconde échéance est également dépassée.
## Sources
- [Groupe de travail aipref, page About](https://datatracker.ietf.org/group/aipref/about/), consulté le 3 septembre 2026
- [Historique du groupe aipref](https://datatracker.ietf.org/group/aipref/history/), consulté le 3 septembre 2026
- [draft-ietf-aipref-vocab-07, texte intégral](https://www.ietf.org/archive/id/draft-ietf-aipref-vocab-07.html), consulté le 3 septembre 2026
- [draft-ietf-aipref-attach-05, texte intégral](https://www.ietf.org/archive/id/draft-ietf-aipref-attach-05.html), consulté le 3 septembre 2026
- [Minutes de la réunion IETF 126, session aipref](https://datatracker.ietf.org/doc/minutes-126-aipref/), consulté le 3 septembre 2026
- [RFC 9309, Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html), consulté le 3 septembre 2026
- [IETF, billet officiel sur le groupe aipref](https://www.ietf.org/blog/aipref-wg/), consulté le 3 septembre 2026
- [Google Search Central, crawlers communs](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers), consulté le 3 septembre 2026
- [OpenAI, documentation des bots](https://developers.openai.com/api/docs/bots), consulté le 3 septembre 2026
- [Cloudflare, Content Signals Policy](https://blog.cloudflare.com/content-signals-policy/), consulté le 3 septembre 2026
- [Cloudflare, robots.txt managé et attente de l'IETF](https://blog.cloudflare.com/control-content-use-for-ai-training/), consulté le 3 septembre 2026
- [llms.txt, la spécification](https://llmstxt.org/), consulté le 3 septembre 2026
- [RSL Collective, lancement du standard RSL](https://rslstandard.org/press/rsl-standard), consulté le 3 septembre 2026
---
## RFC 9309 : ce que robots.txt impose aux crawlers IA
- URL: https://www.referencement-internet-web.com/rfc-9309-robots-txt-conformite-crawlers-ia-2026/
- Author: Guillaume P.
- Published: 2026-08-28T06:00:00.000Z
- Categories: seo
Tapez « RFC 9309 » dans un moteur de recherche et vous obtenez deux choses : le texte brut en anglais sur rfc-editor.org, ou une fiche SEO qui vous répète la syntaxe de `Disallow` sans jamais ouvrir le document. Aucune page ne fait ce que ce texte fait clause par clause : dire quelles règles sont obligatoires (MUST), lesquelles sont recommandées (SHOULD), et lesquelles restent une simple faculté (MAY). C'est cette distinction, et elle seule, qui permet de juger un crawler sur des bases solides plutôt que sur une intuition.
Le RFC 9309 est un standard IETF au stade « Proposed Standard », pas « Internet Standard », publié en septembre 2022. Il fixe des règles MUST, SHOULD et MAY précises sur le matching, le cache et la taille du fichier, mais ne prouve la conformité d'aucun crawler nommé : seules les déclarations des éditeurs et une mesure Cloudflare permettent d'en dire quelque chose.
## Un standard, mais pas celui qu'on croit
Première correction, et elle change la portée de tout le reste : le RFC 9309 n'est pas un « Internet Standard ». Sur la page datatracker de l'IETF, sa maturité est affichée noir sur blanc, « RFC - Proposed Standard (September 2022) ». C'est une catégorie Standards Track, la première marche d'un processus qui compte plusieurs étapes, pas la dernière. Le SERP le présente pourtant en boucle comme « le standard officiel du web ». Ce n'est pas faux au sens où c'est bien un texte IETF sérieux, avec ses auteurs identifiés (Martijn Koster pour l'origine, Gary Illyes, Henner Zeller et Lizzi Sassman de Google pour la formalisation de 2022). Mais « Proposed Standard » et « Internet Standard » ne sont pas synonymes, et un texte qui vous vend l'un pour l'autre a déjà raté la première ligne de sa lecture.
Le texte lui-même est prudent sur sa propre portée. Il précise que ses règles « ne sont pas une forme d'autorisation d'accès », et que le protocole « ne remplace pas des mesures de sécurité valides ». Autrement dit : le RFC 9309 documente un protocole de politesse entre serveurs et crawlers, pas un mécanisme de contrôle d'accès. Personne ne va en prison pour l'avoir ignoré. Ce qui existe, en revanche, c'est un texte de référence assez précis pour qu'on puisse dire, clause par clause, ce qu'un crawler devrait faire. Pour la syntaxe elle-même, `Disallow`, `Allow`, jokers et sitemap, notre [guide technique robots.txt et sitemap XML](/robots-txt-sitemap-xml-guide-technique-seo) couvre la partie pratique que cet article ne refait pas.
## Ce que le RFC impose, clause par clause
Voici la grille que le SERP ne fait jamais : chaque règle avec son statut normatif exact, tel que défini par la RFC 2119 (les mots en capitales MUST, SHOULD, MAY ont un sens normatif précis dans le vocabulaire IETF, et seulement en capitales).
| Clause | Règle | Statut |
| ------- | ------------------------------------------------------------------------------ | ---------- |
| 2.2.1 | Sélectionner son groupe par correspondance insensible à la casse du user-agent | MUST |
| 2.2.1 | Se replier sur le groupe `user-agent: *` si aucun groupe ne correspond | MUST |
| 2.2.2 | Retenir la correspondance la plus spécifique (le plus grand nombre d'octets) | MUST |
| 2.2.2 | Faire commencer la comparaison au premier octet du chemin | MUST |
| 2.2.2 | Retenir `allow` en cas d'égalité stricte entre une règle `allow` et `disallow` | SHOULD |
| 2.2.2 | Comparer les chemins en tenant compte de la casse | SHOULD |
| 2.2.3 | Supporter les caractères `#`, `$` et `*` | MUST |
| 2.2.4 | Interpréter des enregistrements hors protocole, comme `Crawl-delay` | MAY |
| 2.3 | Servir le fichier à `/robots.txt` en minuscules, encodé en UTF-8 | MUST |
| 2.3.1.1 | Suivre les règles analysables en cas de téléchargement réussi | MUST |
| 2.3.1.2 | Suivre au moins cinq redirections consécutives | SHOULD |
| 2.3.1.3 | Accéder à toutes les ressources en cas d'erreur 4xx | MAY |
| 2.3.1.4 | Présumer une interdiction complète en cas d'erreur 5xx | MUST |
| 2.3.1.4 | Sortir de cette interdiction après une période « raisonnablement longue » | MAY |
| 2.3.1.5 | Analyser chaque ligne et utiliser les règles analysables | MUST |
| 2.4 | Ne pas garder une version en cache plus de 24 heures | SHOULD NOT |
| 2.5 | Imposer une limite d'analyse d'au moins 500 kibioctets | MUST |
Trois lignes méritent qu'on s'y arrête, parce que le web les confond en permanence. La sortie de l'interdiction en cas de panne serveur (ligne 2.3.1.4, deuxième occurrence) est un MAY, pas un droit acquis : le texte cite 30 jours « en exemple », pas comme un seuil chiffré. La durée de cache de 24 heures est un SHOULD NOT, avec une exception explicite quand le fichier est injoignable, pas une interdiction sèche. Et le traitement d'une erreur 4xx reste un MAY : un crawler qui choisit de ne rien crawler sur un 404 reste parfaitement conforme, même si la formule inverse circule partout.
Le fait le plus mal compris, c'est sans doute les 500 kibioctets. Le texte les impose au crawler comme plancher d'analyse, pas au site comme plafond de fichier. Rien n'interdit à un éditeur de publier un robots.txt de 2 Mo ; ce que le RFC garantit, c'est qu'un crawler conforme analysera au moins les 500 premiers kibioctets avant de pouvoir s'arrêter. Ne confondez pas non plus ce chiffre avec les 15 Mo que Google documente comme limite de crawl d'un fichier ordinaire : ce sont deux mécanismes distincts, l'un sur le robots.txt lui-même, l'autre sur les pages qu'il autorise à visiter.
## La grille qui manque au web : norme, déclaration, mesure
Voici l'outil que cet article vous donne, et qui n'existe nulle part ailleurs en français : trois catégories de fait, qui ne se mélangent jamais.
- Norme : ce que dit le texte du RFC 9309, tel quel.
- Déclaration d'éditeur : ce qu'une entreprise écrit sur sa propre documentation. Une déclaration prouve qu'elle l'a écrit, pas qu'elle le fait.
- Mesure : ce qu'une étude identifiée et méthodologique a observé de l'extérieur.
Sur cette base, voici ce que les éditeurs documentent réellement, en les nommant chacun avec leur propre déclaration.
Google documente traiter toutes les erreurs 4xx sauf 429 comme l'absence de robots.txt valide, ce qui reste conforme puisque la clause est un MAY. Sur les erreurs 5xx, Google documente une séquence en trois temps : arrêt du crawl pendant douze heures en gardant les tentatives de fetch, puis usage de la dernière version valide pendant trente jours, et, s'il n'existe aucune version en cache, un comportement d'absence de restriction. C'est la ligne la plus délicate de toute cette lecture : la clause 2.3.1.4 impose un MUST sur l'interdiction complète en cas de panne serveur, et le cas « pas de copie en cache » de Google s'en approche dangereusement. Je ne vais pas écrire que Google viole le RFC : la clause suivante ouvre elle-même une sortie MAY après une période raisonnablement longue, sans fixer où commence le raisonnable. C'est une divergence apparente, pas une non-conformité établie, et la nuance mérite d'être gardée telle quelle.
Un écart, en revanche, se nomme sans détour, parce que c'est Google lui-même qui l'écrit noir sur blanc : AdsBot ignore le groupe `user-agent: *` avec l'accord de l'éditeur publicitaire, alors que la clause 2.2.1 impose un MUST de repli sur ce groupe. Google documente une exception à une clause obligatoire. C'est le seul écart net de cet article, et il tient parce qu'il est écrit par la source elle-même, pas déduit d'une observation extérieure.
Anthropic documente que ses robots respectent les signaux « do not crawl » en honorant les directives standard du robots.txt, et supporte en plus l'extension non standard `Crawl-delay`, que le RFC range en MAY sans l'imposer ni l'interdire. OpenAI documente qu'une modification du fichier met environ 24 heures à être répercutée sur ses systèmes. Perplexity documente le même ordre de grandeur, jusqu'à 24 heures. Ce délai de propagation compte double si votre enjeu est la citation par les moteurs génératifs plutôt que le blocage : c'est le terrain de notre article sur [llms.txt et son adoption réelle](/llms-txt-standard-robots-txt-ia-generative-2026).
Ce que ces trois éditeurs documentent aussi, chacun de son côté, c'est qu'un fetcher déclenché par une requête d'utilisateur (ChatGPT-User chez OpenAI, Perplexity-User chez Perplexity, une catégorie équivalente chez Google) peut ne pas appliquer le robots.txt. Ce n'est pas une violation : le RFC vise explicitement les « crawlers », définis comme des clients automatiques. Un fetcher qui va chercher une page parce qu'un utilisateur l'a demandé n'entre pas dans cette définition, et trois éditeurs sur quatre exploitent exactement cette lecture, sans que le texte la contredise.
Sur ce qu'un crawler nommé fait réellement, clause par clause, sur le terrain, la documentation publique ne dit rien. Ni GPTBot, ni ClaudeBot, ni PerplexityBot ne publient de conformité détaillée à la limite d'analyse, à la règle de matching ou au traitement des pannes serveur. Ce vide est un constat sur l'état de la documentation publique à ce jour, et c'est précisément ce qui rend une accusation de non-conformité indéfendable pour ces trois robots à ce stade. La question de savoir s'il faut bloquer ou laisser passer ces crawlers, elle, est traitée à part dans notre article sur [le dilemme bloquer ou autoriser les bots IA](/crawl-ia-bots-gptbot-claudebot-robots-txt-editeurs-2026), que je ne rejoue pas ici.
La seule mesure de terrain disponible vient de Cloudflare, le 4 août 2025, et elle est partie prenante : Cloudflare vend du blocage de bots. Sa méthode part de plaintes de clients ayant à la fois interdit Perplexity en robots.txt et posé des règles WAF, avec des domaines neufs créés pour le test, non indexés et non découvrables. Cloudflare y écrit que les crawlers déclarés et non déclarés de Perplexity tentaient d'accéder au contenu, contrairement aux normes de crawl du RFC 9309, sur des dizaines de milliers de domaines et des millions de requêtes par jour. Le même protocole appliqué à ChatGPT-User donne un résultat inverse : ChatGPT-User a récupéré le robots.txt et cessé de crawler quand il était interdit. C'est un test ciblé né de réclamations clients, pas un panel représentatif de l'ensemble des crawlers IA, et Cloudflare a depuis retiré Perplexity de sa liste de bots vérifiés. J'attribue ce constat à sa source, et je donne l'autre voix : Perplexity a répondu dans un billet intitulé « Agents or Bots: Making Sense of AI on the Open Web », qui oppose la récupération déclenchée par un utilisateur au crawl automatisé, et un porte-parole a déclaré à TechCrunch que ces robots n'étaient pas ceux de l'entreprise et que le billet de Cloudflare tenait de l'argumentaire commercial. Le cas Perplexity, sous l'angle de la vérification technique cette fois, plages IP et DNS inverse à l'appui, est démonté dans notre article sur [l'authenticité des crawlers IA par plage IP](/verifier-authenticite-crawlers-ia-ip-ranges-2026).
## Les errata que personne ne cite
Un RFC publié n'est pas un texte figé. Celui-ci porte quatre errata, tous au statut « Reported », aucun au statut « Verified » : une coquille de nom de fichier signalée en septembre 2022, un point de code Unicode mal transcrit signalé la même semaine, une incohérence entre la grammaire formelle et un exemple du texte signalée en juin 2024, et un quatrième, plus récent, déposé le 28 avril 2026 par Fabrice Canel, de Microsoft. Ce dernier propose une extension optionnelle pour les listes de user-agents séparées par une virgule dans une même ligne, avec un chiffre de terrain à l'appui : environ 0,3 % des robots.txt contiendraient déjà une virgule dans leurs champs user-agent. Aucun des guides SEO du sujet ne mentionne cet erratum, ni les trois précédents.
Ce que ça dit du texte : le RFC 9309 continue d'être discuté, quatre ans après sa publication, par les mêmes acteurs qui l'ont écrit. Un standard « Proposed » qui reçoit encore des signalements techniques en 2026 n'est pas un texte mort, mais ce n'est pas non plus un texte clos.
## Sur quoi peut se fonder une accusation de non-conformité
C'est la question que le SERP ne pose jamais, alors qu'elle est la seule qui compte pour un éditeur de site : sur quoi peut-on réellement s'appuyer pour dire d'un crawler qu'il ne respecte pas le RFC 9309 ?
Trois fondations, et rien d'autre. Ce que le crawler documente lui-même sur sa propre page, ce qu'une mesure de terrain identifiée et méthodologique a observé, ou une contradiction directe entre les deux. Une plainte non vérifiée sur un forum, une intuition sur un pic de trafic dans les logs, une comparaison avec un autre bot supposé « plus propre » : aucun de ces éléments ne suffit à établir une non-conformité, aussi convaincants qu'ils paraissent sur le moment.
## Le terrain voisin, et pourquoi il n'est pas celui-ci
Un chantier IETF distinct existe en ce moment même, le groupe de travail « AI Preferences » (aipref), qui travaille à standardiser l'expression de préférences sur la collecte et le traitement de contenu pour l'IA, avec deux documents, `draft-ietf-aipref-vocab` et `draft-ietf-aipref-attach`, que la charte du groupe prévoit de transmettre à l'IESG au 31 août 2026. Ce chantier touche à la fouille de textes et de données et au droit d'auteur, un terrain juridique complètement différent de la conformité technique traitée ici. Je ne le développe pas davantage ici : je l'ai fait séparément dans [aipref, le chantier IETF encore bloqué à deux catégories](/ietf-aipref-vocabulaire-preferences-ia-2026), pour ne pas mélanger à la lecture du RFC 9309 l'erreur que cet article essaie justement de corriger. Le protocole voisin qui prétend combler ce vide juridique, TDMRep, mérite sa propre lecture critique : je l'ai faite dans [TDMRep, ce qu'il prouve et ce qu'il ne prouve pas](/tdmrep-w3c-reservation-legale-tdm-ia-2026).
Le problème, sur ce sujet, c'est qu'on confond trop souvent un protocole technique avec une garantie juridique. Le RFC 9309 dit ce qu'un crawler devrait faire techniquement. Il ne dit rien de ce qu'un tribunal ferait d'une violation, et pour cause : ce n'est pas son terrain.
J'hésite encore à trancher si le vide documentaire sur GPTBot, ClaudeBot et PerplexityBot relève d'une prudence légitime des éditeurs ou d'un choix de ne pas s'exposer à une comparaison publique gênante. Les deux lectures se défendent, et je n'ai pas d'élément qui permette de choisir entre les deux.
## Questions fréquentes
### Le RFC 9309 est-il un standard officiel de l'Internet ?
Non, pas au sens strict. Sur datatracker.ietf.org, sa maturité affichée est « Proposed Standard », la première étape d'un processus IETF en plusieurs marches, distincte d'un « Internet Standard ». C'est un texte Standards Track sérieux, mais pas la dernière étape de normalisation.
### GPTBot, ClaudeBot ou PerplexityBot respectent-ils le RFC 9309 ?
Aucune documentation publique ne permet de répondre clause par clause pour ces trois crawlers. Leurs pages officielles ne détaillent ni la durée de cache appliquée, ni la limite d'analyse, ni le traitement des erreurs serveur. Ce que chaque éditeur documente, en revanche, c'est son engagement général à honorer les directives robots.txt.
### Les fetchers comme ChatGPT-User violent-ils le RFC en ignorant robots.txt ?
Non, selon la lecture du texte. Le RFC vise les « crawlers », définis comme des clients automatiques. OpenAI, Perplexity et Google documentent chacun une catégorie de fetchers déclenchés par une requête d'utilisateur, distincte de leurs crawlers automatiques, et le RFC ne tranche pas explicitement ce cas.
### Les 500 kibioctets sont-ils une taille maximale de robots.txt ?
Non. C'est une limite d'analyse imposée au crawler : il doit lire au moins les 500 premiers kibioctets du fichier. Rien n'interdit à un site de publier un fichier plus volumineux. Ne confondez pas ce chiffre avec les 15 Mo que Google documente comme limite de crawl des pages ordinaires.
### La mesure Cloudflare sur Perplexity est-elle une preuve définitive de non-conformité ?
C'est une mesure datée et documentée, mais elle vient d'un acteur qui vend du blocage de bots, née de plaintes clients plutôt que d'un panel représentatif. Cloudflare y écrit avoir observé des crawlers Perplexity accéder à du contenu contrairement aux normes du RFC 9309, sur un test ciblé. C'est un fait attribuable à sa source, pas un verdict indépendant.
## Sources
- [RFC 9309, Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html), consulté le 28 août 2026
- [RFC 9309, page datatracker IETF, statut Proposed Standard](https://datatracker.ietf.org/doc/rfc9309/), consulté le 28 août 2026
- [RFC 9309, page des errata, 4 signalements Reported](https://www.rfc-editor.org/errata/rfc9309), consulté le 28 août 2026
- [The Web Robots Pages, texte d'origine de 1994 de Martijn Koster](https://www.robotstxt.org/orig.html), consulté le 28 août 2026
- [Google Search Central Blog, annonce de la soumission du draft à l'IETF, 1er juillet 2019](https://developers.google.com/search/blog/2019/07/rep-id?hl=en), consulté le 28 août 2026
- [Google, interprétation du Robots Exclusion Protocol](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=en), consulté le 28 août 2026
- [Google, aperçu des crawlers et fetchers, cas AdsBot](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en), consulté le 28 août 2026
- [OpenAI, aperçu des crawlers OpenAI](https://developers.openai.com/api/docs/bots), consulté le 28 août 2026
- [Anthropic, centre d'aide, crawl et blocage des robots](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler), consulté le 28 août 2026
- [Perplexity, documentation des crawlers](https://docs.perplexity.ai/docs/resources/perplexity-crawlers), consulté le 28 août 2026
- [Cloudflare, blog, crawlers non déclarés de Perplexity, 4 août 2025](https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/), consulté le 28 août 2026
- [IETF Datatracker, charte du groupe de travail AI Preferences](https://datatracker.ietf.org/wg/aipref/about/), consulté le 28 août 2026
- [TechCrunch, réponse publique de Perplexity au billet Cloudflare, 5 août 2025](https://techcrunch.com/2025/08/05/some-people-are-defending-perplexity-after-cloudflare-named-and-shamed-it), consulté le 28 août 2026
---
## TDMRep : ce qu'il prouve, et ce qu'il ne prouve pas
- URL: https://www.referencement-internet-web.com/tdmrep-w3c-reservation-legale-tdm-ia-2026/
- Author: Guillaume P.
- Published: 2026-08-10T06:00:00.000Z
- Categories: referencement
Un fichier JSON de trois lignes qui protégerait légalement votre contenu contre l'entraînement des IA génératives, mieux que ne le fait `robots.txt`. C'est la promesse qui revient sur à peu près toutes les pages qui parlent de TDMRep. J'ai lu la spécification du W3C dans son intégralité, les textes de droit qu'elle est censée appliquer, et sondé cinquante-deux domaines pour voir qui s'en sert réellement. La promesse ne tient pas telle quelle.
TDMRep est un rapport final de groupe communautaire du W3C, publié le 10 mai 2024, pas une norme W3C. Il propose quatre techniques (fichier, en-tête HTTP, meta HTML, métadonnées EPUB ou PDF) pour exprimer une réservation de droits au titre de l'article 4 de la directive 2019/790. Aucun texte européen ne le nomme : le code GPAI ne cite que `robots.txt`.
## TDMRep, ce que dit vraiment la spécification
Première chose à corriger, parce qu'elle conditionne tout le reste : TDMRep n'est pas un standard du W3C. La spécification le dit d'elle-même, noir sur blanc : « This specification was published by the Text and Data Mining Reservation Protocol Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. » C'est un « Final Community Group Report », daté du 10 mai 2024, troisième version d'un texte publié une première fois le 16 février 2022. Un groupe communautaire, distinct des groupes de travail qui produisent les recommandations du W3C, présidé par Laurent Le Meur et Giulia Marangoni, avec 66 participants affichés sur la page du groupe. Rien de tout ça n'a la portée d'une norme adoptée par le W3C.
Deuxième correction, plus discrète mais plus utile : la quasi-totalité des pages qui présentent TDMRep parlent de trois modes de déclaration. Il y en a quatre. La spécification est explicite : « This specification provides four complementary techniques for expressing rightsholders' choices. »
| Technique | Où ça se déclare | Exemple |
| ---------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------- |
| Fichier | `tdmrep.json` dans `/.well-known` | `{"location": "/", "tdm-reservation": 1}` |
| En-tête HTTP | Réponse à une requête `GET` ou `HEAD` | `tdm-reservation: 1` et `tdm-policy: https://provider.com/policies/policy.json` |
| Meta HTML | Balise `meta` dans le `head` du document | `name="tdm-reservation" content="1"` |
| Métadonnées EPUB / PDF | Section metadata du document, syntaxe à deux-points | `tdm:reservation` et `tdm:policy` (pas de trait d'union) |
L'ordre compte. La spécification pose une hiérarchie précise : l'en-tête HTTP écrase le fichier, la meta HTML écrase l'en-tête, les métadonnées EPUB ou PDF écrasent la meta HTML. Et l'absence d'une valeur à une étape ne réinitialise jamais celles trouvées plus haut. Les ayants droit sont invités à n'utiliser qu'une seule technique à la fois, pour éviter justement ce genre de conflit en cascade.
La valeur `tdm-reservation: 1` signifie que les droits TDM sont réservés. Si une `tdm-policy` (une URL) est renseignée, l'agent de fouille peut s'en servir pour demander une autorisation. La valeur `0` signifie l'inverse : fouille possible sans contact préalable. Toute autre valeur est traitée comme une erreur de protocole, et l'agent doit alors considérer le champ comme non défini. Un détail que j'ai trouvé utile à préciser : d'après les notes de réunion du groupe du 30 septembre 2025, le signal `tdm-reservation` ne veut pas dire « pas de fouille », il veut dire « droits réservés ». La nuance a son importance juridique, on y revient plus bas.
## Où est la vraie obligation légale
Voici la chaîne de textes que TDMRep tente de satisfaire, sans qu'aucun d'eux ne le nomme.
| Texte | Disposition | Ce qu'il impose |
| --------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Directive (UE) 2019/790 | Article 4, paragraphe 3 | L'exception de fouille de textes et de données « s'applique à condition que l'utilisation des œuvres […] n'ait pas été expressément réservée par leurs titulaires de droits de manière appropriée, notamment par des procédés lisibles par machine pour les contenus mis à la disposition du public en ligne » |
| Code de la propriété intellectuelle, article L122-5-3, III | Transposition française | Les copies pour fouille sont permises « sauf si l'auteur s'y est opposé de manière appropriée, notamment par des procédés lisibles par machine » |
| Règlement (UE) 2024/1689 (IA Act), article 53, paragraphe 1, point c) | Obligation des fournisseurs de modèles d'IA à usage général | Ils « mettent en place une politique visant à se conformer au droit de l'Union en matière de droit d'auteur […] et notamment à identifier et à respecter […] une réservation de droits exprimée conformément à l'article 4, paragraphe 3, de la directive (UE) 2019/790 » |
Le point important tient dans la formulation : le droit exige une réserve « appropriée » et « lisible par machine ». Aucun de ces trois textes ne cite TDMRep par son nom. TDMRep est un moyen technique parmi d'autres de satisfaire une exigence légale, il ne crée pas cette exigence, et il n'en est pas non plus l'unique satisfaction possible. Le considérant 18 de la directive va même plus loin en précisant que la réserve peut passer « par des procédés lisibles par machine, y compris des métadonnées et les conditions générales d'utilisation d'un site internet ». Un simple texte dans des CGU pourrait donc, en théorie, jouer le même rôle qu'un fichier JSON.
## TDMRep a-t-il une valeur juridique que robots.txt n'a pas ?
C'est l'affirmation qui revient partout : TDMRep aurait, contrairement à `robots.txt`, une valeur juridique reconnue par l'IA Act. Elle ne résiste pas à la lecture du texte que cette affirmation est censée citer.
Le code de bonnes pratiques pour l'IA à usage général, publié par la Commission le 10 juillet 2025 et signé par 22 acteurs (dont Google, Microsoft, Mistral AI, OpenAI, Anthropic), pose deux engagements distincts dans sa mesure 1.3 sur le droit d'auteur. Le premier engagement, celui qui nomme un protocole précis, dit ceci : « to employ web-crawlers that read and follow instructions expressed in accordance with the Robot Exclusion Protocol (robots.txt), as specified in […] Request for Comments No. 9309 ». `robots.txt` est cité nommément, avec sa RFC.
Le second engagement, lui, ne nomme aucun protocole. Il parle « d'autres protocoles appropriés lisibles par machine », à condition qu'ils aient été adoptés par une organisation de normalisation, ou qu'ils soient à l'état de l'art, largement adoptés par les ayants droit, et « généralement agréés au terme d'un processus inclusif facilité au niveau de l'UE ». TDMRep ne satisfait à ce jour aucun de ces critères : ni normalisé, ni mesurablement adopté à grande échelle (voir plus bas), ni objet d'un accord européen formalisé.
Et la Commission européenne elle-même ne traite pas TDMRep comme la solution retenue. Elle a ouvert le 1er décembre 2025 une consultation, close le 23 janvier 2026, dont la FAQ officielle liste huit solutions techniques candidates identifiées par une étude de l'EUIPO : `robots.txt`, TDMRep, C2PA TDM Assertions, AI.txt, le Do Not Train Registry de Spawning AI, JPEG Trust, le protocole TDM.ai de Liccium, et l'Open Rights Data Exchange de Valunode. Une candidate parmi huit, pas la solution choisie. C'est le fait qui manque à toutes les pages qui présentent TDMRep comme déjà validé par le droit de l'UE.
Signe supplémentaire que le dossier n'est pas clos côté normalisation : le groupe communautaire du W3C a lui-même décidé, d'après ses notes du 30 septembre 2025, d'attendre l'issue des travaux du groupe IETF AI Preferences (coprésidé par Mark Nottingham et Suresh Krishnan, deux drafts en cours, aucune RFC publiée à ce jour) avant de déterminer un chemin vers une éventuelle normalisation de TDMRep.
## Ce que dit la jurisprudence allemande, et ce qu'elle ne dit pas
Deuxième affirmation à corriger : non, aucun tribunal n'a « validé » TDMRep. Le seul contentieux européen que j'ai trouvé sur le sujet ne porte pas sur TDMRep, mais sur ce qu'exige la notion de réserve lisible par machine en général.
Je n'ai pas pu lire le texte intégral des décisions LG Hamburg (27 septembre 2024, affaire 310 O 227/23) et OLG Hamburg (10 décembre 2025, affaire 5 U 104/24), opposant le photographe Robert Kneschke à LAION e.V. Ce qui suit vient de trois analyses juridiques secondaires. Selon Paul Keller, sur le Kluwer Copyright Blog, la cour d'appel de Hambourg a jugé que « it is not only important that the text can be captured by machine, but also that it can be interpreted by machine in such a way that […] the content covered by the reservation is not processed » : une simple détectabilité par une machine ne suffit pas, il faut que la réserve soit interprétable automatiquement. Selon Ekaterina Filikhina et Lennart Elsass, du cabinet DLA Piper, sur le blog Technology's Legal Edge, la cour a aussi jugé que le demandeur n'avait « not demonstrate[d] that the usage reservation was machine-readable in the second half of 2021 ». Le cabinet allemand VOSSIUS résume le principe posé : « Ein Nutzungsvorbehalt bei online zugänglichen Werken sei nur dann wirksam, wenn er in maschinenlesbarer Form erklärt werde. »
Deux limites à garder en tête. D'abord, TDMRep n'est mentionné dans aucune des trois analyses comme objet du litige : c'est le critère général de lisibilité par machine qui est en jeu, pas ce protocole précis. Ensuite, la cour d'appel a autorisé un pourvoi devant la Cour fédérale de justice allemande (BGH), toujours selon DLA Piper. Le dossier reste ouvert, en droit allemand, et je n'ai trouvé aucune décision de la Cour de justice de l'Union européenne sur ce point.
## Sur le terrain : ce que nous avons trouvé en sondant 52 domaines
Les pages qui vendent TDMRep ne publient jamais de chiffre d'adoption. Nous avons sondé le 7 août 2026 `/.well-known/tdmrep.json` sur un panel de 52 domaines constitué à la main (presse française, éditeurs scientifiques, institutions culturelles, presse internationale). Ce panel n'a rien de représentatif du web dans son ensemble, et le résultat doit se lire comme un instantané, pas comme une statistique de marché.
| Résultat | Nombre de domaines |
| ------------------------------------------ | ------------------ |
| Fichier valide et conforme | 10 |
| Domaine bloquant (403), verdict impossible | 8 |
| Fichier absent | 34 |
Parmi les dix fichiers servis : Springer Nature et Elsevier réservent leurs droits (`tdm-reservation: 1`) avec une `tdm-policy` associée. Deux fichiers, en revanche, s'écartent de la spécification. Cambridge University Press sert un objet JSON unique là où le format impose un tableau d'objets. Le Parisien ajoute deux propriétés absentes de la spécification (`tdm-agents` et `usage-policy`) et duplique la même règle de localisation deux fois. Ce sont des constats techniques sur les fichiers tels qu'ils sont servis, pas un jugement sur l'intention des éditeurs.
Le détail qui m'a fait sourire : EDRLab, l'organisation qui porte et promeut TDMRep, sert sur son propre domaine un fichier qui déclare `"tdm-reservation": 0`, c'est-à-dire des droits non réservés. Et le W3C lui-même, l'organisation qui héberge le groupe de travail, ne publie aucun `tdmrep.json` : la requête renvoie une page 404. Ce n'est pas une preuve d'incohérence de fond, juste un rappel que porter un protocole n'oblige pas à s'auto-imposer sa configuration la plus stricte.
Sur les fournisseurs de modèles d'IA nommés (OpenAI, Google, Anthropic, Perplexity, Mistral AI), aucune de leurs pages de documentation officielle sur le crawl ne mentionne TDMRep, alors que `robots.txt` y est cité systématiquement. Je le présente comme un constat de recherche documentaire daté du 7 août 2026, pas comme une preuve que ces acteurs ignorent le protocole : plusieurs de ces pages sont partiellement rendues en JavaScript, et une absence de mention trouvée n'équivaut pas à une absence de mention tout court.
## Ce qu'il faut poser sur son serveur lundi matin
Trois recommandations, dans l'ordre où je les traiterais.
**Si vous voulez réserver vos droits de manière lisible par machine, le fichier `/.well-known/tdmrep.json` reste le choix le plus simple à maintenir.** La spécification donne un exemple multi-règles utile pour des sites avec des zones à traitement différent :
```json
[
{ "location": "/directory-a/", "tdm-reservation": 1 },
{
"location": "/directory-b/html/",
"tdm-reservation": 1,
"tdm-policy": "https://provider.com/policies/policy.json"
},
{ "location": "/directory-b/images/*.jpg", "tdm-reservation": 0 }
]
```
Le motif le plus spécifique l'emporte en cas de chevauchement. N'utilisez qu'une seule des quatre techniques : en combiner plusieurs ouvre la porte aux conflits de priorité décrits plus haut.
**Ne présentez jamais ce fichier comme une garantie juridique en soi.** Ce qu'exige le droit, c'est une réserve appropriée et lisible par machine. TDMRep est une façon technique d'y répondre, pas la façon reconnue par un texte de loi. Si un client vous demande si poser ce fichier le protège légalement mieux qu'un `robots.txt` bien configuré, la réponse honnête est : le droit ne fait pas cette hiérarchie, seul le code de bonnes pratiques GPAI nomme explicitement `robots.txt`. Pour la partie blocage technique des robots eux-mêmes, plutôt que de dupliquer l'information ici, direction notre [guide sur le blocage des crawlers IA par robots.txt](/crawl-ia-bots-gptbot-claudebot-robots-txt-editeurs-2026) et notre [guide technique robots.txt et sitemap XML](/robots-txt-sitemap-xml-guide-technique-seo).
**Ne comptez pas sur TDMRep pour peser sur vos citations dans les IA génératives.** C'est un mécanisme d'opt-out juridique, pas un levier de visibilité. Si votre sujet est la citabilité par les moteurs génératifs, l'angle utile est ailleurs : nous avons déjà démonté ce mythe pour un fichier voisin dans notre article sur [llms.txt et son adoption réelle](/llms-txt-standard-robots-txt-ia-generative-2026), et la question des droits voisins des éditeurs face aux AI Overviews est traitée dans notre article sur [Google AI Overviews et l'opt-out des droits voisins en France](/google-ai-overviews-france-droits-voisins-opt-out-2026). Pour vérifier que le crawler qui lit vos fichiers TDMRep est bien celui qu'il prétend être, notre article sur la [vérification de l'authenticité des crawlers IA par plage IP](/verifier-authenticite-crawlers-ia-ip-ranges-2026) couvre la partie technique.
Je n'ai pas de certitude sur l'issue de ce dossier. Le groupe W3C attend l'IETF, la Commission attend sa consultation, la cour d'appel de Hambourg attend le BGH. Personne, au moment où j'écris ces lignes, n'a tranché lequel des huit protocoles candidats deviendra la référence, ni même s'il y en aura une seule.
## Questions fréquentes
### TDMRep est-il un standard officiel du W3C ?
Non. C'est un « Final Community Group Report », publié le 10 mai 2024 par un groupe communautaire du W3C. La spécification précise elle-même qu'il n'est « pas un W3C Standard » et n'est « pas sur la voie des normes W3C ». Un rapport de groupe communautaire n'a pas le même statut qu'une recommandation W3C.
### Combien de techniques la spécification propose-t-elle pour déclarer une réserve ?
Quatre : un fichier `tdmrep.json` dans `/.well-known`, un en-tête HTTP, une balise meta HTML, et des métadonnées dans les documents EPUB 2, EPUB 3 ou PDF. La spécification recommande de n'en utiliser qu'une seule à la fois pour éviter les conflits de priorité entre techniques.
### Un tribunal a-t-il déjà validé TDMRep ?
Non, aucune décision connue ne porte sur TDMRep lui-même. Le seul contentieux identifié, entre le photographe Robert Kneschke et LAION e.V. devant les juridictions de Hambourg, tranche uniquement le critère général de lisibilité par machine d'une réserve. La cour d'appel a par ailleurs autorisé un pourvoi devant la Cour fédérale de justice allemande.
### robots.txt et TDMRep ont-ils la même valeur légale ?
Non selon les textes disponibles. Le code de bonnes pratiques pour l'IA à usage général nomme explicitement `robots.txt` et sa RFC 9309 dans son engagement principal. TDMRep relève d'un second engagement, plus général, sur les protocoles alternatifs « appropriés », sans être cité nommément à ce jour.
### Que se passe-t-il si le champ tdm-reservation contient une autre valeur que 0 ou 1 ?
La spécification traite toute autre valeur comme une erreur de protocole. Dans ce cas, l'agent de fouille doit considérer que `tdm-reservation` n'est pas défini, comme si le champ était absent.
## Sources
- W3C, [spécification TDM Reservation Protocol, Final Community Group Report du 10 mai 2024](https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240510/)
- W3C, [page du groupe communautaire TDMRep, gouvernance et notes de réunion](https://www.w3.org/community/tdmrep/)
- EUR-Lex, [directive (UE) 2019/790, texte officiel français, article 4](https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32019L0790)
- Légifrance, [article L122-5-3 du code de la propriété intellectuelle](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000044363192)
- EUR-Lex, [règlement (UE) 2024/1689 sur l'intelligence artificielle, article 53](https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32024R1689)
- Commission européenne, [code de bonnes pratiques pour l'IA à usage général, date et liste des signataires](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai)
- Commission européenne, [texte officiel du code de bonnes pratiques GPAI (PDF)](https://ec.europa.eu/newsroom/dae/redirection/document/118115)
- Commission européenne, [FAQ de la consultation sur les protocoles de réservation de droits, les huit solutions candidates](https://digital-strategy.ec.europa.eu/en/faqs/stakeholder-consultation-ai-and-copyright-compliance)
- Commission européenne, [ouverture et clôture de la consultation sur les protocoles de réservation](https://digital-strategy.ec.europa.eu/en/consultations/commission-launches-consultation-protocols-reserving-rights-text-and-data-mining-under-ai-act-and)
- IETF, [RFC 9309, Robots Exclusion Protocol](https://www.rfc-editor.org/rfc/rfc9309.html)
- IETF Datatracker, [groupe de travail AI Preferences](https://datatracker.ietf.org/wg/aipref/about/)
- Paul Keller, [Kluwer Copyright Blog, analyse de la décision OLG Hamburg du 10 décembre 2025](https://legalblogs.wolterskluwer.com/copyright-blog/laion-round-2-machine-readable-but-still-not-actionable-the-lack-of-progress-on-tdm-opt-outs-part-1/)
- Ekaterina Filikhina et Lennart Elsass, [DLA Piper, Technology's Legal Edge, analyse de la même décision](https://www.technologyslegaledge.com/2025/12/robert-kneschke-v-laion-judgment-of-10-december-2025-ref-5-u-104-24/)
- Marcus von Welser, [VOSSIUS, analyse de l'arrêt de l'OLG Hamburg sur les jeux de données d'entraînement](https://www.vossius.eu/de/news/detail/urteil-des-olg-hamburg-zu-ki-trainingsdatensaetzen)
---
## Vrai ou faux GPTBot ? Vérifier un crawler IA en 2026
- URL: https://www.referencement-internet-web.com/verifier-authenticite-crawlers-ia-ip-ranges-2026/
- Author: Lucas M.
- Published: 2026-08-04T06:00:00
- Categories: seo
Ouvrez un terminal, tapez `curl -A "compatible; GPTBot/1.4; +https://openai.com/gptbot" https://votresite.fr`, et votre log serveur enregistrera une visite de GPTBot. Sauf qu'OpenAI n'a rien demandé. Le user-agent est une chaîne de caractères que le client envoie lui-même, personne ne la signe, personne ne la contrôle. C'est exactement le problème du dev qui fait confiance aux données venues du client : ça marche jusqu'au jour où quelqu'un a envie de tricher.
**Un user-agent ne prouve rien. La seule vérification qui tient est l'adresse IP source : on la compare aux fichiers JSON de plages publiés par chaque opérateur, récupérés en direct. Google et Common Crawl acceptent en plus un contrôle par DNS inverse. OpenAI, Anthropic et Perplexity, non : chez eux, l'adresse IP est le seul point d'appui.**
## Pourquoi le user-agent est la mauvaise preuve
Dans un jeu multijoueur, on ne demande jamais au client combien de points de vie il lui reste. Il mentirait. Le serveur garde l'autorité, le client n'envoie que des intentions. Le web des crawlers fonctionne selon le même principe, sauf que beaucoup d'administrateurs raisonnent encore comme si le user-agent faisait foi.
Or il déclare deux choses distinctes qu'on confond en permanence : qui crawle, et pourquoi. Chez OpenAI, GPTBot collecte pour l'entraînement des modèles et respecte robots.txt, tandis que ChatGPT-User exécute une action déclenchée par un humain. La documentation d'OpenAI le dit sans détour à propos de ce dernier : « these actions are initiated by a user, robots.txt rules may not apply ». Même entreprise, même infrastructure, comportement inverse face à vos directives. OAI-SearchBot, lui, respecte l'opt-out pour les résultats de recherche.
Conclusion pratique : raisonner par entreprise ne mène nulle part, il faut raisonner par user-agent. Et comme cette chaîne se falsifie en une ligne de commande, il faut ensuite la confronter à quelque chose que l'attaquant ne contrôle pas.
## Ce que chaque opérateur publie réellement
J'ai récupéré les fichiers officiels un par un plutôt que de recopier un tableau trouvé ailleurs. Voici l'état au 28 juillet 2026.
| Crawler | Fichier d'adresses IP | DNS inverse documenté | robots.txt |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------- | ---------------------------------------------------------- |
| GPTBot (entraînement) | `openai.com/gptbot.json`, 21 blocs CIDR IPv4, mise à jour du 30 octobre 2025 | Non | Respecté |
| ChatGPT-User (action utilisateur) | `openai.com/chatgpt-user.json`, 373 blocs CIDR, mise à jour du 23 juillet 2026 | Non | Peut ne pas s'appliquer, action initiée par un utilisateur |
| OAI-SearchBot (recherche) | `openai.com/searchbot.json`, 35 blocs CIDR, mise à jour du 2 janvier 2026 | Non | Respecté, opt-out des résultats de recherche |
| ClaudeBot, Claude-User, Claude-SearchBot | `claude.com/crawling/bots.json`, fichier unique commun aux trois, 20 entrées, mise à jour du 1er mai 2026 | Non | Respecté, extension `Crawl-delay` supportée |
| Googlebot (et le jeton Google-Extended) | Vérification officielle fondée sur le DNS, colonne suivante | Oui, en deux temps | Respecté |
| PerplexityBot | `www.perplexity.ai/perplexitybot.json`, 8 entrées seulement, mise à jour du 7 février 2025 | Non | Respecté |
| Perplexity-User | Un fichier dédié est cité dans la documentation, non récupéré lors de cette vérification | Non | Généralement ignoré, action utilisateur |
| CCBot (Common Crawl) | `index.commoncrawl.org/ccbot.json`, IPv4 et IPv6 | Oui, IPv4 uniquement | Respecté |
Deux détails de ce tableau méritent qu'on s'y arrête.
Le fichier d'Anthropic est unique et partagé. Sa structure se résume à une clé `creationTime` et une liste `prefixes`, sans aucun champ nommant l'agent. Un bloc en /22 sur 216.73.216.0/22, dix-neuf adresses individuelles en /32 sur des plages 34.x, 35.x et 136.x, et c'est tout. Conséquence directe : l'adresse IP vous dit qu'une requête vient bien d'Anthropic, jamais lequel des trois bots l'a émise. Pour ça, vous n'avez que le user-agent, celui-là même qui ne prouve rien. La chaîne de preuve se coupe à cet endroit précis, et aucune bidouille serveur ne la recolle.
Second détail, les dates. Le fichier de GPTBot date d'octobre 2025, celui de ChatGPT-User de juillet 2026, celui de PerplexityBot de février 2025. Ces listes bougent à des rythmes complètement différents, et l'écart de volume est du même ordre : 8 entrées chez Perplexity contre 373 chez ChatGPT-User. Toute personne qui colle ces plages en dur dans une conf nginx signe une régression à retardement.
## Google-Extended n'est pas un crawler, arrêtez de chercher ses IP
C'est l'erreur que je vois passer le plus souvent, et elle fait perdre des heures. Google-Extended n'a ni plages d'adresses, ni user-agent, ni DNS propre. C'est un jeton lu dans robots.txt par l'infrastructure de crawl existante de Google, qui contrôle si votre contenu sert à entraîner les modèles Gemini et les API génératives de Vertex AI. Google le présente comme un contrôle laissé à l'administrateur du site, pas comme un robot supplémentaire.
Donc : vous ne verrez jamais `Google-Extended` dans vos logs, et vous ne trouverez jamais sa liste d'adresses, parce qu'elle n'existe pas. La requête qui arrive, c'est Googlebot, et c'est Googlebot qu'on vérifie. Le jeton agit en amont, sur l'usage du contenu, pas sur la connexion.
## La procédure, étape par étape
Voilà ce que je mets en place. Rien d'exotique, mais l'ordre compte.
**1. Extrayez le couple user-agent, adresse IP de vos logs.** Pas le user-agent seul. Une ligne de log sans son IP source est inexploitable pour cette vérification. Si vous croisez déjà [vos logs serveur avec le Crawl Stats de la Search Console](/analyse-logs-serveur-crawl-stats-gsc-2026), la donnée est en place.
**2. Récupérez les fichiers JSON en direct, dans le script.** Un `fetch` au moment du contrôle, ou un cache court avec revalidation. Jamais de plages copiées à la main dans un fichier de conf. Les dates de mise à jour du tableau ci-dessus suffisent à démontrer pourquoi.
**3. Faites le match CIDR, pas une comparaison de chaînes.** Une adresse contenue dans 216.73.216.0/22 ne « ressemble » à rien textuellement. Il faut convertir en entier et masquer, ce que fait n'importe quelle bibliothèque d'adressage réseau de votre langage. C'est cinq lignes de code, et c'est la seule étape qui produit une vraie décision binaire.
**4. Pour Googlebot, passez au DNS inverse en deux temps.** La procédure officielle de Google demande d'abord un `host [IP]` sur l'adresse relevée dans les logs, puis de vérifier que le nom obtenu se termine par `googlebot.com`, `google.com` ou `googleusercontent.com`. Ensuite seulement, un `host [domaine]` doit renvoyer l'adresse de départ. C'est ce second aller-retour, le forward-confirmed reverse DNS, qui fait la preuve : un attaquant peut contrôler la zone inverse d'une IP, il ne contrôle pas la zone directe de google.com.
**5. Même logique pour CCBot, avec sa limite.** Common Crawl documente un DNS inverse fonctionnel : l'adresse 18.97.14.84 résout en `18-97-14-84.crawl.commoncrawl.org`. C'est valable en IPv4 seulement, la documentation précise que l'IPv6 n'est pas encore supporté. Si votre serveur est joignable en IPv6, prévoyez le repli sur le match CIDR.
**6. Journalisez le verdict, ne bloquez pas dans la foulée.** Un booléen `verified` à côté de chaque ligne de log vaut mieux qu'une règle WAF écrite à chaud. Vous saurez au bout d'une semaine quelle proportion de votre trafic « IA » est authentique.
Une remarque sur l'étape 2 : sur un petit site à faible trafic, figer les plages une fois par trimestre m'a paru raisonnable pendant des années. J'hésite encore, honnêtement. Le compromis se défend tant que quelqu'un tient le calendrier, et il tombe le jour où cette personne change de poste.
## Le cas Perplexity, ou pourquoi la liste d'IP ne suffit pas
En août 2025, Cloudflare a publié une analyse technique documentant un crawler qu'il qualifie de furtif : un user-agent générique imitant Chrome sur macOS, entre 3 et 6 millions de requêtes par jour, des adresses situées hors des plages officiellement publiées par Perplexity, et des changements d'ASN décrits comme des tentatives de contourner les blocages. Le test portait sur des dizaines de milliers de domaines fraîchement enregistrés avec un robots.txt restrictif. Je m'en tiens à ce que Cloudflare a publié : aucune réponse de Perplexity sur ces accusations n'a été retrouvée lors de cette vérification, je ne lui prête donc aucune position.
Ce qui m'intéresse ici, c'est la mécanique. Un crawler qui ne veut pas être identifié n'annonce pas un user-agent de crawler. Votre contrôle d'authenticité renverra donc « non vérifié » sur une requête qui se présente comme un navigateur ordinaire, et vous ne saurez rien de plus. La vérification par IP prouve l'authenticité d'un bot déclaré, elle ne détecte pas un bot qui se cache. Ce sont deux problèmes différents, et le second relève de la [détection comportementale côté CDN](/cloudflare-ai-audit-paywall-juin-2026-bots-crawl).
Le tableau plus haut distingue d'ailleurs deux réalités qu'on empile souvent sous « Perplexity ignore robots.txt » : Perplexity-User l'ignore généralement, c'est documenté et assumé puisqu'un humain déclenche la requête, tandis que PerplexityBot, le crawler documenté, le respecte. L'accusation de Cloudflare porte sur un troisième acteur, non déclaré.
## Ce que vous faites du verdict
Vérifier n'est pas bloquer. Anthropic déconseille explicitement le blocage par adresse IP, pour une raison de mécanique interne : couper l'IP peut empêcher ses bots de lire votre robots.txt, et ne garantit donc pas l'opt-out que vous cherchiez. Vous obtenez le pire des deux mondes, un bot qui n'entre plus et qui n'a jamais lu votre refus.
L'authenticité sert à autre chose : à savoir si votre politique s'applique à du trafic réel. Décider quels crawlers autoriser est un autre débat, traité dans notre article sur [la stratégie robots.txt des éditeurs face aux bots IA](/crawl-ia-bots-gptbot-claudebot-robots-txt-editeurs-2026). La vérification, elle, dit simplement si les lignes que vous écrivez dans [robots.txt](/robots-txt-sitemap-xml-guide-technique-seo) ou dans [un fichier llms.txt](/llms-txt-standard-robots-txt-ia-generative-2026) parlent à quelqu'un.
## FAQ
### Le user-agent GPTBot peut-il être falsifié ?
Oui, en une seule commande. Un user-agent est une chaîne envoyée par le client, sans signature ni contrôle. Seule la comparaison de l'adresse IP source avec le fichier `openai.com/gptbot.json` publié par OpenAI permet de trancher. OpenAI ne documente aucune autre méthode de vérification.
### Comment vérifier Googlebot officiellement ?
Google demande un DNS inverse sur l'adresse relevée dans vos logs avec la commande `host`, et vérifie que le nom obtenu appartient à `googlebot.com`, `google.com` ou `googleusercontent.com`. Une seconde requête DNS directe sur ce nom doit renvoyer l'adresse de départ. Les deux étapes sont nécessaires.
### Peut-on distinguer ClaudeBot de Claude-User par l'adresse IP ?
Non. Anthropic publie une liste d'adresses unique et commune à ClaudeBot, Claude-User et Claude-SearchBot, sans aucun champ distinguant les trois agents. L'adresse IP confirme l'origine Anthropic, rien de plus. Seul le user-agent nomme l'agent, et il ne constitue pas une preuve.
### Où trouver les plages IP de Google-Extended ?
Nulle part, et c'est normal. Google-Extended n'est pas un crawler mais un jeton lu dans robots.txt par l'infrastructure de crawl de Google, qui contrôle l'usage du contenu pour l'entraînement de ses modèles génératifs. Les requêtes proviennent de Googlebot, dont la vérification suit la procédure DNS officielle.
### Faut-il copier les plages IP dans sa configuration serveur ?
Non. Les fichiers évoluent à des rythmes très différents selon les opérateurs : octobre 2025 pour GPTBot, juillet 2026 pour ChatGPT-User, février 2025 pour PerplexityBot. Une liste figée devient fausse sans prévenir. Le script doit interroger l'URL officielle au moment du contrôle.
## Sources
- [OpenAI, documentation des bots](https://developers.openai.com/api/docs/bots)
- [Anthropic, does Anthropic crawl data from the web](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)
- [Fichier d'adresses des bots Anthropic](https://claude.com/crawling/bots.json)
- [Google Search Central, verifying Googlebot and other crawlers](https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot)
- [Google, an update on web publisher controls](https://blog.google/technology/ai/an-update-on-web-publisher-controls/)
- [Perplexity, guide des bots](https://docs.perplexity.ai/guides/bots)
- [Cloudflare, Perplexity is using stealth, undeclared crawlers](https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/)
- [Common Crawl, CCBot](https://commoncrawl.org/ccbot)
---
## Tableaux et listes : formater ses données pour l'IA
- URL: https://www.referencement-internet-web.com/donnees-structurees-extraction-ia-tableaux-listes/
- Author: Lucas M.
- Published: 2026-08-03T06:00:00
- Categories: seo
Tous les guides GEO répètent la même phrase : « faites des tableaux, des listes, du FAQ ». Aucun ne dit comment construire ces tableaux. J'ai passé assez de temps à écrire des parseurs pour savoir qu'un tableau mal foutu, avec des cellules fourre-tout et des colonnes sans en-tête, c'est un tableau qu'aucune machine ne lit proprement. Formater ses données pour l'extraction par l'IA, ce n'est pas cocher la case « j'ai mis un tableau ». C'est appliquer des règles de construction précises à chaque donnée factuelle.
Pour formater une donnée extractible par l'IA : un tableau si l'item porte trois informations liées ou plus, une liste sinon ; une cellule de deux phrases maximum ; un en-tête explicite par colonne ; une unité jamais ambiguë. La donnée doit se comprendre seule, sans le paragraphe autour. Le balisage schema.org, lui, n'est pas le levier.
## Tableau ou liste : comment trancher ?
La première décision, avant même d'écrire une ligne, c'est le contenant. Et là, il existe une règle concrète que le SERP marketing n'évoque jamais. Le guide de rédaction technique de Google la pose noir sur blanc : un tableau se justifie quand chaque item porte trois données liées ou plus. En dessous, une liste fait mieux le travail.
Concrètement : « nom du bot, éditeur, respecte robots.txt » par ligne, ça fait trois attributs par entité, donc tableau. « Les trois étapes du pipeline RAG », ça n'a qu'une dimension par item, donc liste numérotée. Se tromper de contenant, c'est forcer l'extracteur à deviner la structure, et un extracteur qui devine se plante.
Cette logique de découpage prolonge celle des [passages autonomes citables par l'IA](/contenu-citable-ia-rag-passages-autonomes-geo/), mais elle descend un cran plus bas : au niveau de la donnée elle-même, pas de la section. Sous le capot, c'est la même contrainte : le bloc sera lu isolé, jugé isolé, cité isolé.
## Comment construire un tableau qu'une machine lit vraiment ?
Un tableau visuellement propre dans votre navigateur peut être illisible pour un parseur. La différence se joue dans le HTML, et le W3C Web Accessibility Initiative donne la structure minimale : les en-têtes marqués `
`, l'attribut `scope="col"` ou `scope="row"` pour dire à quelle colonne ou ligne un en-tête s'applique, un `` pour nommer le tableau. Sans ça, une cellule de donnée flotte sans repère : la machine voit « 941 » mais ne sait pas que c'est un nombre de mots.
C'est exactement le même mécanisme que celui qui rend une page accessible aux lecteurs d'écran. J'ai longtemps cru que l'accessibilité et l'extraction IA étaient deux chantiers séparés. Ce sont les mêmes balises, le même bénéfice : ce qui aide un lecteur d'écran à annoncer « colonne Mots, valeur 941 » aide un modèle à rattacher la valeur à son en-tête. Le sujet recoupe directement l'[accessibilité comme facteur SEO](/accessibilite-wcag-facteur-seo-cache-trafic-2026/).
Deux règles de contenu complètent la structure. D'abord, une cellule de deux phrases maximum : au-delà, Google recommande de reconsidérer le tableau, parce qu'une cellule qui devient un paragraphe casse la logique tabulaire. Ensuite, un en-tête qui veut dire quelque chose. « Valeur » ne veut rien dire. « Taux d'échec de récupération » situe la donnée. Un en-tête vague, c'est une donnée orpheline.
Pour les devs dans la salle : introduisez toujours le tableau par une phrase avant de l'afficher. L'extracteur s'appuie sur cette phrase de contexte pour rattacher l'ensemble au sujet. Un tableau qui tombe sans intro, c'est une donnée sans amarre.
## Une donnée sans unité explicite ne vaut rien : pourquoi ?
Voilà l'erreur que je vois le plus. On écrit « 512 » en pensant que le contexte suffit. Pour un humain qui lit le paragraphe, oui. Pour une donnée arrachée à son paragraphe, non : 512 quoi ? Des tokens, des mots, des mégaoctets ?
Schema.org a une réponse dédiée pour lever cette ambiguïté. La propriété `unitCode` attend un code UN/CEFACT de trois caractères, ou une URL. Le principe, cité par schema.org : les ordinateurs comprennent ces codes de façon plus fiable « parce qu'il existe exactement une séquence par signification ». Quand il n'existe pas de code standard, `unitText` prend le relais en texte libre. L'idée n'est pas de tout baliser, c'est de comprendre le principe et de l'appliquer d'abord dans le texte visible : nommez l'unité à côté du chiffre, toujours.
Anthropic a documenté la version radicale de ce principe dans son billet d'ingénierie « Contextual Retrieval » (19 septembre 2024). En préfixant chaque extrait d'un court résumé de 50 à 100 tokens qui situe la donnée dans son document, le taux d'échec de récupération chute fortement : de 35 % avec les seuls embeddings contextuels, jusqu'à 49 % en ajoutant un BM25 contextuel, et 67 % avec un reranking, sur une base de 5,7 % d'échec. Leur exemple : un extrait brut « le chiffre d'affaires a progressé de 3 % » ne dit ni de quelle entreprise ni de quel trimestre. Contextualisé, il devient « This chunk is from an SEC filing on ACME corp's performance in Q2 2023 ». Vous ne contrôlez pas le préfixe que le moteur ajoute. Vous contrôlez une chose : écrire des données qui portent déjà leur contexte, pour ne pas dépendre de cette béquille.
## Quel formatage pèse vraiment sur les citations ?
Ici, il faut être honnête sur ce que la recherche mesure et ne mesure pas. L'étude académique de référence sur le GEO (Aggarwal et al., Princeton, acceptée à KDD 2024) a quantifié l'effet de plusieurs méthodes d'optimisation sur la visibilité en réponse générative. Voici son classement, en amélioration relative du « Position-Adjusted Word Count » par rapport à la baseline :
| Méthode d'optimisation testée | Gain relatif vs baseline |
| ----------------------------- | ------------------------ |
| Ajout de citations/quotations | ~41 % |
| Ajout de statistiques | ~31 % |
| Citation de sources | ~28 % |
| Optimisation de fluidité | ~28 % |
| Ajout de termes techniques | ~18 % |
| Simplicité du langage | ~13 % |
| Signaux d'autorité | ~12 % |
| Ajout de mots uniques | ~6 % |
| Keyword stuffing | ~-8 % |
La nuance qui change tout : cette étude ne teste pas le formatage en tableau ou en liste comme méthode distincte. Ce qu'elle mesure, c'est la densité de faits sourcés, de statistiques et de citations. Autrement dit, le tableau n'est pas la cause magique, il est le contenant qui rend ces faits denses et extractibles. Le keyword stuffing, lui, dégrade la performance. La leçon est presque contre-intuitive : soignez la donnée avant le contenant.
Reste le mythe du balisage. Une bonne moitié des guides GEO recommandent d'« ajouter du schema.org » pour se faire citer. Deux études récentes contredisent ce conseil. Ahrefs a suivi 1 885 pages ayant ajouté du JSON-LD entre août 2025 et mars 2026, contre 4 000 pages témoins : sur Google AI Overviews, l'effet mesuré est de -4,6 % (baisse statistiquement significative), et non significatif ailleurs. Search Atlas, en classant des domaines par tranche de couverture schema (de 0 à 100 %), trouve des distributions de visibilité quasi identiques d'une tranche à l'autre. Google le confirme dans sa doc : « il n'y a pas de données structurées schema.org spéciales à ajouter » pour apparaître dans les fonctionnalités IA.
Il faut distinguer deux choses que le SERP confond en permanence : le formatage de la donnée (tableaux, listes, unités, effet réel sur la lisibilité et l'extraction) et le balisage schema.org (effet sur la citation non démontré par ces études). Le balisage garde son utilité pour la compréhension structurelle et l'indexation classique, sujet détaillé dans le [guide des données structurées et schema markup](/schema-markup-donnees-structurees-seo/) et dans [ce que les annonces schema.org taisent](/schema-org-v31-juin-2026-product-aimodel-citation/). Mais comme levier de citation, non. Ce n'est pas un bug, c'est une feature : les moteurs récompensent le contenu visible, pas la plomberie invisible.
## Google assemble déjà vos tableaux : faut-il anticiper ?
Un signal à ne pas ignorer. À Google I/O 2026 (19 mai), l'entreprise a annoncé une « generative UI » : Search assemble désormais lui-même des tableaux, graphiques et visuels en temps réel à partir de composants, avec un déploiement prévu à l'été 2026. Dans le même temps, AI Mode a dépassé le milliard d'utilisateurs mensuels, avec un volume de requêtes qui double chaque trimestre depuis son lancement.
La lecture que j'en fais : si le moteur reconstruit lui-même la présentation, il a besoin d'une donnée source propre à assembler. Une donnée bien étiquetée, unité comprise, en-tête clair, devient de la matière première réutilisable. Là je m'avance peut-être, je n'ai pas encore vu la generative UI tourner à grande échelle. Mais la direction est cohérente avec ce que Microsoft dit déjà de son côté : titres clairs, tableaux et sections FAQ aident les systèmes IA à faire remonter l'information clé. Ni OpenAI ni Perplexity ne publient de préférence de format dans leur doc crawler, donc pas de recette officielle à suivre au-delà de ça.
## FAQ
### Faut-il mettre un tableau ou une liste pour être extractible ?
Un tableau se justifie quand chaque item porte trois informations liées ou plus, selon le guide de rédaction technique de Google. En dessous, une liste est plus lisible pour une machine. Le critère n'est pas esthétique : il tient à la structure de vos données. Un tableau utilisé pour une donnée à une seule dimension force l'extracteur à deviner, et il se trompe.
### Comment rendre un tableau lisible par une IA ?
Marquez les en-têtes en `| ` avec l'attribut `scope`, ajoutez un `` (recommandation W3C WAI), limitez chaque cellule à deux phrases et donnez un en-tête explicite à chaque colonne. Introduisez toujours le tableau par une phrase de contexte. Ces règles rejoignent celles de l'accessibilité : ce qui aide un lecteur d'écran aide un modèle à rattacher une valeur à son en-tête.
### Le balisage schema.org aide-t-il à se faire citer par l'IA ?
Pas comme levier de citation. L'étude Ahrefs (mai 2026) mesure -4,6 % sur Google AI Overviews après ajout de JSON-LD, et Search Atlas ne trouve aucune corrélation entre couverture schema et visibilité. Google confirme n'exiger aucun balisage spécial pour ses fonctionnalités IA. Le schema reste utile pour la compréhension structurelle et l'indexation classique, pas pour être cité.
### Pourquoi préciser l'unité d'une donnée ?
Parce qu'une donnée extraite perd son paragraphe. « 512 » isolé ne dit pas s'il s'agit de tokens, de mots ou de mégaoctets. Schema.org prévoit `unitCode` (code UN/CEFACT) et `unitText` justement pour lever cette ambiguïté. Dans le texte visible, la règle est simple : nommez l'unité à côté du chiffre, toujours.
## La donnée avant le contenant
Le réflexe « je mets un tableau » ne suffit pas. Ce qui compte, c'est la donnée dedans : trois attributs liés ou plus pour justifier le tableau, une cellule courte, un en-tête qui situe, une unité nommée. Le formatage n'invente rien, il rend extractible ce qui est déjà solide. Le schema.org et les balises exotiques relèvent du confort, pas du levier. Et si vous voulez remonter d'un cran vers la structure de page, le point de départ reste [le guide GEO complet](/geo-generative-engine-optimization-guide/). À vos tableaux.
## Sources
- [GEO: Generative Engine Optimization, Aggarwal et al., arXiv](https://arxiv.org/abs/2311.09735)
- [Contextual Retrieval, Anthropic Engineering](https://www.anthropic.com/engineering/contextual-retrieval)
- [Lists and tables, Google Technical Writing](https://developers.google.com/tech-writing/one/lists-and-tables)
- [Tables Tutorial, W3C Web Accessibility Initiative](https://www.w3.org/WAI/tutorials/tables/)
- [unitCode, Schema.org](https://schema.org/unitCode)
- [AI Features and Your Website, Google Search Central](https://developers.google.com/search/docs/appearance/ai-features)
- [We tracked 1885 pages adding schema, Ahrefs](https://ahrefs.com/blog/schema-ai-citations/)
- [The Limits of Schema Markup for AI Search, Search Atlas](https://searchatlas.com/blog/limits-of-schema-markup-for-ai-search/)
- [Search's I/O 2026 updates, Google](https://blog.google/products-and-platforms/products/search/search-io-2026/)
- [Introducing AI Performance in Bing Webmaster Tools, Bing Blog](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview)
---
## Contenu citable par l'IA : la méthode en 5 étapes
- URL: https://www.referencement-internet-web.com/contenu-citable-ia-rag-passages-autonomes-geo/
- Author: Lucas M.
- Published: 2026-07-31T06:00:00
- Categories: seo
Un moteur génératif ne cite pas une page. Il cite un passage. J'ai compris cette distinction pour de bon en montant un pipeline RAG maison sur un week-end : le modèle ne reçoit jamais votre article complet, il reçoit un morceau de quelques centaines de mots, découpé par un algorithme, et il répond à partir de ce morceau. Rendre un contenu citable par l'IA, ce n'est donc pas optimiser une page. C'est fabriquer des passages autonomes, des blocs qui gardent leur sens une fois arrachés au reste.
Pour rendre un contenu citable par l'IA, découpez chaque section en passages autonomes : un H2 formulé comme une question, une réponse directe de 40 à 80 mots en tête, une entité nommée et une donnée sourcée. Le moteur extrait ce bloc sans le reste de la page. Le balisage schema.org, lui, ne fait pas le travail.
## Pourquoi l'IA cite un passage, pas une page ?
Sous le capot, un moteur comme ChatGPT Search, Perplexity ou Google AI Mode fait du RAG : il récupère des fragments de documents (retrieval), puis génère une réponse à partir de ces fragments. Google décrit d'ailleurs sa propre technique de « query fan-out » : il émet plusieurs recherches liées sur des sous-sujets, puis assemble la réponse à partir des sources appariées. Votre page n'entre jamais entière dans ce circuit. Elle est découpée en chunks avant d'être indexée.
Ce découpage, c'est le maillon fragile. Un chunk mal coupé, qui commence au milieu d'une idée et se termine avant la donnée clé, devient inexploitable. Anthropic l'a chiffré dans son billet d'ingénierie « Contextual Retrieval » (19 septembre 2024) : en préfixant chaque chunk d'un court contexte de 50 à 100 tokens généré par le modèle, le taux d'échec de récupération chute nettement.
| Configuration du pipeline RAG | Taux d'échec de récupération | Réduction |
| ----------------------------- | ---------------------------- | --------- |
| Embeddings seuls (référence) | 5,7 % | base |
| + Contextual Embeddings | 3,7 % | -35 % |
| + Contextual BM25 | 2,9 % | -49 % |
| + reranking | 1,9 % | -67 % |
L'exemple d'Anthropic est parlant. Un chunk brut disait « The company's revenue grew by 3 % over the previous quarter » sans dire de quelle entreprise ni de quel trimestre il s'agissait. Contextualisé, il devient « This chunk is from an SEC filing on ACME corp's performance in Q2 2023 ; the previous quarter's revenue was $314 million », suivi du contenu d'origine. Ce préfixe, vous ne le pilotez pas. Ce qui reste dans vos mains, c'est d'écrire des passages qui se suffisent à eux-mêmes, au lieu d'attendre du moteur qu'il les rattrape.
C'est là que le GEO (Generative Engine Optimization) prend son sens. Le terme vient d'un papier de recherche fondateur (Aggarwal et al., Princeton, Georgia Tech, Allen Institute for AI, arXiv 2311.09735, accepté à KDD 2024) qui mesure jusqu'à 40 % de gain de visibilité dans les réponses génératives selon la façon dont le contenu est structuré. Pour le cadre général, le sujet est détaillé dans le [guide GEO complet](/geo-generative-engine-optimization-guide/).
## À quoi ressemble une page réellement citée ?
Plusieurs études indépendantes ont mesuré la structure des pages effectivement citées par les moteurs IA. Croisées, elles dessinent une grille de référence que les guides marketing génériques ne donnent presque jamais. La médiane calculée par Evertune sur 33 000 URLs massivement citées par ChatGPT :
| Élément mesuré | Médiane d'une page citée par ChatGPT | Source |
| -------------------------- | ------------------------------------ | ---------------------- |
| Nombre de mots | 941 | Evertune (33 000 URLs) |
| Paragraphes | 18 | Evertune |
| Longueur moyenne de phrase | 17 mots | Evertune |
| Titres H2 / H3 | 4 / 2 | Evertune |
| Liens internes / externes | 28 / 15 | Evertune |
| Listes structurées | 2 | Evertune |
Deux enseignements. D'abord, la hiérarchie de titres compte : selon AirOps (12 000 URLs analysées), 68,7 % des pages citées par ChatGPT suivent une structure de titres séquentielle correcte (H1 vers H2 vers H3, sans saut), contre environ un quart des résultats classiques de la page 1 de Google. Ces mêmes pages comptent en moyenne 13,75 sections avec listes. Un extracteur RAG s'appuie sur ces balises pour découper proprement : un plan mal titré, il le coupe n'importe où.
Ensuite, la fraîcheur et l'autorité pèsent lourd. L'étude Ahrefs sur les 1000 pages les plus citées par ChatGPT (septembre 2025) montre un DR médian de 90, une présence organique Google pour 71,7 % d'entre elles, et surtout 76,4 % mises à jour dans les 30 jours précédant l'analyse. Wikipedia rafle 29,7 % des citations, les pages d'accueil 23,8 %, le contenu éducatif 19,4 %. Traduction pour un site normal : sans signal de qualité préexistant, la meilleure structure du monde ne suffira pas. La structure ouvre la porte, l'autorité la franchit.
## La méthode : 5 étapes pour des passages autonomes
Voici le workflow que j'applique, section par section. L'idée directrice : chaque bloc doit survivre à l'extraction.
1. **Formulez le H2 comme une question.** « Pourquoi l'IA cite un passage » plutôt que « Le fonctionnement du RAG ». Le titre en question colle à la requête que l'utilisateur tape et sert de clé d'appariement. C'est le même principe que pour décrocher un [featured snippet](/featured-snippets-position-zero-guide/), poussé un cran plus loin.
2. **Ouvrez chaque section par une réponse directe de 40 à 80 mots.** Le premier paragraphe répond à la question du titre, complètement, sans renvoyer à « comme vu plus haut ». C'est le bloc que le moteur va extraire. Le storytelling, les nuances, les exemples viennent après. Jamais avant.
3. **Ancrez une entité nommée et une donnée sourcée dans le passage.** Un chunk qui contient « selon Ahrefs, 76,4 % des pages citées » se contextualise tout seul. Un chunk qui dit « la plupart des pages » ne vaut rien une fois isolé. Les [données propriétaires deviennent le carburant des citations](/etudes-proprietaires-citations-llm-geo-2026/) précisément pour cette raison.
4. **Calibrez la longueur du bloc sur le type de réponse visé.** Un papier de recherche (Bhat et al., arXiv 2505.21700, mai 2025) montre que les petits chunks de 64 à 128 tokens sont optimaux pour les réponses factuelles concises et riches en entités, quand les chunks plus grands préservent mieux un raisonnement narratif. En pratique, un point de départ documenté (blog technique Redis) reste 512 tokens avec 10 à 20 % de chevauchement, à ajuster ensuite. Concrètement : une définition, une donnée, un fait daté tiennent dans un passage court et dense ; une démonstration a besoin d'air.
5. **Respectez la hiérarchie de titres, sans saut.** H1 unique, H2 pour les grandes questions, H3 pour les sous-points. Pas de H2 qui saute directement à un H4 pour faire joli en CSS. L'extracteur lit l'arbre des titres pour poser les frontières de ses chunks. Un arbre propre, ce sont des coupes propres.
Une réserve, parce que je déteste les recettes vendues comme universelles : on lit partout que le chunking sémantique (regrouper par similarité d'embeddings) écrase toutes les autres méthodes. Les comparaisons publiées donnent des résultats mitigés, et sur un article déjà bien titré, un découpage basé sur la structure documentaire fait souvent aussi bien pour moins cher. Sur ce point précis, j'avoue hésiter encore selon les corpus. À benchmarker sur votre propre contenu, pas à appliquer en dogme.
## Faut-il baliser en schema.org pour être cité ?
Non, ou en tout cas pas comme levier de citation. C'est la partie qui fâche, parce qu'une bonne moitié des guides GEO recommandent encore d'« ajouter du FAQ schema » pour se faire citer. Deux faits récents cassent ce conseil.
D'abord, Google a mis fin aux rich results FAQPage. Depuis le 7 mai 2026, le résultat enrichi FAQ n'apparaît plus dans Search ; les outils associés dans la Search Console sont retirés par phases jusqu'en août 2026. Le type schema.org FAQPage reste valide et toujours lu par Google pour comprendre la page, mais sans effet visible en SERP. J'ai suivi le calendrier dans [l'analyse de la fin des FAQ rich results](/fin-faq-rich-results-google-7-mai-2026-impact-seo/).
Ensuite, une étude Ahrefs (11 mai 2026) a suivi 1 885 pages ayant ajouté du JSON-LD entre août 2025 et mars 2026, comparées à 4 000 pages témoins. Sur des pages déjà citées, l'ajout de schema.org ne change rien de mesurable : Google AI Overviews -4,6 %, AI Mode +2,4 % (non significatif), ChatGPT +2,2 % (non significatif). Le point technique qui explique tout : durant la récupération directe, les moteurs testés (ChatGPT, Claude, Perplexity, Gemini, Google AI Mode) n'ont extrait que le HTML visible. Le JSON-LD, le Microdata caché, le RDFa caché ont été ignorés.
Attention à ne pas surinterpréter dans l'autre sens. La même étude, élargie à 6 millions d'URLs, note que les pages citées portent environ 3 fois plus souvent du JSON-LD que les pages non citées. Mais Ahrefs précise que la causalité n'est pas établie : c'est une corrélation avec des sites techniquement plus matures. Le balisage accompagne la qualité, il ne la crée pas. Et Google le dit noir sur blanc dans sa doc officielle : « There's no special schema.org structured data that you need to add » pour apparaître dans AI Overviews ou AI Mode. Pour la vue d'ensemble sur l'utilité réelle du markup, voir [ce que les annonces schema.org taisent](/schema-org-v31-juin-2026-product-aimodel-citation/).
C'est un choix de conception assumé : ce qui pèse pour un moteur, c'est ce que le lecteur a sous les yeux, pas ce qu'on range dans le balisage.
## Un fichier llms.txt et des bots autorisés, ça aide ?
Le standard llms.txt propose un fichier Markdown à la racine du site (`/llms.txt`) avec un H1 obligatoire, un résumé du projet et des sections listant vos URLs au format `[nom](url) : notes`. L'idée : donner aux modèles une version concise et exploitable du site, puisque leur fenêtre de contexte ne peut pas avaler un site HTML complet. C'est propre conceptuellement. Reste que son adoption et son effet réel sont discutés, comme je le note dans [le point sur llms.txt](/llms-txt-standard-robots-txt-ia-generative-2026/).
Plus concret côté accès : vérifiez que vos passages sont bien atteignables par les crawlers IA. GPTBot et OAI-SearchBot pour OpenAI, PerplexityBot pour Perplexity, ClaudeBot et Claude-SearchBot pour Anthropic. Détail que peu de monde connaît : les trois bots d'Anthropic respectent robots.txt, y compris Claude-User pour la navigation à la demande, là où Perplexity-User et ChatGPT-User l'ignorent souvent. Bloquer par erreur un de ces agents, c'est saborder toute la méthode en amont. Le guide sur [autoriser ou bloquer GPTBot et ClaudeBot](/crawl-ia-bots-gptbot-claudebot-robots-txt-editeurs-2026/) détaille les arbitrages.
## FAQ
### Faut-il ajouter du schema FAQPage pour être cité par l'IA ?
Non. Google a retiré les rich results FAQ de Search le 7 mai 2026, et l'étude Ahrefs de mai 2026 montre que l'ajout de JSON-LD n'améliore pas mesurablement les citations IA sur des pages déjà citées. Pendant la récupération directe, les moteurs ne lisent que le HTML visible. Le vrai levier reste le contenu visible bien structuré, pas le balisage caché.
### Quelle taille de passage pour être citable par un moteur RAG ?
Selon le papier arXiv 2505.21700 (mai 2025), les chunks de 64 à 128 tokens sont optimaux pour les réponses factuelles concises et riches en entités ; les blocs plus grands conviennent mieux au raisonnement narratif. Un point de départ courant documenté par Redis est 512 tokens avec 10 à 20 % de chevauchement. Côté rédaction, visez une réponse directe de 40 à 80 mots en tête de section.
### Le JSON-LD aide-t-il vraiment les citations IA ?
Pas directement. Ahrefs observe que les pages citées portent environ 3 fois plus souvent du JSON-LD, mais souligne que la causalité n'est pas prouvée : c'est un marqueur de maturité technique, pas une cause. Google confirme n'exiger aucun balisage spécial pour AI Overviews et AI Mode. Le balisage aide la compréhension structurelle et l'indexation classique, sans être un levier de citation prouvé.
### La fraîcheur du contenu compte-t-elle pour être cité ?
Oui, fortement. L'étude Ahrefs sur les 1000 pages les plus citées par ChatGPT (septembre 2025) montre que 76,4 % d'entre elles avaient été mises à jour dans les 30 jours précédant l'analyse, avec un DR médian de 90. Un contenu daté et jamais rafraîchi part avec un lourd handicap, même parfaitement structuré.
## Le passage avant la page
Arrêtez de penser « page ». Pensez « bloc extractible ». Chaque section de votre contenu est un candidat isolé à la citation : elle sera lue seule, jugée seule, citée seule. Le H2 en question, la réponse directe en tête, l'entité nommée, la donnée sourcée, la hiérarchie propre. Le reste (le FAQ schema, le llms.txt, les balises exotiques) relève du confort, pas du levier. Pour aller plus loin sur les surfaces IA, voir [apparaître dans ChatGPT et Perplexity](/apparaitre-chatgpt-perplexity-reponses-ia/).
À vous de jouer.
## Sources
- [GEO: Generative Engine Optimization, Aggarwal et al., arXiv](https://arxiv.org/abs/2311.09735)
- [Contextual Retrieval, Anthropic Engineering](https://www.anthropic.com/engineering/contextual-retrieval)
- [Google Search Central, AI features](https://developers.google.com/search/docs/appearance/ai-features)
- [Google to no longer support FAQ rich results, Search Engine Land](https://searchengineland.com/google-to-no-longer-support-faq-rich-results-476957)
- [We tracked 1885 pages adding schema, Ahrefs](https://ahrefs.com/blog/schema-ai-citations/)
- [ChatGPT's most cited pages, Ahrefs](https://ahrefs.com/blog/chatgpts-most-cited-pages/)
- [ChatGPT content structure, AirOps](https://www.airops.com/blog/chatgpt-content-structure)
- [9 ways to structure your content to be cited by ChatGPT, Evertune](https://www.evertune.ai/resources/insights-on-ai/9-ways-to-structure-your-content-to-be-cited-by-chatgpt)
- [The llms.txt specification](https://llmstxt.org/)
- [OpenAI bots documentation](https://developers.openai.com/api/docs/bots)
- [Perplexity crawlers documentation](https://docs.perplexity.ai/docs/resources/perplexity-crawlers)
- [Anthropic crawler policy](https://privacy.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)
- [Chunking strategy for RAG pipelines, Redis](https://redis.io/blog/chunking-strategy-rag-pipelines/)
- [Rethinking Chunk Size for Long-Document Retrieval, arXiv](https://arxiv.org/abs/2505.21700)
---
## URL Inspection API : elle lit, elle n'indexe pas
- URL: https://www.referencement-internet-web.com/url-inspection-api-monitoring-indexation-2026/
- Author: Baptiste P.
- Published: 2026-07-30T06:00:00
- Categories: seo
Tu balances tes URLs dans l'API URL Inspection de Google Search Console, tu attends, et tu es persuadé que Google va toutes les avaler et les indexer d'un coup. Spoiler alert : non. Elle te dit juste ce que Google pense déjà de tes pages. C'est un moniteur, pas un bouton magique « indexe-moi ça ».
Cette API est sortie le 31 janvier 2022. Depuis, elle traîne une réputation qu'elle ne mérite pas, et je vois encore des gens la traiter comme un accélérateur d'indexation. On va remettre les choses à plat, parce que la confusion coûte du temps et du quota pour rien.
## Non, elle n'indexe rien du tout
Le point qui fâche, autant le poser tout de suite : l'API URL Inspection est en lecture seule. Elle interroge l'état d'indexation connu de Google pour une URL, elle renvoie un rapport, et c'est fini. Elle ne soumet aucune page pour exploration. Google le dit noir sur blanc dans son annonce de lancement.
C'est un peu comme ouvrir le journal des logs d'un serveur de jeu : tu vois qui s'est connecté, quand, et si le serveur a planté. Consulter le log ne fait pas apparaître de nouveaux joueurs. Là c'est pareil. Tu lis un état, tu ne le modifies pas.
Je suis tombé sur un thread Reddit où un mec s'étonnait que ses pages restaient hors index après quelques centaines d'appels à l'API. Normal : il inspectait en boucle, il ne soumettait rien. Il avait juste construit le plus beau tableau de bord de son échec d'indexation. Si l'indexation coince à la base, va plutôt regarder du côté de la [crawlabilité et de l'indexation technique](/crawlabilite-indexation-google-seo-technique/), c'est là que ça se joue.
## Ce que l'API te crache vraiment
Bon, si elle n'indexe pas, elle sert à quoi ? À monitorer. Et là, elle est plutôt généreuse. L'objet principal, `indexStatusResult`, te renvoie de quoi diagnostiquer une page sans ouvrir l'interface :
- `verdict` : PASS, FAIL ou NEUTRAL, le résumé brut de la situation
- `coverageState` : l'état de couverture en texte, celui que tu lis d'habitude dans l'interface
- `robotsTxtState` : ALLOWED ou DISALLOWED, pour savoir si ton robots.txt bloque
- `indexingState` : INDEXING_ALLOWED, ou bloqué par une balise meta ou un en-tête HTTP
- `googleCanonical` contre `userCanonical` : la canonique que Google a retenue face à celle que tu as déclarée
- `lastCrawlTime`, `pageFetchState`, `crawledAs` : quand, comment, et sur quel agent Google a crawlé
Ce couple `googleCanonical` / `userCanonical`, c'est de l'or pour un audit à l'échelle. Tu détectes en masse les pages où Google a décidé, tout seul, qu'une autre URL était la bonne. Bonne chance pour repérer ça à la main sur dix mille pages.
L'API remonte aussi un `richResultsResult` (tes données structurées et leurs erreurs) et un `ampResult` si tu as encore des pages AMP dans la nature. Franchement, la première fois que j'ai lu la doc complète, j'ai mis un moment à réaliser tout ce qu'on pouvait en tirer côté monitoring pur.
## Le quota, ce boss qu'on croit plus dur qu'il n'est
Là où beaucoup se plantent : le fameux plafond de 2 000 requêtes par jour. Sauf que ce chiffre n'est pas un mur absolu sur ton compte. C'est 2 000 requêtes par jour et 600 par minute **par propriété vérifiée**. Au niveau du projet dans la Google Cloud Console, tu montes à 10 millions de requêtes par jour et 15 000 par minute. Autant dire que le vrai goulot, c'est la propriété, pas le projet.
Et comme chaque appel n'inspecte qu'une seule URL (le champ `inspectionUrl` est au singulier, pas de traitement par lot natif), tu boucles. Une requête, une URL. Pour scanner un gros site, tu enchaînes les appels en respectant les 600 par minute.
Le contournement que tout le monde utilise : découper ton site en plusieurs propriétés Search Console (sous-domaines, sous-dossiers), chacune avec son propre quota de 2 000 par jour. Screaming Frog, qui intègre l'API pour du monitoring de masse, récupère jusqu'à 2 000 URLs par jour et par propriété sur un crawl. Multiplie les propriétés, multiplie le plafond. C'est bête mais ça marche.
Côté auth, rien d'exotique : OAuth avec le scope `webmasters` ou `webmasters.readonly`, une propriété vérifiée, et si tu passes par un compte de service, tu l'ajoutes comme utilisateur dans les paramètres de Search Console. Sans ça, l'API te claque la porte au nez. Pour tout ce qui touche au suivi post-crawl, ça se marie bien avec l'[analyse des logs serveur et des crawl stats](/analyse-logs-serveur-crawl-stats-gsc-2026/).
## URL Inspection contre Indexing API : arrête de les confondre
Voilà la vraie source du malentendu. Il existe une deuxième API, l'Indexing API, et elle, elle soumet des URLs pour exploration prioritaire. C'est celle que les gens croient utiliser quand ils appellent URL Inspection.
Sauf que l'Indexing API a deux limites qui refroidissent vite. Son quota par défaut est de 200 requêtes de publication par jour et par projet (180 par minute pour `getMetadata`, 380 par minute toutes méthodes confondues). Et surtout, Google la réserve aux pages qui embarquent du balisage `JobPosting` ou du `BroadcastEvent` dans un `VideoObject`. Une offre d'emploi, un événement en direct. Ton article de blog ou ta fiche produit ? Hors périmètre.
Donc non, tu ne peux pas « forcer » l'indexation de ton site avec l'une ou l'autre. URL Inspection lit, Indexing API soumet mais seulement pour deux types de contenus très précis. Si tu retiens une chose, c'est celle-là. Pour le reste, ton budget de crawl se travaille à l'ancienne, en soignant ton [crawl budget](/crawl-budget-comprendre-optimiser-google/).
## mobileUsabilityResult, le zombie du schéma
Petit piège pour finir. Le champ `mobileUsabilityResult` existe encore dans le schéma de réponse, mais il est marqué comme déprécié. Google a retiré le rapport Mobile Usability, le Mobile-Friendly Test et son API : annoncé en avril 2023, effectif le 4 décembre 2023.
Le champ est donc un zombie. Il apparaît, il ne raconte plus rien d'utile, et tu perds ton temps si tu construis un monitoring dessus. Ignore-le, comme cette notification que tu ne lis jamais.
## Le mot de la fin
L'API URL Inspection, c'est un excellent outil de surveillance : suivi d'indexation après publication, détection de pages désindexées, chasse aux erreurs serveur, audit canonique à grande échelle. Un tableau de bord de l'état de santé de ton site vu par Google.
Ce qu'elle n'est pas : un raccourci vers l'index. Personne ne va te faire indexer plus vite en boucant des appels. Le jour où tu intègres ça, tu arrêtes de gaspiller ton quota et tu commences à en tirer quelque chose. Et si tu veux voir à quoi ressemble une vraie galère GSC, va lire le [bug Discover de mai 2026](/bug-discover-search-console-7-8-mai-2026-rapport-client/), ça relativise.
## Sources
- [Google for Developers : Usage Limits (Search Console API)](https://developers.google.com/webmaster-tools/limits)
- [Google Search Central : Welcoming the new URL Inspection API](https://developers.google.com/search/blog/2022/01/url-inspection-api)
- [Google for Developers : Method index.inspect](https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect)
- [Google for Developers : UrlInspectionResult](https://developers.google.com/webmaster-tools/v1/urlInspection.index/UrlInspectionResult)
- [Google for Developers : Indexing API quota & pricing](https://developers.google.com/search/apis/indexing-api/v3/quota-pricing)
- [Search Engine Land : Google drops Mobile Usability report and tools](https://searchengineland.com/google-officially-drops-mobile-usability-report-mobile-friendly-test-tool-and-mobile-friendly-test-api-435377)
- [Screaming Frog : How to automate the URL Inspection API](https://www.screamingfrog.co.uk/seo-spider/tutorials/how-to-automate-the-url-inspection-api/)
---
## SEO multi-établissements : le piège des pages jumelles
- URL: https://www.referencement-internet-web.com/seo-multi-etablissements-store-locator-pages-dupliquees/
- Author: Baptiste P.
- Published: 2026-07-29T06:00:00
- Categories: seo
On ne va pas se mentir : le SEO multi-établissements, c'est le terrain miné par excellence. Tu as trente, cent, cinq cents points de vente, et tu veux une page qui ranke pour chacun. Logique. Sauf que la méthode la plus « efficace » pour y arriver, dupliquer un template et changer juste le nom de la ville, porte un nom chez Google. Et ce nom, c'est du spam.
Le truc c'est que la frontière entre « réseau bien structuré » et « ferme à pages jumelles » est plus fine que tu crois. Google l'a même documentée noir sur blanc. Alors avant de générer tes cinq cents pages de villes, on décortique là où ça casse, et comment construire un store locator qui passe la douane.
## Google a un mot pour ça : « doorway abuse »
Dans ses règles anti-spam, Google définit le doorway abuse : des pages créées pour ranker sur des requêtes très proches, qui mènent l'internaute vers des pages intermédiaires moins utiles que la destination finale. Et l'exemple qu'il donne, tiens-toi bien, c'est exactement le nôtre : des pages ciblant des régions ou des villes précises qui renvoient les utilisateurs vers une seule et même page.
Traduction : si tes cinq cents pages de villes sont des coquilles vides qui redirigent toutes vers un formulaire de contact unique, tu es dans le viseur. Ce n'est pas une interprétation de blogueur SEO, c'est écrit dans la doc officielle. C'est le cousin germain du [contenu dupliqué classique, avec ses causes et ses solutions](/duplicate-content-causes-impact-solutions/), en version industrielle.
## La photocopieuse, l'autre ligne rouge
Depuis mars 2024, Google a ajouté une deuxième notion à son arsenal : le scaled content abuse. En clair, générer des tonnes de pages dans le seul but de manipuler le classement, sans aider personne. Peu importe la méthode, IA, template ou stagiaire à la chaîne, c'est le résultat qui compte.
Et Google ne rigole pas avec ça. Après cette mise à jour, la firme a annoncé, puis mesuré, 45 % de contenu non original en moins dans ses résultats, là où elle en attendait 40 %. Ta ferme de pages produites en [SEO programmatique](/seo-programmatique-creation-pages-echelle/) sans la moindre valeur ajoutée éditoriale ? Elle joue avec le feu.
## Le store locator qui tient la route : trois étages
Bon, assez de menaces. Comment on fait bien ? Un store locator qui performe s'organise, selon les praticiens du référencement local, en trois niveaux. C'est la logique hub-and-spoke, version géographique.
- **La page de recherche globale.** La carte, le champ de recherche, le point d'entrée. Celle que tout le monde connaît.
- **Les pages hubs.** Regroupement par région, par ville ou par type de service. Elles captent les requêtes que la page de recherche laisse filer.
- **Les pages locales.** Une fiche complète par établissement : la vraie viande.
L'idée, c'est que chaque étage nourrit le suivant. Et surtout, aucune page locale ne doit rester orpheline. D'après les spécialistes du store locator, chaque fiche doit être accessible depuis la page d'aperçu, depuis la navigation du site, et idéalement depuis un contenu contextuel ailleurs, un lien posé dans un article pèse plus lourd qu'un lien de menu.
### Ce qui remplit vraiment une page locale
Là, je vois venir la question à un million : « combien de mots minimum ? ». Réponse : Google ne fixe aucun seuil de mots. Zéro. C'est un mythe qui a la vie dure. Ce qu'il veut, c'est assez de contenu réellement spécifique pour justifier une page indexée à part.
En pratique, ça donne quoi ? Les vrais horaires, l'équipe du point de vente, les avis locaux, les actus du magasin, des photos réelles (pas la banque d'images corporate collée partout). Selon John Mueller, de chez Google, le contenu localisé n'est pas assimilé à du contenu dupliqué par principe. Mais il ajoute la nuance qui tue : une page de ville doit rester spécifique, pas un copier-coller avec le nom de la commune en variable.
Petite digression perso : j'ai bossé sur un locator où toutes les pages traînaient le même paragraphe, avec juste le nom de la ville qui changeait. Résultat, la moitié n'était même pas indexée. Google avait fait le tri tout seul, sans me demander mon avis. Et gaffe à un effet de bord vicieux : deux pages qui visent la même intention finissent par se manger entre elles. C'est de la [cannibalisation SEO, à repérer et corriger vite](/cannibalisation-seo-identifier-corriger/).
## Le balisage : LocalBusiness et sa hiérarchie
Côté données structurées, Schema.org fournit pile ce qu'il faut. Le type `LocalBusiness` décrit un établissement physique ou une succursale, un restaurant, une agence bancaire, un cabinet médical, peu importe l'enseigne.
Pour modéliser ton réseau, deux propriétés font le job : `parentOrganization` (la maison mère) et `subOrganization` (les points de vente qui en dépendent). Tu déclares la hiérarchie proprement, chaque fiche sait à quelle enseigne elle appartient. Ça ne te sort pas un rich result par magie, mais [ce que Google exploite vraiment dans les données structurées](/schema-markup-donnees-structurees-seo/) mérite d'être balisé correctement.
Un piège à éviter au passage : ne confonds pas ça avec le hreflang. Le hreflang, c'est fait pour les variantes de langue ou de pays d'un même contenu, pas pour tes pages de villes en français sur un site français. Ça, c'est du [référencement international, un tout autre chantier](/seo-international-hreflang-multilingue/).
## Google Business Profile : le seuil des 10
Le SEO multi-établissements ne vit pas que sur ton site. Google Business Profile, c'est l'autre moitié du terrain. Et là, il y a un seuil à connaître.
Dès 10 établissements de la même enseigne, tu débloques la vérification en masse : compte professionnel, groupe d'établissements, tableur que tu uploades, et Google valide le lot. En dessous de 10, tu vérifies fiche par fiche, à l'ancienne. Détail qui pique : une agence ne peut pas obtenir cette vérification en masse pour le compte de tous ses clients, chaque enseigne doit l'acquérir elle-même, puis déléguer l'accès.
Le vrai danger ici, ce sont les doublons. Google considère une fiche comme doublon dès qu'une fiche vérifiée existe déjà pour la même adresse, et le doublon disparaît de la recherche. Le grand classique, c'est le déménagement où l'on crée une nouvelle fiche au lieu de mettre à jour l'ancienne. Pour fusionner, tu signales sur Google Maps, c'est soumis à revue, et tu risques de perdre les réponses aux avis au passage (les avis eux-mêmes survivent). Rien de dramatique, mais mieux vaut ne pas en arriver là.
Bonne nouvelle quand même : une fois ton réseau au propre, tu publies un même post, une offre ou un événement, sur plusieurs fiches d'un coup. Tu sélectionnes les établissements concernés, tu postes, terminé. Pour le reste, [optimiser chaque fiche Google Business Profile en 2026](/google-business-profile-optimiser-fiche-2026/) reste la base du travail.
## La vraie ligne de partage
Au fond, tout se joue sur une question bête : est-ce que chaque page existe pour un humain qui cherche ce point de vente précis, ou juste pour attraper une requête au filet ? Google a bâti tout son arsenal anti-spam autour de cette distinction, du doorway abuse au scaled content.
Honnêtement, sur les très gros réseaux, je me demande encore jusqu'où pousser la personnalisation avant que le coût éditorial ne devienne intenable. Cinq cents pages vraiment uniques, c'est un vrai chantier. Mais l'alternative, la photocopieuse, revient à se tirer une balle dans le pied à retardement. Entre les deux, il n'y a pas trente-six issues : tu construis moins de pages, mais des vraies.
## Sources
- [Spam policies for Google Search (doorway abuse, scaled content abuse)](https://developers.google.com/search/docs/essentials/spam-policies)
- [Google Search Update : Quality Improvements, mars 2024](https://blog.google/products-and-platforms/products/search/google-search-update-march-2024/)
- [Type LocalBusiness (Schema.org)](https://schema.org/LocalBusiness)
- [Consolidate duplicate URLs (Google Search Central)](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)
- [Vérifier des fiches en masse, seuil de 10 établissements (Google Business Profile Help)](https://support.google.com/business/answer/4490296?hl=en)
- [Gestion des établissements en masse (Google Business Profile Help)](https://support.google.com/business/answer/3217744?hl=en)
- [Résoudre les fiches en double (Google Business Profile Help)](https://support.google.com/business/answer/12756178?hl=en)
- [Publier sur plusieurs établissements (Google Business Profile Help)](https://support.google.com/business/answer/7342169?hl=en)
- [Contenu localisé et contenu dupliqué, position de John Mueller (Search Engine Journal)](https://www.searchenginejournal.com/when-is-duplicate-content-acceptable-for-local-seo-google-explains/519562/)
- [Structurer son store locator (Partoo)](https://www.partoo.co/en/online-presence/store-locator/create/structure/)
- [Maillage interne des pages locales (Mapular)](https://mapular.com/blog/store-locator-seo-how-location-pages-drive-local-search-traffic)
- [Vérification GBP pour réseaux multi-établissements (BrightLocal)](https://www.brightlocal.com/learn/verifying-google-business-profile-for-multiple-locations/)
---
## Data clean rooms : la neutralité est un mythe
- URL: https://www.referencement-internet-web.com/data-clean-rooms-attribution-seo-first-party-2026/
- Author: Baptiste P.
- Published: 2026-07-28T06:00:00
- Categories: analytics
Il y a une phrase qui traîne dans tous les pitchs adtech : « les data clean rooms sont des environnements neutres ». On vous vend un coffre-fort partagé où deux marques croisent leurs données sans jamais les exposer, un arbitre impartial entre les parties. Sauf que le 18 mai 2026, Publicis a racheté LiveRamp, le dernier acteur qui pouvait encore prétendre à cette neutralité. L'arbitre vient de signer dans une des équipes. Et personne dans le secteur n'a l'air surpris.
Alors avant de reparler d'attribution sans cookies tiers, remettons les choses à plat. Parce que le sujet est réel, la techno tient debout, mais le storytelling autour, lui, prend l'eau.
## Une data clean room, c'est quoi au juste
Le principe est plutôt élégant. Deux parties, un annonceur et une plateforme par exemple, veulent savoir combien de personnes exposées à une pub ont fini par acheter. Chacune a ses données de son côté. Une data clean room, c'est l'environnement sécurisé où ces jeux de données se rencontrent pour produire un résultat agrégé, sans qu'aucune donnée individuelle brute ne traverse la frontière entre les deux. Les identifiants sont hashés, la sortie est agrégée, et personne ne repart avec le fichier de l'autre.
En pratique, ça sert surtout à l'attribution : croiser exposition publicitaire et conversions pour mesurer un ROI, sans exposer le détail utilisateur. Si vous avez déjà galéré à recoller un [parcours client éclaté](/attribution-marketing-comprendre-parcours-client/) entre dix points de contact, vous voyez l'intérêt.
Petite précision utile, parce qu'on confond les deux tout le temps : une clean room n'est pas du [tracking server-side](/server-side-tracking-first-party-data-privacy-post-cookies-2026/). Le server-side, c'est une méthode de collecte, fiabiliser la remontée des événements côté serveur. La clean room, c'est un environnement d'analyse en aval. Les deux sont complémentaires : ce que vous collectez en server-side vient souvent alimenter la clean room. L'un ramasse, l'autre recoupe.
## Le casting : Google, Amazon, Meta
Côté acteurs, on retrouve les suspects habituels. Google Ads Data Hub combine vos données first-party avec Google Ads, DV360 et CM360. Et il applique des seuils d'agrégation stricts : environ 20 utilisateurs uniques minimum par ligne pour l'injection de bruit, environ 50 pour les contrôles de différence, environ 10 pour les requêtes limitées aux clics et conversions. En dessous, la ligne est filtrée silencieusement. Pas de bruit, pas de résultat.
Amazon Marketing Cloud a fait un geste notable : depuis le 18 septembre 2025, l'accès est direct et gratuit pour tout annonceur Sponsored Ads, sans passer par un partenaire tiers. Amazon a même étendu sa fenêtre de lookback de 13 à 25 mois (disponible aux États-Unis et au Canada depuis le 11 novembre 2025, déploiement France prévu au premier trimestre 2026). AMC applique aussi des seuils d'agrégation par niveau de risque, mais Amazon ne publie pas les valeurs exactes, donc je ne vais pas vous inventer de chiffres.
Meta, de son côté, teste Advanced Analytics, une clean room propriétaire en bêta limitée sur liste d'attente. À la conférence MeasureUp en Australie (septembre 2025), Meta a présenté des résultats bêta : +14 % de revenu incrémental pour des marques du voyage, +42 % d'efficacité en bas de funnel pour une marque de boisson, sur 120 tests et 20 campagnes. Des chiffres de démo, à prendre pour ce qu'ils sont.
Il y a aussi PAIR (Publisher Advertiser Identity Reconciliation), développé au départ par l'équipe Google Ads, lancé via DV360 le 11 octobre 2022, puis repris comme standard ouvert par l'IAB Tech Lab. La spec v1.1 a été finalisée le 16 juillet 2025. Techniquement, PAIR repose sur de la cryptographie commutative : les clés de jointure sont chiffrées plusieurs fois par chaque partie et appariées sans jamais être déchiffrées en clair. Sur le papier, c'est propre.
## Le rachat qui fait tomber le masque
Maintenant, le vrai sujet. Le discours de la « salle blanche neutre » reposait sur l'existence d'acteurs tiers indépendants, la fameuse Suisse du secteur. Regardez comment ça s'est effondré, rachat après rachat.
Janvier 2024 : LiveRamp rachète Habu pour 200 millions de dollars. Avril 2025 : WPP absorbe InfoSum et l'intègre à GroupM. Et le 18 mai 2026 : Publicis annonce l'acquisition de LiveRamp lui-même, transaction 100 % cash à 38,50 $ par action, valeur d'entreprise autour de 2,2 milliards de dollars (capitaux propres proches de 2,5 milliards), avec une prime de 30 % sur le cours de clôture du 15 mai 2026. Clôture attendue fin 2026.
Faites le compte. Toutes les plateformes de data collaboration indépendantes sont désormais soit absorbées par des groupes publicitaires (Publicis, WPP), soit opérées en propre par les Big Tech (Google, Amazon, Meta). Il ne reste plus un seul acteur qui n'ait pas d'intérêt dans la partie. Comme l'a résumé AdExchanger, le rachat de LiveRamp par Publicis ressemble moins à un changement de maillot qu'à l'arbitre qui rejoint une des équipes.
Ça ne rend pas la techno inutile. Une clean room chiffre toujours correctement, agrège toujours au-dessus d'un seuil. Mais l'argument commercial de la neutralité, celui qui justifiait de confier ses données first-party à un tiers « impartial », il faut le ranger. La neutralité ne s'applique désormais qu'à un segment qui a quasiment disparu. Les clean rooms des Big Tech, elles, n'ont jamais prétendu être neutres : elles sont propriétaires de leur écosystème par construction. Ce qui, au fond, est presque plus honnête.
C'est aussi là que ça se complique dans la vraie vie : chaque plateforme opère sa propre clean room cloisonnée. Une marque doit rejoindre Google ADH, puis AMC, puis Meta, puis chaque retailer, séparément. Plus vous ajoutez de partenaires, plus la complexité opérationnelle explose. Et la mise en place demande une vraie expertise data (SQL, modélisation, lecture de résultats agrégés) qui reste hors de portée de beaucoup de PME, gratuité de l'accès ou pas.
## Le « monde sans cookies » ? Pas vraiment
L'autre morceau de storytelling à démonter, c'est l'idée qu'on bascule dans un monde cookieless et que les clean rooms sont le sauvetage. Sauf que Google a fait marche arrière. En avril 2025, la firme a confirmé qu'elle ne déprécierait pas les cookies tiers dans Chrome et n'afficherait pas d'invite de consentement. Le 17 octobre 2025, elle a retiré un grand nombre d'API [Privacy Sandbox](/privacy-sandbox-google-retire-topics-api-octobre-2025-consequences-seo-2026/), raison invoquée : faible adoption.
Résultat : Chrome, qui pèse environ 70,25 % du marché mondial des navigateurs en mai 2026 selon StatCounter, continue d'autoriser les cookies tiers par défaut. Seuls Safari (environ 15,72 %) et Firefox en mode strict (environ 2,23 %) les bloquent déjà totalement. Le « monde sans cookies tiers » existe, mais il est partiel et fragmenté selon le navigateur, pas acté par Chrome. Les clean rooms répondent à un vrai problème de mesure, elles ne répondent pas à une extinction généralisée qui n'a pas eu lieu.
## Pseudonymisé n'est pas anonyme
Dernier point, et pas le moins important côté conformité. On présente souvent les clean rooms comme des machines à anonymiser. Attention au raccourci. Au sens du RGPD, une donnée pseudonymisée (un email hashé, un ID de remplacement) reste une donnée personnelle. Seule une anonymisation effective et irréversible sort du champ du règlement.
Or la plupart des clean rooms travaillent avec des identifiants pseudonymisés en entrée. Ce n'est qu'en sortie, une fois le résultat agrégé au-dessus d'un seuil de k-anonymity, qu'on approche d'un résultat réellement anonyme. La nuance n'est pas cosmétique : elle détermine quel régime juridique s'applique à vos données pendant tout le traitement. Et non, il n'existe pas à ce jour de recommandation de la CNIL dédiée aux data clean rooms publicitaires qui viendrait valider l'ensemble. La seule mention repérée date d'un appel à contributions de juillet 2023 sur les bases de données pour l'IA, un contexte différent.
## Le mot de la fin
Les data clean rooms sont un outil de mesure sérieux, avec de vraies garanties techniques : chiffrement, seuils d'agrégation, pas de données brutes qui circulent. Sur ce plan, rien à redire. Ce qui a changé en 2026, c'est le discours. La neutralité de l'intermédiaire, c'était l'argument de vente. Publicis vient de le racheter avec LiveRamp.
Mon conseil : traitez une clean room pour ce qu'elle est, un environnement d'analyse propriétaire opéré par une partie qui a ses propres intérêts. Vérifiez les seuils, cadrez le statut RGPD de vos identifiants, et arrêtez de croire qu'un tiers « impartial » veille sur vos données. Il ne reste plus personne pour tenir ce rôle.
## Sources
- [Snowflake - What is a data clean room](https://www.snowflake.com/en/fundamentals/what-is-a-data-clean-room/)
- [Google for Developers - Ads Data Hub privacy checks](https://developers.google.com/ads-data-hub/guides/privacy-checks)
- [IAB Tech Lab - PAIR](https://iabtechlab.com/pair/)
- [PPC Land - IAB Tech Lab releases PAIR 1.1](https://ppc.land/iab-tech-lab-releases-pair-1-1-protocol-to-simplify-encrypted-data-matching/)
- [Amazon Ads - AMC for sponsored ads](https://advertising.amazon.com/library/news/amc-for-sponsored-ads)
- [PPC Land - Amazon extends Marketing Cloud lookback window](https://ppc.land/amazon-extends-marketing-cloud-lookback-window-from-13-to-25-months/)
- [PPC Land - Meta showcases data clean room results at MeasureUp](https://ppc.land/meta-showcases-data-clean-room-results-at-australias-measurement-conference/)
- [Publicis Groupe - Publicis to acquire LiveRamp](https://www.publicisgroupe.com/en/news/press-releases/publicis-to-acquire-liveramp-to-accelerate-data-co-creation-for-smarter-agents)
- [AdExchanger - Publicis acquires LiveRamp](https://www.adexchanger.com/marketers/publicis-acquires-liveramp-in-a-major-shakeup-for-indie-data-collaboration/)
- [AdExchanger - WPP acquires InfoSum](https://www.adexchanger.com/online-advertising/wpp-acquires-data-clean-room-startup-infosum/)
- [eMarketer - Google's Privacy Sandbox elimination](https://www.emarketer.com/content/google-s-privacy-sandbox-elimination-ends-quest-cookieless-chrome)
- [Leto Legal - Pseudonymisation et RGPD](https://www.leto.legal/guides/rgpd-les-enjeux-de-la-pseudonymisation-des-donnees)
- [Wpromote - Server-side identity resolution](https://www.wpromote.com/blog/analytics/server-side-identity-resolution/)
---
## SEO juridique : le schema LegalService ne t'affiche rien
- URL: https://www.referencement-internet-web.com/seo-juridique-avocats-schema-legalservice-2026/
- Author: Baptiste P.
- Published: 2026-07-27T06:00:00
- Categories: seo
Tu télécharges le playbook SEO standard, tu l'appliques à un cabinet d'avocats, et là surprise : la moitié des briques sont soit cassées par Google, soit interdites par la loi. Le SEO juridique, c'est un peu comme lancer un jeu avec un patch de compatibilité qui te grise la moitié des boutons. Le schema LegalService censé te sortir de beaux résultats enrichis ? Il n'affiche rien. Les avis 5 étoiles sur ta page ? Double interdiction. Bienvenue dans le mode le plus verrouillé du référencement français.
Pour comprendre pourquoi c'est aussi serré, faut remonter le fil. Parce que rien de tout ça n'est arrivé d'un coup : c'est une série de textes et de décisions qui ont, année après année, dessiné le terrain de jeu. On y va dans l'ordre.
## Remontons le fil : 2014, la pub d'avocat sort du placard
Longtemps, un avocat n'avait quasiment pas le droit de faire sa promo. Le premier vrai déblocage arrive avec le décret n° 2014-1251 du 28 octobre 2014, pris pour l'application de la loi n° 2014-344 du 17 mars 2014 relative à la consommation. Ce texte autorise et encadre pour la première fois la sollicitation personnalisée : uniquement par courrier postal ou email, à l'exclusion de tout message envoyé sur un mobile. Donc pas de SMS, et surtout pas de démarchage physique ou téléphonique. Le porte-à-porte version robe noire, c'est mort avant même d'avoir commencé.
Neuf ans plus tard, gros reset. Le décret n° 2005-790 du 12 juillet 2005, celui que la moitié des agences web citent encore comme référence, a été abrogé le 3 juillet 2023. Remplacé par le décret n° 2023-552 du 30 juin 2023 portant code de déontologie des avocats. Si un prestataire te ressort le décret de 2005 pour cadrer ta com', il bosse avec une doc périmée depuis deux ans.
Le texte en vigueur, c'est donc l'article 15 de ce décret 2023-552. Il reprend la substance de 2014 : la publicité et la sollicitation personnalisée sont permises « si elles procurent une information sincère sur la nature des prestations de services proposées et si leur mise en œuvre respecte les principes essentiels de la profession ». Traduction : pas de comparatif avec les confrères, pas de dénigrement, et le coût de la prestation doit figurer dans une convention d'honoraires. Tu peux communiquer, mais dans un couloir très étroit.
## Les avis clients : le piège en deux couches
Là, je casse direct le réflexe le plus répandu. « Affiche tes avis clients sur ton site, mets un beau widget avec des étoiles, ça booste le SEO. » Pour un avocat, ce conseil te plante sur deux niveaux différents, et c'est assez vicieux.
Couche 1, côté Google. Depuis 2019, avec une règle réaffirmée dans la doc en décembre 2025, il existe le principe des avis « self-serving ». Si l'entité notée contrôle elle-même les avis publiés à son sujet, que ce soit via un balisage maison ou un widget tiers intégré sur son propre site, ses pages en `LocalBusiness` ou en `Organization` sont inéligibles à l'étoile de notation. Or `LegalService` hérite justement de `LocalBusiness`. Donc même avec un balisage `AggregateRating` techniquement nickel, ton cabinet n'aura jamais l'étoile. Le code passe la validation, mais le rendu reste à zéro.
Couche 2, côté déonto, et elle est encore plus tranchante. Le vade-mecum de la communication des avocats du CNB, 3e édition d'octobre 2023, interdit carrément de publier des témoignages clients sur le site de l'avocat, widget Google Reviews compris. L'idée : un avis client est subjectif, on ne sélectionne jamais que les positifs, ça contrevient aux principes essentiels de la profession. La nuance à retenir, c'est où passe la ligne : les avis déposés directement sur ta fiche Google Business Profile restent tolérés, parce que Google est une plateforme tierce sur laquelle tu n'as pas le contrôle éditorial. C'est l'import du témoignage sur ton site propre qui est banni, pas l'avis en lui-même sur Google. Pour l'optimisation de cette fiche, j'en parle dans mon [guide Google Business Profile](/google-business-profile-optimiser-fiche-2026).
Petite précision qui surprend souvent : noter et comparer des avocats reste parfaitement légal… pour les autres. La Cour de cassation l'a tranché le 11 mai 2017 (arrêt n° 16-13.669) : les sites tiers non soumis à la déontologie peuvent classer des avocats, à condition de délivrer une information loyale, claire et transparente. Ce que tu ne peux pas faire chez toi, un annuaire externe a le droit de le faire chez lui. Cherchez la logique.
## Le schema LegalService : joli sur le papier, invisible dans Google
On arrive au cœur du mythe. Schema.org définit bien un type dédié : `LegalService`, décrit comme « a business that provides legally-oriented services, advice and representation, e.g. law firms ». Il hérite à la fois de `Organization` et de `Place` via `LocalBusiness`, avec des sous-types plus précis comme `Attorney` ou `Notary`. Le balisage existe, il est propre, il aide Google à structurer tes infos. Jusque-là, rien à jeter.
Le problème, c'est ce que ça déclenche visuellement dans les résultats : rien. La galerie officielle des résultats enrichis de Google ne recense ni `LegalService`, ni `Attorney`. Les seuls types qui s'appliquent à un cabinet sont génériques, pas juridiques : Local business, Organization, Profile page, Q&A, Review snippet. Aucun badge dédié à la profession n'existe. Si une agence te vend des encarts flashy « spécial avocat » grâce au schema, elle te vend du vent. Le mécanisme réel des données structurées est détaillé dans notre [guide dédié](/schema-markup-donnees-structurees-seo).
Et le dernier enrichissement sur lequel beaucoup misaient encore, le rich result FAQPage, a rendu l'âme. Depuis le 7 mai 2026, les résultats enrichis FAQ n'apparaissent plus dans Google Search. Le balisage reste valide chez Schema.org et lisible par d'autres crawlers, mais côté Google, plus aucun extrait. Et franchement, pour le juridique, ça ne change même pas grand-chose : entre août 2023 et cette suppression totale, le FAQ rich result était déjà réservé aux sites gouvernementaux et de santé faisant autorité. Un cabinet d'avocats n'y avait de toute façon jamais accès. J'ai décortiqué cette disparition dans mon [papier sur la fin des FAQ](/fin-faq-rich-results-google-7-mai-2026-impact-seo).
Je vais être honnête, il y a un point où je coince encore : difficile de dire si Google finira un jour par lire ce balisage `LegalService` pour nourrir ses réponses génératives. Pour l'instant, aucune preuve solide dans un sens ou dans l'autre. Alors je balise quand même, par hygiène, sans en attendre de miracle visible.
## Alors, tu mises sur quoi ?
Si tu ne peux ni acheter des étoiles, ni afficher des témoignages, ni compter sur un rich result maison, il te reste le seul levier qui tient vraiment debout : la confiance. Google range le juridique dans les sujets YMYL, ceux qui touchent à l'argent, aux droits, à la vie des gens. Sur ces thématiques, il pousse le contenu qui aligne un E-E-A-T solide. Et depuis décembre 2022, un premier « E » a été ajouté à l'acronyme : Experience. Concrètement, ça valorise le contenu écrit à partir d'une expérience de terrain, dossiers réels à l'appui, pas juste de la théorie recopiée. Sur un cabinet, ça veut dire montrer du vécu, des cas traités, une vraie signature d'auteur. Je creuse ce virage dans mon [analyse du critère Experience](/eeat-experience-critere-decisif-contenu-ia-2026).
Reste ta fiche Google Business Profile, autorisée mais tenue en laisse par l'article 10 du RIN : c'est un outil d'information, pas de sollicitation active. Infos factuelles, coordonnées, spécialités, et basta. Pas de slogan promo, pas de promesse de résultat, ton sobre et neutre. Et n'oublie pas l'article 10.5 : quand tu ouvres ou modifies sérieusement ton site, tu dois en informer sans délai le Conseil de l'Ordre et lui communiquer tes noms de domaine, sachant que le domaine doit porter ton nom ou celui du cabinet. Au passage, les liens vers des sites marchands y sont interdits. Le RIN, lui, reste bien en vigueur en 2026 : le CNB a ouvert une consultation jusqu'au 29 mai 2026 pour y intégrer, à droit constant, les dispositions du décret 2023-552.
Bilan des courses : le SEO d'un avocat, c'est le même moteur que partout ailleurs, mais avec la moitié des cheats désactivés et un game master qui te surveille. Pas de raccourci payant, pas de widget d'avis, pas de badge magique. Juste du contenu qui prouve ton expertise, une fiche irréprochable, et le respect scrupuleux de ta déonto. C'est plus lent, c'est plus exigeant, et pour une profession qui engage des gens à des moments critiques de leur vie, c'est probablement très bien comme ça.
## Sources
- [Schema.org - LegalService](https://schema.org/LegalService)
- [Google Search Central - Search Gallery (résultats enrichis)](https://developers.google.com/search/docs/appearance/structured-data/search-gallery)
- [Google Search Central - FAQPage structured data](https://developers.google.com/search/docs/appearance/structured-data/faqpage)
- [Google Search Central - Review snippet (self-serving reviews)](https://developers.google.com/search/docs/appearance/structured-data/review-snippet)
- [Google Search Central Blog - E-A-T gets an extra E for Experience](https://developers.google.com/search/blog/2022/12/google-raters-guidelines-e-e-a-t)
- [Légifrance - Décret n° 2023-552 du 30 juin 2023 portant code de déontologie des avocats](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000047774060)
- [Légifrance - Article 15 du décret n° 2023-552](https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000047776450)
- [Légifrance - Décret n° 2014-1251 du 28 octobre 2014](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000029644231)
- [CNB - Toilettage du RIN (concertation 2026)](https://cnb.avocat.fr/actualite/le-cnb-envoie-a-la-concertation-l-avant-projet-de-decision-a-caractere-normatif-relative-au-toilettage-du-rin)
- [Legalis - La Cour de cassation autorise la comparaison et la notation d'avocats par des sites tiers](https://www.legalis.net/actualite/la-cour-de-cassation-autorise-la-comparaison-et-la-notation-davocats-par-des-sites-tiers/)
- [Village Justice - La fiche profil Google pour les professions juridiques](https://www.village-justice.com/articles/fiche-profil-google-les-professions-juridiques-entre-visibilite-numerique,54427.html)
---
## SEO santé : pourquoi la loi t'interdit d'acheter ton rang
- URL: https://www.referencement-internet-web.com/seo-sante-cliniques-praticiens-eeat-renforce-2026/
- Author: Baptiste P.
- Published: 2026-07-24T06:00:00
- Categories: seo
Ouvre le manuel de croissance SEO classique : tu achètes des liens, tu produis du contenu à la chaîne, tu payes pour grimper. Maintenant tente le même combo en SEO santé, et tu te prends un mur juridique en pleine face. Parce que dans le référencement médical français, il existe un truc que quasiment aucun autre secteur n'a : une loi qui t'interdit littéralement de payer pour apparaître en priorité dans les résultats.
On ne va pas se mentir, le SEO santé c'est le mode hardcore du référencement. Google range déjà les sujets médicaux dans la catégorie la plus surveillée du web (le YMYL, on y revient). Et par-dessus, en France, le Code de déontologie vient serrer la vis encore plus fort. Deux couches de contraintes empilées. Bienvenue dans le donjon.
## Le seul secteur où la loi t'interdit d'acheter ton rang
Commençons par ce qui rend ce terrain vraiment à part. Longtemps, un médecin n'avait quasiment aucun droit de communiquer publiquement sur son activité. Puis le décret n° 2020-1662 du 22 décembre 2020 a rebattu les cartes : il remplace l'interdiction quasi totale de publicité par un régime de communication encadré, autorisé sous conditions strictes (information loyale et honnête, sans témoignages ni comparaison avec les confrères).
Sauf qu'il y a un « mais » de la taille d'un boss de fin de jeu. L'article R4127-19-1 du Code de la santé publique est on ne peut plus clair : « Il est interdit au médecin d'obtenir contre paiement ou par tout autre moyen un référencement numérique faisant apparaître de manière prioritaire l'information le concernant dans les résultats d'une recherche effectuée sur l'internet. »
Traduis ça en langage SEO : Google Ads sur ton nom de spécialité, achat de position, boost payant, c'est niet. Et le Conseil national de l'Ordre des médecins ne s'est pas arrêté là. Dans ses recommandations de février 2021, il assimile même l'usage de hashtags destinés à augmenter sa visibilité et cibler des patients potentiels à une « stratégie promotionnelle » qui tombe dans les moyens de référencement prioritaire proscrits. Oui, des hashtags. On est à des années-lumière du growth-hacking à base de spam.
Le truc c'est que cette contrainte, loin d'être un bug, redéfinit toute la stratégie. Si tu ne peux pas acheter ta place, il ne te reste qu'une seule voie : la mériter.
## YMYL : quand Google te met sous surveillance renforcée
Côté moteur, même logique de méfiance. Google classe la santé dans les sujets YMYL, « Your Money or Your Life », soit tout ce qui peut « affecter de manière significative la santé, la stabilité financière ou la sécurité des personnes ». Pour ces sujets, la firme le dit noir sur blanc : ses systèmes donnent encore plus de poids au contenu qui aligne un E-E-A-T solide.
E-E-A-T, c'est Experience, Expertise, Authoritativeness, Trustworthiness. Et attention au piège classique : ces quatre lettres ne pèsent pas pareil. Google précise que la confiance (Trust) est le pilier le plus important, les trois autres ne servant qu'à l'alimenter. Le premier « E », Experience, a d'ailleurs été ajouté en décembre 2022 pour valoriser le contenu produit à partir d'une expérience de première main. Cette histoire de vécu est détaillée dans notre papier sur [l'Experience, ce critère devenu décisif](/eeat-experience-critere-decisif-contenu-ia-2026), et les bases du concept dans le [guide E-E-A-T complet](/eeat-comprendre-ameliorer-score-google).
Concrètement, plusieurs analyses SEO reconnues (Ahrefs, SEOZoom) qui décryptent les consignes des évaluateurs Google convergent sur un point : un contenu médical devrait être écrit ou relu par une personne dûment accréditée, mis à jour selon le consensus scientifique, et sourcé par des autorités de santé. Je le formule au conditionnel volontairement, parce que la citation exacte de ces consignes n'a pas pu être vérifiée mot pour mot. Mais l'esprit est là : sur la santé, ta signature d'auteur et tes sources ne sont pas un bonus, c'est le prix d'entrée.
## Les rich results médicaux ? Spoiler : y'en a pas
Là, je vais casser un mythe que je vois recyclé partout. Beaucoup d'agences vendent le balisage schema médical comme un ticket vers de beaux résultats enrichis dans Google. Regardons les faits.
Oui, Schema.org documente une vraie panoplie de types dédiés : `MedicalOrganization`, `Physician`, `MedicalWebPage`, et le type Physician est utilisé par 10 000 à 100 000 domaines selon les stats de Schema.org. Le balisage existe, il est adopté, et il aide Google à comprendre ta page. Jusque-là tout va bien.
Le problème, c'est ce que ça déclenche visuellement : rien. La galerie officielle des résultats enrichis de Google (une trentaine de types éligibles) ne liste aucun type médical. Ni Physician, ni MedicalOrganization, ni MedicalWebPage. Pire, le seul enrichissement que beaucoup utilisaient encore, le rich result FAQPage, a été carrément supprimé de Google Search le 7 mai 2026. Le balisage reste valide pour la compréhension du contenu, mais l'affichage bonus, oublie.
Donc oui, balise proprement tes pages, ça reste un signal utile pour être compris (j'explique le mécanisme dans mon [guide des données structurées](/schema-markup-donnees-structurees-seo)). Mais si un prestataire te promet des étoiles et des encarts médicaux flashy grâce au schema, il te vend du vent. Au passage, si tu croises encore une reco pour la certification HONcode, sache qu'elle a cessé toute activité fin décembre 2022. Ne bâtis rien dessus.
## Ce qui marche vraiment (et c'est pas du hack)
Le levier légal et efficace ? La fiche d'établissement Google Business Profile, gratuite et utilisable par les praticiens, avec des catégories imposées (gynécologue, dermatologue, chirurgien orthopédiste). Deux garde-fous à ne jamais oublier : pas de publicité déguisée, et surtout aucune photo permettant d'identifier un patient sans son consentement. Le secret médical prime sur ton envie de belles images.
Attention à ne pas confondre ce chantier avec du référencement local générique, où tu peux pousser les feux librement. Le SEO local classique, je le décris dans mon [guide pour les entreprises de proximité](/seo-local-guide-entreprises-proximite) et sur l'[optimisation de la fiche d'établissement](/google-business-profile-optimiser-fiche-2026). En santé, tu prends les mêmes fondamentaux, mais tu retires tout ce qui ressemble à de la promo agressive. C'est un peu comme jouer un run en difficulté maximale : mêmes commandes, zéro droit à l'erreur.
Dernier point de patience : améliorer sérieusement le contenu d'une page peut mettre plusieurs mois à se refléter dans le classement, souvent pas avant la prochaine core update. C'est une règle générale, valable pour tous les secteurs, pas une spécificité santé. Ne panique donc pas si tes efforts ne se voient pas dès la semaine suivante.
## Verdict sans appel
Le SEO santé n'est pas un secteur où tu triches ou tu accélères à coups de budget. La loi te l'interdit, Google te scrute, et le raccourci n'existe tout simplement pas. La seule stratégie qui tient debout : bâtir une confiance réelle. Auteur identifié et accrédité, sources sérieuses, transparence, fiche irréprochable.
Est-ce que c'est frustrant pour quelqu'un habitué à optimiser vite ? Franchement, j'hésite encore sur ce point. Une partie de moi trouve ces contraintes lourdes, l'autre se dit que pour un secteur qui touche à la santé des gens, c'est peut-être exactement le niveau d'exigence qu'il faut. Sur ce terrain, mériter sa place vaut mieux que l'acheter. Et pour une fois, c'est la loi qui le dit.
## Sources
- [Google Search Central - Creating Helpful, Reliable, People-First Content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)
- [Google Search Central Blog - E-A-T gets an extra E for Experience](https://developers.google.com/search/blog/2022/12/google-raters-guidelines-e-e-a-t)
- [Légifrance - Décret n° 2020-1662 du 22 décembre 2020](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042731060)
- [Légifrance - Article R4127-19-1 du Code de la santé publique](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042750056)
- [Egora - Recommandations CNOM sur la communication des médecins](https://www.egora.fr/gestion-du-cabinet/juridique/communication-des-medecins-sur-internet-les-conseils-de-lordre)
- [Schema.org - Health and medical types](https://schema.org/docs/meddocs.html)
- [Google Search Central - Search Gallery (résultats enrichis)](https://developers.google.com/search/docs/appearance/structured-data/search-gallery)
- [Google Search Central Blog - Changes to HowTo and FAQ rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes)
- [Google - Consignes fiche d'établissement](https://support.google.com/business/answer/3038177?hl=fr)
---
## SEO immobilier : le terrain où les portails perdent
- URL: https://www.referencement-internet-web.com/seo-immobilier-agences-sortir-ombre-portails-annonces/
- Author: Baptiste P.
- Published: 2026-07-23T06:00:00
- Categories: seo
Spoiler alert : ton agence immobilière ne battra jamais SeLoger sur son propre terrain. Ni Leboncoin, ni Bien'ici d'ailleurs. Le SEO immobilier version « je vais ranker premier sur "appartement Lyon" », c'est mort avant même d'avoir commencé. Autant le dire tout de suite, ça t'évitera de cramer un budget dans une bataille perdue.
Les chiffres racontent l'histoire. Selon le baromètre 2024 d'Eskimoz relayé par Monimmeuble, les portails immobiliers ont capté environ 388 millions de visites SEO sur l'année, contre 76 millions pour les agences traditionnelles. Cinq fois plus. Et l'écart s'est creusé par rapport à 2023. Bref, sur le volume brut, tu joues en division inférieure.
## Le match est truqué (et c'est très bien comme ça)
Regarde qui tient le haut du pavé. D'après Yanport, sur les annonces de vente en Île-de-France (douze mois arrêtés au 31 mars 2026), SeLoger pèse 33,1 % des annonces professionnelles, Bien'ici 21,2 % et Leboncoin 20,7 %. En PACA, SeLoger monte à 28,2 %, Leboncoin à 22,5 %. Ces plateformes ont des équipes SEO entières, des millions de pages, une autorité de domaine que tu ne rattraperas jamais.
C'est un peu comme vouloir défier un joueur classé Radiant en 1v1 sur sa map préférée : tu vas te faire démonter, et ce n'est même pas vexant. La bonne nouvelle, c'est qu'on ne joue pas au même jeu. Toi, tu connais le quartier. Eux non. Voilà la faille.
## Non, le schema RealEstateListing ne va pas te sauver
Petit détour obligatoire, parce que je vois passer la promesse partout : « ajoute le schema RealEstateListing et Google va afficher tes annonces en gros dans les résultats ». On ne va pas se mentir : c'est faux.
Le type `RealEstateListing` de Schema.org est officiellement marqué comme expérimental, dans la zone « new » du vocabulaire. Et surtout, la galerie officielle des données structurées supportées par Google Search ne le liste nulle part. Pas de rich result dédié aux annonces immobilières classiques. Zéro. Google reconnaît `LocalBusiness`, `Product`, `VacationRental`, mais pas ça.
Donc oui, tu peux baliser tes pages proprement, ça reste une bonne hygiène technique et ça aide à structurer ton contenu. Mais si quelqu'un te vend le schema comme le hack magique qui va faire pleuvoir les mandats, méfie-toi. Les données structurées, c'est utile, à condition de savoir [ce que Google exploite réellement et ce qu'il ignore](/schema-markup-donnees-structurees-seo/). Le reste, c'est du wishful thinking.
## L'hyperlocal, ce truc que les portails ne peuvent pas faire
Voilà le vrai terrain de jeu. Les portails raisonnent par ville, par département. Toi, tu peux descendre au quartier, à la rue, au micro-marché. Une page dédiée aux Chartrons à Bordeaux, avec les vrais prix au m², la typologie des acheteurs, les écoles du coin : ça, aucun portail national ne le fera à ta place. C'est toute la logique du [SEO hyperlocal, où tu domines une micro-zone plutôt qu'une ville entière](/seo-hyperlocal-dominer-micro-zone-plutot-ville-entiere/).
Pour nourrir ces pages avec des données solides, il y a une mine d'or publique : le fichier DVF, les Demandes de valeurs foncières. C'est la DGFiP qui le publie sur data.gouv.fr depuis mai 2019, il couvre les cinq dernières années de transactions réelles sur presque tout le territoire. Prix réels, pas estimations au doigt mouillé.
Attention quand même, et c'est là que ça se corse : je ne suis pas juriste, mais la licence est claire sur un point. La réutilisation est interdite dès qu'elle permet de ré-identifier des personnes, ou de faire indexer ces données brutes par des moteurs de recherche externes. Traduction : tu t'en sers pour construire ton analyse de quartier, tu ne balances pas la base telle quelle en accès public sur ton site. Tu transformes, tu agrèges, tu commentes. Utilisée intelligemment, une estimation en ligne bâtie là-dessus devient un aimant à leads vendeurs, un excellent point d'entrée pour une [stratégie de référencement local pensée pour les entreprises de proximité](/seo-local-guide-entreprises-proximite/).
## Ta fiche Google, ce chantier que tout le monde bâcle
Si je devais choisir une seule action avant tout le reste, ce serait celle-là. Et pourtant c'est celle que tout le monde néglige.
Geolid a passé au crible plus de 17 000 fiches Google Business Profile des trente principaux réseaux d'agences et de mandataires en France. Résultat : 68 % des fiches d'agences sont incomplètes. 68 %. Pour les mandataires, c'est 52 %. La majorité du secteur laisse trainer des fiches à moitié vides pendant que le local pack, lui, décide qui apparaît quand un vendeur tape « agence immobilière » près de chez lui.
C'est frustrant, parce que c'est gratuit et que ça se corrige en une après-midi. Horaires, photos, catégories, zone d'intervention, réponses aux avis. Rien de sorcier. J'ai vu des agences dépenser dans des campagnes payantes avec une fiche fantôme à côté, ça me rend un peu dingue. Commence par [optimiser ta fiche Google Business Profile en 2026](/google-business-profile-optimiser-fiche-2026/) avant même de penser au reste.
## La FNAIM a compris le truc
Ce n'est pas juste une théorie de blogueur SEO. Le 10 juin 2026, la FNAIM du Grand Paris a dégainé trois outils pensés précisément pour sortir les agences de la dépendance aux portails.
Il y a GoFlint, un chatbot IA branché sur un QR code WhatsApp collé en vitrine, pour capter les passants. Referral Immo, un système d'apport d'affaires entre agences du réseau. Et Immoexpert, développé avec Orisha, une estimation en ligne alimentée par les données DVF actualisées, avec mise en relation directe entre vendeur et agence.
Le fil rouge est limpide : reprendre la main sur la captation, arrêter de payer un péage à SeLoger pour parler à ses propres prospects. Quand une fédération de ce poids bouge là-dessus, ce n'est pas un hasard.
## Pour les pressés
Franchement, sur la stratégie globale j'hésite encore sur un point : jusqu'où pousser l'estimation en ligne sans tomber dans l'usine à leads bidon. Mais sur la direction générale, aucun doute.
Arrête de vouloir battre les portails sur le volume, tu perdras. Ignore les vendeurs de schema magique, Google n'affiche pas tes annonces en rich results. Concentre tout sur l'hyperlocal par quartier nourri au DVF, sur une fiche Google enfin complète, et sur des outils de captation directe. C'est moins sexy qu'un hack à la mode. C'est juste ce qui marche.
## Sources
- [Baromètre SEO immobilier 2024 (Eskimoz, via Monimmeuble)](https://monimmeuble.com/actualite/seo-immobilier-quels-acteurs-dominent-le-marche-en-2024)
- [Analyse du marché des annonces immobilières (Yanport)](https://www.yanport.com/blog/posts/analyse-du-marche-des-annonces-immobilieres-vente)
- [Type RealEstateListing (Schema.org)](https://schema.org/RealEstateListing)
- [Galerie des données structurées supportées (Google Search Central)](https://developers.google.com/search/docs/appearance/structured-data/search-gallery)
- [Trois outils de la FNAIM du Grand Paris (MySweetImmo)](https://www.mysweetimmo.com/2026/06/10/immobilier-la-fnaim-du-grand-paris-lance-trois-outils-pour-aider-les-agences-a-trouver-des-clients/)
- [Demandes de valeurs foncières (DVF, data.gouv.fr)](https://www.data.gouv.fr/datasets/demandes-de-valeurs-foncieres)
- [Étude Google Business Profile secteur immobilier (Geolid)](https://geolid.com/blog/etude-secteur-immobilier-les-chiffres-cles-sur-google-business-profile/)
---
## Consent Mode v2 : non, ça ne plombe pas ton SEO
- URL: https://www.referencement-internet-web.com/consent-mode-v2-google-consentement-seo-analytics-2026/
- Author: Baptiste P.
- Published: 2026-07-22T06:00:00
- Categories: analytics
Spoiler alert : le Consent Mode v2 ne va pas faire couler ton référencement. Je le mets tout de suite parce que c'est le mythe qui circule le plus, et il est faux. On lit partout que mal configurer son consentement ferait plonger le trafic organique. Sauf que le Consent Mode v2, c'est un truc de mesure et de pub, pas un facteur de classement Google. Nuance énorme. Et c'est justement là que tout le monde se plante, alors on va remettre les pendules à l'heure.
## Le mythe qui refuse de mourir
Le raisonnement des articles paniqués, c'est : « bannière de cookies plus stricte égale moins de données égale Google qui te déclasse ». C'est faux à l'étape 3. Google Search ne regarde pas ton signal de consentement pour décider où te ranker.
Côté recherche, John Mueller l'avait déjà tranché en 2020 (rapporté par Search Engine Roundtable) : les bannières de cookies « are fine » pour le référencement, tant que tu ne bloques pas l'indexation derrière une interstitielle qui masque le contenu. Depuis, rien n'a bougé sur ce point.
Le vrai risque, il est ailleurs. C'est un risque de pilotage à l'aveugle : si tu ne modélises pas correctement tes conversions, tu prends de mauvaises décisions marketing. Pas un déclassement. Une cécité. Ce qui est déjà bien assez pénible.
## Consent Mode v2, c'est quoi au juste
Le Consent Mode, c'est un mécanisme qui ajuste le comportement des tags et SDK Google selon le choix de consentement de l'utilisateur. En clair : selon que le visiteur accepte ou refuse, tes balises se comportent différemment. Google le documente noir sur blanc sur sa Tag Platform.
La version 2 a débarqué en novembre 2023 avec deux nouveaux paramètres. Au total, tu pilotes quatre signaux :
- `ad_storage` : le stockage lié à la pub (les cookies publicitaires, en gros)
- `analytics_storage` : le stockage côté mesure d'audience
- `ad_user_data` : l'envoi de données utilisateur à des fins publicitaires
- `ad_personalization` : l'usage de ces données pour la pub personnalisée et le remarketing
Les deux derniers, `ad_user_data` et `ad_personalization`, sont l'ajout de la v2. Le truc c'est que chaque signal est indépendant. Tu peux avoir un « oui » sur la mesure et un « non » sur la pub. C'est comme un menu de graphismes dans un jeu : tu règles chaque option séparément, tu ne coches pas juste « bas / élevé ».
## Basic ou Advanced : deux façons de gérer le refus
Là, ça se joue sur deux modes, et le choix change tout ce que Google peut reconstruire derrière.
En **mode Basic**, les tags sont carrément bloqués tant que l'utilisateur n'a pas interagi avec la bannière. Aucune donnée n'est envoyée avant le consentement. Google modélise à partir d'un modèle général, plus grossier.
En **mode Advanced**, les tags se chargent dès l'ouverture de la page. Si l'utilisateur refuse, Google envoie quand même des « pings » sans cookies, anonymisés, depuis chaque page. Ces pings permettent à Google Ads et GA4 de modéliser les conversions et les événements clés à partir d'un modèle spécifique à ton compte. Plus fin, donc.
Sauf que la modélisation n'est pas magique. Pour que Google Ads active la modélisation des conversions en Advanced, il te faut un seuil : 700 clics publicitaires sur 7 jours, par pays et par domaine. En dessous, pas de modèle spécifique. Autant dire que les petits comptes rament pour l'atteindre. C'est un peu comme un succès à débloquer avec un grind minimum : pas de raccourci.
## Éditeur ou annonceur : arrête de tout mélanger
Voilà l'erreur que je vois recopiée d'article en article. On confond deux obligations Google qui n'ont rien à voir. Elles tombent à des dates différentes, sur des acteurs différents, avec des outils différents.
Côté **annonceur** : depuis mars 2024, le consentement est requis pour la mesure, la personnalisation et le remarketing sur les utilisateurs de l'EEE. Ça concerne GA4, Google Ads, Floodlight. C'est ça, le Consent Mode v2 au sens strict. Si tu fais tourner des campagnes ou de l'audience, c'est ton camp. Pour la partie remarketing pur, j'en avais parlé dans mon papier sur le [retargeting publicitaire à l'ère du RGPD](/retargeting-remarketing-publicitaire-rgpd-2026/).
Côté **éditeur** (celui qui vend de l'inventaire pub via Ad Manager) : depuis le 16 janvier 2024 pour l'EEE et le UK, et le 31 juillet 2024 pour la Suisse, il te faut une CMP certifiée Google intégrée au TCF pour diffuser des annonces personnalisées. Ça, c'est une autre paire de manches, gérée dans Ad Manager, pas dans le Consent Mode.
Deux mondes. Une même bannière peut servir les deux, mais les règles ne sont pas les mêmes. Si un article te balance « Consent Mode v2 » et « CMP certifiée TCF » dans la même phrase comme si c'était pareil, méfie-toi : l'auteur n'a pas compris son sujet.
Petite précision qui a son importance : cette CMP doit être à jour du TCF v2.3, dont la transition s'est achevée le 28 février 2026, avec le segment `disclosedVendors` désormais obligatoire dans les chaînes de consentement. Et non, le Consent Mode ne remplace pas ta base légale RGPD : Google exige une base légale valide et la conservation des preuves de consentement, en plus du signal technique. Le signal ne te dédouane de rien juridiquement.
## Le 15 juin 2026 : ad_storage prend le volant
Un changement est passé le 15 juin 2026, et il mérite qu'on le signale. Avant, le partage des données publicitaires de GA4 vers Google Ads dépendait d'un double contrôle. Depuis cette date, `ad_storage` (donc le Consent Mode) devient la seule autorité pour ces données. Google Signals, lui, ne pilote plus que le reporting comportemental interne de GA4.
Plot twist : Google a annoncé qu'une bascule équivalente touchera `ad_personalization` plus tard en 2026, sans date précise pour l'instant. J'ai décortiqué toute la mécanique de ce virage dans mon [analyse de la consolidation GA4 vers Google Ads du 15 juin](/ga4-google-ads-consolidation-15-juin-2026-consent-mode-ad-storage/). Si tu gères des campagnes, va le lire, c'est là que ça compte vraiment.
## Et le SEO dans tout ça
On y revient, parce que c'est le nerf de la guerre. Aucune déclaration officielle de Google Search ne relie le Consent Mode à ton classement. Aucune. L'impact sur ton SEO existe, mais il est indirect : il passe uniquement par la qualité de tes données de mesure et de ton UX.
Concrètement : si ton consentement est mal câblé, tu perds en visibilité sur tes propres chiffres, tu attribues mal tes conversions, tu arbitres mal ton budget. Résultat, tu peux couper une source de trafic rentable par erreur. Le classement, lui, ne bouge pas d'un pixel à cause de ta bannière.
Sur la frontière exacte entre « données dégradées » et « décision foireuse », j'ai, honnêtement, encore des zones de flou, parce que ça dépend énormément de ta stack analytics. Mais le principe tient : la bannière ne te punit pas dans les SERP. Elle te prive de lucidité. Pour reconstruire une mesure propre malgré le refus, mes deux réflexes de base restent la [conformité RGPD de tes analytics](/rgpd-analytics-conformite-guide-2026/) et une [mesure d'audience privacy-first sans cookies](/privacy-first-analytics-mesurer-audience-sans-cookies/).
## Verdict sans appel
Le Consent Mode v2 est un problème d'annonceur et de mesure, pas un problème de référenceur. Ta place dans Google ne dépend pas de ta bannière. Ta capacité à comprendre ce qui marche, si. Câble-le proprement, garde tes preuves de consentement, et arrête de flipper pour ton ranking. Il va très bien.
## Sources
- [Consent Mode - Google Tag Platform](https://developers.google.com/tag-platform/security/concepts/consent-mode)
- [Les 4 signaux de consentement - Google Ads Help](https://support.google.com/google-ads/answer/13802165?hl=en)
- [Consentement requis EEE (annonceurs) - Google Ads Help](https://support.google.com/google-ads/answer/13695607?hl=en)
- [Seuil de modélisation des conversions - Google Ads Help](https://support.google.com/google-ads/answer/10548233?hl=en)
- [CMP certifiée et TCF (éditeurs) - Google Ad Manager Help](https://support.google.com/admanager/answer/13554116?hl=fr)
- [Consolidation ad_storage du 15 juin 2026 - Google Analytics Help](https://support.google.com/analytics/answer/17016975?hl=en)
- [Transition TCF v2.3 - IAB Europe](https://iabeurope.eu/all-you-need-to-know-about-the-transition-to-tcf-v2-3/)
---
## Trafic referral ChatGPT : le hype face aux vrais chiffres
- URL: https://www.referencement-internet-web.com/chatgpt-trafic-referral-marques-2026/
- Author: Baptiste P.
- Published: 2026-07-21T06:00:00
- Categories: analytics
Ouvre n'importe quelle présentation marketing de 2026, tu vas tomber dessus : le trafic referral ChatGPT, vendu comme le nouvel eldorado du web. Des courbes qui montent en flèche, des multiplicateurs de conversion à faire pâlir un drop rate de Genshin, et la promesse tranquille que le search organique appartient au passé. Spoiler alert : les chiffres racontent une histoire nettement moins sexy que le pitch.
On ne va pas se mentir, il s'est passé un truc réel. Le 7 mai 2026, ChatGPT a remplacé ses citations en bas de réponse par des noms de marque cliquables directement dans le corps du texte (selon Similarweb). Résultat immédiat : le total des referrals ChatGPT a bondi de 157,7 % en une semaine. Belle courbe pour une slide. Sauf qu'un +157 % sur une base minuscule, ça reste minuscule. Et c'est exactement le détail que tout le monde oublie de mentionner.
## 1,08 %. C'est le chiffre qui devrait te calmer
Le rapport Conductor 2026 a analysé 3,3 milliards de sessions sur 13 770 domaines. Verdict : le trafic referral IA, toutes plateformes confondues, pèse 1,08 % du trafic total des sites. Un pour cent. Pendant ce temps, le search organique reste à 33,8-42,4 % selon les secteurs.
Traduction pour les pressés : quand on te dit que « l'IA envoie désormais autant de trafic que Google », on te vend du rêve. En volume, on parle d'un canal qui commence à peine à exister. ChatGPT domine ce petit gâteau (87,4 % de tout le referral IA selon Conductor), mais dominer 1 % du web, ça reste 1 % du web. C'est un peu comme flex le meilleur K/D d'un lobby à trois joueurs.
Alors oui, ce 1 % grimpe (environ un point par mois d'après Conductor). Ça bouge, faut le suivre. Mais confondre « en croissance » et « déjà dominant », c'est la faute de débutant qui fait prendre de mauvaises décisions de budget.
## « ChatGPT convertit 23x mieux », vraiment ?
Là, on arrive au gros morceau du narratif. Tu as forcément croisé les multiplicateurs magiques : 4,4x, 23x, « l'IA convertit tellement mieux que l'organique ». Le truc, c'est que ces chiffres viennent de blogs SEO jamais nommés précisément, sans étude vérifiable derrière. Zéro traçabilité. Sur un sujet où l'argent se décide, c'est un red flag énorme.
Quand on regarde les sources qui existent vraiment, ça part dans tous les sens. Similarweb (panel agrégé) mesure une conversion de 7,1 % pour le referral ChatGPT, juste derrière le search payant à 7,8 %. Seer Interactive claque un spectaculaire 15,9 % contre 1,76 % pour l'organique, sauf que c'est un seul client et un échantillon IA riquiqui. Bref, chacun tire la couverture avec sa méthodo.
Et puis il y a le pavé dans la mare. L'étude peer-reviewed de Kaiser et Schulze, publiée dans Marketing Science, a analysé 973 sites e-commerce (20 milliards de dollars de revenu cumulé, plus de 50 000 transactions ChatGPT). Sa conclusion : le trafic ChatGPT convertit mieux que le social payant, mais moins bien que tous les autres canaux traditionnels, search organique compris. Il représente moins de 0,2 % du trafic total. Une source académique, relue par des pairs, qui dit exactement l'inverse du narratif LinkedIn. Devine laquelle des deux versions se fait le plus partager.
Honnêtement, sur la vraie valeur de ce trafic, j'hésite encore : les panels se contredisent, les périmètres ne sont jamais les mêmes, et l'étude la plus sérieuse est aussi la plus rabat-joie. Ce que je sais, c'est qu'aucun chiffre de conversion ne veut rien dire sans son échantillon, son secteur et sa date collés à côté.
Si tu veux creuser ce que vaut vraiment un visiteur venu d'une IA, c'est traité plus en détail dans notre papier sur le [ROI du trafic IA](/roi-trafic-ia-search-visiteur-conversion-valeur-2026).
## 87,4 % et 52,7 % : arrête de mélanger les deux
Voilà le piège où tombe 90 % des posts sur le sujet. Deux pourcentages circulent, et ils ne parlent pas de la même chose.
Le premier, 87,4 %, c'est la part de ChatGPT dans le trafic referral **envoyé** vers les sites tiers (Conductor). Autrement dit : parmi le trafic que les IA renvoient vers le web, ChatGPT en fournit l'écrasante majorité. Le second, 52,7 %, c'est la part de ChatGPT dans l'**usage** des plateformes IA elles-mêmes en mai 2026 (Similarweb), et celui-là est en chute libre : 86,7 % en janvier 2025, puis la dégringolade au profit de Gemini (27,3 %) et Claude (8,9 %).
Deux métriques, deux directions opposées. ChatGPT reste le plus gros pourvoyeur de clics sortants, tout en perdant du terrain sur le nombre d'utilisateurs qui l'ouvrent. Balancer un seul de ces chiffres sans dire lequel, c'est comme crier « victoire » en montrant le mauvais scoreboard.
## Mesurer sans te raconter d'histoires
Bonne nouvelle : depuis le 13 mai 2026, GA4 a ajouté un canal « AI Assistant » par défaut, avec détection automatique de ChatGPT, Gemini et Claude. Pas rétroactif, donc ne panique pas si ton historique est vide.
En attendant, la méthode manuelle marche très bien. Direction Rapports, Acquisition de trafic, puis tu filtres la dimension « Session source/medium » sur `chatgpt` : tu vois apparaître les lignes `chatgpt.com / referral`. Tu peux aussi te bricoler un regroupement de canaux personnalisé avec la regex `chatgpt\.com|chat\.openai\.com|openai\.com`.
Mais attention au gros angle mort. Les utilisateurs de ChatGPT gratuit, et globalement le trafic depuis l'app mobile, n'envoient aucun referrer. Ces visites atterrissent dans le trafic Direct de GA4. Concrètement : ton volume réel de trafic IA est sous-estimé, et personne ne sait de combien. Le nouveau canal et ses trous sont détaillés dans notre [guide sur le canal AI Assistant de GA4](/ga4-ai-assistant-channel-chatgpt-gemini-claude-trafic-2026). Et si ton vrai objectif c'est d'être cité par ces modèles, c'est un autre chantier, que je décortique côté [visibilité dans ChatGPT et Perplexity](/apparaitre-chatgpt-perplexity-reponses-ia).
## Verdict sans appel
Le trafic referral ChatGPT est réel, en croissance, et mérite ta ligne dans GA4. Point. Ce n'est pas un raz-de-marée qui remplace le SEO, ce n'est pas une machine à convertir 23x mieux, et personne ne sait vraiment combien ça vaut au visiteur près. Est-ce que ça restera à 1 % ? Là, franchement, j'ai pas de boule de cristal, et ceux qui prétendent en avoir une te vendent en général un logiciel.
Mon conseil : traite ce canal comme un investissement early access. Tu observes, tu mesures proprement, tu apprends la [différence entre part de trafic et taux de citation](/chatgpt-perplexity-11-pourcent-citations-strategie-distincte), mais tu ne rebases pas toute ta stratégie dessus sur la foi d'une slide à multiplicateurs. Les gens qui font ça en 2026, ils rejoueront la même erreur que ceux qui ont tout misé sur le référencement Amazon en oubliant leur propre site.
## Sources
- [Similarweb, mise à jour liens de marque du 7 mai 2026](https://www.similarweb.com/blog/insights/ai-news/chatgpt-referral-traffic-triples/)
- [Conductor, 2026 AEO/GEO Benchmarks Report](https://www.conductor.com/academy/aeo-geo-benchmarks-report/)
- [Kaiser & Schulze, ChatGPT Referrals to E-Commerce Websites, Marketing Science](https://pubsonline.informs.org/doi/10.1287/mksc.2025.0489)
- [Similarweb, Generative AI stats (conversion, usage plateformes)](https://www.similarweb.com/blog/marketing/geo/gen-ai-stats/)
- [Seer Interactive, case study conversion ChatGPT](https://www.seerinteractive.com/insights/case-study-6-learnings-about-how-traffic-from-chatgpt-converts)
- [DigitalApplied, part du trafic IA 2026 (usage plateformes)](https://www.digitalapplied.com/blog/ai-referral-traffic-share-2026-gemini-chatgpt-geo-analysis)
- [Search Engine Journal, canal AI Assistant dans GA4](https://www.searchenginejournal.com/google-analytics-adds-ai-assistant-as-default-channel-group/574974/)
- [Orbit Media, tracker le trafic IA dans GA4](https://www.orbitmedia.com/blog/track-ai-traffic-ga4/)
- [Rankshift, limite du referrer pour le trafic ChatGPT gratuit](https://www.rankshift.ai/blog/how-to-track-chatgpt-referrals-in-ga4/)
---
## Search Central Live Deep Dive débarque en Europe
- URL: https://www.referencement-internet-web.com/search-central-live-deep-dive-europe-2026-bilan/
- Author: Baptiste P.
- Published: 2026-07-20T06:00:00
- Categories: seo
Un studio qui annonce un jeu avec une fenêtre de sortie floue, aucune salle pour le lancement et zéro nom au casting. Voilà à peu près l'état du Search Central Live Deep Dive Europe 2026 au moment où j'écris ces lignes. Le 18 juin 2026, Google a posé sur son Search Central Blog que son format technique le plus pointu traversait enfin la frontière européenne. Première fois pour la région EMEA. Et pour changer, c'est la communauté SEO qui a eu la main sur une partie du casting.
Alors non, ceci n'est pas un compte rendu. L'événement n'a pas encore eu lieu. Ce que je peux faire, c'est vous dire ce qui est acté, ce qui ne l'est pas, et à quoi ressemble la seule répétition générale qu'on ait sous la main.
## Première fois que l'EMEA a droit à son Deep Dive
Le Deep Dive, ce n'est pas le Search Central Live classique qui passe quelques heures dans une ville et repart. C'est le gros format : plusieurs jours en présentiel, des discussions techniques qui creusent vraiment, des ateliers pratiques (Google Search Console, Google Trends), des études de cas et du networking communautaire. Google a aussi lancé un appel à propositions pour des Community Lightning Talks, ces micro-interventions où un membre de la communauté monte sur scène.
L'annonce est signée Cherry Prommawin et Gary Illyes, de l'équipe Search Relations. Sur le papier, les sujets pressentis tournent autour du crawling, de l'indexation, du ranking et de l'intégration de l'IA dans la recherche Google. Si le mot crawling vous fait déjà transpirer, j'ai un [rappel sur la crawlabilité et l'indexation technique](/crawlabilite-indexation-google-seo-technique/) qui remet les bases en place. Et pour l'histoire de l'IA dans les SERP, jetez un œil à [ce qui change côté AI Mode pour les éditeurs](/google-ai-mode-editeurs-contenu-2026/).
Côté public, Google vise les propriétaires de sites, les développeurs web et les pros du SEO. L'événement sera en anglais, avec une audience surtout européenne mais des internationaux bienvenus (par contre, le voyage et l'hébergement, c'est pour votre pomme). Petit piège à éviter : ne confondez pas ce Deep Dive avec le Search Central Live standard qui s'est tenu à Zurich le 9 décembre 2025. Même marque, format différent, une seule journée là-bas. C'est le genre de nuance qui fait passer un article de « recopié à la va-vite » à « la personne a vraiment lu les annonces ».
## La ville ? On a voté, le suspense continue
Le twist sympa de cette édition : Google a demandé à la communauté de choisir la ville hôte. Six candidates sur la table : Barcelone, Budapest, Berlin, Francfort, Lisbonne et Prague. Un formulaire d'intérêt permettait de voter pour la ville et la date, et de proposer ses Lightning Talks, avec une clôture au 1er juillet 2026. L'URL du formulaire était bien active, mais franchement squelettique, aucun détail opérationnel affiché.
La fenêtre visée pour l'événement : mi-septembre à début octobre 2026. Rien de ferme, juste une plage. Et Google avait calé l'annonce du lieu et des dates exactes pour le 6 juillet 2026.
Alors, quelle ville a gagné ? Honnêtement, aucune source fiable ne me le confirme, et je ne vais pas sortir un nom de ville de mon chapeau juste pour boucler le paragraphe. Si Berlin ou Lisbonne l'a emporté, ce sera à confirmer ailleurs qu'ici. Ce que je note, c'est que la fenêtre chevauche le calendrier chargé des grosses conférences SEO de l'automne, à commencer par [BrightonSEO et ses tendances ranking/LLM](/brightonseo-octobre-2026-tendances-ranking-llm/). Autant dire que les agendas de septembre-octobre vont saturer.
## Bangkok 2025, le seul brouillon qu'on ait
Pour deviner à quoi ressemblera l'édition européenne, il n'existe qu'un précédent : le tout premier Deep Dive, en Asie-Pacifique, à Bangkok, du 23 au 25 juillet 2025, au Carlton Hotel Sukhumvit. Environ 300 participants sur trois jours, d'après le récap qu'en a fait Natalia Witczyk sur LinkedIn.
Le programme APAC donnait le ton, jour par jour. Le premier jour sur le crawling. Le deuxième sur l'indexation, avec le contenu texte, les images, l'e-commerce et l'internationalisation. Le troisième sur le serving et la performance : la santé technique du site, et le rappel que les AI Overviews et l'AI Mode sont soumis aux mêmes règles que la recherche standard. Le tout servi en sessions principales, Community Lightning Talks de 7 minutes, sessions posters et Q&A via Slido.
Niveau intervenants, deux sources concordantes citent Gary Illyes (ranking, robots.txt) et Cherry Prommawin (budget de crawl). D'autres noms circulent (Liz Reid, Daniel Waisberg, entre autres), mais uniquement via Search Engine Journal, donc je les range dans la case « à vérifier » plutôt que dans le marbre.
Est-ce que l'Europe copiera ce déroulé au millimètre ? Rien ne le garantit. Mais si vous voulez anticiper les thèmes, Bangkok reste le meilleur indice disponible.
## Ce qu'on ne sait pas (et je ne vais pas faire semblant)
C'est là que je pose les mains à plat sur la table. Pour l'édition Europe : aucun intervenant confirmé. Aucun. John Mueller, souvent associé à ce genre d'événements, n'est pas confirmé non plus, ni pour Zurich en décembre 2025 sur la base des sources primaires, ni a fortiori pour ce Deep Dive. Pas de programme détaillé, pas de liste de sessions, pas de chiffre de fréquentation. Et surtout pas de bilan, puisqu'il n'y a rien à biler tant que l'événement ne s'est pas tenu.
Sur ce point, j'assume mon incertitude : je préfère un article honnête qui dit « on ne sait pas encore » qu'un faux récap gonflé de détails inventés. C'est exactement le genre de contenu creux que Google dit vouloir déclasser, alors autant ne pas se tirer une balle dans le pied.
## Verdict
Un format technique lourd, première fois en Europe, avec un vote communautaire pour la ville : sur le fond, c'est une bonne nouvelle pour quiconque bosse le référencement de ce côté du globe. Reste que tout le concret (ville, dates, casting, programme) attend confirmation. Je surveille, je ne spécule pas. Rendez-vous quand Google lâchera les vraies infos, là on pourra parler pour de bon.
## Sources
- [Google Search Central Blog, annonce Deep Dive Europe 2026](https://developers.google.com/search/blog/2026/06/scl-deep-dive-europe-2026)
- [Google Search Central, page événement Deep Dive](https://developers.google.com/search/events/search-central-live-deep-dive)
- [ppc.land, vote communautaire sur la ville hôte](https://ppc.land/google-asks-seo-community-to-vote-on-deep-dive-europe-2026-location/)
- [Search Engine Journal, Search Central APAC 2025 jour 1](https://www.searchenginejournal.com/google-search-central-apac-2025-everything-day-one/551634/)
- [Natalia Witczyk, récap Deep Dive APAC 2025 sur LinkedIn](https://www.linkedin.com/pulse/google-search-central-live-deep-dive-recap-natalia-witczyk-7bjwf)
- [ppc.land, Search Central Live de retour à Zurich en décembre 2025](https://ppc.land/google-search-central-live-returns-to-zurich-in-december-2025/)
---
## Fil d'Ariane 2026 : le baliser après le retrait mobile
- URL: https://www.referencement-internet-web.com/fil-ariane-breadcrumb-seo-navigation-schema-2026/
- Author: Guillaume P.
- Published: 2026-07-17T06:00:00
- Categories: seo
Le 23 janvier 2025, Google a arrêté d'afficher le fil d'Ariane dans les résultats de recherche sur mobile. Plus de `Accueil > Blog > SEO`, juste le nom de domaine. La question m'est tombée dessus la semaine suivante, posée par un client e-commerce un peu paniqué : « Si Google ne l'affiche plus, on retire le balisage ? »
Non. Et c'est tout l'objet de cet article. Le fil d'Ariane (breadcrumb, si vous préférez l'anglais) reste un des balisages les plus rentables du SEO technique, même après ce retrait. Voyons pourquoi, et comment le poser proprement.
## Ce que Google a vraiment changé en janvier 2025
Reprenons les faits, parce que la rumeur a vite gonflé la chose en « Google tue le fil d'Ariane ». Faux.
Le changement ne touche que l'affichage mobile. À partir du 23 janvier 2025, Google n'affiche plus le fil d'Ariane dans les résultats de recherche mobile, dans toutes les langues et régions : à la place, on ne voit que le nom de domaine. Le desktop n'est pas concerné. Sur ordinateur, cette fonctionnalité reste disponible dans toutes les régions et langues où Google Search existe.
La raison avancée, relayée par Search Engine Journal et Search Engine Land : le fil d'Ariane se retrouvait tronqué sur les petits écrans et n'apportait pas grand-chose à l'internaute en situation de recherche mobile. Google a donc simplifié l'URL visible. À noter que cette fonctionnalité tournait sur mobile depuis environ seize ans, lancée en 2009 selon Android Authority. Seize ans de service avant la sortie discrète.
Le point qui doit vous rassurer : si vous utilisez déjà le balisage, il n'y a rien à faire. Le balisage BreadcrumbList reste supporté et recommandé sur desktop, le rapport dédié dans la Search Console continue de fonctionner, et le Rich Results Test valide toujours ce balisage. Personne ne vous demande de toucher à votre code.
## Pourquoi le garder malgré tout
Là je vais être direct, parce que c'est le cœur du sujet.
D'abord, le desktop. L'affichage enrichi y est intact. Sur cette seule surface, votre résultat affiche un chemin de navigation lisible plutôt qu'une URL brute. Ça reste un gain de clarté dans la SERP, et donc des [résultats enrichis](/rich-snippets-resultats-enrichis-guide) que vos concurrents laissent parfois sur la table.
Ensuite, le maillage. Gary Illyes, chez Google, l'a dit dès 2017 : « We like them. We treat them as normal links in, e.g., PageRank computation. » Les liens d'un fil d'Ariane sont traités comme des liens normaux dans le calcul du PageRank. Autrement dit, votre breadcrumb participe à votre [maillage interne](/maillage-interne-strategie-bonnes-pratiques-seo) et à la circulation d'autorité entre vos pages. Ce bénéfice-là n'a jamais dépendu de l'affichage en SERP. Il vit dans le code, il y reste.
Il y a aussi l'angle IA. Semrush avance que les données structurées, dont le balisage breadcrumb, pourraient aider les modèles de langage à mieux lire et comprendre une page, donc à la citer en recherche générative. J'insiste sur le conditionnel : Semrush ne chiffre pas cette affirmation, aucune étude n'est produite à l'appui. C'est une hypothèse qualitative, à traiter comme telle. Je ne vais pas vous vendre un miracle GEO sur cette base.
Enfin, la seule donnée chiffrée solide que j'ai trouvée sur l'impact réel. La plateforme de tests A/B SearchPilot a mené l'expérience chez un client du secteur du voyage, anonymisé. Premier temps : ajout du seul balisage BreadcrumbList côté serveur. Résultat « inconclusive », rien de significatif. Deuxième temps : ajout d'un fil d'Ariane visible sur mobile, en plus du balisage schema. Là, gain de 5 % de trafic organique, statistiquement significatif, avec une nette amélioration du positionnement. Le CTR mobile, lui, n'a que très peu bougé.
Ce chiffre est précieux mais c'est un cas unique, un seul client anonymisé. Ne le prenez pas pour une moyenne de marché. Ce qu'il suggère, en revanche, c'est net : le balisage seul ne suffit pas, c'est la combinaison balisage plus fil d'Ariane visible qui a payé.
## Le balisage BreadcrumbList, proprement
Passons au concret. Le fil d'Ariane se balise en JSON-LD, le format que Google recommande pour les [données structurées](/schema-markup-donnees-structurees-seo). Schema.org définit un BreadcrumbList comme une liste chaînée de pages liées, décrites au minimum par leur URL et leur nom, se terminant généralement par la page courante.
Trois propriétés par élément de la liste (chaque `ListItem`) :
- `position` : la place du maillon dans le fil. La position 1 marque le début. Schema.org précise que cette propriété sert à reconstruire l'ordre des éléments.
- `name` : le titre du maillon affiché pour l'utilisateur.
- `item` : l'URL de la page que désigne le maillon. Elle n'est pas requise pour le dernier élément, la page courante.
L'ordre suit la convention `itemListOrder` ascendante : les valeurs les plus basses en premier, le premier élément correspondant au sommet du fil. Pour être éligible au résultat enrichi, un BreadcrumbList doit contenir au moins deux `ListItem`. Inclure une entrée pour le domaine du site ou pour la page courante elle-même est facultatif.
Voici à quoi ça ressemble, avec deux niveaux et le dernier maillon sans `item` :
```json
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Livres",
"item": "https://example.com/livres"
},
{
"@type": "ListItem",
"position": 2,
"name": "Science-fiction"
}
]
}
```
Un conseil que Google martèle et que je vois trop peu appliqué : refléter le parcours utilisateur typique vers la page, pas la structure d'URL. « Instead of mirroring the URL structure », dit la doc. Votre arborescence de dossiers et le chemin qu'un humain suit pour arriver sur la page ne coïncident pas toujours. C'est le second qu'il faut baliser.
Une fois posé, testez. Le Rich Results Test, sur search.google.com/test/rich-results, valide le rendu avant mise en production. Et surveillez le rapport dédié dans [Google Search Console](/google-search-console-tutoriel-complet-debutants), lancé le 19 septembre 2019, sous la section Améliorations. L'erreur qu'il remonte le plus souvent : `Missing field 'item'`. Neuf fois sur dix, un développeur a oublié l'URL sur un maillon intermédiaire. Vérifiez ce champ en premier.
## Le fil visible : ne pas l'oublier
Le balisage, c'est la moitié du travail. L'autre moitié, c'est le fil d'Ariane que l'internaute voit sur la page. Et c'est souvent là que ça pèche.
Le Nielsen Norman Group recommande le fil d'Ariane depuis 1995, pour ses bénéfices de navigation à quasi aucun coût d'interface. Leur définition est claire : une liste de liens représentant la page courante et ses « ancêtres », page parente, grand-parente, et ainsi de suite. Ce point, je le répète à chaque audit : le fil d'Ariane montre la hiérarchie du site, pas l'historique de navigation de la session. Ce n'est pas un bouton retour du navigateur.
Cette distinction structure d'ailleurs la typologie de Semrush, qui retient trois types. Le fil hiérarchique (hierarchy-based), qui suit la structure du site du haut vers le bas, celui dont on parle ici. Le fil par attributs (attribute-based), qui reflète les attributs d'un produit, surtout en e-commerce, en complément du hiérarchique. Et le fil par historique (path-based), fondé sur le parcours propre à chaque visiteur, que Semrush déconseille et juge « hard to find » sur les sites modernes. Si un prestataire vous propose ce dernier, méfiance.
Le NN/g note aussi un détail qui devrait clore tout débat interne : en test utilisateur, le fil d'Ariane ne pose jamais de problème. Les gens peuvent l'ignorer, ce petit élément de design, mais ils ne le mécomprennent jamais et ne peinent jamais à l'utiliser. C'est rare, une composante d'UI aussi indolore.
Deux réserves honnêtes, quand même. Sur mobile, évitez que le fil passe sur plusieurs lignes ou devienne trop petit pour un contact tactile confortable, prévient le NN/g. Et tous les sites n'en tirent pas le même bénéfice : Semrush rapporte le cas du blog MEDvidi, où moins de 0,5 % des visiteurs cliquaient sur les liens du fil, ce qui a conduit à le retirer. Un cas isolé, non généralisable, mais qui rappelle qu'un site à un seul niveau de profondeur n'a pas forcément besoin d'un fil d'Ariane.
Sur le placement, la convergence est nette : près du haut de page, sous la navigation principale, à un emplacement cohérent sur tout le site.
## Ce que je ferais à votre place
Vous gardez le balisage BreadcrumbList, sans hésiter. Le retrait mobile de janvier 2025 ne change rien à sa valeur : desktop intact, PageRank via les liens, lecture facilitée pour les moteurs. Vous ne le retirez que si votre site est réellement plat, un seul niveau, où le fil ferait doublon avec la navigation principale.
Et surtout, vous ne vous contentez pas du code invisible. Le seul chiffre fiable de ce dossier, le +5 % de SearchPilot, est venu du fil visible combiné au schema, pas du schema seul. C'est là que se joue le vrai gain. Le reste, c'est de l'hygiène technique : deux maillons minimum, le champ `item` renseigné partout sauf sur la page courante, et un passage au Rich Results Test avant chaque déploiement.
Google a d'ailleurs déjà retiré [d'autres affichages enrichis](/fin-faq-rich-results-google-7-mai-2026-impact-seo) sans que le balisage sous-jacent perde son intérêt. Le fil d'Ariane suit la même logique : moins visible en SERP, toujours utile dans le moteur.
## Sources
- Google Search Central, Documentation BreadcrumbList : https://developers.google.com/search/docs/appearance/structured-data/breadcrumb
- Schema.org, Définition BreadcrumbList : https://schema.org/BreadcrumbList
- Google Search Central Blog, Simplifying breadcrumbs (23 janvier 2025) : https://developers.google.com/search/blog/2025/01/simplifying-breadcrumbs
- Search Engine Land, Google no longer shows breadcrumbs in mobile search : https://searchengineland.com/google-no-longer-shows-breadcrumbs-in-mobile-search-results-snippets-451079
- Search Engine Journal, Google drops breadcrumbs from mobile search results : https://www.searchenginejournal.com/google-drops-breadcrumbs-from-mobile-search-results/538091/
- Android Authority, Mobile Google Search breadcrumbs : https://www.androidauthority.com/mobile-google-search-breadcrumbs-3520144/
- Search Engine Journal, Breadcrumb navigation ranking factors (citation Gary Illyes) : https://www.searchenginejournal.com/ranking-factors/breadcrumb-navigation/
- Nielsen Norman Group, Breadcrumbs : https://www.nngroup.com/articles/breadcrumbs/
- Semrush, Breadcrumbs for websites : https://www.semrush.com/blog/breadcrumbs-for-websites/
- SearchPilot, Mobile breadcrumbs and server-side schema : https://www.searchpilot.com/resources/case-studies/mobile-breadcrumbs-and-server-side-schema
- WP Tavern, Google Search Console adds breadcrumbs report : https://wptavern.com/google-search-console-adds-breadcrumbs-report-sends-out-warnings-for-structured-data-errors
---
## Délivrabilité email 2026 : SPF, DKIM, DMARC et BIMI
- URL: https://www.referencement-internet-web.com/delivrabilite-email-spf-dkim-dmarc-bimi-2026/
- Author: Baptiste P.
- Published: 2026-07-16T06:00:00
- Categories: marketing-digital
La délivrabilité des emails, c'est le moment où votre message atterrit en boîte de réception plutôt que dans le dossier spam, ou pire, se fait rejeter avant même d'arriver. Depuis février 2024, ce n'est plus une affaire de chance ni de bon contenu : Google, Yahoo puis Microsoft ont chacun posé leurs conditions techniques. SPF, DKIM, DMARC et maintenant BIMI ne sont plus des cases à cocher optionnelles pour qui envoie en volume. Voici ce qui a changé, dans l'ordre où c'est arrivé, et ce qu'il faut faire concrètement.
## Février 2024 : Google et Yahoo posent les règles
Le point de bascule s'appelle « bulk sender ». Chez Google comme chez Yahoo, la définition est la même : plus de 5000 messages par jour vers des comptes personnels (Gmail d'un côté, boîtes Yahoo de l'autre). Au-delà de ce seuil, l'expéditeur bascule dans une catégorie soumise à des exigences renforcées, entrées en vigueur le 1er février 2024.
Le socle est identique : SPF et DKIM alignés sur le domaine, et un enregistrement DMARC publié. Bonne nouvelle pour ceux qui débutent, une politique `p=none` (surveillance seule, sans blocage) suffit à passer la porte. C'est le minimum accepté, pas le niveau recommandé.
Là où ça se complique, c'est le taux de plainte, et c'est un point que beaucoup présentent de travers. Google recommande de rester sous 0,10 % de plaintes et prévient de ne jamais atteindre 0,30 %. À ce seuil critique, mesuré via Postmaster Tools, vous perdez le support de mitigation de Google jusqu'à repasser sous 0,3 % pendant sept jours consécutifs. Yahoo, lui, fixe directement le plafond à moins de 0,3 %, mais calculé sur le mail délivré en boîte de réception, pas sur le volume total envoyé. Deux fournisseurs, deux méthodes de calcul : ne les mélangez pas dans vos tableaux de bord.
Dernier morceau de ce paquet 2024 : la désinscription en un clic. La norme technique existe depuis janvier 2017, c'est la RFC 8058, qui impose l'en-tête `List-Unsubscribe-Post: List-Unsubscribe=One-Click` avec au moins une URL HTTPS. Ce qui est nouveau, c'est l'obligation : les expéditeurs qui incluaient déjà un lien de désinscription avaient jusqu'au 1er juin 2024 pour l'implémenter. Google impose d'honorer la demande sous 48 heures, Yahoo parle de deux jours. Les emails transactionnels (confirmation de commande, réinitialisation de mot de passe) ne sont pas concernés, seulement le commercial et le marketing. C'est le même genre de discipline réglementaire qu'on retrouve côté [conformité analytics et RGPD](/rgpd-analytics-conformite-guide-2026) : une case oubliée et tout un canal se grippe.
J'ai vu un client, une boutique avec une newsletter hebdo tranquille, voir sa délivrabilité s'effondrer en mars 2024 simplement parce que son DMARC n'était pas publié. Rien de cassé dans le contenu, rien de spammy. Juste un enregistrement DNS manquant. Ça vaut le coup de vérifier avant de chercher des raisons compliquées, c'est souvent bête à ce point. Si vous montez une stratégie d'[email marketing](/email-marketing-strategie-outils-2026) sérieuse, l'authentification passe avant la ligne d'objet.
## Mai 2025 : Microsoft entre dans la danse
Un an plus tard, Outlook a rejoint le mouvement. Depuis le 5 mai 2025, Microsoft applique ses propres exigences aux expéditeurs de plus de 5000 emails par jour vers les adresses outlook.com, hotmail.com et live.com.
Le fond est du même bois : un SPF configuré et valide, un DKIM valide, un alignement SPF ou DKIM avec le domaine From, et un DMARC publié (`p=none` accepté là aussi). Un email non conforme se voit rejeter avec un code précis : `550 5.7.515`, qui signale que le domaine expéditeur n'atteint pas le niveau d'authentification requis. Et attention à une idée reçue : demander au destinataire de vous ajouter en liste blanche (Safe Sender List) ne contourne rien du tout. L'authentification passe avant la préférence du destinataire.
Un mot important, parce que c'est la tentation classique : ne collez pas à Microsoft les seuils de Google et Yahoo. Les sources techniques disponibles sur Outlook ne mentionnent aucun taux de plainte chiffré ni obligation formelle de désinscription en un clic. Le volet Microsoft, à ce stade, est centré sur l'authentification. Extrapoler un « 0,3 % côté Outlook » serait inventer.
## Novembre 2025 : Gmail serre la vis pour de bon
La phase de tolérance de 2024 est terminée. Depuis novembre 2025, Gmail applique des rejets temporaires (codes 4.7.x, qui limitent le débit du trafic non conforme) et des rejets permanents (codes 5.7.x, qui bloquent purement le message), avec perte du support de mitigation à la clé. En clair : ce qui passait avec un avertissement il y a deux ans se fait maintenant refouler.
## Le socle technique, sans le jargon
Un rappel utile, parce que ces trois protocoles ne font pas la même chose. SPF (RFC 7208) autorise des serveurs à envoyer pour votre domaine, mais il a une limite piégeuse : une évaluation ne doit pas dépasser 10 requêtes DNS, sinon c'est un PermError, et le maximum de requêtes renvoyant un résultat vide est fixé à 2. DKIM (RFC 6376) signe cryptographiquement le message ; la pratique du secteur recommande désormais des clés de 2048 bits et une rotation tous les six mois, conformément aux recommandations M3AAWG. DMARC, enfin, s'appuie sur les deux pour décider du sort d'un email qui échoue.
Et voici le point que trop d'expéditeurs oublient : l'authentification prouve votre identité, elle ne garantit pas votre place en boîte de réception. Un domaine parfaitement authentifié peut quand même finir en spam si sa réputation est dégradée (taux de plainte, rebonds, engagement, historique de l'IP). D'où l'intérêt de démarrer un nouvel envoi en douceur, avec un warm-up d'IP à faible volume (de l'ordre de 50 à 100 emails par jour), et de garder une hygiène de liste stricte pour éviter les spam traps, ces adresses piégées créées par les fournisseurs pour repérer les mauvaises pratiques. Toucher un spam trap peut suffire à une mise en liste noire.
## BIMI et DMARCbis : la couche 2026
BIMI, c'est le logo de votre marque affiché à côté de l'expéditeur. Sauf que le prérequis est exigeant : un DMARC en `p=quarantine` ou `p=reject` avec `pct=100`. La politique `p=none` n'est pas supportée, donc BIMI récompense ceux qui sont allés jusqu'au bout. Le logo doit être un SVG au profil Tiny-PS, carré, d'une taille maximale de 32 Ko (16 Ko conseillés pour une compatibilité maximale). Pour obtenir la coche bleue vérifiée dans Gmail, il faut un VMC (Verified Mark Certificate) ; un CMC est accepté en alternative, mais sans la coche. Comptez jusqu'à 48 heures de propagation après ajout de l'enregistrement DNS. Les émetteurs de VMC confirmés en 2026 sont DigiCert, GlobalSign et SSL.com.
Est-ce que BIMI vaut l'investissement pour une PME ? Honnêtement, j'hésite encore. La coche bleue rassure et fait partie de ces signaux qui font de votre [marque un actif SEO à part entière](/marque-actif-seo-branding-pese-plus-backlinks-2026), mais le coût du certificat n'est pas anodin, et le gain de délivrabilité pur reste discutable. À trancher au cas par cas.
Côté norme, un changement de fond en mai 2026 : DMARCbis. Les RFC 9989, 9990 et 9991 remplacent la vieille RFC 7489 (publiée en mars 2015, statut Informational) et font passer DMARC au statut Proposed Standard. Rien à refaire dans l'immédiat côté configuration, mais la référence officielle a changé.
## Où en est vraiment le marché
Un chiffre circule beaucoup : 52,1 % d'adoption DMARC en 2026 (937 931 domaines valides sur 1,8 million analysés par EasyDMARC, contre 47,7 % en 2025). Sauf que ce chiffre ne mesure que la présence d'un enregistrement. En réalité, seulement 23 % environ des domaines analysés sont en politique d'application (`quarantine` ou `reject`), et à peine 9 % combinent application ET reporting, la configuration réellement protectrice. Ne présentez jamais ces trois nombres comme interchangeables : ils décrivent des étapes différentes.
Le fossé se voit dans les segments. Le Fortune 500 affiche 95 % d'adoption et plus de 80 % en application. Les Inc. 5000, elles, sont plus de la moitié à rester en `p=none`, c'est-à-dire en simple surveillance. Publier un DMARC, c'est franchir la porte. La refermer derrière soi en passant à `reject`, c'est une autre histoire, et la majorité ne le fait pas.
La délivrabilité en 2026 se joue donc sur deux plans : la conformité technique, qui est devenue non négociable, et la réputation, qui se travaille dans la durée. Le premier vous ouvre la porte, le second décide si vous entrez.
## Sources
- [Email sender guidelines | Google](https://support.google.com/a/answer/81126?hl=en)
- [Sender best practices | Yahoo Sender Hub](https://senders.yahooinc.com/best-practices/)
- [RFC 8058 : Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html)
- [Outlook new requirements 2025 | dmarcwise](https://dmarcwise.io/blog/outlook-new-requirements-2025)
- [Gmail enforcement ramps up | Red Sift](https://redsift.com/resources/blog/gmails-enforcement-ramps-up-what-bulk-senders-need-to-know)
- [Set up BIMI | Google Workspace Help](https://knowledge.workspace.google.com/admin/security/set-up-bimi)
- [Creating BIMI SVG logo files | BIMI Group](https://bimigroup.org/creating-bimi-svg-logo-files/)
- [VMC issuers | BIMI Group](https://bimigroup.org/vmc-issuers/)
- [DMARCbis published as RFC 9989, 9990, 9991 | Suped](https://www.suped.com/blog/dmarcbis-is-now-published-as-rfc-9989-9990-9991)
- [2026 DMARC Adoption Report | EasyDMARC](https://easydmarc.com/blog/easydmarc-releases-2026-dmarc-adoption-report/)
- [DMARC adoption 2026 : only 9 % protected | dmarcreport](https://dmarcreport.com/blog/the-dmarc-adoption-2026-domains-records-only-9-percent-protected/)
- [DKIM best practices | MxToolbox](https://mxtoolbox.com/dmarc/details/dkim/best-practices)
---
## SMS marketing 2026 : le canal direct sous-exploité
- URL: https://www.referencement-internet-web.com/sms-marketing-2026-strategie-canal-direct/
- Author: Baptiste P.
- Published: 2026-07-15T06:00:00.000Z
- Categories: marketing-digital
Petit test. Regardez votre téléphone. Vous avez sûrement une notif Discord en attente, trois mails pas ouverts et un SMS. Lequel des trois vous avez lu en premier ? Le SMS. Évidemment. Et pourtant, quand on parle SMS marketing en 2026, la moitié des marketeurs lèvent les yeux au ciel, en mode « le SMS, c'est du spam de 2010 ». Plot twist : les chiffres racontent une tout autre histoire.
Perso, le seul SMS commercial que j'ouvre sans râler, c'est le code de suivi quand ma commande de composants pour le PC arrive. Deux lignes, une info utile, zéro friction. C'est exactement ce que le canal fait de mieux, et c'est aussi ce que beaucoup de marques oublient de faire.
## Un canal que tout le monde snobe, à tort
Commençons par le chiffre qui claque, mais avec un astérisque énorme. On répète partout que le SMS a un taux d'ouverture de 98 %. Sauf que techniquement, c'est faux. Ce fameux 98 % est un taux de délivrabilité, qu'on assimile à une ouverture faute de pixel de suivi propre au SMS. Contrairement à l'email, un SMS n'embarque aucun tracker : la marque ne sait pas si vous l'avez réellement lu, seulement qu'il a été livré. Donc oui, le SMS arrive quasi partout. Non, personne ne peut prouver que vous l'avez ouvert.
Ceci dit, même corrigé, l'écart avec l'email reste énorme. Selon Klaviyo, l'email plafonne à 18,22 % d'ouverture en moyenne en France (données DMA France). Côté engagement, le SMS affiche un taux de clic de 5,76 % au niveau mondial, et une fourchette large de 6 à 16 % en France, contre 5,3 % pour l'email français. Ajoutez à ça que 90 % des SMS seraient lus dans les trois à cinq minutes suivant la réception, d'après plusieurs agrégateurs, et vous comprenez pourquoi le canal reste imbattable sur l'urgence.
Le truc, c'est que le marché n'a rien d'un truc de niche. Selon le baromètre af2m publié en février 2026, la France a envoyé 15,26 milliards de SMS push en 2025, soit une hausse de 7,51 % sur un an. La répartition est parlante : 59,2 % de transactionnel (livraison, authentification, alertes) contre 40,8 % de promotionnel. Autrement dit, le gros du volume, ce n'est pas de la pub, c'est du service. Et c'est là que le canal est le plus légitime.
Côté secteurs, le retail domine avec 31 % des envois, devant la banque et l'assurance (19 %), les services (14 %), l'e-commerce (10 %) et la santé (8 %). Rien d'étonnant : ce sont exactement les univers où une info arrivant en temps réel change quelque chose pour le client.
Là où je tique, c'est sur le décalage entre ces performances et le budget que les boîtes y consacrent. Le SMS reste souvent traité comme le petit cousin de l'[email marketing](/email-marketing-strategie-outils-2026), alors qu'il joue dans une autre catégorie sur la réactivité. Bien intégré dans un scénario de [marketing automation](/marketing-automation-outils-strategie-2026), en relais d'un mail resté sans réponse, il devient le canal de rattrapage le plus efficace de votre stack. Le vrai sujet n'est pas « SMS ou email », c'est « SMS et email, chacun à sa place ».
## Ce que la loi vous autorise vraiment
Avant de dégainer votre première campagne, une règle non négociable : le consentement. La CNIL est claire, la prospection commerciale par SMS envers un particulier exige un opt-in préalable, un consentement « libre, spécifique, éclairé et univoque », matérialisé par une case à cocher non pré-cochée. Pas de case cochée d'office, pas de listes rachetées, pas de « qui ne dit mot consent ».
Il existe une exception, la fameuse dispense « client existant ». Si la personne est déjà cliente et que le SMS concerne des produits ou services similaires, le consentement préalable n'est pas requis. Utile, mais à manier avec précaution : « similaire » ne veut pas dire « n'importe quoi ». Et dans tous les cas, chaque message doit identifier clairement l'émetteur et proposer un moyen simple de se désabonner, le classique mot-clé STOP.
Le prix de l'erreur ? Salé. L'article L34-5 du Code des postes prévoit jusqu'à 75 000 euros d'amende pour une personne physique et 375 000 euros pour une personne morale. Ajoutez la sanction RGPD côté CNIL, qui peut grimper jusqu'à 4 % du chiffre d'affaires mondial annuel. On ne parle plus de tape sur les doigts.
Un point d'actualité peut prêter à confusion, alors soyons précis. Le 25 juin 2026, le Conseil constitutionnel, dans sa décision n°2026-1210 QPC, a censuré le cumul de poursuites par plusieurs autorités (CNIL, ARCEP, DGCCRF) pour un même manquement à l'article L34-5, au nom du principe non bis in idem. Attention au contresens : ça ne veut pas dire que l'opt-in devient optionnel. L'obligation de consentement préalable n'est absolument pas remise en cause, seul le régime de sanctions cumulatives disparaît. L'abrogation complète de l'article est même programmée au 31 octobre 2027 si le législateur ne fait rien d'ici là. Bref, on surveille, mais on ne relâche rien.
À côté de la loi, il y a les bonnes pratiques du secteur. La nouvelle charte Business Messaging de l'af2m, en vigueur depuis le 1er mars 2026, a assoupli les horaires : les messages promotionnels sont désormais autorisés de 8h à 21h30, recommandés du lundi au samedi, le dimanche et les jours fériés étant tolérés mais déconseillés. Elle encadre aussi le nom d'expéditeur, limité à 11 caractères strictement alphanumériques, sans champ trompeur imitant un numéro. Si vous voulez creuser l'articulation avec la conformité globale de vos outils de mesure, mon collègue a fait le tour dans son guide [RGPD et analytics](/rgpd-analytics-conformite-guide-2026).
## RCS : la relève arrive, mais pas partout
Le vrai game-changer annoncé, c'est le RCS. En clair, le successeur du SMS : messages enrichis, images, boutons, carrousels, une expérience qui ressemble enfin à une conversation moderne. Et 2025-2026 marque un tournant, parce qu'Apple a fini par lâcher du lest. Le support RCS est arrivé avec iOS 18 en septembre 2024, le RCS for Business avec iOS 18.1 en octobre, et le chiffrement de bout en bout est en cours de déploiement, encore en bêta avec iOS 26.5 en mai 2026.
Côté adoption française, ça bouge vite. Selon le baromètre af2m, 84 % du parc de smartphones était compatible RCS fin 2025, soit 52 millions d'appareils, et l'accès a été déployé chez les quatre opérateurs majeurs (Orange, Bouygues, Free Mobile, SFR) dès la fin du premier trimestre 2025. Du côté des marques, 738 enseignes étaient actives en RCS for Business fin 2025, pour 200 millions de messages échangés sur l'année.
Maintenant, la douche froide, parce que je déteste le hype non calibré : le RCS est en cours de déploiement, pas généralisé. 84 % de compatibilité, ce n'est pas 100 %. Le chiffrement E2E est encore en bêta. Et 738 enseignes, c'est une goutte d'eau face au nombre total d'annonceurs. Honnêtement, sur les taux d'engagement RCS en France, je préfère rester prudent : les chiffres qui circulent viennent surtout de fournisseurs qui ont tout intérêt à les gonfler, et l'af2m ne publie pas de taux d'ouverture RCS isolé. Donc je ne vous sortirai pas un joli pourcentage que je ne peux pas sourcer.
Le bon réflexe pour 2026 : penser SMS et RCS comme un continuum, pas comme un remplacement. La charte af2m précise d'ailleurs qu'un même consentement vaut pour les deux canaux. Vous construisez votre base d'opt-in maintenant, en SMS, et vous basculez vers le RCS au fur et à mesure que le parc suit.
## Verdict
Le SMS marketing en 2026, ce n'est ni un fossile ni une baguette magique. C'est un canal direct qui livre presque à coup sûr, qui se lit dans la minute, et que trop de marques laissent dormir par flemme ou par peur de la réglementation. La peur est mal placée : les règles sont écrites, publiques, et franchement pas compliquées à respecter. Un opt-in propre, un STOP visible, des horaires corrects, un message qui apporte une vraie info.
Faites ça bien, connectez-le à vos [scénarios de conversion](/taux-conversion-optimisation-cro-guide-2026), et vous tenez le canal le plus sous-coté de votre arsenal. Le reste, c'est du bruit.
## Sources
- [CNIL : la prospection commerciale par SMS, MMS et automate d'appel](https://www.cnil.fr/fr/la-prospection-commerciale-par-courrier-electronique-sms-mms-et-automate-dappel)
- [Legifrance : article L34-5 du Code des postes et des communications électroniques](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042155961/)
- [af2m : Baromètre du marketing SMS 2025](https://af2m.org/barometre-du-marketing-sms-2025/)
- [af2m : Charte Business Messaging 2026](https://af2m.org/charte-business-messaging-2026-laf2m-renforce-les-regles-du-jeu/)
- [Conseil constitutionnel : décision n°2026-1210 QPC du 25 juin 2026](https://www.conseil-constitutionnel.fr/actualites/communique/decision-n-2026-1210-qpc-du-25-juin-2026-communique-de-presse)
- [Klaviyo : SMS vs email marketing, les chiffres](https://www.klaviyo.com/fr/blog/sms-email-marketing)
- [Sinch : le calendrier du support RCS par Apple](https://sinch.com/fr/blog/apple-support-rcs/)
- [af2m : les chiffres du RCS en France au 3e trimestre 2025](https://af2m.org/les-chiffres-du-rcs-en-france-pour-le-3%E1%B5%89-trimestre-2025/)
- [e-marketing.fr : le SMS résiste et le RCS décolle en 2025](https://www.e-marketing.fr/data-1091/veille-et-tribune-2225/marketing-mobile-le-sms-resiste-et-le-rcs-decolle-en-2025-169356/amp)
---
## Retargeting 2026 : le RGPD, pas la fin des cookies
- URL: https://www.referencement-internet-web.com/retargeting-remarketing-publicitaire-rgpd-2026/
- Author: Baptiste P.
- Published: 2026-07-13T06:00:00.000Z
- Categories: marketing-digital
Pendant cinq ans, tout le monde m'a chanté la même rengaine : « prépare-toi, en 2025 les cookies tiers meurent, ton retargeting est fini ». J'ai lu des dizaines de tribunes là-dessus, monté des slides de formation entières autour de cette échéance. Et puis le 22 avril 2025, Google a tout balayé d'un communiqué. Anthony Chavez, le VP Privacy Sandbox, a annoncé le maintien de l'approche actuelle et l'abandon d'un nouveau prompt de consentement dédié aux cookies tiers dans Chrome. Traduction : le couperet promis n'est jamais tombé.
Alors si vous êtes venu chercher le énième article qui vous dit que le retargeting est mort, vous pouvez fermer l'onglet. Le sujet de 2026 n'est pas la disparition d'une technologie. C'est le consentement.
## Le retargeting n'est pas mort, il est sous conditions
Reprenons les bases, parce que la confusion règne. Le retargeting, comme le définit Criteo, cible « des utilisateurs qui ont déjà visité votre site ou interagi avec votre marque sans convertir ». Concrètement, on recible des visiteurs anonymes via des canaux payants (display, Meta, LinkedIn) en s'appuyant sur des données de navigation : cookies, pixels, signaux serveur.
Le remarketing, lui, joue sur un autre terrain. Toujours selon Criteo, il désigne « des tactiques de réengagement utilisant des sources de données propriétaires, comme les adresses email ». Donc des contacts identifiés, votre CRM, vos listes email. La nuance est technique mais elle change tout côté conformité : l'un travaille sur de l'anonyme reciblé, l'autre sur de l'identifié que vous possédez déjà.
Et c'est là que le RGPD entre en scène. Contrairement à ce qu'on lit souvent, le règlement n'interdit pas le retargeting. Il conditionne son fonctionnement. La CNIL est limpide : les cookies essentiels (authentification, panier, sécurité) ne réclament qu'une information, alors que les cookies publicitaires exigent un consentement préalable et positif. Pas d'opt-in explicite, pas de dépôt. Votre pixel de reciblage tombe dans la seconde catégorie, sans exception.
## Ce que la CNIL exige, noir sur blanc
J'ai vu trop de bannières cookies bricolées pour ne pas insister. Les règles sont écrites, elles sont publiques, et elles ne se négocient pas.
Premier point : la symétrie. La CNIL impose que l'utilisateur puisse « accepter ou refuser le dépôt et/ou la lecture des cookies avec le même degré de simplicité ». Deux boutons, même niveau, même format, « tout accepter » et « tout refuser ». Si votre « refuser » est planqué derrière trois clics et un menu gris pâle, vous êtes hors des clous.
Deuxième point, celui qu'on oublie le plus : le refus par défaut. Toute action autre qu'une acceptation explicite, un silence, la fermeture de la bannière, un scroll, doit être considérée comme un refus. Le consentement implicite n'existe pas.
Troisième point, la durée. La CNIL recommande de conserver le choix de l'utilisateur, consentement comme refus, pendant six mois avant de le ressolliciter. Ni plus, ni moins. Ça pose au passage une vraie question opérationnelle sur la fenêtre de reciblage disponible.
Et pour ceux qui gèrent plusieurs écrans par internaute, il y a du nouveau. La délibération n°2025-131, adoptée le 18 décembre 2025 et publiée au Journal officiel le 18 janvier 2026, autorise un consentement unique pour tous les terminaux rattachés à un même compte utilisateur, à condition qu'il soit connecté. L'objectif affiché : limiter la fatigue du consentement, cette lassitude qui pousse les gens à cliquer « tout accepter » juste pour faire disparaître la fenêtre. Honnêtement, je ne sais pas encore si ça va vraiment réduire la friction ou juste déplacer le problème vers la page de login. On verra à l'usage.
## Le RTB, cette machine invisible que peu de marketeurs comprennent
Un détour technique, parce qu'on ne pilote pas ce qu'on ne comprend pas. Derrière une bonne partie du retargeting display se cache le Real-Time Bidding. La CNIL le définit comme « un type de publicité programmatique qui repose sur la mise aux enchères de chaque impression de manière indépendante ».
Le mécanisme, quand on le regarde de près, tient de la course contre la montre. Vous chargez une page avec un espace publicitaire. Cet espace part instantanément aux enchères auprès d'acheteurs potentiels, qui consultent des informations sur vous et votre profil publicitaire pour fixer leur mise. Le plus offrant remporte l'affichage. Le tout dure quelques centaines de millisecondes, le temps que la page finisse de s'afficher. Chaque impression display que vous voyez a fait l'objet d'une micro-enchère dont vous n'avez rien perçu. Quand j'explique ça en formation, il y a toujours un silence dans la salle.
## Post-cookies quand même : first-party et TCF
Alors si les cookies tiers survivent, pourquoi tout le monde bascule vers la donnée first-party ? Parce que « ils ne disparaissent pas » ne veut pas dire « rien ne bouge ». Le programme Privacy Sandbox a été officiellement enterré en octobre 2025 après six ans de développement, plusieurs API abandonnées faute d'adoption. C'est traité plus en détail dans notre article sur [le server-side tracking et la first-party data](/server-side-tracking-first-party-data-privacy-post-cookies-2026), parce que c'est là que se déplace vraiment le centre de gravité.
Google Customer Match illustre bien le virage. L'outil permet d'activer vos listes clients sur Search, l'onglet Shopping, YouTube, Gmail et Display. Mais attention aux garde-fous : les emails, prénoms, noms et téléphones doivent être hachés en SHA-256 avant l'upload, et une liste doit compter au moins 100 membres ajoutés ou mis à jour sur les 540 derniers jours pour rester éligible. Depuis début mars 2024, les listes Customer Match activées sur l'inventaire partenaire ou des places de marché tierces dans l'Espace économique européen (Royaume-Uni et Suisse inclus) ne sont plus disponibles pour le web et les applications. Seules les propriétés Google en propre restent ouvertes à la donnée first-party.
Côté cadre publicitaire, le Transparency and Consent Framework d'IAB Europe évolue aussi. La version 2.3 a été publiée le 19 juin 2025, avec une date limite d'adoption fixée au 28 février 2026. Et depuis la v2.2 de mai 2023, confirmé en v2.3, l'intérêt légitime n'est plus une base légale valable pour les finalités publicitaires : seul le consentement explicite permet désormais de cibler ou personnaliser une publicité. C'est un point que beaucoup d'annonceurs continuent d'ignorer, à leurs risques.
Un mot sur le fantasme du moment, le Digital Omnibus et son article 88a. Non, ce texte ne va pas supprimer le consentement publicitaire. Il n'est pas encore adopté, il est en cours de négociation, et sa liste de finalités dispensées de consentement vise la mesure d'audience agrégée en propre ou la sécurité. La publicité ciblée, elle, resterait soumise au consentement même si le texte passe en l'état. Ne bâtissez pas votre stratégie 2026 sur une loi qui n'existe pas.
## Doser la pression, sans tomber dans le mythe
Reste la question de la fréquence. On lit partout des règles gravées dans le marbre du genre « trois impressions par jour, dix par semaine ». Méfiance : ce sont des exemples indicatifs isolés, pas une norme du secteur. La seule référence un peu sérieuse que je connaisse reste une étude Nielsen de 2017, qui situait entre cinq et neuf expositions la zone où la résonance client augmentait de 51 %. Ancienne, encore citée, mais à prendre pour ce qu'elle est : une fourchette, pas une vérité universelle. Le bon plafonnement dépend de votre secteur, de votre objectif et de votre créa.
Meta, de son côté, allonge la laisse. À partir du 18 mai 2026, la rétention maximale des audiences personnalisées basées sur l'événement « Achat » passe de 180 jours à 730 jours, deux ans, avec migration automatique des audiences existantes sauf opt-out avant la date. Deux ans de fenêtre de reciblage sur un acheteur, ça change la maille de vos campagnes. En parallèle, le mode Advantage+ Audience laisse l'algorithme identifier les meilleurs convertisseurs à partir de l'historique et des signaux du Pixel, en supprimant les contraintes manuelles de ciblage.
Ma conviction, à froid : le retargeting de 2026 se joue moins sur la technologie que sur la propreté de votre chaîne de consentement. Une bannière conforme, une donnée first-party bien collectée, un plafonnement raisonnable. Le reste, c'est du bruit de fond. Si vous voulez creuser la mesure sans traceurs, notre guide sur [le privacy-first analytics](/privacy-first-analytics-mesurer-audience-sans-cookies) fait le tour, et pour l'articulation avec la conformité globale, [RGPD et analytics](/rgpd-analytics-conformite-guide-2026) complète le tableau.
## Sources
- [Google Privacy Sandbox : maintien des cookies tiers dans Chrome (22 avril 2025)](https://privacysandbox.google.com/blog/privacy-sandbox-next-steps)
- [CNIL : règles de conformité sur les cookies et traceurs](https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies/comment-mettre-mon-site-web-en-conformite)
- [CNIL : recommandations finales sur le consentement multi-terminaux](https://www.cnil.fr/fr/cookies-et-autres-traceurs-recommandations-finales-sur-le-consentement-multi-terminaux)
- [CNIL : définition du Real-Time Bidding (RTB)](https://www.cnil.fr/fr/definition/real-time-bidding-rtb-ou-encheres-en-temps-reel)
- [Criteo : retargeting vs remarketing, la différence](https://www.criteo.com/blog/retargeting-vs-remarketing-whats-the-difference/)
- [Google Ads Help : Customer Match, plateformes et conditions](https://support.google.com/google-ads/answer/6379332?hl=fr)
- [IAB Europe : transition vers le TCF v2.3](https://iabeurope.eu/all-you-need-to-know-about-the-transition-to-tcf-v2-3/)
- [Common Thread Co : extension de la rétention Meta à 730 jours](https://commonthreadco.com/blogs/coachs-corner/meta-purchase-audience-730-days-ecommerce)
- [Blog Droit Européen : la proposition Digital Omnibus et l'article 88a](https://blogdroiteuropeen.com/2026/03/24/la-proposition-domnibus-numerique-le-rendez-vous-manque-de-la-simplification-du-regime-des-traceurs-feryel-lehdhili/)
- [Nielsen (2017) : la fréquence publicitaire efficace](https://asknigelhollis.com/blog/what-is-an-effective-frequency-for-advertising.html)
---
## Sous-domaine ou sous-répertoire : le vrai match SEO
- URL: https://www.referencement-internet-web.com/sous-domaine-sous-repertoire-choix-seo/
- Author: Baptiste P.
- Published: 2026-07-10T06:00:00.000Z
- Categories: seo
`blog.site.com` ou `site.com/blog` ? Sur le papier, c'est un détail de config. En vrai, c'est le genre de débat qui déchire un thread Reddit SEO en trois heures, avec des gens qui balancent des captures Analytics comme si c'étaient des preuves ADN. Le sous-domaine à gauche du domaine racine, le sous-répertoire (ou sous-dossier) à droite. Deux façons de ranger le même contenu, et une guerre de tranchées qui dure depuis plus de dix ans.
Le truc c'est que la réponse « officielle » et la réponse « du terrain » ne collent pas toujours. Du coup on va démêler ça sans vous vendre de fausse certitude.
## Ce que Google dit, noir sur blanc
Commençons par les gens qui codent le moteur, ça évite les fantasmes.
Matt Cutts, en 2012, dans une vidéo Webmaster Help : les deux sont « roughly equivalent ». Sa reco à l'époque tenait en une phrase : prenez celui qui est le plus simple à configurer avec votre CMS, point. Les deux vivent sur le même domaine global, donc pour lui la vraie question était pratique, pas SEO.
Six ans plus tard, John Mueller enfonce le clou pendant des office hours de mai 2018. Je cite, parce que la nuance compte : « In general, we see these the same. I would personally try to keep things together as much as possible. » Traduction maison : Google traite les deux pareil, mais lui, perso, garderait tout regroupé sur le même site autant que possible, et réserverait le sous-domaine aux trucs vraiment à part. Il ajoute même qu'il y a des avis très tranchés là-dessus et que « this is something that could go either way ». Vers 2017, il avait déjà lâché une formule plus sèche reprise partout : Google web search se débrouille très bien avec l'un comme avec l'autre.
Donc côté doctrine, c'est clair : match nul. Sauf que.
## Pourquoi les études de cas vous mentent (un peu)
C'est là que ça se complique et que j'ai moins de certitudes. Parce que si vous tapez « subdomain vs subdirectory case study », vous allez tomber sur une avalanche de graphiques qui montrent le trafic qui explose après un passage en sous-répertoire. Alléchant. Et souvent trompeur.
Patrick Stox, chez Ahrefs, a signé en mars 2021 un article au titre volontairement provoc : « Subdirectories Are Not Better Than Subdomains For SEO ». Son argument central est imparable : ces migrations qui « prouvent » la supériorité du sous-répertoire sont presque toujours polluées par d'autres changements faits en même temps. Il liste six facteurs qui brouillent tout : un héritage temporaire de signaux, des erreurs de config analytics, des pages bloquées ou en noindex, une refonte concomitante, un [maillage interne](/maillage-interne-strategie-bonnes-pratiques-seo) retravaillé au passage, et des modifs de contenu.
Dit autrement : vous changez huit trucs, le trafic monte, et vous attribuez tout au changement d'URL. Corrélation, causalité, tout ça.
Michael Martinez (SEO-Theory) va dans le même sens : selon lui, la plupart des gains observés lors de ces migrations viennent surtout de l'optimisation du maillage réalisée au même moment, pas du changement de structure en lui-même.
Le cas que je trouve le plus honnête vient d'un roundup de cognitiveSEO. Craig Emerson raconte une migration sous-domaine vers sous-dossier avec des redirections 301 propres et, cette fois, rien d'autre de changé. Résultat : une page qui traînait hors du top 100 est remontée à la position 57 en deux semaines environ. C'est cité comme « l'exemple le plus propre » justement parce qu'aucune autre variable ne vient parasiter la mesure. Un cas isolé ne fait pas une loi, mais celui-là a le mérite de ne pas tricher.
Et pour équilibrer : cognitiveSEO a aussi migré ses propres outils d'un sous-domaine vers un sous-dossier en juin 2017. Verdict ? Rien. Positions stables autour de la 5e place, avant comme après. Aucune amélioration. La preuve vivante que « ça dépend ».
## Le contre-exemple qui calme tout le monde
Vous voulez une raison de ne PAS diaboliser le sous-domaine ? Le cas learn.g2.com.
Ce sous-domaine de G2 est passé de zéro à plus d'un million de visiteurs organiques mensuels en moins d'un an. Un sous-domaine, donc, qui cartonne. La preuve que le format n'est pas une malédiction.
Sauf que la suite pique : il a ensuite perdu 852 000 visites, soit une chute de 85 % par rapport à son pic, alignée sur le déploiement du Helpful Content Update de septembre 2023. Ce qui l'a tué, ce n'est pas le sous-domaine. C'est la nature du contenu face à une mise à jour d'algo. Plot twist : la structure d'URL n'était même pas dans l'équation.
Retenez ça, parce que c'est le vrai enseignement : le succès d'un sous-domaine dépend surtout de la qualité du contenu et des humeurs de l'algorithme, pas du choix technique en soi.
## Alors, sous-domaine quand ?
Malgré la neutralité affichée par Google, un consensus mou existe chez les experts. Stephen Kenwright (Branded3) résume l'ambiance : « Subfolders are almost always preferable over subdomains », sauf impossibilité technique. Eric Enge nuance : Google voit plutôt bien le sous-domaine comme une partie intégrée du domaine principal, mais il recommande quand même le sous-dossier par sécurité sur un nouveau projet. Gianluca Fiorelli, lui, reste sceptique : d'après lui, les liens gagnés par un blog en sous-domaine profitent surtout à ce sous-domaine, pas au reste du site. À prendre comme des avis d'experts, pas comme des lois gravées.
Concrètement, le sous-domaine garde des cas d'usage légitimes :
- **Un site international ou multilingue**, avec des régions vraiment distinctes. Google recommande d'ailleurs de gérer le ciblage avec le [hreflang](/seo-international-hreflang-multilingue) plutôt que de compter sur la structure seule.
- **Un support, un forum, un environnement technique** franchement séparé du site principal (genre un staging).
Petit piège technique à connaître : dans la Search Console, un sous-domaine est une propriété distincte de la racine. Il faut le vérifier séparément. Si vous jonglez avec plusieurs sous-domaines, ça fait autant de propriétés à gérer. Rien de dramatique, mais [dans la Search Console](/google-search-console-tutoriel-complet-debutants) ça se sent vite.
## L'angle qu'on oublie : le crawl budget
Un argument sous-estimé, et pour le coup documenté noir sur blanc par Google en décembre 2024 : le budget de crawl se gère par hostname. Chaque sous-domaine est un hôte distinct avec son propre budget.
La reco officielle : « Place resources on a different hostname, like a CDN or subdomain. This can help shift the crawl budget burden away from your main site. » En clair, un sous-domaine peut servir à déporter la charge de crawl loin de votre site principal. Sur un gros site, ce n'est pas rien. Si le sujet vous parle, j'en cause plus en détail dans le [crawl budget](/crawl-budget-comprendre-optimiser-google).
## Le mot de la fin
Bon, on en parle du verdict ? Google traite les deux pareil, c'est acté depuis 2012 et reconfirmé en 2018. La différence de perf que promettent les études de cas est presque toujours polluée par d'autres changements faits en même temps, Ahrefs l'a bien démonté.
Ma reco, à froid : sur un nouveau projet, sous-répertoire par défaut. C'est le choix qui simplifie tout, vous consolidez votre contenu au même endroit et vous vous épargnez une propriété Search Console de plus. Le sous-domaine, vous le sortez quand vous avez une vraie raison structurelle : international, environnement séparé, ou déport de crawl sur un très gros site.
Et si vous êtes déjà en sous-domaine et que tout roule ? Ne migrez pas juste parce qu'un thread Reddit vous a fait peur. Une [migration](/migration-site-seo-checklist-ne-rien-perdre) mal gérée casse plus qu'un choix d'URL « sous-optimal » ne rapporte. Le vrai levier, ça reste le contenu. Le reste, c'est de la plomberie.
## Sources
- [Search Engine Journal : John Mueller sur sous-domaines vs sous-répertoires (office hours mai 2018)](https://www.searchenginejournal.com/google-treats-subdomains-subdirectories-john-mueller-says/254687/)
- [WebProNews : Matt Cutts sur sous-domaines vs sous-répertoires (2012)](https://www.webpronews.com/matt-cutts-talks-subdomains-vs-subdirectories/)
- [Ahrefs (Patrick Stox) : Subdirectories Are Not Better Than Subdomains For SEO](https://ahrefs.com/blog/subdomain-vs-subfolder/)
- [cognitiveSEO : roundup d'études de cas et d'avis d'experts](https://cognitiveseo.com/blog/16687/subdomains-vs-subfolders/)
- [Search Engine Journal : vérification Search Console séparée pour un sous-domaine](https://www.searchenginejournal.com/subdomains-vs-subfolders-seo/239795/)
- [Search Engine Journal : déporter le crawl sur un autre hostname (guidance Google, décembre 2024)](https://www.searchenginejournal.com/google-host-resources-on-different-hostname-to-save-crawl-budget/534317/)
- [Backlinko : cas G2.com et Helpful Content Update](https://backlinko.com/subdirectory-vs-subdomain)
- [Semrush : sous-domaine vs sous-répertoire, position officielle de Google](https://www.semrush.com/blog/subdomain-vs-subdirectory/)
---
## AI Overviews France : droits voisins et opt-out éditeurs
- URL: https://www.referencement-internet-web.com/google-ai-overviews-france-droits-voisins-opt-out-2026/
- Author: Guillaume P.
- Published: 2026-07-09T06:00:00.000Z
- Categories: seo
La France a été le dernier gros marché européen sans AI Overviews. Ce n'était pas un hasard technique, c'était du droit. Le 29 juin 2026, Google a envoyé un courrier aux éditeurs de presse pour formaliser l'arrivée des AI Overviews et de l'AI Mode dans l'Hexagone, avec une échéance avant le 23 septembre 2026. Derrière cette annonce, il y a une bataille de sept ans sur les droits voisins de la presse. Et c'est ce volet juridique, pas la mécanique SEO, qui explique pourquoi la France a traîné.
Je bosse avec des éditeurs de contenu depuis longtemps, et la question qui revient en ce moment n'est plus « comment optimiser pour l'AI Overview ». C'est « est-ce que je peux dire non, et à quel prix ». Réponse honnête : c'est compliqué, et la réponse dépend de si vous êtes un média qui touche des droits voisins ou un site lambda qui n'a rien signé.
## Ce que la loi française protège vraiment
Petit rappel de cadre, parce que tout part de là. La loi n°2019-775 du 24 juillet 2019, entrée en vigueur le 24 octobre 2019, a créé les droits voisins de la presse en France. Elle transpose l'article 15 de la directive européenne 2019/790 du 17 avril 2019 sur le droit d'auteur dans le marché unique numérique. Concrètement, elle a introduit les articles L.218-1 et suivants du Code de la propriété intellectuelle.
Le principe posé par l'article L.218-2 est simple : l'autorisation de l'éditeur de presse est requise avant toute reproduction ou communication au public de ses publications sous forme numérique par un service en ligne. Traduction : Google ne peut pas reprendre votre contenu de presse sans accord et sans rémunération.
Sauf que le texte prévoit deux exceptions qui pèsent lourd. Les bénéficiaires ne peuvent pas interdire les actes d'hyperlien, ni l'usage de mots isolés ou de très courts extraits. Toute la bagarre depuis 2019 se joue dans cette zone grise : à partir de quand un « résumé IA » cesse d'être un très court extrait pour devenir une reproduction qui doit être payée ? Personne n'a de réponse tranchée, et c'est précisément le terrain sur lequel les AI Overviews avancent.
## Deux amendes, un même reproche
Google a déjà payé cher son rapport à la presse française. L'Autorité de la concurrence a infligé une première sanction de 500 millions d'euros le 12 juillet 2021 (décision n°21-D-17), pour non-respect de ses injonctions de négocier de bonne foi. À l'époque, c'était la plus lourde amende jamais prononcée par l'Autorité pour non-exécution d'une décision.
Puis une deuxième, de 250 millions d'euros, le 15 mars 2024 (décision n°24-D-03). Et celle-là est directement liée à l'IA. Le grief : Google avait lié l'utilisation de son IA, à l'époque Bard, renommé Gemini en février 2024, à l'affichage des contenus protégés, sans proposer aux éditeurs de solution technique pour s'y opposer sans casser leur visibilité ailleurs. Autrement dit, pas d'opt-out neutre. L'Autorité reprochait aussi à Google d'avoir utilisé des contenus de presse pour entraîner son IA sans que les éditeurs, ni elle-même, en soient informés.
Attention à ne pas déformer ce point, je le vois mal résumé partout : l'amende ne sanctionne pas « l'entraînement de Gemini » en soi. Elle vise l'absence de mécanisme d'opposition technique et le défaut d'information. La nuance change tout pour comprendre ce qui se joue aujourd'hui.
Un accord-cadre a fini par être renouvelé le 14 janvier 2025 entre Google et l'Alliance de la presse d'information générale (APIG), couvrant 295 publications membres. Cet accord porte sur Google Search, Discover et Actualités. Il pose un socle, mais il ne dit pas grand-chose de l'IA générative.
## Le pari des trois engagements
Pour débloquer la France, Google a mis trois choses sur la table dans son courrier du 29 juin 2026. Un, le contrôle : chaque éditeur peut choisir d'apparaître ou non dans les fonctionnalités IA. Deux, la transparence : le nombre d'impressions générées par les AI Overviews sera communiqué séparément du search classique. Trois, la rémunération : les 450 éditeurs déjà rémunérés au titre des droits voisins toucheront une indemnisation supplémentaire pour la reprise de leur contenu par le moteur IA.
C'est un vrai virage par rapport à octobre 2025. Lors du déploiement européen de l'AI Mode le 8 octobre 2025, la France avait été explicitement exclue. Le vice-président senior de Google, Nick Fox, avait publiquement reconnu l'impasse réglementaire française, en espérant la résoudre « en quelques semaines ou mois », sans calendrier. Neuf mois plus tard, on y est.
Reste que ce dispositif ne vaut que pour les éditeurs déjà dans la boucle des droits voisins. Si vous êtes une PME, un blog spécialisé, un e-commerce, vous n'êtes pas dans les 450. Vous n'avez ni rémunération, ni le levier de négociation d'un grand média. Vous êtes juste… dedans.
## L'opt-out, ce mot qu'on vous vend trop vite
C'est là que je vois passer le plus d'approximations. Non, Google-Extended ne vous sort pas des AI Overviews. Ce token robots limite l'entraînement IA et le grounding dans certains systèmes Google, mais il ne retire pas une page de l'AI Overview ni de l'AI Mode, qui puisent dans l'index de recherche classique via Googlebot. Vous pouvez bloquer Google-Extended et rester affiché dans les résumés IA. Beaucoup de gens confondent les deux, et c'est une erreur coûteuse.
La seule balise qui retire vraiment votre contenu des réponses IA, c'est `nosnippet`. Sauf qu'elle retire aussi votre snippet des résultats classiques. Vous perdez donc en SEO traditionnel pour échapper à l'IA. Marché de dupes.
Google a bien annoncé, les 2 et 3 juin 2026, un nouveau bouton dans la Search Console permettant d'exclure un site des AI Overviews, de l'AI Mode et des AI Overviews dans Discover, sans impacter le classement en recherche classique. Google affirme que ce choix « ne sera pas utilisé comme signal de ranking ». Sur le papier, c'est le graal des éditeurs. Mais ce contrôle est en test auprès d'un sous-ensemble de propriétaires de sites au Royaume-Uni seulement, depuis le 17 juin 2026. Extension mondiale annoncée, aucune date pour la France. Donc à l'heure où j'écris, ce bouton n'existe pas pour vous si vous êtes français.
Et même quand il arrivera, deux limites. La granularité par page n'est pas là : le contrôle vaut pour le site entier, la version page par page serait prévue pour mars 2027. Surtout, l'outil fournit les impressions mais pas les données de clics sur les fonctionnalités IA. Comment arbitrer une décision d'opt-out sans savoir combien de trafic l'IA vous rapporte ou vous vole ? Un éditeur m'a posé la question la semaine dernière, je n'ai pas su lui répondre autrement que par « on navigue à l'aveugle ».
## Ce que ça change pour votre trafic
La rémunération des grands médias ne réglera pas votre problème de trafic. Les résumés IA captent le clic. Une étude Seer Interactive, relayée en France, a mesuré sur plus de 25 millions d'impressions une baisse de 61 % du taux de clic organique quand un résumé IA apparaît. À prendre avec prudence, c'est une étude tierce sur données américaines, mais l'ordre de grandeur donne le vertige. Côté Discover, le trafic référent aurait chuté de 21 % sur un an selon le Reuters Institute. Je détaille ailleurs cette [érosion du CTR organique et les KPI à recalibrer](/ctr-organique-chute-61-pourcent-recalibrer-kpi-seo-2026), parce que le vrai sujet n'est pas juridique pour vous, il est comptable.
Un dernier signal qui date de 2024 mérite d'être rappelé, parce qu'il montre le rapport de force. Le 13 novembre 2024, Google avait lancé un test A/B retirant les contenus de presse des résultats pour 1 % des utilisateurs dans neuf pays européens, officiellement pour « estimer la valeur » de ces contenus. Le Tribunal de commerce de Paris a bloqué le test en France dès le 13-14 novembre, sous astreinte pouvant atteindre 900 000 euros. Le SEPM avait dénoncé une violation des engagements pris devant l'Autorité. Ce genre d'épisode explique pourquoi les éditeurs français négocient dur : ils savent que Google teste en permanence les limites.
Mon conseil, à froid. Si vous êtes un média avec droits voisins, poussez pour la transparence des impressions et surveillez la rémunération IA, c'est votre levier. Si vous n'êtes personne dans ce jeu, ne comptez pas sur l'opt-out miracle qui n'existe pas encore chez nous. Travaillez plutôt votre [visibilité IA dans la Search Console](/gsc-rapports-impressions-ai-overviews-ai-mode-2026) et vos [canaux de distribution alternatifs à Google](/editeurs-abandonnent-google-bluesky-linkedin-basculement-2026). Le droit protège la presse. Il ne vous protège pas, vous.
## Sources
- [Legifrance : article L.218-2 du Code de la propriété intellectuelle](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000038826732)
- [Legifrance : chapitre VIII CPI, droits des éditeurs et agences de presse](https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006069414/LEGISCTA000038826677/)
- [Autorité de la concurrence : sanction de 500 millions d'euros (décision 21-D-17)](https://www.autoritedelaconcurrence.fr/en/article/remuneration-related-rights-press-publishers-and-agencies-autorite-fines-google-500-million)
- [Autorité de la concurrence : sanction de 250 millions d'euros (décision 24-D-03)](https://www.autoritedelaconcurrence.fr/en/press-release/related-rights-autorite-fines-google-eu250-million-non-compliance-some-its)
- [Abondance : arrivée des AI Overviews en France et engagements de Google](https://www.abondance.com/20260630-2528492-google-ai-overviews-arrivee-france-ete.html)
- [Alliance de la presse : accord Google-APIG renouvelé le 14 janvier 2025](https://www.alliancepresse.fr/actualite/google-et-lalliance-de-la-presse-francaise-renouvellent-leur-accord-sur-les-droits-voisins/)
- [Google Search Central : fonctionnalités IA, nosnippet et Google-Extended](https://developers.google.com/search/docs/appearance/ai-features)
- [9to5Google : nouvel opt-out AI Overviews en test au Royaume-Uni](https://9to5google.com/2026/06/02/google-ai-mode-overviews-opt-out/)
- [Search Engine Journal : l'opt-out sans les données pour l'exploiter](https://www.searchenginejournal.com/google-gives-sites-ai-search-opt-out-but-not-the-data-to-use-it/577978/)
- [Next.ink : la justice bloque le test de suppression des contenus de presse](https://next.ink/157770/droits-voisins-la-justice-bloque-le-test-de-google-excluant-des-editeurs-de-presse-europeens/)
---
## Information agents Google : faut-il publier plus frais ?
- URL: https://www.referencement-internet-web.com/google-information-agents-seo-fraicheur-2026/
- Author: Baptiste P.
- Published: 2026-07-08T06:00:00
- Categories: seo
Google I/O 2026, quelqu'un lance le terme « information agents » sur scène, et la moitié du secteur SEO part en vrille. Il faudrait republier tous les jours ? Transformer sa cadence en flux tendu façon build order StarCraft ? On ne va pas se mentir : la panique a été plus rapide que la lecture de l'annonce. Alors on prend une minute. Les information agents, c'est une vraie fonctionnalité officielle de Google, pas un fantasme de consultant. Mais ce que ça change pour ta stratégie de fraîcheur, c'est beaucoup plus terre à terre que le buzz ne le laisse croire.
Réponse courte, pour ceux qui sont pressés : ta cadence n'a pas besoin de devenir hystérique. La réponse longue, elle, mérite qu'on démêle d'abord un sacré nœud de câbles.
## Trois trucs que tout le monde mélange
Le vrai problème, avant même de parler fraîcheur, c'est que trois notions différentes se font écraser dans le même sac. Et tant qu'on ne les sépare pas, on raconte n'importe quoi.
Numéro un : les **information agents**. Terme officiel de Google, annoncé à I/O 2026 (blog.google, le 19 mai 2026). L'idée : un agent qui scanne en continu, 24 heures sur 24, blogs, actus et réseaux sociaux, plus des données temps réel côté finance, shopping et sport, puis t'envoie une synthèse. C'est un service de veille automatisé, pas un nouvel algo de classement. Côté déploiement, Search Engine Land annonçait l'été 2026 pour les abonnés AI Pro et Ultra aux États-Unis. Dans les faits, au 12 juin 2026, Search Engine Journal constatait un déploiement limité aux seuls abonnés Ultra, sans date confirmée pour les Pro. Bref, un truc encore très niche.
Numéro deux : les **AI Overviews** et l'**AI Mode**. La synthèse générée en haut de tes résultats. Et là, le point à retenir pour la suite : Google est clair, ces réponses puisent dans l'index Search existant. Pas de crawl parallèle magique.
Numéro trois : les **crawlers IA génériques**. GPTBot, ClaudeBot, PerplexityBot, Google-Extended et compagnie. Search Engine Land les range en trois familles : l'entraînement (GPTBot, ClaudeBot, Google-Extended, CCBot), l'indexation pour recherche (OAI-SearchBot, PerplexityBot) et le déclenché-utilisateur (ChatGPT-User, Google-Agent). Trois familles, trois comportements, aucun rapport direct avec l'annonce de I/O.
Petite précision pour éviter de dire une bêtise : on serait tenté de croire que les information agents s'appuient sur le fetcher Google-Agent, ce déclencheur qui ignore le `robots.txt` et sert aux agents type Project Mariner. Google n'a rien confirmé de tel. Donc on reste sur deux briques documentées séparément, sans tirer de fil entre les deux. C'est un peu comme deviner le lore d'un jeu à partir de deux artworks sans texte : tentant, mais tu inventes.
## La vraie question : faut-il vraiment publier plus frais ?
Voilà le cœur du sujet. Est-ce que ce scan continu doit te pousser à balancer du contenu toutes les douze heures ?
Commençons par le seul chiffre solide qui va dans le sens des paranos. Ahrefs a passé au crible 17 millions de citations IA : le contenu cité par les moteurs génératifs est en moyenne 25,7 % plus frais que le top 10 organique classique. Traduction : quand une IA choisit une source, elle penche statistiquement vers du récent. Le signal existe, il est mesuré, on ne va pas faire semblant.
Sauf que « plus frais » ne veut pas dire « publié ce matin ». Et c'est là que le discours officiel de Google refroidit les ardeurs. Sa doc sur les fonctionnalités IA est explicite : les AI Overviews et l'AI Mode reposent sur l'index Search, avec « no additional requirements… nor special optimizations necessary ». Aucune exigence de fraîcheur spéciale, aucune optimisation dédiée réclamée. Autrement dit, le bon vieux SEO reste le socle.
Et cette histoire de fraîcheur, Google la gère depuis des lustres avec le système QDF, « Query Deserves Freshness ». Certaines requêtes appellent du récent (une actu, un résultat sportif), d'autres non (une définition, un tuto intemporel). Le QDF existe bien avant les information agents et n'a rien à voir avec eux. Si le rôle des dates comme signal te trotte dans la tête, j'en avais parlé en détail dans [cet article sur la fraîcheur du contenu](/dates-publication-fraicheur-contenu-signal-google-2026).
Alors oui, on trouve des études plus alarmistes. AirOps avance qu'un contenu non mis à jour au moins tous les trois mois aurait trois fois plus de risque de perdre sa citation en IA. Le chiffre est marquant, mais sa méthodo n'est pas publiée, donc je le cite pour ce qu'il est : une estimation d'AirOps, à prendre avec des pincettes, pas une loi gravée par Google.
Honnêtement, sur le rythme exact à tenir, je n'ai pas de certitude chiffrée à te vendre, et personne n'en a : aucune doc officielle ne publie d'intervalle de crawl précis pour qui que ce soit. Ce qu'on sait, c'est la direction, pas la cadence magique.
## Le piège de la fausse fraîcheur
Là, par contre, j'ai une conviction nette. La pire réaction à toute cette histoire, c'est de tricher sur les dates.
Tu vois le réflexe : changer le champ « date de publication », remettre le compteur à zéro, et hop, contenu « rafraîchi ». Sauf que Google documente noir sur blanc que cette fausse fraîcheur, une date modifiée sans que le contenu bouge vraiment, est pénalisée. Tu ne gagnes rien, tu prends un risque. Le level design est fait pour repérer les tricheurs.
La vraie mise à jour, c'est du fond : de nouveaux chiffres, un angle actualisé, une section réécrite parce que le sujet a bougé. Ça, ça se voit et ça compte. Le reste, c'est du maquillage que le boss de fin détecte en deux secondes.
## Et les crawlers, dans tout ça ?
Puisqu'on parle de bots qui te lisent, un mot sur le trafic réel, parce que le fantasme dépasse souvent la mesure. Le Cloudflare Radar, sur un an (mai 2024 à mai 2025), donne Googlebot à 50 % du trafic de crawl, en hausse de 96 % sur l'année. GPTBot suit à 7,7 % du crawl total, mais avec une croissance de 305 %. ClaudeBot, lui, recule à 5,4 %, en baisse de 46 %.
Attention au piège de chiffres qui traînent : quand un article te balance « GPTBot capture 30 % du trafic », ce n'est pas la même base. 30 %, c'est sa part parmi les seuls crawlers IA. 7,7 %, c'est sa part du crawl total, source Cloudflare. Deux dénominateurs, deux histoires. Ne mélange pas.
Et Google-Extended dans le lot ? C'est un simple token à poser dans ton `robots.txt` pour cadrer l'entraînement et le grounding de Gemini. Zéro impact sur ton ranking Search, Google le dit clairement. Le laisser ouvert ou le bloquer, c'est un choix éditorial sur l'usage de ton contenu par l'IA, pas un levier de position. Si la gestion fine de ces bots t'intéresse, les arbitrages sont détaillés dans [ce guide sur le crawl IA et le robots.txt](/crawl-ia-bots-gptbot-claudebot-robots-txt-editeurs-2026). Et pour l'optimisation côté synthèses, [notre guide AI Overviews](/guide-google-ai-overviews-15-mai-2026-best-practices) reste le point de départ.
## Alors, on fait quoi ?
Le truc c'est que la question de départ était mal posée. Ce n'est pas « publier plus », c'est « publier juste ». Un sujet chaud, sensible à la fraîcheur au sens QDF ? Là, oui, la vitesse paie. Un contenu evergreen ? Une bonne mise à jour de fond deux fois par an bat dix republications cosmétiques.
Ma reco, tranchée : ignore la panique I/O, garde ta cadence saine, et investis l'énergie dans des mises à jour réelles plutôt que dans un flux tendu que personne ne t'a demandé. Les information agents sont un service de veille pour utilisateurs Ultra, pas un pistolet sur ta tempe éditoriale. Le jour où Google publiera un intervalle de crawl chiffré et une exigence de fraîcheur officielle, on en reparlera. En attendant, on ne code pas contre une spec qui n'existe pas.
## Sources
- [Google I/O 2026 Search announcements (blog.google)](https://blog.google/products-and-platforms/products/search/search-io-2026/)
- [Google Search gains information agents (Search Engine Land)](https://searchengineland.com/google-search-gains-information-agents-and-improved-agentic-experiences-477979)
- [Information agents rolled out to Ultra subscribers (Search Engine Journal)](https://www.searchenginejournal.com/google-rolls-out-ai-mode-information-agents-to-ultra-subscribers/579085/)
- [Google Search AI features documentation](https://developers.google.com/search/docs/appearance/ai-features)
- [Google common crawlers (developers.google.com)](https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers)
- [Ahrefs : fresh content and AI citations](https://ahrefs.com/blog/fresh-content/)
---
## Articles LinkedIn : le hack SEO et citations IA en 2026
- URL: https://www.referencement-internet-web.com/linkedin-articles-seo-google-citations-llm-b2b-2026/
- Author: Baptiste P.
- Published: 2026-07-07T06:00:00
- Categories: content-marketing
Plot twist : le meilleur coup SEO de 2026 se joue peut-être sur une plateforme que vous n'hébergez même pas. On parle des articles LinkedIn natifs, ceux que vous publiez direct dans le fil ou en newsletter, et de leur capacité à se faire citer par les moteurs IA. Spoiler alert : les chiffres sont bien plus sérieux que le buzz LinkedIn habituel. C'est un peu comme découvrir que le PNJ que tout le monde snobe dans le RPG file en fait le meilleur loot du jeu.
Sauf qu'entre le potentiel réel et les conseils d'agence qui circulent, il y a un fossé. On va trier. D'un côté ce que les études mesurent vraiment, de l'autre le mythe qu'on vous vend et qui vous fait perdre du temps. Je tranche à la fin.
## LinkedIn, deuxième source citée par les IA : non, c'est pas une blague
Commençons par le fait qui devrait vous faire lever un sourcil. Semrush a analysé 325 000 prompts uniques sur douze secteurs, et le verdict est net : LinkedIn apparaît dans 11 % des réponses IA en moyenne. Dans le détail par plateforme, ça monte à 14,3 % sur ChatGPT Search, 13,5 % sur Google AI Mode, et redescend à 5,3 % sur Perplexity. Au total, près de 89 000 URLs LinkedIn distinctes citées. Résultat : deuxième domaine le plus cité, juste derrière Reddit, devant Wikipedia, YouTube et tous les grands médias. Oui, devant les mastodontes de la presse.
Profound raconte la même histoire sous un autre angle. Sur 1,4 million de citations passées au crible entre mi-novembre 2025 et mi-février 2026, LinkedIn est passé de la 11e à la 5e place des domaines cités par ChatGPT. Et surtout, numéro un pour les requêtes professionnelles, et ce sur les six modèles testés. Si vous bossez en B2B, ce chiffre-là vaut de l'or.
Une troisième étude, signée Peec AI et relayée par Search Engine Land, boucle le tableau. Sur 30 millions de sources analysées à travers cinq moteurs (ChatGPT, Google AI Mode, Gemini, Perplexity, AI Overviews), le podium des domaines les plus cités donne Reddit, YouTube, puis LinkedIn. Trois études indépendantes, trois méthodos différentes, même conclusion. Quand ça converge autant, on arrête de crier au hasard.
Le truc à comprendre, c'est pourquoi. Un LLM cherche des sources où des pros s'expriment sous leur vrai nom, avec un minimum de crédibilité pro attachée. Or LinkedIn, c'est exactement ça : 1,3 milliard de membres, dont plus de 37 millions rien qu'en France début 2026. Un gisement de contenu identifié, structuré, et rapidement indexé par Google. Si le sujet des citations IA est nouveau pour vous, mon [guide GEO](/geo-generative-engine-optimization-guide) pose les bases avant qu'on aille plus loin.
Petite nuance honnête quand même, parce que je déteste qu'on me survende un truc. Chez Profound, le détail par format montre que les articles long-form ne pèsent qu'entre 6 et 8,9 % des citations LinkedIn. L'essentiel, ce sont les posts du fil (autour de 26 %). Les articles progressent, mais ne rêvez pas : publier un pavé long-form ne vous garantit pas la citation. C'est un canal parmi d'autres sur la plateforme, pas un bouton magique.
## Le mythe des 60 réactions obligatoires
Maintenant le passage où je vais froisser quelques consultants. Vous avez forcément croisé ce conseil : pour espérer une visibilité IA, il vous faudrait du contenu qui cartonne, genre 60 réactions et plus de dix commentaires de qualité. Le seuil viral obligatoire. Le truc c'est que ce chiffre sort d'agences, pas de mesures.
Et quand on regarde les données réelles, il s'effondre. Semrush a mesuré l'engagement médian du contenu LinkedIn effectivement cité par les IA : entre 15 et 25 réactions, et un commentaire, pas plus. On est très loin du seuil viral qu'on vous agite sous le nez. Autrement dit, l'IA se fiche de savoir si votre post a fait un carton mondain. Elle veut de l'info pertinente, bien écrite, attribuée à quelqu'un.
Ce que Semrush observe en revanche, c'est un profil de publication régulier. 95 % du contenu cité est original (5 % de reshares seulement), les articles qui marchent tiennent entre 500 et 2 000 mots, les posts entre 50 et 299 mots, et 75 % des auteurs cités publient au moins cinq fois par mois. Traduction : la constance bat le buzz. C'est chiant à entendre parce que c'est moins glamour qu'un hack, mais c'est ça le vrai levier.
Honnêtement, sur ce point précis, je comprends d'où vient la confusion. Un post viral et un post cité par l'IA, ça ressemble au même objectif vu de loin, alors qu'en vrai les deux mécaniques n'ont presque rien à voir. Courir après les réactions pour plaire à un LLM, c'est optimiser la mauvaise variable. Un peu comme grind le farming d'un boss alors que la quête se débloque ailleurs. Cette logique du signal de crédibilité plutôt que de la popularité, je la creusais déjà dans [mentions de marque vs backlinks](/mentions-vs-backlinks-citations-experts-valent-plus-2026), et elle se vérifie ici aussi.
LinkedIn en rajoute une couche marketing, à prendre avec des pincettes : la plateforme affirme, sans publier sa méthodologie ni son échantillon, une baisse de 60 % des visites non-marque sur un sous-ensemble de sujets B2B lié à sa propre recherche IA. Donnée auto-déclarée, donc je ne la traite pas comme une preuve. Mais elle raconte au moins une chose : LinkedIn a bien conscience d'être devenu un carrefour de la recherche générative.
## Côté Google pur, faut calmer le jeu
Parce qu'il y a un piège, et il est de taille. Tous les liens sortants de LinkedIn, articles natifs compris, sont en nofollow. Selon plusieurs analyses SEO concordantes, la plateforme a basculé l'ensemble de ses liens en nofollow dès le 6 juin 2014. Concrètement : le lien que vous glissez vers votre site depuis un article LinkedIn ne vous transmet aucun jus SEO au sens classique. Zéro backlink dofollow. Si votre plan c'était de farmer des liens vers votre domaine, oubliez.
Ce qui ne veut pas dire que le SEO on-page LinkedIn ne sert à rien. Les articles natifs vous laissent personnaliser le titre SEO (60 caractères pour bosser) et la description SEO (160 caractères, dont 140 à 160 recommandés pour remplir l'espace). C'est exactement le même jeu que sur n'importe quel CMS : un titre qui donne envie de cliquer, une description qui vend le clic. Ces contenus sont rapidement indexés par Google, donc autant soigner ces deux champs.
Et tant qu'on parle de hacks côté Google, laissez-moi enterrer une légende au passage. Le fameux fichier llms.txt que la moitié de LinkedIn brandit comme la solution GEO ultime ? Google déclare officiellement l'ignorer. Sa doc le dit noir sur blanc : mettre en place un llms.txt ne nuit ni n'aide à votre visibilité ou classement, Google Search l'ignore purement. Donc pendant que certains peaufinent un fichier que le moteur jette à la poubelle, publier régulièrement sur LinkedIn se fait, lui, citer pour de vrai. Le contraste résume assez bien l'année.
Le vrai enjeu derrière tout ça, c'est que le trafic IA explose : la croissance globale du referral depuis les moteurs IA a bondi de 357 % sur 2025 par rapport à 2024, avec ChatGPT en hausse de 52 % et Gemini de 388 % sur un an. Être cité dans ces réponses, même sans lien dofollow, c'est capter une audience qui, avant, serait passée par une recherche classique. Le lien nofollow ne fait pas de SEO, mais la citation fait de la visibilité. Nuance qui change tout.
## Ce que je ferais si je repartais de zéro
Alors on fait quoi de tout ça, concrètement ? Pas un plan en dix étapes, promis, juste la logique que je suivrais. Publier des articles LinkedIn qui ont une vraie valeur d'expert, sur les sujets où vous voulez être perçu comme une référence, en visant la régularité plutôt que le coup d'éclat viral. Cinq publications par mois, c'est le rythme des auteurs cités, pas un chiffre sorti d'un chapeau.
Et surtout, ne jamais oublier que vous bâtissez sur du terrain loué. LinkedIn, c'est un formidable amplificateur de citations IA, mais le jour où l'algo change d'humeur, vous n'avez aucun recours. C'est tout l'intérêt de coupler cette présence à une [audience propriétaire](/audience-proprietaire-newsletter-membership-declin-trafic-google) que vous contrôlez, et de traiter LinkedIn comme un canal de distribution, pas comme votre maison. Cette bascule d'un contenu d'expert vers de la conversion, sans se faire enfermer par la plateforme, est détaillée dans notre papier sur le [thought leadership B2B](/thought-leadership-b2b-contenu-expert-conversion-seo-2026).
## Bilan de la partie
TL ;DR pour les pressés : oui, les articles LinkedIn sont un canal sérieux pour se faire citer par les IA en B2B, non ce n'est pas le hack SEO Google qu'on vous vend. Trois études indépendantes placent LinkedIn au sommet des sources citées, l'engagement viral est un mythe (15 à 25 réactions suffisent), et le nofollow tue toute idée de jus SEO direct.
Ce que je retiens, moi ? Le vrai levier n'a rien de sexy : publiez souvent, publiez utile, sous votre nom. L'IA récompense la crédibilité et la régularité, pas le buzz. Et si vous cherchez pourquoi vos citations LLM ne se recoupent presque jamais d'une plateforme à l'autre, allez voir [les 11 % de citations communes entre ChatGPT et Perplexity](/chatgpt-perplexity-11-pourcent-citations-strategie-distincte). Ça calme les ardeurs, et ça remet l'église au milieu du village.
## Sources
- [Semrush : étude sur la visibilité IA de LinkedIn](https://www.semrush.com/blog/linkedin-ai-visibility-study/)
- [Profound : LinkedIn, domaine le plus cité pour les requêtes professionnelles](https://www.tryprofound.com/blog/linkedin-is-the-most-cited-domain-for-professional-queries-in-ai-search)
- [Search Engine Land : Reddit, YouTube et LinkedIn en tête des citations IA (étude Peec AI)](https://searchengineland.com/ai-search-engines-cite-reddit-youtube-and-linkedin-most-study-473138)
- [Google Search Central : guide d'optimisation pour la recherche IA (llms.txt ignoré)](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)
- [Search Engine Land : LinkedIn et la baisse du trafic non-marque](https://searchengineland.com/linkedin-ai-powered-search-cut-traffic-468187)
- [Blog du Modérateur : chiffres LinkedIn 2026](https://www.blogdumoderateur.com/chiffres-linkedin/)
---
## Google Ads Performance Max 2026 : reprendre le contrôle
- URL: https://www.referencement-internet-web.com/performance-max-2026-steering-exclusions-audiences/
- Author: Guillaume P.
- Published: 2026-07-06T06:00:00.000Z
- Categories: marketing-digital
Performance Max, c'est la boîte que Google vous vend fermée. Vous versez le budget, l'algo répartit, vous regardez les canaux défiler sans jamais mettre la main dessus. Depuis des mois, les agences promettent de « reprendre le contrôle » en 2026. Soyons honnêtes : une bonne partie de ce discours est du marketing. Il n'existe aucun interrupteur pour couper Display, YouTube ou Gmail dans une campagne PMax standard. Le contrôle existe, mais il reste indirect. Voilà le vrai sujet.
Alors autant partir de la vérité qui dérange avant de parler solutions.
## Arrêtons de tourner autour du pot : le bouton n'existe pas
Aucun levier ne vous laisse plafonner ou désactiver un canal entier dans PMax. C'est documenté côté Google, et c'est le point central : le pilotage reste indirect, jamais un curseur par réseau. Retenez ça, le reste en découle.
Google communique pourtant beaucoup sur la transparence. Il y a bien un rapport de performance par canal, avec répartition et diagnostics, arrivé le 30 avril 2025 (bêta le 21 mai). Utile pour comprendre où part l'argent. Mais un diagnostic n'est pas une manette. Voir que la moitié du budget file sur YouTube ne vous donne pas le bouton pour le couper. La réalité du terrain : vous observez, vous n'agissez pas directement.
Prenez les mots-clés négatifs. Vous pouvez en pousser jusqu'à 10 000 par campagne, contre 100 il y a encore un an. Belle progression. Sauf qu'ils ne s'appliquent qu'à Search et Shopping. Rien sur Display, YouTube ou Gmail. Autrement dit, là où le budget dérape le plus souvent, sur le réseau visuel, vous restez aveugle et sans frein. Même logique pour les exclusions de marque : Search, Shopping et YouTube search, point.
C'est exactement ce que reprochent les annonceurs. Digiday relayait en juillet 2025 les critiques de plusieurs agences comme Tinuiti ou Jellyfish : de la visibilité, oui, mais peu de leviers d'action réels. Et pendant ce temps, un vieux chiffre circule partout dans les argumentaires : « 18 % de conversions en plus à CPA équivalent ». Il date de février 2023. On vous le ressort comme s'il datait d'hier. Le problème, c'est qu'on nous vend du rêve avec des données périmées.
Il y a même une étude (Adalysis, portée par des agrégateurs, à prendre avec des pincettes car je ne l'ai pas vérifiée à la source) qui suggère que Search bat PMax sur les mêmes requêtes, le score de PMax étant gonflé par le trafic de marque. Spéculatif, mais ça colle au ressenti terrain.
## Les trois leviers qui marchent vraiment en 2026
Bon. Assez tapé, passons au concret. Trois réglages tiennent la route cette année pour rendre PMax moins bête.
**Un, les exclusions de placements au niveau du compte.** C'est le plus tangible. Une liste unique s'applique d'un coup à PMax, Demand Gen, Display, Video, App et aux partenaires de recherche. Sa visibilité a été élargie le 14 janvier 2026. En pratique, vous montez jusqu'à 20 000 placements par soumission, avec un plafond de 65 000 par compte, et l'effet arrive sous douze heures. En agence via un MCC, comptez trois listes de 250 000. C'est le seul endroit où vous reprenez vraiment la main sur le réseau visuel. Un client e-commerce m'a appelé le mois dernier, la moitié de son budget partait sur des chaînes YouTube douteuses. On a nettoyé au niveau du compte. Le lendemain, c'était réglé.
**Deux, les mots-clés négatifs au niveau campagne.** Le plafond est passé de 100 en janvier 2025 à 10 000 depuis avril 2025. Utile pour couper le gaspillage sur la recherche et le Shopping, surtout si vous vendez du catalogue via [Merchant Center](/google-merchant-center-seo-convergence-ecommerce-2026). Je rappelle quand même la limite : ça n'agit pas au-delà de Search et Shopping. Ne le vendez pas comme un filet complet.
**Trois, les exclusions d'audiences first-party.** D'après une source secondaire (Dataslayer), depuis fin mars ou début avril 2026, une audience Customer Match ou vos visiteurs de site pourraient désormais être exclus totalement, alors qu'avant ça ne servait que de signal. Si c'est confirmé, ça change la donne pour arrêter de repayer des clients déjà convertis. Sur ce levier-là, je reste prudent : une seule source le documente, je ne l'ai pas encore validé en compte. À tester avant d'en faire une promesse client.
## Le « channel steering », ce mot qui ment
Un mot sur le terme à la mode. On vous parle de « channel steering » comme si c'était une fonctionnalité avec son onglet dédié. Ce n'est pas le cas. C'est un fourre-tout qui recouvre plusieurs réglages indirects.
Google range là-dedans les règles de valeur de conversion, les signaux d'audience, les search themes, les négatifs, les exclusions de marque, et les règles « URL contains ». Cette dernière permet d'écarter des catégories de pages de votre flux produit selon un motif d'URL, pratique pour un [catalogue e-commerce bien découpé](/referencement-ecommerce-2026-fiches-produit-rich-results). Empilez ces réglages et vous orientez la machine. Mais ne cherchez pas l'interrupteur central : il n'existe pas.
## Verdict
En clair : PMax en 2026 reste une boîte à moitié fermée, et personne ne va vous donner la clé complète. Ce que je ferais, concrètement, à votre place : monter d'abord une liste d'exclusions de placements propre au niveau du compte, c'est le seul levier qui mord vraiment sur le réseau visuel. Ensuite charger les négatifs sur Search et Shopping. Et tester les exclusions first-party dès qu'elles sont confirmées, sans en faire une religion.
Le reste, c'est de la surveillance et de la patience. PMax n'est pas votre pilote automatique, c'est un canal parmi d'autres, à traiter comme [un complément du référencement organique](/google-ads-seo-complement-strategie-2026), pas comme un substitut. Celui qui vous promet un curseur par canal ne connaît pas l'outil.
## Sources
- [Google Ads : exclusions de placements au niveau du compte](https://support.google.com/google-ads/answer/7331110)
- [Google Ads : mots-clés négatifs dans Performance Max](https://support.google.com/google-ads/answer/15726455)
- [Google Ads : exclusions de marque](https://support.google.com/google-ads/answer/14505308)
- [Google Ads : absence de contrôle direct par canal dans PMax](https://support.google.com/google-ads/answer/16683501)
- [Google : le rapport de performance par canal arrive sur Performance Max](https://blog.google/products/ads-commerce/channel-performance-reporting-coming-to-performance-max/)
- [Digiday : Google entrouvre sa boîte noire, les marketeurs restent sceptiques](https://digiday.com/marketing/google-is-slowly-opening-its-black-box-but-marketers-arent-so-convinced/)
---
## Substack SEO 2026 : faire ranker sa newsletter sur Google
- URL: https://www.referencement-internet-web.com/substack-seo-newsletter-google-ranking-2026/
- Author: Baptiste P.
- Published: 2026-07-03T06:00:00.000Z
- Categories: content-marketing
Vous avez lancé votre newsletter sur Substack, elle tourne bien dans les boîtes mail, et là vous vous demandez pourquoi Google fait semblant de ne pas la voir. Question légitime. Publier sur Substack, c'est un peu comme monter sa base sur une map Minecraft en mode aventure : le terrain est déjà posé, vous décorez, mais le level design ne vous appartient pas. La vraie question du coup : jusqu'où peut-on pousser le SEO d'une newsletter qu'on n'héberge même pas soi-même ?
Réponse courte : plus loin qu'on ne le croit, mais jamais aussi loin qu'on voudrait. On déballe le truc.
## Bonne nouvelle : Substack est déjà branché pour Google
Commençons par ce qui marche, parce qu'il y en a. Contrairement à la légende urbaine, une page Substack n'est pas un trou noir pour le crawl. Son `robots.txt` bloque totalement un aspirateur comme BLEXBot, et met des barrières sur tout un tas de chemins internes (les pages `/action/`, `/subscribe`, `/sign-in`, les commentaires, les embeds). Mais vos articles publiés, eux, ne sont pas dans la liste noire. Google peut les lire. Deux sitemaps sont même déclarés dans ce fichier. Si la logique des `robots.txt` et sitemap vous échappe encore, mon [guide technique sur le sujet](/robots-txt-sitemap-xml-guide-technique-seo) pose les bases.
Deuxième truc que beaucoup répètent et qui est faux : « Substack n'a pas de H1 ». Alors non. Le titre de votre article, le fameux headline, est codé en H1 automatiquement côté backend. D'après ce que rapportent les analyses de la plateforme, vous ne pouvez juste pas en ajouter un deuxième à la main. Ce qui, honnêtement, vous évite surtout de faire n'importe quoi. Le H1 est géré pour vous, point.
Et Substack pense aussi aux balises meta. Votre SEO title est pré-rempli avec le headline, et reste modifiable. La SEO description, elle, récupère votre sous-titre si vous laissez le champ vide. Petit rappel qui fâche : la meta description n'est pas un facteur de ranking, ça c'est confirmé. Elle sert à donner envie de cliquer, pas à grimper. Du coup, misez tout sur un SEO title qui claque. Une donnée généraliste reprise par Backlinko situe le sweet spot des titres autour de 40 à 60 caractères, avec un gain de CTR non négligeable dans cette fourchette. À caler dans le champ dédié.
Pour vérifier que tout ça remonte, branchez Google Search Console. Sur Substack, la manip passe par Google Tag Manager : vous créez un conteneur GTM, vous collez son ID dans les réglages de publication, et vous ajoutez la propriété côté GSC. Si vous n'avez jamais touché à GTM, c'est le moment d'ouvrir mon [guide d'installation](/google-tag-manager-guide-installation-utilisation), parce que c'est là que ça peut coincer pour un débutant.
Est-ce que ça paie vraiment ? Un témoignage que j'ai croisé (à prendre pour ce que c'est, un retour individuel) parle d'environ 800 clics organiques par mois avec une cinquantaine d'articles, et plus de mille lecteurs venus de Google sur trois mois. Pas de quoi révolutionner votre business, mais la preuve que le canal existe.
## Là où le level design vous bloque
Maintenant les mauvaises nouvelles, parce qu'il y en a aussi. Et la première est un vrai piège pour quiconque démarre en 2026.
Avant, toute nouvelle publication Substack recevait son `sitemap.xml` dès la création, au format `https://votrenom.substack.com/sitemap.xml`. Pratique. Sauf que depuis 2025, d'après un témoignage de première main daté de septembre, ce n'est plus automatique. Substack exige désormais des « quality standards » qu'il ne divulgue pas avant de générer le sitemap d'une pub récente. C'est là que ça se complique et que je préfère être franc : personne ne connaît le seuil exact, ni en abonnés ni en trafic. Donc si votre newsletter est neuve et que vous cherchez votre sitemap en vain, vous n'êtes pas fou, c'est juste le nouveau régime. Les publications déjà installées, elles, gardent le leur.
Autre limite selon le sujet de votre newsletter : le contenu payant. Substack propose bien un réglage pour autoriser les moteurs à indexer le contenu derrière paywall. À activer ou pas selon votre stratégie, mais sachez qu'il existe. Et niveau données structurées ou schema, difficile de savoir précisément ce que la plateforme injecte : je n'ai pas trouvé d'info fiable là-dessus, donc je m'abstiens de vous vendre du vent.
Le fond du problème, c'est que vous jouez sur un sous-domaine `votrenom.substack.com`. Toute l'autorité que vous construisez, vous la construisez sur la maison de quelqu'un d'autre. Et ça, aucun réglage ne le corrige.
## Domaine perso ou migration : le choix qui change tout
D'où l'option qui sépare les amateurs des gens sérieux : le domaine personnalisé. Substack facture un forfait unique d'environ 50 dollars par publication pour le brancher, et l'ajout comme la suppression sont gratuits ensuite. Comptez jusqu'à 36 heures de propagation, d'après les retours, avant que tout soit stable.
Pourquoi c'est un vrai game-changer, celui-là sans ironie ? Parce qu'une étude Ahrefs sur plus de deux cent mille domaines rappelle un truc : l'autorité de domaine n'est pas un facteur officiel de Google, mais elle corrèle salement avec le ranking. En passant sur votre propre nom de domaine, vous arrêtez d'engraisser le sous-domaine de Substack et vous capitalisez pour vous. C'est aussi le prérequis d'une stratégie d'[audience propriétaire](/audience-proprietaire-newsletter-membership-declin-trafic-google), le seul rempart quand le trafic Google se raréfie.
Le bonus, il est énorme si vous envisagez de partir un jour. Avec un domaine perso, le contenu déjà indexé reste sous votre domaine même quand vous migrez vers Ghost ou WordPress. Traduction : vous ne repartez pas de zéro côté SEO. Sans domaine perso, migrer, c'est jeter tout votre historique d'indexation à la benne. Si l'idée vous trotte, ma [checklist de migration sans rien perdre](/migration-site-seo-checklist-ne-rien-perdre) vous évitera les classiques.
Petite mise en perspective pour rester humble : `substack.com` pèse dans les 122 millions de visites en mai 2026 selon Semrush. Votre newsletter là-dedans, c'est un grain de sable. La visibilité que vous décrochez, vous la décrochez sur votre niche, pas contre la plateforme.
## Verdict sans appel
Substack fait le boulot technique de base mieux que la moitié des sites WordPress mal configurés que je croise. H1 auto, balises meta pré-remplies, indexation propre des articles : pour publier vite et être lu, c'est carré. Si votre jeu, c'est l'écrit long et l'autorité éditoriale, le canal se défend même face à d'autres formats, comme développé dans notre papier sur le [long-form face au short-form](/long-form-vs-short-form-h2-2026-brand-journalism-youtube-substack).
Mais soyons clairs : sans domaine personnalisé, vous louez votre visibilité. Le sitemap conditionnel, le sous-domaine partagé, l'impossibilité de vraiment maîtriser la technique, tout ça vous met un plafond. Mon conseil tranché : lancez sur Substack pour valider votre audience, branchez le domaine perso dès que vous êtes sérieux, et gardez la porte de sortie ouverte. Une newsletter, ça doit vous appartenir. Le reste, c'est du confort.
## Sources
- [Substack robots.txt (fichier officiel)](https://substack.com/robots.txt)
- [Content Clarity : Substack post optimization checklist SEO](https://contentclarity.substack.com/p/substack-post-optimization-checklist-seo)
- [Content Clarity : guide des réglages SEO Substack](https://contentclarity.substack.com/p/guide-to-substack-seo-settings)
- [Boodsy : brancher Substack sur Google Search Console](https://boodsy.substack.com/p/get-your-substack-on-google-search-console)
- [Harshini Writes : Substack a coupé la génération automatique de sitemap](https://harshiniwrites.substack.com/p/substack-stopped-giving-this-feature)
- [Really Good Business Ideas : le domaine personnalisé Substack](https://www.reallygoodbusinessideas.com/p/substack-custom-domain)
---
## Données propriétaires : le carburant des citations LLM
- URL: https://www.referencement-internet-web.com/etudes-proprietaires-citations-llm-geo-2026/
- Author: Baptiste P.
- Published: 2026-07-02T06:00:00.000Z
- Categories: content-marketing
Spoiler alert : la moitié des tutos GEO que vous croisez vous vendent des bidouilles de formatage pour décrocher des citations LLM. Une balise par ci, une FAQ par là. Le truc c'est que le vrai levier, celui que les études pointent, est beaucoup moins sexy. Il tient en deux mots : données propriétaires. Vos chiffres à vous, votre sondage, votre benchmark maison. Ce que personne d'autre sur le web ne possède.
On ne va pas se mentir : produire de la recherche originale, c'est chiant, c'est long, et ça se délègue mal. Du coup tout le monde préfère croire qu'un bon ` | |