5 façons d'utiliser les fichiers journaux pour le référencement avec Gerry White

Comment tirez-vous parti des fichiers journaux pour améliorer votre référencement ?

C'est ce dont nous allons parler aujourd'hui avec un homme avec plus de 20 ans d'expérience dans l'industrie du référencement travaillant pour des marques et des agences, notamment la BBC, Just Eat et Rise at Seven. Bienvenue au podcast In Search SEO, Gerry White.

Dans cet épisode, Gerry partage cinq façons d'utiliser les fichiers journaux pour le référencement, notamment :

• Voir comment Google regarde votre site
• Paramètres
• Y a-t-il des sous-domaines qui consomment votre budget de crawl
• Fichiers JavaScript et CSS
• Codes de réponse

Gerry : Hé, content d'être là.

D : C'est bon de vous avoir. Vous pouvez trouver Gerry en recherchant Gerry White sur LinkedIn. Alors Gerry, chaque référenceur devrait-il utiliser des fichiers journaux ?

G : Non, je sais que cela semble controversé quand je dis que les fichiers journaux, nous avons d'énormes quantités d'informations. Mais honnêtement, la plupart du temps, ce sont des rendements décroissants. Et souvent, vous pouvez généralement trouver beaucoup d'informations avant d'aller dans les fichiers journaux. Ce que je veux dire par là, c'est que si vous jetez un coup d'œil aux informations de la console de recherche Google, vous y trouverez d'énormes quantités d'informations. Quand j'ai regardé dans les fichiers journaux, c'est quand j'ai d'abord épuisé beaucoup d'autres endroits. Je recommande toujours d'explorer un site en utilisant quelque chose comme Screaming Frog ou n'importe quel robot d'exploration de bureau que vous avez, puis de regarder Google Search Console avant de commencer à regarder les fichiers journaux.

La raison pour laquelle je dis cela, et la raison pour laquelle j'ai l'air presque anti-logfiles quand je vais parler de leur utilité, est le fait qu'ils sont en fait assez difficiles à utiliser au départ. Et il faut un peu de compétence, de connaissances et d'expérience pour vraiment mettre la main dessus, et même pour y accéder. Mais une grande chose à propos d'aujourd'hui est le fait que maintenant, nous avons en fait plus accès aux fichiers journaux que presque jamais auparavant. Au début, quand j'ai commencé, nous n'avions pas Google Analytics ni aucun logiciel d'analyse comme nous en avons aujourd'hui. L'analyse du fichier journal était la façon dont nous examinions la façon dont les gens visitaient les sites Web. Maintenant, nous ne regardons jamais rarement les fichiers journaux pour savoir comment les gens regardent les sites Web, à moins que nous ne fassions quelque chose avec InfoSec. Ou nous faisons quelque chose pour diagnostiquer quelque chose de vraiment étrange et merveilleux.

Mais en fait, la plupart du temps, nous avons de bien meilleurs logiciels d'analyse. Cela pourrait changer parce qu'en fait, une chose étrange est le fait que beaucoup de sites Web ne peuvent pas suivre le nombre de personnes qui accèdent à une page 404, car la plupart du temps, vous ne cliquez jamais sur le fait que vous accepterez les cookies sur une page 404 . Soudain, les fichiers journaux reviennent pour répondre à des questions très étranges comme celle-là.

Mais la principale raison pour laquelle je parle de fichiers journaux aujourd'hui est à des fins de référencement. Alors oui, si vous avez des problèmes avec de grands sites, si vous avez un grand site de commerce électronique, si vous avez un site international, multilingue et énorme avec une navigation à facettes, alors les fichiers journaux sont quelque chose qui devrait absolument être pris en compte et devrait certainement être examiné le plus tôt possible.

D : Donc, aujourd'hui, vous partagez cinq façons dont le référencement devrait utiliser les fichiers journaux. Commençons par le numéro un, voir comment Google regarde votre site.

1. Voir comment Google regarde votre site

