Un guide pour diagnostiquer les problèmes courants de JavaScript SEO

Soyons honnêtes, JavaScript et SEO ne font pas toujours bon ménage. Pour certains référenceurs, le sujet peut donner l'impression qu'il est enveloppé d'un voile de complexité.

Eh bien, bonne nouvelle : lorsque vous décollez les couches, de nombreux problèmes de référencement basés sur JavaScript reviennent aux principes fondamentaux de la façon dont les robots des moteurs de recherche interagissent avec JavaScript en premier lieu.

Donc, si vous comprenez ces principes fondamentaux, vous pouvez approfondir les problèmes, comprendre leur impact et travailler avec les développeurs pour résoudre ceux qui comptent.

Dans cet article, nous vous aiderons à diagnostiquer certains problèmes courants lorsque les sites sont construits sur des frameworks JS. De plus, nous décomposerons les connaissances de base dont chaque référencement technique a besoin en matière de rendu.

Le rendu en quelques mots

Avant d'entrer dans les détails, parlons d'ensemble.

Pour qu'un moteur de recherche comprenne le contenu alimenté par JavaScript, il doit explorer et afficher la page.

Le problème est que les moteurs de recherche n'ont qu'un nombre limité de ressources à utiliser, ils doivent donc être sélectifs quant au moment où cela vaut la peine de les utiliser. Il n'est pas certain qu'une page sera rendue, même si le crawler l'envoie à la file d'attente de rendu.

S'il choisit de ne pas afficher la page, ou s'il ne peut pas afficher le contenu correctement, cela pourrait être un problème.

Cela dépend de la manière dont le serveur frontal sert HTML dans la réponse initiale du serveur.

Lorsqu'une URL est créée dans le navigateur, un frontal comme React, Vue ou Gatsby générera le code HTML de la page. Un robot d'exploration vérifie si ce code HTML est déjà disponible sur le serveur (HTML "pré-rendu"), avant d'envoyer l'URL en attente de rendu afin qu'il puisse consulter le contenu résultant.

La disponibilité d'un code HTML pré-rendu dépend de la configuration du frontal. Il générera soit le code HTML via le serveur, soit dans le navigateur client.

Rendu côté serveur

Tout est dans le nom. Dans une configuration SSR, le robot d'exploration reçoit une page HTML entièrement rendue sans nécessiter d'exécution et de rendu JS supplémentaires.

Ainsi, même si la page n'est pas rendue, le moteur de recherche peut toujours explorer n'importe quel HTML, contextualiser la page (métadonnées, copie, images) et comprendre sa relation avec d'autres pages (fil d'Ariane, URL canonique, liens internes).

Rendu côté client

Dans CSR, le HTML est généré dans le navigateur avec tous les composants JavaScript. Le JavaScript doit être rendu avant que le HTML ne soit disponible pour l'exploration.

Si le service de rendu choisit de ne pas rendre une page envoyée à la file d'attente, la copie, les URL internes, les liens d'image et même les métadonnées restent indisponibles pour les crawlers.

Par conséquent, les moteurs de recherche n'ont que peu ou pas de contexte pour comprendre la pertinence d'une URL pour les requêtes de recherche.

Remarque : Il peut y avoir un mélange de HTML qui est servi dans la réponse HTML initiale, ainsi que du HTML qui nécessite JS pour s'exécuter afin de rendre (apparaître). Cela dépend de plusieurs facteurs, dont les plus courants incluent le cadre, la manière dont les composants de site individuels sont construits et la configuration du serveur.

La boîte à outils JavaScript SEO

Il existe certainement des outils qui aideront à identifier les problèmes de référencement liés à JavaScript.

Vous pouvez effectuer une grande partie de l'enquête à l'aide des outils du navigateur et de la console de recherche Google. Voici la liste restreinte qui constitue une boîte à outils solide :

