Brug af serverlogfiler til afdækning af SEO-problemer

Nogle gange har hjemmesider søgemaskineoptimeringsproblemer, som Google Search Console, Google Analytics og SEO-værktøjerne uden hylde ikke kan finde. Når dette sker, er jeg ofte afhængig af en old school-metode: webserver logs.

Hvad er webserverlogfiler?

Du må antage, at Google Analytics eller lignende analytiske platforme registrerer hvert besøg på dit websted. Analytics-platforme registrerer dog ikke de fleste robotbesøg, herunder søgemaskinebots.

Webserverlogs registrerer dog hvert besøg på dit websted, uanset om det er fra mennesker eller robotter. Tænk på webserver logfiler som automatiserede tidsskrifter af al aktiviteten på dit websted. De omfatter typisk den besøgendes oprindelige IP-adresse, browser-brugeragenterne, de ønskede sider og den side, hvor den besøgende kom fra.

Den største udfordring med serverlogfiler er, at oplysningerne er i et råformat. Du skal tage ekstra skridt for at analysere dataene.

For eksempel, her er hvad et Apache kombineret logformat ser ud.

66.249.64.34 - frank [05 / Apr / 2017: 13: 55: 36-0700] "GET / produkt-123 HTTP / 1.1" 200 2326 "http://www.webstore.com/home.html" "Mozilla / 5.0 kompatibel; Googlebot / 2.1; + http: //www.google.com/bot.html) "

Jeg har understreget de vigtigste dele af loggen: IP-adressen til den besøgende, besøgstidspunktet, den besøgte side, den refererende side og den besøgende eller bot. Du kan bruge IP-adressen til Bekræft Googlebot-besøg.

3-eksempler på brug af serverlogfiler

Her er tre nylige eksempler, hvor jeg brugte webserverlogfiler til at komme til roden for SEO-problemer.

Det første eksempel kommer fra mit arbejde med et multinationalt selskab. Google Search Console> Gennemgå> Sitemaps rapporterede mere end 100,000 sider i XML-sitemapsne, men Google indekserede mindre end 20,000 af dem. Imidlertid, Søgekonsol> Google Indeks> Indeksstatus rapporteret mere end 70,000 sider indekseret.

Hvordan er det muligt?

Google kan indeksere mange dubletter eller forældede sider og savne de "rigtige" sider på et websted. Den svære del er at bestemme, hvilke dublette sider der er indekseret, og hvilke rigtige sider der ikke er.

Desværre giver Google Search Console ikke en liste over indekserede webadresser eller fortæller hvilke sider fra dine XML-sitemaps ikke indekseret. For at løse problemet havde vi brug for svaret på begge disse spørgsmål.

I dette tilfælde modtog jeg serverlogfiler, der dækker slutningen af ​​januar til begyndelsen af ​​marts. Efter at have analyseret dem lærte vi, at mindre end 9 procent af siderne i XML-sitemapet var gennemgået af Google i den periode.

I denne klients tilfælde blev 91.6% af sitemap-webadresser ikke gennemsøgt.

I denne klients tilfælde blev 91.6 procent af sitemap-webadresser ikke gennemsøgt.

Da vi kiggede tæt på de sider, der ikke blev gennemsøgt, fandt vi, at de fleste af dem havde nøjagtig det samme indhold og skabelonen. Den eneste forskel var navnet på produktet. Det viste sig, at Googlebot havde ikke gennemsøgte dem på grund af siderne med ens indhold. Udover dette bekræftede vi, at Googlebot spildte tid på botfælder.

Jeg har tidligere adresseret botfælder eller uendelige gennemgange. De vises ofte på websteder med omfattende databaser - som de fleste e-handelsplatforme - og forårsager, at søgemaskinerobotter fortsætter med at hente sider i en endeløs sløjfe. Et eksempel på dette er facetteret eller guidet navigation, som kan producere et næsten grænseløst antal muligheder. Uendelige crawlrum spilder Googlebot's gennemgå budgettet, og kunne forhindre indeksering af vigtige sider.

Løsningen i dette tilfælde var en smertefuld proces med at skrive unikt indhold for hver side, begyndende med de bedst sælgende produkter. (Måling af investeringen i unikt indhold kan hjælpe med at afgøre, om det giver mening at gøre dette.)

