Audit technique SEO et crawl javascript

Les sites web utilisent des tas de fonctionnalités pour améliorer l’expérience utilisateur comme des menus de navigation, des liens vers des produits associés, des blocs de témoignages, des carrousels, etc… qui utilisent du code javascript développé « maison » ou via des services tiers (ex: jquery). Est ce que ces fonctions javascripts ne se font pas au détriment du SEO ? Comment Les moteurs de recherche perçoivent ces contenus générés en javascript ? Comment Google gère le crawl javascript ?

Google dit crawler le javascript mais jusqu’à quel point et dans quelles conditions ? Toutes ces questions soulèvent un vrai défi pour les développeurs qui, bien souvent, ont du mal à développer des pages avec du javascript tout en respectant les bonnes pratiques SEO. En fait, ils s’en foutent la plupart du temps. 😉 Beaucoup de référenceurs eux-mêmes, surtout si ils sont peu techniques, ont du mal à s’assurer qu’un contenu sera bien indexable lorsqu’il s’agit de javascript. Il y a quelques années en arrière, le réflexe de tout bon référenceur face a du contenu stratégique généré en javascript était simplement de le transformer en HTML.

Mais aujourd’hui la réponse SEO devrait être beaucoup plus nuancée car l’objectif n’est pas de se passer du javascript, surtout lorsqu’il apporte un vrai plus en terme d’expérience utilisateur, mais de minimiser les impacts négatifs sur le comportement des moteurs de recherche. Tout audit SEO, technique ou pas, devrait prendre en compte la manière dont google crawle, indexe et positionne une page avec du javascript tout en préservant la meilleure expérience utilisateur possible.

Est ce que les moteurs de recherche crawle le javascript ?

Et bien oui et non. Google crawle plus ou moins bien le javascript. J’ai bien dit « plus ou moins », car ce serait une erreur de penser que Google crawle totalement et parfaitement le javascript. Et ce serait même risqué de le penser, surtout pour des sites qui utilisent massivement du javascript. De plus, Google est le seul moteur de recherche à crawler plus ou moins bien le javascript, ce qui est déjà pas mal lorsque celui-ci représente plus de 90% des parts de marché en France. Mais pour un site dédié à l’international, c’est un point crucial à considérer et il faut donc éviter d’avoir recours au javascript pour afficher des contenus importants.

Ce que dit Google

Depuis 2008, Google à commencer à lire le flash (c’est du javascript) de façon assez limitée.

Depuis au moins 2014, Google exécute le javascript. C’est pas faux, on peut facilement en avoir la preuve en utilisant l’outil « explorer comme Google » de search console . Mais ça manque de précisions et ils mettent souvent des «  » dans leurs déclarations. En gros, ils disent qu’en « général », ils sont capables d’afficher et de comprendre du contenu en javascript:

Source

La corollaire c’est que Google n’est pas toujours capable d’afficher et de comprendre tout le contenu en javascript.

Ils disent aussi qu’il faut respecter le principe de l’amélioration progressive dans la construction d’un site, soit de proposer des pages accessibles au plus grand nombre, simples et en proposant des fonctions supplémentaires en fonction de l’équipement des internautes. Ce principe met clairement le HTML en priorité.:

Source

Ce que dit Google sur le javascript et le SEO en vidéo

Dans cette première vidéo d’une série consacrée au javascript et au SEO, il dit que le javascript est vu à posteriori par Google. Il utilise le crawler html pour indexer rapidement la page, puis se réserve le droit de revenir plus tard avec un crawl javascript si la page utilise du javascript. Ça signifie que ce n’est pas systématique. D’ailleurs à la fin de la vidéo, il dit qu’il vaut mieux s’assurer que le contenu important d’une page soit bien visible en html.

Ce que disent les tests

On peut retrouver de nombreux tests sur le web qui prouvent que Google indexe bien du contenu en javascript. Mais il ne faudrait pas prendre ces tests souvent basiques comme une généralité et une vérité absolue. La réalité est plus complexe, parfois Google indexe parfaitement du contenu en javascript et parfois il le fait pas. Dans ce dernier cas, on a rarement des explications d’ailleurs. Le mieux c’est de tester l’indexabilité de sa propre intégration sur un groupe de pages avant de lancer tout un site en live, au risque de perdre du trafic. Voici un lien vers un projet très intéressant qui teste l’indexation de différentes implémentations javascripts. Et un autre lien vers un article avec des tests basiques mais concluants.

