JavaScript SEO : pourquoi Google ne voit pas votre contenu

La page fonctionne parfaitement dans Chrome, mais Google n'indexe qu'un titre vide et quelques lignes du pied de page. Les développeurs disent que les robots modernes exécutent JavaScript ; l'équipe SEO voit des URL qui ne gagnent jamais en visibilité. Les deux n'ont raison qu'à moitié.

Google peut rendre JavaScript, mais cela ne signifie pas que toute application sera rapidement explorée, correctement comprise et entièrement indexée. Diagnostiquez selon ses trois étapes réelles : explorer le HTML, rendre JavaScript et indexer le résultat.

Comment Google traite les pages JavaScript

Phase 1 : exploration

Googlebot récupère l'URL et lit le statut HTTP, les en-têtes, directives robots et HTML initial. Il peut déjà extraire liens <a>, canonical, titres et contenu de la réponse.

Si le serveur renvoie 404, 500, bloque l'exploration ou transmet noindex, le traitement peut s'arrêter avant l'exécution de l'application.

Phase 2 : rendu

Une page 200 peut entrer dans une file de rendu. Chromium sans interface exécute JavaScript, récupère les ressources autorisées et crée le DOM rendu. L'attente dépend des ressources du robot.

Phase 3 : indexation

Google lit contenu et liens du HTML rendu, puis évalue canonical, qualité, duplication et indexabilité. Le succès du rendu ne garantit pas l'indexation : la page doit apporter de la valeur et des signaux cohérents.

Le test le plus rapide : désactiver JavaScript

Utilisez le code source ou curl pour examiner la réponse HTML. Ne vous fiez pas seulement à Elements de DevTools, qui montre le DOM après exécution des scripts.

Vérifiez cinq éléments :

1. Le titre et la méta-description sont-ils présents ?
2. Le H1 et le texte principal sont-ils visibles ?
3. Les chemins internes sont-ils de vrais liens <a href> ?
4. Canonical et robots sont-ils immédiatement corrects ?
5. Le serveur renvoie-t-il le bon statut ?

Si la réponse contient seulement <div id="app"></div>, la découverte dépend du rendu. Ce n'est pas forcément défectueux, mais cela ralentit inutilement l'indexation et le débogage.

Sept défaillances courantes du SEO JavaScript

1. Le contenu apparaît seulement après interaction

Googlebot n'est pas obligé de cliquer sur les onglets, déplier les accordéons, utiliser le défilement infini ou appuyer sur « Charger plus ». Le contenu récupéré après une action peut ne jamais être découvert.

Rendez le contenu important en HTML ou fournissez une URL distincte et un lien explorable pour chaque état méritant l'indexation. Un accordéon dont le contenu existe déjà dans le DOM est plus sûr qu'un chargement après clic.

2. Les routes client renvoient toujours 200

Une SPA peut afficher « Introuvable » tout en répondant 200, créant une soft 404. L'inverse existe aussi : une route valide reçoit un 404 serveur avant le démarrage du routeur frontend.

Chaque URL indexable nécessite un statut serveur pertinent. Les pages manquantes renvoient 404, les contenus déplacés une redirection et les défaillances temporaires 5xx.

3. Les liens ne sont pas explorables

Ceci ressemble à de la navigation pour un utilisateur, mais n'est pas un chemin fiable pour les robots :

<span onclick="goTo('/products')">Products</span>

Utilisez :

<a href="/products">Products</a>

Un routeur client peut toujours intercepter la navigation si l'ancre contient une vraie URL.

4. JavaScript réécrit la canonical

La canonical devrait être présente dans le HTML source et rester stable. Si le source vise A et qu'un script passe à B, le robot reçoit des signaux contradictoires à différents moments. N'attendez pas non plus de JavaScript qu'il retire noindex : Google peut voir la directive et ignorer le rendu.

5. Les règles robots bloquent bundles ou API

L'application peut nécessiter JavaScript, CSS ou une API publique pour construire le contenu. Sans accès de Googlebot à ces ressources, le rendu peut être vide ou incomplet.

Protégez les API privées. Vérifiez le rendu public et les ressources avec les outils réseau du navigateur et l’inspection d’URL de Search Console ; détecter Cloudflare ne vérifie pas les politiques WAF privées.

6. Le rendu dépend du stockage local, des cookies ou de la position

Googlebot arrive comme un nouveau visiteur. Si le contenu principal exige un jeton localStorage, un cookie de consentement particulier ou un résultat de géolocalisation, le robot peut recevoir un état vide.

Servez une version par défaut utile. La personnalisation doit l'enrichir, pas remplacer tout le sujet de l'URL.

7. L'hydratation échoue

Le SSR peut envoyer un HTML complet, puis une erreur d'hydratation supprimer le contenu ou créer un autre DOM. Le moteur peut encore lire la réponse, mais l'expérience et les liens après rendu peuvent casser.

Surveillez les erreurs console, divergences d'hydratation et requêtes échouées en production. Les pannes affectant les robots ou appareils lents passent facilement inaperçues en QA ordinaire.

CSR, SSR, SSG et rendu hybride

Blogs, pages de destination, catégories et documentation bénéficient généralement du SSR ou SSG. Un tableau de bord authentifié n'a pas besoin d'indexation : le CSR y convient parfaitement.

