Pourquoi vos pages techniquement parfaites n'apparaissent-elles pas dans Google ?

Quelle différence entre crawlable et indexable ?

Une page peut être crawlée par Googlebot sans jamais entrer dans l'index. Le crawl, c'est la visite technique du bot. L'indexation, c'est la décision d'ajouter cette page au catalogue de résultats potentiels.

Des centaines de sites perdent du trafic parce qu'ils confondent les deux. Leur fichier de logs montre des passages réguliers de Googlebot, mais Search Console affiche « Exclue par la balise noindex ». Le bot vient, lit, puis jette. Concrètement, une directive noindex dans le HTML ou dans les en-têtes HTTP suffit à bloquer l'indexation même si le crawl budget est alloué.

Quels sont les principaux obstacles à l'indexation ?

La balise meta robots noindex reste le coupable classique, souvent laissée en production après une phase de staging. Mais les en-têtes HTTP X-Robots-Tag passent inaperçus car ils ne s'affichent pas dans le code source visible.

Les paramètres de CMS posent aussi problème. WordPress, Shopify, Prestashop embarquent des options « Visibilité pour les moteurs de recherche » qui ajoutent un noindex global. Un développeur distrait coche la case, le site déploie en production avec toutes les pages bloquées. Les redirections 301/302 ne sont pas indexables non plus, mais elles transfèrent le signal vers la cible — sauf si la cible elle-même est bloquée.

Comment Google détecte-t-il ces blocages ?

Googlebot lit d'abord les en-têtes HTTP avant même de parser le HTML. Si un X-Robots-Tag: noindex apparaît dans la réponse serveur, le contenu HTML n'est même pas analysé pour l'indexation. Le bot peut quand même suivre les liens internes pour découvrir d'autres pages, mais celle-ci reste exclue.

Dans Search Console, l'onglet « Couverture » ou « Pages » signale ces exclusions avec des libellés explicites : « Exclue par la balise noindex », « Bloquée par le fichier robots.txt », « Page avec redirection ». Le problème, c'est que ces rapports peuvent mettre plusieurs jours à remonter après un déploiement. Un audit préventif évite de perdre une semaine de visibilité.

• Crawl ≠ indexation : Googlebot peut visiter une page sans l'ajouter à l'index
• Balises meta robots et en-têtes X-Robots-Tag bloquent l'indexation même si le crawl est autorisé
• Search Console signale les exclusions, mais avec plusieurs jours de latence
• Les CMS grand public (WordPress, Shopify) ont des options cachées qui ajoutent des noindex globaux
• Un audit préventif des directives robots doit faire partie du checklist de mise en production

Cette déclaration est-elle cohérente avec les pratiques observées ?

Oui, et c'est même un rappel bienvenu. Sur le terrain, 30 à 40 % des audits SEO révèlent des pages stratégiques bloquées par des directives oubliées. Les équipes focalisent sur le contenu, les backlinks, la structure, mais négligent l'indexabilité technique. Google peut crawler 10 000 pages par jour sur un site et n'en indexer que 200 si des noindex traînent.

La confusion vient aussi du fait que les outils SEO populaires (Screaming Frog, Oncrawl, Botify) simulent un crawl mais ne vérifient pas toujours les en-têtes HTTP en conditions réelles. Un scan local peut manquer un X-Robots-Tag configuré uniquement en production via Cloudflare ou un CDN. Il faut tester avec l'outil d'inspection d'URL de Search Console, qui montre exactement ce que Googlebot voit.

Quelles nuances faut-il apporter ?

Google dit « assurez-vous que les pages sont indexables », mais ne précise pas le délai entre correction et indexation effective. [À vérifier] Un noindex retiré ne garantit pas une indexation immédiate. Le recrawl peut prendre des jours, voire des semaines sur un site à faible crawl budget.

Autre point flou : Google ne détaille pas l'impact des canonical mal configurées. Une balise canonical pointant vers une URL différente n'est pas un noindex strict, mais elle redirige le signal d'indexation ailleurs. Résultat : la page originale reste crawlée mais jamais affichée dans les SERPs. Techniquement, elle n'est pas « bloquée », mais l'effet est le même.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Certaines pages doivent rester non indexables : pages de connexion, paniers, résultats de recherche interne, filtres à facettes dynamiques. Un site e-commerce peut générer des milliers d'URLs combinatoires (couleur + taille + prix) qu'il vaut mieux bloquer pour ne pas diluer le crawl budget.

Le vrai challenge est de segmenter intelligemment. Un noindex global sur /search/ est pertinent, mais un noindex sur /category/ est souvent une erreur. Les CMS modernes permettent des règles conditionnelles (noindex si paramètre X présent), mais leur configuration demande une vision claire de l'architecture. Un mauvais paramétrage coûte plus cher qu'un audit externe.

Que faut-il faire concrètement pour auditer l'indexabilité ?

D'abord, exporter la liste des URLs « Exclues » depuis Search Console > Pages. Trier par motif d'exclusion : noindex, robots.txt, canonicales, soft 404. Chaque catégorie révèle un type de problème différent. Les noindex accidentels se repèrent vite si une page stratégique apparaît dans la liste.

Ensuite, crawler le site avec Screaming Frog en mode Spider, activer l'option « Render JavaScript » si le site est en React/Vue/Angular. Vérifier la colonne « Indexability » pour chaque URL. Comparer avec les en-têtes HTTP réels via l'onglet « Response Headers ». Un décalage entre le HTML (noindex absent) et les en-têtes (X-Robots-Tag présent) signale une couche serveur ou CDN qui injecte des directives.

Quelles erreurs éviter lors du déploiement ?

Ne jamais laisser un environnement de staging avec password protection + noindex puis copier la base de données en production sans nettoyer les settings. WordPress, par exemple, stocke le réglage « Décourager les moteurs de recherche » dans wp_options. Un import SQL direct réactive le noindex global.

Éviter aussi les règles robots.txt trop larges. Un « Disallow: /*? » bloque toutes les URLs avec paramètres, y compris les paginations légitimes ou les variantes de langue (?lang=en). Googlebot ne peut ni crawler ni indexer. Préférer des Disallow ciblés sur les paramètres inutiles (utm_, sessionid, sort).

Comment vérifier que les corrections fonctionnent ?

Utiliser l'outil d'inspection d'URL dans Search Console immédiatement après le retrait d'un noindex. Cliquer sur « Tester l'URL en direct » pour forcer un nouveau crawl. Google affichera « URL indexable » ou signalera un problème persistant. Si tout est vert, demander une indexation manuelle.

Surveiller les logs serveur pendant 48h après la correction. Si Googlebot ne revient pas, c'est que la page a une faible priorité de crawl. Il faut alors booster le signal : ajouter des liens internes depuis des pages déjà indexées, soumettre un sitemap XML actualisé, ou publier du contenu frais qui appelle cette URL. L'indexabilité technique ne suffit pas si Google ne la découvre jamais.

• Exporter les URLs exclues depuis Search Console et trier par motif
• Crawler le site avec rendu JavaScript activé pour détecter les noindex dynamiques
• Vérifier les en-têtes HTTP réels (X-Robots-Tag, canonical) via cURL ou les dev tools
• Tester chaque correction avec l'outil d'inspection d'URL avant de généraliser
• Automatiser des alertes Search Console pour détecter de nouvelles exclusions chaque semaine
• Documenter les règles d'indexabilité dans un guide interne pour éviter les régressions