D’après mes tests

Dans mes audits SEO de mes clients, je constate aussi que ce n’est pas si simple, parfois il indexe et parfois non. Plus étrange, Au sein d’un même site,  des commentaires javascripts sont indéxés sur une page et sur une autre page, le même bloc de commentaires n’est pas indexé (la page est indéxée en revanche). Ce qui a tendance à confirmer qu’on a d’un côté un bot HTML et de l’autre un bot JAVASCRIPT, ou alors que le même bot (googlebot) ne crawle pas toujours le javascript mais seulement le HTML dans certains cas. Un de ces cas serait que Le « bot javascript » ne crawlerait que les pages les plus populaires car ce bot est plus gourmand en ressources que le bot HTML. Je précise que c’est des suppositions mais ce serait cohérent avec plusieurs de mes constats.

Comment marche le chargement javascript d’une page ?

Processus du crawl Html et javascript par Google

Avant d’aller au prochain point et comprendre comment Google crawle le javascript, il est d’abord important de comprendre globalement le mécanisme de chargement d’une page par un navigateur. Googlebot n’étant rien d’autre qu’un navigateur headless (sans tête), c’est à dire qu’il ne construit pas visuellement la page mais se contente d’extraire du code.

Le crawl HTML

Voici le processus simplifié du crawl d’une page HTML par un bot HTML:

1. Le bot fait une requête GET au serveur
2. Le bot télécharge le HTML brut de la page (l’équivalent de ce que vous voyez en affichant le code source d’une page > CTRL + U)
3. Le bot analyse la page, son contenu texte, et les différentes propriétés associés comme les méta (description,..), les balises (canoniques, noindex, schema.org, …) et autres propriétés associés
4. La page est indéxée (ou pas), évaluée et positionnée selon tout un tas de critères (plus de 100 critères algorithmiques)

Le problème avec cette méthode est qu’elle ne permet pas de visualiser ce que voit l’internaute sur son navigateur. Ce qu’il y a dans le code source ne correspond pas fidèlement à ce que voit l’utilisateur. Le javascript modifie et transforme le contenu HTML brut avant d’afficher le rendu final. C’est pour ça que Googlebot utilise un navigateur headless au lieu de se baser uniquement sur le document HTML d’une page.

Le crawl JAVASCRIPT

Voici à présent le processus simplifié du crawler javascript Googlebot ou d’un navigateur:

1. Requête initiale: Le navigateur (ou googlebot) fait une requête GET de la page et des ressources associées (JS, CSS,..)
2. Construction du DOM: Le navigateur (ou googlebot) construit le DOM. En gros, Le DOM c’est simplement la manière dont le contenu de la page est mis en forme et positionné, il permet d’interpréter visuellement la page.
3. DOM chargé (DOM Loaded): Le navigateur (ou googlebot) signale au serveur qu’il a terminé de charger et d’analyser le DOM et qu’il est prêt à interpréter le javascript.
4. Exécution du javascript: Le javascript réalise des changements sur la page, des ajouts, des suppressions, des modifications, il recode la page en quelque sorte. Ce nouveau code peut être bien différent du code source original. Ce nouveau code peut être vu en utilisant « inspecter l’élément » sur votre navigateur >> CTRL + SHIFT + I
5. Evènement Load (LOAD event): L’évènement LOAD est déclenché par le navigateur pour signalé au serveur qu’une ressource et ses dépendances sont chargées. Ça signifie en général qu’une page a fini de charger.
6. Evènements post chargements: Une page peut continuer à changer avec du nouveau contenu envoyé, via des interactions de l’utilisateur ou encore par des événements déclenchés par des services tiers. On va voir que ce delta entre l’événement LOAD et cette étape est importante pour la suite.

Comment google crawle le javascript ?

Google analyse donc le même contenu disponible pour l’utilisateur, celui qu’on voit dans « inspecter l’élément » ou presque , car il existe plusieurs limitations qu’on verra par la suite. Il connait aussi 2 versions du code la page, le code source brut et le code généré après le DOM. Le plus souvent, lorsqu’il connait la deuxième version, il utilisera ce dernier en priorité mais il peut utiliser des signaux provenant des 2 versions, notamment en cas de contradictions entre la version HTML brut et le rendu HTML final.

