La Renaissance du référencement technique : Le pourquoi et le comment du rôle oublié du référencement dans la mécanique du Web

La Renaissance du référencement technique : Le pourquoi et le comment du rôle oublié du référencement dans la mécanique du Web

La Renaissance du référencement technique : Le pourquoi et le comment du rôle oublié du référencement dans la mécanique du Web

Les technologies du web et leur adoption progressent à un rythme effréné. Le contenu est un jeu auquel jouent tous les types d’équipes et d’agences, nous sommes donc tous en compétition pour une part de ce gâteau. En attendant, le référencement technique est plus compliqué et plus important que jamais et une grande partie de la discussion sur le référencement s’est détournée de ses composantes techniques croissantes au profit du marketing de contenu.

En conséquence, le SEO connaît une renaissance où les composantes techniques reviennent au premier plan et nous devons nous y préparer. Dans le même temps, un certain nombre de leaders d’opinion ont déclaré que l’OMR moderne n’est pas technique. Ces déclarations déforment les opportunités et les problèmes qui ont germé sur le dos des nouvelles technologies. Elles contribuent également à un manque de connaissances techniques toujours plus grand dans le domaine du marketing de l’optimisation des moteurs de recherche et rendent difficile pour de nombreux moteurs de recherche de résoudre nos nouveaux problèmes.

Ce fossé des connaissances qui s’est creusé ces dernières années m’a incité à faire, pour la première fois, une « tournée » de présentation. Je donnais mon exposé sur la Renaissance de l’optimisation des moteurs de recherche sous une forme ou une autre depuis janvier, car je pensais qu’il était important d’alimenter une conversation sur le fait que les choses ont changé et que de nombreuses organisations et sites web pourraient être en retard s’ils ne tiennent pas compte de ces changements. Un certain nombre de choses se sont produites qui prouvent que je suis sur la bonne voie depuis que j’ai commencé à donner cette présentation, j’ai donc pensé qu’il valait la peine d’amener la discussion pour poursuivre la discussion. Pouvons-nous ?

Un bref historique du référencement (selon moi)

Il est intéressant de penser que le SEO technique est devenu une race en voie de disparition ces dernières années. Il fut un temps où c’était une condition préalable.

Image via PCMag

Personnellement, j’ai commencé à travailler sur le web en 1995 en tant que stagiaire au lycée chez Microsoft. Mon titre, comme celui de tous ceux qui travaillaient sur le web à l’époque, était « webmaster ». C’était bien avant que la profession de webmaster ne se divise en une myriade de disciplines. Il n’y avait pas de frontend vs. backend. Il n’y avait pas de personne en charge du développement ou de la gestion des ressources. Vous n’étiez qu’un webmaster.

À l’époque, avant que Yahoo, AltaVista, Lycos, Excite et WebCrawler n’entrent dans leur période de gloire, nous découvrions le web en cliquant sur des liens, en utilisant Gopher, Usenet, IRC, des magazines et par e-mail. À peu près à la même époque, IE et Netscape étaient engagés dans la guerre des navigateurs et vous aviez le choix entre plusieurs langages de script côté client. Les cadres faisaient fureur.

Puis les moteurs de recherche sont apparus. À vrai dire, à cette époque, je ne pensais pas vraiment au fonctionnement des moteurs de recherche. Je savais simplement que Lycos me donnait ce que je croyais être les résultats les plus fiables pour mes recherches. À ce moment-là, je n’avais aucune idée qu’il y avait un monde souterrain de gens qui manipulaient ces portails pour faire leurs enchères.

Entrez dans le SEO.

Image via Fox

Le référencement est né d’un échantillon de ces webmasters, le sous-ensemble des informaticiens qui comprenaient le domaine autrement ésotérique de la recherche d’informations et ces gens « Get Rich Quick on the Internet ». Ces marionnettistes d’Internet étaient essentiellement des magiciens qui échangeaient des conseils et des astuces dans les coins presque sombres du web. Ils étaient essentiellement des intellos qui extorquaient des dollars aux moteurs de recherche en remplissant des mots-clés, en faisant tourner le contenu et en le masquant.

Puis Google s’est présenté à la fête.

Image via droidforums.net

Les premières mises à jour de Google ont lancé le jeu du chat et de la souris qui permettrait de raccourcir certaines vacances perpétuelles. Pour condenser les 15 dernières années de l’histoire des moteurs de recherche en un court paragraphe, Google a modifié le jeu en passant de la pollution du contenu et de la manipulation des liens à une série de mises à jour commençant par la Floride et plus récemment par Panda et Penguin. Après les améliorations apportées à Panda and Penguin, le visage de l’industrie du référencement a changé de façon spectaculaire. Beaucoup des référenceurs les plus arrogants, qui disaient « je peux tout classer », ont fait leur entrée dans le monde des affaires, ont créé des sociétés de logiciels ou ont réduit leurs pertes en faisant autre chose. Cela ne veut pas dire que les hacks et les liens de spam ne fonctionnent plus, car c’est certainement le cas souvent. Au contraire, la sophistication de Google a fini par décourager beaucoup de gens qui n’ont plus le cran de faire les montagnes russes.

Simultanément, des gens de différentes disciplines ont commencé à se lancer dans le référencement. En fait, les gens sont toujours arrivés dans le domaine du référencement en provenance d’horizons professionnels très différents, mais cela a commencé à attirer beaucoup plus de gens du « marketing ». C’est très logique, car l’optimisation des moteurs de recherche en tant qu’industrie s’est fortement orientée vers le marketing de contenu. Après tout, nous devons obtenir ces liens d’une manière ou d’une autre, n’est-ce pas ?

L’image par l’entrepreneur

Naturellement, cela a engendré beaucoup de marketing auprès des spécialistes du marketing qui ont fait des déclarations comme « L’optimisation moderne des moteurs de recherche ne nécessite presque aucune expertise technique ».

Ou l’une de mes préférées, qui a peut-être attiré encore plus de colère : « Le référencement, c’est du maquillage ».

Image via le terrain des moteurs de recherche

Bien que je ne sois naturellement pas d’accord avec ces déclarations, je comprends pourquoi ces personnes apporteraient ces idées dans leur direction de la réflexion. Indépendamment du fait que j’ai travaillé avec ces deux hommes dans le passé et que je connais leurs prédispositions à l’égard du contenu, le point essentiel qu’ils font valoir est que de nombreux systèmes modernes de gestion de contenu sont à l’origine de bon nombre de nos meilleures pratiques d’optimisation des moteurs de recherche. Google est assez bon pour comprendre ce dont vous parlez dans votre contenu. En fin de compte, l’objectif de votre organisation doit être de créer quelque chose de significatif pour votre base d’utilisateurs afin que vous puissiez proposer un marketing compétitif.

Si vous vous souvenez de la dernière fois que j’ai essayé de plaider en faveur d’un changement de paradigme dans l’espace du référencement, vous avez raison de penser que je suis fondamentalement d’accord avec cette idée. Mais pas au prix d’ignorer le fait que le paysage technique a changé. L’référenceurs technique est le prix de l’admission. Ou, pour citer Adam Audette, « le référencement doit être invisible », pas du maquillage.

L’évolution de la technologie du web entraîne une renaissance technique

En matière de référencement, nous critiquons souvent les développeurs qui veulent toujours déployer la nouvelle chose brillante. Pour aller de l’avant, il est important que nous comprenions les nouvelles choses brillantes afin de pouvoir les optimiser plus efficacement.

Le référencement a toujours eu une peur saine du JavaScript, et pour cause. Bien que les moteurs de recherche disposent depuis au moins dix ans de la technologie nécessaire pour explorer le web de la même manière que nous le voyons dans un navigateur, il a toujours été difficile de savoir si ce contenu était réellement exploré et, surtout, indexé.

