Site en Javascript & SEO : comment éviter la catastrophe ?

React, Vue, Angular, Backbone, Ember, Aurelia sont des frameworks JS qui font fureur. Ils offrent certes de nombreux avantages : flexibilité, rapidité de développement et langage unique. Mais nous restons perplexes sur l'efficacité de ces technologies pour le SEO.

Depuis quelques années, ces technologies ont le vent en poupe car promues directement par Google. Qui n'hésite pas à communiquer sur sa capacité à indexer ces sites. Les agences de développement en tirent d’ailleurs des conclusions souvent trop hâtives sur le bon référencement de ces sites en Javascript.

L’argument imparable souvent utilisé est qu’Angular est obligatoirement "SEO friendly" puisque développé par des ingénieurs de Google. Or, chez Search Foresight, nous restons très perplexes sur l’efficacité d’un site développé via ces technologies. Surtout quand il s’agit de remonter sur des requêtes concurrentielles. Un Framework JS, à date, n’a aucune chance de performer en SEO sans quelques adaptations que nous vous décrivons dans cet article.

Les sites basés sur JavaScript offrent de grandes opportunités en termes d'expérience utilisateur, car ils sont en général plus interactifs et plus rapides à utiliser. Traditionnellement, les moteurs de recherche ne lisaient que le code HTML d'un site web. Mais au fil des années, ils ont su développer leur capacité à rendre le JavaScript crawlable et indexable, mais non sans effort pour un moteur qui cherche à optimiser son temps d’explorabilité.

A travers ce schéma, on visualise deux situations que le moteur rencontre lors de son crawl quotidien du web.

1. Classic Html content : Google crawl un site avec un rendu html directe. Il en fait un rendu qu’il indexe dans son infrastructure.
2. Javascript content : Le crawl de Google est différé jusqu'à ce que Googlebot dispose de toutes les  ressources disponibles pour traiter ce contenu. De plus, il lui faut environ 5 secondes pour générer le rendu de la page et ainsi s’assurer que tous les appels aux fichiers statiques aient tous bien répondu.

Dit autrement, Google passe trois fois plus de temps pour traiter une page allant de son crawl, son indexation et surtout la rendition de son contenu. Comme vous le savez, les entreprises privées qui sont derrière les moteurs de recherche ont comme souci perpétuel l’optimisation du temps de crawl dû aux milliards de sites à explorer quotidiennement. Et comme le budget de crawl, vous devez lui faciliter ses passages pour que son travail d’indexation se passe dans les meilleures conditions, pour favoriser votre site dans les pages de résultat.

De plus, avec la communication positive de Google sur sa capacité à crawler et à indexer un site en Javascript, peu de SEO confirment qu’un site avec un framework JS performe sans aucune intervention sur la génération d’un contenu html et de ses URLs. Et malgré l’enthousiasme de vos développeurs ou de  votre agence technique qui y trouvent leur compte dans ce choix technologique, il est impératif, pour le moment, d'activer une solution de génération d’HTML sans quoi, votre refonte sera tragique.

Les indicateurs d’aide à la décision

Dans votre réflexion, vous devez toujours avoir en tête votre part de trafic Search qui réalise votre audience. Si cette part est ou doit devenir importante, refondre son site avec un Framework Javascript aura aussi bien un impact sur la visibilité naturel de votre site mais aussi sur les enchères de vos annonces payantes (SEA). En effet, vous risquez de payer plus cher vos mots clés si Google ne comprend pas bien votre contenu.

L’international est également un sujet à prendre en compte car peu de moteurs de recherche sont véritablement capables de comprendre le contenu de votre site en Javascript sans SSR.

Différence entre CSR et SSR

• Dans l'approche traditionnelle (rendu côté serveur), un navigateur ou Googlebot reçoit un HTML qui décrit totalement la page. La copie du contenu est déjà là - votre navigateur (ou Googlebot) a juste besoin de télécharger du CSS et de "peindre" le contenu à l'écran. Les moteurs de recherche ne rencontrent généralement aucun problème avec le contenu rendu côté serveur.
• L'approche de rendu côté client est de plus en plus populaire et un peu différente et les moteurs de recherche ont parfois du mal à faire le lien. Ici, il est assez courant qu'au moment du chargement initial, un navigateur ou Googlebot obtienne une page HTML vierge (avec peu ou pas de copie de contenu). Ensuite, la magie opère : le JavaScript télécharge de manière asynchrone la copie du contenu du serveur et met à jour votre écran (et modifie le DOM).
• Si vous avez un site web rendu côté client, vous devez donc vous assurer que Google peut l'explorer et le rendre correctement.

