UX et SEO : Faut-il encore les opposer ?

Mais commençons par nous demander d’où provient la "tension" entre UX et SEO ?

A l’origine : une page vue par les moteurs différente de la page vue par les internautes

Si on remonte aux débuts des moteurs de recherche, Google y compris, les robots d’exploration avaient une vision des pages web très différentes de celle d’un utilisateur normal, parce que très, très limitée. En fait, Googlebot n’avait strictement aucune idée de l’apparence de la page telle qu’elle était vue par un utilisateur "normal". Le moteur se contentait d’analyser le contenu de la page, sans tenir compte des CSS, du javascript, et même de la plupart des balises HTML décrivant l’apparence de la page…

Fig. 1. A gauche, la page visible par l’internaute. A droite, le contenu vu par un bot de la génération 1998.

Evidemment, cette "myopie" des bots conduisait à toute une série de recommandations SEO qui pouvait s’avérer contradictoire avec l’expérience utilisateur que l’on souhaitait créer.

C’était donc l’époque où est né ce mythe selon lequel un site optimisé pour les moteurs était forcément "moche"...
Aujourd’hui la "vision" des bots s’est nettement améliorée, et ce que "voit" Googlebot aujourd’hui, c’est la même page (en théorie) qu’un utilisateur.

Fig. 2. Un exemple du rendu obtenu avec la fonctionnalité « fetch and render as Googlebot » de la Google Search Console. Les deux versions sont ici strictement identiques. Des différences apparaissent cependant quand on bloque l’accès via le robots.txt à des images, des fichiers javascripts ou des CS.

Et deux cas d’utilisation fort différents

Souvent, l’UX d’un site est pensée pour créer un parcours guidé depuis une page d’accueil jusqu’à une page où se passe une conversion… Mais dans le cas où un internaute provient d’un moteur de recherche, une part plus ou moins importante de ce parcours est contournée, l’internaute pouvant même atterrir directement sur la page de conversion. Ceux qui opposent UX et SEO oublient souvent que les arbitrages à rendre proviennent de ces deux cas d’utilisation différents.
Par exemple : en invoquant des raisons UX, il est fréquent aujourd’hui de proposer de très longues pages que l’on peut faire défiler sur un écran tactile. Le problème, en cas d’atterrissage depuis un moteur de recherche, c’est que l’internaute cherche quelque chose de précis sur cette longue page. S’il ne le voit pas instantanément dès le premier écran, les chances sont grandes qu’il rebondisse immédiatement et aille voir une page d’un autre site qui, elle, donne l’information. Mais en fait, s’il n’y a pas une bonne correspondance entre requêtes tapées par les internautes et contenu, la page sera mal classée et cela réduira les visites en provenance des moteurs.

Fig. 3. Un exemple typique du parcours d’un utilisateur vu par un ergonome. Or l’arrivée directe sur une page d’atterrissage peut se révéler le cas le plus fréquent, alors que le site est un optimisé pour un parcours partant de la page d’accueil.

Donc cette tension entre deux cas d’utilisation force aussi à faire des arbitrages : si les conversions dépendent du trafic issu des moteurs, il vaut mieux découper le contenu en de multiples pages d’atterrissage répondant à des requêtes différentes. Si le parcours le plus fréquent est une descente dans le catalogue effectuée par des visiteurs passant par la home ou leurs favoris, alors la page unique redevient possible.

Fig. 4. Visualisation des parcours à l’aide de l’outil Web Analytics. Analyser les parcours utilisateurs en fonction de la source de la visite permet de se rendre compte quel est le parcours le plus fréquent et donc, quel est le parcours qu’il faut optimiser d’un point de vue expérience utilisateur… Dans de nombreux cas, la visite démarre depuis une page profonde..

Notons toutefois que nous verrons plus loin qu’il existe des solutions en HTML 5 pour avoir une page unique analysée par les moteurs comme étant plusieurs pages....

Quelques exemples de faux "conflits" entre SEO et UX

Il existe de nombreux points de "friction" entre SEO et UX. La plupart ont trouvé aujourd’hui leurs solutions techniques, soit parce que les moteurs ont évolué, soit parce que les techniques pour faire les sites web ont changé.

