Comment optimiser les sites Web réactifs pour les moteurs de recherche et les bots

Les frameworks JavaScript réactifs (tels que React Vue.js et Angular ) font fureur, et ce n'est pas le cas se demandent qu’ils sont utilisés dans de plus en plus de sites Web et d’applications en raison de leur flexibilité, de leur modularité et de la facilité de leurs tests automatisés.

Ces cadres permettent de réaliser de nouvelles choses auparavant impensables sur un site Web ou une application, mais . ] comment fonctionnent-ils en termes de référencement Les pages créées avec ces frameworks sont-elles indexées par Google? Étant donné qu'avec ces frameworks, tout ou presque tout le rendu de la page se fait en JavaScript (et que le HTML téléchargé par les bots est en grande partie vide), il semble que ce soit une solution de rechange si vous souhaitez que vos sites Web soient indexés. moteurs de recherche ou même analysés par les robots en général.

Dans cet article, je parlerai surtout de Vue.js, car c’est le cadre que j’ai le plus utilisé, et avec lequel j’ai une expérience directe en matière d’indexation par le Les moteurs de recherche sur les grands projets, mais je peux supposer que la majeure partie de ce que je vais couvrir est également valable pour d'autres frameworks.

Description du problème

Fonctionnement de l'indexation

Pour que votre site Web soit indexé par Google, il doit être exploré par Googlebot (un logiciel d'indexation automatisé qui visite votre site Web et enregistre le contenu des pages dans son index) en suivant les liens de chaque page. Googlebot recherche également des fichiers XML spéciaux Sitemap dans les sites Web pour rechercher les pages qui pourraient ne pas être liées correctement depuis votre site public et pour recevoir des informations supplémentaires sur la fréquence de modification des pages du site Web et la date à laquelle elles ont été modifiées.

Of History

Jusqu'à il y a quelques années (avant 2009), Google indexait le contenu du code HTML d'un site Web, à l'exception de tout le contenu créé par JavaScript. Il était de notoriété publique dans le référencement que les liens et le contenu importants ne devaient pas être écrits par JavaScript, car ils ne seraient pas indexés par Google, et cela pourrait entraîner une pénalité pour le site Web car Google pourrait le considérer comme un "contenu factice". si le propriétaire du site Web essayait de montrer aux utilisateurs quelque chose de différent de ce qui était présenté aux moteurs de recherche et essayait de le duper.

Les arnaqueurs avaient coutume de mettre beaucoup de contenu SEO-friendly dans le code HTML et de le masquer. en JavaScript, par exemple. Google a toujours mis en garde contre cette pratique :

"Servir à Googlebot un contenu différent de celui qu'un utilisateur normal verrait est considéré comme un acte de camouflage et serait contraire à nos consignes relatives aux webmasters."

Vous pourriez être sanctionné pour cela. . Dans certains cas, vous pourriez être pénalisé pour avoir servi un contenu différent à différents agents utilisateurs côté serveur, mais également pour avoir changé de contenu via JavaScript après le chargement de la page. Je pense que cela montre que Google indexe depuis longtemps les sites Web exécutant JavaScript – tout au moins pour comparer le code HTML final du site (après l'exécution de JavaScript) et le code HTML brut qu'il analysait pour ses index. Mais Googlebot n'exécutait pas toujours JavaScript et Google n'utilisait pas le contenu généré par JavaScript à des fins d'indexation.

Puis, compte tenu de l'utilisation accrue d'AJAX pour la diffusion de contenu dynamique sur des sites Web, Google proposa un « AJAX crawling scheme ”pour aider les utilisateurs à indexer les sites Web basés sur AJAX. C'était très compliqué. Il fallait en principe que le site Web produise un rendu des pages avec le contenu AJAX inclus. À la demande de Google, le serveur fournirait une version de la page avec tout (ou la plupart) du contenu qui aurait été généré de manière dynamique par JavaScript inclus dans la page HTML – pré-rendu sous forme d'instantané HTML . du contenu. Ce processus consistant à faire en sorte qu'une solution côté serveur fournisse un contenu destiné (à toutes autres fins) à être généré côté client, impliquait que ceux qui souhaitaient disposer d'un site reposant fortement sur JavaScript indexé par Google devaient passer par beaucoup de choses.

Par exemple, si le contenu lu par AJAX provenait d’un service Web externe, il était nécessaire de dupliquer les mêmes appels de service Web côté serveur et de produire côté serveur le même code HTML été produit côté client par JavaScript – ou du moins très similaire. C'était très compliqué car, avant l'avènement de Node.js, il était nécessaire de dupliquer au moins partiellement la même logique de rendu dans deux langages de programmation différents: JavaScript pour le frontend et PHP, Java, Python, Ruby, etc., etc. le backend. Cela s'appelle « rendu sur le serveur », et cela pourrait donner lieu à des problèmes de maintenance: si vous apportiez des modifications importantes à la manière dont vous rendiez le contenu dans l'interface, vous deviez dupliquer ces modifications dans le serveur. ] La seule alternative pour éviter la duplication de la logique consistait à analyser votre propre site avec un navigateur exécutant JavaScript, à enregistrer les résultats finaux sur votre serveur et à les transmettre à Googlebot. Ceci est en quelque sorte similaire à ce que nous appelons maintenant " Pre-rendu ".

Google (avec son système de balayage AJAX) garantissait également que vous évitiez les pénalités car dans ce cas vous étiez servir un contenu différent à Googlebot et à l'utilisateur. Cependant, depuis 2015, Google déconseille cette pratique avec un blog officiel qui disait aux gestionnaires de sites Web:

"Aujourd'hui, tant que vous n'empêchez pas Googlebot d'explorer vos fichiers JavaScript ou CSS. nous sommes généralement capables de restituer et de comprendre vos pages Web comme des navigateurs modernes . ”

Cela ne nous dit pas que Googlebot avait soudainement acquis la capacité d'exécuter JavaScript lors de l'indexation de pages Web, car nous savons qu'il le faisait depuis très longtemps (au moins pour vérifier le contenu faux et les escroqueries). Au lieu de cela, il nous a dit que le résultat de l’exécution de JavaScript serait indexé et utilisé dans les SERP.

Cela semble impliquer que nous n’avons plus à nous soucier de fournir à Google du code HTML au serveur. Cependant, nous voyons toutes sortes d'outils pour le rendu côté serveur et le rendu préalable disponibles pour les frameworks JavaScript, il semble que ce ne soit pas le cas. En outre, lorsque vous traitez avec de grandes agences de référencement sur de gros projets, le rendu préalable semble être considéré comme obligatoire.

Comment Google indexe-t-il réellement les pages créées avec des cadres frontaux?

L'expérience

Pour savoir ce que Google indexe réellement dans les sites Web créés avec un cadre frontal, j'ai créé une petite expérience. Il ne couvre pas tous les cas d’utilisation, mais c’est au moins un moyen d’en savoir plus sur le comportement de Google. J'ai construit un petit site Web avec Vue.js et différentes parties du texte ont été rendues différemment.

Le contenu du site Web est tiré de la description du livre Infinite Jest de David Foster Wallace dans le Infinite Jest Wiki ( merci les gars! ). Il existe quelques textes d'introduction pour le livre entier et une liste de caractères avec leur biographie:

• Un texte dans le code HTML statique, en dehors du conteneur principal de Vue.js;
• Un texte est restitué immédiatement par Vue.js car il est contenu dans des variables déjà présentes dans le code de l'application: elles sont définies dans l'objet du composant du composant;
• #Certains textes sont rendus par Vue.js à partir du data mais avec un retard de 300 ms;
• Le bios du personnage provient d'un ensemble d'API repos, que j'ai construits exprès en utilisant Sandbox . Comme je supposais que Google exécuterait le code du site Web et s’arrêterait après un certain temps pour prendre un instantané de l’état actuel de la page, j’ai configuré chaque service Web pour répondre avec un délai incrémentiel, le premier à 0 ms, le second à 300 ms, le troisième avec 600 ms et ainsi de suite jusqu'à 2700 ms.

Chaque bio de caractère est raccourcie et contient un lien vers une sous-page, disponible uniquement via Vue.js (les URL sont générées par Vue.js à l'aide de l'historique API). , mais pas côté serveur (si vous appelez directement l’URL de la page, vous n’obtenez pas de réponse du serveur), pour vérifier si celles-ci ont également été indexées. J’ai supposé que ceux-ci ne seraient pas indexés, car ce ne sont pas des liens adéquats rendant le serveur, et il n’ya aucun moyen que Google puisse diriger les utilisateurs directement vers ces liens. Mais je voulais juste vérifier.

J'ai publié ce petit site de test sur mes pages Github et demandé une indexation – jetez un oeil .

Les résultats

Les résultats de l'expérience (concernant le page d'accueil) sont les suivants:

