Robots.txt étendu, deep links et DMA : analyse technique

Trois signaux majeurs cette semaine. Google étend sa documentation robots.txt pour documenter explicitement les directives qu'il ne supporte pas. Il publie en parallèle des best practices formalisées pour les deep links Android/iOS. Et la Commission européenne propose d'obliger Google à partager ses données de recherche avec ses concurrents et les chatbots IA, dans le cadre du Digital Markets Act. Ces trois événements, pris ensemble, redessinent les contours du SEO technique pour les mois à venir.

L'expansion de la documentation robots.txt : ce que Google dit vraiment

La mise à jour de la documentation robots.txt de Google ne se limite pas à un exercice de style éditorial. Google documente désormais les directives qu'il ne supporte pas — Crawl-delay, Noindex dans robots.txt, Host, et plusieurs autres. Ce qui était auparavant de la connaissance tribale partagée dans des threads Twitter devient une référence officielle.

Pourquoi c'est significatif

Jusqu'ici, la position de Google sur les directives non standard était dispersée entre des réponses de John Mueller sur Reddit, des vidéos Google Search Central, et des articles de blog tiers. Avoir une page unique de référence change la donne pour trois raisons :

1. Clarification du comportement de parsing : Googlebot parse le fichier robots.txt selon la RFC 9309 (publiée en septembre 2022). Toute directive hors spec est ignorée silencieusement. Pas d'erreur, pas de warning dans Search Console. Votre Crawl-delay: 10 n'a jamais eu le moindre effet sur Googlebot — mais il impacte bien d'autres bots comme Bingbot ou certains crawlers de monitoring.

2. Signal d'intention : documenter ce qui n'est pas supporté est souvent le prélude à documenter ce qui pourrait le devenir. Google a l'habitude de formaliser avant d'itérer.

3. Impact sur les audits techniques : les équipes SEO qui auditent des robots.txt de sites legacy peuvent désormais pointer vers une source officielle pour justifier le nettoyage de directives obsolètes.

Le piège classique : Noindex dans robots.txt

C'est le cas d'école. Pendant des années, Google a officieusement supporté Noindex: comme directive dans robots.txt. En septembre 2019, le support a été retiré. Pourtant, en 2026, des milliers de sites utilisent encore cette directive en croyant qu'elle empêche l'indexation.

Voici un robots.txt typique d'un e-commerce de 20 000 pages, récupéré lors d'un audit récent :

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Noindex: /promo/
Crawl-delay: 5

User-agent: Googlebot
Allow: /

Sitemap: https://shop.example.fr/sitemap_index.xml

Trois problèmes ici. Noindex: est ignoré par Googlebot — les pages /promo/ restent indexables si elles ne portent pas de <meta name="robots" content="noindex"> ou un header HTTP X-Robots-Tag: noindex. Crawl-delay: 5 est ignoré par Googlebot mais ralentit Bingbot, ce qui peut être voulu ou non. Et la règle Allow: / pour Googlebot est redondante puisque tout est autorisé par défaut sauf les Disallow explicites.

La correction propre pour empêcher l'indexation des pages promo sans bloquer le crawl (utile pour la découverte de liens internes) :

