Le SEO JavaScript démystifié
Comment concilier framework JS et performances sur le Search ?

• Directeur technique SEO
• Refontes SEO
• Web Performance
• Missions coup de poing / chute de trafic
@aymerictwit
Adrien RUSSO
Consultant SEO indépendant
• Accompagnement général
• Problématiques JS, maillage, sémantique
(à l'échelle)
@adrienrusso
Aymeric BOUILLAT

Dans la file d’attente de rendu des 50 prochaines minutes
1. Introduction : pourquoi s'intéresser au JavaScript ?
2. Les problématiques en SEO JavaScript
3. Les solutions pour optimiser un site JS
4. Conclusion : la responsabilité des SEO

JavaScript et SEO,
la patience est de
mise…

Le JavaScript, c’est quoi ?
Avant
Rendre les pages Web interactives côté
client
Après
Créer le front-end et le back-end d’un site,
une application complète !

Pourquoi le JavaScript c’est compliqué ?

Le JavaScript, c’est de l’électricité pour Google
Source : https://bilan-electrique-2020.rte-france.com/consommation-repartition-sectorielle-de-la-consommation-2

Plus de 4% de la consommation électrique
française totale !
Source : https://www.statista.com/statistics/788540/energy-consumption-of-google/

Concilions JavaScript et performance

Car il n'est pas prêt de partir

Exploration des sites
pour Google

Indexation en 2 temps
File
d’attente
pour le crawl
Crawl Traitement Indexation
Découverte
de nouvelles
URL
URL HTML
Rendu
File d’attente
pour le rendu
Algorithmes
de ranking

Un contenu = une URL pour le SEO
Le problème des SPA (Single Page App) = tout le site accessible via une seule URL…
Single Page Application Multiple Pages Application

Pourtant, elles existent encore en 2023

#fail : refonte de site en JavaScript
Nombre de mots-clés positionnés sur google.fr
KO !!
Source : SEMRush

Même avec du rendu JavaScript,
Google peut faire face à un mur
Site pré-rendu, mais sans attribut href pour Google

Google doit récupérer les fichiers
JS, pour voir dans le futur
• Pour Google: du temps de crawl supplémentaire
• Pour votre site: des ressources supplémentaires
à servir (crawl JS, CSS, XHR, etc)
88 miles / hour
1,21 gigawatts !

Chargement des ressources de la page

et impact sur le budget d’exploration…

Crawl budget = que pour les gros sites!
Inventaire
perçu
Ne pas
gaspiller le
temps passé
par Google sur
votre site
Popularité
URL les plus
populaires sont
explorées plus
souvent
Obsolescence
Explorer
fréquemment les
documents pour
d'identifier toute
modification
> 10 000 pages uniques
dont le contenu change très
rapidement / quotidiennement
> 1 M de pages uniques
dont le contenu change assez souvent
(une fois par semaine)

Attention à
l’interprétation des
données…!
Baisse du TTFB = Augmentation du crawl ?

Les directives de cache sur les ressources JS
Mieux réguler le crawl de Google!
Ex: Cache-Control: max-age= 604800

Bloquer ces ressources JavaScript ?
Cas SEO Bloquer au crawl
Ressource qui a un impact sur le contenu?
Ressource liée à un formulaire (connexion, validation, etc.) ?
Ressource qui modifie les liens de navigation (ex: mega-menu) ?
Ressource ne sert qu’a ajouter des interactions avec l’utilisateur, non actionnables par Google ?
Ressources qui ne change pas le contenu mais dont on ne connait pas l’utilité?

Impact d’une ressource
JavaScript bloquée
Méthode
1) Identifier la ressource problématique
2) Clic droit sur la page Web
3) « Inspecter l’élément »
4) « Onglet « Réseau »
5) Clic sur la ressource
6) Clic-droit sur « Block request URL » 2
3
4
5
6

Délais et problèmes
de rendu chez
Google

Case study
Google a eu besoin de 9 fois plus de temps pour explorer les pages accessibles via JavaScript
Source : https://www.onely.com/blog/google-needs-9x-more-time-to-crawl-js-than-html/
/html/
/javascript/
HTML Brut
WebRendering
Service
Pages
crawlées
en 36H
Pages
crawlées
en 313 H

Temps de rendu
Web Rendering Service (rendu) et délais!
File d’attente de rendu
Certaines pages ne seront pas rendues tout de suite
(voire pas du tout…)
1 2

Stratégie de rendu
(CSR, SSR, SSG, ISR…)

On peut entendre dire que le "Google
moderne" travaille parfaitement avec JS
https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics?hl=fr

Comprenez ces 3 concepts et vous
comprendrez tout le reste
CSR
= Client Side
Rendering
Qui rend ? Le client
(Google, votre
navigateur, etc)
SSG
= Static Site
Generation
Qui rend ? Votre
serveur, pour fournir du
HTML statique à tout
le monde
SSR
= Server Side
Rendering
Qui rend ? Votre
serveur, pour une
version HTML mise à
jour pour tout le monde

