JavaScript SEO : éviter les pièges du rendu côté serveur

Le référencement JavaScript est actuellement l'un des sujets brûlants de l'industrie du référencement, car le Web moderne évolue et de plus en plus de sites Web relancent ou sont construits sur des applications Web basées sur JavaScript, principalement sur React ou AngularJS. Avec cela, plus de complexité est ajoutée au référencement, car nous devons nous assurer que Google est capable de rendre JavaScript efficacement, afin que les pages puissent être indexées et classées correctement. Ceci peut être réalisé en utilisant le rendu côté serveur. Cependant, cela n'est pas sans risque. Dans cet article, je passe en revue cinq erreurs de rendu côté serveur et explique comment vous pouvez les éviter.

Si vous recherchez un accompagnement dans l'optimisation technique de votre site web, pourquoi ne pas prendre rendez-vous sans engagement avec nos consultants Digital Strategies Group et découvrir où ils peuvent vous aider ?

Demander un rendez-vous!

Quels sont les différents types de rendu côté serveur ?

Le pré-rendu de votre site Web pour Google sur votre serveur (rendu côté serveur, SSR) est une option pour garantir que votre site Web JavaScript est compatible avec Googlbot. De cette façon, vous pouvez fournir la version HTML pré-rendu de votre site Web à Google, tandis que l'utilisateur obtient la version de navigateur normale (pas encore rendue).

Cependant, en ce qui concerne le rendu côté serveur, il existe également différentes manières de rendre, comme vous pouvez le voir dans le tableau suivant, qui a été utilement fourni par Google, avec quelques ajouts utiles de Jan-Willem Bobbink.

Il existe trois manières principales de configurer et d'exécuter le rendu côté serveur :

1. Rendu côté serveur avec HTML dynamique

Le rendu côté serveur crée une version HTML rendue de chaque URL à la demande.

2. Rendu statique avec HTML statique

Fondamentalement, cela crée une version HTML pré-rendu (statique) d'une URL à l'avance et la stocke dans le cache.

3. Rendu côté serveur avec (ré)hydratation avec HTML dynamique et JS/DOM

Le serveur fournit une version HTML statique de l'URL et du client (navigateur, etc.) qui inclut déjà un balisage structuré du modèle d'objet de document (DOM). Le client prend cela et le transforme en un DOM dynamique qui peut réagir aux changements côté client et le rendre plus interactif.

Google a publié un excellent aperçu du rendu du Web, avec tous les avantages et inconvénients, ainsi qu'une explication plus approfondie si vous êtes intéressé. Mais tout d'abord, si vous cherchez de l'aide sur le thème du JavaScript SEO ou du Server Side Rendering, assurez-vous de nous contacter ici au Searchmetrics Digital Strategies Group.

Entrer en contact!

Pièges lors du rendu de sites Web JavaScript via le serveur

Nous avons récemment rencontré des problèmes de SSR avec l'un de nos clients. Ils exécutent leur site Web sur Angular JS et le rendent avec Rendertron via un Headless Chrome.

Ils utilisent une approche de rendu SSR statique, ce qui signifie qu'ils rendent une page et mettent en cache le HTML rendu sur le serveur (à l'avance). Le code HTML mis en cache ne sera pas remplacé automatiquement mais est basé sur la logique de rendu. Voici cinq problèmes que nous avons rencontrés en travaillant sur ce site Web. Je les partage avec vous ici, afin que si vous avez des défis similaires, vous ayez une idée de la façon de les gérer. Cependant, cela peut être considéré comme une liste inachevée/extensible.

1. Quand vous ne faites rien

Lorsque vous ne vous souciez pas et ne faites pas attention à la façon dont Google rend votre page, laissez-moi vous montrer comment Google rend (voit réellement) votre page. Ceci est basé sur un site Web construit sur une application monopage (SPA) utilisant un framework JavaScript, sans rendu côté serveur.

Cela ne semble pas particulièrement prometteur, n'est-ce pas ? C'est exactement pourquoi il est important d'utiliser SSR, car il ressemble alors à ceci :

2 . Pagination

