5 moduri de a utiliza fișierele de jurnal pentru SEO cu Gerry White

Cum profitați de fișierele jurnal pentru a vă îmbunătăți SEO?

Despre asta vom vorbi astăzi cu un bărbat cu peste 20 de ani de experiență în industria SEO, care lucrează la mărci și agenții, inclusiv BBC, Just Eat și Rise at Seven. Un călduros bun venit la podcast-ul In Search SEO, Gerry White.

În acest episod, Gerry împărtășește cinci moduri de a utiliza fișierele jurnal pentru SEO, inclusiv:

• Vedeți cum arată Google site-ul dvs
• Parametrii
• Există subdomenii care vă consumă bugetul de accesare cu crawlere
• Fișiere JavaScript și CSS
• Codurile de răspuns

Gerry: Hei, mă bucur că sunt aici.

D: Mă bucur să te am pe tine. Îl puteți găsi pe Gerry căutându-l pe Gerry White pe LinkedIn. Deci, Gerry, fiecare SEO ar trebui să folosească fișiere de jurnal?

G: Nu, știu că sună controversat când spun că fișierele jurnal, avem cantități uriașe de informații. Dar, sincer, de cele mai multe ori este în scădere. Și adesea puteți găsi o mulțime de informații înainte de a intra în fișierele jurnal. Ceea ce vreau să spun prin asta este că, dacă arunci o privire în informațiile din Google Search Console, există cantități uriașe de informații acolo. Când m-am uitat în fișierele jurnal, am epuizat mai întâi multe alte locuri. Recomand întotdeauna să accesați cu crawlere un site folosind ceva precum Screaming Frog sau orice crawler de pe desktop pe care îl aveți și apoi să vă uitați la Google Search Console înainte de a începe să vă uitați la fișierele jurnal.

Motivul pentru care spun asta și motivul pentru care sun aproape anti-fișierele jurnal atunci când voi vorbi despre cât de utile sunt, este faptul că inițial este destul de dificil să lucrezi cu ele. Și este nevoie de puțină abilitate, cunoștințe și experiență pentru a pune mâna pe ele și chiar pentru a avea acces la ele. Dar un lucru grozav despre astăzi este faptul că acum avem de fapt mai mult acces la fișierele jurnal decât aproape niciodată. Inițial, când am început, nu aveam Google Analytics sau vreun software de analiză ca și astăzi. Analiza fișierelor de jurnal a fost modul în care am privit modul în care oamenii au vizitat site-urile web. Acum, nu ne uităm niciodată la fișierele jurnal rar pentru modul în care oamenii privesc site-urile web, cu excepția cazului în care facem ceva cu InfoSec. Sau facem ceva pentru a diagnostica ceva cu adevărat ciudat și minunat.

Dar, de fapt, de multe ori avem un software de analiză mult mai bun. Acest lucru s-ar putea schimba, deoarece, de fapt, un lucru ciudat este faptul că multe site-uri web nu pot urmări câți oameni merg la o pagină 404, pentru că de multe ori nu dați clic niciodată pe că veți accepta cookie-uri pe o pagină 404. . Deodată, fișierele de jurnal revin din nou pentru a răspunde la câteva întrebări foarte ciudate de genul acesta.

Dar motivul principal pentru care vorbesc despre fișierele jurnal astăzi este în scopuri SEO. Deci, da, dacă aveți probleme cu site-urile mari, dacă aveți un site mare de comerț electronic, dacă aveți un site internațional, multilingv, imens, cu navigare fațetă, atunci fișierele de jurnal sunt ceva care cu siguranță ar trebui luat luate în considerare și cu siguranță ar trebui să fie analizate cât mai curând posibil.

D: Deci astăzi, împărtășiți cinci moduri în care SEO ar trebui să folosească fișierele jurnal. Începând cu numărul unu, să vedem cum arată Google site-ul dvs.

1. Vedeți cum arată Google pe site-ul dvs