Lorsque nous avions initialement examiné l’idée de la navigation sans tête en 2011, la réponse collective a été que les frais de calcul l’interdisaient à l’échelle. Mais il semble que même si c’est le cas, Google pense qu’une partie suffisante du web est rendue à l’aide de JavaScript et que c’est un investissement qui en vaut la peine.

Avec le temps, de plus en plus de gens examineraient cette idée ; finalement, un commentaire de cet ex-Googler sur Hacker News indiquerait que c’est quelque chose que Google a compris depuis longtemps qu’il fallait conquérir :

C’était en fait mon rôle principal chez Google de 2006 à 2010.

L’un de mes premiers cas d’essai a été une certaine période des archives du Wall Street Journal sur leurs pages en langue chinoise, où tout le texte réel était dans une chaîne JavaScript littérale, et avant mes changements, Google pensait que toutes ces pages avaient un contenu identique… juste la chaudière de navigation. Comme le WSJ n’a pas fait cela pour ses pages en anglais, je suppose qu’il n’essayait pas de cacher le contenu aux moteurs de recherche, mais plutôt de contourner un vieux bogue de navigateur qui rendait le texte chinois incorrect (ou laid), mais le fait de rendre le texte via JavaScript a permis d’éviter ce bogue.

Les parties vraiment intéressantes étaient (1) d’essayer de s’assurer que le rendu était déterministe (de sorte que des pages identiques semblaient toujours identiques à Google à des fins d’élimination des doublons) (2) de détecter quand nous nous écartions de manière significative du comportement réel du navigateur (de sorte que nous ne générions pas trop d’URL absurdes pour le crawler ou trop de fausses redirections), et (3) faire en sorte que le navigateur émulé ressemble un peu à IE et Firefox (et plus tard Chrome) à un moment donné, de sorte que nous n’ayons pas eu des tonnes de pages qui disaient « revenez en utilisant IE » ou « veuillez télécharger Firefox ».

J’ai fini par modifier l’envoi du bytecode de SpiderMonkey pour aider à détecter quand le navigateur simulé s’était lancé dans les mauvaises herbes et générait probablement des absurdités.

J’ai eu beaucoup de mal à déterminer l’ordre dans lequel les différents événements JavaScript étaient déclenchés dans IE, FireFox et Chrome. Il s’avère que certaines pages déclenchent des événements dans des ordres différents entre une page fraîchement chargée et une page si vous appuyez sur le bouton de rafraîchissement. (C’est à ce moment que j’ai appris à maintenir la touche shift enfoncée tout en appuyant sur le bouton de rechargement du navigateur pour faire en sorte que celui-ci fasse comme s’il s’agissait d’une page fraîchement chargée).

A un moment donné, certains SEO ont compris que le random() retournait toujours 0,5. Je ne suis pas sûr que quelqu’un ait compris que JavaScript voyait toujours la date comme étant l’été 2006, mais je présume que cela a changé. J’espère qu’ils ont maintenant fixé la date et la graine aléatoires en utilisant un hachage cryptographique codé de tout le javascript chargé et du texte de la page, donc c’est déterministe mais très difficile à jouer. (Vous pouvez rendre la date déterministe pour un mois et les dates de différentes pages sautent en avant à des moments différents en ajoutant un HMAC du contenu de la page (nombre de secondes dans un mois) à l’heure actuelle, en arrondissant cette heure à la limite d’un mois, puis en soustrayant la valeur que vous avez ajoutée précédemment. Cela permet d’éviter une rotation excessive de l’index en changeant toutes les dates en même temps, tout en donnant à chaque page une date unique).

Maintenant, considérez ces statistiques d’utilisation de JavaScript sur le web à partir de BuiltWith :

JavaScript est évidemment là pour rester. La majeure partie du web l’utilise pour rendre du contenu sous une forme ou une autre. Cela signifie que la qualité de la recherche risque de s’effondrer avec le temps si Google ne peut pas comprendre le contenu des pages rendues en JavaScript.

En outre, le cadre de travail MVW de Google, AngularJS, a été adopté par un grand nombre de personnes ces derniers temps. Lorsque j’ai assisté à la conférence I/O de Google il y a quelques mois, les récentes avancées des applications Web progressives et de Firebase étaient mises à mal en raison de la vitesse et de la flexibilité qu’elles apportent au web. On ne peut que s’attendre à ce que les développeurs fassent un effort plus important.

Image via Builtwith

Malheureusement, malgré les contributions fantastiques de BuiltVisible sur le sujet, il n’y a pas eu assez de discussions autour des applications web progressives, des applications monopages et des cadres JavaScript dans l’espace SEO. Au lieu de cela, il y a des discussions sur les 301 contre les 302. Peut-être que le dernier pic d’adoption et la prolifération des PWAs, SPAs et JS frameworks à travers les différentes verticales vont changer cela. Chez iPullRank, nous avons travaillé avec un certain nombre d’entreprises qui sont passées à l’angulaire ; il y a beaucoup de choses qui valent la peine d’être discutées sur ce sujet spécifique.

En outre, la contribution de Facebook aux cadres JavaScript MVW, React, est adoptée pour la vitesse et les avantages très similaires de la flexibilité dans le processus de développement.

Cependant, en ce qui concerne le référencement, la différence essentielle entre Angular et React est que, dès le début, React a intégré une fonction renderToString qui permet au contenu de se rendre correctement du côté du serveur. Cela rend la question de l’indexation des pages de React plutôt triviale.

AngularJS 1.x, d’autre part, a donné naissance à une meilleure pratique de référencement, qui consiste à pré-rendre les pages à l’aide d’un appareil de capture d’écran sans tête piloté par un navigateur, tel que Prerender.io, Brombone, etc. C’est quelque peu ironique, car il s’agit d’un produit propre à Google. Nous y reviendrons plus tard.

Afficher la source est mort

En raison de l’adoption de ces cadres JavaScript, l’utilisation de View Source pour examiner le code d’un site web est une pratique obsolète. Ce que vous voyez dans View Source n’est pas le Document Object Model (DOM) calculé. Vous voyez plutôt le code avant qu’il ne soit traité par le navigateur. Le manque de compréhension des raisons pour lesquelles vous pourriez avoir besoin de voir le code d’une page différemment est un autre exemple où une compréhension plus détaillée des composants techniques du fonctionnement du web est plus efficace.

Selon la façon dont la page est codée, vous pouvez voir des variables à la place du contenu réel, ou vous pouvez ne pas voir l’arbre DOM complet qui se trouve là une fois que la page a été complètement chargée. C’est la raison fondamentale pour laquelle, dès qu’un référencement entend qu’il y a du JavaScript sur la page, la recommandation est de s’assurer que tout le contenu est visible sans JavaScript.

Pour illustrer ce point plus avant, considérez cette vue View Source de Seamless.com. Si vous recherchez la méta description ou le rel-canonical sur cette page, vous trouverez des variables à la place de la copie réelle :

Si vous regardez plutôt le code dans la section Elements de Chrome DevTools ou Inspect Element dans d’autres navigateurs, vous trouverez le DOM entièrement exécuté. Vous verrez que les variables sont maintenant remplies avec la copie. L’URL pour le rel-canonique 1 page, tout comme la méta description :

Comme les moteurs de recherche fonctionnent de cette manière, vous risquez de ne pas avoir une vue complète de ce qui se passe si vous utilisez par défaut la fonction Afficher les sources pour examiner le code du site.

HTTP/2 est en cours

