5 modi per utilizzare i file di registro per la SEO con Gerry White

Come stai sfruttando i file di registro per migliorare il tuo SEO?

Questo è ciò di cui parleremo oggi con un uomo con oltre 20 anni di esperienza nel settore SEO lavorando presso marchi e agenzie, tra cui BBC, Just Eat e Rise at Seven. Un caloroso benvenuto al podcast In Search SEO, Gerry White.

In questo episodio, Gerry condivide cinque modi per utilizzare i file di registro per la SEO, tra cui:

• Vedere come Google guarda il tuo sito
• Parametri
• Ci sono sottodomini che consumano il tuo crawl budget?
• File JavaScript e CSS
• Codici di risposta

Gerry: Ehi, felice di essere qui.

D: È bello averti addosso. Puoi trovare Gerry cercando Gerry White su LinkedIn. Quindi Gerry, ogni SEO dovrebbe usare i file di registro?

G: No, so che suona controverso quando dico che i file di log contengono enormi quantità di informazioni. Ma onestamente, la maggior parte delle volte si tratta di rendimenti decrescenti. E spesso puoi generalmente trovare molte informazioni prima di entrare nei file di registro. Quello che intendo con questo è che, se dai un'occhiata alle informazioni di Google Search Console, ci sono enormi quantità di informazioni lì. Quando ho esaminato i file di registro, è quando ho esaurito per la prima volta molti altri posti. Consiglio sempre di eseguire la scansione di un sito utilizzando qualcosa come Screaming Frog o qualsiasi altro crawler desktop che possiedi, quindi di guardare Google Search Console prima di iniziare a esaminare i file di registro.

Il motivo per cui lo dico, e il motivo per cui sembro quasi anti-logfile quando parlerò di quanto siano utili, è il fatto che in realtà è piuttosto impegnativo con cui lavorare inizialmente. E ci vuole un po' di abilità, conoscenza ed esperienza per metterci davvero le mani sopra e persino per accedervi. Ma una cosa grandiosa di oggi è il fatto che ora abbiamo effettivamente più accesso ai file di registro che mai. Inizialmente, quando ho iniziato, non avevamo Google Analytics o alcun software analitico come quello che abbiamo oggi. L'analisi del file di registro è stata il modo in cui abbiamo esaminato il modo in cui le persone visitavano i siti Web. Ora, non esaminiamo mai raramente i file di registro per come le persone guardano i siti Web, a meno che non stiamo facendo qualcosa con InfoSec. Oppure stiamo facendo qualcosa per diagnosticare qualcosa di veramente strano e meraviglioso.

Ma in realtà, la maggior parte delle volte, abbiamo un software di analisi molto migliore. Questo potrebbe cambiare perché in realtà, una cosa strana è il fatto che molti siti Web non sono in grado di tenere traccia di quante persone visitano una pagina 404, perché la maggior parte delle volte non fai mai clic sul fatto che accetti i cookie su una pagina 404 . All'improvviso, i file di registro tornano di nuovo per rispondere a domande molto strane come quella.

Ma il motivo principale per cui oggi parlo di file di log è per scopi SEO. Quindi sì, se hai problemi con siti di grandi dimensioni, se hai un grande sito di e-commerce, se hai un sito internazionale, multilingue, enorme con navigazione a faccette, allora i file di registro sono qualcosa che dovrebbe assolutamente essere preso in considerazione e sicuramente dovrebbe essere esaminato il più presto possibile.

D: Quindi oggi condividi cinque modi in cui la SEO dovrebbe utilizzare i file di registro. A partire dal numero uno, vedere come Google guarda il tuo sito.

1. Vedere come Google guarda il tuo sito

G: Sì, Google è abbastanza imprevedibile, quasi come un bambino ribelle. È strano perché anche se dico che possiamo esaminare i siti e utilizzare gli strumenti di scansione per dare un'occhiata a come Google dovrebbe guardare il sito, spesso siamo sorpresi di scoprire che Google è diventato ossessionato da un insieme di pagine o lungo uno strano percorso da qualche parte. O più recentemente, ho lavorato con un supermercato chiamato Odor nell'ultimo anno e una delle cose che abbiamo scoperto è che il bot di Google ha esaminato molto la configurazione dell'analisi e ha creato collegamenti artificiali da essa. Google sta trovando collegamenti interrotti. E per molto tempo ho cercato di capire perché trovasse decine di migliaia di 404 che non erano affatto sulla pagina. Ma si scopre che sta guardando la configurazione dell'analisi e creando un collegamento da quella. Quindi stiamo osservando l'impatto che ha avuto. E se guardiamo al fatto che Google sta trovando tutti questi 404, potrebbe non essere un grosso problema. Ma ora vogliamo sapere quanto tempo sta spendendo su quei 404, e se risolviamo questo piccolo problema, significherà che la scansione del resto del sito aumenterà del 20-30%? Qual è l'opportunità se lo aggiustiamo lì? Si tratta di capire perché Google sta guardando il sito in quel modo e cosa sta scoprendo che in realtà non dovrebbe trovare.