G: Da, Google este destul de imprevizibil, aproape ca un copil nestăpânit. Este ciudat pentru că, deși spun că putem să ne uităm pe site-uri și că putem folosi instrumente de crawling pentru a vedea cum ar trebui să privească Google pe site, suntem adesea surprinși să aflăm că Google a fost obsedat de un set de pagini sau de a merge pe un traseu ciudat undeva. Sau mai recent, am lucrat în ultimul an cu un supermarket numit Odor, iar unul dintre lucrurile pe care le-am găsit a fost că robotul Google s-a uitat foarte mult la configurația de analiză și a creat legături artificiale din ea. Google găsește linkuri rupte. Și pentru o lungă perioadă de timp, am încercat să-mi dau seama de ce găsea zeci de 1000 de 404 care nu erau deloc pe pagină. Dar se pare că s-a uitat la configurația de analiză și a creat un link din aceasta. Deci ne uităm la cât de mult impact a avut. Și dacă ne uităm la faptul că Google găsește toate aceste 404, aceasta ar putea să nu fie o problemă masivă. Dar acum vrem să știm cât timp petrece pe acele 404 și dacă remediam această problemă minusculă, va însemna că accesarea cu crawlere a restului site-ului va crește cu 20-30%? Care este oportunitatea dacă o reparăm acolo? Totul este să se uite de ce Google se uită la site-ul așa și ce găsește pe care cu adevărat nu ar trebui să găsească.

2. Parametri

Un alt lucru la care ne uităm adesea sunt parametrii. Nu știu dacă știți, dar oamenii de SEO trebuie întotdeauna să trimită către versiunea canonică a paginii. Ceea ce vreau să spun este că există adesea mai multe versiuni ale unei pagini care au uneori un fel de urmărire internă sau de urmărire externă. Există atât de multe moduri prin care ne putem conecta la o pagină și adesea un produs, de exemplu, poate fi așezat în mai multe locuri pe un site. Un bun exemplu în acest sens este că am lucrat pe un site, care a fost Magento. Și fiecare produs părea să se încadreze în fiecare categorie, așa că a fost uimitor când am aflat că există aproximativ 20 de versiuni ale fiecărui produs și că fiecare produs poate fi accesat cu crawlere. Deci, de acolo, am știut că și Google petrecea o cantitate imensă de timp accesând cu crawlere site-ul. Și ceea ce este interesant este că, dacă eliminați un produs, Google va spune „Oh, dar am alte 19 versiuni ale acestui produs”, așa că va dura ceva timp până când pagina reală aproape să dispară dacă ați folosit un 404 sau ceva de genul ăsta din cauza modului în care funcționează Google. Google va vedea că aceasta este o versiune canonică a acestei pagini. Dar dacă eliminați versiunea canonică, atunci va începe să folosească altele diferite. Și acesta este genul de informații pe care ni le oferă fișierul jurnal. Capacitatea noastră de a privi site-ul așa cum este Google.

Și, de asemenea, ne permite să privim lucruri precum codurile de stare. Un exemplu excelent în acest sens este că există un cod de stare care spune că nu am fost modificat. Și pentru viața mea acum, nu mă pot gândi ce este, ar fi trebuit să notez asta înainte de acest podcast. Dar, practic, „Nu am fost modificat” îmbunătățește masiv rata de accesare cu crawlere a unui site web. Și când aflu că acesta era ceva pe care Google îl respecta, ceea ce pot face a fost cu toate imaginile, cu toate produsele. , și toate aceste fragmente care nu sunt modificate foarte regulat, dacă putem folosi un nemodificat și putem îmbunătăți viteza cu care se accesează cu crawlere Google, îmbunătățim eficiența și reducem sarcina pe server, putem apoi îmbunătățiți semnificativ modul în care Google găsește toate produsele diferite.