L’un des principaux points d’intérêt de Google est la vitesse des pages. Pour être efficace en matière de référencement, il est indispensable de comprendre l’impact du réseau sur la vitesse des pages.

Avant l’annonce de HTTP/2, la spécification du protocole de transfert hypertexte n’avait pas été mise à jour depuis très longtemps. En fait, nous utilisons HTTP/1.1 depuis 1999. HTTP/2 est une grande nouveauté par rapport à HTTP/1.1, et je vous encourage à en prendre connaissance, car il contribuera de façon spectaculaire à la rapidité du web.

Image via Slideshare

Mais rapidement, l’une des plus grandes différences est que HTTP/2 utilisera une connexion TCP (Transmission Control Protocol) par origine et « multiplexera » le flux. Si vous avez déjà examiné les problèmes mis en évidence par Google PageSpeed Insights, vous remarquerez que l’une des principales questions qui se posent toujours est la limitation du nombre de requêtes HTTP/ C’est ce que le multiplexage permet d’éliminer ; HTTP/2 ouvre une connexion à chaque serveur, en y faisant transiter des ressources en même temps, en déterminant souvent les ressources nécessaires en fonction de la ressource initiale. Les navigateurs nécessitant une sécurité de la couche transport (TLS) pour exploiter HTTP/2, il est très probable que Google fasse une sorte de « push » dans un avenir proche pour que les sites web l’adoptent. Après tout, la vitesse et la sécurité ont été les fils conducteurs de tout ce qui s’est passé au cours des cinq dernières années.

Image via Builtwith

Ces derniers temps, de plus en plus d’hébergeurs ont mis en avant le fait qu’ils rendent HTTP/2 disponible, ce qui explique probablement la hausse significative de son utilisation cette année. La beauté de HTTP/2 est que la plupart des navigateurs le prennent déjà en charge et que vous n’avez pas à faire grand-chose pour l’activer, sauf si votre site n’est pas sécurisé.

Image via CanIUse.com

Gardez HTTP/2 sur votre radar, car il pourrait bien être l’aboutissement de ce que Google a encouragé.

Les outils de référencement sont à la traîne par rapport aux moteurs de recherche

Quand j’y pense de manière critique, les outils de SEO ont toujours été à la traîne par rapport aux capacités des moteurs de recherche. C’est normal, car les outils de référencement sont construits par de petites équipes et il faut donner la priorité aux choses les plus importantes. Un manque de compréhension technique peut vous amener à croire les informations des outils que vous utilisez alors qu’elles sont inexactes.

Lorsque vous examinerez la documentation de Google, vous constaterez que certains de mes outils préférés ne sont pas conformes aux spécifications de Google. Par exemple, Google vous permet de spécifier hreflang, rel-canonical, et x-robots dans les en-têtes HTTP. Il y a un énorme manque de cohérence dans la capacité des outils de référencement à vérifier ces directives.

Il est possible que vous ayez effectué un audit d’un site et trouvé difficile de déterminer pourquoi une page a été retirée de l’index. Cela pourrait très bien être dû au fait qu’un développeur a suivi la documentation de Google et a spécifié une directive dans un en-tête HTTP, mais votre outil de référencement ne l’a pas fait apparaître. En fait, il est généralement préférable de les définir au niveau de l’en-tête HTTP plutôt que d’ajouter des octets à votre temps de téléchargement en remplissant d’eux le Que sont vraiment les classements en 2016 ?

Les classements sont une chose amusante et, à vrai dire, ils le sont depuis un certain temps déjà. J’étais moi-même réticent à l’idée d’un classement moyen lorsque Google l’a introduit dans les outils pour webmasters et la console de recherche, mais les classements moyens ont en fait beaucoup plus de sens que les outils de classement standard. Je m’explique.

Les outils de référencement tirent des classements basés sur une situation qui n’existe pas vraiment dans le monde réel. Les machines qui grattent Google sont censées être propres et agnostiques, sauf si vous spécifiez explicitement un emplacement. En effet, ces outils cherchent à comprendre comment les classements seraient perçus par les utilisateurs effectuant une recherche pour la première fois sans contexte ni historique avec Google. Les logiciels de classement émulent un utilisateur qui se connecte au web pour la toute première fois et la première chose qu’il pense à faire est de chercher « canne à pêche de 4 pieds ». Ensuite, il cherche continuellement une série d’autres requêtes liées et/ou sans rapport avec le sujet, sans jamais cliquer sur un résultat. Certes, certains logiciels peuvent faire d’autres choses pour essayer d’imiter cet utilisateur, mais dans tous les cas, ils collectent des données qui ne reflètent pas nécessairement ce que voient les vrais utilisateurs. Et enfin, avec tant de personnes qui suivent si fréquemment les mêmes mots clés, il faut se demander à quel point ces outils gonflent le volume de recherche.

En fin de compte, nous ignorons le véritable contexte de l’utilisateur, en particulier dans le domaine du mobile.

Les outils de classement qui vous permettent de suivre les classements des mobiles vous permettent généralement de définir un seul contexte ou ils spécifieront simplement « téléphone mobile » comme option. Les recherches de Cindy Krum indiquent que les fonctionnalités et les classements du SERP seront différents selon la combinaison de l’agent utilisateur, de la marque et du modèle du téléphone, du navigateur et même du contenu de leur téléphone.

Les outils de classement ignorent également la réalité du choix de l’utilisateur. Nous sommes à une époque où il y a tout simplement tellement d’éléments qui composent le SERP, que le n°1 n’est tout simplement PAS le n°1. Dans certains cas, #1 est le 8ème choix sur la page et bien en dessous du pli.

Avec les AdWords ayant un 4ème emplacement publicitaire, le bio étant poussé bien en dessous du pli, et les utilisateurs n’étant pas sûrs de la différence entre bio et payant, être #1 en bio ne signifie plus ce qu’il était. Donc, lorsque nous regardons les rapports de classement qui nous disent que nous sommes numéro un, nous nous faisons souvent des illusions sur le résultat que cela va entraîner. Lorsque nous signalons cela à nos clients, nous ne nous concentrons pas sur la possibilité d’agir ou sur le contexte de l’utilisateur. Au contraire, nous nous concentrons entièrement sur la vanité.

Bien sûr, les classements ne sont pas un objectif commercial ; ils sont une mesure du potentiel ou de l’opportunité. Peu importe que nous parlions de la façon dont ils ne devraient pas être le principal KPI, les classements sont toujours quelque chose que les SEO pointent pour montrer qu’ils bougent l’aiguille. C’est pourquoi nous devrions envisager de considérer les classements organiques comme étant relatifs aux caractéristiques du SERP qui les entourent.

En d’autres termes, j’aimerais que les classements incluent à la fois le classement organique standard de 1 à 10 ainsi que la position absolue par rapport aux Paid, aux packs locaux et aux snippets vedettes. Toute autre chose reviendrait à ignorer l’impact des choix qui sont en grande partie offerts à l’utilisateur.

Récemment, nous avons vu quelques améliorations à cet effet avec Websterdata qui a apporté un grand changement à la façon dont ils font surface dans les classements et je sais qu’un certain nombre d’autres outils ont également mis en évidence les caractéristiques organiques. Qui sera le premier à mettre en évidence le contexte de la recherche intégrée ? Après tout, beaucoup d’utilisateurs ne connaissent pas la différence.

Qu’est-ce que l’occultation en 2016 ?

Le cloaking est officiellement défini comme le fait de montrer aux moteurs de recherche quelque chose de différent de l’utilisateur. Qu’est-ce que cela signifie lorsque Google permet des sites adaptatifs et réactifs et qu’il effectue des recherches sans tête et en mode texte ? Qu’est-ce que cela signifie lorsque Googlebot respecte les codes de réponse 304 ?