G : Oui, Google est assez imprévisible, presque comme un enfant indiscipliné. C'est étrange parce que même si je dis que nous pouvons regarder des sites et que nous pouvons utiliser des outils d'exploration pour voir comment Google devrait regarder le site, nous sommes souvent surpris de découvrir que Google est devenu obsédé par un ensemble de pages ou par sur une route étrange quelque part. Ou plus récemment, je travaille depuis un an pour un supermarché appelé Odor, et l'une des choses que nous avons trouvées est que le bot Google a beaucoup étudié le type de configuration analytique et créé des liens artificiels à partir de celui-ci. Google trouve des liens brisés. Et pendant longtemps, j'ai essayé de comprendre pourquoi il trouvait des dizaines de milliers de 404 qui n'étaient pas du tout sur la page. Mais il s'avère qu'il a examiné la configuration analytique et créé un lien à partir de cela. Nous examinons donc l'impact que cela a eu. Et si nous examinons le fait que Google trouve tous ces 404, ce n'est peut-être pas un gros problème. Mais maintenant, nous voulons savoir combien de temps il passe sur ces 404, et si nous résolvons ce petit problème, cela signifiera-t-il que l'exploration du reste du site augmentera de 20 à 30 % ? Quelle est l'opportunité si nous le réparons là-bas ? Il s'agit de regarder pourquoi Google regarde le site comme ça, et ce qu'il trouve qu'il ne devrait vraiment pas trouver.

2. Paramètres

L'autre chose que nous examinons souvent, ce sont les paramètres. Je ne sais pas si vous le savez, mais les spécialistes du référencement doivent toujours créer un lien vers la version canonique de la page. Ce que je veux dire, c'est qu'il existe souvent plusieurs versions d'une page qui ont parfois une sorte de suivi interne ou de suivi externe. Il existe de nombreuses façons de créer un lien vers une page et souvent un produit, par exemple, peut se trouver à plusieurs endroits sur un site. Un bon exemple de cela est que j'ai travaillé sur un site, qui était Magento. Et chaque produit semblait appartenir à chaque catégorie, donc c'était incroyable quand nous avons découvert qu'il y avait environ 20 versions de chaque produit, et que chaque produit était explorable. Donc, à partir de là, nous savions que Google passait également beaucoup de temps à parcourir le site. Et ce qui est intéressant, c'est que si vous supprimez un produit, Google dira en quelque sorte "Oh, mais j'ai 19 autres versions de ce produit", il faudra donc un certain temps pour que la page réelle disparaisse presque si vous avez utilisé un 404 ou quelque chose comme ça à cause de la façon dont Google fonctionne. Google verra qu'il s'agit d'une version canonique de cette page. Mais si vous supprimez la version canonique, il commencera à en utiliser d'autres. Et c'est le genre d'informations que le fichier journal nous donne.La possibilité pour nous de regarder le site de la même manière que Google.

Et cela nous permet également de regarder des choses comme les codes de statut. Un bon exemple de ceci est qu'il y a un code d'état qui indique que je n'ai pas été modifié. Et pour ma vie en ce moment, je ne peux pas penser à ce que c'est, j'aurais dû l'écrire avant ce podcast. Mais en gros, le "je n'ai pas été modifié" améliore massivement le taux de crawling d'un site web. Et quand j'apprends que c'était quelque chose que Google respectait, ce que je pouvais faire c'était avec toutes les images, tous les produits , et tous ces éléments qui ne sont pas modifiés très régulièrement, si nous pouvons utiliser un non modifié, et nous pouvons améliorer la vitesse d'exploration de Google, améliorer l'efficacité et réduire la charge sur le serveur, nous pouvons puis améliorez considérablement la manière dont Google trouve tous les différents produits.