En effet, le principal frein d’un site utilisant ces technologies sera de charger le contenu à l’appel du navigateur (côté client) avec pour conséquence de ne pas voir son contenu présent dans le code.

Qu’est-ce que recommande Google ?

La méthode Hybrid Rendering / Isomorphic or Universal

Le code HTML pré-rendu est envoyé aux utilisateurs et aux moteurs de recherche. Ensuite, le serveur ajoute le JavaScript nécessaire pour mettre en musique votre page.

Des outils tiers existent pour produire la version html nécessaire aux moteurs de recherche : Puppeteer, Rendertron.

La méthode du Dynamic Rendering / Prerendering

Cette méthode envoie le contenu rendu côté client aux utilisateurs tandis que les moteurs de recherche obtiennent le contenu rendu côté serveur. Ainsi votre site détecte dynamiquement s'il s'agit d'une demande de moteur de recherche. Et pour ceux qui se posent la question, non ce n’est pas considéré comme du cloaking car le contenu doit être iso.

L'utilisation des escaped fragments ou de la méthode pushstate n'est plus recommandée par Google.

Les outils de mise en œuvre du prérendu : Prerender.io, BromBone, PhantomJS aboutissent à une version statique en cache de vos pages.

Les meilleurs frameworks Javascript pour faire du SEO

Parmi la liste des frameworks, certains ont nativement la fonctionnalité d’un rendu HTML côté serveur pour les moteurs de recherche : React et Angular 2.0. Les autres framework doivent fonctionner avec un service de pré-rendu tiers.

Angular et React sont pensés pour le SEO

Les nouvelles versions d'Angular (4 avec Universal) et ReactJS ont une capacité de rendu côté serveur disponible, ce qui apporte également un certain nombre d'avantages supplémentaires. Passer à la dernière version serait la solution idéale pour éviter le rendu SSR classique de l’Ajax, qui garantit que tous les moteurs de recherche, réseaux sociaux, etc. peuvent lire de manière cohérente et précise le contenu de votre site.

React + NextJS

Depuis le début de sa création, React JS supporte le rendu serveur. Autrefois, on les appelait Application Universal, aujourd’hui, c'est une Application SSR (Server Side Rendering). On peut donc depuis toujours rendre une Web App React JS côté serveur.

La difficulté vient des requêtes externes pour récupérer les datas. Les appels sont asynchrones et il faut donc gérer la réception des réponses avant de rendre l’application. Il faut également gérer les librairies pour être compatible SSR.

Next JS est idéale si vous souhaitez mettre en place une application Web performante et indexable par les moteurs de recherche.

Pour la gestion des balises meta Title et Description, Next JS utilise la librairie next/head au lieu de react-helmet. Pas de panique, elle s'implémente de la même manière.

L’équivalent pour Vue JS est Nuxt JS.

Conclusion

• Pour que votre site web soit optimisé pour les moteurs de recherche, vous devez vous assurer que les robots peuvent voir votre contenu et qu'ils peuvent voir et suivre votre navigation. Vous pouvez minimiser les risques en fournissant un contenu important au format HTML et en n'utilisant JS que comme il est prévu pour des fonctionnalités supplémentaires.
• Les moteurs de recherche n’interagissent pas avec la page : le contenu important doit être chargé par défaut et non en fonction d’une interaction de l’utilisateur (clic, survol de la souris, défilement…).
• Vous devez utiliser des liens <a href=…> : les liens ng-click, onclick ou href = "javascript : void (o);" peuvent ne pas être considérés comme des liens (donc non explorés) sauf si vous incluez également <a href=…>.
• Assurez-vous que toutes les ressources nécessaires au rendu sont explorables (non bloquées dans le fichier robots.txt).