Le rendu dynamique a servi à transmettre un HTML spécial aux robots, mais maintenir deux versions crée des divergences et des coûts. Si possible, servez le même contenu principal prérendu aux utilisateurs et robots.

Audit SEO JavaScript étape par étape

Étape 1 : comparer trois versions

Placez côte à côte :

• Le HTML source ;
• Le DOM rendu par le navigateur ;
• Le HTML rendu ou la capture d'URL Inspection.

Tout élément présent seulement dans votre navigateur mais absent d'URL Inspection est une piste sérieuse.

Étape 2 : examiner requêtes et ressources

Repérez les ressources renvoyant 403, 404, des erreurs CORS, dépassements de délai ou blocages robots. Une seule API défaillante peut supprimer toute une zone malgré le chargement du bundle principal.

Étape 3 : auditer les métadonnées

Titres, descriptions, canonical, robots et données structurées doivent être propres à chaque route. Les SPA gardent souvent les métadonnées précédentes ou dérivent les canonical d'URL non normalisées.

Meta Tag Checker montre le titre, la canonical, les balises Open Graph et les titres fournis pour une URL.

Étape 4 : examiner liens et sitemaps

Les liens internes nécessitent href, les sitemaps seulement des URL canonical et chaque URL listée le statut prévu. Un sitemap ne compense pas une navigation inexplorable.

Étape 5 : mesurer les performances

Gros bundles et tâches longues nuisent aux utilisateurs et rendent le rendu coûteux. Lancez Page Speed Checker, en surveillant LCP, INP, TBT et JavaScript inutilisé.

Étape 6 : tester les modèles, pas seulement l'accueil

Échantillonnez article, catégorie, produit, filtre, pagination et URL manquante. La plupart des défauts concernent des routes rarement ouvertes manuellement par les développeurs.

Une défaillance typique

Un site de recrutement Vue récupère les cartes d'emploi après montage du composant de catégorie. Le H1 figure dans le source, mais chaque carte est générée par JavaScript et utilise @click sur un <div> sans href.

Les visiteurs parcourent normalement les offres, mais Google peine à trouver les détails : le sitemap liste les emplois sans chemins explorables ni liens internes. Utilisez XML Sitemap Checker pour améliorer leur découverte.

La solution n'est pas de supprimer Vue. L'équipe remplace les cartes par <a href>, rend la liste initiale côté serveur, garde les filtres interactifs côté client et renvoie de vrais 404 pour les offres expirées. L'architecture reste moderne et la découverte ne dépend plus du hasard.

Liste de contrôle avant publication

• Contenu principal présent dans le HTML ou rendu fiable.
• Routes valides répondant 200 ; routes supprimées 404/410.
• Navigation importante avec <a href>.
• Canonical et robots présents dans le source et stables.
• CSS, JavaScript et API nécessaires explorables.
• États vides de nouveaux visiteurs ne remplaçant pas le contenu essentiel.
• Métadonnées correctement actualisées pendant la navigation.
• Données structurées dans le HTML rendu.
• Contenu principal équivalent sur mobile et ordinateur.
• URL Inspection voyant ce que voit un visiteur.

Surveiller le SEO JavaScript après publication

Une inspection ponctuelle détecte les défauts évidents, mais les applications changent souvent. Ajoutez quelques contrôles en production pour détecter les erreurs SEO avant qu'une tendance n'apparaisse dans Search Console.

Surveillez des routes publiques représentatives avec un test du HTML :

• Titre et canonical attendus présents dans la réponse ;
• Titre principal et fragment reconnaissable du contenu présents ;
• Code d'état cohérent avec l'état de la route ;
• Au moins un lien interne important avec un vrai href ;
• Directives robots sans changement inattendu.

Exécutez un second contrôle dans un navigateur avec rendu pour le contenu dépendant légitimement de l'hydratation. Capturez erreurs console, requêtes échouées, canonical finale, données structurées et capture d'écran. Le test HTML protège les bases de l'exploration ; le test rendu protège l'application réelle.

Choisissez les URL par modèle plutôt que selon le seul trafic. L'accueil peut rester fonctionnel alors que les produits, la pagination ou les routes localisées cassent. Gardez un exemple stable pour chaque modèle indexable et un exemple négatif devant renvoyer 404.

Les annotations de publication sont tout aussi utiles. Quand les pages indexées ou impressions baissent, connaître la date exacte de modification du routeur, gestionnaire de consentement, framework de rendu ou API accélère le diagnostic. Sans historique, les équipes accusent souvent l'algorithme d'une régression de leur propre déploiement.

Pour les grands sites, comparez automatiquement HTML source et DOM rendu. Alertez si le rendu perd beaucoup de texte ou de liens, ou si le contenu apparaît seulement après une action différée. Ces contrôles ne remplacent pas URL Inspection, mais repèrent chaque jour des erreurs évitables.

Vérification complète : utilisez SEO Checker sur une URL représentative et un audit SEO gratuit pour détecter les problèmes répétés entre modèles.

Conclusion

JavaScript ne fait pas échouer le SEO. Le vrai dommage vient du contenu visible seulement après clic, des statuts incorrects, des liens sans href et des métadonnées tardives. Donnez du sens à la réponse initiale, gardez URL et statuts fidèles, puis améliorez l'expérience avec JavaScript plutôt que cacher le contenu essentiel.

Référence : Google Search Central – principes du SEO JavaScript.