Vous publiez un article, vous attendez, et rien ne bouge dans les statistiques. Le doute s’installe vite : Google est-il seulement passé ? La Search Console affiche parfois « URL détectée, mais non indexée » sans plus de détails, ce qui n’aide pas. Le problème, c’est que l’exploration et l’indexation sont deux opérations distinctes, et qu’un passage de Googlebot peut rester invisible dans tous les rapports disponibles. Pour en avoir le cœur net, il faut descendre d’un cran et regarder ce que votre serveur a réellement reçu.
Lire un fichier log pour prouver une visite réelle
Un fichier log enregistre chaque requête reçue par le serveur : adresse IP, date, URL, user-agent, code HTTP et temps de réponse. C’est la seule source qui atteste d’un passage effectif, parce qu’elle est écrite par votre machine, pas par un outil tiers.
Un rapport de couverture vous dit ce que Google a décidé de faire d’une page ; le log vous dit ce qui s’est passé techniquement. La nuance compte quand on cherche à comprendre pourquoi une page neuve reste absente des résultats, et c’est le genre de vérification que détaille régulièrement dedieonet.fr sur les questions de crawling.
Concrètement, ouvrez le fichier d’accès de votre hébergeur, puis filtrez sur la chaîne « Googlebot ». Attention, l’user-agent seul ne prouve rien : n’importe qui peut le falsifier. La méthode fiable consiste à vérifier l’adresse IP par une résolution DNS inverse, ou à confronter la requête avec les plages d’adresses publiées par Google. Sur un petit site, un simple filtre sur l’URL concernée suffit souvent à trancher. Sur un gros volume, passez par un script ou un outil d’analyse de logs, sinon vous y passerez la soirée.
Ce que vous cherchez précisément, c’est une ligne avec le code HTTP 200 sur l’URL de votre nouvelle page, une date postérieure à la publication et un user-agent Googlebot. Si le code est un 301 ou un 404, vous avez votre réponse : le problème est ailleurs, et l’indexation n’a aucune chance d’aboutir. Si la ligne n’existe pas du tout, Googlebot n’est pas venu, ou il est venu sur une autre version de l’URL. Franchement, ce simple tri règle la moitié des inquiétudes.
Search Console et logs : deux sources qu’il faut croiser
L’inspection d’URL de la Search Console montre l’état d’une page telle que Google la connaît, avec la date du dernier crawl, la version canonique retenue et le rendu de la page. C’est pratique, mais l’outil ne rafraîchit pas ses données en direct : il affiche un état mis en cache, parfois vieux de plusieurs jours. Un log, lui, est horodaté à la seconde près. Croiser les deux évite de conclure trop vite sur un problème qui n’existe plus, ou sur une exploration qui n’a jamais eu lieu.
Reste la question que tout le monde se pose au moins une fois : comment savoir si je ne suis pas moi-même pris pour un robot en testant mon propre site ? C’est un faux problème dans la plupart des cas, mais il faut connaître le circuit.
Le robots.txt est interrogé avant la requête HTTP dans le circuit de crawling décrit par Google. Autrement dit, Googlebot lit d’abord vos règles, puis demande la page. Si vous bloquez une ressource en CSS ou en JavaScript dans ce fichier, le rendu de la page peut échouer chez Google alors qu’il s’affiche parfaitement chez vous.
Il existe deux versions de Googlebot, Smartphone et Desktop, et les deux répondent au même nom dans le robots.txt, sans possibilité de cibler l’un sans l’autre. Vous ne pouvez donc pas autoriser le robot mobile tout en bloquant le robot desktop, ni l’inverse.
Une interdiction écrite dans ce fichier s’applique aux deux, ce qui surprend souvent ceux qui testaient une règle ciblée. Le contrôle se fait dans la Search Console, rubrique dédiée à l’analyse du fichier, avec un test des URL concernées.
Les vérifications qui font gagner du temps
Avant de chercher midi à quatorze heures, passez une série de contrôles simples sur la page publiée. La plupart des cas d’exploration sans indexation se règlent à ce stade, sans toucher à quoi que ce soit d’autre. Sur ce point, voir aussi notre article sur hreflang verifier publication.
- L’URL renvoie-t-elle bien un code 200, sans redirection ni erreur serveur ?
- La balise canonical pointe vers cette page et pas vers une autre version.
- Avez-vous interdit la page dans le robots.txt ou posé une balise noindex ?
- Le contenu est-il unique, ou recopié d’une fiche produit déjà en ligne ?
- Combien pèse le HTML une fois chargé, hors images et scripts ?
Cette dernière ligne est celle qu’on oublie systématiquement, et c’est justement celle qui casse tout. Une page lourde peut être explorée correctement, apparaître dans vos logs avec un code 200, et ne jamais finir en index. Vous aurez beau relancer l’inspection d’URL, tout semblera normal. Le crawl a eu lieu, la lecture non.
Pourquoi une exploration réussie ne mène pas à l’indexation
Si une page HTML dépasse 2 Mo, Googlebot la tronque silencieusement, sans erreur ni avertissement dans la Search Console. Il lit le début, s’arrête, et repart. Tout ce qui se trouve après la coupure n’existe pas pour lui, y compris votre contenu principal si vous l’avez placé bas dans le code. Le diagnostic devient alors infernal, parce que tous les indicateurs visibles sont au vert : exploration effectuée, code 200, aucune erreur signalée. Le problème n’est pas le crawl, il est dans le volume servi.
La limite de taille est de 2 Mo pour le HTML et de 64 Mo pour le PDF, avec un ratio visualisable via une barre de progression dans les outils de Google. Ce contraste explique pourquoi certaines pages passent sans difficulté là où d’autres échouent : le format change tout.
Un catalogue PDF volumineux sera lu sans broncher, tandis qu’une page produit bourrée de contenu en ligne, de scripts et de données structurées sera coupée avant la fin. Vérifier l’exploration ne suffit donc pas, il faut aussi contrôler le poids du HTML.
Le remède est rarement compliqué. Sortir le code JavaScript non critique, comprimer la réponse, déplacer les blocs de données volumineux vers des fichiers chargés à la demande. L’objectif n’est pas d’atteindre un score parfait, juste de rester sous le seuil avec de la marge, parce que le HTML a tendance à gonfler au fil des mois. Une page qui pesait un mégaoctet l’an dernier peut avoir doublé sans que personne ne s’en aperçoive.
Demander l’indexation, oui, mais après avoir corrigé
Une fois les correctifs faits, vous pouvez demander l’indexation d’une page dans la Search Console, via l’inspection d’URL et le bouton d’exploration. Cela ne force rien : vous signalez simplement la page à Google, qui décidera de la traiter ou non. La manipulation est utile après une modification réelle, beaucoup moins si vous la répétez tous les jours sur la même URL sans rien changer. Le quota est limité, et l’acharnement n’accélère rien.
Que font les robots qui explorent constamment le Web pour découvrir les pages, au fait ? Ils suivent les liens, parcourent les sitemaps et reviennent régulièrement sur les sites qu’ils connaissent déjà. Googlebot, comme ses confrères, priorise selon la fraîcheur et la popularité perçue. Une page publiée puis jamais liée depuis une autre page du site a peu de chances d’être trouvée rapidement. Un lien interne depuis une page bien crawlé fait souvent plus d’effet qu’une demande d’indexation.
Le réflexe utile, en SEO, consiste à parcourir un site avec un logiciel qui imite un robot pour repérer les erreurs avant Google. Ce crawl de contrôle repère les pages trop lourdes, les redirections en chaîne et les ressources bloquées, autant de choses qu’un simple test visuel ne montre pas. Faites-le après chaque grosse publication. Ça prend dix minutes et ça évite des semaines d’attente inutile.
Ce que la donnée brute vous apprend vraiment
Une exploration prouvée dans les logs ne garantit pas l’indexation, et une page absente des résultats n’est pas forcément une page jamais visitée. Les deux mondes obéissent à des règles différentes, et le poids du HTML est le pont invisible entre eux.
Prendre l’habitude de vérifier les deux côtés, logs et Search Console, change la façon de diagnostiquer un problème de référencement. La prochaine fois qu’une page neuve reste introuvable, irez-vous d’abord regarder vos logs ou relancer une inspection d’URL ?
