Google, JavaScript et pages non-200 : ce qu’il faut retenir en 2026

Une page peut sembler parfaite dans votre navigateur et pourtant envoyer un signal très mauvais à Google. C’est exactement le piège des sites qui dépendent beaucoup du JavaScript, des routes côté client, des filtres dynamiques ou d’une interface moderne mal raccordée aux bons statuts HTTP.

Le sujet n’est pas “JavaScript est-il mauvais pour le SEO ?”. La réponse est non. Google sait exécuter du JavaScript. Le vrai sujet, c’est plutôt : que reçoit Googlebot au moment du crawl, quel statut HTTP accompagne la page, et le contenu important existe-t-il au moment où Google peut le traiter ?

Pourquoi ce point mérite une vraie vérification

Sur un site classique, on a tendance à raisonner simplement : une URL répond, le contenu s’affiche, donc Google devrait comprendre la page. Sur un site très dynamique, ce raccourci devient fragile. Le navigateur humain voit souvent le résultat final après chargement des scripts, appels API, composants, widgets, consentement, mesure d’audience et hydratation. Googlebot, lui, commence par une requête HTTP.

Cette première réponse compte énormément. Si le serveur renvoie un statut incohérent, si le HTML initial est quasiment vide, si les liens sont injectés trop tard, ou si la page dépend d’un script bloqué, Google peut avoir une lecture très différente de la vôtre.

Ce sujet est devenu plus important avec les sites React, Vue, Angular, Next, Nuxt, Shopify headless, Webflow enrichi, WordPress très chargé en plugins et e-commerces à filtres dynamiques. Ce ne sont pas de mauvaises technologies. Elles demandent juste une discipline plus stricte : la page importante doit être servie proprement, pas seulement devenir jolie après quelques secondes dans Chrome.

Comment Google traite JavaScript

Google décrit le traitement des pages JavaScript en trois grandes étapes : exploration, rendu, indexation. Dans son guide JavaScript SEO basics, Google explique que les pages en statut 200 sont envoyées dans la file de rendu, même si elles contiennent ou non du JavaScript. En revanche, si la réponse HTTP est non-200, le rendu peut être ignoré.

C’est le cœur du problème. Si votre page produit son contenu principal uniquement après JavaScript, mais que le serveur répond 404, 500, 401, 403 ou renvoie une route d’erreur, Google n’a pas forcément l’occasion de voir le contenu que votre navigateur finit par afficher.

Google rappelle aussi que le rendu peut prendre du temps. Une page peut être crawlée puis rendue plus tard, selon les ressources disponibles. Ce délai n’est pas forcément grave, mais il devient gênant si votre contenu dépend d’un script fragile, d’une API lente, d’un consentement mal géré ou d’un état côté client qui n’existe pas pour Googlebot.

Le bon réflexe est donc de rendre le contenu critique disponible tôt : titre, contenu principal, liens internes, canonical, meta robots, données structurées utiles, prix et disponibilité pour l’e-commerce, ou au moins une version serveur suffisamment complète pour que Google comprenne la page sans attendre un enchaînement fragile de scripts.

Les statuts HTTP qui changent tout

Le statut HTTP est un message envoyé par le serveur avant même que l’utilisateur ne lise la page. Pour Google, il indique si la ressource est disponible, déplacée, interdite, absente ou temporairement en erreur.

La documentation Google sur les codes HTTP et les crawlers rappelle un point souvent oublié : un code 2xx signifie que Google peut traiter le contenu, mais si ce contenu ressemble à une erreur, une page vide ou un message d’échec, Search Console peut remonter une soft 404. Autrement dit, répondre 200 ne suffit pas si la page raconte “produit introuvable”, “aucun résultat” ou “erreur de chargement”.

À l’inverse, une vraie page supprimée doit souvent répondre 404 ou 410. Une page déplacée doit répondre 301 ou 308 selon le cas. Une page inaccessible derrière login doit répondre un statut cohérent. Et une panne temporaire ne devrait pas être maquillée en 200 avec une belle page “maintenance” indexable.

