Vous avez été nombreux à être intrigués par l’annonce du thème de ma conférence au SMX Paris : “Le Edge SEO, ou comment faire du SEO dans le Nuage quand tout le reste à échoué”.

Vous trouverez les slides de cette conférence coprésentée avec Stéphane Rios de la startup Fasterize à la fin de cet article, mais comme les slides se résument souvent à une phrase et une illustration, je vais donc vous donner de plus amples explications.

Le principe du Edge SEO

L’idée derrière le Edge SEO, c’est d’exploiter les nouvelles possibilités offertes par les versions modernes des CDN, les Content Delivery Network.

Un CDN est un réseau de serveurs réparti partout dans le monde, à proximité des utilisateurs, et qui contient localement une copie des pages webs et des ressources (videos, images) afin de les délivrer rapidement et facilement aux utilisateurs finaux. Ce type de service est particulièrement utile pour un site dont l’audience est internationale, car cela permet d’éviter des “temps de latence” trop important, causés par les milliers de kilomètres de fils de cuivre et les centaines de boîtiers électroniques qui séparent le navigateur de l’internaute du serveur web.

Le CDN le plus connu est Akamai, mais il existe de nombreux autres opérateurs aujourd’hui comme Limelight, Cloudflare, Edgecast, Level 3, Fastly

Les CDN sont également utilisés pour répartir sur un réseau de serveurs les ressources lourdes à télécharger (notamment les videos). On trouve également des librairies javascript ou des polices disponibles sur des CDN gratuits (comme le service de Google) pour accélérer le temps de chargement de ces ressources dans le navigateur. Et les CDN servent également de couche de sécurité pour éviter les attaques Ddos, entre autres choses.

Dans un CDN, on appelle serveur origine le serveur web qui “fabrique” les pages web, et serveur “edge” le serveur du CDN situé le plus près de l’internaute et qui répond aux requêtes de son browser.

Les CDN passent dans le Nuage

Jadis, les CDN étaient toujours des serveurs physiques dotés d’un logiciel permettant de “coordonner” leur travail, et notamment de gérer le routage correct des requêtes http.

Mais cette architecture avait pour inconvénient de rendre la maintenance de ces énormes réseaux de serveurs compliquée, et en pratique, les configurations physiques et logicielles des multiples serveurs Edge pouvaient comporter de subtiles différences génératrices de bugs et de pannes.

Mais avec la montée en puissance des serveurs virtuels et de l’informatique distribuée, bref du Cloud, les CDN basculent de plus en plus vers une architecture de ce type : logiciels, configuration sont maintenus indépendamment de l’infrastructure physique, et on peut s’appuyer sur AWS d’Amazon ou Microsoft Azure pour créer un CDN.

C’est ce qu’une compagnie comme Cloudflare a compris très tôt : comme son nom le laisse soupçonner, Cloudflare offre un service de CDN construit à partir d’une architecture Cloud.

Il est maintenant possible de faire tourner des scripts complexes sur les serveurs Edge

Un serveur Edge dans un CDN fonctionne comme un cache. Ce qui signifie qu’il est efficace dès que l’on peut renvoyer une copie statique d’une ressource au navigateur. Si par contre, la page doit être personnalisée, comporter un contenu dynamique, changer en fonction d’un cookie etc., cela devient compliqué. Dans certaines situations, le CDN ne fait rien à part transmettre la requête au serveur web et renvoyer le contenu généré à des milliers de kilomètres au navigateur de l’internaute (on dit dans ce cas que le CDN est transparent).

Pour éviter cela les fournisseurs de CDN ont inventé en 2001 un langage permettant d’effectuer un certain nombre de fonctions simples sur les serveurs Edge : le langage ESI (Edge Side Includes). Mais les possibilités offertes étaient très limitées.

Mais depuis quelques années, Cloudflare propose les “Cloudflare Workers“. Et là, on a basculé dans une autre dimension…

Les possibilités très étendues des Cloudflare Workers ont permis au concept de Cloud SEO de naître

La magie des Cloudflare Workers

Les Cloudflare Workers sont des scripts rédigés en langage javascript (donc inutile d’apprendre un nouveau langage). Ils permettent d’intercepter les requêtes http: pour gérer diverses fonctions sur le serveur Edge, comme rafraîchir un élément d’une page.

Il y’a deux ans, j’avais identifié le potentiel des Cloudflare Workers pour le SEO, et j’avais appelé le concept “CLIO” (Cloud based Interleaved Optimizations). Vous retrouverez mes explications de l’époque dans cet article du blog de Search Foresight :

https://www.search-foresight.com/lapproche-clio-de-sf-une-nouvelle-facon-de-faire-le-seo/

C’est exactement le même concept que les anglo-saxons, suite aux conférences aux articles de Dan Taylor (un référenceur anglais) appellent aujourd’hui le Edge SEO.

Comment ça marche, le Edge SEO ?

