Les bonnes pratiques SEO avec les frameworks javascript - SEO CAMPUS 9 mars 2017

Cedric Rambaud
Consultant SEO Senior – Search Foresight

Philippe Yonnet
DG et fondateur – Search Foresight
3

Confiez-nous vos projets ambitieux
Plateforme e-commerce, Accompagnement SEA international, Migration & Refonte…
Nos experts maîtrisent les problématiques les plus avancées.
4
PROJETS COMPLEXES
PROBLEMATIQUES TECHNIQUES,
CMS, MIGRATIONS, ORGANISATION
PROJETS EXTREMES
SITES A FORT TRAFIC, LEADERS,
GRANDS COMPTES, FORTES
VOLUMETRIES
INTERNATIONAL
SITES MULTILINGUES, SEO LOCAL,
GESTION DES LANGUES

SF vous partage sa passion du Search
Chaque semaine, de nouvelles ressources à votre disposition en exclusivité
5
Des prises de parole chaque semaine
Un accès en avant première aux web-conférences
Search Foresight et aux contenus de nos prises de
parole pour vous transmettre notre expérience
Des contenus de référence
Des contenus exclusifs chaque semaine :
Newsletter, Articles, Case study, Etudes…
Une communauté de passionnés
Partagez avec une communauté d’experts du Digital,
du Search, du Webmarketing…
Des évènements pointus
Echangez et networkez lors de nos évènements
exclusifs : Meet-up, Barcamp, Petits-déjeuners…

SF recrute
https://www.search-foresight.com/agence-seo/nos-jobs/
Retrouvez-nous au job dating organisé à l’occasion du SEO Campus à 17h30
6

Agence conseil en stratégie digitale | SEO • SEM • CRO • Inbound Marketing • Analytics
La problématique
7

Oups j’ai fait mon site en full Angular JS !
Et je le regrette déjà
8
Javascript activé Javascript désactivé
<body ng-controller="appController as app"
id="appController">
<a href="{{pathMap._home._hash}}"> </a>
<a id="triggerAutoRefreshTag"
onclick='angular.element("#appController").scope().autoRe
fresh(location.hash);'></a>
<app-head></app-head>
<app-head-mini></app-head-mini>
<div class="container main
{{app.isCurrentContext(pathMap._phoneDetails._formated
Hash) ||
app.isCurrentContext(pathMap._hotspotDetails._formated
Hash) ? 'phonedetails' : ''}}">
<app-navigator></app-navigator>
<app-title></app-title>
<banner></banner>
<app-container></app-container>
<store-container></store-container>
<phone-container></phone-container>
<support-container></support-container>
<plan-container></plan-container>
<as-container ng-if="appName=='spp'"></as-container>
<familyplans-container ng-
if="appName=='spp'"></familyplans-container>
<checkout-container></checkout-container>
<page></page>
Euh … où est le contenu ?

Un site full angular indexé
Angular JS c’est compliqué, cela ne renvoie pas le même code qu’un site « standard »
et les bots ne semblent pas comprendre ce qu’ils voient. Et pourtant….
9
… un site full angular JS peut être
indexé !

Par contre, côté visibilité, c’est plus vraiment ça
10

Ce que voit l’utilisateur
Tout le contenu est accessible
avec une navigation dans la
sidebar de gauche.
11

Ce que voit Googlebot
Et pourtant le code téléchargé ressemble à ça :
</head>
<body itemscope itemtype="http://schema.org/WebPage">
<div class="wrapper">
<div ng-include="'app/layout/shell.html'"></div>
<div id="splash-page" ng-show="showSplash">
<div class="page-splash">
<div class="page-splash-message">
</div>
<div class="progress progress-striped active page-progress-bar">
<div class="bar"></div>
</div>
</div>
</div>
</div>
<script src="rsc/js/lib-adc3d5f6d9.js"></script>
<script src="rsc/js/app-f84e7b0c4f.js"></script>
</body>
</html>
La rendition est parfaite sur fetch as Googlebot
12

Ce que voit un bot ‘normal’
Le contenu n’est pas visible. Là où se trouvaient
les contenus se trouvent maintenant des
variables.
Simulation via Browseo
13

Google et le javascript
14

Une histoire d’amour
En 2008 google nous dit : je peux crawler le flash et le javascript ! Cependant entre le
discours et la réalité des faits il y avait alors un fossé ! Dès lors, les webmasters et SEO
partaient tout de même du principe que Google ne crawlait pas le javascript.
Depuis 2015 la question se repose de plus en plus : Google crawl-t-il le javascript ?
Et depuis 2015 la réponse penche plutôt vers le « Oui mais… »
En 2016 Google met à jour ses guidelines concernant le javascript en indiquant qu’il
supporte l’utilisation du javascript pour les titles, description et robots meta tags.
15
+ = ?