<!-- Sur chaque page /promo/* -->
<meta name="robots" content="noindex, follow">

Ou côté serveur, si vous ne voulez pas toucher au template :

# Configuration Nginx
location /promo/ {
    add_header X-Robots-Tag "noindex, follow" always;
    # 'always' est nécessaire pour que le header soit envoyé
    # même sur les réponses 3xx et 4xx
}

L'avantage du header HTTP X-Robots-Tag : il fonctionne aussi sur les fichiers non-HTML (PDF, images), et il n'exige pas de modifier les templates applicatifs. Pour un site avec 500+ pages promo générées dynamiquement, c'est souvent la solution la plus propre.

Auditer votre robots.txt actuel

Screaming Frog permet de vérifier rapidement si votre robots.txt contient des directives non supportées. Mais pour un monitoring continu — surtout sur des sites où plusieurs équipes (SEO, dev, ops) modifient le fichier — un outil comme Seogard détecte automatiquement les changements de robots.txt et alerte quand une directive invalide est introduite. Sur un site de 15 000 pages, un Disallow: / ajouté par erreur un vendredi soir peut désindexer l'intégralité du site avant que quiconque ne s'en rende compte le lundi.

Pour ceux qui veulent déjà comprendre comment Google documente l'expansion potentielle des règles non supportées, nous avions analysé les premiers signaux il y a quelques semaines.

Deep links : Google formalise les best practices

Google a publié des recommandations structurées pour les deep links — ces liens qui redirigent l'utilisateur directement vers un contenu spécifique dans une application mobile plutôt que vers la page d'accueil ou le navigateur. Ce n'est pas nouveau techniquement, mais la formalisation par Google dans un contexte SEO l'est.

Le problème que ça résout

Considérez un média en ligne avec 8 000 articles. Un utilisateur qui clique sur un résultat Google depuis un smartphone avec l'app installée attend d'atterrir sur l'article, pas sur l'écran d'accueil de l'app. Sans deep links correctement configurés, c'est exactement ce qui se passe — et le taux de rebond explose.

Google distingue trois types de liens pour Android :

• Deep links : gérés par des intent filters, mais sans vérification de propriété. N'importe quelle app peut déclarer gérer un domaine.
• Web links : deep links utilisant http:// ou https://, avec la même limitation.
• Android App Links : deep links vérifiés via Digital Asset Links (assetlinks.json). Le système ouvre directement l'app sans demander à l'utilisateur de choisir.

C'est le troisième type qui nous intéresse pour le SEO. Google recommande explicitement les Android App Links pour éviter les ambiguïtés d'intent resolution.

Implémentation technique des Android App Links

Deux étapes. D'abord, le fichier de vérification côté serveur :

// Hébergé à https://media.example.fr/.well-known/assetlinks.json
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "fr.example.media",
    "sha256_cert_fingerprints": [
      "14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"
    ]
  }
}]

Le fingerprint SHA-256 doit correspondre exactement au certificat de signature de votre APK/AAB. Une erreur fréquente : utiliser le certificat de debug au lieu du certificat de release. Pour obtenir le bon fingerprint :

# Pour un keystore de release
keytool -list -v -keystore release-keystore.jks -alias media-key | grep SHA256

# Pour un App Bundle signé par Google Play (Play App Signing)
# Le fingerprint est disponible dans la Play Console
# Setup > App signing > App signing key certificate

Ensuite, dans le AndroidManifest.xml de l'application :

<activity android:name=".ArticleActivity"
    android:exported="true">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="media.example.fr"
            android:pathPrefix="/article/" />
    </intent-filter>
</activity>

L'attribut android:autoVerify="true" déclenche la vérification automatique du fichier assetlinks.json à l'installation de l'app. Si la vérification échoue (fichier absent, fingerprint incorrect, certificat SSL invalide), Android ne traitera pas les liens comme des App Links vérifiés.

Impact SEO concret

Pour Google, un deep link vérifié est un signal de cohérence entre votre présence web et votre présence app. Dans les résultats de recherche mobile, les pages avec des App Links vérifiés peuvent afficher un badge "App" et offrir une expérience directe vers l'application. Sur un média avec 8 000 articles et 60 % de trafic mobile, la différence de taux de rebond entre "ouverture dans l'app" et "ouverture dans le navigateur mobile" peut atteindre 15 à 25 points de pourcentage, selon les données internes que nous avons observées sur des projets similaires.

Notre article détaillé sur les best practices Google pour les deep links "Read more" couvre les spécificités des liens de type "lire la suite" dans les flux de contenu.

Le cas iOS : Universal Links

Côté Apple, le mécanisme équivalent est les Universal Links, configurés via un fichier apple-app-site-association (AASA) :

// Hébergé à https://media.example.fr/.well-known/apple-app-site-association
{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appIDs": ["TEAM_ID.fr.example.media"],
        "components": [
          {
            "/": "/article/*",
            "comment": "Matches all article pages"
          }
        ]
      }
    ]
  }
}

Attention : Apple ne tolère aucune redirection sur le fichier AASA. Il doit être servi directement en application/json depuis /.well-known/apple-app-site-association, sans extension .json. Si votre CDN ou votre reverse proxy ajoute une redirection 301, les Universal Links ne fonctionneront pas.

Le DMA entre en scène : Google forcé de partager ses données de recherche

La Commission européenne a proposé, dans le cadre de l'application du Digital Markets Act (DMA), d'obliger Google à partager ses données de recherche avec ses concurrents et les chatbots IA. C'est une rupture structurelle, pas un ajustement technique.

Ce que ça implique concrètement

Le DMA, en vigueur depuis mars 2024, désigne Google Search comme "gatekeeper". L'article 6(11) du DMA impose aux gatekeepers de fournir un accès aux données de ranking, de clics et de requêtes à des conditions équitables. La proposition de la CE va plus loin : elle vise spécifiquement les données qui alimentent les résultats de recherche, et les ouvre aux chatbots IA comme concurrents légitimes.

Pour les équipes SEO, trois conséquences techniques :

1. Multiplication des surfaces de crawl. Si des moteurs alternatifs et des chatbots IA obtiennent accès aux données de requêtes Google, ils vont construire leurs propres index plus agressivement. Le crawl budget devient un enjeu encore plus critique. Un site de 30 000 pages qui gérait principalement Googlebot devra potentiellement optimiser pour 5 à 10 crawlers supplémentaires, chacun avec ses propres comportements. Notre analyse sur les 68 millions de visites de crawlers IA montre déjà l'ampleur du phénomène.

2. Fragmentation des signaux de visibilité. Aujourd'hui, Search Console est votre source de vérité pour comprendre comment Google voit votre site. Si Perplexity, Brave Search ou un chatbot européen utilisent des données de ranking partagées par Google, vos contenus apparaîtront dans des contextes que vous ne monitorez pas. L'analyse de log files pour les crawlers IA devient indispensable.

3. Enjeu de contrôle du contenu. Si vos données de ranking sont partagées, des systèmes tiers peuvent afficher vos contenus dans des contextes que vous n'avez pas approuvés. Le robots.txt et les directives comme noai ou noimageai (pas encore standardisées, mais en discussion) prennent une importance nouvelle.

Implications pour le robots.txt

C'est ici que les trois actualités de la semaine convergent. L'expansion de la documentation robots.txt par Google, combinée à la pression DMA, suggère un avenir où le contrôle granulaire des accès par agent devient essentiel.

Aujourd'hui, un robots.txt typique distingue à peine Googlebot des autres. Dans un monde post-DMA, vous pourriez avoir besoin de quelque chose comme :

User-agent: Googlebot
Allow: /
Disallow: /internal/

User-agent: Bingbot
Allow: /
Disallow: /internal/
Crawl-delay: 2

User-agent: GPTBot
Disallow: /premium-content/
Disallow: /data-reports/

User-agent: anthropic-ai
Disallow: /premium-content/
Disallow: /data-reports/

User-agent: PerplexityBot
Disallow: /premium-content/

User-agent: *
Disallow: /internal/
Disallow: /staging/

Sitemap: https://shop.example.fr/sitemap_index.xml

Ce type de configuration granulaire n'est viable que si vous monitorez activement quels bots accèdent à votre site et comment ils se comportent. Les logs serveur sont votre première ligne de défense.

Scénario concret : migration et convergence des trois sujets

Prenons un cas réaliste. Un site e-commerce français, 18 000 pages produit, 3 000 pages catégorie, 500 pages de contenu éditorial. Trafic organique : 280 000 sessions/mois. 65 % mobile. Application Android et iOS existantes, mais deep links mal configurés. Le site tourne sur Next.js avec SSR.

Situation initiale

L'audit Screaming Frog révèle :

• Le robots.txt contient Crawl-delay: 10 et Noindex: /soldes/ — deux directives ignorées par Googlebot.
• 1 200 pages /soldes/* sont indexées malgré l'intention de les exclure.
• Le fichier assetlinks.json pointe vers un ancien certificat de signature (l'app a été migrée vers Play App Signing il y a 6 mois).
• Les Universal Links iOS ne fonctionnent pas : le fichier AASA est servi avec une redirection 302 par le CDN Cloudflare.
• Aucune règle robots.txt pour les crawlers IA. Les logs montrent 45 000 requêtes/jour de GPTBot et 12 000 de ClaudeBot, concentrées sur les fiches produit.

Plan de correction

Phase 1 — robots.txt (jour 1-2)

Suppression des directives non supportées. Ajout de règles spécifiques pour les crawlers IA. Configuration du rate limiting côté Nginx pour éviter la surcharge :

# Rate limiting pour les crawlers IA
map $http_user_agent $is_ai_crawler {
    default 0;
    "~*GPTBot" 1;
    "~*ClaudeBot" 1;
    "~*anthropic-ai" 1;
    "~*PerplexityBot" 1;
    "~*Bytespider" 1;
}

limit_req_zone $is_ai_crawler zone=ai_crawlers:10m rate=5r/s;

server {
    location / {
        if ($is_ai_crawler) {
            limit_req zone=ai_crawlers burst=10 nodelay;
        }
        # ... reste de la config
    }
}

Phase 2 — Deep links (jour 3-7)

Mise à jour du fingerprint SHA-256 dans assetlinks.json. Correction du fichier AASA en désactivant la redirection Cloudflare sur /.well-known/* via une Page Rule. Validation avec l'outil de test d'Android : adb shell am start -a android.intent.action.VIEW -d "https://shop.example.fr/produit/chaussure-running-42".

Phase 3 — Noindex des pages soldes (jour 3-5)

Remplacement de la directive robots.txt par un header HTTP X-Robots-Tag appliqué au niveau Nginx. Soumission des URL via l'API d'indexation pour accélérer la prise en compte.

Phase 4 — Monitoring continu (jour 8+)

Mise en place d'alertes sur les changements de robots.txt, les headers X-Robots-Tag, et les volumes de crawl par user-agent. Un outil de monitoring comme Seogard détecte ces régressions en continu — indispensable quand trois équipes (SEO, dev, ops) touchent à la configuration serveur.

Résultats attendus

Sur 4 à 6 semaines : désindexation des 1 200 pages /soldes/*, réduction de 40 % du crawl IA non désiré (libérant de la bande passante serveur), et restauration des App Links vérifiés sur Android — avec un impact mesurable sur le taux de rebond mobile.

La convergence robots.txt + DMA + deep links : une lecture stratégique

Ces trois actualités ne sont pas décorrélées. Elles pointent vers une même direction : la fragmentation de l'accès au contenu web.

Avant, vous aviez un interlocuteur principal (Google), un fichier de contrôle (robots.txt), et une surface de rendu (le navigateur web). Désormais, votre contenu est consommé par des crawlers IA, affiché dans des chatbots, ouvert dans des applications mobiles, et potentiellement redistribué via des concurrents de Google ayant accès aux données de ranking.

Le contrôle granulaire de l'accès à vos contenus — par agent, par surface, par contexte — devient une compétence technique de premier plan. Les sites qui gèrent encore leur robots.txt comme en 2015 (un bloc User-agent: * et quelques Disallow) accumulent une dette technique invisible.

Quelques questions à poser lors de votre prochain audit technique :

• Votre robots.txt contient-il des directives que Googlebot ignore silencieusement ?
• Savez-vous quels crawlers IA accèdent à votre site, à quelle fréquence, et sur quelles sections ?
• Vos deep links Android et iOS sont-ils vérifiés et fonctionnels sur vos 50 URL les plus visitées en mobile ?
• Si la CE impose le partage de données de recherche, êtes-vous prêt à monitorer votre visibilité au-delà de Google Search Console ?

La tendance vers une architecture pensée pour les agents IA se confirme chaque semaine. Le robots.txt est le premier point de contact entre votre serveur et ces agents. Traitez-le comme une pièce d'infrastructure critique, pas comme un fichier qu'on écrit une fois et qu'on oublie.

Comment monitorer ces changements à l'échelle

Sur un site de moins de 100 pages, une vérification manuelle suffit. Au-delà, les risques de régression sont exponentiels. Voici les outils et méthodes qui fonctionnent à l'échelle.

Validation continue du robots.txt

Screaming Frog permet de tester le robots.txt contre une liste d'URLs en mode liste. Mais c'est un test ponctuel. Pour du monitoring continu :

# Script cron simple pour détecter les changements de robots.txt
#!/bin/bash
SITE="https://shop.example.fr"
HASH_FILE="/var/monitoring/robots_hash.txt"
CURRENT_HASH=$(curl -s "$SITE/robots.txt" | sha256sum | awk '{print $1}')
STORED_HASH=$(cat "$HASH_FILE" 2>/dev/null)

if [ "$CURRENT_HASH" != "$STORED_HASH" ]; then
    echo "$CURRENT_HASH" > "$HASH_FILE"
    curl -X POST "https://hooks.slack.com/services/YOUR/WEBHOOK" \
        -H 'Content-type: application/json' \
        -d "{\"text\":\"⚠️ robots.txt modifié sur $SITE — vérification requise\"}"
fi

C'est un point de départ, mais ça ne valide pas la sémantique du fichier. Vous ne saurez pas qu'un Disallow: / a été ajouté — juste que le fichier a changé. Un monitoring SEO dédié comme Seogard parse le contenu, identifie les directives à risque, et corrèle les changements avec les données de crawl.

Validation des deep links

Google fournit un outil de test pour les App Links qui vérifie la validité de votre assetlinks.json. Pour les Universal Links iOS, la validation est plus opaque — Apple ne fournit pas d'outil public équivalent, mais vous pouvez vérifier que votre fichier AASA est correctement servi :

# Vérification du fichier AASA
curl -I "https://shop.example.fr/.well-known/apple-app-site-association"
# Doit retourner 200, Content-Type: application/json, pas de redirection

# Vérification du contenu
curl -s "https://shop.example.fr/.well-known/apple-app-site-association" | python3 -m json.tool
# Doit parser sans erreur et contenir votre appID

Analyse de logs par user-agent

Search Console ne vous montre que le crawl de Googlebot. Pour les autres crawlers, les logs serveur sont votre seule source. Un pipeline ELK (Elasticsearch, Logstash, Kibana) ou une solution comme GoAccess peut segmenter les requêtes par user-agent et identifier les pics de crawl IA.

L'enjeu n'est pas uniquement défensif. Comprendre quels crawlers IA visitent votre site, et quelles pages ils priorisent, vous donne une carte de votre visibilité IA actuelle et future.

Ce qu'il faut retenir

L'expansion de la documentation robots.txt par Google, la formalisation des deep links, et la pression réglementaire du DMA convergent vers un même impératif : maîtriser finement qui accède à votre contenu, comment, et dans quel contexte. Le robots.txt n'est plus un fichier accessoire — c'est une politique d'accès à votre patrimoine de contenu. Les deep links ne sont plus un "nice to have" mobile — ils sont un facteur d'expérience utilisateur que Google mesure. Et le DMA ne concerne pas que les juristes — il va multiplier les crawlers et les surfaces sur lesquelles votre contenu apparaît, que vous le vouliez ou non. Mettez en place un monitoring automatisé de ces trois surfaces dès maintenant, avant que la prochaine régression silencieuse ne vous coûte du trafic.