Googlebot n'a que faire de vos resource hints
Gary Illyes a récemment confirmé ce que beaucoup soupçonnaient sans preuve formelle : Googlebot ignore purement et simplement les resource hints (preconnect, prefetch, preload, dns-prefetch, prerender). Dans la même prise de parole, il a rappelé que la validité HTML n'est pas un facteur de classement. Deux clarifications qui méritent bien plus qu'un résumé — elles remettent en question des pratiques d'optimisation technique répandues dans l'écosystème SEO.
Décortiquons pourquoi c'est le cas d'un point de vue architectural, ce que ça change concrètement pour vos stratégies de crawl, et surtout ce que vous devriez faire à la place si votre objectif est d'influencer le comportement de Googlebot sur un site de plusieurs milliers de pages.
Ce que sont les resource hints — et ce qu'ils ne sont pas
Les resource hints sont des directives destinées au navigateur client pour anticiper le chargement de ressources. Ils existent sous forme de balises <link> dans le <head> ou d'en-têtes HTTP Link.
<!-- DNS prefetch : résoudre le DNS d'un domaine tiers avant d'en avoir besoin -->
<link rel="dns-prefetch" href="https://cdn.shopify-media.com">
<!-- Preconnect : DNS + TCP + TLS handshake anticipé -->
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
<!-- Prefetch : télécharger une ressource en basse priorité pour navigation future -->
<link rel="prefetch" href="/api/product-recommendations.json">
<!-- Preload : télécharger une ressource critique pour la page courante, haute priorité -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<!-- Prerender (Speculation Rules API) : rendre une page entière en avance -->
<link rel="prerender" href="/checkout/step-2">Ces directives sont des optimisations de performance côté client. Elles permettent au navigateur Chrome, Firefox ou Safari d'anticiper des connexions réseau ou des téléchargements pour réduire la latence perçue par l'utilisateur. Leur spécification est maintenue par le W3C dans le Resource Hints Working Draft.
Pourquoi Googlebot les ignore : une question d'architecture
Googlebot n'est pas Chrome. Ou plus précisément : Googlebot utilise une version headless de Chrome (WRS — Web Rendering Service), mais son comportement de crawl est découplé du comportement de navigation d'un utilisateur.
Le crawler de Google fonctionne en deux phases distinctes :
-
Crawl : Googlebot télécharge le HTML brut. À ce stade, il extrait les liens (
<a href>), les directives (robots,canonical,hreflang), et les métadonnées. Les resource hints ne contiennent pas de sémantique exploitable pour l'indexation. -
Rendering : WRS exécute le JavaScript et produit le DOM final. Même à cette étape, les resource hints sont des instructions d'optimisation réseau — elles ne modifient pas le contenu du DOM ni la structure des liens.
Du point de vue de Google, un <link rel="prefetch" href="/page-b"> n'est pas un lien. Ce n'est pas une indication que /page-b existe ou devrait être crawlée. C'est une instruction au navigateur pour optimiser la performance. Googlebot n'a aucune raison de l'interpréter autrement.
Cela signifie concrètement que si vous avez des pages orphelines que vous espériez faire découvrir via prefetch ou prerender, Googlebot ne les verra jamais par ce canal.
Le cas particulier de la Speculation Rules API
La Speculation Rules API (qui remplace <link rel="prerender">) est encore plus explicite sur ce point. Cette API est conçue exclusivement pour Chrome et utilise un JSON inline :
<script type="speculationrules">
{
"prerender": [
{
"where": {
"href_matches": "/products/*"
},
"eagerness": "moderate"
}
],
"prefetch": [
{
"urls": ["/cart", "/checkout"],
"eagerness": "conservative"
}
]
}
</script>Ce bloc speculationrules est un mécanisme purement client. Googlebot ne l'exécute pas pour décider quelles pages crawler. Les URLs listées dans les règles de spéculation ne sont pas traitées comme des liens découvrables. Si /cart n'apparaît nulle part dans un <a href>, un sitemap, ou un autre signal de découverte, Googlebot ne la crawlera pas simplement parce qu'elle figure dans vos speculation rules.
Validité HTML et classement : la clarification nécessaire
Gary Illyes a ajouté que la validité HTML n'est pas un facteur de classement. Cette affirmation est cohérente avec la position historique de Google, mais elle mérite un examen nuancé.
Ce que Google tolère réellement
Le parser HTML de Chrome (et donc de WRS) est extrêmement tolérant. Il implémente la spécification HTML du WHATWG, qui définit des algorithmes de correction d'erreurs pour pratiquement tous les cas de HTML malformé.
Un document comme celui-ci sera interprété correctement :
<!DOCTYPE html>
<html>
<head>
<title>Fiche produit - Chaussures running trail</title>
<meta name=description content="Chaussures trail imperméables, semelle Vibram, drop 8mm">
<link rel=canonical href=https://shop.example.fr/chaussures/trail-waterproof-v3>
</head>
<body>
<h1>Trail Waterproof V3</h1>
<p>Prix : 129,90 €
<div class="specs">
<p>Poids : 285g
<p>Drop : 8mm
</div>Les guillemets manquants autour des attributs, les balises <p> non fermées, l'absence de </body> et </html> — tout cela est parfaitement géré par le parser. Google indexera cette page sans problème.
Où la validité HTML impacte indirectement le SEO
L'affirmation de Gary Illyes est précise : la validité HTML en tant que signal direct n'entre pas dans l'algorithme de classement. Mais un HTML sévèrement malformé peut avoir des conséquences indirectes bien réelles :
1. Balises meta tronquées ou mal interprétées. Si votre <meta name="robots" content="noindex"> se retrouve dans le <body> à cause d'une erreur de structure du <head>, Chrome la traitera quand même, mais le comportement n'est plus garanti selon les cas. Une balise <meta> placée après un élément block (un <div> qui se glisse dans le <head> par erreur) provoquera la fermeture implicite du <head> par le parser.
2. Structured data cassées. Un JSON-LD mal échappé ou un microdata avec des balises imbriquées incorrectement sera ignoré par le Rich Results parser. Le HTML peut être « valide au sens du parser » mais produire un DOM inattendu qui casse vos données structurées.
3. Impact sur le rendering JavaScript. Un framework comme React ou Vue s'attend à un DOM initial précis pour l'hydration. Un HTML invalide qui produit un DOM différent de celui attendu côté serveur génère des hydration mismatches qui peuvent casser le rendu final vu par Googlebot.
La recommandation pragmatique : ne cherchez pas la validation W3C parfaite, mais assurez-vous que votre HTML produit le DOM attendu. L'outil de test reste Chrome DevTools > Elements : si le DOM affiché correspond à votre intention, c'est suffisant.
Ce qui influence réellement le comportement de crawl de Googlebot
Si les resource hints sont hors-jeu, quels sont les leviers réels pour influencer la façon dont Googlebot parcourt votre site ? Voici les mécanismes qui fonctionnent, classés par ordre d'impact.
Liens internes <a href> : le signal fondamental
Le lien hypertexte standard reste le mécanisme principal de découverte. Googlebot suit les <a href> présents dans le DOM rendu. Pas les onclick, pas les window.location, pas les router.push() sans ancre correspondante.
Pour un e-commerce de 18 000 pages produit, la structure de maillage interne détermine directement la profondeur de crawl. Un produit accessible en 2 clics depuis la homepage sera crawlé plus fréquemment qu'un produit enfoui à 6 niveaux de navigation.
Vérifiez votre maillage avec Screaming Frog : lancez un crawl en mode « JavaScript rendering » pour capturer le DOM rendu, puis analysez la colonne « Crawl Depth ». Si des pages stratégiques apparaissent à une profondeur supérieure à 4, restructurez votre navigation.
Sitemap XML : le filet de sécurité
Le sitemap ne remplace pas le maillage interne, mais il complète la découverte. Google l'utilise comme signal additionnel, particulièrement pour les pages nouvellement créées ou les pages à faible maillage.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://shop.example.fr/chaussures/trail-waterproof-v3</loc>
<lastmod>2026-02-25</lastmod>
<changefreq>weekly</changefreq>
<priority>0.8</priority>
</url>
<!-- 17 999 autres URLs -->
</urlset>Point important : Google a confirmé dans sa documentation officielle que <changefreq> et <priority> sont largement ignorés. Le signal utile est <lastmod>, à condition qu'il reflète une modification réelle du contenu. Si vous mettez à jour <lastmod> sans changement substantiel, Google finira par ignorer cette donnée pour votre domaine.
robots.txt et gestion du crawl budget
Pour un site de 18 000 pages dont seulement 12 000 sont pertinentes pour l'indexation, le robots.txt est votre outil de priorisation du crawl budget. Bloquez les facettes non pertinentes, les pages de résultats de recherche interne, et les filtres combinatoires.
# robots.txt pour un e-commerce avec filtres à facettes
User-agent: Googlebot
Disallow: /search?
Disallow: /filter/
Disallow: /products?sort=
Disallow: /products?color=*&size=*&brand=*
Allow: /products?category=
# Sitemap
Sitemap: https://shop.example.fr/sitemap-index.xmlAttention au piège classique : Disallow empêche le crawl mais pas l'indexation. Si des pages bloquées par robots.txt reçoivent des backlinks, Google peut les indexer sans les crawler (titre et description générés à partir des ancres de liens). Utilisez noindex via la balise meta robots pour les pages que vous voulez désindexer, et Disallow pour celles que vous voulez simplement soustraire au crawl.
En-têtes HTTP et réponses serveur
La vitesse de réponse de votre serveur influence directement le crawl rate. Google ajuste dynamiquement sa vitesse de crawl en fonction de la réactivité du serveur. Un TTFB moyen de 2,5 secondes sur vos pages catégories réduira mécaniquement le nombre de pages crawlées par session.
Surveillez le rapport « Statistiques de l'exploration » dans Google Search Console. Si vous voyez le temps de réponse moyen dépasser 800ms, vous avez un problème de crawl budget avant même de parler de resource hints.
Scénario concret : migration d'un média de 25 000 articles
Prenons un site média avec 25 000 articles, migrant d'une architecture Angular SPA vers Next.js avec SSR. L'équipe technique avait implémenté des prefetch et preconnect agressifs dans le <head> pour améliorer les Core Web Vitals côté utilisateur — ce qui est une bonne pratique UX. Mais ils avaient aussi ajouté des <link rel="prefetch"> vers les articles recommandés en croyant faciliter leur découverte par Googlebot.
Le diagnostic
Après la migration, l'équipe constate dans Search Console que 8 000 articles restent dans l'état « Discovered – currently not indexed » après 6 semaines. Le crawl rate est passé de 4 200 pages/jour à 1 800 pages/jour.
L'analyse avec Screaming Frog en mode JS rendering révèle :
-
Les articles recommandés sont chargés via un composant React qui utilise
useEffectpour fetcher une API, puis affiche les liens dans un carousel. Googlebot voit les<link rel="prefetch">dans le<head>, mais pas les<a href>correspondants, car le composant ne rend les liens qu'après un appel API qui échoue silencieusement lors du rendering par WRS (timeout de l'API interne à 5 secondes, WRS attend ~5s max pour le rendering). -
Le SSR est fonctionnel pour le contenu principal de l'article, mais le bloc de recommandations est rendu côté client uniquement.
-
8 000 articles orphelins n'ont comme seul lien entrant que les
prefetchhints — invisibles pour Googlebot.
La résolution
L'équipe apporte trois modifications :
1. Server-side rendering du bloc de recommandations. Les articles liés sont maintenant résolus côté serveur via getServerSideProps et rendus dans le HTML initial comme des <a href> standards :
// pages/articles/[slug].tsx
export const getServerSideProps: GetServerSideProps = async (context) => {
const { slug } = context.params!;
const article = await getArticle(slug);
// Résoudre les recommandations côté serveur
// au lieu de les laisser au client
const recommendations = await getRecommendations(slug, {
limit: 6,
timeout: 2000, // Timeout court pour ne pas pénaliser le TTFB
fallback: article.categoryTopArticles // Fallback statique si l'API est lente
});
return {
props: {
article,
recommendations
}
};
};
// Composant de recommandations
function ArticleRecommendations({ recommendations }: { recommendations: Article[] }) {
return (
<nav aria-label="Articles recommandés">
<h2>À lire aussi</h2>
<ul>
{recommendations.map((rec) => (
<li key={rec.slug}>
{/* Lien standard <a href> — visible par Googlebot */}
<a href={`/articles/${rec.slug}`}>
{rec.title}
</a>
</li>
))}
</ul>
</nav>
);
}2. Conservation des resource hints pour les vrais utilisateurs. Les preconnect et prefetch restent en place pour la performance client. Ils n'interfèrent pas avec le SEO — ils l'ignorent simplement. L'équipe garde le meilleur des deux mondes.
3. Soumission d'un sitemap segmenté. Au lieu d'un seul sitemap de 25 000 URLs, l'équipe crée des sitemaps par catégorie avec des <lastmod> précis, soumis via l'API Search Console :
# Générer et soumettre les sitemaps segmentés
curl -X PUT \
"https://www.googleapis.com/webmasters/v3/sites/https%3A%2F%2Fmedia.example.fr/sitemaps/https%3A%2F%2Fmedia.example.fr%2Fsitemaps%2Fpolitique.xml" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json"Le résultat
Trois semaines après les corrections :
- Le crawl rate remonte à 5 100 pages/jour (supérieur au pré-migration grâce à un TTFB amélioré par Next.js SSR).
- Les articles « Discovered – currently not indexed » passent de 8 000 à 1 200 (les 1 200 restants étant des articles très anciens à faible valeur).
- Le maillage interne moyen passe d'un crawl depth de 5,2 à 3,1 grâce aux blocs de recommandations rendus côté serveur.
Ce cas illustre parfaitement le propos de Gary Illyes : les resource hints n'ont jamais été un canal de découverte pour Googlebot. Les vrais leviers sont le HTML rendu côté serveur, les liens <a href> standards, et la structure du maillage.
Comment auditer et détecter ces problèmes
L'écart entre ce que voit un navigateur utilisateur et ce que voit Googlebot est la source de la majorité des problèmes de crawl. Voici une méthode d'audit systématique.
Étape 1 : comparer le DOM navigateur vs. DOM Googlebot
Utilisez l'outil d'inspection d'URL dans Search Console pour obtenir le HTML rendu tel que Google le voit. Comparez-le avec le DOM de Chrome DevTools. Pour chaque page critique, vérifiez que les blocs de liens (navigation, recommandations, pagination, fil d'ariane) sont présents dans les deux versions.
Pour aller plus loin, vous pouvez tester systématiquement ce que Google voit sur vos templates principaux.
Étape 2 : identifier les pages orphelines
Dans Screaming Frog, croisez les données de crawl avec les données de la Search Console (via l'intégration API). Les pages qui apparaissent dans le sitemap ou dans Search Console mais qui ne sont pas atteintes par le crawl Screaming Frog depuis la homepage sont potentiellement orphelines.
Si ces pages n'ont comme liens entrants que des prefetch ou des prerender hints, elles sont de facto invisibles pour Googlebot.
Étape 3 : monitorer les régressions
Une refonte de composant, une mise à jour de framework, un changement de logique de rendu — tout cela peut transformer silencieusement des <a href> en liens dynamiques invisibles au crawl. Un outil de monitoring continu comme SEOGard détecte ces régressions dès qu'elles se produisent, en comparant le DOM rendu entre deux crawls successifs et en alertant quand des liens sortent du HTML initial.
Le problème des audits manuels est leur fréquence : un audit trimestriel ne captera pas un déploiement du mardi qui casse le rendering du bloc de navigation catégorie. Le monitoring automatisé comble ce gap.
Resource hints : gardez-les, mais pour les bonnes raisons
Les resource hints ne sont pas inutiles — ils sont inutiles pour le SEO. Pour la performance utilisateur, ils restent des outils puissants et recommandés par Google lui-même sur web.dev.
Le preconnect vers vos CDN tiers réduit le LCP. Le prefetch des pages de navigation probable améliore l'INP perçu. La Speculation Rules API peut rendre la navigation quasi-instantanée sur Chrome. Ces optimisations ont un impact sur les Core Web Vitals, qui eux sont un signal de classement (même si son poids reste modeste).
Le piège est de confondre les deux niveaux. Optimisez vos resource hints pour vos utilisateurs. Optimisez votre maillage interne, vos sitemaps et votre structure de rendu pour Googlebot. Ce sont deux systèmes indépendants qui coexistent dans le même HTML mais qui servent des audiences fondamentalement différentes.
Ce qu'il faut retenir
La clarification de Gary Illyes n'est pas une surprise technique — c'est une confirmation officielle qui devrait mettre fin à un mythe persistant. Googlebot découvre vos pages via les liens <a href> dans le DOM rendu et via vos sitemaps. Tout le reste — resource hints, JavaScript router.push, liens dans des attributs data-* — est invisible pour le crawler.
Si vous gérez un site de plusieurs milliers de pages, auditez dès maintenant le gap entre vos resource hints et vos vrais liens HTML. Vous pourriez découvrir que des pans entiers de votre site dépendent d'un canal de découverte que Googlebot n'a jamais emprunté. Et pour éviter que ce type de régression silencieuse ne se reproduise après chaque déploiement, un monitoring automatisé du DOM rendu reste la seule approche viable à l'échelle.