Quel est l'impact du dynamic rendering sur le SEO ?
Le (dynamic rendering) rendu dynamique lancé par Google à la fin 2018 à pour but de mieux interpréter le JavaScript… C'est du bullshit de la part de Google aka Martin Splitt … Je parie dans quelques années, il va arrêter tout et que les Googlebots pourront comprendre votre site parfaitement…
On rentre très vite dans l'ère de l'Intelligence artificielle aka ChatGPT les lignes vont bouger au niveau du crawl et l'indexation de contenu. Google a déjà fait des petits pas avec son Googlebot Evergreen en 2019…Eh oui c'était pas une révolution totale avec le Chromium… Disons qu'il a les ressources pour améliorer son crawler. C'est juste une question de priorités. Le profit ou l'internaute!
En attendant, ne vous précipitez pas sur cette solution (si vous n'avez pas vraiment besoin) car c'est extrêmement délicat et coûteux à mettre en place. Il demande beaucoup de tests avant d'être déployé correctement.
Attention Google ne va pas indexer toutes vos pages en moyenne 30% ou plus…
- Éviter aux maximums le Javascript sur votre site (eh oui, c'est plus facile à dire qu'à faire.) en tout cas sur les pages stratégiques et faciliter aux maximums le crawl et l'indexation de vos pages…
- Garder un œil attentif sur ces points surtout le budget de crawl.
- Indexing les pages les plus importantes.
En même temps, il faut être conscient que chaque page web qui contient du JavaScript c'est une prise de tête et qui rend le SEO délicat, aussi plus compliqué. Non seulement votre site Web doit être codé de manière à faciliter son traitement par les moteurs de recherche, mais il doit aussi être plus performant et se charger plus rapidement que la concurrence.
Mais en même temps, c'est l'avantage du SEO technique on peut agir sur l'un des facteurs de classement sur lequel vous avez un contrôle direct.
Comment faire pour que votre site JavaScript soit facilement crawlable par Google, tout en offrant à vos visiteurs une superbe expérience Web et obtenir des conversions…
Que se passe-t-il lorsque Google visite votre page Web ?
Google utilise Googlebot (desktop et mobile), pour crawler et indexer et cataloguer chaque page Web sur Internet.
Son objectif principal c'est de fournir à l'utilisateur le meilleur résultat possible pour une requête donnée. Pour ce faire, il cherche à comprendre le contenu d'une page Web donnée et à évaluer son importance relative par rapport aux autres pages Web traitant du même sujet. Même les requêtes les plus complexes : Google MUM.
La plupart des sites web sont réalisés à l'aide de trois principaux langages de programmation :
- HTML
- CSS
- JavaScript.
HTML et JavaScript rendering
Googlebot peut avoir quelques difficultés à traiter et à rendre le code volumineux. Si le code de votre page est désordonné, le robot d'exploration peut ne pas réussir à le rendre correctement et considérer votre page comme vide.
Faites attention au temps de chargement de vos JS. Si un script a besoin de plus de 5 secondes pour se charger, Googlebot ne rendra pas et n'indexera pas le contenu généré par ce script.
Pour savoir quelles ressources de votre page posent des problèmes de rendering (et pour voir si vous avez des problèmes), connectez-vous à votre compte Google Search Console, allez dans Inspection des URL, entrez l'URL que vous voulez vérifier, cliquez sur le bouton Tester l'URL en direct, puis cliquez sur Afficher la page testée.
Allez ensuite dans la section Plus d'informations et cliquez sur les dossiers Page Resources et JavaScript console messages pour voir la liste des ressources que Googlebot n'a pas réussi à rendre.
Concrètement…
Google traite le langage HTML en deux étapes : l'exploration et l'indexation. Tout d'abord, Googlebot explore le code HTML d'une page.
Il lit le texte et les liens sortants d'une page et analyse les mots clés qui l'aident à déterminer le sujet de la page Web. Ensuite, Googlebot indexe la page.
Avec JavaScript, ce processus est plus compliqué. Le rendering ou”rendu” de JavaScript se fait en trois étapes :
Qu'est-ce que le Rendering ?
Google doit traiter votre JavaScript plusieurs fois afin de comprendre parfaitement son contenu. Ce processus est connu sous le nom de rendering. Lorsque Google rencontre du JavaScript sur une page Web, il le place dans une file d'attente et y revient lorsqu'il dispose des ressources nécessaires pour le rendre.
Chaque page Web a deux états – le rendu se fait entre les deux
- L' Initial HTML.
- Rendered HTML.
Du coup un site Web peut être très différent entre ces deux états par exemple:
L' Initial HTML apparaît en premier. Il s'agit de la réponse du serveur. Il contient du HTML et des liens vers des ressources telles que JavaScript, CSS et des images qui sont nécessaires pour construire la page. Pour voir le HTML initial par vous-même, consultez la source de la page de votre site.
Le Rendered HTML est plus largement connu sous le nom de DOM, une abréviation de Document Object Model. Chaque page Web possède un DOM. Il représente le HTML initial plus toutes les modifications apportées par le JavaScript auquel le HTML a fait appel. Pour visualiser le DOM, ouvrez les outils de développement de votre navigateur et cliquez sur l'onglet console.
Un autre point qui est important c'est de savoir la différence entre HTML et DOM pour résoudre les problèmes de référencement JS… Eh oui!
Lorsque le contenu change entre le HTML initial et le DOM, c'est JavaScript côté client qui change de page.
Ces changements indiquent que le JavaScript est exécuté dans le navigateur de l'utilisateur. Lorsque JavaScript est exécuté dans le navigateur de l'utilisateur, nous l'appelons Client-Side Rendering (CSR).
Et c'est là tout se coinse.
Cela met votre page Web en danger. Si quelque chose ne va pas pendant l'exécution, les modifications JavaScript peuvent ne jamais avoir lieu. JavaScript est un processus complexe et la ressource la plus coûteuse de votre site.
Cela ressemble à un problème de développement, oui et non ? Cela dépend! Les SEO ont un rôle important à jouer.
Le problème avec le référencement JavaScript
Le HTML is King
C'est la norme en matière de développement web ( du moins je le crois). Les moteurs de recherche peuvent rendre le contenu basé sur le HTML facilement.
Par contre, il est plus difficile pour les moteurs de recherche de traiter le Javascript. Il est gourmand en ressources disons 100 fois ou plus…
Cela signifie que les pages Web basées sur le langage JavaScript bouffent votre budget de crawl. Google affirme que son robot d'exploration du Web peut traiter JavaScript.
Disons oui et non.
Google a besoin de plus de ressources pour explorer, indexer et rendre vos pages JavaScript. Par exemple le moteur de recherche de Bing n'est pas capable d' analyser du JavaScript.
Étant donné que les moteurs de recherche doivent utiliser davantage de ressources pour rendre vos pages JavaScript, il est probable que de nombreux éléments de votre page ne seront pas du tout indexés. Google et d'autres moteurs de recherche pourraient ignorer vos métadonnées et vos balises canoniques, par exemple, qui sont essentielles pour le référencement.
Le fait est que Javascript offre une bonne expérience utilisateur. C'est la raison pour laquelle vous êtes en mesure de créer dessites Web flashy qui font dire à vos utilisateurs “Superbe, c'est trop cool ce site“.
Non non c'est du bullshit pour le SEO. Passons!
Pouvez-vous me dire de quoi parle ce site… Non… Eh bien c'est pareil pour Googlebot.
Google ne peut pas indexer ce qu'il ne peut restituer.
Comment créer une expérience Web moderne sans sacrifier le référencement ?
La plupart des développeurs y parviennent grâce au rendu côté serveur, certains font aussi du pré-rendering.
Quelle est la différence entre le rendu côté client et le rendu côté serveur ?
La plupart des frameworks JavaScript tels qu'Angular, Vue et React utilisent par défaut le rendu côté client. Ils attendent de charger entièrement le contenu de votre page Web jusqu'à ce qu'ils puissent le faire dans le navigateur de l'utilisateur.
En d'autres termes, ils rendent le contenu pour les humains, plutôt que sur le serveur pour que les moteurs de recherche le voient.
Le rendu côté client est moins cher que les autres solutions. Il réduit également la charge sur vos serveurs sans ajouter de travail supplémentaire pour vos développeurs.
Cependant, il risque d'entraîner une mauvaise expérience pour l'utilisateur. Par exemple, il ajoute quelques secondes de temps de chargement à vos pages Web, ce qui peut entraîner un taux de rebond élevé. Au secours: Core Web Vitals aide- moi…
Le rendu côté client affecte également les robots. Googlebot utilise un système d'indexation en deux temps. Il parcourt et indexe d'abord le code HTML statique, puis le contenu JavaScript lorsqu'il dispose des ressources nécessaires. Cela signifie que votre contenu JavaScript peut passer inaperçu lors du processus d'indexation.
C'est une mauvaise chose. Vous avez besoin que Google voie ce contenu si vous voulez être mieux classé que vos concurrents et être trouvé par vos clients.
Quelle est donc l'alternative ?
En dev, c'est le rendu côté serveur : configurer votre JavaScript de manière à ce que le contenu soit rendu sur le serveur de votre site Web plutôt que sur le navigateur côté client.
Le contenu JavaScript est ainsi rendu à l'avance, ce qui le rend lisible pour les robots. Le SSR ” Server Side Rendering” présente également des avantages en termes de performances qu'on peut optimiser. Les robots et les humains bénéficient d'une expérience plus rapide, et il n'y a aucun risque d'indexation partielle ou de contenu manquant. Penser rendering dynamique.
Les avantages du rendu dynamique
En quoi le rendu dynamique est-il réellement bénéfique pour le référencement et l'activité globale ?
Il aide Google à crawler votre site Web plus rapidement et à tirer le meilleur parti de votre budget de crawl.
Google alloue une certaine quantité de temps et de ressources à chaque site Web qu'on appelle le budget de crawl. Comme indiqué ci-dessus, si votre site Web est difficile à rendre et à explorer, il est probable que le taux de crawl sera plus faible, que toutes vos pages ne seront pas indexées par les robots des moteurs de recherche et que votre contenu n'apparaîtra pas dans les résultats de recherche de Google.
Cela signifie également que davantage de contenu est crawlé et indexé par les robots des moteurs de recherche, sans compromettre la qualité de l'expérience utilisateur (UX).
Grâce au rendu dynamique, les robots des moteurs de recherche sont en mesure d'explorer et d'indexer votre site Web beaucoup plus rapidement et efficacement. Comme les robots des moteurs de recherche peuvent utiliser plus efficacement votre budget d'exploration, ils peuvent indexer plus d'URL et de contenu sur chaque page, ce qui résout efficacement les problèmes d'indexation.
Vous obtiendrez un meilleur retour sur vos investissements en contenu.
Plus de contenu indexé dans Google, plus le retour sur investissement de vos efforts de marketing de contenu et des investissements réalisés dans votre SEO est élevé aka ROI.
Le rendu dynamique est associé à un nombre plus élevé de mots-clés de classement organique, ainsi qu'à une augmentation des impressions organiques, des clics et, finalement, des conversions.
Mais, le SEO c'est du bon sens!
Pourquoi tout le monde n'utilise-t-il pas simplement le rendu côté serveur ?
Eh oui! C'est pas aussi simple que ça…
Si le rendu côté serveur était facile, alors tous les sites Web le feraient et le référencement JavaScript ne serait pas un problème. Mais, le rendu côté serveur n'est pas facile du tout… C'est un truc de ouf je vous le dis…
Le SSR est coûteux, prend du temps et est difficile à mettre en œuvre. Vous avez besoin d'une équipe de développement web compétente pour le mettre en place.
En plus, il fait son égoïste.
Il a également tendance à ne pas fonctionner qu'avec les JavaScript tiers. Les sites Web qui utilisent le rendu côté serveur nécessitent souvent des bibliothèques JavaScript externes ou des plugins difficiles à configurer. (Google a développé des outils dans ce sens… eh ben oui… ).
C'est le cas d'Angular, qui nécessite la bibliothèque universelle Angular pour activer le rendu côté serveur. L'activation du rendu côté serveur avec Angular nécessite un grand nombre de pièces mobiles. Si une seule pièce n'est pas à sa place, cela pourrait dérouter les robots d'exploration du Web et entraîner une baisse de vos résultats de recherche.
React, quant à lui, utilise la bibliothèque Next.JS pour activer le rendu côté serveur. Cela signifie que votre équipe de développement doit maintenir un serveur supplémentaire à un coût supplémentaire.
Alors comment rendre des frameworks comme React SEO friendly pour satisfaire vos clients et les moteurs de recherche ? La solution est le rendu dynamique aka “dynamic rendering”.
Qu'est-ce que le Dynamic Rendering?
Le dynamic rendering est le processus qui consiste à servir le contenu en fonction de “l'user-agent” (et souvent l’IP) qui le demande. Il s'agit essentiellement d'une solution hybride qui offre le meilleur des deux mondes. Elle fournit du HTML statique aux robots et du JavaScript dynamique aux utilisateurs.
Les robots disposent ainsi d'une version de votre page Web lisible par une machine, dépouillée et composée uniquement de texte et de liens, qu'ils peuvent facilement analyser.
Il offre à vos utilisateurs humains une expérience Web entièrement rendue, optimisée et prévue, qui les incite à interagir plus longtemps avec votre site Web.
Ce qu'il faut faire avant la mise en place du dynamic rendering
En fait focus sur le DATA de votre site et le SEO Technique.
- Audit Complet de votre site : crawl data – Log file data – Trafic & conversion data – SERP data
- Robots.txt
- Mise à jour de votre Sitemap
- Attention à votre Maillage interne et Backlinks
- Audit UX
- Nettoyer et Réparer les URL
Comment mettre en œuvre le dynamic rendering ?
La mise en œuvre du dynamic rendering est un processus en trois étapes.
- Premièrement, vous installez un moteur de rendu dynamique (disons Prerender), pour transformer votre contenu dynamique en HTML statique.
- Ensuite, vous choisissez les agents utilisateurs qui, selon vous, devraient recevoir le contenu statique. Dans la plupart des cas, cela inclut les robots d'exploration des moteurs de recherche comme Googlebot et Bingbot. Il peut y en avoir d'autres, comme LinkedInbot, que vous souhaitez également inclure.
Si votre service de prérendu ralentit votre serveur ou si vos demandes HTTP augmentent, envisagez de mettre en place un cache pour stocker le contenu. Ensuite, déterminez si vos agents-utilisateurs ont besoin d'un contenu de desktop ou mobile. Vous pouvez utiliser le service dynamique pour leur offrir la solution appropriée.
3.Enfin, configurez vos serveurs pour fournir du HTML statique. Vérification de votre configuration
Vous devez maintenant vous assurer que le rendu dynamique fonctionne correctement.
Voici quelques éléments à vérifier :
Test Mobile-Friendly : Il s'agit d'une fonction de la suite d'outils de la Google Search Console. Google a effectué le passage à l'indexation mobile-first pour tous les sites Web en septembre 2020. Attention Mobile et desktop rendering ce n'est pas le même crawl penser mobile-first index. En d'autres termes, Google examine la version mobile de votre site Web avant la version du desktop. Il est donc important que votre site Web soit optimisé pour une expérience mobile-first.
Outil d'inspection des URL : Vous devez vous assurer que votre site Web est correctement exploré et indexé. C'est ce que fait l'outil d'inspection des URL.
Fetch as Google : C'est ce que vous utiliserez pour déterminer l'efficacité de votre moteur de rendu dynamique. Il vous permet de vous assurer que les URL individuelles sont correctement soumises à l'indexation.
Outil de test des données structurées : Si vous utilisez le balisage de schéma dans votre site Web, alors vous voudrez utiliser cet outil. Il garantit que votre moteur de rendu dynamique n'interfère pas avec le balisage du schéma.
Quand utiliser le dynamic rendering?
Je vais vous faire une réponse de SEO… Cela dépend…
En fonction de votre présence en ligne, vous n'aurez peut-être jamais à vous soucier du dynamic rendering. Plus précisément, votre site Web n'en a besoin que si vous appartenez à l'une ou plusieurs des catégories ci-dessous.
- Votre site Web est fortement tributaire de JavaScript pour la prise en charge des fonctionnalités de base et des mécanismes de l'interface utilisateur. Si c'est le cas, les robots de Google et de Bing seront souvent bloqués sur vos pages à fort contenu JavaScript, ce qui rendra le processus d'indexation plus difficile. Le rendu dynamique est une solution de rechange naturelle pour éviter que vos fonctionnalités JS ne deviennent un handicap pour le référencement et le crawl.
- Votre site Web publie régulièrement beaucoup de contenu. Dans ce cas, vous bénéficierez de crawls plus fréquents et plus complets qui capturent tout ce nouveau contenu sur une base continue. Le rendu dynamique permet de minimiser le temps d'exploration nécessaire pour chacune de vos pages, ce qui augmente la quantité totale de contenu pouvant être indexé régulièrement.
- Votre site Web est confronté à des problèmes de budget de crawl. Les crawlers n'indexent jamais toutes les pages qu'ils rencontrent, par simple manque de capacité. Votre budget d'exploration, qui correspond au nombre de requêtes qu'un robot crawl fera pour votre site Web, peut empêcher l'indexation de certains de vos meilleurs contenus. Le dynamic rendering peut optimiser votre budget d'exploration car il réduit le temps nécessaire à l'indexation de chaque page.
Ces critères peuvent être pertinents pour un certain nombre d'industries. Les sites Web E-commerce comme Amazon, par exemple, comportent à la fois de grandes quantités de JavaScript et un contenu qui évolue rapidement et nécessite des mises à jour continues. Il en va de même pour les sites Web qui fonctionnent comme des éditeurs par exemple Lefigaro.fr et qui nécessitent une indexation fréquente du contenu nouvellement publié afin de maximiser leur visibilité.
Les petits sites Web relativement statiques ne seront probablement pas concernés. Mais si votre site entre dans l'une des catégories ci-dessus, surtout s'il utilise du JavaScript, le dynamic rendering doit être une priorité de mise en œuvre.
Le dynamic rendering est-il synonyme de Content Cloaking ?
Disons à ce stade les Experts SEO peuvent tirer la sonnette d'alarme.
Mais, en même temps Google n'a-t-il pas créé des règles spécifiques contre “le cloaking de contenu”, c'est-à-dire la tactique consistant à proposer des versions différentes de votre site Web aux utilisateurs et aux robots d'indexation pour ” leurrer les robots” ?
Il est vrai que le cloaking de contenu peut entraîner des pénalités importantes pour les moteurs de recherche. Voici donc la bonne nouvelle : le dynamic rendering n'est pas considéré comme du camouflage ou « occultation » de contenu. Voici ce que dit Google :
En tout cas, ce qu'il faut faire c'est de ne pas tricher et d'être de bonne foi pour que le contenu reste le même, quels que soient les visiteurs (bots ou humain). Tant que seul le processus de rendu est différent, et non le contenu servi aux robots d'exploration et aux visiteurs humains, vous êtes dans le vert.
Pour simplifier, reprenons l'exemple de Google :
- Montrer une page avec du contenu sur les” oiseaux” aux robots d'exploration mais la même page avec du contenu sur des produits pour “perdre du poids “aux visiteurs humains du coup c'est du cloaking et sera pénalisé.
- Montrer le même contenu sur les “oiseaux” aux robots d'exploration et aux visiteurs humains, la seule différence étant un rendu HTML plat pour les robots et un JavaScript dynamique pour les humains, n'est pas considéré comme du cloaking de contenu.
Conclusion
Avant de penser dynamic rendering pour votre site il existe des tas de solutions autres… Mais c'est vrai le dynamic rendering est un moyen idéal pour résoudre vos problèmes de JavaScript SEO mais pas pour tout les sites il faut procéder cas par cas. Car, chaque site est différent.
Pour aller plus loin : JavaScript SEO: Les Bonnes Pratiques en [2023]
Vous souhaitez augmenter votre trafic organique et engager votre audience de manière efficace ?
Besoin d'aide pour débloquer le trafic SEO sur votre site ? Prendre contact avec nous dès maintenant.
Ressources
Chargement du code JavaScript tiers
