SEO JavaScript : assurez-vous que les liens survivent au rendu

Google rend le JavaScript avec un Chromium evergreen. Le problème vient rarement du rendu lui-même. Il s'agit plutôt de liens qui ne deviennent jamais des balises <a>, et de pages qui dépendent d'un état que le crawler ne possède pas.

Équipe de recherche ArchiLinks · Mis à jour 2026-10-29

Un pont reliant des fondations en pierre à des structures en verre représentant la survie des liens

Ce qu'un crawler voit

Googlebot utilise un Chromium evergreen depuis mai 2019. Cela a tranché la question de sa capacité à exécuter du JavaScript moderne.

Les risques pratiques sont plus anciens : le rendu intervient après le crawl et peut être retardé, le contenu derrière des clics ou des connexions n'apparaît jamais, et un lien créé à partir d'un gestionnaire onclick sur un div n'est pas un lien. Avant de vérifier les backlinks sur les pages de votre site que vous avez récemment migrées vers un front-end React, confirmez que ces pages affichent leur contenu dans la réponse brute ou dans le HTML rendu.

SSR, SSG, CSR : quelles conséquences pour les liens

Approche	Contenu dans la première réponse	Liens internes sous forme d'ancres	Adapté pour
SSR (Next.js, Nuxt)	Oui	Oui, si vous utilisez de vraies balises <a>	Pages publiques avec des données changeantes
SSG ou pré-rendu	Oui	Oui	Docs, blogs, pages marketing
Application single-page CSR	Non, coquille vide	Uniquement après rendu	Tableaux de bord derrière une connexion
Hybride (SSR pour la page d'accueil, CSR pour l'application)	Par route	Par route	La plupart des produits avec une partie publique

Test 1 : HTML brut versus HTML rendu

Si les liens clés apparaissent dans la première réponse, la question est réglée. Sinon, comparez avec un rendu headless.

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

Un jardinier inspectant les racines d'un arbre représentant les vérifications de santé des backlinks externes

Là où les liens externes interviennent

Un bug de rendu masque votre contenu. Il n'efface pas les liens que d'autres sites vous ont déjà attribués.

Après un passage à Next.js, Vite ou un CMS headless, exécutez toppages pour l'hôte et testez les 20 URL les plus liées pour vérifier leur statut, leur canonical et leur contenu visible. Faites-le en priorité. Si une page avec 40 domaines référents renvoie une coquille vide ou une erreur 404 côté client, corrigez-la avant toute autre chose, car c'est là que votre autorité se concentre. La page sur l'équité des liens internes vs externes montre comment comparer cette liste avec vos liens internes, et la checklist de migration intègre ce test dans un plan de lancement.

Les frameworks comptent moins que la rigueur. Express avec un moteur de template, un thème WordPress et un Next.js app router peuvent tous servir des liens crawlables. Chacun peut aussi échouer si une équipe déploie des ancres qui n'existent qu'après un clic.

Liste de contrôle des liens et du rendu

La navigation et la pagination utilisent <a href>, et non des gestionnaires de clic sur d'autres éléments.
Chaque route renvoie un code d'état réel. Les pages d'erreur 404 soft doivent renvoyer le code 404.
L'instruction noindex ou l'URL canonique injectés par JavaScript doivent correspondre à ceux de la réponse du serveur.
Le contenu de repli dans la première réponse doit être la page réelle, et non un indicateur de chargement que Google pourrait indexer.
Le code d'authentification ne doit pas rediriger les robots d'indexation sur les routes publiques.
Les fichiers CSS et JS nécessaires au rendu ne doivent pas être bloqués dans le fichier robots.txt.
Le chargement différé utilise IntersectionObserver ou les attributs de chargement natifs, et non les événements de défilement.

Analyse des données de Search Console

Search Console répond à la plupart des questions sur le rendu si vous consultez les bons rapports. Utilisez l'inspection d'URL, puis Affichez la page crawlée.

Comparez trois éléments : le HTML récupéré par Google, la capture d'écran et les ressources de la page qui n'ont pas pu se charger. Une page qui semble complète dans votre navigateur mais vide dans la capture d'écran est généralement bloquée par une erreur de script ou une ressource interdite ; la solution se trouve dans votre processus de build, et non dans votre contenu.

N'oubliez pas le délai. Une modification déployée aujourd'hui n'apparaîtra dans l'outil d'inspection qu'après le nouveau crawl de l'URL par Google, ce qui peut prendre plusieurs jours.

Quand le SSR vaut le coup

Pages publiques qui doivent se positionner : oui. Tableaux de bord : non.

Si une route doit générer du trafic organique, servez le contenu dans la première réponse. Si elle est derrière une connexion, évitez la complexité. Choisissez par route et non par projet, et documentez la décision pour qu'un développeur suivant ne l'annule pas.

Utilisez le test des résultats enrichis et l'inspection d'URL pour comparer le rendu.
Testez avec le test en direct de la Search Console après chaque mise à jour du framework.

Deux maisons sur une colline montrant le rendu prerendered versus client-side

Le rendu côté serveur est-il nécessaire, ou le prerendering suffit-il ?

Le rendu côté serveur est optionnel. C'est un moyen de faire en sorte que la première réponse contienne ce dont un crawler a besoin. De nombreux sites publics y parviennent avec du prerendering, une construction statique ou un rendu serveur pour les pages importantes, et laissent les parties connectées de côté.

