JavaScript SEO : Comment Google rend le JavaScript et où cela échoue

Cherchez « JavaScript SEO » et les résultats se divisent en deux genres obsolètes : la panique des années 2018 (“ Google rend-il vraiment le JavaScript ? ”) et l'enthousiasme des cadres (“ Next.js est SEO-friendly, mettez-le en production ”). Les deux passent à côté de l'endroit où les dégâts se produisent réellement aujourd'hui. Google rend le JavaScript — ce débat est terminé. La vraie question est plus étroite et beaucoup plus coûteuse : la page que Google a indexée est-elle la page que vous avez déployée ? Le contenu côté client uniquement, les erreurs d'hydratation et les redirections JavaScript produisent tous des sites qui semblent parfaits dans le navigateur mais arrivent incomplets dans l'index — et parce que la page « fonctionne », personne ne remarque jusqu'à ce que le rapport de trafic le montre.

Ce guide couvre la façon dont Google explore et rend réellement le JavaScript, les pièges d'indexation qui survivent à l'ère du rendu, et pourquoi une redirection JavaScript fuit de l'équité qu'une 301 serveur ne fuit pas. La méthode tout au long est d'abord le dépôt : sur un site de framework moderne, chacune de ces défaillances est visible dans une poignée de fichiers sources — next.config, middleware.ts, les limites des composants clients — avant qu'aucun crawler ne s'exécute. C'est la couche JavaScript de notre pilier SEO agentic, et elle suit la même règle que l' audit technique SEO : aucune correction n'est faite jusqu'à ce que Google Search Console indique que le chiffre a bougé.

Comment Google explore et rend vraiment le JavaScript

Google traite une page JavaScript en phases, et l'écart entre elles est là que le SEO JavaScript vit. D'abord, Googlebot récupère le HTML brut — tout ce que le serveur retourne avant l'exécution d'un seul script. Les liens et le contenu trouvés ici entrent en traitement immédiatement. Tout ce qui n'existe qu'après l'exécution du JavaScript attend la deuxième phase : la page entre dans une file d'attente de rendu, et quand les ressources le permettent, le Web Rendering Service de Google la charge dans un Chromium sans interface et à jour — à jour avec le Chrome stable depuis la mise à jour de Googlebot de 2019 de Google — exécute les scripts, et indexe le résultat rendu.

Deux propriétés de ce pipeline importent plus que le pipeline lui-même. La file d'attente est généralement rapide — Martin Splitt de Google a évalué le délai d'attente médian de rendu à environ cinq secondes, avec la longue traîne en minutes — donc « Google met des semaines à rendre du JS » est surtout du folklore mort. Mais le rendu est au mieux des efforts : les scripts qui erreurs, les ressources bloquées par les règles de robots, les appels API qui expirent ou nécessitent des identifiants, et le contenu qui n'apparaît qu'après un clic ou un défilement échouent tous silencieusement. Googlebot ne clique pas sur les boutons, ne remplit pas les formulaires, et ne fait pas défiler de la manière qu'un utilisateur le ferait — la documentation JavaScript SEO de Google lui-même dit que le contenu chargé sur interaction ne sera pas indexé. Ce qui rend est ce qui indexe. Ce qui échoue rend comme absence, et l'absence ne produit aucun message d'erreur.

Les pièges d'indexation qui survivent à l'ère du rendu

Parce que le rendu fonctionne surtout, les défaillances qui restent sont du type silencieux : des pages qui réussissent chaque test des yeux et indexent toujours incomplètes. Trois motifs en comptent pour la plupart, et tous les trois sont diagnosticables à partir de la source avant qu'aucun crawler ne s'exécute.

Contenu côté client uniquement : la page qui arrive vide

Le motif d'application monopage classique — servez une coquille, récupérez le vrai contenu avec JavaScript côté client après le chargement — met votre contenu principal du mauvais côté de l'écart de rendu. Si la récupération est rapide, publique et sans erreur, Google l'obtient généralement. Chaque « si » dans cette phrase est un mode de défaillance. Sur un site que nous avons audité, les pages de produit semblaient complètes dans chaque navigateur tandis que la copie du corps était chargée à partir d'un appel API qui échouait dans les conditions de Googlebot — la version indexée était un modèle : navigation, passe-partout, pas de produit. Le site n'a pas été pénalisé. Il a simplement été indexé comme la chose vide qu'il servait. Dans le dépôt, c'est un diagnostic d'un fichier : le contenu récupéré dans un useEffect ou derrière une limite ’use client’ est côté client uniquement ; le contenu récupéré dans un composant serveur est expédié dans le HTML et n'entre jamais dans la file d'attente de rendu du tout.