Tableau : symptôme, risque, contrôle à faire

Les cas qui posent problème

Le premier cas, très courant, est la page de détail qui dépend d’une API. Le serveur répond 200 avec une coquille d’application. Ensuite JavaScript demande les données du produit, du service ou de l’article. Si l’API répond lentement, si elle renvoie une erreur, ou si Google ne récupère pas la ressource essentielle, la page peut finir presque vide côté rendu.

Le deuxième cas est la route client qui “répare” une erreur. L’URL répond 404, mais l’interface affiche quand même un contenu après navigation interne. Pour l’utilisateur qui clique depuis le site, tout semble fonctionner. Pour Googlebot qui arrive directement sur l’URL, le signal HTTP reste mauvais.

Le troisième cas est la page inexistante servie en 200. On la voit souvent sur les SPA, les moteurs de recherche internes, les fiches produits supprimées ou les filtres sans résultat. Visuellement, la page existe, mais son contenu dit en réalité “rien à afficher”. Google peut y voir une soft 404.

Le quatrième cas est la maintenance bricolée. Une page “nous revenons bientôt” en 200 sur tout le site, pendant plusieurs heures ou jours, peut envoyer un message très confus. Si la maintenance est temporaire, il vaut mieux gérer le statut, les délais et les pages critiques avec prudence, plutôt que de servir une page vide ou générique comme si tout allait bien.

Ce qu’il faut vérifier en priorité

Ne commencez pas par toutes les URL. Commencez par celles qui peuvent vraiment coûter cher si Google les comprend mal.

• Pages qui génèrent déjà des clics : elles ont de l’historique, donc une erreur technique peut faire mal rapidement.
• Pages à enjeu commercial : avis, comparatifs, fiches outils, pages code promo, catégories e-commerce, pages de vente.
• Modèles de page partagés : si un modèle est cassé, des centaines d’URL peuvent être touchées.
• Pages nouvellement refondues : changement de thème, migration, CDN, framework, gestion des routes, moteur de filtres.
• Pages avec contenu chargé tard : prix, disponibilité, avis, FAQ, liens internes, blocs “produits liés”.

Sur chaque page importante, vérifiez le statut HTTP réel, le contenu dans le HTML initial, le rendu après JavaScript, le canonical, le robots meta, les liens internes et la présence du contenu qui justifie l’indexation.

Si la page est lourde ou que le HTML utile arrive trop tard, relisez aussi le point sur la limite des 2 Mo de Googlebot pour Google Search. Le sujet n’est pas identique, mais il pousse la même conclusion : une page importante doit être facile à récupérer et à comprendre.

Lors d'une refonte ou d'un changement d'hébergement, ce diagnostic doit aussi passer par les logs : voir ce que Googlebot reçoit vraiment après migration aide à repérer les pages JavaScript servies avec le mauvais statut.

Ce qui fausse souvent le diagnostic

L’erreur la plus fréquente est de regarder uniquement le rendu visuel dans le navigateur. Un site peut sembler fonctionner alors qu’il envoie un signal HTTP incohérent, qu’il dépend d’une redirection côté client ou que le contenu principal n’existe pas dans une forme stable au moment où Google le traite.

La deuxième erreur est d’utiliser seulement des commandes Google. Elles peuvent aider à repérer une anomalie, mais elles ne remplacent ni Search Console, ni les logs, ni l’inspection du HTML rendu. Le guide sur les commandes Google encore utiles en 2026 détaille justement cette limite.

La troisième erreur est de confondre crawl, rendu et indexation. Une URL peut être crawlée, mais mal rendue. Elle peut être rendue, mais jugée trop pauvre. Elle peut être indexable, mais ne jamais ressortir correctement parce que son contenu principal est faible, dupliqué ou masqué derrière une logique fragile.

L’autre erreur est de mélanger ce sujet avec un simple problème de volume de crawl. Les deux se touchent parfois, mais ils ne se remplacent pas. Si votre problème principal est la charge serveur, la fréquence de passage ou le comportement de Googlebot, le guide pour réduire le crawl Google en 2026 sera plus adapté.

