Le screenshot “Rendered” de l’inspection d’URL dans Google Search Console a un talent particulier : il te fait perdre du temps. Tu vois une mise en page éclatée, des blocs qui se chevauchent, une police par défaut, parfois même une page à moitié vide. Et tu te demandes si Google est en train d’indexer “ça”.
La réalité est plus tordue. Le rendu GSC n’est pas une capture “comme un utilisateur”. C’est une photo d’un pipeline (fetch → rendu → extraction), prise dans un contexte qui n’a pas forcément les mêmes ressources, les mêmes timings, ni la même exécution JS que ton Chrome local. Et surtout, un rendu moche ne dit pas grand-chose sur le point qui compte vraiment en SEO technique : est-ce que Google découvre, crawl et comprend tes URLs de façon fiable.
Ce que le test de rendu GSC fait réellement (et ce qu’il ne fait pas)
Dans l’Inspection d’URL, tu as typiquement deux angles : “vue explorée” (ce que Google a récupéré lors du crawl) et “test en direct” (une requête à l’instant T). Le rendu s’appuie sur le Web Rendering Service de Google, qui exécute une page comme un navigateur headless dans des contraintes contrôlées.
Ce que ça veut dire concrètement : Google récupère ton HTML, tente de charger les ressources (CSS, JS, images), exécute du JavaScript, puis te montre une capture. Derrière, il y a aussi une extraction du DOM et du contenu. Donc oui, c’est utile. Mais c’est un simulateur, pas une promesse, et encore moins un “certificat d’indexation”.
Gros piège : tu peux avoir un rendu qui “a l’air OK” et un site qui ne se fait pas découvrir, parce que les liens sont non crawlables. Et tu peux avoir un rendu visuellement cassé alors que le contenu et les liens importants sont bien présents dans l’HTML/DOM, donc indexables.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Pourquoi le rendu est “cassé” alors que ton site va bien
Quand GSC affiche une page bizarre, ce n’est pas forcément ton layout qui est “incompatible Google”. C’est souvent une histoire de ressources qui n’arrivent pas, de conditions d’exécution différentes, ou d’éléments qui dépendent de signaux absents (cookies, géoloc, storage, consentement, etc.). Le screenshot devient une scène de crime, pas un verdict.
CSS, polices, bundles : la chaîne est aussi solide que son maillon le plus fragile
Le rendu peut partir en vrille si une feuille CSS critique est bloquée, si un bundle JS renvoie un 403/404, si un CDN sert une version différente au bot, ou si ton serveur fait du filtrage un peu “créatif” sur l’User-Agent. La conséquence visuelle est immédiate. Mais la conséquence SEO dépend de ce qui manque vraiment : si c’est juste de la cosmétique (police, grille), Google peut quand même extraire le contenu. Si c’est ton JS d’hydratation qui ne charge jamais, tu te retrouves avec un DOM vide, et là c’est une autre histoire.
Un classique moderne : les CSS sont chargées via du JS (ou injectées) et le moindre souci de chargement te laisse une page “non stylée”. Ça ressemble à un bug énorme, mais côté crawl, le vrai sujet est : est-ce que le contenu principal et les liens internes existent sans dépendre d’un miracle côté client.
Robots, auth, WAF, CSP : les blocages silencieux
Le rendu GSC peut aussi être “cassé” parce que Google n’a pas accès aux mêmes ressources que toi. Pas besoin d’imaginer un complot. Il suffit d’un CDN qui bloque certains pays, d’un WAF qui challenge des patterns, d’une règle qui refuse certains User-Agents, ou d’un serveur de statiques qui demande une auth (même involontaire, via un cookie absent).
Et puis il y a les blocages plus subtils : des scripts tagués “consent” qui ne s’exécutent que si un cookie est là, des assets sur un sous-domaine avec une policy CORS/CSP stricte, ou un robots.txt qui bloque un dossier d’assets “parce que c’est du /static/ donc osef”. Sauf que non : si tu bloques tes CSS/JS essentiels, tu compliques le rendu et parfois l’extraction.
Timeouts et hydratation : la page qui “existe” trop tard
Le Web Rendering Service n’attend pas ton app indéfiniment. Si ton rendu dépend de calls API lents, de retries, de gros bundles, ou d’une hydratation qui prend des secondes, tu peux te retrouver avec une capture prise “avant la fin”. Résultat : header ok, squelette ok, contenu principal absent, navigation incomplète. Visuellement, ça fait peur. Techniquement, ça ressemble à ce que Google a pu voir au moment où il a décidé de passer à autre chose.
On le voit souvent sur des SPA qui affichent un loader, puis remplissent toute la page après plusieurs appels. Pour un humain, c’est juste un site un peu lent. Pour un crawler, c’est potentiellement une page sans substance.
Le vrai piège : la navigation 100% JS et les liens qui ne sont pas des liens
Si je ne devais garder qu’un seul message : la plupart des problèmes “9 mois, toujours pas indexé” ne viennent pas d’un screenshot moche. Ils viennent de la découverte d’URLs. Google ne devine pas ton routing interne. Il suit des liens.
Et dans beaucoup d’apps modernes, on “navigue” avec des div cliquables, des handlers onClick, des boutons, des composants de router qui finissent par produire quelque chose qui marche pour un utilisateur… mais qui n’expose pas des <a href="..."> stables et crawlables dans le DOM initial.
Oui, Google exécute du JS. Non, tu ne dois pas parier ton indexation sur “Google cliquera partout et simulera mon app”. Le crawl web reste fondamentalement basé sur des URLs et des liens. Si tes pages de catégorie, de produit, d’article ne sont jamais découvertes via des liens HTML normaux ou un sitemap propre, tu peux attendre très longtemps.
Le symptôme SEO typique
Tu vois quelques pages indexées (souvent la home, parfois une ou deux routes “faciles”), mais la majorité ne bouge pas. Dans GSC, ça peut ressembler à des URLs “découvertes, actuellement non indexées”, ou carrément aucune trace parce qu’elles ne sont jamais découvertes. Et toi, tu reviens au screenshot rendu en boucle, comme si c’était la cause.
Non. Le screenshot est un indicateur. La cause fréquente, c’est l’absence de chemins de découverte fiables.
Ce que j’appelle un “vrai lien” en 2026
Un vrai lien, c’est un <a> avec un href vers une URL stable, en clair. Pas une navigation déclenchée uniquement par JS. Pas un composant qui oublie le href. Pas un bouton qui push une route en silence.
Tu peux avoir une SPA, du routing client, de la préfetch, tout ce que tu veux. Mais si tu veux être crawlable sans prier, expose des liens HTML. Quitte à intercepter le clic côté client pour garder une navigation “app-like”.
// Exemple React : SEO-friendly + SPA-friendly
function SmartLink({ to, children }) {
return (
<a
href={to}
onClick={(e) => {
// Laisse le comportement normal si ouverture nouvel onglet, etc.
if (e.metaKey || e.ctrlKey || e.shiftKey || e.altKey) return;
e.preventDefault();
window.history.pushState({}, "", to);
window.dispatchEvent(new PopStateEvent("popstate"));
}}
>
{children}
</a>
);
}Ce code n’est pas “la solution React universelle”, c’est juste l’idée : le href existe, l’URL est réelle, et ton app peut quand même gérer la navigation. Dans un framework (Next, Nuxt, Remix…), ça se fait proprement avec leurs composants de lien, tant qu’ils rendent bien un <a href> exploitable et que les routes existent serveur.
Rendre ton site crawlable : mon standard minimal (pragmatique)
Quand je veux dormir tranquille, je ne cherche pas “un rendu parfait”. Je cherche un socle. Un socle où Google peut découvrir les pages importantes, les crawler sans friction, et obtenir quelque chose d’exploitable même si le JS est capricieux.
D’abord, chaque URL importante doit répondre en 200 avec un HTML qui n’est pas un simple “shell” vide. Un shell, c’est tentant, c’est propre côté front, mais côté SEO c’est une dette. Si tu fais du SSR, tu gagnes immédiatement en robustesse. Si tu ne fais pas de SSR, un pre-render peut déjà changer la donne, surtout pour des routes “catalogue” et “contenu”.
Ensuite, le maillage interne doit exister sans interaction. Les pages de liste doivent lier vers les pages de détail avec des <a href>. Les pages de détail doivent relier vers des pages sœurs, des catégories, des pages de marque, bref des chemins. Le crawler ne scroll pas comme un humain. Si ton “infinite scroll” est le seul moyen d’atteindre la page 12, tu as un problème de découverte.
Enfin, les fondamentaux HTTP doivent être propres : pas de redirections en chaîne, pas de variations d’URL infinies, pas de canonicals contradictoires, pas de noindex “par défaut” qui s’oublie en prod. Ça a l’air basique, mais dans les apps modernes, c’est souvent là que ça se joue.
Vérifier avec des signaux qui ne sont pas des screenshots
Le screenshot du rendu est un signal UI. Et comme tous les signaux UI, il est séduisant… et parfois trompeur. Quand tu veux trancher, regarde des preuves plus “sèches”.
La première preuve, ce sont les logs serveur. Est-ce que Googlebot passe réellement sur tes routes profondes, ou seulement sur la home et quelques assets ? Est-ce qu’il récupère tes bundles JS et tes CSS, ou est-ce que tu vois des 403/404 côté statiques ? Là, tu n’es plus dans l’interprétation. Tu es dans le factuel.
Deuxième preuve : dans GSC, distingue bien “test en direct” et “page explorée”. Tu peux réussir un test en direct et avoir une version explorée (et indexée) différente, plus ancienne, ou incomplète. Regarde l’HTML récupéré, les ressources bloquées, et surtout les signaux de couverture/indexation. Si tes URLs ne sont jamais découvertes, tu peux rendre autant que tu veux, ça ne décollera pas.
Troisième preuve : tes sitemaps et ton linking interne. Un sitemap bien rempli peut aider à la découverte, mais ce n’est pas une baguette magique. Si ton site vit uniquement via un sitemap et que le maillage interne est pauvre ou non crawlable, tu as une architecture fragile. Le sitemap doit accélérer, pas remplacer une navigation web normale.
Quand un rendu bizarre est un vrai problème (pas juste cosmétique)
Il y a des cas où le screenshot moche est le symptôme d’un vrai mur. Le cas le plus net : le contenu principal n’existe pas dans l’HTML initial et n’apparaît qu’après exécution JS… mais ce JS ne se charge pas (bundle cassé), ne s’exécute pas (erreur runtime), ou dépend d’une API bloquée/filtrée pour Googlebot. Là, Google voit un squelette vide, et tu peux attendre des mois.
Autre cas très courant : des routes qui n’existent pas réellement côté serveur. L’utilisateur navigue dans la SPA, tout va bien. Mais quand Google essaie d’accéder directement à /produits/chaussures-rouges, le serveur renvoie un 404 ou une redirection vers une page générique. Le rendu peut même “sembler” afficher quelque chose via des bricolages, mais l’URL n’est pas une vraie ressource web. Et Google indexe des ressources web.
Enfin, fais attention aux scripts conditionnels. Si ton contenu dépend d’un A/B test, d’un tag manager, d’un consentement, ou d’une logique “si localStorage a telle valeur”, tu peux accidentellement servir une version vide à un crawler. Ce genre de bug tient des mois parce qu’il est invisible en navigation normale.
Mon avis (assez sec) : arrête de “valider” au rendu GSC
Utilise le rendu GSC comme une alerte, pas comme une certification. Un site crawlable, c’est un site où les URLs existent, où les liens sont des liens, où les ressources nécessaires ne sont pas bloquées, et où le HTML a de la matière. Quand tu as ça, le screenshot peut être moche et tu t’en sortiras quand même. Quand tu n’as pas ça, tu peux avoir un rendu “joli” en test live… et te prendre 6 à 9 mois de stagnation.
Si tu construis une app, pense “web” avant de penser “app”. Tu peux garder ton UX, tes transitions, ton routing client. Mais au fond, Google veut des documents reliés par des liens. Donne-lui ça, et le reste redevient un problème d’optimisation, pas un problème d’existence.