2. Parametri

L'altra cosa che guardiamo spesso sono i parametri. Non so se lo sai, ma i SEO si collegano sempre alla versione canonica della pagina. Quello che voglio dire è che spesso ci sono più versioni di una pagina che a volte hanno una sorta di tracciamento interno o tracciamento esterno. Ci sono tanti modi in cui possiamo collegarci a una pagina e spesso un prodotto, ad esempio, può trovarsi in più posti in un sito. Un buon esempio di ciò è che ho lavorato su un sito, che era Magento. E ogni prodotto sembrava rientrare in ogni singola categoria, quindi è stato fantastico quando abbiamo scoperto che esistevano circa 20 versioni di ogni prodotto e ogni prodotto era scansionabile. Quindi, da lì, sapevamo che anche Google stava impiegando un'enorme quantità di tempo a eseguire la scansione del sito. E la cosa interessante è che, se rimuovi un prodotto, Google dirà "Oh, ma ho altre 19 versioni di questo prodotto", quindi ci vorrà un po' prima che la pagina effettiva scompaia quasi se hai utilizzato un 404 o qualcosa del genere a causa del modo in cui funziona Google. Google vedrà che si tratta di una versione canonica di questa pagina. Ma se rimuovi la versione canonica, inizierà a usarne di diverse. E questo è il tipo di informazioni che ci fornisce il file di log.La capacità per noi di guardare il sito nel modo in cui lo è Google.

E ci permette anche di guardare cose come i codici di stato. Un ottimo esempio di ciò è che c'è un codice di stato che dice che non sono stato modificato. E per la vita di me in questo momento, non riesco a pensare a cosa sia, avrei dovuto scriverlo prima di questo podcast. Ma fondamentalmente, il "Non sono stato modificato" migliora enormemente la velocità di scansione di un sito Web. E quando scopro che questo era qualcosa che Google rispettava, quello che potevo fare era con tutte le immagini, tutti i prodotti e tutti questi bit e pezzi che non vengono modificati molto regolarmente, se possiamo utilizzare un non modificato e possiamo migliorare la velocità di scansione di Google, migliorare l'efficacia e ridurre il carico sul server, possiamo quindi migliorare in modo significativo il modo in cui Google trova tutti i diversi prodotti.

Il modo in cui Google guarda le cose, vogliamo, vogliono gli amministratori del server e tutti vogliono, è che il server sia il più veloce ed efficiente possibile. Ancora una volta, tornando al lato dei file di registro, al giorno d'oggi, non potremmo utilizzare i file di registro in modo efficace, per molti anni. Perché con i CDN, spesso scopri che ci sarebbero più punti in cui una pagina verrebbe colpita. E il CDN spesso non aveva un file di registro stesso. Quindi esamineremo tutti questi posti diversi e vedremo quanto carico c'è su questo server e quanto carico c'è su quel server. E proviamo a mettere tutto insieme e i file di registro saranno in un formato diverso. Ora con i CDN, possiamo effettivamente iniziare a comprendere l'efficacia di un CDN. Improvvisamente, cose come PageSpeed ​​sono fortemente influenzate e migliorate dal fatto che se utilizziamo i file di registro, possiamo iniziare a capire il fatto che l'immagine, ad esempio, attraverso la canonizzazione delle immagini, quindi se c'è un'immagine utilizzata su più pagine, come fintanto che gli URL sono coerenti, il CDN funziona e Google lo scansiona meglio. Sì, ci sono tanti modi diversi in cui i file di registro aiutano a migliorare PageSpeed, memorizzare nella cache e servire utenti e motori di ricerca in modo molto più efficiente.

D: Sto rivedendo i tuoi cinque punti che stavi per condividere. E ci sono diversi elementi che hai già condiviso. Mi ricordi qualcuno a cui posso solo fare una domanda e mi danno un episodio di podcast di 15 minuti senza fare ulteriori domande. Quindi c'è una persona che probabilmente può farlo, anche più di te. E probabilmente è Duane Forrester. Duane e io abbiamo scherzato sul fatto che lo facesse, io gli facevo solo una domanda e io me ne andavo e lo lasciavo solo a condividere il contenuto per il resto dell'episodio. Ma hai parlato un po' di parametri. Non so se hai toccato il punto numero tre, ovvero scoprire se ci sono sottodomini che stanno consumando il crawl budget, perché non dovrebbero esserci.