Importance de l’évènement LOAD

Sur search console : explorer comme Google , Ce qui est affiché c’est le rendu HTML au moment de l’évènement LOAD (LOAD event). Google doit bien prendre une capture de la page à un moment donné et il semble que ce soit à ce moment là. Ceci dit, Le moment exact de la capture de la page varie surement plus ou moins en fonction du contexte, des performances, etc… Ça signifie que ce qui est chargé après ce moment là n’est pas pris en compte par  google. L’objectif est donc de faire en sorte que tout le contenu important soit bien chargé avant cet Evènement LOAD.

On peut facilement voir le moment de ce LOAD event en utilisant la console de votre navigateur :

Exemple de timeline d’un site et load event au niveau de la ligne rouge

La ligne rouge représente l’évènement LOAD, soit le moment où Google capture la page. On constate que la page continue de charger après cet événement et ce contenu sera ignoré par  google. Par ailleurs, la ligne verte est le moment où le navigateur commence à construire visuellement la page (le DOM) et la ligne bleue signifie que le DOM est chargé et qu’il commence à exécuter le javascript à partir de ce moment là. On remarquera que cette phase post DOM est plus longue que la construction du DOM.

Ce dernier point est important car le temps d’exécution et d’analyse du javascript demande plus de ressources, plus de CPU, plus de temps de la part de Googlebot que la simple analyse du code HTML. On peut donc s’attendre à ce que Google ne crawle pas systématiquement le javascript d’une page et que ça dépende de son autorité. Pour des analyses à grande échelle ou pour des résultats « temps réel » comme le calcul du positionnement sur google actualités, il est probable que  google utilise son crawler « classique » (bot html) pour gagner du temps, le crawl javascript se faisant à posteriori.

Crawl HTML et Crawl Javscript: 2 process séparés

(MAJ 01/06/2017): Un article de distilled fait la même hypothèse sur le fait qu’il y a une file d’attente différente pour l’affichage du javascript et celle du HTML et va même un peu plus loin:

• Certaines pages sont chargées sans exécution du javascript: cad des pages qui n’ont pas besoin de javascript ou des pages jugées non prioritaires par Google
• Certaines pages sont affichées immédiatement: Concerne les pages de sites d’autorité et qui dépendant fortement du JS
• La plupart des pages ont leur JS chargés après le HTML: Le javascript est analysé à posteriori et ainsi de nouveaux liens peuvent être suivi par  googlebot et du nouveau contenu peut être indexé.

Limitations du crawl javascript de Google

• Google ne crawle pas tout le temps le javascript d’une page, ça dépend souvent de son autorité
• Le code vu dans « inspecter l’element » n’est pas tout le temps le même que celui qu’on peut voir dans « explorer comme google » car le moteur de rendu n’est pas aussi puissant que les navigateurs récents, notamment lorsqu’il fait face à des fonctions complexes, imbriqués, etc…
• En plus des problèmes inhérents de Google à interpréter le javascript, les pages sont parfois mal codés et comportent des erreurs qui compliquent la tache de Google.

(MAJ 01/06/2017): Au delà de ça, des tests ont montré que le fait de supprimer la dépendance du javascript pour l’affichage du contenu et des liens, même si ceux sont indexables par Google, a révélé une amélioration du trafic organique de 6% en moyenne:

Augmentation du trafic des moteurs de recherche de 6% en moyenne après suppression de la dépendance des sites testés au javascript

Erreurs fréquentes SEO sur le javascript