Google sait rendre le JS et CSS
Google peut comprendre et rendre le CSS et le JS. En témoigne un exemple très simple : les
sites responsives. Google doit avoir accès au CSS d’un site (à minima) pour comprendre qu’un
site responsive est mobile friendly.
Aussi, un ‘explorer comme Google’ dans la search console nous montre très clairement que
Google « voit » ce que le navigateur « voit ».
16

Et les liens brouillés alors ?
Cela a bien évidemment pour conséquence que les liens « brouillés » en javascript ne le sont
plus vraiment *à priori* !
Google peut lire par exemple :
Les liens avec la fonction Onclick
Les liens avec la fonction Onclick qui génère le lien (via l’appel à un script dans le header de la
page)
Les liens jquery faisant appel à un script dans le header de la page
Les liens onclick avec un appel à un script externe
17
Exemple de liens lus par Googlebot

S’il peut suivre les liens… Il peut aussi lire le contenu !
Cela impact donc également la lecture des contenus encapsulés dans du javascript et leur
indexation.
Google pourra indexer des pages avec du contenu généré dynamiquement en javascript ce qui
peut être soit :
Une bonne nouvelle : mon texte est intéressant et enrichit la page  peut-être un meilleur
positionnement.
Une mauvaise nouvelle : le contenu généré en javascript n’est pas intéressant et ne va pas
dans le sens de ce que je voulais faire.
18

Google peut tout lire ? NON.
Google ne peut pas, ne sait pas tout lire : c’est le cas de l’AJAX par exemple.
POURQUOI ? Parce que l’ajax ne nécessite aucune action pour être chargé  aucun moyen
pour le moteur de « deviner » ce qu’il doit faire pour déclencher l’ajax !
En 2009 Google mettait en avant la technique des hash bang pour aider le crawl et
l’indexation des contenus chargés en AJAX.
En 2015 Google ne recommande plus cette technique parce qu’il nous dit pouvoir lire les
contenus générés en AJAX.
Malheureusement, dans les faits c’est loin d’être concluant.
19