Modul în care Google se uită la lucruri, dorim noi, doresc administratorii de server și toată lumea vrea, este ca serverul să fie cât mai rapid și cât mai eficient posibil. Din nou, revenind la partea fișierelor de jurnal, în zilele noastre, nu am putut folosi fișierele de jurnal în mod eficient, timp de mulți ani. Deoarece cu CDN-urile, ai descoperi adesea că ar exista mai multe locuri în care ar fi accesată o pagină. Și CDN-ul de multe ori nu avea un fișier jurnal în sine. Așa că ne vom uita la toate aceste locuri diferite și vom vedea câtă sarcină este pe acest server și câtă încărcare este pe acel server. Și încercăm să punem totul împreună și fișierele jurnal vor fi într-un format diferit. Acum, cu CDN-urile, putem începe efectiv să înțelegem eficiența unui CDN. Dintr-o dată, lucruri precum PageSpeed ​​sunt afectate și îmbunătățite masiv de faptul că, dacă folosim fișiere jurnal, putem începe să înțelegem faptul că imaginea, de exemplu, prin canonizarea imaginilor, deci dacă există o singură imagine utilizată pe mai multe pagini, ca atâta timp cât adresele URL sunt consistente, CDN-ul funcționează, iar Google îl accesează cu crawlere mai bine. Da, există atât de multe moduri diferite în care fișierele jurnal ajută la îmbunătățirea Vitezei paginii, a stocării în cache și a servirii utilizatorilor și motoarele de căutare mult mai eficient.

D: Vă trec în revistă cinci puncte pe care urma să le împărtășiți. Și există diferite elemente ale acestora pe care le-ați împărtășit deja. Îmi amintești de cineva căruia îi pot adresa doar o singură întrebare și îmi oferă un episod de podcast de 15 minute fără a mai pune întrebări. Deci există o persoană care poate face asta, chiar mai mult decât tine. Și probabil că este Duane Forrester. Eu și Duane am glumit că a făcut asta, eu i-am pus o întrebare și eu am plecat și l-am lăsat să distribuie conținutul pentru restul episodului. Dar ai vorbit puțin despre parametri. Nu știu dacă ați atins punctul numărul trei, care este descoperirea dacă există subdomenii care consumă bugetul de accesare cu crawlere, așa cum nu ar trebui să existe.

3. Există subdomenii care vă consumă bugetul de accesare cu crawlere?

G: De fapt, asta se întoarce la Just Eat. La un moment dat, am descoperit că site-ul web a fost replicat pe mai multe subdomenii diferite și toate acestea au putut fi accesate cu crawlere. Acum, în mod interesant, acestea nu aveau vizibilitate conform instrumentelor precum Citrix. Și motivul pentru care nu au făcut-o a fost pentru că totul a fost canonizat. Așadar, când am aflat că, deși aceste duplicate existau, Google cheltuia ceva mai puțin 60 până la 70% din buget pentru accesarea cu crawlere a acestor subdomenii. Și din cauza modului în care acestea nu au fost stocate în cache în același mod din cauza CDN-urilor și a altor tehnologii, acest lucru a creat de fapt o mulțime de încărcări de server. Deci a fost ceva care a fost fascinant pentru noi, pentru că pur și simplu ignoram asta ca o problemă care trebuie rezolvată cândva în viitor. Pentru că știam de problemă. Știam că există un fel de problemă și am vorbit despre asta. Dar i-am deprioritizat până când am început să ne uităm la fișierele jurnal.

Am văzut că Google cheltuiește multă energie, timp și resurse aici. Câtă sarcină de server creează? Cât de mult impact a fost? Și nu am putut înțelege cât de mare a fost încărcarea unui server din cauza modului în care serverul nu a fost capabil să interpreteze diferitele surse. Deci, a fost fascinant că, atunci când am primit fișierele jurnal, am putut îmbunătăți fiabilitatea site-ului web cu o sumă considerabilă. Deci știam despre subdomenii, pur și simplu nu știam cât de mare era o problemă până când am început să căutăm fișierele jurnal. Și apoi, brusc, am văzut că acest lucru trebuie remediat cât mai curând posibil. A fost unul dintre acele lucruri pe care am știut cum să-l reparăm, a fost doar prioritizarea. Era în partea de jos a cozii și a ajuns la numărul doi.

