Uanset hvad andre måtte sige, så har størrelsen en stor betydning. Sådan er det i hvert fald når det kommer til websites. Her er det nemlig langt fra ligegyldigt, om et site har et par enkelte URL-adresser, eller det har mange tusinde eller endda millioner. Store websites skal derfor også håndteres på en anden måde, end små skal.
Indholdsfortegnelse
Spillereglerne er anderledes for store websites
Hvad der kan virke som banale fejl for et mindre website, kan fuldstændigt ødelægge indeksering af et stort website. Der er markante forskelle på hvordan man udfører SEO på et stort website kontra et lille og årsagerne af mange, læs med her og blive klogere på emnet.
Videointroduktion til emnet
Definition af store websites i forhold til denne artikel
Lad os først starte med definitionen et stort website. Store websites er websites bestående af minimum 500.000 URL-adresser og i rigtig mange tilfælde op imod millioner af URL-adresser.
Derfor er store websites en udfordring ift. SEO
Websites i stor skala giver udfordringer for både webmastere og SEO-udøvere, grundet en række forskellige elementer:
Den skala et stort website repræsenterer betyder, at eksistensen af fundamentale tekniske fejl kan multipliceres af mange gange, og øge det totale antal udfordringer en søgemaskinecrawler vil opdage.
Disse udfordringer kan og vil over tid give mange udfordringer med den kvalitative vurdering af websitet som helhed, fra et Googlemæssigt perspektiv.
For det andet kan enorme websites byde på udfordringer for søgemaskinecrawlere, når de skal forstå side arkitekturen og beslutte sig for hvilke sider der skal crawles og hvor langt tid de ønsker at bruge på at crawlel websitet.
Crawl budget
Et websites crawlbudget bliver defineret ud fra to elementer, crawl rate og crawl demand. Crawl rate grænsen definerer hvor hurtigt og hvor ofte et website må crawles, denne frekvens er defineret ud fra et forsigtighedsprincip, der hedder at crawlet ikke må skade din server.
Crawl demand er derimod en sats, der definerer hvor meget Google ønsker at crawle af dit website. Denne sats er defineret ud fra populariteten af dine sider (indgående links) og hvor godt de sider der er indekseret, klarer sig i deres søgeresultater.
Crawlbudgettet er altså en kombination af disse to elementer tilsammen. Det betyder også, at for at det bliver muligt, at få indekseret et meget stort website, så skal det have mange indgående links (popularitet) og ellers vil det være svært, hvis ikke umuligt, at få det hele indekseret.
Googlebot har kun et vist crawlbudget til rådighed – når dette er brugt op, stopper Google sit crawl, uanset om Googlebot er færdig eller ej.
Der er ikke plads til alt i det synlige indeks
Selvom dit website bliver indekseret, betyder det ikke nødvendigvis at man vil kunne finde dit website i søgemaskineindekset, når der indtastes forskellige søgeord. Du vil dog altid kunne finde din side, hvis du tager en længere paragraf fra din side og søger på denne. Hvis du ikke kan finde din side ved at gøre dette, kan du være sikker på, at siden ikke er indekseret.
Der er kamp om pladserne i søgemaskinerne og ligger du ikke på første side på en given søgning, skal du ikke forvente at få nogen besøg. Det er helt normalt at en placering som nr. 14 ikke giver nogen besøg overhovedet!
Supplemental index
Google bruger desuden noget, der hedder supplemental indeks eller supplerende indeks om man vil. Her lægges alle de sider de har indekseret, som de ikke mener har den rette kvalitet til at nå ind i det rigtige søgeindeks.
Har du sider med meget lidt originalt indhold eller sider stort set uden noget indhold, men måske blot en video, er der en stor chance for, at dette ender i det supplerende indeks.
Det er ikke anbefalelsesværdigt at ligge i det supplerende indeks, det bevidner nemlig at Google ikke bryder sig om det indhold du har, og at kvaliteten er for lav. Har du sider der er af så dårlig karakter, at det lander i supplemental index, bør du sørge for at udelukke disse sider fra indekset, det andet kan skade dit website!
Det kan gøres aktivt med noindex eller brugen af eksempelvis robots.txt.
Du kan se om dit indhold er i det supplerende indeks ved at foretage en søgning som du ved du kan findes på, gå nu alle søgesiderne igennem. Hvis du finder din side inden du når til den sidste side, hvor Google viser dig en besked som den du kan se herunder, er du i det rigtige indeks:
Kan du først finde dit website, når du har sagt ja til at se flere resultater inklusive de udeladte, er den pågældende side i det supplerende indeks.
Udbredte fælder ved store websites
Hastighed og stabilitet
Dit website skal altid være tilgængeligt, også om natten – er du på en host, der ofte laver store opdateringer om natten der efterlader dit website utilgængeligt i timevis, er det om at få skiftet serverhosting med det samme. Googlebot kigger nemlig forbi hele døgnet rundt og sover ikke om natten, ligesom dine brugere måske gør.
Det samme kan gøre sig gældende, hvis der skæres på båndbredden om natten, dette er også et meget udbredt fænomen. Oplever du ofte at Googlebot eller din egen crawler får connection timeouts, connect failed, no response, connection reset, timeout mv. Skal du have kigget på din server og finde et ordentligt miljø i stedet.
Flere af ovenstående fejl kan dog også forekomme når websitet blot er for langsomt til at respondere på Googlebots forespørgsel, eksempelvis en no responce eller connect failed. Google har en tærskel for hvor lang tid de vil vente på at en given URL svarer – denne værdi er sandsynligvis dynamisk ift. det komplette crawlbudget.
Hvorimod vi med Javascript ved, at Googles præcise tærskel er lige præcis 5 sekunder og ikke et millisekund mere.
Det er dermed ufatteligt vigtigt, at ens website svarer meget hurtigt, hvis man skal gøre sig en forhåbning om at blive indekseret fuldt ud.
Fejlsider
Det er ikke for sjov, at os SEO-folk er så opmærksomme på mindre fejl på et website, i stor skala, kan de nemlig give alvorlige problemer og noget så simpelt som 4xx sider, kan blive et stort problem, når de skaleres.
Dette gælder både bløde og hårde 4xx-fejl. Bløde 4xx fejl opstår når sider på websitet ikke længere eksisterer, men ikke returnerer en 404 header statuskode. Det kan være at siden har lavet en automatisk 302 omdirigering til en anden URL-adresse, som melder status kode 200 OK, men som ikke er tilsvarende den side, der blev forespurgt på.
Du kan finde frem til bløde så vel som hårde 404 fejl i Googles Search Console, et absolut essentielt værktøj, til hvis man arbejder med store websites.
På et stort website, vil gentagne fejlsider stoppe crawling og kan dermed ødelægge indekseringen af vigtige elementer på ens website. Hvis Googlebot gang på gang støder på sider, der ikke responderer korrekt, vil de stoppe crawlet af den enkelte række af sider i crawlkøen og forsøge igen en anden gang. Bliver fejlsiderne ved med at være til stede, er der en stor chance for, at Google aldrig kommer forbi dem også selvom Googlebot ofte starter sine crawls fra forskellige indgangsvinkler.
Duplikeret indhold
En af de største syndere for indekseringsblokering på store websites er ikke overraskende duplikeret indhold. Duplikeret indhold kommer i mange forskellige størrelser, den mest udbredte og mest kendte form for duplikeret indhold er når et website kopierer tekst fra et andet website og poster det samme indhold på deres platform.
Men mindre elementer som duplikerede sidetitler og duplikerede meta-beskrivelser kan på store websites skabe mindst lige så mange udfordringer. Årsagen til dette er at Google først og fremmest scanner head på et dokument, inden de går i gang med at scanne resten af dokumentet. Opstår samme sidetitel og meta-beskrivelse om og om igen, kan Googlebot fejlagtigt gå ud fra, at der er tale om samme side og samme indhold også selvom dette ikke er tilfældet.
Ovenstående scenarie er dog heldigvis en af de nemmere at løse, der skal blot udarbejdes automatiske regler for skrivning af unikke sidetitler og meta-beskrivelser, for alle sider på websitet. Det hører dog til sjældenhederne at jeg kan konstatere at et website, har 100% styr på ovenstående.
Duplikeret indhold sætter Googlebot på prøve
Subdomæner og protokoller
Problemer med valg af et primært domæne, for eksempel brugen af både http og https og/eller non-www og www, kan give mange versioneringer af hver eneste side på et website.
Svarer URLs med forskellige subdomæner og protokoller, vil der blive skabt et utal af variationer af sider på websitet og får Googlebot først fat i en forkert URL og kan fortsætte ud af samme sti, så har man pludseligt en ekstra versionering indekseret af dele eller hele websitet.
Tager man ej heller forbehold for brugen af små og store bogstaver i URLs, og er det muligt at kalde en side ved ændring af et enkelt bogstav til kapital, så kan et utal af versioneringer også indekseres på denne bekostning. Et enkelt link, som eksempelvis eksempel.dk/Link kan altså skabe en ekstra versionering, hvis man ikke har sikret sine URLs.
Og hvor links kommer fra, der linker forkert er ligegyldigt, for Google følger de links de falder over, så det behøves ikke være internt på websitet, at linket er sat forkert, førend det kan indekseres af Googlebot og dermed skabe et duplikat.
Tyndt indhold
Sider der byder på meget lidt til slet ingen værdi, kaldes i fagsprog for tyndt indhold. Eksempler på dette kunne være en side med et billede og intet andet, som vi kender det fra mange CMSer der skaber indholdssider, til billeder, der kan indekseres – en funktion blandt andet WordPress benytter sig af, hvis man ikke får det slået fra eller påsat noindex på siderne, disse sider kaldes i WordPress for attachments URLs og der genereres en til flere for hvert eneste billede man har, alt efter opsætning.
Billeder må gerne indekseres, naturligvis, da vi gerne vil have disse indekseres, men det skal være selve billederne der indekseres, ikke sider, der indeholder billedet, en fuldstændig overflødig funktion, der skaber en side for hvert eneste billede for et website.
Man kan eksempelvis bruge Yoasts SEO Plugin, til at sætte et redirect på disse attachments. Hvis man tror at det ikke kan skabe problemer, at få disse indekseret, er det bare om at hoppe ud i Google og søge på ”Yoast Image attachments issue”.
Du vil finde ufatteligt mange artikler og tråde fra 2018, hvor Yoast igennem en opdatering, kom til at slå denne funktion fra – hvis du selv kører WordPress, er der en god chance for du kan huske episoden, den fik nemlig ikke bare lidt, men stor opmærksomhed, netop grundet dens voldsomme indvirken på mange websites.
Opdateringen gjorde at rigtigt mange store websites, mistede store dele af deres synlighed i de organiske resultater, mens meget mindre sider, var fuldstændigt upåvirket. Årsagen? De store sider fik tusindvis af nye sider indekseret, sider der blot var tyndt indhold, mens mindre sider, fik langt færre nye redundante sider indekseret.
Igen, var udfordringen altså mængderne og dermed den store ændring, der pludseligt slog ud under et crawl for Googlebot.
Yoast var hurtig til at udgive et ekstra plugin, der sørgede for at ordne problematikken – men udfordringerne var så alvorlige for nogle websites, at fikset ikke blot var en genetablering af noindex på disse sider, men påsættelse af en 410 gone status på alle disse sider, således at Googlebot, med det samme de recrawlede siderne, smed siden ud af deres indeks.
410: Page Deleted or Gone
Et andet eksempel kunne være en side, der blot viser en video, uden dertilhørende indhold som Google kan bruge til at matche siden mod en given forespørgsel.
Anderledes brug af blokeringer
Arbejder man på meget store websites, kan parametre blive et stort problem, grundet de mange kombinationsmuligheder – i nogle tilfælde kan et forsøg på at crawle en række parametre, fuldstændigt opsluge crawlbudgettet. Det kunne eksempelvis være ved kombination af farve, størrelse, materiale mv.
Ofte vil man blot bruge noindex eller canonical på denne type af sider, men på meget store websites, kan det ofte betale sig helt at blokere for crawling af siderne igennem robots.txt. Dette for at sikre at Googlebot ikke bruger unødvendige ressourcer på en del af et website, som alligevel ikke skal indekseres.
På et stort website, er det ikke unormalt at der kan genereres flere millioner variationer af URLs igennem en række parametre, det er utroligt mange sider for Googlebot at tage stilling til, særligt, når vi alligevel ikke ønsker dem i deres søgeresultater.
Har man decideret problemer med crawlbudget, som mange rigtigt store websites har, så kan brugen af robots.txt, til at begrænse mængden af sider, være et super effektivt værktøj.
Store websites kan give store problemer – og store muligheder
Sidder du med et stort website, er der altså en god sandsynlighed for at du sidder med nogle store problemer. Det er meget tænkeligt, at problemerne rent faktisk i sig selv er små, men på grund af sitets størrelse bliver de store. Det er ofte nemt, at finde de store problemer, det kræver ikke så meget erfaring.
Men at finde de små problemer der vokser sig større, det er straks en anden sag, og noget der kræver viden og mange års erfaring. En læge kan nemt finde og diagnosticere et åbent benbrud, men er det en lille knogle, der er brækket inde i benet, er sagen en anden, men begge dele kan gøre, at du ikke kan gå.
Jeg vil gerne hjælpe med at give dit website ben at gå på, ja faktisk vil jeg gerne have det til at sprinte. Så lad mig kigge på det, og se om de små problemer ikke kan udvikle sig til at blive nogle store muligheder.