Det andet eksempel kommer fra et stort websted i bilindustrien. Vi har flyttet webstedet til HTTPS og konfronteret mange genindeksforsinkelser, der har skadet webstedets organiske søgeplaceringer.

Denne sag var særlig udfordrende, fordi vi mistænkte for, at webstedet havde alvorlige botfælder, men vi skulle behandle terabyte logdata fra flere webservere, klassificere sider efter sidetype og efterligne funktionaliteten af Søgekonsol> Gennemgå> URL-parametre at forstå problemet.

Opdelingen efter sidetype tillod os at indsnævre botfældeproblemet til URL-gruppen "Årsmodel-kategori". Derefter ønskede vi at se, om et usædvanligt antal sider gennemsøgt - på grund af webadresseparametrene - kunne føre os til botfælden.

Vores loganalyse hjalp os med at identificere problemet. Vi fandt tre nye webadresseparametre, der ikke blev vist i Søgekonsol> Gennemgå> URL-parametre liste, men de fik flere besøg end forventet. (Kategorisering af webadresseparametre hjælper Google med at undgå at gennemgå dobbelt webadresser.) Faktum de ikke var angivet i Søgekonsol> Gennemgå> URL-parametre forhindret os i at løse problemet. Jeg antog, at Google ville opregne alle parametre, vi skulle være bekymrede for, men det var forkert. Vi havde tæt på 100-problemwebadresseparametre.

Emnet for URL-parametre kan være forvirrende. Webadresseparametre indstilles dynamisk på en webs URL, og kan drevet af dens skabelon og dens datakilder. Webadresseparametre er lavet af en nøgle og en værdi adskilt af et lige-tegn (=) og sammenføjet med en ampersand (&). Den første parameter kommer altid efter et spørgsmålstegn i en webadresse.

Næsten hver e-handelsplatform har dynamiske sider, der automatisk genereres ud fra databaseindhold. Disse dynamiske sider bruger ofte webadresseparametre til at hjælpe e-handelsprogrammet til at give det rigtige indhold. Et eksempel på dette er paginerede kategorisider, som følger.

  • http://www.webstore.com/shoes
  • http://www.webstore.com/shoes?page=2
  • http://www.webstore.com/shoes?page=3
  • http://www.webstore.com/shoes?page=4

I dette tilfælde er "side" en URL-parameter. Google anser det for en aktiv parameter, fordi den ændrer eller påvirker sideindholdet. I Google Search Console ville vi oprette parameteren i Gennemgå> URL-parametre. Dette vil instruere Google om at gennemgå hver side, så den kan hente kanoniske tags og pagineringskoder.

Indstilling af "side" -parameteren i Search Console> Crawl> URL-parametre.

Opsætning af parameteren "side" i Søgekonsol> Gennemgå> URL-parametre. Klik på billedet for at forstørre.

Et andet eksempel er en parameter, vi tilføjer til siderne til sporingsformål, for at vide, hvilke marketingkampagner der udfører bedre.

  • http://www.webstore.com/shoes?utm_source=Google
  • http://www.webstore.com/shoes?utm_source=Bing
  • http://www.webstore.com/shoes?utm_source=Facebook

I dette tilfælde er parameteren "utm_source", som er en standard Google Analytics tracking parameter. Det påvirker ikke sidens indhold. Google anser dette for en passiv parameter.

parameter2

Opsætning af "utm_source" i Søgekonsol> Gennemgå> UTM Parametre. Google anser dette for en passiv parameter. Klik på billedet for at forstørre.

Det sidste eksempel involverer en populær webudgiver. Vores udfordring var, at vi vidste, at der var dobbelt sider på webstedet, men da vi kørte ScreamingFrog, et edderkoppeværktøj, kunne vi ikke finde dem, fordi de ikke var forbundet internt. Men da vi søgte på Google, kunne vi se nogle få i søgeresultaterne - bekræftede, at de blev indekseret. Gætte webadresser, der skal kontrolleres, er ikke særligt skalerbare. Web logs til undsætning!

Vi downloadede logdata fra slutningen af ​​februar til slutningen af ​​marts og fokuserede på at få svaret på spørgsmålet: Hvilke webadresser har Googlebot gennemsøgt, der ikke er inkluderet i XML-sitemap?

