SEO JavaScript : ce que Google lit d'abord

Deux versions de chaque page, lues à deux moments

Quand une adresse est demandée, le serveur répond par un document HTML. Sur un site en pages statiques ou rendu côté serveur, ce document contient déjà le texte, le titre, la description et l'adresse canonique, celle que le moteur doit retenir quand une page a plusieurs adresses. Sur une application rendue dans le navigateur, il contient souvent une coquille : un en-tête minimal et un script, qui va chercher le contenu puis l'écrit dans la page.

Vos visiteurs ne voient pas la différence, puisque leur navigateur exécute le script. Les robots ne l'exécutent pas tous, et pas au même moment.

Google décrit trois étapes dans sa documentation sur JavaScript et la recherche : l'exploration, le rendu, puis l'indexation. À l'exploration, il lit la réponse du serveur. Il place ensuite en file d'attente de rendu les pages qui répondent avec un code 200, sauf celles qu'une consigne lui demande de ne pas indexer. Une page peut y rester quelques secondes, ou plus longtemps. Ce que le script écrit n'existe pour lui qu'après le rendu ; ce que la réponse du serveur disait de la page, il l'a lu avant.

Noindex, canonical, en-tête : trois défauts qui ne se voient pas

La consigne de non-indexation (noindex) est la plus sensible. Google précise que lorsqu'il la rencontre, il peut sauter le rendu et l'exécution du script. Un script qui retire cette consigne une fois la page chargée peut donc ne jamais s'exécuter pour lui : la page reste hors de l'index, alors qu'elle s'affiche normalement chez chaque visiteur. Dans l'autre sens, une consigne ajoutée par le script n'est vue que par un robot qui exécute le script, et la page dit deux choses contraires selon qui la lit.

L'adresse canonique suit une logique voisine. Google accepte qu'elle soit posée par le script, mais demande de ne pas la changer pour une autre valeur que celle du HTML d'origine. Sa page sur les adresses canoniques ajoute que si elle ne peut pas être écrite dans le HTML d'origine, mieux vaut l'y laisser absente et ne la poser que par le script. Deux valeurs différentes sont deux signaux qui se contredisent.

Les balises qui parlent aux moteurs vivent dans l'en-tête de la page, l'élément head. Google n'accepte l'adresse canonique que là, et sa page sur les métadonnées valides précise que dès qu'il rencontre dans l'en-tête un élément qui n'y a pas sa place, une image ou un cadre intégré par exemple, il considère que l'en-tête est terminé et ne lit plus la suite. Un composant peut aussi écrire ces balises directement dans le corps de la page. La description ou l'adresse canonique existe alors, avec la bonne valeur, à un endroit où elle ne compte plus.

Ces défauts suivent souvent un gabarit : les pages construites sur le même modèle sont touchées, les autres sont correctes. Et une balise mal placée reste présente et juste, si bien qu'un contrôle qui vérifie seulement sa présence la trouve.

Sites générés par IA : une seule coquille pour toutes les adresses

Plusieurs outils qui créent un site à partir d'une description produisent une application rendue dans le navigateur. Le serveur y renvoie souvent le même document pour toutes les adresses, avec le même titre et la même description, et le script choisit ensuite quoi afficher. Google, qui rend ces pages, peut voir le contenu de chacune. Un robot qui s'en tient à la réponse du serveur voit une seule page, répétée à chaque adresse.

La même construction a un second effet. Une adresse qui n'existe pas reçoit, elle aussi, le document commun avec un code de succès, et c'est le script qui affiche « page introuvable ». Google appelle cela une soft 404, ou 404 molle, et propose deux remèdes : rediriger par le script vers une adresse qui répond réellement 404, ou ajouter une consigne de non-indexation aux pages d'erreur. Le guide sur ce qu'un site doit répondre à une adresse inexistante explique pourquoi ce code compte.

Ces outils laissent souvent passer d'autres défauts, hors du référencement. Le guide pour vérifier un site créé avec une IA les passe en revue.

Exiger des pages lisibles avant tout script

Ces exigences se posent sans lire une ligne de code, à la personne ou à l'agence qui construit le site, et dans cet ordre.