3. Ci sono sottodomini che consumano il tuo crawl budget?

G: Questo in realtà risale a Just Eat. A un certo punto, abbiamo scoperto che il sito Web era replicato su più sottodomini diversi e tutti questi erano scansionabili. Ora, curiosamente, questi non avevano visibilità secondo strumenti come Citrix. E il motivo per cui non l'hanno fatto è stato perché era tutto canonizzato. Quindi, quando abbiamo scoperto che sebbene questi duplicati fossero là fuori, Google spendeva un po' meno dal 60 al 70% del suo budget per la scansione di questi sottodomini. E a causa del modo in cui questi non venivano memorizzati nella cache allo stesso modo a causa dei CDN e di altre tecnologie, questo stava effettivamente creando molti carichi di server. Quindi è stato qualcosa di affascinante per noi, perché lo stavamo semplicemente ignorando come un problema che deve essere risolto in futuro. Perché sapevamo del problema. Sapevamo che c'era una specie di problema e ne avevo parlato. Ma l'avevo deprioritizzato fino a quando non abbiamo iniziato a guardare i file di registro.

Abbiamo visto che Google sta spendendo molta energia, tempo e risorse qui. Quanto carico del server sta creando? Quanto ha influito? E non siamo riusciti a capire quanto fosse carico di un server a causa del modo in cui il server non era in grado di interpretare le diverse fonti. Quindi è stato affascinante che, una volta ottenuti i file di registro, potessimo migliorare notevolmente l'affidabilità del sito web. Quindi sapevamo dei sottodomini, semplicemente non sapevamo quanto fosse un problema fino a quando non abbiamo iniziato a esaminare i file di registro. E poi all'improvviso, abbiamo visto che questo deve essere risolto al più presto. Era una di quelle cose che sapevamo come sistemare, era solo una priorità. Era in fondo alla coda ed è salito al numero due.

4. File JavaScript e CSS

D: Hai toccato la canonicalizzazione ma hai anche detto che, nello specifico, i file JavaScript e CSS possono essere un problema. Perché?

G: Una delle cose che facciamo spesso è rompere la cache aggiungendo un parametro al file CSS. Il motivo per cui lo facciamo è quello che succede se usi un CDN o qualcosa di simile, è che ogni volta che aggiorni il CSS, crei nuove pagine o qualcosa del genere, allora il problema è che hai un file CSS che è memorizzato nella cache e le nuove pagine non saranno in grado di usarlo. E abbiamo lunghi tempi di cache su tutti questi diversi file JavaScript e CSS. Quindi all'interno della pagina, non appena aggiungiamo qualcosa che richiede l'aggiornamento di JavaScript o CSS, devi solo modificare leggermente il parametro al suo interno. Da lì, quello che dovevamo assicurarci era che tutti i diversi server utilizzassero la stessa versione dei parametri in avanti. Ed era qualcosa in cui se lavori con più team diversi, più siti Web diversi, l'unico JavaScript migliore che alimenta l'intera cosa, ci siamo sempre assicurati che fosse la versione giusta. E i file di registro sono stati un modo in cui ci siamo assicurati che tutte le diverse pagine raggiungessero costantemente la versione JavaScript corretta perché forse dovevamo aggiornare una chiave API o qualcosa di simile. C'erano così tanti modi diversi in cui dovevamo farlo. E questo era qualcosa che era un compito enorme per gli sviluppatori.

Una delle cose che stavamo osservando nei file di registro era, il vecchio veniva colpito, da dove veniva colpito e potevamo sistemarlo? Abbiamo anche scoperto che esistono molti modi diversi in cui è possibile scrivere il percorso del file JavaScript. Ad esempio, era in un sottodominio se usavamo un nome host diverso, perché, curiosamente, se lavori su più siti Web diversi, spesso scopri che ci sono URL diversi o nomi di dominio diversi che accedono effettivamente allo stesso server. E spesso se si utilizza un CDN o si utilizza una sottodirectory, a volte può essere molto incoerente. E dal punto di vista dell'utente, se stai colpendo lo stesso file JavaScript in sei o sette modi diversi all'interno di un viaggio, lo stai caricando in sei o sette modi diversi. E anche se potrebbe non sembrare molto, cumulativamente, ciò aggiunge alcuni megabyte al tuo viaggio. E questo, ovviamente, rallenta l'intera esperienza e rende i server meno efficienti. E c'è molto di più. Quindi assicurati che la versione corretta di JavaScript, CSS e altri bit e pezzi venga sempre colpita. E assicurati anche che non ci sia motivo per nascondere JavaScript con parametri o qualcosa del genere. Ci sono tanti modi in cui si possono creare trappole per ragni, che includono i file JavaScript, dove, per esempio, qualcosa viene taggato al suo interno, dove forse non usano il giusto riferimento assoluto al JavaScript. Quindi si trova in una directory diversa rispetto ad altre volte. Sono sorprendenti tutti i diversi modi in cui puoi individuare quando JavaScript viene caricato in modo leggermente diverso da più pagine diverse. Quindi sì, è molto semplice. Ma è sorprendentemente costoso quando si tratta di analisi.