Dans les modèles adaptatifs et réactifs, il arrive souvent que plus ou moins de contenu soit affiché pour différents contextes. C’est rare dans le cas des modèles réactifs, car ils sont censés repositionner et dimensionner le contenu par définition, mais certaines implémentations peuvent au contraire réduire les composants du contenu pour que le contexte de visualisation fonctionne.

Dans le cas où un site réagit à la résolution de l’écran en changeant le contenu affiché et que plus de contenu est affiché au-delà de la résolution rendue par Googlebot, comment distinguer cela de l’occultation ?

De même, le code de réponse 304 est un moyen d’indiquer au client que le contenu n’a pas été modifié depuis sa dernière visite ; il n’y a donc aucune raison de le télécharger à nouveau.

Googlebot adhère à ce code de réponse pour éviter d’être une bête de somme de la bande passante. Qu’est-ce qui empêche donc un webmaster d’obtenir une version de la page indexée, de la modifier et de renvoyer un 304 ?

Je ne sais pas s’il existe des réponses définitives à ces questions pour le moment. Cependant, d’après ce que je vois dans la nature, elles se sont avérées être des opportunités pour les SEO techniques qui sont toujours dédiés à l’essai et à l’apprentissage.

Crawling

L’accessibilité du contenu, en tant que composante fondamentale que les OMR doivent examiner, n’a pas changé. Ce qui a changé, c’est le type d’effort analytique qu’il faut y consacrer. Il a été établi que les capacités d’exploration de Google se sont considérablement améliorées et des personnes comme Eric Wu ont fait un excellent travail pour faire apparaître les détails granulaires de ces capacités grâce à des expériences comme JSCrawlability.com

De même, je voulais tenter une expérience pour voir comment Googlebot se comporte une fois qu’il charge une page. En utilisant LuckyOrange, j’ai essayé de capturer une vidéo de Googlebot une fois qu’il arrive à la page :

J’ai installé le script LuckyOrange sur une page qui n’avait pas encore été indexée et je l’ai configuré pour qu’il ne se déclenche que si l’agent utilisateur contient « googlebot ». Une fois que j’ai été configuré, j’ai ensuite invoqué Fetch and Render depuis la console de recherche. J’avais espéré voir le défilement de la souris ou une tentative de remplissage de formulaire. Au lieu de cela, le curseur n’a jamais bougé et « googlebot » n’est resté sur la page que quelques secondes. Plus tard, j’ai vu un autre résultat de Googlebot à cette URL, puis la page est apparue dans l’index peu après. Il n’y avait aucune trace de la deuxième visite dans LuckyOrange.

Bien que j’aimerais faire des tests plus approfondis sur un site plus grand pour valider cette constatation, mon hypothèse à partir de cette expérience anecdotique est que Googlebot se rendra sur le site et déterminera si une page/site doit être explorée à l’aide du crawler sans tête. Sur cette base, il reviendra sur le site en utilisant le crawler approprié pour le travail.

Je vous encourage à faire un essai également. Vous n’êtes pas obligé d’utiliser LuckyOrange – vous pouvez utiliser HotJar ou tout autre outil similaire – mais voici mon code pour LuckyOrange :