1. Dressez la liste des pages qui doivent être trouvées dans un moteur : l'accueil, les offres, les fiches produits, les articles. Un espace client ou un tableau de bord derrière une connexion n'en fait pas partie, et peut rester rendu dans le navigateur.
2. Demandez, par écrit, comment ces pages sont rendues : côté serveur, en pages statiques produites à l'avance, ou seulement dans le navigateur. Les exigences qui suivent en dépendent.
3. Pour ces pages, exigez que la réponse du serveur contienne déjà le titre, la description, le texte principal et l'adresse canonique. C'est ce que permettent le rendu côté serveur et le pré-rendu, que Google recommande. Le rendu dynamique, qui sert aux robots une version déjà rendue et aux visiteurs l'application, est décrit par Google comme un contournement, pas une solution durable.
4. Exigez qu'aucune page à indexer ne porte de consigne noindex dans le code envoyé par le serveur, même provisoirement, et que le script ne change jamais l'adresse canonique écrite dans ce code.
5. Exigez que l'adresse canonique, la description et les déclarations de langue soient dans l'en-tête du document, sans image ni cadre intégré placé avant elles.
6. Faites vérifier le résultat par quelqu'un qui n'a pas construit le site, à la mise en ligne puis après chaque refonte. Ces défauts naissent dans un gabarit, et un composant ajouté plus tard suffit à les faire revenir.

Une consigne noindex laissée dans le gabarit, une adresse canonique réécrite par le script, un élément mal placé au début de l'en-tête se corrigent dans le gabarit, une fois pour toutes les pages qui l'utilisent. Ce sont les premiers à faire traiter. Quand une partie des pages est déjà correcte, la bonne façon de faire existe déjà dans le site.

Le chantier est d'une autre taille quand le serveur renvoie la même coquille à chaque adresse. Lui faire envoyer le contenu et les balises de chaque page, par un rendu côté serveur ou un pré-rendu, change la construction du site : cela se planifie, puis se revérifie page par page après la mise en ligne.

Le servi et le rendu, pris dans la même visite

L'audit lit les pages dans un navigateur, comme un visiteur. Pour la page de référence du site, en général l'accueil, il garde aussi le document renvoyé par le serveur avant toute exécution du script. Les deux versions viennent de la même visite : une seconde requête pourrait recevoir autre chose.

• L'adresse canonique et la consigne de non-indexation, dans chacune des deux versions. Une adresse canonique qui n'apparaît qu'après le script, deux adresses canoniques différentes, ou une consigne d'indexation qui change d'une version à l'autre comptent comme un défaut.
• Le titre, le titre principal et la part du texte déjà présents dans la réponse du serveur. Ils sont relevés sans compter comme un défaut : une page dont le texte arrive par le script peut être indexée.
• Le texte présent dans la réponse du serveur et absent de la page affichée. C'est le sens inverse du même écart : un robot lirait un texte qu'aucun visiteur ne voit, ce que les règles de Google contre le spam appellent la dissimulation (cloaking) quand l'intention est de tromper. Le contenu prévu pour les navigateurs sans script et les gabarits non affichés sont écartés, et seul un écart d'un volume significatif est retenu. Le rapport en cite des extraits : c'est un fait relevé, pas un jugement d'intention, car un site peut retirer un bloc au chargement sans rien cacher.
• La position des balises, sur chaque page de l'échantillon. Une adresse canonique, une description ou une déclaration de langue rendue hors de l'en-tête compte comme un défaut, et le rapport dit combien de pages sont touchées et combien sont déjà correctes. Un titre hors de l'en-tête n'est pas compté, puisque le navigateur le lit où qu'il soit, et des données structurées dans le corps de la page sont à leur place.
• Le moment de la lecture. L'audit attend que la page cesse de changer avant de la lire. Une page qui attend encore ses propres données, le titre toujours vide, n'est pas jugée sur cette coquille : elle est relevée comme une page qui ne s'affiche pas à temps.

Si la réponse du serveur n'a pas pu être conservée, la comparaison est déclarée non vérifiable, jamais réussie. Et elle porte sur ce que chaque version contient : le temps que Google met à rendre vos pages, ou l'exploration qu'il accorde au site, se lisent dans ses propres outils, pas de l'extérieur.

Une boutique, un site Webflow : deux versions qui concordent

Ce pourcentage porte sur une vingtaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.

Les deux défauts du sens opposé, une balise qui n'apparaît qu'après le script et une balise rendue hors de l'en-tête, restent chacun un cas isolé dans nos audits. Le plus fréquent est un site dont les deux versions concordent, et le rapport le dit aussi.

Les deux exemples de rapport publiés en sont deux cas, sur des constructions différentes. Le site vitrine B2B est construit avec Webflow : ses balises et son contenu sont dans la réponse du serveur, avant tout script. Sur les 120 pages de la boutique en ligne, l'adresse canonique est dans l'en-tête, et le rapport ne trouve aucun écart entre le texte servi et le texte rendu. Pour ces deux sites, ce que Google lit à l'exploration est déjà ce que voit le visiteur.

Ce site applique la même exigence à lui-même. Il est construit en pages statiques : le titre, la description, l'adresse canonique et les déclarations de langue de chaque page qui doit être trouvée sont dans la réponse du serveur, sans dépendre du script. C'est un choix de construction parmi d'autres ; une application rendue dans le navigateur peut aussi être indexée, à condition de tenir les points ci-dessus.