Prenons quelques exemples très fréquents, où l’on voit souvent ergonomes et SEO s’écharper mutuellement. Et voyons aussi des exemples de solution techniques qui rendent ces affrontements franchement inutiles

Privilégier les images au détriment du texte pour rendre les sites "plus beaux"

Les experts SEO demandent souvent à revoir les maquettes de site qui présentent surtout des images et peu de texte, en arguant que cela empêchera le site de bien se positionner.

Dans des cas extrêmes, évidemment, le problème existe. Par cas extrêmes, on entend ici l’absence quasi totale de textes et de légendes. Mais en l’absence de ces cas extrêmes, en réalité on se fiche du ratio images/textes car il n’est pris en compte nulle part dans l’algorithme. Et il suffit de peu de texte pour arriver à positionner une page sur une requête, dès lors que le contenu textuel est pertinent comme réponse sur cette requête.

Les pages riches en images sont également critiquées parce qu’elles sont lourdes à télécharger. Mais en HTML5, on peut parfaitement optimiser le chargement des images :

1. En appelant dynamiquement en Javascript la taille d’image adaptée à chaque usage (thumbnail sur mobile, image pleine taille en résolution Retina sur une tablette) ;
2. On peut même placer le lien vers le master de l’image en haute résolution dans une une balise <noscript> (non, ce n’est pas du cloaking) pour améliorer le classement de l’image dans Google Images. Un navigateur dont le Javascript est activé ne chargera pas cette image pesant plusieurs dizaines de mega octets.

Fig. 5. En HTML 5 + Javascript, on peut appeler dynamiquement la bonne taille d’image pour chaque dispositif et contexte d’utilisation : thumbnail sur smartphone ou en mode liste/grille, et image en grande taille sur tablette Desktop. Etc.

Les contenus chargés en Ajax

Pouvoir actualiser dynamiquement une zone d’une page sans la recharger apporte un réel avantage ergonomique, et cet avantage est apporté par la technologie Ajax. Les sites modernes en usent et en abusent parfois.

Le problème est que les moteurs de recherche ont jusqu’à présent éprouvé d’énormes difficultés à explorer, indexer et positionner correctement les contenus chargés en Ajax.

Une première solution technique était d’utiliser la méthode des "hash bangs" décrite ici :
https://developers.google.com/webmasters/ajax-crawling/docs/specification
Rappelons que cette méthode a été déclarée obsolète par Google il y a quelques mois. Elle est toujours supportée, mais ce support pourrait disparaître dans l’avenir.
Google préconise aujourd’hui une méthode en HTML 5 plus élégante et plus facile à maintenir : l’emploi de la méthode pushState() :
https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html
Cette méthode permet de rendre l’Ajax crawlable, et donc de pouvoir utiliser de l’Ajax en maîtrisant ce que les moteurs doivent crawler et indexer, sans changer l’ergonomie.
On peut trouver une démo du comportement de la fonction pushtate() à cette adresse :
http://html5.gingerhost.com/

Fig. 6. Une copie d’écran de la demo : un clic sur le lien « London » change
l’url affichée dans la barre du navigateur en http://html5.gingerhost.com/london.

Les long scrolling pages

Les "pages à défilement infini" sont ces pages qui chargent du contenu supplémentaire au fur et à mesure qu’on les fait défiler. L’interface de Google Images est un bon exemple de ces types de page.

L’intérêt ergonomique de ces pages sur des écrans tactiles n’est plus à démontrer. Mais les "long scrolling pages" sont souvent dénoncées en SEO car les moteurs ne peuvent pas toujours découvrir le contenu chargé en Ajax.

Il existe plusieurs solutions pour fabriquer des "long scrolling pages" compatibles mais là aussi, la solution la plus élégante est d’utiliser la méthode pushState().

John Mueller de Google a décrit une implémentation avec PushState() sur le blog webmaster de Google :
https://webmasters.googleblog.com/2014/02/infinite-scroll-search-friendly.html

Fig. 7. Le résultat obtenu grâce à cette méthode : à gauche le rendu utilisateur, qui est une page infinie. A droite la liste apparait pour un moteur comme une série d’éléments paginés, doté d’URL propres, et analysé par le moteur comme une liste paginée « normale » avec des balises rel next/prev.