• Afficher la source : faites un clic droit sur une page et cliquez sur "Afficher la source" pour voir le code HTML pré-rendu de la page (la réponse initiale du serveur).
• Tester l'URL en direct (inspection d'URL) : affichez une capture d'écran, le code HTML et d'autres détails importants d'une page affichée dans l'onglet d'inspection d'URL de Google Search Console. (De nombreux problèmes de rendu peuvent être détectés en comparant le code HTML pré-rendu à partir de la "source d'affichage" avec le code HTML rendu à partir du test de l'URL en direct dans GSC.)
• Outils de développement Chrome : cliquez avec le bouton droit sur une page et choisissez "Inspecter" pour ouvrir des outils permettant d'afficher les erreurs JavaScript, etc.
• Wappalyzer : découvrez la pile sur laquelle un site est construit et recherchez des informations spécifiques au framework en installant cette extension Chrome gratuite.

Problèmes courants de référencement JavaScript

Problème 1 : le code HTML pré-rendu est universellement indisponible

En plus des implications négatives pour l'exploration et la contextualisation mentionnées précédemment, il y a aussi la question du temps et des ressources nécessaires à un moteur de recherche pour afficher une page.

Si le robot choisit de faire passer une URL par le processus de rendu, elle se retrouvera dans la file d'attente de rendu. Cela se produit car un robot d'exploration peut détecter une disparité entre la structure HTML pré-rendue et rendue. (Ce qui a beaucoup de sens s'il n'y a pas de code HTML pré-rendu !)

Il n'y a aucune garantie quant à la durée d'attente d'une URL pour le service de rendu Web. La meilleure façon d'orienter le WRS vers un rendu opportun est de s'assurer qu'il y a des signaux d'autorité clés sur site illustrant l'importance d'une URL (par exemple, liés dans la barre de navigation supérieure, de nombreux liens internes, référencés comme canoniques). Cela devient un peu compliqué car les signaux d'autorité doivent également être explorés.

Dans Google Search Console, il est possible de savoir si vous envoyez les bons signaux d'autorité aux pages clés ou si vous les faites rester dans les limbes.

Accédez à Pages > Indexation des pages > Crawled – actuellement non indexé et recherchez la présence de pages prioritaires dans la liste.

S'ils sont dans la salle d'attente, c'est parce que Google ne peut pas déterminer s'ils sont suffisamment importants pour y consacrer des ressources.

Causes courantes

Paramètres par défaut

Les frontaux les plus populaires sont configurés "prêts à l'emploi" pour le rendu côté client, il y a donc de fortes chances que les paramètres par défaut soient le coupable.

Si vous vous demandez pourquoi la plupart des interfaces utilisent par défaut la RSE, c'est en raison des avantages en termes de performances. Les développeurs n'aiment pas toujours le SSR, car il peut limiter les possibilités d'accélérer un site et de mettre en œuvre certains éléments interactifs (par exemple, des transitions uniques entre les pages).

Demande d'une seule page

Si un site est une application d'une seule page, il est entièrement enveloppé de JavaScript et génère tous les composants d'une page dans le navigateur (c'est-à-dire tout) est rendu côté client et les nouvelles pages sont servies sans rechargement).

Cela a des implications négatives, dont la plus importante est peut-être que les pages sont potentiellement introuvables.

Cela ne veut pas dire qu'il est impossible de configurer un SPA d'une manière plus conviviale pour le référencement. Mais il y a de fortes chances qu'il y ait un travail de développement important nécessaire pour que cela se produise.

Problème 2 : Certains contenus de page sont inaccessibles aux robots d'exploration

Faire en sorte qu'un moteur de recherche affiche une URL est formidable, tant que tous les éléments sont disponibles pour l'exploration. Que se passe-t-il s'il affiche la page, mais qu'il y a des sections d'une page qui ne sont pas accessibles ?

Par exemple, un référenceur effectue une analyse des liens internes et trouve peu ou pas de liens internes signalés pour une URL liée sur plusieurs pages.

Si le lien ne s'affiche pas dans le rendu HTML de l'outil Tester l'URL en direct, il est probable qu'il soit servi dans des ressources JavaScript auxquelles Google n'a pas accès.

Pour identifier le coupable, il serait judicieux de rechercher des points communs en termes d'emplacement du contenu de page manquant ou des liens internes sur la page à travers les URL.

Par exemple, s'il s'agit d'un lien FAQ qui apparaît dans la même section de chaque page de produit, cela aide grandement les développeurs à affiner un correctif.

Causes courantes

Erreurs JavaScript

Commençons par un avertissement ici. La plupart des erreurs JavaScript que vous rencontrez n'ont pas d'importance pour le référencement.

Donc, si vous partez à la recherche d'erreurs, apportez une longue liste à votre développeur et démarrez la conversation avec "Quelles sont toutes ces erreurs ?", il se peut qu'il ne la perçoive pas très bien.

Approchez avec le "pourquoi" en parlant du problème, afin qu'ils puissent être l'expert JavaScript (parce qu'ils le sont !).

Cela étant dit, il existe des erreurs de syntaxe qui pourraient rendre le reste de la page inanalysable (par exemple, "blocage du rendu"). Lorsque cela se produit, le moteur de rendu ne peut pas décomposer les éléments HTML individuels, structurer le contenu dans le DOM ou comprendre les relations.

Généralement, ces types d'erreurs sont reconnaissables car ils ont également une sorte d'effet dans la vue du navigateur.

En plus de la confirmation visuelle, il est également possible de voir les erreurs JavaScript en cliquant avec le bouton droit sur la page, en choisissant « inspecter » et en naviguant vers l'onglet « Console ».

Le contenu nécessite une interaction de l'utilisateur

L'une des choses les plus importantes à retenir à propos du rendu est que Google ne peut pas rendre de contenu qui oblige les utilisateurs à interagir avec la page. Ou, pour le dire plus simplement, il ne peut pas "cliquer" sur les choses.

Pourquoi est-ce important? Pensez à notre vieil ami fidèle, la liste déroulante accordéon, et au nombre de sites qui l'utilisent pour organiser le contenu comme les détails des produits et les FAQ.

Selon la façon dont l'accordéon est codé, Google peut être incapable de rendre le contenu dans la liste déroulante s'il ne se remplit pas jusqu'à l'exécution de JS.

Pour vérifier, vous pouvez "Inspecter" une page, et voir si le contenu "caché" (ce qui s'affiche une fois que vous cliquez sur un accordéon) est dans le HTML.

Si ce n'est pas le cas, cela signifie que Googlebot et les autres robots d'exploration ne voient pas ce contenu dans la version rendue de la page.

Problème 3 : Les sections d'un site ne sont pas explorées

Google peut afficher ou non votre page s'il l'explore et l'envoie dans la file d'attente. S'il n'explore pas la page, même cette opportunité n'est pas envisageable.

Pour savoir si Google explore des pages, le rapport Crawl Stats peut être utile dans Paramètres > Statistiques d'exploration .

Sélectionnez Demandes de crawl : OK (200) pour voir toutes les instances de crawl de 200 pages d'état au cours des trois derniers mois. Ensuite, utilisez le filtrage pour rechercher des URL individuelles ou des répertoires entiers.

Si les URL n'apparaissent pas dans les journaux d'exploration, il y a de fortes chances que Google ne soit pas en mesure de découvrir les pages et de les explorer (ou qu'il ne s'agisse pas de 200 pages, ce qui est un tout autre problème).

Causes courantes

Les liens internes ne sont pas explorables

Les liens sont les panneaux de signalisation que les robots d'exploration suivent vers de nouvelles pages. C'est l'une des raisons pour lesquelles les pages orphelines sont un si gros problème.

Si vous avez un site bien lié et que des pages orphelines apparaissent dans les audits de votre site, il y a de fortes chances que ce soit parce que les liens ne sont pas disponibles dans le code HTML pré-rendu.

Un moyen simple de vérifier consiste à accéder à une URL qui renvoie à la page orpheline signalée. Faites un clic droit sur la page et cliquez sur "Afficher la source".

Ensuite, utilisez CMD + f pour rechercher l'URL de la page orpheline. S'il n'apparaît pas dans le code HTML pré-rendu mais apparaît sur la page lors du rendu dans le navigateur, passez au numéro quatre.

Sitemap XML non mis à jour

Le sitemap XML est crucial pour aider Google à découvrir de nouvelles pages et à comprendre quelles URL prioriser dans un crawl.

Sans le sitemap XML, la découverte de pages n'est possible qu'en suivant les liens.

Ainsi, pour les sites sans code HTML pré-rendu, un sitemap obsolète ou manquant signifie attendre que Google rende les pages, suive les liens internes vers d'autres pages, les mette en file d'attente, les rende, suive leurs liens, etc.

Selon le frontal que vous utilisez, vous pouvez avoir accès à des plugins qui peuvent créer des sitemaps XML dynamiques.

Ils ont souvent besoin de personnalisation, il est donc important que les référenceurs documentent avec diligence toutes les URL qui ne devraient pas figurer dans le plan du site et la logique expliquant pourquoi.

Cela devrait être relativement facile à vérifier en exécutant le plan du site via votre outil de référencement préféré.

Problème 4 : les liens internes sont manquants

L'indisponibilité des liens internes vers les crawlers n'est pas seulement un problème potentiel de découverte, c'est aussi un problème d'équité. Étant donné que les liens transmettent l'équité SEO de l'URL de référence à l'URL cible, ils constituent un facteur important dans la croissance de l'autorité de la page et du domaine.

Les liens de la page d'accueil en sont un excellent exemple. C'est généralement la page qui fait le plus autorité sur un site Web, donc un lien vers une autre page de la page d'accueil a beaucoup de poids.

Si ces liens ne sont pas explorables, c'est un peu comme avoir un sabre laser cassé. L'un de vos outils les plus puissants est rendu inutile (jeu de mots).

Causes courantes

Interaction de l'utilisateur requise pour accéder au lien

L'exemple d'accordéon que nous avons utilisé précédemment n'est qu'un cas où le contenu est caché derrière une interaction de l'utilisateur. Un autre qui peut avoir des implications étendues est la pagination à défilement infini - en particulier pour les sites de commerce électronique avec des catalogues de produits substantiels.

Dans une configuration de défilement infini, d'innombrables produits sur une page de liste de produits (catégorie) ne se chargeront pas à moins qu'un utilisateur ne défile au-delà d'un certain point (chargement paresseux) ou n'appuie sur le bouton "Afficher plus".

Ainsi, même si le JavaScript est rendu, un robot d'exploration ne peut pas accéder aux liens internes des produits qui n'ont pas encore été chargés. Cependant, le chargement de tous ces produits sur une seule page aurait un impact négatif sur l'expérience utilisateur en raison des mauvaises performances de la page.

C'est pourquoi les référenceurs préfèrent généralement la vraie pagination dans laquelle chaque page de résultats a une URL distincte et explorable.

Bien qu'il existe des moyens pour un site d'optimiser le chargement différé et d'ajouter tous les produits au HTML pré-rendu, cela conduirait à des différences entre le HTML rendu et le HTML pré-rendu.

En fait, cela crée une raison d'envoyer plus de pages à la file d'attente de rendu et de faire travailler les crawlers plus fort qu'ils n'en ont besoin - et nous savons que ce n'est pas génial pour le référencement.

Au minimum, suivez les recommandations de Google pour optimiser le défilement infini.

Liens mal codés

Lorsque Google explore un site ou affiche une URL dans la file d'attente, il télécharge une version sans état d'une page. C'est en grande partie pourquoi il est si important d'utiliser des balises href et des ancres appropriées (la structure de liaison que vous voyez le plus souvent). Un robot d'exploration ne peut pas suivre les formats de lien tels que router, span ou onClick.

Peut suivre:

• <a href="https://example.com">
• <a href="/relatif/chemin/fichier">

Impossible de suivre :

• <a routerLink="un/chemin">
• <span href="https://example.com">
• <a>

Pour les besoins d'un développeur, ce sont tous des moyens valables de coder des liens. Les implications SEO sont une couche supplémentaire de contexte, et ce n'est pas leur travail de savoir - c'est celui du SEO.

Une grande partie du travail d'un bon référenceur consiste à fournir aux développeurs ce contexte par le biais de la documentation.

Problème 5 : les métadonnées sont manquantes

Dans une page HTML, les métadonnées telles que le titre, la description, l'URL canonique et la balise meta robots sont toutes imbriquées dans l'en-tête.

Pour des raisons évidentes, les métadonnées manquantes sont préjudiciables pour le référencement, mais encore plus pour les SPA. Des éléments comme une URL canonique auto-référençante sont cruciaux pour améliorer les chances qu'une page JS passe avec succès dans la file d'attente de rendu.

De tous les éléments qui doivent être présents dans le code HTML pré-rendu, l'en-tête est le plus important pour l'indexation.

Heureusement, ce problème est assez facile à détecter, car il déclenchera une abondance d'erreurs pour les métadonnées manquantes dans l'outil de référencement qu'un site utilise pour les rapports d'hygiène. Ensuite, vous pouvez confirmer en recherchant la tête dans le code source.

Causes courantes

Véhicule de métadonnées manquant ou mal configuré

Dans un framework JS, un plugin crée la tête et insère les métadonnées dans la tête. (L'exemple le plus populaire est React Helmet.) Même si un plugin est déjà installé, il doit généralement être configuré correctement.

Encore une fois, c'est un domaine où tout ce que les référenceurs peuvent faire est de soumettre le problème au développeur, d'expliquer pourquoi et de travailler en étroite collaboration vers des critères d'acceptation bien documentés.

Problème 6 : Les ressources ne sont pas explorées

Les fichiers de script et les images sont des blocs de construction essentiels dans le processus de rendu.

Puisqu'ils ont également leurs propres URL, les lois de l'exploration s'appliquent également à eux. Si l'exploration des fichiers est bloquée, Google ne peut pas analyser la page pour l'afficher.

Pour voir si les URL sont explorées, vous pouvez afficher les demandes passées dans les statistiques d'exploration GSC.

• Images : accédez à Paramètres > Statistiques d'exploration > Demandes d'exploration : Image
• JavaScript : accédez à Paramètres > Statistiques d'exploration > Demandes d'exploration : Image

Causes courantes

Répertoire bloqué par robots.txt

Les URL de script et d'image s'imbriquent généralement dans leur propre sous-domaine ou sous-dossier dédié, de sorte qu'une expression d'interdiction dans le fichier robots.txt empêchera l'exploration.

Certains outils de référencement vous indiqueront si des fichiers de script ou d'image sont bloqués, mais le problème est assez facile à repérer si vous savez où vos images et vos fichiers de script sont imbriqués. Vous pouvez rechercher ces structures d'URL dans le fichier robots.txt.

Vous pouvez également voir tous les scripts bloqués lors du rendu d'une page en utilisant l'outil d'inspection d'URL dans Google Search Console. « Tester l'URL en direct », puis accédez à Afficher la page testée > Plus d'informations > Ressources de la page .

Ici, vous pouvez voir tous les scripts qui ne se chargent pas pendant le processus de rendu. Si un fichier est bloqué par robots.txt, il sera marqué comme tel.

Faites-vous des amis avec JavaScript

Oui, JavaScript peut entraîner des problèmes de référencement. Mais à mesure que le référencement évolue, les meilleures pratiques deviennent synonymes d'une expérience utilisateur exceptionnelle.

Une excellente expérience utilisateur dépend souvent de JavaScript. Ainsi, bien que le travail d'un référencement ne consiste pas à coder en JavaScript, nous devons savoir comment les moteurs de recherche interagissent avec, le rendent et l'utilisent.

Avec une solide compréhension du processus de rendu et de certains problèmes de référencement courants dans les frameworks JS, vous êtes sur la bonne voie pour identifier les problèmes et être un allié puissant pour vos développeurs.