• Des urls indexables: Il est toujours nécessaire d’avoir une « vraie » page qui répond normalement en code 200 et qui est donc indexable. La création d’url en javascript (ex: pushstate) ne suffit pas pour créer une vraie page.
• Attributs basiques: les balises title, schema.org, canonical, meta, .. ont toujours besoin d’exister si ces propriétés sont générés en javascript. Le plus sûr ça reste quand même de faire en sorte que ces propriétés essentielles apparaissent dans le code source de la page.
• Liens et images: Il est toujours préférable d’utiliser le code HTML traditionnel pour l’intégration des liens (a href) et des images (img src). Google a parfois du mal avec certaines approches javascripts pour l’intégration des liens et des images. Sauf si on a pu vérifier que l’intégration javascript était bien indexable.
• Attention aux contradictions: Comme on l’a vu, google connait potentiellement 2 versions de la page, code HTML brut et rendu HTML final,  et il est pas rare de voir des contradictions entre les 2. Par exemple, le code source comporte un rel canonical qui a disparu dans le rendu final. Lors d’un audit technique, le bon réflexe est de comparer ces 2 versions.
• Du contenu important chargé après l’événement LOAD: Si du Contenu est chargé après cet évènement, il ne sera pas crawlé et donc pas indéxé.
• Auditer le contenu « inspecter l’élément » et pas le code source: Même si ce n’est pas parfait, c’est toujours plus proche de la perception de Google que le code source. Il y a aussi l’outil « explorer comme google » qui est encore plus précis mais plus compliqué à extraire.
• Le contenu qui dépend de l’interaction d’un internaute n’est pas indexable: Si du contenu est généré uniquement lors d’un événement déclenché par l’utilisateur, il ne sera pas indexable.
• Les urls avec un # ne sont pas indéxées: C’était déja le cas et ça l’est toujours, la partie de l’url après le # ne sera pas crawlé et donc pas indéxée. Exception faite pour le « #! » que google continue de supporter même si cette méthode pour les sites en ajax notamment n’est plus recommandé.
• Trop de javascripts ca reste toujours un problème: On l’a vu, le javascript est plus lent à charger et un site plus lent à crawler ça signifie moins de pages indéxées et donc moins de trafic potentiel. Je rappelle que googlebot a un temps limité pour crawler un site et lui offrir un site rapide, c’est lui rendre service et vous rendre service surtout.
• Bloquer le crawl des JS: Si vous voulez que Google comprenne le javascript d’une page, il faut éviter de bloquer le crawl des fichiers JS dans le robots.txt.

Conseils pour aider Google à comprendre vos pages en javascript

Google nous a livré quelques petits conseils sur cette page  pour l’aider à bien comprendre les informations essentielles d’une page:

• Titres et Méta descriptions uniques : Google dit que vous pouvez utiliser le javascript pour modifier title et meta description grace au javascript. Bon, il faut déja s’assurer que ce que les méta HTML soit bien identique aux méta générées en javascript. Er je vous conseille vivement de ne pas croire Google sur parole la dessus et s’assurer que ce type de données essentielles soient bien en dur dans le code HTML.
• S’assurer que le code javascript soit bien compréhensible par Google: Google admet lui-même qu’il a certaines limitations pour lire les pages en fonction de la technologie javascript utilisée. Il donne d’ailleurs de précieux conseils pour résoudre certains problèmes liés à javascript
• Utiliser des codes HTTP qui ont du sens pour Google: utilisez des codes réponses (200, 404, 301, etc…) qui indiquent clairement à Googlebot si une page peut être explorée , indexée, ou redirigée.
• Utilisez les balises méta-robots judicieusement : Modifier la balise méta-robots peut ne pas fonctionner comme prévu dit-il. C’est bizarre qu’il dise ça d’ailleurs car il dit pourtant qu’on peut modifier sans problèmes les titles via du javascript. Il prévient en tout cas de ne pas utiliser le javascript pour mettre un «noindex» sur une page.
• Utilisez le Lazy-loading pour économiser la bande passante: Utilisez le lazy loading pour charger les images qui sont au dessus de la ligne de flottaison, c’est à dire qui sont visibles à l’écran. Les autres images seront chargées au fur et à mesure du scroll de l’utilisateur. C’est intéréssant car Google admet implicitement que le traitement javascript lui demande plus de ressources qu’un parsing HTML simple, même si on s’en doute.

Voici aussi quelques bonnes pratiques cités par  John Muller de google

En gros, le javascript c’est bien, mais vaux mieux s’assurer de sa compatibilité et assurer l’essentiel avec du bon code HTML

Cet article est amené à évoluer en fonction de mes prochaines découvertes faites lors de mes audits de site web.

A propos de Serge Esteves

Consultant SEO / Webmarketing : Techniques avancées en référencement combinées aux leviers du marketing entrant (UX, CRO, analytics, content marketing, ereputation, ..).