La façon dont Google regarde les choses, nous voulons, les administrateurs du serveur veulent, et tout le monde veut, est que le serveur soit aussi rapide et aussi efficace que possible. Encore une fois, pour en revenir au côté des fichiers journaux, de nos jours, nous ne pouvions plus du tout utiliser efficacement les fichiers journaux pendant de nombreuses années. Parce qu'avec les CDN, vous constaterez souvent qu'il y aura plusieurs endroits où une page sera consultée. Et le CDN n'avait souvent pas de fichier journal lui-même. Nous allons donc examiner tous ces différents endroits et voir combien de charge il y a sur ce serveur et combien de charge est sur ce serveur. Et nous essayons de tout rassembler et les fichiers journaux seront dans un format différent. Maintenant, avec les CDN, nous pouvons réellement commencer à comprendre l'efficacité d'un CDN. Soudainement, des choses comme PageSpeed ​​sont massivement impactées et améliorées par le fait que si nous utilisons des fichiers journaux, nous pouvons commencer à comprendre le fait que l'image, par exemple, par canonisation des images, donc s'il y a une image utilisée sur plusieurs pages, comme tant que les URL sont cohérentes, le CDN fonctionne et Google l'explore mieux. Oui, il existe de nombreuses façons différentes d'utiliser les fichiers journaux pour améliorer PageSpeed, mettre en cache et servir les utilisateurs et les moteurs de recherche beaucoup plus efficacement.

D : Je passe en revue vos cinq points que vous alliez partager. Et vous en avez déjà partagé différents éléments. Vous me rappelez quelqu'un à qui je ne peux poser qu'une seule question et ils me donnent un épisode de podcast de 15 minutes sans poser d'autres questions. Il y a donc une personne qui peut probablement le faire, encore plus que vous. Et c'est probablement Duane Forrester. Duane et moi avons plaisanté sur le fait qu'il faisait cela, je lui posais juste une question et je m'éloignais et le laissais juste partager le contenu pour le reste de l'épisode. Mais vous avez parlé un peu des paramètres. Je ne sais pas si vous avez abordé le point numéro trois, qui consiste à découvrir s'il y a des sous-domaines qui consomment du budget de crawl, car il ne devrait pas y en avoir.

3. Y a-t-il des sous-domaines qui consomment votre budget de crawl ?

G : Cela remonte en fait à Just Eat. À un moment donné, nous avons découvert que le site Web était répliqué sur plusieurs sous-domaines différents, et tous étaient explorables. Maintenant, fait intéressant, ceux-ci n'avaient aucune visibilité selon des outils comme Citrix. Et la raison pour laquelle ils ne l'ont pas fait était que tout était canonisé. Ainsi, lorsque nous avons découvert que bien que ces doublons existaient, Google dépensait un peu moins de 60 à 70 % de son budget pour explorer ces sous-domaines. Et en raison de la manière dont ceux-ci n'étaient pas mis en cache de la même manière à cause des CDN et d'autres technologies, cela créait en fait beaucoup de charges de serveur. C'était donc quelque chose qui était fascinant pour nous, parce que nous ignorions simplement cela comme un problème qui doit être résolu dans un avenir très proche. Parce que nous connaissions le problème. Nous savions qu'il y avait une sorte de problème, et j'en avais parlé. Mais je l'avais dépriorisé jusqu'à ce que nous commencions à regarder les fichiers journaux.

Nous avons vu que Google dépense beaucoup d'énergie, de temps et de ressources ici. Combien de charge serveur crée-t-il ? Quel impact cela a-t-il eu ? Et nous ne pouvions pas comprendre à quel point il s'agissait d'une charge de serveur à cause de la façon dont le serveur n'était pas capable d'interpréter les différentes sources. Il était donc fascinant que lorsque nous obtenions les fichiers journaux, nous puissions améliorer considérablement la fiabilité du site Web. Nous connaissions donc les sous-domaines, nous ne savions tout simplement pas à quel point c'était un problème jusqu'à ce que nous commencions à examiner les fichiers journaux. Et puis tout à coup, nous avons vu que cela devait être corrigé dès que possible. C'était une de ces choses que nous savions comment arranger, c'était juste la priorisation. Il était au bas de la file d'attente et il a été repoussé au numéro deux.