L’avantage de ce type d’implémentation est double :

1. Les URL générées grâce à pushstate() sont des URL normales.
2. Et l’appel de ces URLs, si le code Javascript est bien fait, permet d’atterrir directement sur le bon écran. Donc en cas de recherche aboutissant sur la page, le problème d’UX évoqué plus haut ne se produira pas, le visiteur verra bien le contenu qu’il recherche.

Les carrousels bidimensionnels

La montée en puissance du nombre des tablettes et des écrans tactiles a conduit à des ergonomies de sites affichant leur contenu sous la forme d’écrans à défilement horizontal, ou vertical, quand ce n’est pas les deux à la fois.

Le contenu des écrans est souvent chargé en Ajax, ces sites présentent souvent pour caractéristique d’avoir une seule URL vue par les moteurs de recherche.

C’est évidemment un problème pour le SEO puisqu’on perd la relation "URL <->contenu", et le maillage interne existe sous une forme difficile à comprendre pour le moteur (puisque le passage d’un écran à l’autre ne se fait pas par des liens mais par des "tap" ou des actions gérées en Javascript).

La solution consiste à associer une URL à chaque écran (sauf les écrans dupliqués) à l’aide de la méthode pushState() en HTML 5. Et d’ajouter une vraie navigation par liens en plus des interactions en utilisant les URL créées par la méthode pushState(). Et on obtient le meilleur des deux mondes...

Fig. 8. Les carrousels sont de plus en plus communs à cause de leur adaptation aux interfaces tactiles, notamment sur les smartphones où l’on a de plus en plus des pages infinies verticalement combinée avec des carrousels horizontaux.

Les animations en Javascript et les effets de parallaxes

Le support du Flash pose de plus en plus de problèmes (notamment sur smartphones), donc cette technologie est de plus en plus abandonnée au profit d’autres solutions. Utiliser les possibilités d’animation en HTML5 est une alternative possible, mais elle n’est pas maîtrisée par assez de développeurs. C’est pourtant une solution qui permet facilement de rendre le contenu des animations crawlables par les moteurs.

Le plus souvent, les animations qui remplacent du Flash sont faites aujourd’hui en Javascript. Mais avec des technologies qui rendent le contenu des animations inaccessible aux moteurs.

Fig. 9. Une démo d’effet de parallaxe sur Alsacréations :
http://www.alsacreations.com/xmedia/tuto/exemples/parallaxe/etape3/

En soi, recourir à du Javascript pour réaliser ces animations n’est pas un problème. Ce qui l’est, c’est le non-respect de deux grands principes que doivent respecter les intégrateurs HTML/CSS/Javascript pour que leur code soit :

1. Maintenable ;
2. Compatible SEO ;
3. Et le plus léger possible (pour usage sur smartphone notamment).

Ces deux principes sont :

1. Le codage en amélioration progressive (progressive enhancement) ;
2. Et le codage en Javascript discret (unobstrusive javascript).

Amélioration Progressive et Javascript Discret

De nombreuses fonctionnalités modernes améliorant l’UX font un usage intensif du Javascript. Cet usage intensif, mal maîtrisé, est à l’origine de nombreux problèmes gênants ou bloquants pour le SEO. Mais ce n’est pas une fatalité.
Pour éviter ces problèmes, il faut d’abord coder le code interprété par le navigateur (HTML+CSS+Javascript) en respectant les principes de l’amélioration progressive.

Dans la pratique on crée :

1. Un code HTML basique, qui encapsule le contenu minimal à faire explorer et indexer par les moteurs, et qui présente une navigation par liens. Ce code est fonctionnel, et permet de naviguer sur le site et de consulter le contenu en situation dégradée : par exemple un navigateur dont le Javascript est désactivé, ou un bot de moteur de recherche plus archaïque que celui de Google.
2. Des feuilles de style CSS, qui améliorent le "look and feel" de la page.
3. Et une couche Javascript, qui donne accès à l’UX avancée pour cette page.

Le caractère "progressif" de ce concept signifie que l’on part d’une interface de base qui est améliorée dès lors que le navigateur est plus sophistiqué ou capable d’exploiter toutes les possibilités codées en Javascript.
Le codage en amélioration progressive est une bonne pratique d’intégration, qui est enseignée dans les écoles de web design.