• Le contenu déjà présent dans le contenu HTML statique est indexé par Google (ce qui est assez évident);
• Le contenu généré par Vue en temps réel toujours est indexé par Google;
• Le contenu généré par Vue, mais restitué après 300 ms est également indexé;
• Le contenu provenant du service Web, avec un certain retard, peut-être indexé, mais pas toujours. J'ai vérifié l'indexation de la page par Google à différents moments et le contenu inséré en dernier (après quelques secondes) était parfois indexé, parfois non. Le contenu rendu assez rapidement est indexé la plupart du temps, même s'il provient d'un appel asynchrone à un service Web externe. Cela dépend du budget de rendu de Google pour chaque page et site, qui dépend de ses algorithmes internes. Il peut varier énormément en fonction du classement de votre site et de l'état actuel de la file d'attente de rendu de Googlebot. Vous ne pouvez donc pas vous fier au contenu provenant de services Web externes pour obtenir une indexation;
• Les sous-pages (car elles ne sont pas accessibles directement par un lien) ne sont pas indexées comme prévu.

Que nous dit cette expérience? Fondamentalement, Google indexe le contenu généré de manière dynamique, même s'il provient d'un service Web externe, mais rien ne garantit que le contenu sera indexé s'il "arrive trop tard". J'ai eu des expériences similaires avec d'autres sites de production réels autres que cette expérience.