jQuery(function() {
Window.__lo_site_id = XXXX ;
si (navigator.userAgent.toLowerCase().indexOf(‘googlebot’) >)
{
var wa = document.createElement(‘script’) ;
wa.type = ‘text/javascript’ ;
wa.async = true ;
wa.src = (‘https’ == document.location.protocol ? ‘https://ssl‘ : ‘http://cdn‘) + ‘.luckyorange.com/w.js’ ;
var s = document.getElementByTagName(‘script’)[0] ;
s.parentNode.insertBefore(wa,s) ;
// Marquez-le avec Googlebot
window._loq = window._low || [] ;
window._loq .push ([« tag », « Googlebot »]) ;
}
)) ;

La morale de l’histoire, cependant, est que ce que Google voit, à quelle fréquence il le voit, etc. sont toujours des questions primaires auxquelles nous devons répondre en tant qu’OMR. Bien que ce ne soit pas sexy, l’analyse des fichiers journaux est un exercice absolument nécessaire, surtout pour les projets de référencement de grands sites – peut-être maintenant plus que jamais, en raison de la complexité des sites. Je vous encourage à écouter tout ce que dit Marshall Simmonds en général, mais surtout sur ce sujet.

À cet effet, les statistiques d’exploration de Google dans la console de recherche sont totalement inutiles. Ces graphiques me disent quoi, exactement ? Super, merci Google, vous avez parcouru un tas de pages à un moment donné en février. Cool !

Il existe un grand nombre d’outils d’analyse des fichiers de log, de Kibana dans la pile ELK à d’autres outils comme Logz.io. Cependant, l’équipe de Screaming Frog a fait des pas de géant dans ce domaine avec la récente sortie de son analyseur de fichiers journaux.

Cet outil permet de gérer facilement des millions de fichiers, ce qui, je l’espère, est une indication de ce qui est à venir avec leur outil Spider. Quel que soit le fabricant de l’outil, les informations qu’il vous aide à débloquer sont incroyablement précieuses en termes de ce qui se passe réellement.

L’année dernière, nous avons eu un client qui était catégorique sur le fait que ses pertes en matière de bio n’étaient pas dues à la mise à jour de Penguin. Il pensait que cela pouvait être dû à l’arrêt d’autres campagnes traditionnelles et numériques qui auraient pu contribuer au volume de recherche, ou peut-être à la saisonnalité ou à un autre facteur. En extrayant les fichiers journaux, j’ai pu recouper toutes les données de toutes les campagnes en cours et montrer qu’il n’y avait rien de tout cela ; au contraire, l’activité de Googlebot a énormément diminué juste après la mise à jour de Penguin et en même temps que leur trafic de recherche organique. Les fichiers journaux l’ont clairement mis en évidence.

Il est conforme à la sagesse conventionnelle en matière d’optimisation des moteurs de recherche que Googlebot se base sur les pages qui ont la meilleure qualité et/ou quantité de liens pointant vers elles. En superposant le nombre de parts sociales, de liens et de visites sur Googlebot pour nos derniers clients, nous constatons qu’il y a plus de corrélation entre les parts sociales et l’activité d’exploration que les liens. Dans les données ci-dessous, la section du site qui contient le plus de liens est en fait celle qui est le moins explorée !

Il s’agit là d’informations importantes que vous ne faites peut-être que deviner sans prendre le temps de fouiller dans vos fichiers journaux.

Comment les fichiers journaux vous aident à comprendre AngularJS

Comme toute autre page web ou application, chaque demande donne lieu à un enregistrement dans les journaux. Mais selon la configuration du serveur, il y a une tonne de leçons qui peuvent en découler en ce qui concerne la configuration d’AngularJS, surtout si vous effectuez un pré-rendu en utilisant une des technologies d’instantanés.

Pour l’un de nos clients, nous avons constaté que souvent, lorsque le système de snapshot avait besoin de rafraîchir son cache, cela prenait trop de temps et était trop lent. Pour Googlebot, il s’agit de 5XX erreurs.

Ce comportement entraîne la chute de ces pages de l’index et, au fil du temps, nous avons vu des pages faire des allers-retours entre un classement très élevé et la disparition totale, ou une autre page du site prendre sa place.

En outre, nous avons constaté qu’il y avait de nombreux cas où Googlebot était mal identifié comme un utilisateur humain. En conséquence, Googlebot a reçu la page en direct d’AngularJS plutôt que l’instantané HTML. Cependant, malgré le fait que Googlebot ne voyait pas les instantanés HTML de ces pages, ces pages étaient toujours présentes dans l’index et se classaient très bien. Nous avons donc fini par travailler avec le client sur un test visant à supprimer le système d’instantanés sur certaines sections du site, et le trafic de recherche organique s’est en fait amélioré.

Ceci est directement en ligne avec ce que Google dit dans son annonce de la déprédation du système AJAX Crawling. Ils sont en mesure d’accéder au contenu rendu en utilisant JavaScript et indexeront tout ce qui est affiché au chargement.

Cela ne veut pas dire que les systèmes d’instantanés HTML ne valent pas la peine d’être utilisés. Le comportement de Googlebot pour les pages pré-rendues est qu’elles ont tendance à être explorées plus rapidement et plus fréquemment. Je pense que cela est dû au fait que l’exploration est moins coûteuse en termes de calcul pour leur exécution. Dans l’ensemble, je dirais que l’utilisation d’instantanés HTML reste la meilleure pratique, mais ce n’est certainement pas la seule façon pour Google de voir ce type de sites.

Selon Google, vous ne devriez pas servir des instantanés uniquement pour eux, mais aussi pour les améliorations de vitesse que l’utilisateur obtient.

En général, les sites Web ne doivent pas pré-rendre des pages uniquement pour Google. Nous espérons que vous pré-rendrez des pages pour améliorer les performances pour les utilisateurs et que vous suivrez des directives d’amélioration progressive. Si vous pré-rendu des pages, assurez-vous que le contenu servi à Googlebot correspond à l’expérience de l’utilisateur, tant au niveau de l’apparence que de l’interaction. Servir à Googlebot un contenu différent de celui qu’un utilisateur normal verrait est considéré comme du camouflage, et serait contraire à nos lignes directrices pour les webmasters.

Il s’agit de décisions hautement techniques qui ont une influence directe sur la visibilité des recherches organiques. D’après l’expérience que j’ai acquise en interviewant des référenceurs pour rejoindre notre équipe à iPullRank au cours de l’année dernière, très peu d’entre eux comprennent ces concepts ou sont capables de diagnostiquer des problèmes avec les instantanés HTML. Ces problèmes sont désormais courants et ne feront que s’aggraver à mesure que ces technologies continueront d’être adoptées.

Cependant, si nous devons également servir des instantanés à l’utilisateur, cela soulève la question : Pourquoi utiliserions-nous le cadre en premier lieu ? Naturellement, les décisions relatives à la pile technologique dépassent le cadre du simple référencement, mais vous pourriez envisager un cadre qui ne nécessite pas un tel appareil, comme MeteorJS.

Sinon, si vous voulez vraiment vous en tenir à Angular, envisagez Angular 2, qui prend en charge le nouvel Angular Universal. Angular Universal sert du JavaScript « isomorphe », ce qui est une autre façon de dire qu’il pré-rend son contenu côté serveur.

Angular 2 comporte toute une série d’améliorations par rapport à Angular 1.x, mais je vais laisser ces Googlers vous en parler.

Avant que tous les cadres de travail fous n’apparaissent, Google a eu une idée sur les technologies émergentes, à savoir « l’amélioration progressive ». Avec de nombreux nouveaux dispositifs IdO à l’horizon, nous devrions construire des sites web pour servir du contenu pour le plus petit dénominateur commun de fonctionnalité et sauver les cloches et les sifflets pour les dispositifs qui peuvent les rendre.

Si vous partez de zéro, une bonne approche consiste à construire la structure et la navigation de votre site en utilisant uniquement du HTML. Ensuite, une fois que vous avez mis en place les pages, les liens et le contenu du site, vous pouvez pimenter l’apparence et l’interface avec AJAX. Googlebot sera heureux de regarder le HTML, tandis que les utilisateurs de navigateurs modernes pourront profiter de vos bonus AJAX.

En d’autres termes, assurez-vous que votre contenu est accessible à tous. Criez à Fili Weise pour me le rappeler.

Le grattage est la faille fondamentale de l’analyse SEO

Le grattage est fondamental dans tout ce que font nos outils de référencement. cURL est une bibliothèque permettant de faire et de traiter des requêtes HTTP. La plupart des langages de programmation populaires ont des liens avec la bibliothèque et, de ce fait, la plupart des outils de référencement utilisent la bibliothèque ou quelque chose de similaire pour télécharger des pages web.

Considérez que cURL fonctionne de la même manière que le téléchargement d’un fichier unique à partir d’un FTP ; en termes de pages web, cela ne signifie pas que la page peut être visualisée dans son intégralité, car vous ne téléchargez pas tous les fichiers requis.

C’est un défaut fondamental de la plupart des logiciels de référencement pour la même raison que View Source n’est plus un moyen valable de visualiser le code d’une page. Parce qu’un certain nombre de transformations JavaScript et/ou CSS se produisent au chargement, et parce que Google grouille de navigateurs sans tête, vous devez regarder la vue Inspect (élément) du code pour avoir une idée de ce que Google peut réellement voir.

C’est là que la navigation sans tête entre en jeu.

L’une des bibliothèques de navigation sans tête les plus populaires est PhantomJS. De nombreux outils en dehors du monde du référencement sont écrits à l’aide de cette bibliothèque pour l’automatisation du navigateur. Netflix en possède même une pour gratter et prendre des captures d’écran appelée Sketchy. PhantomJS est construit à partir d’un moteur de rendu appelé QtWebkit, c’est-à-dire qu’il est bifurqué du même code que celui sur lequel est basé Safari (et Chrome avant que Google ne le bifurque en Blink). Bien que PhantomJS ne dispose pas des fonctionnalités des derniers navigateurs, il a suffisamment de fonctionnalités pour prendre en charge la plupart des éléments dont nous avons besoin pour l’analyse SEO.

Comme vous pouvez le voir dans le dépôt GitHub, des logiciels d’instantanés HTML tels que Prerender.io sont également écrits à l’aide de cette bibliothèque.

PhantomJS dispose d’une série de bibliothèques de wrappers qui le rendent assez facile à utiliser dans une variété de langues différentes. Pour ceux d’entre vous qui souhaitent l’utiliser avec NodeJS, consultez HorsemanJS.

Pour ceux d’entre vous qui sont plus familiers avec PHP, consultez PHP PhantomJS.

Un ajout plus récent et mieux qualifié au groupe des navigateurs sans tête est Headless Chromium. Comme vous l’avez peut-être deviné, il s’agit d’une version sans tête du navigateur Chrome. Si j’étais un parieur, je dirais que ce que nous avons ici est une sorte de fourchette de Googlebot édulcorée.

C’est donc probablement un élément que les sociétés de référencement devraient prendre en considération lorsqu’elles repenseront leur propre infrastructure de navigation à l’avenir, ne serait-ce que pour un groupe d’utilisateurs de premier plan. Si vous voulez en savoir plus sur Headless Chrome, consultez ce que Sami Kyostila et Alex Clarke (tous deux Googlers) ont dit à BlinkOn 6 :

Utiliser le grattage dans le navigateur pour faire ce que vos outils ne peuvent pas

Bien que de nombreux outils de référencement ne puissent pas examiner le DOM entièrement rendu, cela ne signifie pas que vous, en tant que référenceur individuel, devez passer à côté. Même sans utiliser un navigateur sans tête, Chrome peut être transformé en une machine à gratter avec juste un peu de JavaScript. J’en ai parlé longuement dans mon article « Comment gratter chaque page du Web ». En utilisant un peu de jQuery, vous pouvez effectivement sélectionner et imprimer n’importe quoi d’une page vers la console JavaScript, puis l’exporter vers un fichier dans la structure que vous préférez.

Cette méthode vous permet d’éviter une grande partie du codage nécessaire pour faire croire aux sites que vous êtes un véritable utilisateur, comme l’authentification et la gestion des cookies qui doivent se faire du côté serveur. Bien entendu, cette méthode de décodage est plus adaptée aux cas isolés qu’à la création de logiciels.

ArtooJS est un bookmarklet conçu pour permettre le grattage dans le navigateur et l’automatisation du grattage sur une série de pages et l’enregistrement des résultats dans un fichier sous forme de JSON.

Une solution plus complète est l’extension Chrome, WebScraper.io. Elle ne nécessite aucun code et permet de faire un pointer-cliquer sur l’ensemble du processus.

Comment aborder le contenu et les liens à partir du contexte technique

Une grande partie de ce que le SEO a fait ces dernières années a été dévolue à la création de plus de contenu pour plus de liens. Je ne sais pas si le fait d’ajouter quoi que ce soit à la discussion sur la façon d’augmenter le contenu ou de créer plus de liens est utile à ce stade, mais je soupçonne qu’il y a des possibilités pour les liens et le contenu existants qui ne sont pas prioritaires pour beaucoup de gens.

Google s’intéresse d’abord aux entités

Les googleurs ont récemment annoncé qu’ils examinent d’abord les entités lorsqu’ils étudient une requête. Une entité est la représentation par Google des noms propres dans leur système pour distinguer les personnes, les lieux et les choses, et pour informer leur compréhension du langage naturel. À ce stade de l’entretien, je demande aux gens de lever la main s’ils ont une stratégie d’entité. J’ai déjà fait cet exposé une douzaine de fois à ce stade et seules deux personnes ont levé la main.

Bill Slawski est le plus éminent penseur sur ce sujet, je vais donc m’en remettre à sa sagesse et vous encourager à lire :

Comment Google pourrait procéder à la reconnaissance des entités
SEO et les nouveaux résultats de recherche
Associations d’entités avec des sites web et des entités connexes

Je vous encourage également à utiliser un outil de traitement du langage naturel comme AlchemyAPI ou MonkeyLearn. Mieux encore, utilisez la propre API de traitement du langage naturel de Google pour extraire des entités. La différence entre votre recherche par mot-clé standard et les stratégies d’entités est que votre stratégie d’entités doit être construite à partir de votre contenu existant. Ainsi, pour identifier les entités, vous devez d’abord effectuer une recherche par mot-clé, puis faire passer ces pages de destination par un outil d’extraction d’entités pour voir comment elles s’alignent. Vous voudrez également faire passer les pages de renvoi de vos concurrents par ces mêmes API d’extraction d’entités pour identifier les entités ciblées par ces mots clés.

TF*IDF

De même, la fréquence des termes et des documents inversés ou TF*IDF est une technique de traitement du langage naturel qui ne fait pas l’objet de beaucoup de discussions de ce côté-ci de l’Atlantique. En fait, les algorithmes de modélisation de sujets ont fait l’objet de débats très animés dans la communauté du référencement dans le passé. Le problème est que les outils de modélisation thématique ont tendance à nous ramener vers l’âge des ténèbres de la densité des mots-clés, plutôt que de considérer l’idée de créer un contenu utile pour les utilisateurs. Cependant, dans de nombreux pays européens, on ne jure que par TF*IDF (ou WDF*IDF – Within Document Frequency/Inverse Document Frequency) comme technique clé qui permet d’augmenter la visibilité organique même sans liens.

Après avoir passé un peu de temps en Allemagne l’année dernière, certaines personnes ont réussi à me convaincre qu’un nouveau regard sur TF*IDF en valait la peine. Nous l’avons donc fait et nous avons commencé à l’intégrer dans notre processus d’optimisation du contenu.

Dans l’étude de Searchmetrics de 2014 sur les facteurs de classement, ils ont constaté que si TF*IDF avait en fait une corrélation négative avec la visibilité, les termes pertinents et probants avaient de fortes corrélations positives.

Image via Searchmetrics

En se basant sur l’examen de ces facteurs, Searchmetrics a demandé que TF*IDF ne soit plus analysé en 2015, en faveur des termes de preuve et des termes pertinents. D’année en année, la corrélation positive se maintient pour ces types de termes, bien qu’elle ne soit pas aussi élevée.

Images via Searchmetrics

Dans les facteurs de classement de Websterdata pour 2015, nous constatons que les éléments liés à l’ADL et au TF*IDF restent dans les facteurs de contenu les plus élevés sur la page.

En effet, quel que soit le modèle que vous examinez, l’idée générale est d’utiliser des mots-clés apparentés dans votre texte afin d’obtenir un meilleur classement pour le mot-clé cible principal, car cela fonctionne.

Je ne peux pas dire que nous avons examiné cette tactique isolément, mais je peux dire que les pages que nous avons optimisées à l’aide de TF*IDF ont vu leur classement progresser plus rapidement que celles qui n’en ont pas bénéficié. Bien que nous utilisions l’outil TF*IDF de OnPage.org, nous ne le suivons pas en utilisant des règles numériques strictes et rapides. Nous laissons plutôt les mots clés qui s’y rapportent influencer l’idéation et nous les utilisons ensuite comme ils ont un sens.

Cet ordre d’optimisation technique du contenu doit à tout le moins être revu. Pendant que vous y êtes, vous devriez aussi envisager les autres tactiques que Cyrus Shepard a mises en avant pour tirer le meilleur parti de vos efforts de marketing de contenu.

302s contre 301s – sérieusement ?

Ces derniers temps, un réexamen de la redirection 301 contre 302 est revenu dans la chambre d’écho du SEO. J’ai l’impression que les analystes des tendances des webmasters aux yeux du public aiment attirer l’attention ou s’ennuient, alors ils émettent de vagues tweets juste pour voir ce qui se passe.

Pour ceux d’entre vous qui préfèrent travailler plutôt que d’attendre que Gary Illyes tweet, tout ce que j’ai, c’est des données à partager.

Il était une fois une grande organisation médiatique avec laquelle nous avons travaillé. Comme c’est le cas pour ce genre d’organisations, leur équipe technique était réticente à mettre en œuvre la plupart de nos recommandations. Pourtant, ils avaient des millions de liens internes et externes pointant vers des URL qui renvoyaient 302 codes de réponse.

Après de nombreuses réunions, et une analyse de rentabilité plus convaincante, la seule chose substantielle que nous avons pu les convaincre de faire a été de changer ces 302 en 301. Presque du jour au lendemain, il y a eu une augmentation des classements dans la zone 1-3.

Malgré la saisonnalité, il y a eu une augmentation du trafic de la recherche organique également.

Je le répète, le seul changement substantiel à ce stade a été le passage des 302 aux 301. Il en a résulté quelques millions de visites supplémentaires en recherche organique d’un mois à l’autre. C’était il y a un an, certes, mais tant que quelqu’un ne m’aura pas montré que la même chose se produit ou qu’il n’y a pas de perte de trafic lorsque vous passez des 301 aux 302, nous n’aurons pas de discussion.

La liaison interne, l’approche technique

Selon le modèle PageRank, le flux de liens à travers le site est un élément incroyablement important à examiner. Malheureusement, une grande partie des discussions avec les clients ne portent que sur les liens externes et non sur la manière de mieux maximiser la densité de liens que possède déjà un site.

Il existe un certain nombre d’outils qui mettent ce concept au premier plan. Par exemple, Searchmetrics calcule et visualise le flux de la densité des liens sur l’ensemble du site. Cela vous donne une idée de l’endroit où vous pouvez créer des liens internes pour renforcer d’autres pages.

En outre, Paul Shapiro a rédigé un article convaincant sur la manière dont vous pouvez calculer gratuitement une version du PageRank interne à l’aide du logiciel de calcul statistique R.

L’une ou l’autre de ces approches est incroyablement utile pour offrir une plus grande visibilité au contenu et se situe dans le cadre de ce que peut offrir le référencement technique.

Les données structurées sont l’avenir de la recherche organique

La phrase la plus populaire est que Google cherche à devenir la couche de présentation du web. Aidez-les à le faire !

Il y a eu beaucoup de discussions sur la façon dont Google prend notre contenu et tente de mettre nos propres sites web hors jeu. Avec l’explosion du trafic que le secteur a constatée sur les sites qui se retrouvent en vedette, il est assez évident que, dans de nombreux cas, il est plus intéressant pour vous que Google reprenne votre contenu que de ne pas le faire.

Avec les appareils de recherche vocale sur les appareils mobiles et le prochain Google Home, l’utilisateur ne reçoit qu’une seule réponse. C’est-à-dire que l’ordinateur Star Trek que Google est en train de construire ne va pas lire tous les résultats – seulement un. Ces réponses sont alimentées par des cartes riches et des bribes d’informations, qui sont à leur tour alimentées par des données structurées.

Google nous a en fait rendu un grand service en ce qui concerne les données structurées en mettant à jour les spécifications qui permettent à JSON-LD. Avant cela, Schema.org consistait à apporter des modifications très fastidieuses et spécifiques au code avec un faible retour sur investissement. Maintenant, les données structurées alimentent un certain nombre de composants du SERP et peuvent être placées simplement à la d’un document assez facilement. Le moment est venu de revoir la mise en œuvre du balisage supplémentaire. Le guide des données structurées de Builtvisible reste la référence.

La vitesse des pages est toujours l’obsession de Google

Google a des attentes très agressives concernant la vitesse des pages, en particulier pour le contexte mobile. Ils veulent que le contenu ci-dessus se charge en une seconde. Cependant, 800 millisecondes de ce temps sont pratiquement hors de votre contrôle.

Image via Google

En fonction de ce que vous pouvez affecter directement, en tant que SEO, vous disposez de 200 millisecondes pour faire apparaître le contenu à l’écran. Une grande partie de ce qui peut être fait sur la page pour influencer la vitesse à laquelle les choses se chargent est l’optimisation de la page pour le chemin de rendu critique.

Image via Nianpeng Li

Pour comprendre ce concept, nous devons d’abord prendre un peu de recul pour avoir une idée de la façon dont les navigateurs construisent une page web.

Le navigateur prend l’adresse URL (uniform resource locator) que vous indiquez dans votre barre d’adresse et effectue une recherche DNS sur le nom de domaine.
Une fois qu’un socket est ouvert et qu’une connexion est négociée, il demande ensuite au serveur le code HTML de la page que vous avez demandée.
Le navigateur commence à analyser le HTML dans le Document Object Model jusqu’à ce qu’il rencontre le CSS, puis il commence à analyser le CSS dans le CSS Object Model.
Si à un moment donné il rencontre du JavaScript, il met en pause la construction du DOM et/ou du CSSOM jusqu’à ce que le JavaScript termine son exécution, à moins qu’il ne soit asynchrone.
Une fois que tout cela est terminé, le navigateur construit l’arbre de rendu, qui construit ensuite la mise en page de la page et enfin les éléments de la page sont peints.

Dans la section Timeline de Chrome DevTools, vous pouvez voir les différentes opérations au fur et à mesure qu’elles se déroulent et comment elles contribuent au temps de chargement. Dans la ligne de temps en haut, vous verrez toujours la visualisation en jaune car l’exécution de JavaScript est la plus longue de toutes les parties de la construction de la page. Le JavaScript provoque l’arrêt de la construction de la page jusqu’à ce que l’exécution du script soit terminée. C’est ce que l’on appelle le JavaScript « bloquant le rendu ».

Ce terme peut vous sembler familier car vous avez fouillé dans PageSpeed Insights à la recherche de réponses sur la manière d’apporter des améliorations et « Eliminer le JavaScript bloquant le rendu » est un terme courant. L’outil est principalement conçu pour soutenir l’optimisation du chemin critique de rendu (Critical Rendering Path). De nombreuses recommandations portent sur des questions telles que le dimensionnement statique des ressources, l’utilisation de scripts asynchrones et la spécification des dimensions des images.

En outre, les ressources externes contribuent de manière significative au temps de chargement des pages. Par exemple, je vois toujours la bibliothèque de Chartbeat prendre 3 secondes ou plus juste pour résoudre le DNS. Ce sont tous des éléments qui doivent être examinés lorsque l’on envisage de rendre le chargement d’une page plus rapide.

Si vous en savez beaucoup sur la spécification AMP (Accelerated Mobile Pages), une grande partie de ce que je viens de souligner pourrait vous sembler très familier.

L’AMP existe essentiellement parce que Google pense que le grand public est mauvais en matière de codage. Il a donc créé un sous-ensemble de HTML et a lancé un CDN global derrière pour que vos pages atteignent la marque de la seconde. Personnellement, j’ai une forte aversion pour l’AMP, mais comme beaucoup d’entre nous l’ont prédit au début de l’année, Google a déployé l’AMP au-delà du seul média vertical et dans tous les types de pages du SERP. La feuille de route indique qu’il y a beaucoup plus à venir, donc c’est certainement quelque chose que nous devrions creuser et chercher à capitaliser.

Utiliser les directives de pré-navigation pour accélérer les choses

Pour permettre d’améliorer la vitesse du site, la plupart des navigateurs disposent de conseils de ressources avant la navigation. Ces conseils vous permettent d’indiquer au navigateur qu’un fichier sera nécessaire plus tard dans la page. Ainsi, lorsque les composants du navigateur sont inactifs, il peut télécharger ou se connecter à ces ressources dès maintenant. Chrome cherche spécifiquement à faire ces choses automatiquement lorsqu’il le peut, et peut ignorer complètement vos spécifications. Cependant, ces directives fonctionnent un peu comme la balise rel-canonique – vous avez plus de chances d’en tirer profit que de ne pas en tirer profit.

Image via Google

Rel-préconnexion – Cette directive vous permet de résoudre le DNS, d’initier la poignée de main TCP et de négocier le tunnel TLS entre le client et le serveur avant que vous n’en ayez besoin. Lorsque vous ne le faites pas, ces choses se produisent l’une après l’autre pour chaque ressource plutôt que simultanément. Comme l’indique le schéma ci-dessous, dans certains cas, vous pouvez gagner près d’une demi-seconde rien qu’en faisant cela. Sinon, si vous voulez juste résoudre le DNS à l’avance, vous pouvez utiliser rel-dns-prefetch.

Si vous voyez beaucoup de temps d’inactivité dans votre Timeline dans Chrome DevTools, rel-preconnect peut vous aider à en réduire une partie.

Vous pouvez spécifier rel-preconnect avec

ou rel-dns-prefetch avec

Rel-prefetch – Cette directive vous permet de télécharger une ressource pour une page qui sera nécessaire à l’avenir. Par exemple, si vous voulez extraire la feuille de style de la page suivante ou télécharger le HTML de la page suivante, vous pouvez le faire en le spécifiant comme

Rel-prerender – A ne pas confondre avec le Prerender.io mentionné ci-dessus, rel-prerender est une directive qui vous permet de charger une page entière et toutes ses ressources dans un onglet invisible. Une fois que l’utilisateur clique sur un lien pour aller à cette URL, la page apparaît instantanément. Si l’utilisateur clique sur un lien que vous n’avez pas spécifié comme rel-prerender, la page pré-rendue est effacée de la mémoire. Vous spécifiez le « rel-prerender » comme suit :

J’ai déjà parlé de rel-prerender dans le passé dans mon post sur la façon dont j’ai amélioré la vitesse de notre site de 68,35% avec une ligne de code.

Il y a un certain nombre d’avertissements qui accompagnent rel-prerender, mais le plus important est que vous ne pouvez spécifier qu’une page à la fois et qu’un seul rel-prerender peut être spécifié sur tous les fils de discussion de Chrome. Dans mon article, je parle de la manière d’exploiter l’API Google Analytics pour déterminer au mieux l’URL que l’utilisateur est susceptible de visiter ensuite.

Si vous utilisez un logiciel d’analyse qui n’est pas Google Analytics, ou si vous avez des publicités sur vos pages, il comptera à tort les occurrences de rediffusion comme des vues réelles de la page. Il vous faudra donc intégrer tout JavaScript que vous ne souhaitez pas lancer avant que la page ne soit effectivement affichée dans l’API de visibilité de la page. En fait, vous ne lancerez les analyses ou les publicités que lorsque la page sera réellement visible.

Enfin, gardez à l’esprit que rel-prerender ne fonctionne pas avec le navigateur Firefox, iOS Safari, Opera Mini ou Android. Je ne sais pas pourquoi ils n’ont pas été invités à la pré-fête, mais je ne recommande pas de l’utiliser sur un appareil mobile de toute façon.

Rel-préchargement et rel-sous-ressource – Suivant le même schéma que ci-dessus, le rel-préchargement et le rel-sous-ressource vous permettent de charger des choses dans la même page avant qu’elles ne soient nécessaires. Le rel-subresource est spécifique à Chrome, tandis que le rel-preload fonctionne pour Chrome, Android et Opera.

Enfin, gardez à l’esprit que Chrome est suffisamment sophistiqué pour tenter toutes ces choses. Vos conseils en matière de ressources les aident à développer un niveau de confiance de 100 % pour agir sur eux. Chrome fait une série de prédictions basées sur tout ce que vous tapez dans la barre d’adresse et il garde une trace de ses prédictions pour déterminer ce qu’il faut préconnecter et précharger pour vous. Consultez les prédictions de chrome://predictors pour voir ce que Chrome a prédit en fonction de votre comportement.

Image via Google

Que devient le SEO à partir de là ?

Pour être un bon référenceur, il faut posséder une série de compétences qu’il est difficile pour une seule personne d’acquérir. Par exemple, un référenceurs doté de solides compétences techniques peut avoir du mal à assurer un travail de proximité efficace ou vice-versa. Naturellement, l’optimisation des moteurs de recherche est déjà stratifiée de cette manière entre les pages et les pages cachées. Cependant, les compétences techniques requises ont continué à augmenter de façon spectaculaire ces dernières années.

Il existe un certain nombre de compétences qui ont toujours donné un avantage injuste aux référenceurs techniques, telles que les compétences en matière de développement web et de logiciels ou même les compétences en matière de modélisation statistique. Il est peut-être temps de stratifier davantage le référencement technique par rapport à l’optimisation traditionnelle des pages en fonction du contenu, car les compétences requises sont plus celles d’un développeur web et d’un administrateur réseau que celles de ce que l’on considère généralement comme un référencement (du moins à ce stade du jeu). En tant qu’industrie, nous devrions envisager un rôle d’ingénieur SEO, comme l’ont déjà fait certaines organisations.

L’ingénieur SEO devra au moins maîtriser tous les éléments suivants pour pouvoir réellement tirer parti de ces possibilités techniques :

Modèle d’objet de document – La compréhension des éléments constitutifs des navigateurs web est fondamentale pour comprendre comment les développeurs de sites web manipulent le web au fur et à mesure qu’ils le construisent.
Chemin de rendu critique – Comprendre comment un navigateur construit une page et ce qui entre dans le rendu de la page aidera à améliorer la vitesse que Google exige de manière plus agressive.
Données structurées et balisage – Comprendre comment les métadonnées peuvent être spécifiées pour influencer la façon dont Google comprend les informations présentées.
Vitesse de la page – La compréhension des autres composants de codage et de mise en réseau qui influent sur le temps de chargement de la page est l’étape suivante naturelle pour accélérer la vitesse de la page. Bien entendu, il s’agit là d’un enjeu bien plus important que le référencement, car il a une incidence sur l’expérience générale de l’utilisateur.
Analyse des fichiers journaux – Il est nécessaire de comprendre comment les moteurs de recherche parcourent les sites web et ce qu’ils jugent important et accessible, surtout avec l’avènement des nouvelles technologies frontales.
SEO pour les cadres JavaScript – Il est essentiel de comprendre les implications de l’utilisation de l’un des cadres les plus populaires pour le développement en amont, ainsi que de comprendre en détail comment, pourquoi et quand un dispositif d’instantané HTML peut être nécessaire et ce qu’il faut pour le mettre en œuvre. L’autre jour encore, Justin Briggs a rassemblé la plupart des connaissances sur ce sujet en un seul endroit et les a décomposées en leurs composantes. Je vous encourage à y jeter un coup d’œil.
Chrome DevTools – Une compréhension de l’un des outils les plus puissants de la boîte à outils SEO, le navigateur web Chrome lui-même. Les fonctionnalités de Chrome DevTools associées à quelques plugins tiers comblent les lacunes pour de nombreuses choses que les outils de référencement ne peuvent actuellement pas analyser. L’ingénieur SEO doit être capable de construire quelque chose de rapide pour obtenir les réponses à des questions qui n’étaient pas posées auparavant par notre industrie.
Pages mobiles agrégées et pages instantanées Facebook – Si l’on en croit la feuille de route de l’AMP, les pages instantanées Facebook sont une spécification similaire et je pense qu’il sera difficile pour elles de continuer à exister exclusivement.
HTTP/2 – Une compréhension de la façon dont ce protocole va changer radicalement la vitesse du web et les implications en termes de référencement d’une migration de HTTP/1.1.
Rendons le référencement encore meilleur

L’une des choses qui ont toujours rendu le référencement intéressant et ses leaders d’opinion si convaincants, c’est que nous avons testé, appris et partagé ces connaissances de manière si intense. Il semble que cette culture de test et d’apprentissage ait été noyée dans le déluge de contenu. Peut-être que beaucoup de ces types de personnes ont disparu car les tactiques qu’elles connaissaient et aimaient ont été avalées par les animaux du zoo de Google. Peut-être que l’érosion continue de nos données rend de plus en plus difficile de tirer des conclusions solides.

Quoi qu’il en soit, à l’heure actuelle, il y a beaucoup moins de personnes qui testent et découvrent publiquement les possibilités. Nous devons exiger davantage de notre secteur, de nos outils, de nos clients, de nos agences et de nous-mêmes.

Arrêtons de courir après le train du contenu et revenons à des expériences qui fonctionnent.

À propos de l’iPullRank –

Michael King est un développeur de logiciels et de sites web qui est devenu un spécialiste du marketing depuis 2006. Il est le fondateur et le directeur général de l’agence de marketing numérique intégré iPullRank, spécialisée dans le référencement, l’automatisation du marketing, l’architecture des solutions, les médias sociaux, la stratégie de contenu et la mesure. Dans une vie antérieure, il a également été un rappeur international en tournée. Suivez le sur twitter @ipullrank ou sur son blog – The Best Practice

109
95