Vil du lære om SEO? Så er det her du skal læse med! Konkrete og lavpraktiske råd omkring SEO, baseret på egen erfaring, læs med her og nå nye højder med dit website!
I Googles Search Console, er det muligt at se gennemsnitsplaceringer, for en given URL eller et søgeord. Nogle argumenterer for, at dette værktøj er det bedste du kan bruge til at holde øje med dine placeringer, mens andre argumenterer for det modsatte. Læs for og i mod i denne artikel.
Search Console er gennemsnitsplaceringer
Det er meget vigtigt at forstå, at de placeringer der vises for henholdsvis URLs eller søgeord i Search Console, er gennemsnitsplaceringer. Der er altså ikke tale om et direkte udtræk og vil således meget sjældent harmonere med den faktiske og nutidige placering.
Gennemsnitsplaceringen er baseret på alle registrerede positioner, for den periode, som datovælgeren er sat til. Har man derfor sat datovælgeren til 4 uger og har man haft en 10 placering i to uger og en 5 placering i en uge, vil Search Console vise gennemsnitsplaceringen 7.5.
Tjekker du derimod Googles søgeresultater, vil du finde at placeringen er på en femteplads.
Andre variabler der påvirker gennemsnitsplaceringen
Eftersom at Search Console er baseret på faktiske data, er der flere elementer, der spiller ind, når en given gennemsnitsplacering for et søgeord eller en URL udregnes. Disse elementer påvirker ikke andre almindelige placeringstjekkere, der søger at vise det neutrale resultat. Dette er hvad alle brugere, som udgangspunkt ser, første gang de søger efter et specifikt emne inden for en konkret niche.
Personliggjorte søgeresultater
Google personaliserer søgeresultater baseret på din historik, for at give dig resultater, der i større grad er tilpasset dig. I Search Console stammer data som sagt fra reelle besøgende og derfor er søgeordsplaceringerne stærkt påvirket af personaliseringer som Google giver de enkelte brugere.
En almindelig ranktracker ser på søgeresultaterne i en neutral tilstand, hvor placeringer ikke er påvirket af nogle af disse variabler. Det er det stikmodsatte når du bruger Search Console som placeringstjekker.
Placeringer i Search Console, er blandt andet påvirket af disse variabler:
Søgehistorik – Baseret på de søgninger brugeren foretager i Google.
Hjemmesidebesøg – Hvilke hjemmesider brugeren har besøgt igennem Googles søgeresultater eller igennem Googles Chrome browser.
Google konto – Er en bruger logget ind i Google mens de søger, er resultaterne stærkt påvirket af tidligere historik og interesse.
Hvor brugeren laver sin forespørgsel (lokale resultater, land, region, by)
Mobilplacering vs. Desktopplacering (Her kan være store forskelle)
Der er stor forskel på om du kigger på gennemsnitsplaceringen for et søgeord eller en URL, mere om dette neden for.
Gennemsnitsplacering for søgeord
Denne gennemsnitsplacering er baseret på et konkret søgeord eller søgefrase.
Overtager en ny side placeringen for et konkret søgeord, vil placeringen ofte påvirkes af dette, enten positivt eller negativt.
Problemet med at kigge på søgeord isoleret, er at det kan være, at du overser, at URLen skifter og at det nu måske, er en side, du slet ikke ønsker skal rangere, som Google har valgt, som den primære version for dit website.
Dette kan du nemt fikse, ved at implementere et canonical-tag. Det ændrer dog stadig ikke på, at du skal være opmærksom på skiftet, for at kunne håndtere det.
Det er langt om længe blevet muligt at se særskilt på mobile og desktop resultater og rankings i Search Console. Dette gør du ved at vælge enhed, under ”Performance”, vælg mobil for at isolere data udelukkende til mobile resultater eller omvendt, desktop eller tablet for den sags skyld.
En anden god filtrering at benytte, hvis man ønsker at bruge Search Console som placeringstjekker, at isolere data til det land, man opererer i. Har du et dansk website, bør du derfor vælge Danmark under lande, for at frafiltrere rankings fra udenlandske søgninger, som naturligvis har en markant lavere gennemsnitsplacering.
Viser kun 1000 resultater – Ubrugeligt for større websites
Uanset om du vælger forespørgsler eller sider er du begrænset af at Google Search Console kun viser dig 1000 resultater.
Dette kan være fint for mindre websites, men på større websites, går man glip af en masse data, da resultaterne er begrænset til de 1000 resultater – rangerer du på flere tusinde søgeord og søgefraser, har du dermed kun et stærkt begrænset indblik.
Gennemsnitsplacering for URLs
Det forholder sig helt anderledes, når vi kigger på gennemsnitsplacering for en URL og det bør selvfølgelig ikke komme som nogen overraskelse. For i modsætning til at kigge på et konkret søgeord, kigger vi her på en URL, der kan have mange søgeord og søgefraser.
En URL-ranking er derfor en gennemsnitsplacering, for den pågældende URLs, fordelt på alle de søgeord og søgefraser, som den pågældende URL rangerer på.
Dette er både Search Consoles store force, så vel som dets store mangel.
Hvad er en eksponering? Varierer alt efter om der ses på side- eller søgeordsniveau
Ifølge Google selv er en eksponering, når en URL dukker op i et søgeresultat for en bruger. Det betyder også, at har du et dobbelt resultat på en given søgning, vil der blive registreret to eksponeringer og ikke bare en enkelt, hvis der er tale om to forskellige URLs og man sorterer på sider og ikke søgeord.
Dette forekommer dog kun, når du kigger på sideniveau, her kan et resultat give mange eksponeringer, alt efter hvad der vises på resultatsiden. Eksempelvis knowledge graph kombineret med almindelige organiske resultater.
Ser du på rankings for et søgeord, tælles der kun en eksponering også selvom der dukker flere resultater frem fra samme side. Der er dermed en stor forskel på eksponeringer, alt efter om der trackers på søgeordsniveau eller sideniveau.
Samtidig opnås en eksponering blot resultatet vises på den side en bruger ser på, det er altså ikke en forudsætning af brugeren har fokus på resultatet eller scroller ned til det, så længe det er til stede på resultatsiden der vises, er der tale om en eksponering.
Googles placeringer kan både være mere retvisende og mindre retvisende
Bruger du et almindeligt keyword tracker tool, tjekker du som regel placeringen på et givent tidspunkt, hver dag, hver anden dag ugentligt eller hvad du nu har sat din tracker til.
Hvis man kender lidt til Googles søgeresultater, ved man hvor ofte de skifter og hvordan at placeringer den dag i dag er langt mere dynamiske end tidligere. Det betyder også at du i løbet af en dag, kan blive præsenteret på mange forskellige placeringer i løbet af et døgn, men du måler kun på eksempelvis 24 timers interval, der kan have været foregået meget med en placering i mellemtiden.
Spørgsmålet er bare, hvad man skal bruge denne viden til, for dynamikken kan du ikke gøre så meget ved.
Udfordringer ved Search Console
Viser gennemsnitsplaceringer der er påvirket af personaliseringer
Viser gennemsnitsplaceringer der er påvirket af lokation
Så kan du bruge Search Console som placeringstjekker? Ja, det kan du godt, hvis du driver et mindre website, men der er fordele og ulemper.
Optimalt set, gør du ligesom Jeg gør, og gør brug af både en direkte SERP-søgeordstracker, så vel som Search Console, altså en kombination af begge værktøjer.
Går du op I dit website og dets synlighed, har du med garanti bidt mærke I at Google har introduceret ”Largest Contentful Paint” forkortet LCP, som et af deres tre ”Core Web Vitals”. De tre core web vitals, bliver deciderede rankingfaktorer i 2021. Men hvad er LCP egentligt? Og hvordan kan du forbedre det?
Videointroduktion til emnet
Se videoen og få en hurtig opsummering eller spring videoen over og læs artiklen efter videoen.
Hvad er LCP?
LCP står som sagt for Largest Contentful Paint, på dansk ville man nok oversætte det til største indholdsmæssige udfyldning. Værdien måler brugertilfredshed, ligesom de to andre core web vitals måleværdier gør.
LCP er en måling af hvor lang tid det tager for det primære indhold af en side at downloade og blive klar til, at der kan interageres med det. Det der måles, er det største billede eller indholdsstykke inde i brugeres viewport (det som brugeren ser) og kun det som findes i viewporten. Andre elementer på siden tæller ikke med i denne måling.
Typisk vil der være tale om billeder, videoer, baggrundsbilleder eller store tekststykker i eksempelvis en paragraf.
Hvorfor måler Google på LCP?
LCP viser meget præcist, hvor hurtigt en hjemmeside kan bruges af en bruger. Herudover er det nemt og enkelt målepunkt, som er nemt at optimere imod.
Sektionselementer, overskrifter og formelementer kan alle være elementer, der bruges til at udregne LCP og det kunne faktisk i realiteten være et hvilket som helst HTML-element, der indeholder tekst. Så længe det er det største element.
Modsat mange andre målepunkter er LCP nem at forstå og handle på. Alt du skal gøre, er at se på dit website og lokalisere den største blok tekst eller billede og herefter optimere det, ved at gøre det mindre eller eliminere elementer der kunne forhindre det i at blive downloadet hurtigt.
Hvordan forbedrer man sin LCP?
Herunder finder du en række af de punkter, du kan forbedre, hvis du vil sænke din LCP.
Langsomme serversvar
Jo længere tid det tager browseren at modtage indhold fra serveren, desto længere tid tager det at rendere noget som helst på skærmen. Jo hurtigere serversvar desto lavere LCP. Det er med andre ord værdien TTFB (Time to first Byte) du skal kigge efter i de forskellige hastighedsmålingsværktøjer, som Google Pagespeed og Pingdom Tools. Jo lavere TTFB des bedre.
Elementer der kunne forbedre serverens svar, kunne udover at få en bedre og hurtigere server, være at servere HTML-siders cache som det første og prøve at etablere tredjepartsforbindelser tidligt i forløbet (Rel=Preconnect og DNS-Prefetch).
Gengivelsesblokerende Javascript og CSS
Før end at en browser kan rendere noget indhold, skal HTML-markup parses ind i et DOM-træ, parseren pauser hvis den møder eksterne stylesheets (CSS) eller synkroniserede JavaScript tags.
Både CSS og scripts er gengivelsesblokerende og de forsinker FCP og dermed også LCP. For at forbedre disse elementer, kan man udsætte ikke kritisk CSS og benytte sig af inline kritisk CSS (Kritisk CSS der bruges til at loade above the fold indhold, kan inkluderes i head), samt minificere CSS (Fjerne alle overflødige karakterer så som: mellemrum, kommentarer mv. disse er alle overflødige for en browser, men fylder). Generelt set handler det dog om at få minimeret mængden af blokerende CSS, nu mindre, nu hurtigere load.
Herudover kan du reducere brugen af CSS generelt set, langt de fleste temaer, kommer med en masse CSS der ikke benyttes. Du kan bruge dækningstabben i Google Chromes DevTools til at finde frem til ubenyttet CSS, som du kan fjerne fra dine temafiler.
Ift. Javascript kan du igen gøre brug af minimering og komprimering, forsinke ikke benytte javascript og minimere ubenyttede polyfills (moderne kode til moderne browsere).
Langsomme ressourcer
Udover CSS og Javascripts blokeringstid er der også andre mange andre former for ressourcer der kan påvirke LCP eksempelvis -elementer,
Alle disse elementer påvirker LCP, hvis de renderes above-the-fold. Derfor bør du arbejde på at optimere og komprimere billeder, komprimere tekstfiler, prøve på at preloade vigtige ressourcer og levere forskellige aktiver baseret på netværksforbindelse (Adaptive serving).
Herudover kan brugen af service workers forbedre LCP voldsomt.
Hvordan finder jeg frem til min LCP?
Selve resultaterne leverer Google til dig både i deres Search Console, hvor de løbende måler på denne værdi, sammen med de to andre Core Web Vitals, men du kan også få gradueringen igennem Google PageSpeed Insights.
For at finde oversigten i Search Console skal du blot logge ind på din konto, vælge dit websted og herefter navigere til ”Vigtige netstatistikker” under ”Forbedringer”.
Du får nu en oversigt over henholdsvis dårlige webadresser, gode webadresser og webadresser der skal forbedres.
Klik nu på åben rapport og kig under detaljer, hvor følgende oversigtsvindue kommer frem:
Herfra kan du klikke dig videre ind og trække en liste over sider, der skal forbedres.
Du kan også bruge Lighthouse, som er samme værktøj, som der benyttes i PageSpeed Insights.
Går du op i dit website og dets synlighed, har du med stor sandsynlighed bidt mærke i at Google har introduceret kumulativt layoutskifte forkortet CLS, som et af deres tre ”Core Web Vitals”. De tre core web vitals, bliver deciderede rankingfaktorer i januar 2021. Men hvad er CLS egentligt? Og hvordan kan du forbedre det?
Målet med at fokusere på disse nye elementer, er at skabe en bedre brugeroplevelse altså en forbedring af UX og det er både webmastere og SEOer, der skal bide mærke i disse nye elementer.
Videogennemgang af emnet
Hvad er Cumulative Layout Shift?
CLS måler et website layouts stabilitet for at sikre en god og flydende brugeroplevelse, særligt i forbindelse med interaktion af websitet. Ustabile layouts fører ofte til dårlige brugeroplevelser både på mobil og desktop og Google er ikke interesseret i at lede deres brugere ind på hjemmesider, med en dårlig brugeroplevelse. Google lever ligesom så mange andre virksomheder af at ”sælge” gode oplevelser.
Du kender helt sikkert til fænomenet – du sidder og kigger på et website, siden ser ud som om den er loadet færdig – du finder et element du gerne vil klikke på, men som du skal til at klikke, loader noget nyt på skærmen og elementet flytter sig og du kommer måske endda til at klikke på et andet element, en ikke særlig heldig eller positiv oplevelse. Det er præcis denne irriterende oplevelse, som Google vil slå hårdt ned på i fremtiden og med god grund.
Ved en brugermæssig interaktion, altså at brugere interagerer med et element, eksempelvis åbner en menu, har Google en threshold på 500 ms. De anerkender, at der gerne må være en animation eller andre mindre elementer, der kan skabe et visuelt skifte – men de skal være færdigloadet inden for 500 ms og ellers er det et reélt problem.
De fem elementer, der ofte er syndebukkene
Billeder uden dimensioner
Har man billeder, uden der er defineret en dimension, igennem eksempelvis et responsivt design, så kan det give udfordringer med at billedet først loader i sin fulde størrelse, for herefter at tilpasse sig og det skaber lige præcis den effekt, som Google ser hårdt på. Ren tilpasning igennem viewport, kan altså være en stor synder.
FOUT og FOIT (Webfonte)
Layoutskifte kan ske når der downloades fonte. Da der først benyttes en fallback font, loades denne først, vil der forekomme en FOUT (Flash Of Unstyled Text), når den nye font aktiveres efter download. En anden metode, er at benytte usynlig tekst, indtil den nye font vises, men det skaber så i stedet FOIT (Flash of Invisible Text) og ingen af løsningerne er dermed optimale.
Hvad er så den optimale løsning? Websafe fonte, som alle computere besidder. Rigtigt mange brugere har Googles fonte eller en stor del af dem, men du vil have brugere, der ikke har dem og som først skal downloade dem.
DIT (Dynamically injected content)
Elementer som kort fra Google maps, indlejrede social media post eller YouTube videoer er alle det man kalder for dynamisk injecteret indhold. Sådanne widgets, kan være uforudsigelige da indholdet ikke ved hvor stort outputtet nødvendigvist er, da indholdet kan variere. Det betyder, at webplatforme der tilbyder indlejringer, ikke nødvendigvis altid har reserveret nok plads på siden ved første load. Det kan så føre til et layoutskifte, når brugeren når det reelle element og det loades ind i sin fulde størrelse.
Annoncer
Mange annoncer skaber CLS, men hvis du styler elementerne hvor annoncen placeres, eksempelvis ved at style DIV til en specifik højde og bredde, vil annoncen være begrænset til disse. Gør man brug af restvisninger og er der nogle gange, ikke flere annoncer at vise, bør der påsættes et alternativt banner, der vises i stedet, så pladsen fyldes ud – et placeholderbillede kan også gøre tricket, men der skal altså være en fallback mulighed.
Hvordan udregnes CLS?
CLS udregnes igennem to forskellige målinger, den første hedder Impact Fraction. Impact Fraction er en måling af hvor meget plads ustabile elementer benytter af den pågældende viewport (Hvad du ser på skærmen).
Når et element downloades og herefter skifter, måles den plads elementet har benyttet og forskellen på den plads, som elementet rent faktisk benytter, når den er fuldt ud renderet og placeret på dens endelige destination.
Et eksempel på dette kunne være, at 20% af viewporten reserveres, men når elementet er færdigloadet, fylder det kun 10% af viewporten mod de 20% der rent faktisk blev reserveret til det.
Når disse kombineres, får man 30% (Hvad vi regnede med elementet ville fylde og hvad det rent faktisk kom til at fylde) og dette udtrykkes som en score i følgende format: 0.30.
For at regne os frem til CLS, skal vi dog kigge på næste element Distance Fraction, som er den mængde af plads som sideelementet har flyttet sig fra dens oprindelige position til dens endelige position.
Et eksempel på dette kunne være, at 20% af viewporten reserveres, men når elementet er færdigloadet, fylder det kun 10% af viewporten mod de 20% der rent faktisk blev reserveret til det.
Lad os sige at området der påvirkes, er sat til 330×490 mens viewport er sat til 375×667. For at regne Impact Fraction ud, dividerer vi nu det påvirkede område med viewporten.
Distance Fraction = distancen elementet bevæger sig / højden på viewport
Lad os sige at elementet hopper 150 pixels mens viewporten er sat til 680. Regnestykket bliver derfor således: 150/680 = 0.220 (Distance Fraction)
CLS udregnes herefter, ved at multiplicere disse to tal.
CLS = 0.646 * 0.220 = 0,14212
Hvad er en god CLS-score?
En CLS på under 0.1 betyder at en side er visuelt stabil, alt over 0.1 er altså en side der behøves forbedringer og alt over 0.25 betyder en direkte dårlig oplevelse. Du skal med andre ord sørge for at alle dine sider, kan loades med en CLS på under 0.25 og helt optimalt under 0.1.
Pas på din cache, når du skal evaluere CLS
Mange af de elementer der bruges til at rendere en side gemmes i browserens cache. Det betyder også, at har du besøgt dit website mange gange før, kan mange af disse allerede været loadet i din browser cache. Det betyder, at du ikke lægger mærke til CLS som førstegangsbrugere vil.
Sørg derfor for at tømme din webbrowsers cache, inden du begynder at evaluere på CLS manuelt.
Er det ikke lidt besværligt at regne sin CLS ud?
Jo og det er heller ikke noget du skal bruge tid på, ovennævnte udregninger er kun med, for at du forstår hvordan Google kommer frem til deres resultat.
Selve resultaterne leverer Google til dig både i deres Search Console, hvor de løbende måler på denne værdi, sammen med de to andre Core Web Vitals, men du kan også få gradueringen igennem Google PageSpeed Insights.
For at finde oversigten i Search Console skal du blot logge ind på din konto, vælge dit websted og herefter navigere til ”Vigtige netstatistikker” under ”Forbedringer”.
Du får nu en oversigt over henholdsvis dårlige webadresser, gode webadresser og webadresser der skal forbedres.
Klik nu på åben rapport og kig under detaljer, hvor følgende oversigtsvindue kommer frem:
Herfra kan du klikke dig videre ind og trække en liste over sider, der skal forbedres.
I ovenstående eksempel var der ingen udfordringer med CLS, men til gengæld var der udfordringer på mange webadresser, ift. en af de andre 2 Core Web Vitals, nemlig LCP (Largest Contentful Paint).
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.
Videointroduktion til emnet
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.
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.
Links har længe været fundamentet for gode placeringer i søgemaskiner, lige siden Googles begyndelse. Dette skyldes Googles fokusering på netop links, og muligheden for igennem disse at beregne en kvalitetsscore, der kunne bruges til at skabe et retvisende hierarki af Internettet i søgemaskiner.
Links forbinder hele Internettet og det giver perfekt mening, at de websites der gør det godt, har flest links pegende på sig.
Verden har dog ændret sig og alle der ved lidt om SEO, forstår den dag i dag vigtigheden af links og dermed også værdien af links. I takt med at forståelsen for værdien af links vinder frem, er det blevet markant sværere at opnå naturlige links til ens website.
Derfor er Google også nødt til konstant at være på forkant og tilpasse deres popularitetsalgoritmer, hvis de skal være retvisende for siders reelle popularitet.
Derfor er Google også nødt til i større stil at lytte mere til andre signaler som co-occurunce, co-citation og URL-mentions!
Hvad er linkløse mentions?
En mention er som navnet antyder en benævnelse. Inden for SEO bruger vi ordet mentions om alle de benævnelser et website får, hvor der ikke er et aktivt link til stede.
Det vil med andre ord sige, at websitets navn bliver nævnt, men uden at brugeren har et klikbart link til rådighed, der kan føre brugeren videre til det omtalte website.
Fænomenet kaldes også for implied links eller underforståede links, det ligger altså i kortene, at der lige så godt kunne have været tale om et link – men at det aktive link, ikke er til stede af den ene eller anden årsag.
Tæller mentions med i Googles popularitetsanalyser?
Ikke hvis man læser det oprindelige PageRank-patent. Her er det en forudsætning, at der er et link til stede. Det er ganske enkelt det, der skaber grobund for den kalkulerede score og intet andet.
Det oprindelige PageRank-patent blev udarbejdet tilbage i 1998 af Googles skabere, Larry Page og Sergey Brin. Der er sket meget siden dengang. Her 22 år efter ville det være naivt at tro på, at der ikke var lavet talløse ændringer til denne primære og første sorteringsmotor i Google.
Google har samtidig af et par omgange, været ude og udtale sig om fænomenet.
Nævnes i forbindelse med Panda og Quality Raters
Hvis man læser patentet for Googles første større kvalitetsopdatering, Google Panda, vil man se, at der refereres til underforståede links og ”ekspreslinks”.
Ekspreslinks bliver defineret som værende links, en bruger kan klikke på mens underforståede links defineres som værende en reference til en målressource uden et aktivt link. Begge værdier bruges til at beregne værdi for en given side.
Vi ved også fra Google Quality Rater Guidelines at Quality Raters skal vurdere personer og websiders omdømme ud fra benævnelser rundt omkring på Internettet.
Googles Gary Illyes har været ude og sige følgende:
Hvis du publicerer høj kvalitetsindhold, der bliver citeret på Internettet, og jeg taler ikke bare om links, men også benævnelser på sociale netværk, at folk snakker om dit brand, ting som det. Så gør du det storartet.Googles Gary Illyes
Slutteligt, har jeg selv for godt 10 år siden, sammen med min daværende kollega Søren Riisager været med til at udføre en klinisk SEO-test.
Her fik vi igennem en række tests bekræftet, at Google følger benævnelser af URLs uden aktive links og indekserer siderne der nævnes. Så allerede dengang fulgte Google altså mentions som de følger andre links.
Hvorfor er det blevet sværere at få indgående links til sit website?
Google har selv været med til at påvirke webmasters lyst til at linke ud, ved blandt andet at frigive linkspamalgoritmer som Penguin, der med et ændrede den måde hvor på mange opfattede et link.
Pludselig kunne et link være farligt og direkte skadeligt og selvom penguin ikke straffer for udgående links, har det sat en generel frygt i folk og dermed gjort, at mange tænker sig om en ekstra gang, inden de indsætter link.
Det har ført til en stor stigning i brugen af det der kaldes mentions eller implied links og derfor giver det perfekt mening, at Google kommer til at kigge mere og mere på disse, når de skal udregne et websites popularitet.
Andre årsager til at Google ikke kun kan være afhængig af aktive links:
Begrænset udvalg af almen presse (I et land som Danmark er der bare begrænset dækning)
Flere websites gør brug af betalingsmure (Og links herfra har ingen værdi for dit website, udover naturligvis eventuel direkte trafik)
Offentlige websites, offentlig tilhørighed, linker kun til andre offentlige institutioner
Linkpolitikker såsom automatiske nofollow på alle udgående links (Tænk Forbes, Entrepeneur, Wikipedia) eller ingen links til kommercielle interesser (Tænk eks dr.dk)
Markant stigning i brugen af sociale medier hvor Google har meget lille indsigt
Mængden af nichemedier falder i takt med at flere og flere bruger sociale medier til at skabe fællesskaber i stedet for almindelige websites
Du kan derfor være meget sikker på, at værdien af implied links eller URL mentions, vil stige de næste par år.
Har dit website flere hundrede indgående links, vil det også have mange implied links og hvis disse ikke er til stede, er det ret nemt at konkludere, at linkprofilen nok ikke er videre naturlig.
Udover at værdien af mentions vil stige, vil vi også se at Google læner sig mere og mere op af to andre målepunkter, co-citation og Co-Occurence, disse kan du læse mere om i denne artikel, jeg udarbejdede tilbage i 2016: Google & links, nu og i fremtiden.
Publicerer du indhold, er det afgørende hurtigt at få det ud i Googles indeks, særligt hvis der er tale om nyheder. I denne artikel, lærer du hvordan du kan bygge en publiceringsbooster til dit website, der sikrer dig lynhurtig indeksering af alle artikler du udgiver.
Publiceringsmaskinen
Det setup jeg gerne vil beskrive for dig, har jeg brugt af mange omgange, første gang for mere end 8 år siden og det virker stadig lige så godt, som dengang.
Det handler om at gøre brug af syndikeringstjenester, til at opbygge en maskine, der syndikerer alt dit indhold, ikke bare af en enkelt omgang men af flere omgange. Så hvis du tror denne artikel blot handler om hvordan du tilmelder dit artikelunivers til en RSS-parser, tager du heldigvis fejl.
Hvad er en RSS-parser website?
Et RSS parser website, er et website som syndikerer RSS feeds fra en masse forskellige hjemmesider. Ofte vil de være delt op i forskellige kategorier, så brugere nemmere kan scanne indholdet igennem ved at klikke lidt rundt på websitet.
For nogle år siden, havde vi langt flere af denne type sider i Danmark, den dag i dag har vi kun få til rådighed, men de udenlandske er i princippet lige så gode er benytte til formålet, da mange af dem har danske sektioner, herudover handler øvelsen om hurtig indeksering.
Hvad sker når man udgiver en artikel og man er tilmeldt et RSS-parser website?
Når du på din blog eller din hjemmeside udgiver noget nyt indhold, pinger du RSS-websitet, som så trækker en snippet fra dit feed, så vel som titlen på dit indlæg eller din nye side.
Dette bliver nu vist som helt almindelig HTML, du får altså en beskrivende tekst (din snippet), som kort forklarer hvad indlægget handler om og så får du et link der peger ind på din artikel/side, med din titel som ankertekst. Hvis du indarbejder vigtige ankertekster i dine artiklers titler (hvilket du bør), får du altså ankeroptimerede backlinks til din artikel/side.
Bliver mine uddrag ikke begravet i mængden på RSS-parser websitet?
Jo, men besøgende fra RSS-parser websitet er ikke formålet med syndikeringen, dit indlæg vil hurtigt bliver begravet i mængden, men Google skal nok være i stand til at finde dit indhold. Google besøger meget ofte denne slags sider, netop fordi, der deles meget nyt indhold og det derfor er en smart måde, at finde nyt indhold på.
På nogle af de forskellige websites, er links nofollowed, det skal du ikke tage dig af, det er stadig et link, det bekræfter hvad artiklen/siden handler om og så sikrer det lynhurtig indeksering.
Mange af de større RSS websites, som ikke er på dansk, har landekategorier så du kan få dine snippets og links ind under en kategori med andre danske blogs.
Opskrift på simpel publicerings-booster
Det første du skal gøre, er at sikre, at dine indlæg/artikler/sider udgives i et RSS-feed, det er dette feed, du skal bruge, til at tilmelde dine publikationer, til de forskellige sider.
Du har med meget stor sandsynlighed, allerede adgang og gør brug af feeds. Prøv at indtaste /feed efter dit artikelunivers URL. Eksempelvis: https://www.henrik-bondtofte.dk/feed/, som viser alle mine artikler på min personlige blog (hvis du benytter Chrome),
Hvis du får et svar og en liste med artikelnavne og uddrag for dine artikler, som ovenstående, er du klar til at gå i gang. Hvis du ikke har adgang til denne funktion, kører du sandsynligvis et andet system end WordPress.
Hvis dette ikke kan klares nemt igennem et plugin, må du selve kode funktionen eller få din udvikler til det.
Herefter tilmelder du dit website, et par RSS-parser websites.
Feed på feeds
Mange publiceringstjenester tilbyder et feed til dit feed hos dem! Det betyder, at du kan få en URL, som du kan tilmelde til andre RSS-parsers, som så linker tilbage til RSS-parser siden, med alle dine resultater (links og uddrag).
Denne øvelse kan du lave med hvert RSS-parser website, der tillader dette.
Fidusen er at Google hele tiden bliver tvunget til at tage stilling til dine RSS-feeds, da der kontinuerligt linkes til dem, fra andre RSS-parsers.
Kædes det hele sammen, kan du være sikker på dine RSS-parser profilsider/lister, bliver besøgt meget ofte!
Herudover linker de andre RSS-parser sider tilbage til din URL, hvor dine links er på, det betyder at du tier linkbuilder. Du gør siden, der linker til dine indlæg stærkere, og du gør det ovenikøbet helt automatisk.
Du sikrer samtidig løbende links til siden, hver gang du publicerer noget, ligesom du også sikrer flere links til dine endelige destinations URLs på dit website.
RSS-parser domæne
Næste skridt er, at du indkøber et domæne, der selv skal være et RSS-parser website, dette website skal dog kun bestå af feeds, fra dine egne sider og feeds til dine andre RSS-parser website profiler.
Opret et sigende domæne, der matcher dit overall-emne. Skriver du om mobiltelefoni, kunne domænet eksempelvis hedde mobilnyhederne.dk.
Style siden så den ser flot og brugbar ud. Installer nu her efter et RSS-parser feed plugin. Du kan eksempelvis bruge dette plugin til formålet eller finde et andet: https://wordpress.org/plugins/wp-rss-aggregator/
Efter du har opsat dit RSS-parser website
Du har måske allerede luret den, men du skal selvfølgelig sørge for, at dit nye syndikeringsfeed website også publicerer alt som indlæg og at det også parser til et RSS-feed. Du skal nemlig også tilmelde dit nye RSS-parser website, hvis eneste formål er at linke til dine artikler og andre parser-website profiler til RSS-parser websites.
Du bør tilmelde det til alle de RSS-parser websites du overhovedet kan finde.
Her er vi ude i et andet led og du kan derfor bruge så mange udenlandske RSS-parser websites som du overhovedet ønsker.
Vi skal have volumen på og vi er udelukkende på udkig efter rå linkværdier, der kan overføres til vores feed site, så det kan videreformidle denne værdi, efter at den har ”hvidvasket” linksne, ved at agere mellemled til det primære website.
Du kan i princippet blive ved på denne facon. Mit største setup indebar hele 4 manuelt opsatte RSS-parser websites, der alle var tilmeldt til alle andre RSS-parser websites.
Flere af RSS-parser websitesnes begyndte at rangere udmærket i søgeresultaterne, på trods af det var rene snippets med link videre til en helt anden destinationsURL.
Samtidig sikrede det ikke overraskende, at Google opdagede hver eneste publicering få sekunder til minutter efter det blev udgivet. Hvilket resulterer i næsten omgående indeksering af indhold.
Arbejdet med at bygge links, er både hårdt og tidskrævende. Derfor er det også umådeligt vigtigt, at man sikrer de indgående links, der peger ind på ens website og sørger for, at der ikke bliver lukket ned for sider, med indgående links. Bliver sider der er blevet linket til fjernet eller slettet, går den værdi, der ellers ville flyde igennem linket tabt. I denne artikel lærer du, hvordan du får genetableret gamle tabte eksterne links – uden brug af dyre værktøjer. (mere…)
Google har videreudviklet på den efterhånden aldrende nofollow-linkattribut og har introduceret to nye attributter der skal assistere Google i bedre at forstå naturen i den måde, der linkes på. De to nye link attributter hedder rel=”sponsored” og rel=”ugc”. (mere…)
Hvis du bruger Googles Pagespeed Insights til at vurdere, hvor god du er til at optimere dit website, rent hastighedsmæssigt, så er du meget sikkert stødt på begrebet WebP under forbedring af billeder. Spørgsmålet er så: hvad er WebP og kan det gøre dit website hurtigere? (mere…)
Det er praktisk talt muligt at få alt til at rangere, i hvert fald i en kortere periode. Årsagen til dette skal findes i, at Google kigger på en lang række kriterier, når et website først og fremmest skal oparbejde sig igennem søgeresultaternes hierarki. Når resultatet først er landet på forsiden, skal det stå sin prøve over for ægte brugere, og det er i virkeligheden her, slaget går sin gang. (mere…)
Dette website anvender cookies for at sikre dig den bedst mulige oplevelse af dette website. Hvis du fortsætter med at bruge dette site, vil det antages, at du er indforstået med dette.OkLæs mere