SEO concurrentiel

Bon, le contenu est donc indexé mais cette expérience ne nous dit pas ceci: Le contenu sera-t-il classé de manière concurrentielle? Google préférera-t-il un site Web à contenu statique à un site Web généré de manière dynamique? Il n'est pas facile de répondre à cette question.

D'après mon expérience, je peux dire que le contenu généré de manière dynamique peut se classer parmi les premières positions du SERPS. J’ai travaillé sur le site Web d’un nouveau modèle d’une grande entreprise automobile et lancé un nouveau site Web avec un nouveau domaine de troisième niveau. Le site a été entièrement généré avec Vue.js – avec très peu de contenu dans le code HTML statique à part les balises et les descriptions meta .

Le site a commencé à se classer pour des recherches mineures au cours des premiers jours suivant la publication. , et les extraits de texte dans les SERP contenaient des mots provenant directement du contenu dynamique.

Trois mois plus tard, il occupait le premier rang pour la plupart des recherches liées à ce modèle de voiture, ce qui était relativement facile car il était hébergé sur un domaine officiel appartenant à le constructeur de la voiture et le domaine étaient fortement liés à des sites Web réputés.

Mais vu le fait que nous avions dû faire face à la vive opposition de la société de référencement qui était en charge du projet, je pense que le résultat était toujours remarquable.

En raison des délais serrés et du peu de temps imparti au projet, nous allions publier le site sans pré-rendu.

Texte animé

Ce que Google ne pas index est lourdement – texte animé. Le site de l'une des sociétés avec lesquelles je travaille, Rabbit Hole Consulting contient de nombreuses animations de texte qui sont exécutées pendant le défilement de l'utilisateur et qui nécessitent de scinder le texte en plusieurs parties à l'aide de différentes balises. 19659003] Les principaux textes de la page d'accueil du site web ne sont pas destinés à l'indexation par un moteur de recherche car ils ne sont pas optimisés pour le référencement. Ils ne sont pas faits de langage technique et n'utilisent pas de mots clés: ils sont uniquement destinés à accompagner l'utilisateur dans un voyage conceptuel autour de la société. Le texte est inséré de façon dynamique lorsque l'utilisateur entre les différentes sections de la page d'accueil.

Aucun des textes de ces sections du site Web n'est indexé par Google. Pour que Google affiche quelque chose de significatif dans les SERPs, nous avons ajouté du texte statique dans le pied de page situé en dessous du formulaire de contact. Ce contenu apparaît dans le contenu de la page dans les SERPs.