Når du foretager denne type analyse, kan du forvente at se lister over artikler i en kategori og sider med overflødige webadresseparametre, fordi webstedet er en blog, da de ikke er inkluderet i XML-sitemaps. Jeg anbefaler generelt at indeholde listesider - f.eks. Oversigter over artikler i en kategori - i separate XML-sitemaps (selvom du tildeler kanoniske tags til dem), fordi det hjælper med at bekræfte, om de bliver indekseret.

Ved hjælp af serverlogfiler blev vi overrasket over at finde en række ubrugelige sider med de samme sidetitler som andre legitime sider på webstedet, men ikke noget unikt indhold. Vi vidste ikke, at disse sider eksisterede, men Googlebot kunne finde dem og indekserer desværre mange af dem. Således kræver hjemmesiden nogle alvorlige oprydningsarbejder for at fjerne de ubrugelige sider.

Som en side kan Googlebot finde websider, som edderkoppeværktøjer, som f.eks. ScreamingFrog, ikke kan - af følgende grunde.

  • Google bruger links fra ethvert websted på internettet, ikke kun interne links.
  • WordPress-websteder og de fleste blogplatforme, ping søgemaskiner når nyt indhold oprettes
  • Google har en lang hukommelse. Hvis siden blev gennemgået tidligere, kunne Google genbruge den i fremtiden
  • Google bekræfter ikke dette, men det kan opdage nye sider fra Chrome eller Google Analytics-logfiler.

Transformering af rå logdata

Vi skriver kode for alle kundens loganalyser. Her er en forenklet to-trins proces for at komme i gang.

Først konvertere log data til et struktureret dataformat, som f.eks. CSV, ved hjælp af et regulært udtryk - en "regex." Her er et regulært udtryk, der virker i PHP.

^ (S +) S + S + [([^]] +]] "[AZ] + s ([^ s] +) [^"] + "d + d +" [^ "] * ) "$

Regelmæssige udtryk kan være komplicerede, især hvis du ikke er en webudvikler. I en nøddeskal er regulære udtryk søgemønstre. Du kan være bekendt med jokertegn. Et eksempel bruger udtrykket * .docx i din kommandolinje til at liste alle Microsoft Word-dokumenter i en mappe. Regelmæssige udtryk tillade lignende, men mere sofistikerede søgninger.

Brug Regelmæssige udtryk 101 at validere og forstå, hvordan regex ovenfor fungerer. Indtast det regulære udtryk ovenfor i værktøjet. Du skal også indtaste en teststreng. I dette eksempel bruger jeg Apache-logeksemplet, der blev understreget tidligere i artiklen.

Ved hjælp af RegEx 101 kan vi indsætte serverlogbogsposten, der tidligere blev refereret i artiklen som en "teststreng" og anvende ovenstående regulære udtryk. Resultatet er vores udvindte data. <em> Klik på billedet for at forstørre. </ em>

Ved hjælp af RegEx 101 kan vi indsætte serverlogbogsposten, der tidligere blev refereret i artiklen som en "teststreng" og anvende ovenstående regulære udtryk. Resultatet er vores udvindte data. Klik på billedet for at forstørre.

I dette tilfælde bruger værktøjet regex-søgemønstret på logbogsposten over referencens server til at udtrække Googlebot IP, datoen for besøget, den besøgte side og browserenbrugeragenten (i dette tilfælde Googlebot).

Hvis du ruller ned i afsnittet "Kampoplysninger" til højre, kan du se den uddragne information. Dette regulære udtryk fungerer specifikt med Apache kombineret logformat. Hvis din webserver er Microsoft IIS eller Nginx, vil denne regex ikke fungere som eksempler.

Det næste skridt er at skrive et simpelt PHP-script til at læse logfilerne, en linje ad gangen og udføre denne regex for at søge og indsamle de datapunkter, du har brug for. Så skriver du dem til en CSV-fil. Du kan finde et eksempelfrit script, der gør dette her. Koden er seks år gammel, men som jeg har sagt, er webserver logs old school.

Når du har logfilerne i CSV-format, skal du bruge et business intelligence-værktøj - som henter og analyserer data - for at læse filen og få svar på dine spørgsmål. Jeg bruger Tableau, som er dyrt. Men der er mange andre muligheder, der starter med et gratis niveau, som f.eks Microsoft Power BI.

Kilde

Giv en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.