Vérifier ce que Googlebot lit vraiment dans votre page
Vos balises canonical et hreflang sont-elles là où Google les lit ? La Search Console sait afficher deux choses contradictoires sur la même page : le test d'URL en direct passe au vert, et le rapport d'indexation annonce « URL canonique déclarée par l'utilisateur : Aucun ». Les deux disent vrai. Ils ne regardent simplement pas le même HTML.
Cette méthode départage les deux avec deux commandes curl. Comptez cinq minutes par page, un terminal, et aucun accès au serveur. Elle vous dit qu'une balise tombe au mauvais endroit ; elle ne dit pas quelle couche de votre pile l'y a mise.
Passé au TIQ, tester, itérer, qualifier, le 09/09/2026 · Testé · les 58 URL du sitemap de markentiq.com, plus deux défauts fabriqués et l'étape 06 en Search Console · avec Claude Opus 5, 09/09/2026 · non couvert : les sites à rendu JavaScript côté client, les balises Open Graph et meta robots. Seconde exécution le 10/09/2026, mêmes 58 URL et neuf défauts fabriqués, sur la version 1.4 du kit. Lire le compte rendu d'exécution.
* Le mode d'emploi complet part dans votre presse-papier : les six étapes avec leurs commandes, les règles de décision et la checklist. Collez-le dans une conversation avec Claude, ChatGPT ou Vibe, puis donnez cette consigne : « Commence par l'étape 01 sur cette URL, donne-moi les commandes à lancer, et n'avance à l'étape suivante qu'une fois que je t'ai collé la sortie. »
Je développe des thèmes Shopify sur-mesure et je passe le reste de mon temps sur deux terrains, la performance (Core Web Vitals) et le SEO technique. Les défauts qui m'intéressent sont ceux que les outils déclarent absents, ceux qu'on ne trouve qu'en regardant ce que le serveur envoie vraiment. On peut me solliciter sur une migration vers Shopify, une refonte de thème ou un audit technique de boutique.
Cette méthode est publiée sous la signature de son auteur et dans sa voix. Nous l'avons exécutée nous-mêmes avant de la publier, sur un cas qui n'est pas le sien, et le compte rendu de cette exécution paraît plus bas, y compris ce qu'il nous a fallu corriger.
Ce que la méthode produit
La position en octets de </head>, de <title>, de rel="canonical" et de hreflang sur une URL, avec un verdict par balise.
La preuve, ou l'absence de preuve, que votre site sert deux HTML différents à la même adresse selon qui la demande.
La même vérification sur toutes les URL d'un sitemap, une ligne par URL, exploitable en intégration continue.
Elle ne produit pas de diagnostic de cause. Elle vous dit qu'une balise tombe au mauvais endroit, pas quelle couche de votre pile l'y a mise.
Prérequis
| Prérequis | Pourquoi |
|---|---|
Un terminal avec curl et grep | macOS, Linux, WSL ou Git Bash. Les deux sont déjà installés. |
| L'URL publique de la page | Aucun accès au serveur, aucune connexion à la Search Console. |
| 5 minutes par page | Deux requêtes et quatre grep. |
| Un accès Search Console, pour la dernière étape seulement | Confirmer la lecture de Google. Facultatif. |
La méthode, étape par étape
Le kit de l'auteur est disponible. Les six étapes s'exécutent entièrement à la main, avec curl et grep. head-check.sh ne fait que les enchaîner et rendre un code de sortie utilisable en intégration continue. Il est utile et jamais obligatoire. Voir le kit et le télécharger →
Demander la page avec l'user agent de Googlebot
curl -sS -L -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \ https://example.com/page > bot.html
Beaucoup de frameworks et de CDN décident quoi envoyer en lisant l'en-tête User-Agent. Vous voulez la réponse destinée à Googlebot, celle sur laquelle l'indexation se joue.
Comment on vérifie. Le fichier doit peser quelque chose et contenir votre contenu : wc -c bot.html puis grep -c '<h1' bot.html. Un fichier de 500 octets veut dire qu'on vous a servi une page de challenge.
Le piège. Oublier -L. Sans lui, une URL qui redirige vous rend le corps vide de la 301 et vous concluez à l'absence de tout.
L'autre piège, et il est plus vicieux. Avec -L, vous mesurez la page d'arrivée en croyant mesurer celle que vous avez demandée. Une redirection passe inaperçue, et une page d'erreur qui sert un <head> complet, ce que font beaucoup de CMS, vous rend un verdict parfaitement conforme sur une adresse qui répond 404. Demandez les deux informations à curl :
curl -sS -L -o bot.html -w '%{http_code} %{url_effective}\n' \
-A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://example.com/page
Si le code n'est pas 200, arrêtez-vous là. Si l'adresse finale n'est pas celle que vous avez tapée, tout ce qui suit décrit l'arrivée, pas le départ.
Situer la fin du head
grep -abo '</head>' bot.html | head -1
Vous obtenez un nombre, la position en octets de la fermeture du <head>. C'est la seule frontière qui compte, parce que Google ignore canonical et hreflang en dehors.
Comment on vérifie. La commande doit sortir exactement une ligne. Zéro ligne veut dire que la réponse n'est pas du HTML, ou qu'elle est tronquée.
Le piège. head -1 n'est pas décoratif. Certaines pages contiennent la chaîne </head> dans un script inline, et vous prendriez la mauvaise position.
Situer les balises qui comptent
grep -Eabo '<link[^>]*rel=.?canonical' bot.html | head -1 grep -Eabo '<link[^>]*hreflang=' bot.html | head -1 grep -abo '<title' bot.html | head -1
Comparez chaque nombre à celui de l'étape 02. Plus petit, la balise est dans le <head> et Google la lit. Plus grand, elle est dans le <body> et Google l'ignore.
Comment on vérifie. Allez regarder la zone pour confirmer que vous tenez la bonne balise, avec dd if=bot.html bs=1 skip=OFFSET count=200 2>/dev/null où OFFSET est le nombre que vous venez d'obtenir.
Le piège. Chercher l'attribut seul. grep -abo 'hreflang=' trouve aussi le mot dans le texte de la page, et une page qui explique ces balises se met elle-même en défaut. C'est arrivé à celle que vous lisez. Exigez un <link, comme ci-dessus. C'est aussi plus juste : un hreflang posé sur un <a> n'est pas ce que Google lit pour les alternances de langue.
L'autre piège. Les guillemets et les retours à la ligne. Un framework peut écrire rel='canonical', rel=canonical, ou couper la balise sur trois lignes. Le .? couvre les guillemets. Pour le reste, passez la réponse dans tr '\n' ' ' avant de chercher : un octet pour un octet, les positions ne bougent pas et la balise redevient une seule chaîne.
Demander la même page avec un user agent de navigateur
curl -sS -L -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 \ (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" https://example.com/page > web.html
Refaites les étapes 02 et 03 sur web.html. Deux verdicts différents sur la même URL veut dire que le serveur adapte sa réponse au demandeur.
Comment on vérifie. wc -c bot.html web.html. Un écart de taille important entre les deux réponses est un signal à lui seul.
Le piège. Croire qu'un verdict « après </head> » côté navigateur est une panne. Sur les frameworks qui streament leurs métadonnées, c'est le comportement prévu, et il est sans conséquence pour un humain. La ligne à lire est celle de Googlebot.
Étendre au sitemap
curl -sS https://example.com/sitemap.xml | tr '<' '\n' | grep '^loc>' | sed 's/^loc>//'
Une page saine ne dit rien des 200 autres. Bouclez sur cette liste avec les étapes 01 à 03. Le script head-check.sh du kit le fait en un seul appel, avec un code de sortie utilisable en intégration continue.
Comment on vérifie. Le nombre d'URL traitées doit correspondre au nombre de <loc> du sitemap. S'il est supérieur, votre boucle a coupé une URL sur un espace : bouclez sur des lignes, pas sur des mots, et coupez le développement des jokers avec set -f. Un sitemap est une entrée que vous ne maîtrisez pas.
Le piège. Confondre une panne et un défaut. Une page injoignable au moment du test n'a rien à vous dire sur son <head>, et un réseau qui bronche donne une liste d'échecs qui n'existent pas. Comptez-les à part, réessayez une fois, et rejouez la passe depuis un autre poste avant de conclure. Même chose pour les URL mortes du sitemap : une 404 sort en échec parce qu'elle n'a ni titre ni canonique, et c'est légitime.
L'autre piège. Un sitemap index. Ses <loc> pointent vers d'autres sitemaps, pas vers des pages : bouclé tel quel, il vous rend un échec par sitemap enfant. Vérifiez la balise racine, urlset ou sitemapindex, avant de partir.
Faire confirmer la lecture par Google
Dans la Search Console, inspectez l'URL et lisez deux lignes : la date de dernière exploration, et « URL canonique déclarée par l'utilisateur ». Si la date est postérieure à votre correctif et que la canonique est reconnue, Google a lu la nouvelle version.
Comment on vérifie. La date d'exploration est la seule ligne qui date le verdict. Tout ce qui a été exploré avant votre correctif décrit un passé.
Le piège. Le test en direct. Il s'annonce sous son propre user agent, Google-InspectionTool, qui peut recevoir un autre HTML que Googlebot. Un test live vert ne prouve donc rien sur ce que Googlebot reçoit. C'est exactement le faux négatif que cette méthode existe pour attraper.
Quand deux lectures sont possibles
Sur une URL donnée, une seule comparaison tranche : position de la balise contre position de </head>. Plus petit, rien à faire. Plus grand, il y a quelque chose à corriger.
Quand plusieurs balises sortent du <head>, traiter dans cet ordre. canonical d'abord, parce qu'il décide quelle URL est indexée. hreflang ensuite, parce qu'il ne fonctionne que par paires réciproques et qu'une seule extrémité cassée suffit à annuler le lien. <title> en dernier, Google sait le remplacer par le sien.
Ne relancez pas de validation dans la Search Console tant que la date de dernière exploration est antérieure à votre correctif. Google rejugerait sur sa vieille copie, et l'échec vous coûte plusieurs semaines d'attente avant le prochain essai.
La checklist
- La réponse en user agent Googlebot contient le contenu de la page, pas un challenge
- Le code est 200, et l'adresse qui a répondu est bien celle qui a été demandée
</head>est trouvé une fois et une seulecanonicalest avant</head>, et il pointe sur l'URL testée elle-même- Chaque
hreflangest avant</head>, et la page cible déclare le lien inverse - Le contre-test en user agent navigateur a été fait, et l'écart est compris
- Le test porte sur la production, pas sur une préproduction ni sur un build local
- Au moins une page de chaque gabarit est passée : accueil, page de liste, page de détail, page traduite
- La date de dernière exploration dans la Search Console est postérieure au correctif
Les limites de la méthode
Elle ne dit pas pourquoi. Elle mesure une position dans un flux d'octets. La cause peut être un framework qui streame ses métadonnées, un worker en périphérie, un cache qui sert une variante, une balise injectée trop tard. Le diagnostic commence là où la méthode s'arrête.
Elle ne juge pas la valeur de votre canonique. Une balise correctement placée et correctement formée peut quand même être écartée par Google au profit d'une autre URL du groupe.
Elle ne promet aucun effet sur les positions ni sur l'indexation. Remettre une canonique dans le <head> répare un défaut technique. Une page peut très bien rester non indexée après, pour des raisons qui n'ont rien à voir (nous les détaillons dans Détectée, actuellement non indexée : que faire ?). L'auteur en a un cas dans son exemple, et il n'avait pas bougé depuis trois semaines au moment de la publication.
Elle lit le HTML brut, avant JavaScript. C'est délibéré : une balise canonical hors du <head> n'est pas prise en compte, qu'elle se trouve dans la source ou qu'elle y arrive au rendu.
Elle mesure des octets, pas des caractères. Sur une page accentuée, les nombres ne correspondent à aucune position visible dans un éditeur, et ils changent à chaque build. Seul leur ordre relatif veut dire quelque chose.
Elle ne couvre que quatre balises. Open Graph, meta robots, données structurées : même frontière, même méthode, à ajouter vous-même si votre sujet est là.
Un WAF peut la fausser. Si votre hébergeur traite l'user agent Googlebot autrement que les autres, ou le challenge, vous mesurez cette réponse-là. Le signe est un fichier anormalement court à l'étape 01.
Notre exécution et son résultat
Nous exécutons chaque contribution avant de la publier, sur un cas qui n'est pas celui de son auteur. Ici : les 58 URL du sitemap de markentiq.com, les six étapes, et l'étape 06 en Search Console sur ces mêmes 58 URL.
Verdict : recevable. 58 URL sur 58 conformes, canonical et <title> avant la fermeture du <head>, aucun hreflang déclaré, ce qui est normal pour un site monolingue. Le contre-test en user agent navigateur a porté sur quatre gabarits, dont notre seule page dynamique : aucun écart, octet pour octet.
Le kit a été lu ligne par ligne avant exécution, puis lancé dans un conteneur isolé. Un seul appel réseau vers l'URL fournie, un fichier temporaire par requête supprimé aussitôt, aucune commande destructive, aucun envoi vers un tiers.
Nous avons fabriqué deux défauts pour éprouver la méthode, sur un serveur monté pour l'occasion : une page avec sa canonique après </head>, et une page servant deux HTML selon l'user agent. La méthode attrape les deux, et nomme le second explicitement.
Notre première passe a rendu six échecs qui n'en étaient pas. Les six pages répondent 200 au deuxième essai : c'était le réseau de notre machine d'exécution. Rejouée depuis un autre poste, la même commande donne 58 URL et zéro échec. Limite du kit : en mode sitemap, une requête qui n'aboutissait pas comptait comme un défaut, sans distinction ni réessai. Corrigée en version 1.2, avec une seconde tentative et un état ERR distinct.
Et un contrôle que le kit ne faisait pas. La checklist demande que la canonique pointe sur l'URL testée elle-même ; le script ne comparait que des positions, jamais des valeurs. Contrôle fait à la main sur les 58 URL : 58 canoniques auto-référentes. Le kit publié ici le fait désormais seul : c'est la première des six corrections de la version 1.2 ; la cinquième répare un effet de bord introduit par nos quatre premières.
Ce que l'étape 06 a trouvé, et que nous ne cherchions pas. Sur nos 58 URL, 57 sont indexées avec leur canonique reconnue. La dernière, notre méthode de prospection sous garde, est « Explorée, actuellement non indexée ». Google l'a explorée le 7 septembre (récupération réussie, exploration autorisée) et a choisi de ne pas l'indexer. Le contrôle de head y passe : canonique à l'octet 717 pour un </head> à 5615.
C'est exactement la réserve de l'auteur, vérifiée ailleurs que chez lui. Il a gardé dans son exemple une page corrigée, confirmée par Google et toujours pas indexée, en écrivant que la retirer ferait de sa méthode une promesse de résultat.
Et la méthode a mis en défaut la page que vous lisez. Lancé sur cette page une fois publiée, le kit a rendu FAIL : « hreflang à l'octet 16064, après </head> ». Il n'y a aucune balise hreflang ici : le kit avait trouvé le mot, dans la commande grep -abo 'hreflang=' de l'étape 03. Les motifs exigent maintenant un <link : c'est la sixième correction, la seconde trouvée en exécutant plutôt qu'en relisant.
Ce que cette exécution ne dit pas. Nous n'avons rencontré aucun site en production présentant le défaut d'origine : nous l'avons reproduit en laboratoire. Et notre site est statique : par construction, la méthode avait peu de chances d'y trouver quelque chose.
Seconde exécution, le 10/09/2026 : la méthode revient corrigée par son auteur
Victor Auffray a rejoué les six corrections sur son propre site avant de répondre, puis a livré une version 1.3 qui les porte et en corrige trois de plus, dont deux introduites par les nôtres. Nous les avons rejouées à notre tour sur neuf pages fabriquées, une par défaut : les trois tiennent.
1. Notre correction sur <link avait un angle mort. Une balise coupée sur plusieurs lignes, ce que fait n'importe quel formateur de code, échappe à un motif qui exige <link[^>]*rel= sur une seule ligne. Le faux positif que nous avions supprimé revenait en faux négatif, plus silencieux : la page passait de OK à « canonique absente ». Vérifié : sur une page dont la balise tient sur trois lignes, la 1.2 annonce « absent », la 1.3 la trouve. Elle remplace d'abord les retours à la ligne par des espaces, un octet pour un octet, ce qui laisse les positions exactes.
2. Notre comparaison de canonique portait sur la mauvaise adresse. Elle comparait à l'URL demandée, pas à celle qui a répondu : toute URL de sitemap qui redirige devenait un échec, alors que sa canonique est correcte à l'arrivée. Vérifié : sur une page qui redirige, la 1.2 rend FAIL, la 1.3 imprime la redirection et conclut sur l'arrivée. Nos 58 URL ne redirigent pas, nous ne pouvions pas le voir ; il a dix-huit redirections dans son sitemap.
3. Le code HTTP n'était pas regardé, et la « soft 404 » passait au travers. Une 404 vide n'a ni titre ni canonique et tombe d'elle-même ; une page d'erreur qui répond 404 mais sert un <head> complet avait tout ce que le script cherchait et sortait conforme. Vérifié : sur une soft 404, la 1.2 sort en OK et en code 0, la 1.3 lit le code et échoue. Cette page annonçait le contraire le 09/09, sur la foi d'un essai fait sur une 404 vide ; la phrase est réécrite. La règle transposable : un vérificateur de <head> qui ne regarde pas le code de réponse rend un verdict sur une page qui n'existe pas.
Un quatrième défaut, que personne n'avait vu. En le rejouant, nous avons trouvé que la 1.2 mettait aussi en échec toute canonique écrite en relatif, href="/page", faute de la résoudre avant comparaison. Nos 58 URL portent des canoniques absolues, le défaut ne pouvait pas se voir ici. La 1.3 le corrige au passage, sans que son auteur l'ait cherché.
Le point où les deux lectures se rejoignent, et la version 1.4
Une question restait ouverte : en mode sitemap, que faire d'une URL qu'on n'a pas pu lire ? La version 1.2 mettait la passe en échec : une page que personne n'a pu lire n'est pas une page qui passe. La 1.3 ne changeait plus le code de sortie : une coupure réseau n'est pas un défaut de la page. Les deux constats sont justes, et il n'y avait pas à en sacrifier un.
La 1.4 les tient ensemble par un contrôle plutôt que par un arbitrage. Une page qui ne répond pas sort en ERR, jamais en FAIL. En fin de passe, les URL restées illisibles sont rebalayées une fois de plus : ce qui répond rentre dans le décompte ; ce qui ne répond toujours pas laisse la passe incomplète. Le script le signale par un code de sortie propre et la consigne de rejouer. Éprouvé sur un serveur qui échoue aux deux premières requêtes puis répond : la passe se termine proprement, sans intervention. Les six faux échecs de notre exécution du 09/09 se seraient rattrapés tout seuls.
La 1.4 porte aussi trois correctifs de portabilité et de lisibilité, décrits sur la page du kit. Ces quatre ajouts sont écrits par MarkenTIQ et soumis à l'auteur : l'empreinte de sa version 1.3 est publiée à côté, pour que l'écart reste vérifiable.
Ce que ce va-et-vient enseigne, et c'est la raison d'être du dispositif. Nos six corrections avaient été relues, rejouées sur des défauts fabriqués, et publiées avec leurs mesures. Deux étaient fausses, et aucune relecture ne pouvait le montrer : nos défauts fabriqués étaient tirés de notre propre site, statique, monolingue, sans redirection et à canoniques absolues. Il a fallu un second site, avec ses dix-huit redirections, pour les voir. Un outil ne se durcit pas en étant relu, il se durcit en étant exécuté ailleurs.
L'exemple, avant de vous lancer
L'exemple est un cas réel, pas une reconstitution : celui de tech-everywhere.fr, le site de l'auteur, huit URL déclarées sans canonique par Google alors que le code en déclarait une. Vous y verrez la sortie du kit sur la page en défaut, la cause exacte, le correctif horodaté, la confirmation par Google une heure plus tard, et ce que trois semaines de recul ont donné, y compris la page toujours pas indexée.
Votre retour compte
Vous avez fait tourner cette méthode ? Racontez-nous ce qui a marché et ce qui a coincé : chaque retour améliore la version suivante, et il est transmis à son auteur. Le formulaire est ouvert aux personnes qui ont déjà reçu un pack, avec la même adresse ; l'email marche aussi : contact@markentiq.com.
Cette page vous a servi ? Partagez-la sur LinkedIn. Pour retrouver nos publications dans vos résultats Google, ajoutez MarkenTIQ à vos sources préférées.