Erreurs d'hydratation : expédié deux fois, indexé une fois

Les frameworks modernes font le rendu serveur du HTML, puis l'hydratent — le JavaScript côté client reprend le balisage statique et le rend interactif. Quand le balisage serveur et le rendu client ne sont pas d'accord, les frameworks résolvent l'écart en jetant la version serveur et en re-rendant côté client — ce qui convertit silencieusement votre page rendue serveur en une page rendue client, écart de rendu et tout. Pire encore sont les erreurs adjacentes à l'hydratation qui vident des sous-arbres de composants entiers : une exception non gérée dans un composant et tout ce qui est en dessous disparaît du DOM rendu. La page retourne toujours 200. Rien dans un rapport d'exploration ne le signale. L'indice est dans Google Search Console : l'outil Inspection d'URL HTML rendu est la vérité absolue pour ce que Google a vraiment construit — comparez-le avec votre propre DOM et les sous-arbres manquants s'annoncent eux-mêmes.

Liens et métadonnées qui n'existent qu'après le rendu

La découverte s'exécute d'abord sur le HTML brut. La navigation rendue purement côté client, les gestionnaires onClick servant de liens, et la pagination qui mute l'état au lieu de pointer vers des URL cachent tous votre graphique de liens internes à la première phase, la moins coûteuse de l'exploration — et un lien que Google ne peut pas voir est de l'équité de lien qui ne s'écoule jamais. La même chose s'applique aux métadonnées : les titres, les canoniques et les directives de robots définies par JavaScript côté client arrivent tard, et un canonique ou noindex qui change entre HTML brut et HTML rendu est une ambiguïté que vous avez remise à Google pour la résoudre. La règle du dépôt d'abord est sans équivoque : de vrais éléments <a href> pour chaque chemin d'exploration, et les métadonnées émises côté serveur — en termes Next.js, generateMetadata, jamais document.title.

Redirections JavaScript vs 301 : la fuite lente

Les redirections sont l'endroit où le SEO JavaScript cesse d'être subtil. Une 301 serveur se produit à la couche HTTP : le crawler demande l'ancienne URL, le serveur répond « déplacé en permanence, voici où » dans le statut de réponse, et Google consolide les signaux vers la nouvelle URL — aucun rendu, aucune interprétation, aucune file d'attente. Une redirection JavaScript — window.location dans un script — est invisible à cette couche. L'ancienne URL retourne 200 avec une page attachée. Pour même découvrir qu'une redirection existe, Google doit explorer la page, la mettre en file d'attente, la rendre, exécuter le script et déduire le mouvement. La propre documentation de redirection de Google ne laisse aucun doute sur la hiérarchie : les redirections permanentes côté serveur sont la méthode préférée, et les redirections JavaScript sont le dernier recours, pour quand rien d'autre n'est disponible pour vous.

« Dernier recours » minimise le coût, car Google n'est plus le seul lecteur qui compte. Chaque consommateur de vos URL qui n'exécute pas le JavaScript — les racleurs de réseaux sociaux construisant des aperçus de liens, la plupart des outils SEO mappant vos redirections, et de manière décisive, les crawlers IA — voit une redirection JavaScript comme une page 200 active qui n'a jamais bougé. L'ancienne URL continue d'accumuler des références. La nouvelle commence par moins qu'elle ne devrait. C'est la fuite : pas une pénalité, juste la consolidation du signal qui arrive tard pour Google et jamais pour tout le monde d'autre.

Le dépôt rend cet audit presque embarrassamment rapide. Dans une base de code Next.js, les redirections légitimes vivent dans exactement trois endroits — redirects() dans next.config, NextResponse.redirect dans le middleware, et les appels redirect() dans le code serveur — tous émettent des codes de statut HTTP réels. Tout le reste est une fuite : parcourez les bundles clients pour les assignations window.location et les appels router.replace servant de substituts pour les mouvements qui devraient être côté serveur, et vous avez trouvé en minutes ce qu'un audit de redirection basé sur l'exploration reconstruit en jours.

Le point aveugle : les crawlers IA ne rendent pas