Soft 404 et SPA : le piège classique

Les applications côté client ont souvent un comportement agréable pour l’utilisateur : les pages changent vite, les composants se mettent à jour sans recharger toute l’interface, les filtres répondent instantanément. Mais côté SEO, il faut rester ferme sur un point : une URL absente ne doit pas ressembler à une page indexable normale.

Google recommande, pour les SPA, d’éviter les soft 404 en utilisant par exemple une redirection JavaScript vers une URL qui répond vraiment 404, ou un meta robots noindex sur les pages d’erreur. Ce n’est pas une invitation à tout gérer côté client. C’est une solution quand le routing côté serveur est difficile. Quand c’est possible, une réponse serveur propre reste plus simple à maintenir.

En e-commerce, le piège arrive souvent avec les produits supprimés, les catégories vides, les filtres sans résultat et les pages de recherche interne. Une page sans produit peut être utile pour l’utilisateur qui navigue, mais elle n’a pas forcément vocation à être indexée. Il faut décider : enrichir, rediriger, noindexer, canoniser ou répondre 404/410.

Pour les sites qui veulent aussi se rendre plus lisibles par des assistants IA, llms.txt peut servir de fichier de cadrage, mais il ne compense jamais une page mal servie, non indexable ou fragile côté rendu.

Un autre risque JavaScript a surveiller concerne la navigation elle-meme : Google sanctionne desormais le back button hijacking quand un script empeche l'utilisateur de revenir normalement en arriere.

Le meme risque existe lors d'une refonte complete : migrer WordPress vers Next/Vercel demande de verifier les codes HTTP, les routes, les redirections et les pages réellement servies.

Pourquoi ce sujet compte aussi pour WordPress et l’e-commerce

Ce problème ne concerne pas seulement les SPA “pures”. Un site WordPress peut se compliquer la vie avec un thème lourd, un builder, un module de filtres, un plugin d’avis, un consentement mal configuré ou une optimisation JS trop agressive.

Le contenu principal peut alors arriver après plusieurs dépendances : script du thème, plugin e-commerce, module d’avis, bloc de prix, lazy loading, consentement, widget tiers. Si tout fonctionne pour un visiteur connecté ou pour votre navigateur habituel, ce n’est pas encore une preuve suffisante.

Sur un site e-commerce, le risque est plus visible. Prix, disponibilité, variantes, avis, données structurées et produits liés sont souvent chargés par petits morceaux. Si Google voit seulement une page partielle, une catégorie vide ou une erreur servie en 200, la page perd une partie de sa valeur.

Ce point rejoint aussi la lecture des rapports IA générative dans Search Console : avant de chercher à comprendre pourquoi une page apparaît ou non dans de nouveaux rapports, il faut déjà s’assurer qu’elle est techniquement accessible, indexable et cohérente.

Contrôle en 20 minutes

Voici une méthode simple pour éviter de se perdre.

1. Choisissez 5 URL critiques : une page d’accueil, une catégorie, une fiche ou page avis, une page ancienne qui ranke, une page nouvellement modifiée.
2. Vérifiez le statut HTTP avec le navigateur, un outil de crawl ou une commande type curl -I.
3. Comparez le HTML initial et le rendu final : le contenu principal existe-t-il avant JavaScript ? Les liens importants sont-ils présents ?
4. Testez dans Search Console avec l’inspection d’URL, puis regardez le rendu et les ressources chargées.
5. Regardez le rapport Pages : soft 404, exclues, explorées non indexées, découvertes non indexées, pages avec redirection.
6. Croisez avec les logs si vous avez migré, changé de CDN, ajouté un WAF ou modifié les routes.
7. Corrigez le modèle de page, pas seulement l’URL si plusieurs pages partagent le même comportement.

Le but n’est pas de tout rendre statique. Le but est de réserver la complexité JavaScript à ce qui améliore l’expérience, sans faire dépendre la compréhension de Google d’un enchaînement fragile.