La méthode (obsolète) du hash bang
En 2009, Google propose l’utilisation du
hashbang (escaped fragment) pour mieux gérer
l’AJAX.
Principe : Utilisation habituelle du # (hash)
pour afficher un élément d’une page côté
client.
Ajout du ! (bang) pour le rendre
compréhensible par le moteur.
Lorsqu’il rencontre une URL avec un hashbang
(#!) le moteur va la crawler en remplaçant cet
élément par un _escaped_fragment_
Puis il va indexer la page sous sa forme
originale.
20

La méthode HTML 5 (sympa) du pushstate()
Il s’agit d’une fonction javascript directement incluse dans le
HTML5. Concrètement, pushState() change le chemin de l’url qui
apparait dans la barre d’adresse de l’utilisateur.
Quel intérêt pour le SEO ? Les moteurs seront capables de lire ces
URL et de les différencier des autres.
Quand l’utiliser ? À chaque fois que l’on identifie un état qui
correspond :
- À l’équivalent d’une page HTML complète (90% / 100% différente
dans son contenu de l’état précédent)
- À une page suffisamment différente pour justifier « son
bookmarkage » dans un favori, dans un lien externe, dans un retour
en arrière dans l’historique
Alors, on pousse l’url correspondant à cet état via la méthode
pushstate après déclenchant de l’évènement ou de l’action
conduisant à ce changement d’état.
21
window.history.pushState('','','t
est/url/that-does-not-really-
exist')
Démonstration

Du pushstate sur du scroll infini
Implémentation sur une long
scrolling page :
https://webmasters.googleblog.com
/2014/02/infinite-scroll-search-
friendly.html
22

Conséquence : les tabs et contenus cachés
Ils peuvent ne pas être indexés, ou leur poids peut-être diminué
23
Attention : cela changera avec le « mobile first index »

Qu’est-ce qu’un framework
javascript ?

L’architecture traditionnelle des sites
Les pages sont statiques

Le « client side rendering »
La magie se passe côté client (dans le navigateur) : utilisation de l’AJAX
26

Le concept de SPA (single page application)
Application web monopage
Twitter est un site web de type SPA
Problème : les moteurs de recherche sont
construits pour associer des signaux à de
multiples pages
Créer un site web monopage pose donc
des problèmes pour le référencement

L’architecture version SPA (client side)
28

Les principaux frameworks JS
AngularJS
Le plus connu, appartenant à l’écosystème
Google
Différences entre version 1 et version 2 (la V2
peut être utilisée en « middleware » et « en
rendition hybride »
https://angularjs.org/
EmberJS
http://emberjs.com/
BackboneJS
http://backbonejs.org/
29

Challenge n°1 pour les moteurs
Un bot traditionnel de moteur de
recherche télécharge le code HTML, et
analyse le contenu présent dans ce code
Le contenu généré en ajax ou en javascript
est ignoré
C’est encore vrai pour la plupart des
moteurs de recherche
Googlebot, avec son headless browser, fait
exception
Explorer une SPA

Challenge n°2
Quoi indexer ?
Le contenu change en fonction des interactions : Comment identifier tous les contenus possibles ?
Si on « clique » partout, tout mérite-t’il d’être indexé ?
Comment éviter que l’exploration d’un tel site demande un temps très long ?
Quels signaux prendre en compte ?
Comment exploiter le maillage hypertexte ?
Comment analyser le contenu ?
Comment analyser un morceau de page ou au contraire une « page » qui contient l’équivalent d’un site
entier
A quoi rattacher ces signaux ?
Si la notion de page reliée à une url a disparu, comment continuer à utiliser l’algorithme habituel ?
Quoi indexer ? Quels signaux prendre en compte ? A quoi les associer ?

Les performances en SEO ne sont pas toujours au
rendez-vous
Il est possible de rendre un site de type SPA, avec un rendu
« client side » entièrement crawlable et indexable, pour
Google
Nous allons voir comment un peu plus loin
Attention : on est proche des limites des possibilités actuelles du
moteur
mais attention : cela ne marchera qu’avec Google, attention pour
les sites internationaux
Mais les performances en termes de position ne sont pas
toujours au rendez-vous
Rendre le site explorable est juste un minimum syndical
Conclusion : il est formellement déconseillé d'utiliser ces
technologies dont la compatibilité SEO est partielle voire nulle
et en plus, c'est même déconseillé parce que ce n'est pas une
solution aussi logique et élégante que les développeurs et
intégrateurs veulent bien le dire

Deux bonnes raisons (non SEO)
pour ne pas utiliser cette
approche
33

Ce n'est pas compatible avec les principes de
l'unobstrusive javascript
Unobstrusive javascript : Javascript discret en français
C’est une bonne pratique de codage de page web qui consiste à bien séparer le code HTML et Javascript
pour limiter les inconvénients habituels provoqués par leur intrication
Pb de maintenabilité
Pb de compatibilité
Pb d’accessibilité
Et bien sûr : problèmes de SEO
Exemple :
Ce code n’est pas conforme :
Il faut utiliser ce code plutôt
Et
<input type="text" name="date" onchange="validateDate(this);" />
<input type="text" name="date" id="datefield" />
document.getElementById( "datefield" ).addEventListener( 'change', function(){ do_something(); }, false );

Et la compatibilité avec l’amélioration progressive ?
La plupart des implémentations faites avec
des frameworks javascripts ne sont pas
complètement fidèles, voire pas du tout,
avec les préceptes de l’amélioration
progressive
Quand on désactive le javascript : pas de
fallback, le site n’est plus utilisable
Avec des navigateurs exotiques ou anciens, le
site peut montrer des bugs bloquants
La lourdeur des pages en javascript (chargés
avec la page ou dynamiquement) peut poser
des problèmes de temps de rendition sur
smartphone
Et le « mobile first » ?

Pourquoi c’est populaire chez les développeurs ?
Cela transforme les sites web en vraies applications
Un site web est vraiment un objet logiciel exotique pour la plupart des
développeurs habitués à faire des logiciels classiques et à coder des logiciels en
utilisant des langages comme le C, ou le Java
Un seul langage permet de faire tout le site web
Cela déporte certains problèmes côté client (navigateur)
Cela permet des interfaces riches
C’est moderne
C’est plus efficient, on développe plus rapidement
Quelques raisons invoquées régulièrement !

Auditer un site fait avec un
framework javascript
37

Tester une page avec "fetch as Google"
https://support.google.co
m/webmasters/answer/60
66468?hl=fr
Si le test montre que Google ne parvient pas à « rendre » la page correctement : vous avez un problème

Le concept de "headless browser"
Un browser « headless » est un environnement
logiciel, programmable ou pilotable en ligne de
commande, qui est capable d’effectuer une rendition
complète d’une page HTML en exécutant tout le code
: HTML, CSS et Javascript
Il est qualifié de « headless » car il ne dispose pas de
GUI (d’interface utilisateur)
Grâce à un headless browser, on peut donc simuler
tout ce qui se passe dans un navigateur comme
Chrome ou Firefox. Et donc tester le code généré en
Ajax, ou par des framework Javascript
Remarque : ce type de crawl crée de « fausses visites »
dans vos outils de web analytics
Un bot sans tête mais avec des yeux !

PhantomJS et CasperJS
PhantomJS est le headless browser le plus populaire :
http://phantomjs.org/
CasperJS est un webkit permettant de scraper le
contenu de pages web. Il utilise PhantomJS comme
headless browser
http://casperjs.org/

Auditer avec Screaming Frog
Screaming Frog est un crawler orienté SEO
Il dispose depuis peu d’un mode « headless
browser » basé sur PhantomJS
Dans ce mode, il peut crawler un site en full
Angular
https://www.screamingfrog.co.uk/seo-spider/
Le mode « crawl Javascript »

Auditer un site avec Botify
Même possibilité dans Botify depuis janvier
2017
https://www.botify.com/blog/breaking-news-
botify-announces-javascript-crawl/
https://www.botify.com/blog/crawling-
javascript-for-technical-seo-audits/

Comment rendre ces sites SEO
Compliant ?
43

Solution 1 : coder différemment
Par exemple : amélioration progressive et jQuery

Créer des snapshots HTML (soi même)
Le principe :
Le code javascript est exécuté via un headless
browser côté server, afin de générer le HTML
produit par le code javascript
Ce code est « capturé » avant d’être envoyé,
comme une page HTML normale, au navigateur
de l’internaute
Problème : la méthode fait perdre une partie
de l’intérêt du « client side rendering », la
page devient statique
Souvent, l’arbitrage est d’envoyer les snapshots
aux bots des moteurs de recherche uniquement
Une méthode préconisée par Google pour l’Ajax

Utiliser un serveur de prérendition tiers
Prerender.io : https://prerender.io/
SEO 4 Ajax (Cocorico !) :https://www.seo4ajax.com/
Brombone : http://www.brombone.com/
Inutile de développer votre propre solution de prérendition

Attention : les serveurs de rendition utilisent la
méthode obsolète pour rendre l’ajax crawlable
Soit la méthode des escaped fragments avec hash bangs
Soit la méthode des escaped fragments avec balise meta
<meta name="fragment" content="!">
Attention, cette méthode en HTML5 utilisant la méthode pushstate() est aussi obsolète que l’autre !!!
Pour le moment : tout fonctionne correctement
C’est compatible avec la plupart des moteurs de recherche qui comptent : Bing, Yandex…
Mais demain ???
www.example.com/ajax.html#!key=value
www.example.com/ajax.html?_escaped_fragment_=key=value

Frameworks javascript :
The next generation
48

ReactJS, HapiJS, Angular2 etc.
Code isomorphe : le même code peut être
utilisé côté navigateur, côté serveur, ou
n’importe où entre les deux
Avec ReactJS ou HapiJS, on peut donc
générer le HTML avant de l’envoyer au
navigateur
Il devient possible de créer des sites webs
avec des frameworks JS, sans générer de
problèmes avec le SEO
Attention : mal utilisés, ces frameworks JS de
dernière génération peuvent poser les mêmes
problèmes que ceux expérimentés avec la
première génération
Des frameworks « isomorphes » capables d’une rendition hybride ou server side

Conclusion
50

Conclusion
Compétences côté développeurs
Compétences côté SEO
Et dans tous les cas, c’est à réserver à des
situations où le trafic SEO n’est pas stratégique
pour le site :
- On peut rendre les sites faits avec ces
technologies crawlables et indexables
- Mais si l’on veut atteindre des positions clés
sur des requêtes concurrentielles, il vaut
mieux compter sur un site web en server
side rendering à l’ancienne
Un casse tête qui n’est pas insoluble, mais qui demande de solides compétences techniques

La question qui peut vous rapporter 1 Mug
Quel est le nom anglais de la méthode recommandée pour bien
séparer le HTML et le javascript ?
53

Restons en contact
Philippe Yonnet, DG et fondateur
philippe.yonnet@search-foresight.com
+ 33 1 74 18 29 40 / + 33 6 99 60 21 49
Slideshare.net/S4sight
@S4sight & @Cariboo_seo
www.search-foresight.com
54

Les bonnes pratiques SEO avec les frameworks javascript - SEO CAMPUS 9 mars 2017

Contenu connexe

Tendances

En vedette

Similaire à Les bonnes pratiques SEO avec les frameworks javascript - SEO CAMPUS 9 mars 2017

Plus de Peak Ace

Les bonnes pratiques SEO avec les frameworks javascript - SEO CAMPUS 9 mars 2017