Par défaut, on parle de CSR
Le client demande un
fichier HTML au
serveur
Le serveur renvoie
une page HTML vide
et les ressources
Le client récupère,
exécute, rend les
ressources
L'application est
prête à l'emploi
C'est-ce que l'on souhaite éviter (en SEO) !

Stratégies de rendu fondamentales (1 / 2)
Le client demande un
fichier HTML au
serveur
Le serveur renvoie
une page HTML qui a
été rendue en avance
Le client reçoit une
page donc le contenu
est disponible
L'application est
prête à l'emploi,
après rendu
d'éléments
dynamiques
Bonne solution, mais attention à la scalabilité du site
SSG

Stratégies de rendu fondamentales (2 / 2)
Le client demande un
fichier HTML au
serveur
Le serveur renvoie
une page HTML qui
vient d'être rendue
Le client reçoit une
page donc le contenu
est disponible
L'application est
prête à l'emploi,
après rendu
d'éléments
dynamiques
Bonne solution, mais attention à la charge serveur
SSR

La différence majeure ?
CSR
Le serveur renvoie
les ingrédients au
client, c'est au client
de cuisiner
SSG
Le serveur renvoie un
plat qui a été préparé
en avance au client
SSR
Le serveur renvoie un
plat qui vient d'être
préparé au client

Il y a des avantages et des inconvénients
pour chaque...
SSG
build
- Rapidité (webperf)
- Crawlabilité
- Temps de build
- Interactivité (par défaut)
SSR
hit
- Crawlabilité
- Pas de temps de build
- Interactivité
- Charge serveur
- TTFB (par défaut)

Donc, que choisir ? La réponse simple
SSR CSR
+
= hydration
Avec le SSR, l'objectif de l'hydration est d'alléger la charge serveur

La réponse "qui dépend"
Petite à moyenne volumétrie
SSG CSR
+
= hydration
Avec le SSG, l'objectif de l'hydration est d'assurer l'interactivité

Profiter du SSG statique sans le désavantage
du build time
ISR
Incremental Static
Regeneration
Système de cache permettant de mettre à jour chaque page à une
fréquence donnée, et non pas à chaque hit.

Attention au Dynamic Rendering
- Complexités pour la mise en place
- Risques d'oublis avec la gestion de l'User-agent
- Complexités et risques d'oublis lors de l'audit SEO

Exemple d'erreur en Dynamic Rendering
Des redirections vues par Googlebot en 404, mais redirigée côté navigateur
Source : Sistrix

Problème de configuration en SSR
Dynamic Rendering avec du contenu incompréhensible, juste pour Google…

Le JS peut empêcher
Google de surfer
correctement
Problématiques On-site

Pagination : l'URL doit bouger
• En JS, la pagination "load
more" ou "infinite scroll" est
régulièrement utilisée
• Cela nécessite de générer des
URLs différentes

Contenu qui nécessite une action pour être
visible dans le code
• Google n'indexera jamais un contenu qui nécessite une action
pour devenir visible dans le code HTML
• Ces actions peuvent être un clic, un scroll ou un hover
• Il faut vérifier les menus accordéons, facettes, etc

Impact du non pré-rendu sur les images
• Migration d'un site non JS vers un site JS
• Baisse soudaine du trafic Google Images
• La baisse s'est déroulée après la migration, sans pré-rendu des liens images et
un mauvais pré-rendu sur les contenus en général

Site de e-commerce avec un bloc « Produits
similaires » non rendu pour Google
?????

Des outils pour le
rendu final

Savoir ce que Google a indexé ?
pas avec la commande « cache: »
La commande
ne présente que le
HTML brut
récupéré lors de la
première phase
d’indexation, sans
exécution du JS
cache:
Préférez l’affichage «Version en
texte seul » pour voir texte/liens vus
par Google lors de sa première
phase d’indexation

Comment savoir si Google a indexé le rendu JS?
Commande + « extrait de texte entre guillemets »
site:URL

Comprendre ce que
Google est capable de
rendre en JS
https://search.google.com/test/rich-results

Voir la différence entre HTML brut
et HTML après rendu JS
https://chrome.google.com/webstore/detail/view-rendered-source/ejgngohbdedoabanmclafpkoogegdpob

Auditer le rendu à l'échelle : Screaming Frog
• Visualiser le % de contenu pré-rendu
VS non pré-rendu (textuel, liens, etc)
• Réaliser un crawl sans l'exécution JS et
un crawl avec
• Visualiser le code précis pré-rendu VS
non pré-rendu

Est-ce au SEO de
décider de tout?

Mieux vaut prévenir que guérir
 Point de vue DEV, le JavaScript présente
de nombreux avantages
 Le SEO n’est qu’une pièce du puzzle
 Adaptons nous pour limiter les risques