4. Fișiere JavaScript și CSS

D: Ați atins canonizarea, dar ați mai spus că, în special, fișierele JavaScript și CSS pot fi o problemă. De ce este asta?

G: Unul dintre lucrurile pe care le facem adesea este că spargem memoria cache adăugând un parametru la fișierul CSS. Motivul pentru care facem acest lucru este ceea ce se întâmplă dacă utilizați un CDN sau ceva similar, este că de fiecare dată când actualizați CSS, creați pagini noi sau ceva, atunci problema este că aveți un fișier CSS care este stocat în cache și paginile noi nu o vor putea folosi. Și avem timpi lungi de cache pentru toate aceste fișiere JavaScript și CSS diferite. Deci, în cadrul paginii, de îndată ce adăugăm ceva care necesită actualizarea JavaScript sau CSS, trebuie doar să modificați ușor parametrul din ea. De acolo, ceea ce trebuia să ne asigurăm a fost că toate serverele diferite foloseau aceeași versiune a parametrilor de acum înainte. Și asta a fost ceva în care, dacă lucrați în mai multe echipe diferite, mai multe site-uri web diferite, un JavaScript mai bun care alimentează întregul lucru, ne-am asigurat întotdeauna că este versiunea potrivită. Și fișierele de jurnal a fost o modalitate prin care ne-am asigurat că toate paginile diferite atingeau în mod constant versiunea JavaScript corectă, deoarece poate a trebuit să actualizăm o cheie API sau ceva similar. Au fost atât de multe moduri diferite în care a trebuit să o facem. Și acesta a fost ceva care a fost o sarcină masivă pentru dezvoltatori.

Unul dintre lucrurile pe care ne-am uitat în fișierele de jurnal a fost: a fost lovit cel vechi, de unde a fost lovit și am putea să-l reparăm? De asemenea, am descoperit că există multe moduri diferite în care puteți scrie calea către fișierul JavaScript. De exemplu, a fost într-un subdomeniu în care am folosit un nume de gazdă diferit, deoarece, interesant, dacă lucrați pe mai multe site-uri web diferite, de multe ori descoperiți că există adrese URL diferite sau nume de domenii diferite care accesează de fapt același server. Și adesea, dacă utilizați un CDN sau folosiți un subdirector, uneori poate fi foarte inconsecvent. Și din punctul de vedere al utilizatorului, dacă accesați același fișier JavaScript în șase sau șapte moduri diferite într-o călătorie, atunci îl încărcați în șase sau șapte moduri diferite. Și, deși s-ar putea să nu pară mult, cumulativ, asta adaugă câțiva megaocteți călătoriei tale. Și asta, desigur, încetinește întreaga experiență și face serverele mai puțin eficiente. Și mai e mult mai mult. Așadar, asigurați-vă că versiunea corectă a JavaScript, CSS și alte biți și piese sunt întotdeauna lovite. Și, de asemenea, asigurați-vă că nu există niciun motiv pentru ca JavaScript să fie ascuns cu parametri sau ceva. Există atât de multe moduri în care pot fi create capcane de păianjen, care includ fișierele JavaScript, unde, de exemplu, ceva este etichetat în ele, unde poate nu folosesc referința absolută corectă la JavaScript. Deci se află într-un director diferit de alte ori. Este surprinzător toate modurile diferite în care puteți observa când JavaScript este încărcat ușor diferit de mai multe pagini diferite. Deci da, este unul foarte simplu. Dar este surprinzător de scump când vine vorba de analiză.

5. Coduri de răspuns

D: De asemenea, asigurându-vă că codurile de răspuns sunt livrate în modul pe care l-ați dori. Un exemplu în acest sens este prin faptul că TOS este uneori văzut sau nu de Google, ceea ce ar trebui sau nu ar trebui să fie. Deci de ce s-ar întâmpla asta?