Et bien c’est simple : via un script tournant sur un serveur Edge, cela consiste à modifier la page envoyée par un serveur web pour optimiser ce qui ne l’est pas :

  • les balises SEO : title, Hn, meta robots, desc, canonical, hreflang, alternate, amphtml etc.
  • le contenu
  • les entêtes http
  • les redirections
  • le maillage
  • etc.

Euh… mais pourquoi faire cela sur un serveur Edge ?

Si vous avez un blog de 100 pages sur la pêche à la ligne fait avec WordPress avec 1000 visites par mois, c’est sûr que faire du Edge SEO cela relève plus de l’emploi du bazooka pour tuer une mouche que d’une approche adaptée et efficiente du SEO…

Mais dans ma longue expérience de consultant SEO auprès d’un grand nombre de grand comptes, j’ai croisé pas mal de cas où déployer une optimisation SEO au niveau de l’applicatif ou du serveur web de l’éditeur, c’était impossible.

J’ai même croisé des référenceurs in-house compétents et motivés, mais désespérés parce que justement, à la moindre demande, on leur rétorquait “que cela n’allait pas être possible”.

Pourquoi ? Les raisons peuvent-être :

  • l’emploi de solutions non SEO Friendly, et qu’il n’est pas question d’améliorer parce que trop complexes
  • l’emploi de solutions en SAAS, pas vraiment SEO Friendly, et que vous ne pouvez pas optimiser parce que tout est hébergé chez l’éditeur et contrôlé par lui (allez, qui aime bien châtie bien, je cite deux solutions courantes mais frustrantes pour un SEO : Shopify et SalesForce Commerce Cloud (anciennement Demandware))
  • des équipes de dév débordées, qui dépriorisent systématiquement les projets SEO
  • des plateformes “usine à gaz” où changer le robots.txt ou ajouter un simple lien ou une meta description demande une mise en production sous monitoring, la mobilisation de 10 personnes et deux mois de délai.
  • les périodes de “freeze” durant des semaines où aucune modif n’est autorisée de peur de faire tomber la plateforme ou générer un bug

Et j’en passe et des biens meilleures que j’évoquerai un jour dans la rubrique im-pertinences de ce blog… (parce qu’à force d’appliquer la devise Shadock “Pourquoi faire simple quand on peut faire compliqué” dans les équipes webs, on finit par plonger dans l’absurde, l’improbable, et même… une autre dimension).

Le Edge SEO a ses limites, passons au Cloud SEO

Si vous lisez des articles en anglais sur le Edge SEO, vous allez vite vous rendre compte de deux choses :

  • ceux qui en parlent sont tous anglais (de Leeds, de Norwich, de Londres, du Sussex, de l’Essex). Mais ça ce n’est pas un effet de bord du Brexit, c’est juste que tout le microcosme anglais du référencement s’est intéressé au sujet après la première conférence de Dan Taylor à Brighton SEO
  • et tous les outils développés, tous les exemples tournent sur Cloudflare uniquement

Mais se baser uniquement sur Cloudflare a de sérieux inconvénients :

  • si vous utilisez un autre service de CDN, cela oblige à changer de prestataire, et cela ne se fait pas en un claquement de doigts
  • si vous n’avez pas de CDN, cela vous oblige à payer le service de Cloudflare en plus, ce qui est une barrière de plus à l’adoption

Du coup, la solution c’est de se tourner vers des solutions indépendantes des solutions de CDN, reprenant la même idée : faire tourner des services en javascript dans le Cloud pour optimiser les contenus avant de les envoyer au navigateur de l’internaute.

C’est la solution qu’on retrouve dans la solution d’A/B testing SEO de Distilled : ODN. (oui on peut faire de l’A/B testing en SEO, c’est même une approche qui devient incontournable pour avoir des résultats sans tâtonner à l’aveugle et de risquer un remède pire que le mal. Je prévois un article complet sur le sujet parce que c’est une approche encore peu courante et qu’il faut savoir faire dans les règles pour que les résultats soient probants).

Et c’est aussi la solution que l’on retrouve chez Fasterize, qui au départ ne modifiait pas le code pour faire du SEO, mais pour améliorer les performances des sites. Mais d’ici la fin de l’année, leurs clients pourront aussi faire des optimisations SEO via le back office de leur solution.

L’avantage de cette approche, c’est qu’elle est beaucoup plus facile à intégrer dans une architecture donnée :

  • si vous avez un CDN, le service de Cloud SEO s’intercale entre le CDN et le serveur origine
  • si vous n’avez pas de CDN, le service de Cloud SEO peut être le CDN (notamment s’il s’appuie sur AWS, Azure, Google Cloud…)

Une solution dans le sens de l’histoire

On parle de plus en plus de sites web serverless, le Cloud SEO va dans le sens de l’histoire. Mais on en est aux premiers pas : premiers outils, premières implémentations.

Si par malheur je n’ai pas été assez clair, ou si vous avez largué par les explications techniques, ou si vous avez des objections, n’hésitez pas à poser vos questions ou à faire des remarques dans les commentaires je serai ravi de pouvoir y répondre…

Et si vous voulez tester ce que cela donne en avant première c’est par ici : https://www.fasterize.com/fr/edge-seo/