5. Codici di risposta

D: Assicurandoti anche che i codici di risposta vengano consegnati nel modo che desideri. Un esempio di ciò è attraverso TOS che a volte viene visto o non viene visto da Google che dovrebbe o non dovrebbe essere. Quindi perché dovrebbe accadere?

G: Ancora una volta, visitiamo sempre le pagine Web utilizzando lo stesso browser, la stessa tecnologia, la stessa esperienza e tutto il resto. Cerco di assicurarmi di utilizzare altri strumenti diversi da quelli che uso di solito, poiché tutti fanno un audit Screaming Frog, quindi provo a utilizzare tutti i tipi di frammenti. Ma facciamo sempre finta di essere un po' come un computer. Quindi non fingiamo mai di essere Googlebot, non fingiamo mai di essere tutte queste cose diverse. Quindi, se osservi come i robot di Google accedono a un determinato file da un indirizzo IP diverso... un sacco di tecnologia come CloudFlare, se fai finta di essere Googlebot e stai tentando di accedervi utilizzando Screaming Frog, sa che stai non Googlebot, in realtà sei questo. E quindi ti tratta in modo diverso da come tratteresti Googlebot. E così spesso, i server sono configurati per pre-renderizzare cose per fare tutti i pezzi. E si sta solo assicurando che tutti ricevano il codice di risposta corretto dal server a quel punto.

E sembra abbastanza semplice, ma quando stai scalando a livello internazionale... Quando hai reindirizzamenti geografici, se un utente o un motore di ricerca non può accedere a una determinata pagina perché qualcuno ha inserito un reindirizzamento geografico per dire che se visiti questo website dalla Spagna, quindi vai e carica questa sottodirectory... Non può quindi guardare le versioni root o le versioni alternative. Ecco perché cose come la correttezza dei codici di risposta è assolutamente fondamentale. Ed è sorprendente quanto spesso passi attraverso queste cose e presumi che tutto sia impostato correttamente. Perché di volta in volta sappiamo come dovrebbe essere impostato. Lo diamo a qualcuno, qualcuno lo interpreta, un'altra persona lo implementa e qualcun altro lo esamina. E poi qualcun altro fa clic su un pulsante sul CDN, che dice: "Oh, possiamo geolocalizzare qualcuno in questo particolare posto". Non è tanto il fatto che qualcuno abbia fatto qualcosa di sbagliato, è tanto che c'è qualcosa lungo la catena che l'ha effettivamente spezzata leggermente.

Il sottaceto di Pareto - Frutto basso

D: Finiamo con il Pareto Pickle. Pareto dice che puoi ottenere l'80% dei tuoi risultati dal 20% dei tuoi sforzi. Qual è un'attività SEO che consiglieresti che fornisce risultati incredibili per livelli di impegno modesti?

G: La cosa che preferisco al momento è che ho una dashboard di Google Data Studio molto semplice, che mi permette di dare un'occhiata a quello che chiamo il frutto basso. Ora, tutti odiano il bingo di parole d'ordine. Ma questa è la mia cosa in cui guardo le cose che non sono del tutto classificate come dovrebbero. Guardo tutte le parole chiave in cui si posizionano per un particolare insieme di pagine, ricette, prodotti o qualcosa del genere. Un buon esempio è che, al momento, sto lavorando su decine di migliaia di prodotti, guardo tutte le pagine che hanno avuto impressioni elevate, ma potrebbero esserci alla posizione sei e posso lavorarle fino alla posizione 3. E nove volte su dieci puoi farlo semplicemente assicurandoti che i tag del titolo siano migliorati e che il collegamento interno sia migliorato. Cose molto semplici per scoprire quali delle parole chiave con un volume di ricerca elevato possono essere aumentate un po' di più per aumentare la percentuale di clic.

D: Sono stato il tuo ospite, David Bain. Puoi trovare Gerry cercando Gerry White su LinkedIn. Gerry, grazie mille per essere nel podcast In Search SEO.

G: Il mio piacere. Grazie per il tuo tempo.

D: E grazie per l'ascolto. Dai un'occhiata a tutti gli episodi precedenti e iscriviti per una prova gratuita della piattaforma Rank Ranger.