Pour en savoir plus :
http://www.pompage.net/traduction/degradation-elegante-et-amelioration-progressive

Fig. 10. Les 3 couches d’une page web moderne : le HTML doit contenir le contenu à laisser explorer et indexer par les moteurs de recherche. Ensuite l’UX de base apportée par le code HTML peut être améliorée par le jeu des CSS et du Javascript, qui peuvent modifier radicalement l’apparence de la page et améliorer l’UX.

Le Javascript discret est un autre précepte de développement "front" : il recommande de ne pas mélanger Javascript et HTML d’une façon qui empêcherait un fonctionnement normal de la page si le Javascript est désactivé ou si un bug plante le moteur Javascript du navigateur.

Par exemple, les sites faits entièrement avec des framework Javascript, et où du code HTML appelle des librairies Javascript qui vont générer le code HTML vu par l’utilisateur final, ne respectent pas le principe du Javascript discret. C’est le cas de nombreuses implémentations de site faits avec AngularJS par exemple.
Pour en savoir plus :
https://fr.wikipedia.org/wiki/Javascript_discret

Le cas des liens de navigation

Pour des raisons d’UX, le nombre de liens présents sur les pages est parfois volontairement limité. Et les textes d’ancres aussi sont limités par manque de place sur l’interface (par exemple pour les liens dans les menus, ou le fil d’Ariane).
Ces choix ont un fort impact sur le maillage et notamment sur la profondeur des pages. Une profondeur des pages trop grande est aussi un problème d’UX donc corriger le problème de profondeur, à condition de bien l’expliquer, est quelque chose qu’il est possible d’obtenir même dans un contexte où l’on privilégie l’UX.

Fig. 11. Les breadcrumbs ont tendance à disparaître sur de nombreux sites, pour des raisons esthétiques. Par contre, il est important pour le SEO d’avoir quelque part des liens remontant les pages parentes. Mais ces liens peuvent être ajoutés n’importe où sur la page.

Pour les anchor texts : la seule solution est d’ajouter des liens (suggestions, liens similaires, blocs de navigation alternatifs) avec des anchor texts adaptés, et de les placer dans une zone moins visible que les "call to actions".

Et pour finir : non, le SEO ce n’est plus ça

Nous sommes en 2017, et certaines mauvaises pratiques n’ont plus d’intérêt pour le SEO, et ne sont plus un problème en raison de leur incompatibilité avec des objectifs d’optimisation de l’expérience utilisateur, notamment :

1. Le keyword stuffing (bourrage de mots clés) ;
2. Ajouter des textes SEO de qualité moyenne partout sur les pages ;
3. Et placer le tout au-dessus de la ligne de flottaison "parce que c’est mieux pour le SEO".

Fig. 12. Un exemple de keyword stuffing donné par Google. L’impact négatif sur l’expérience utilisateur est indéniable.
Les progrès de l’algorithme de Google diminuent l’intérêt de ces « optimisations ».

UX et SEO : une question de compétences ?

Les SEO d’aujourd’hui savent que l’algorithme de Google s’est sophistiqué, et que de façon directe ou indirecte, les sites qui proposent la meilleure expérience utilisateur finissent par être favorisés par le moteur de recherche.

Un bon expert SEO doit donc être à l’aise avec les bonnes pratiques en matière d’interface, sur desktop ou mobile. Il doit être capable de détecter les problèmes d’UX, et de proposer les solutions pour les corriger.
Mais avant tout, c’est une question de compétences techniques.

Pour obtenir un résultat sans compromis, il faut donc la rencontre entre deux compétences :

1. Celle de l’expert SEO d’abord, qui doit être capable d’aller au-delà de simples recommandations de base, et proposer des solutions techniques.
2. Et celle des techniciens et des développeurs chargés d’implémenter ces recommandations ensuite.

Bref, arrêtons d’opposer UX et SEO, design et SEO : il existe le plus souvent une solution technique qui permettra d’atteindre les objectifs de l’un et de l’autre. Encore faut-il avoir les compétences pour connaître cette solution, et l’implémenter correctement.