Imaginons que vos pages produits et vos docs soient publiques, tandis que le tableau de bord est derrière une connexion. Prerendezz le premier groupe. Laissez le tableau de bord en client-side. Les pages publiques portent alors leurs liens dans la première réponse, et le tableau de bord peut rester aussi complexe que nécessaire.

Prerendering uniquement de la page d'accueil

Prerendering de la page d'accueil résout le premier crawl, mais laisse toutes les autres routes attendre le navigateur. Si la page d'accueil lie vers des pages de catégorie rendues côté client, les liens de ces pages dépendent toujours du rendu. Vérifiez chaque modèle que vous possédez, pas seulement la porte d'entrée.

Gardez une courte liste des routes publiques avec leur méthode de rendu. La liste révélera les lacunes plus rapidement qu'un rapport de crawl.

Le rendu côté serveur change-t-il la visibilité locale

Le rendu côté serveur peut modifier la rapidité d'apparition du premier contenu, ce que les lecteurs ressentent. Cela ne rend pas une page pertinente pour une requête locale par lui-même. Ces signaux proviennent du contenu de la page, des détails de l'entreprise et des liens qui pointent vers elle.

Traitez le rendu comme le moyen pour ces signaux de devenir lisibles pour un crawler, et mesurez les liens séparément avec l'API.

Apps Vite et React qui servent un seul shell

Une construction Vite qui sert un seul HTML shell pour chaque chemin déplace tout le travail sur le client. Une telle app peut encore se positionner pour certaines requêtes, mais chaque route publique a besoin d'un plan : prerendezz-la, rendezz-la côté serveur, ou acceptez la perte et notez-le.

Avant de vérifier les backlinks sur les routes du site après une reconstruction, décidez comment chaque route publique obtient son contenu. Sinon, les données de liens montreront des liens externes atterrissant sur des pages vides.

Tester si une route affiche ses liens

Deux tests répondent à la plupart des questions. La réponse brute montre ce qu'un crawler obtient avant l'exécution de tout script. Le DOM rendu montre ce qu'un navigateur construit ensuite. Un lien qui n'apparaît que dans le second est toujours un lien, mais il dépend d'un rendu réussi.

Lire le test en direct dans la Search Console

Lancez le test en direct depuis l'inspection d'URL sur une route à la fois. Regardez le HTML rendu, puis la liste des ressources qui ont échoué à charger. Un script bloqué peut supprimer tout un bloc de navigation, et la page semble pauvre sans afficher d'erreur visible.

Répétez le test après une mise à jour du framework, car une nouvelle valeur par défaut peut modifier si les liens sont rendus avant ou après l'exécution d'un script. Le guide pages non indexées couvre ce qu'il faut faire lorsqu'une page rendée reste hors ligne.

Quand une route se rend mais que le contenu est un spinner

Le fallback dans la première réponse est plus important que la plupart des équipes ne l'imaginent. Un spinner ou un conteneur vide signifie que la page ne porte aucun texte pour le crawler à ce moment-là. Mettez le titre, l'intro et les liens principaux dans la première réponse, même si une liste détaillée charge plus tard.

Un fallback qui est la page réelle peut rester simple. Son seul travail est de contenir le contenu jusqu'à l'arrivée du reste.

Déplacer un site client-side sans perdre ses liens

Listez les routes avec des liens externes

Exécutez toppages pour l'hôte et notez les 50 URL les plus fréquentes. Testez ces routes en premier, avant les modifications de code, pour savoir ce que la reconstruction doit conserver.

Comparez la sortie brute et rendue

Pour chaque route, vérifiez le HTML brut et le DOM rendu dans l'ancienne et la nouvelle construction. Notez tout lien qui existe dans l'un mais pas dans l'autre.

Remplacez les gestionnaires de clic par des ancres

Transformez la navigation en vraies ancres avec une adresse appropriée. Le travail de vitesse peut attendre un sprint, tandis qu'une ancre manquante coûte à la route son chemin dans le site.

Répétez le test après la mise en production

Une semaine après la mise en production, lancez le test en direct sur les mêmes routes et comparez les résultats avec les précédents. Les différences montrent où la reconstruction a modifié la sortie.

Codes de statut et redirections dans une app client-side

Une app à page unique affiche souvent un écran de non-trouvé tandis que le serveur retourne un statut 200. Google peut traiter une telle page comme un soft 404, et les liens externes pointant vers l'URL manquante vous apportent alors peu. La correction appartient au serveur.

Routes inconnues qui retournent encore 200

Retournez un vrai 404 depuis le serveur pour toute route qui n'existe pas, et gardez l'écran de non-trouvé dans l'app pour les visiteurs qui arrivent par une route client-side. Où un remplacement existe, envoyez un 301 à la place.

Vérifiez quelques adresses inventées sur l'hôte en direct après chaque mise en production. Le code de réponse est ce qu'il faut lire, pas la page que vous voyez dans le navigateur.

Redirections qui s'exécutent dans le navigateur

Une redirection qui se déclenche après le chargement de la page, par exemple en lisant un paramètre d'URL dans un composant, est différente d'une redirection serveur. Un crawler peut indexer la première réponse avant que la redirection ne s'exécute. Où une route a déménagé définitivement, retournez un 301 depuis le serveur et conservez les paramètres qui changent le contenu. La recette de la carte de redirection montre comment tester ces règles.