Le texte dans le pied de page est indexé. et affiché dans les SERPs, même s'il n'est pas immédiatement visible par les utilisateurs, à moins qu'ils ne descendent au bas de la page et cliquez sur le bouton “Questions” pour ouvrir le formulaire de contact. Cela confirme mon opinion selon laquelle le contenu est indexé même s'il n'est pas affiché immédiatement à l'utilisateur, tant qu'il est restitué rapidement au format HTML – au lieu d'être rendu à la demande ou après un long délai.

Pré-rendu?

Alors, pourquoi tout ce tapage autour du pré-rendu – que ce soit côté serveur ou au moment de la compilation du projet? Est-ce vraiment nécessaire? Bien que certains cadres, comme Nuxt, le rendent beaucoup plus facile à exécuter, ce n’est toujours pas un pique-nique, aussi le choix de l’organiser ou non n’est-il pas léger.

Je pense que c’est non obligatoire . Cela est certainement nécessaire si une grande partie du contenu que vous souhaitez indexer par Google provient d'un service Web externe et n'est pas immédiatement disponible au moment du rendu. De plus, il est possible que, dans certains cas, le contenu ne soit pas disponible du tout, par exemple , temps d'arrêt du service Web. Si lors de la visite de Googlebot, certains de vos contenus arrivent trop lentement, alors peut ne pas être indexé . Si Googlebot indexe votre page exactement au moment où vous effectuez la maintenance de vos services Web, il risque de ne pas indexer de contenu dynamique.

De plus, je n'ai aucune preuve de le classement des différences entre les valeurs statiques. contenu et contenu généré dynamiquement. Cela pourrait nécessiter une autre expérience. Je pense qu'il est très probable que, si le contenu provient d'un service Web externe et ne se charge pas immédiatement, cela pourrait avoir une incidence sur la perception de Google, tout en maintenant les performances de votre site, ce qui est un facteur de classement très important.

Lectures recommandées : Influence de la conception de sites Web mobiles sur la recherche locale (et les mesures à prendre)

Autres considérations

Compatibilité

Jusqu'à récemment, Googlebot utilisait une version assez ancienne de Chromium (le logiciel libre). projet source sur lequel repose Google Chrome), à ​​savoir la version 41. Cela signifiait que certaines fonctionnalités JavaScript ou CSS récentes ne pouvaient pas être restituées correctement par Google (par exemple, IntersectionObserver, syntaxe ES6, etc.).

Google a a récemment annoncé qu’il utilisait désormais la dernière version de Chromium (74, au moment de la rédaction) dans Googlebot, et que cette version serait mise à jour régulièrement. Le fait que Google exécute Chromium 41 aurait pu avoir de grandes conséquences pour les sites qui ont décidé de ne pas tenir compte de la compatibilité avec IE11 et d'autres anciens navigateurs.

Vous pouvez voir une comparaison entre la prise en charge de Chromium 41 et de Chromium 74 ici . ]cependant, si votre site était déjà polyfilling manquant de fonctionnalités pour rester compatible avec les navigateurs plus anciens, il n'y aurait pas eu de problème.

Utilisez toujours polyfills car vous ne savez jamais quel navigateur. manque le support pour les fonctionnalités que vous pensez sont banales. Par exemple, Safari ne prenait pas en charge une nouvelle fonctionnalité majeure et très utile telle que IntersectionObserver jusqu'à la version 12.1, parue en Mars 2019 .

. Erreurs JavaScript

Si vous comptez sur Googlebot pour exécuter votre JavaScript restituer le contenu vital, il faut éviter à tout prix les erreurs JavaScript importantes qui pourraient empêcher le rendu du contenu. Bien que les bots puissent analyser et indexer du HTML qui n’est pas parfaitement valide (même s’il est toujours préférable d’avoir du HTML valide sur n’importe quel site!), S’il existe une erreur JavaScript qui empêche le chargement de certains contenus alors En aucun cas, si vous comptez sur JavaScript pour restituer du contenu essentiel à vos utilisateurs finaux, il est probable que vous disposiez déjà de tests unitaires approfondis pour vérifier les erreurs de blocage, quelle qu’elles soient leurs propriétés. Gardez toutefois à l'esprit que des scénarios imprévisibles peuvent entraîner des erreurs Javascript, par exemple, en cas de traitement incorrect des erreurs dans les réponses de l'API.