G: Din nou, vizităm întotdeauna pagini web folosind același browser, aceeași tehnologie, aceeași experiență și totul. Încerc să mă asigur că folosesc alte instrumente decât cele pe care le folosesc de obicei, deoarece toată lumea face un audit Screaming Frog, așa că încerc să folosesc tot felul de bucăți. Dar ne prefacem mereu că suntem un fel ca un computer. Așa că nu ne prefacem niciodată că suntem Googlebot, nu ne prefacem niciodată că suntem toate aceste lucruri diferite. Deci, dacă te uiți la modul în care roboții Google accesează un anumit fișier de la o altă adresă IP... o mulțime de tehnologie precum CloudFlare, dacă te prefaci că ești Googlebot și încerci să-l accesezi folosind Screaming Frog, știe că ești nu Googlebot, tu ești de fapt asta. Prin urmare, te tratează diferit de modul în care ai trata Googlebot. Și atât de des, serverele sunt configurate pentru a pre-renda lucrurile pentru a face toate părțile. Și este doar să ne asigurăm că toată lumea primește codul de răspuns corect de la server în acel moment.

Și pare destul de simplu, dar când creșteți la nivel internațional... Când aveți redirecționări geografice, dacă un utilizator sau un motor de căutare nu poate accesa o anumită pagină, deoarece cineva a introdus o redirecționare geografică pentru a spune că dacă vizitați aceasta site-ul web din Spania, apoi mergeți și încărcați acest subdirector... Prin urmare, nu se poate uita la versiunile root sau versiunile alternative. De aceea, lucruri precum codurile de răspuns corecte sunt absolut critice. Și este surprinzător cât de des treci prin aceste lucruri și presupui că totul este corect configurat. Pentru că, din nou și din nou, știm cum ar trebui să fie configurat. Dăm asta cuiva, cineva îl interpretează, o altă persoană îl implementează și altcineva trece prin asta. Și apoi altcineva dă clic pe un buton de pe CDN, care spune: „Oh, putem geolocaliza pe cineva în acest loc anume.” Nu este atât de mult faptul că o persoană a făcut ceva greșit este atât de mult încât există ceva în lanț care a rupt-o ușor.

Murătura Pareto - Fructul cu agățat jos

D: Să încheiem cu Murătura Pareto. Pareto spune că poți obține 80% din rezultate din 20% din eforturile tale. Care este o activitate SEO pe care ați recomanda-o și care oferă rezultate incredibile pentru niveluri modeste de efort?

G: Lucrul meu preferat în acest moment este că am un tablou de bord Google Data Studio foarte simplu, care îmi permite să arunc o privire la ceea ce eu numesc fructul care se agăță jos. Acum, toată lumea urăște bingo cu cuvinte la modă. Dar acesta este treaba mea în care mă uit la lucruri care nu sunt chiar atât de bine pe cât ar trebui. Mă uit la toate cuvintele cheie în care sunt clasate pentru un anumit set de pagini, sau rețete, sau produse sau ceva de genul. Un exemplu bun este, în acest moment, lucrez pe zeci de 1000 de produse, mă uit la toate paginile care au avut impresii mari, dar pot fi în poziția șase și le pot lucra până la poziția 3. Și de nouă ori din zece puteți face acest lucru doar asigurându-vă că etichetele de titlu s-au îmbunătățit și că legătura internă s-a îmbunătățit. Lucruri foarte simple pentru a afla care dintre cuvintele cheie cu volum mare de căutare poate fi crescut doar puțin mai mult pentru a crește rata de clic.

D: Am fost gazda ta, David Bain. Îl puteți găsi pe Gerry căutându-l pe Gerry White pe LinkedIn. Gerry, mulțumesc foarte mult pentru că ai participat la podcastul SEO în căutare.

G: Plăcerea mea. Multumesc pentru timpul acordat.

D: Și ​​mulțumesc pentru ascultare. Consultați toate episoadele anterioare și înscrieți-vă pentru o probă gratuită a platformei Rank Ranger.