Un site entier sans canonique, et une Search Console qui disait le contraire
Huit URL déclarées « sans URL canonique sélectionnée par l'utilisateur » par le rapport d'indexation, alors que le code en déclarait une et que le test d'URL en direct la voyait. Neuf jours perdus à croire le verdict périmé. Puis deux commandes, et la réponse : le serveur envoyait deux HTML différents pour la même adresse.
Tout ce qui suit est de Victor Auffray, Tech Everywhere · LinkedIn, à la première personne, sur son propre site. Nous le publions dans sa voix, sans le réécrire : ni les mesures, ni les réserves, ni la fin qui ne tourne pas bien. Ce que la méthode a donné chez nous, sur un autre site, est dans le compte rendu d'exécution de la page méthode.
Ce que cet exemple montre, et ce qu'il ne montre pas. Il montre qu'une contradiction entre deux outils Google sur la même page peut venir d'un serveur qui répond deux choses différentes, et que deux commandes suffisent à le prouver. Il ne montre pas qu'un correctif fait indexer une page : la page d'accueil anglaise est toujours non indexée trois semaines après, et l'auteur l'a laissée dans son compte rendu pour cette raison.
Ce qui est mesuré, et ce qui est reproduit.
Les positions en octets ont été mesurées le 8 septembre 2026 avec les commandes de la méthode, sur la production. Les dates d'exploration et les motifs de non-indexation viennent des rapports de la Search Console de la propriété.
Une réserve, tout de suite. « Je n'ai pas gardé les fichiers HTML capturés en août, avant le correctif. Les chiffres “avant” que vous allez lire sont donc reproduits par le contre-test en user agent navigateur, qui reçoit aujourd'hui exactement ce que Googlebot recevait alors. Le mécanisme est le même, et il est toujours actif pour les navigateurs. »
La sortie du kit sur /en, le 8 septembre 2026.
https://tech-everywhere.fr/en
googlebot </head> at byte 4281
title byte 1834 in head
canonical byte 2548 in head
hreflang byte 2624 in head
browser </head> at byte 1920
title byte 236959 AFTER </head>
canonical byte 237673 AFTER </head>
hreflang byte 237749 AFTER </head>
the two user agents get different HTML. Googlebot is the one that counts.
Deux HTML pour une seule adresse. Le premier a sa canonique 1 733 octets avant la fermeture du <head>. Le second l'a 235 753 octets après. C'est le second que Googlebot recevait jusqu'au 17 août 2026.
Google dit qu'il n'y a pas de canonique. Le code en déclare une.
Le rapport d'indexation listait 8 URL sous « Page en double sans URL canonique sélectionnée par l'utilisateur », dont 6 articles anglais en /en/news/. Google disait ne trouver aucune canonique déclarée sur ces pages.
Sauf que le code en déclarait une. Et le test d'URL en direct de la Search Console la voyait, sur chacune des 6. Neuf jours passés à croire que le verdict de Google était périmé et qu'un nouveau passage suffirait. Une validation relancée sur cette base. Elle a échoué.
Deux commandes, et un écart de 235 ko.
La page demandée en user agent Googlebot, la même en user agent navigateur, et la position de rel="canonical" comparée à celle de </head> dans les deux réponses. Le résultat est celui du bloc de l'étape 01. Le serveur envoyait bien une canonique aux navigateurs, dans le <body>, à 235 ko de l'endroit où Google la lit.
La cause est dans Next.js depuis la version 15.2. Le framework streame les métadonnées de son API Metadata, title, canonical, hreflang et Open Graph, après </head>. Il l'assume pour les robots qui exécutent le JavaScript, et sa liste par défaut range Googlebot dans cette catégorie.
La liste par défaut contient Google-InspectionTool, l'user agent du test en direct de la Search Console. Ce test recevait donc les métadonnées dans le <head> et passait au vert, pendant que Googlebot recevait l'autre version. Même URL, deux HTML, deux verdicts, et les deux outils avaient raison.
Une ligne de configuration, et une dette de maintenance.
Une option htmlLimitedBots, avec la liste par défaut de Next recopiée telle quelle et Googlebot ajouté devant. La valeur remplace la regex par défaut, elle ne s'y ajoute pas : il faut donc recopier la source depuis next/dist/shared/lib/router/utils/html-bots.js, et la revérifier à chaque montée de version. Commit 6b1131e, déployé à 10h33.
L'étape 06 de la méthode, la seule qui compte vraiment.
Inspection de /en/news/best-shopify-apps dans la Search Console : dernière exploration par Googlebot smartphone le 17 août à 11h43, soit 1 heure et 10 minutes après le déploiement. Ligne « URL canonique déclarée par l'utilisateur » : l'URL de la page, au lieu de « Aucun ». Le correctif était validé de l'extérieur, pas seulement en local.
Six gabarits, puis le sitemap.
Le 7 septembre, la méthode a été repassée sur 6 gabarits différents : accueil française, accueil anglaise, page de liste d'articles, article français, article anglais, page de ville. Les quatre balises tombent dans le <head> sur les 6, avec des canoniques entre les octets 2 355 et 3 343 pour des </head> entre 4 120 et 5 709.
Le mode sitemap donne la même chose. Les 8 premières URL déclarées :
OK https://tech-everywhere.fr canonical 2569 < </head> 4338 OK https://tech-everywhere.fr/actualites canonical 2378 < </head> 4185 OK https://tech-everywhere.fr/legal canonical 2422 < </head> 4215 OK https://tech-everywhere.fr/privacy canonical 2424 < </head> 4225 OK https://tech-everywhere.fr/en canonical 2548 < </head> 4281 OK https://tech-everywhere.fr/en/news canonical 2355 < </head> 4120 OK https://tech-everywhere.fr/en/legal canonical 2401 < </head> 4158 OK https://tech-everywhere.fr/en/privacy canonical 2403 < </head> 4168 8 URL(s) checked, 0 failed
Moins glorieux que la partie technique.
Le motif « Page en double sans URL canonique sélectionnée » est retombé. Au 7 septembre il ne reste que 2 URL dedans, et ce ne sont plus des articles : deux vestiges en www., explorés pour la dernière fois les 20 mai et 4 juin 2026, dont le correctif date de juin et n'a rien à voir avec celui-ci.
Les articles anglais ont basculé vers un autre motif, « Page en double : Google n'a pas choisi la même URL canonique que l'utilisateur ». Google lit maintenant la canonique. Il n'est pas d'accord avec elle. C'est une progression dans son pipeline, et c'est un autre chantier.
Le point qui refroidit. /en est toujours dans « Explorée, actuellement non indexée », avec une dernière exploration du 4 septembre 2026. Trois semaines après le correctif, Google re-crawle la page avec sa canonique bien placée, et ne l'indexe toujours pas.
Le site est passé de 97 pages indexées le 7 juillet à 148 le 7 septembre. « Je n'attribue pas cet écart au correctif : j'ai publié des articles et corrigé des redirections dans le même intervalle, et je n'ai aucun moyen de séparer les effets. »
Trois choses, et pas une de plus.
- Que la contradiction entre deux outils Google sur la même page peut venir d'un serveur qui répond deux choses différentes, et que deux commandes suffisent à le prouver.
- Que le test d'URL en direct ne certifie pas ce que Googlebot reçoit. Sur ce point, neuf jours perdus sont plus convaincants qu'une démonstration.
- Que la date de dernière exploration est la seule ligne qui date un verdict. Tout ce que la Search Console affiche à côté décrit l'état du site au moment du passage, pas celui d'aujourd'hui.
Quatre limites, déclarées par l'auteur.
Il ne montre pas que le correctif fait indexer une page. /en est la preuve du contraire, et elle est laissée dans le compte rendu pour cette raison.
Il ne montre pas que ce défaut est fréquent. Un site, le sien, dans une configuration précise : Next.js 15.2 ou plus, API Metadata, aucune option htmlLimitedBots. Aucune mesure sur la proportion de sites concernés, et aucune inventée.
Il ne montre rien sur les autres frameworks. Le mécanisme de la méthode est indifférent à la pile technique, la cause décrite ici ne l'est pas du tout.
Il ne dit rien de l'ampleur du dommage pendant la période aveugle. Entre le déploiement de la version 15.2 et le 17 août, les pages ont été explorées sans canonique. Combien de temps exactement, et avec quelle conséquence sur les positions : inconnu, et les données de la Search Console ne permettent pas de le reconstituer.
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.
Le même contrôle, sur votre site : cinq minutes et deux commandes.
La méthode détaille les six étapes, avec ce qu'on vérifie et le piège de chacune, les règles de décision quand plusieurs balises sortent du <head>, la checklist, et le compte rendu de notre propre exécution sur 58 URL. Le kit de l'auteur enchaîne les six étapes en un appel, et reste facultatif.
Une question sur la méthode, un retour d'usage à partager ? Écrivez-nous : contact@markentiq.com