Il est préférable de disposer d'un logiciel de vérification des erreurs en temps réel (tel que Sentry ou LogRocket) qui vous alertera de toute erreur de cas marginale que vous ne pourriez pas récupérer lors des tests manuels ou à l’unité. Cela ajoute à la complexité de l'utilisation de JavaScript pour le contenu SEO.

Autres moteurs de recherche

Les autres moteurs de recherche ne ne fonctionnent pas ainsi que Google à contenu dynamique. Bing ne semble pas du tout indexer le contenu dynamique, pas plus que DuckDuckGo ou Baidu. Ces moteurs de recherche manquent probablement des ressources et de la puissance de calcul de Google.

Analyser une page avec un navigateur sans navigateur et exécuter JavaScript pendant quelques secondes afin d'analyser le contenu affiché est certainement plus gourmand en ressources que la simple lecture de HTML. . Ou peut-être ces moteurs de recherche ont-ils choisi de ne pas analyser le contenu dynamique pour d'autres raisons. Quelle que soit la cause, si votre projet doit prendre en charge l'un de ces moteurs de recherche, vous devez configurer le pré-rendu.

Note : Pour obtenir plus d'informations sur les autres moteurs de recherche ' fonctions de rendu, vous pouvez vérifier cet article de Bartosz Góralewicz. Il est un peu vieux, mais selon mon expérience, il est toujours valable.

Autres robots

N'oubliez pas que votre site sera également visité par d'autres robots. Les exemples les plus importants sont Twitter, Facebook et d'autres robots de réseaux sociaux qui doivent extraire des méta-informations sur vos pages afin d'afficher un aperçu de votre page lorsqu'elle est liée par ses utilisateurs. Ces robots n'indexeront pas le contenu dynamique et afficheront uniquement les méta-informations trouvées dans le code HTML statique. Cela nous amène à la considération suivante.

Sous-pages

Si votre site est ce qu’on appelle un «site Web One Page» et que tout le contenu pertinent est situé dans un code HTML principal, vous n’aurez aucun problème à ce que ce contenu soit indexé. par Google. Cependant, si vous avez besoin de Google pour indexer et afficher toute page secondaire sur le site Web, vous devez créer du code HTML statique pour chaque d'entre eux – même si vous comptez sur votre Framework JavaScript pour vérifier l'URL actuelle et fournir le contenu pertinent à mettre dans cette page. Mon conseil, dans ce cas, est de créer des pages côté serveur (ou statiques) qui fournissent au moins le titre correct et la méta description / information.

Conclusions

Les conclusions que j'ai Lorsque vous recherchez cet article, voici les éléments suivants:

1. Si vous ne ciblez que Google, il n'est pas obligatoire d'utiliser le rendu préalable pour que votre site soit entièrement indexé:
2. Vous devriez ] not s'appuie sur les services Web tiers pour le contenu devant être indexé, en particulier s'il ne répond pas rapidement.
3. Le contenu que vous insérez immédiatement dans votre code HTML via Vue.js, le rendu est indexé, mais vous ne devez pas utiliser de texte animé ou inséré dans le DOM après des actions utilisateur telles que le défilement, etc.
4. Assurez-vous que testez les erreurs JavaScript dans la mesure où ils pourraient ne pas indexer des pages / sections entières, ou votre site ne serait pas indexé du tout.
5. Si votre site comporte plusieurs pages vous avez toujours besoin d'une certaine logique pour créer des pages qui, tout en s'appuyant sur le même système de rendu frontal que la page d'accueil, peuvent être indexées individuellement par Google. URL
6. Si vous devez disposer de descriptions différentes et d'aperçus d'images pour les médias sociaux entre différentes pages, vous devrez également corriger le problème, côté serveur ou en compilant des images statiques. pages pour chaque adresse URL.
7. Si vous avez besoin que votre site fonctionne sur les moteurs de recherche autres que Google vous avez certainement besoin d'un rendu préalable.

(dm, yk, il)

Remerciements: Merci beaucoup à Sigrid Holzner de SEO Bavaria / Rabbit Hole Consulting pour sa relecture de cet article.