Comment gérer vos pages paginées en matière de rendu ? Eh bien, surtout dans l'édition, les pages paginées peuvent toujours être une bonne chose pour servir Google avec vos articles (les plus récents) pendant que Google les explore. Si vous jetez un œil à vos fichiers journaux, vous verrez comment Google accède à votre pagination, afin que vous sachiez où il est logique de fournir une version pré-rendu (Spoiler : vous n'avez pas besoin de fournir 399 URL avec une version rendue )

Comme notre client rend avec une approche SSR statique, il vient de rendre la première page et de refléter la version en cache de la page 1 jusqu'à la page 10. Sans aucune version rendue à partir de la page 11 et au-delà. Voici deux captures d'écran qui montrent assez bien le problème, avec exactement le même contenu de la page 1 également fourni aux pages 2-10.

Cela signifie que vous donnez à Google 10 pages avec le même contenu et les mêmes articles. Idéalement, vous souhaitez que Google rende toutes les pages uniques avec des articles correctement paginés.

3 . Renouveler la version rendue des pages de catégorie après la publication d'un nouvel article/produit

Notre client a augmenté son classement dans presque toutes les propriétés Google Actualités de manière assez significative, telles que les carrousels AMP, les boîtes d'actualités Google et les boîtes d'actualités mobiles, à l'exception des carrousels d'éditeurs. Nous avons commencé à enquêter sur cela et il s'est avéré que notre client n'a pas mis à jour sa version en cache lorsqu'un nouvel article a été publié. Nous avons découvert qu'ils ont renouvelé leur version en cache des catégories principales une semaine plus tard :

et sur les sous-catégories même un mois plus tard.

Cela a conduit au fait qu'ils avaient encore un vieil article sur le sujet du Brexit dans leur version pré-rendue, mais ils n'avaient pas tous les nouveaux articles publiés sur le sujet. Notre hypothèse ici est qu'en raison de ce problème, il n'y avait pas assez d'articles frais pour que Google remplisse un carrousel, ce qui a eu un impact négatif important sur leurs performances. Nous étudions toujours l'impact du changement.

4 . Le rendu peut entraîner un contenu dupliqué et une mauvaise canonisation

La fourniture d'une version pré-rendu d'une URL peut entraîner des problèmes système. Comme notre client livrait des pages pré-rendues, chacune avec sa propre URL créée par le moteur de rendu, ces URL avaient les paramètres « p=1 ; render=1" et étaient entièrement indexables :

Il y avait même un nouveau canonique mis en place par le moteur SSR pour cette URL. Assez effrayant, hein?

Idéalement, vous souhaitez exclure ces paramètres de l'exploration Google.

5 . Modification du titre de la page lors du rendu

Nous avons également découvert que les titres des pages actuelles étaient rendus via JavaScript. Cela a été fait d'une manière qui signifiait que le méta-titre HTML affichait toujours le nom de la marque lorsque JavaScript était désactivé. Et lorsque l'agent utilisateur n'est pas Googlebot, il n'affiche que le titre de la page HTML. Voir les deux exemples suivants ci-dessous. Le premier montre l'URL avec JavaScript désactivé. La seconde est la même URL, mais avec JavaScript activé.

Pour vous assurer que les métadonnées sont toujours rendues correctement, vous devez les inclure dans la version non rendue (JavaScript) de l'URL.

Conclusion

Le rendu côté serveur ne peut pas être utilisé comme une approche à l'emporte-pièce pour rendre les applications d'une seule page. Une attention particulière est nécessaire pour les approches statiques où vous ne fournissez qu'un instantané. Comme vous pouvez le voir dans l'exemple de notre client, vous devez vous assurer que le moteur SSR fournit toujours une version à jour de l'URL, sinon Google ne verra pas et ne capturera pas vos articles les plus récents, et vous serez passer à côté d'un trafic précieux.

Avant de relancer d'un site Web basé sur HTML vers un framework basé sur JavaScript, assurez-vous que le rendu côté serveur est inclus et qu'il est toujours dynamique !

Si vous rencontrez des problèmes avec JavaScript ou si vous recherchez une assistance pour l'optimisation technique de votre site Web, pourquoi ne pas prendre rendez-vous sans engagement avec nos consultants du groupe Stratégies numériques et découvrir où ils peuvent vous aider ?

Demander un rendez-vous!