4. Fichiers JavaScript et CSS

D : Vous avez évoqué la canonisation, mais vous avez également dit que, plus précisément, les fichiers JavaScript et CSS peuvent poser problème. Pourquoi donc?

G : Une des choses que nous faisons souvent est de casser le cache en ajoutant un paramètre au fichier CSS. La raison pour laquelle nous faisons cela est ce qui se passe si vous utilisez un CDN ou quelque chose de similaire, c'est que chaque fois que vous mettez à jour le CSS, vous créez de nouvelles pages, ou quelque chose, alors le problème est que vous avez un fichier CSS qui est mis en cache et les nouvelles pages ne pourront pas l'utiliser. Et nous avons de longs temps de cache sur tous ces différents fichiers JavaScript et CSS. Ainsi, dans la page, dès que nous ajoutons quelque chose qui nécessite que le JavaScript ou le CSS soit mis à jour, vous modifiez simplement légèrement le paramètre qu'il contient. À partir de là, nous devions nous assurer que tous les différents serveurs utilisaient la même version de paramètres à l'avenir. Et c'était quelque chose où si vous travaillez dans plusieurs équipes différentes, plusieurs sites Web différents, le meilleur JavaScript qui alimente le tout, nous nous sommes toujours assurés que c'était la bonne version. Et les fichiers journaux étaient un moyen de nous assurer que toutes les différentes pages utilisaient systématiquement la bonne version de JavaScript, car nous devions peut-être mettre à jour une clé API ou quelque chose de similaire. Il y avait tellement de façons différentes de le faire. Et c'était quelque chose qui était une tâche énorme pour les développeurs.

L'une des choses que nous examinions dans les fichiers journaux était, l'ancien était-il touché, d'où il était touché, et pourrions-nous le réparer ? Nous avons également constaté qu'il existe de nombreuses façons différentes d'écrire le chemin d'accès au fichier JavaScript. Par exemple, c'est dans un sous-domaine que nous avons utilisé un nom d'hôte différent, car, fait intéressant, si vous travaillez sur plusieurs sites Web différents, vous constatez souvent qu'il existe différentes URL ou différents noms de domaine qui accèdent réellement au même serveur. Et souvent, si vous utilisez un CDN ou un sous-répertoire, cela peut parfois être très incohérent. Et du point de vue de l'utilisateur, si vous accédez au même fichier JavaScript de six ou sept manières différentes au cours d'un parcours, vous le chargez de six ou sept manières différentes. Et bien que cela puisse sembler peu, cumulativement, cela ajoute quelques mégaoctets à votre voyage. Et cela, bien sûr, ralentit toute l'expérience et rend les serveurs moins efficaces. Et il y a bien plus que cela. Assurez-vous donc que la bonne version de JavaScript, CSS et autres éléments est toujours utilisée. Et assurez-vous également qu'il n'y a aucune raison pour que le JavaScript soit caché avec des paramètres ou quelque chose. Il y a tellement de façons de créer des pièges à araignées, y compris les fichiers JavaScript, où, par exemple, quelque chose y est marqué, où peut-être qu'ils n'utilisent pas la bonne référence absolue au JavaScript. Il se trouve donc dans un répertoire différent des autres fois. Il est surprenant de voir toutes les différentes façons dont vous pouvez repérer lorsque JavaScript est chargé légèrement différemment par plusieurs pages différentes. Alors oui, c'est très simple. Mais c'est étonnamment cher quand il s'agit d'analyse.

5. Codes de réponse

D : Assurez-vous également que les codes de réponse sont livrés de la manière que vous souhaitez. Un exemple de cela est que les TOS sont parfois vus ou non par Google, ce qui devrait ou ne devrait pas l'être. Alors pourquoi cela arriverait-il?