Voici la tournure de l'ère du rendu que la plupart des guides de SEO JavaScript n'ont pas rattrapée : les lecteurs les plus récents de votre site se comportent comme les plus anciens. Une analyse 2024 du trafic des crawlers IA par Vercel et MERJ a constaté que les principaux crawlers IA — GPTBot d'OpenAI, ClaudeBot d'Anthropic, PerplexityBot — récupèrent le HTML mais n'exécutent pas le JavaScript. Gemini est l'exception uniquement parce qu'elle chevauche l'infrastructure de rendu de Googlebot. Pour tous les autres, votre site est exactement ce que le serveur retourne : le contenu côté client n'existe pas, les redirections JavaScript ne se sont jamais produites, et une page rendue côté client est une coquille vide portant un 200.

Cela signifie que l'écart de rendu que vous avez fermé pour Google en 2019 s'est silencieusement réouvert pour les systèmes décidant ce qui est cité dans les réponses IA. Si une part croissante de votre découverte s'exécute via des moteurs qui lisent du HTML brut — le changement que notre pilier AI search couvre complètement — alors le rendu serveur de votre contenu principal cesse d'être une commodité de performance et devient la différence entre être citables et être invisibles. La règle pratique s'effondre à une phrase : tout ce que vous voulez qu'une machine quelconque lise doit être dans le HTML que le serveur envoie. Obtenir un rendu est les enjeux pour Google ; être lisible sans rendu est la barre pour tout ce qui vient après Google.

Google a passé cinq ans à apprendre à exécuter votre JavaScript — et puis les crawlers IA sont arrivés lisant du HTML brut comme en 2015. La page qui gagne les deux ères est celle qui n'a jamais eu besoin du rendu.

La liste de vérification JavaScript SEO d'abord le dépôt

L'audit JavaScript d'abord l'exploration signifie rendre votre propre site page par page et rétro-ingéniérer les causes à partir des symptômes. D'abord le dépôt l'inverse : le comportement de rendu de chaque page est déterminé par un petit ensemble de fichiers sources, et un défaut dans une disposition partagée ou une config est un défaut sur chaque page qu'il touche — connaissable à partir d'une lecture de fichier. Voici où chaque question vit dans un dépôt Next.js, et la métrique Google Search Console qui jugera le correctif.

Confirmez ensuite l'intention contre la réalité une fois : l'inspection d'URL dans Google Search Console montre le HTML rendu que Google a vraiment construit — l'outil de SEO JavaScript le plus sous-utilisé, et gratuit. Si un bloc de contenu est dans votre DOM et manque de la copie rendue de Google, vous avez une conclusion de render-gap avec la preuve attachée. La version cinq couches plus large de cette passe — exploration, indexation, canoniques, schéma, Web Vitals essentiels — est l' audit technique SEO ; cette liste de vérification est la couche que le JavaScript met spécifiquement à risque.

Aucun correctif n'est fait jusqu'à ce que Google Search Console le dise

Les correctifs de SEO JavaScript sont inhabituellement faciles à déclarer victoires, car le symptôme visible disparaît instantanément : le contenu est en view-source, la redirection retourne 301, l'élément d'audit devient vert. Rien de cela n'est le résultat. Le résultat est Google en réexplorant, en re-rendant et en réindexant les URL affectées — et l'endroit unique où cela devient visible est Google Search Console, des semaines plus tard. Donc chaque résultat de la liste de vérification ci-dessus est expédié avec son contrat de preuve attaché avant le correctif : l'impact attendu, la métrique qui le jugera (impressions pour le contenu qui est entré dans l'index, position et impressions pour les redirections consolidées, CTR pour les métadonnées), et la cible qui compte comme succès. Environ trois semaines après l'atterrissage du correctif, la métrique est relue et le verdict enregistré : confirmé, régressé ou peu concluant.

Cette discipline paie double sur le travail JavaScript, car les correctifs de render-gap sont parmi les plus vérifiables de tout le SEO : le contenu qui était absent de l'index commence soit à gagner des impressions, soit ne le fait pas. Une migration réexpédiée en tant que 301 consolide soit les données de position, soit ne le fait pas. Exécutez la boucle honnêtement et vous apprenez également quels correctifs JavaScript sur votre site valent le temps d'ingénierie — et lesquels étaient de l'hygiène qui n'a jamais bougé un nombre, ce qui est aussi un résultat.

Si vous voulez que la moitié de la recherche s'exécute par rapport à vos propres données, le rapport SEO gratuit connecte votre Google Search Console et surface les symptômes que cet article décrit — pages affichées bien moins que leurs frères et sœurs, URL qui auraient dû consolider et ne l'ont pas. Et si vous préférez que la boucle entière s'exécute en tant que système — fichiers sources lus, correctifs expédiés en tant que pull requests, verdicts lus de GSC trois semaines plus tard — réservez un appel et nous vous montrerons à quoi cela ressemble sur votre pile.