G : Encore une fois, nous visitons toujours des pages Web en utilisant le même navigateur, la même technologie, la même expérience et tout. J'essaie de m'assurer que j'utilise d'autres outils que ceux que j'utilise habituellement, comme tout le monde fait un audit Screaming Frog, donc j'essaie d'utiliser toutes sortes de morceaux. Mais nous prétendons toujours que nous sommes un peu comme un ordinateur. Donc, nous ne prétendons jamais que nous sommes Googlebot, nous ne prétendons jamais que nous sommes toutes ces choses différentes. Donc, si vous regardez comment les bots Google accèdent à un fichier particulier à partir d'une adresse IP différente... beaucoup de technologies comme CloudFlare, si vous prétendez que vous êtes Googlebot, et que vous essayez d'y accéder en utilisant Screaming Frog, il sait que vous êtes pas Googlebot, vous êtes en fait ceci. Et donc il vous traite différemment de la façon dont vous traiteriez Googlebot. Et si souvent, les serveurs sont configurés pour pré-rendre les choses pour faire tous les morceaux. Et il s'agit simplement de s'assurer que tout le monde reçoit le bon code de réponse du serveur à ce moment-là.

Et cela semble assez simple, mais lorsque vous vous développez à l'échelle internationale… Lorsque vous avez des redirections géographiques, si un utilisateur ou un moteur de recherche ne peut pas accéder à une page particulière parce que quelqu'un a mis une redirection géographique pour dire que si vous visitez ce site web depuis l'Espagne, puis allez charger ce sous-répertoire... Il ne peut donc pas regarder les versions racine ou les versions alternatives. C'est pourquoi des choses comme les codes de réponse corrects sont absolument essentielles. Et il est surprenant de voir combien de fois vous passez par ces choses et vous supposez que tout est correctement configuré. Parce que maintes et maintes fois, nous savons comment cela doit être mis en place. Nous donnons cela à quelqu'un, quelqu'un l'interprète, une autre personne le met en œuvre et quelqu'un d'autre le traverse. Et puis quelqu'un d'autre clique sur un bouton du CDN, qui dit : "Oh, nous pouvons géolocaliser quelqu'un à cet endroit particulier." Ce n'est pas tant le fait qu'une personne ait fait quelque chose de mal, c'est tellement qu'il y a quelque chose dans la chaîne qui l'a effectivement légèrement brisé.

Le cornichon de Pareto - Fruit à portée de main

D : Finissons avec le Pareto Pickle. Pareto dit que vous pouvez obtenir 80 % de vos résultats à partir de 20 % de vos efforts. Quelle est une activité de référencement que vous recommanderiez qui fournit des résultats incroyables pour des niveaux d'effort modestes ?

G : Ce que je préfère en ce moment, c'est que j'ai un tableau de bord Google Data Studio très basique, qui me permet de jeter un œil à ce que j'appelle les fruits à portée de main. Maintenant, tout le monde déteste le bingo à la mode. Mais c'est mon truc où je regarde des choses qui ne se classent pas aussi bien qu'elles le devraient. Je regarde tous les mots-clés où ils se classent pour un ensemble particulier de pages, ou de recettes, ou de produits, ou quelque chose. Un bon exemple est que, pour le moment, je travaille sur des dizaines de milliers de produits, je regarde toutes les pages qui ont obtenu des impressions élevées, mais il peut y en avoir à la position six, et je peux les travailler jusqu'à la position 3. Et neuf fois sur dix, vous pouvez le faire en vous assurant simplement que les balises de titre se sont améliorées et que les liens internes se sont améliorés. Des trucs très simples pour savoir lequel des mots-clés avec le volume de recherche élevé peut être augmenté un peu plus pour augmenter le taux de clics.

D : J'ai été votre hôte, David Bain. Vous pouvez trouver Gerry en recherchant Gerry White sur LinkedIn. Gerry, merci beaucoup d'être sur le podcast In Search SEO.

G : Mon plaisir. Merci pour votre temps.

D : Et merci pour votre écoute. Découvrez tous les épisodes précédents et inscrivez-vous pour un essai gratuit de la plateforme Rank Ranger.