I denne artikel gennemgår jeg de forskellige elementer, du kan skrue på, når du vil have din video positioneret bedre i YouTubes søgeresultater. En god placering på YouTube kan også øge chancen for, at dine videoer bliver vist i de organiske resultater. YouTube er verdens næststørste søgemaskine og byder derfor på masser af muligheder for markedsføring.
(mere…)
I August 2005 indgav Google en patentansøgning ved navn ’Agent Rank’. I dette patent redegør Google-medarbejderen David Minouge for en type agenter, der benytter modtagelsen og interaktioner på indhold udarbejdet af ”agenten” til at fastslå deres position. I patentet står det direkte, at ”agenters” indhold kan opnå højere rangeringer i søgeresultaterne end indhold, der ikke er signeret af en ”agent”, eller for den sags skyld rangerer højere end mindre autoritære ”agenter”.
Ovenstående er taget fra min artikel omkring AuthorRank, som jeg udgav tilbage i 2012, hvor Google+ var på sit højeste. Vi var mange, der mente, at Google+ skulle være det bindeled som Google manglede for at kunne kæde personer sammen med ekspertise. Det viste sig ikke at holde stik dengang, hvilket der kan være mange årsager til. Kompleksiteten i det at spore enkeltpersoner på tværs af websitet må have været den tungestvejende årsag, men igennem brugen af Google+ ville Google have haft meget nemmere ved dette. Problemet var bare, at adaptionsraten var alt for lav.
Selvom vi var mange, der var vilde med Google+, gik det hurtigt op for os, at Google+ stort set kun indeholdt personer fra marketingbranchen og fotografer, som platformen netop egnede sig rigtigt godt til.
Author.URL ejendommen er en ejendom under Article-Schema, som du kan tilføje til dine strukturerede data for artikler. Værdien består blot af et link til en webside, der definerer og identificerer artiklens forfatter. Linket kunne eksempelvis pege på en profil på et socialt medie eller på en om-side på et givent website. Eller en helt anden form for side, der identificerer forfatteren, fx en Wikipedia-side om personen.
Ejendommen er ikke ny, men det nye er, at Google den 6. august 2021 ændrede i dokumentationen for Articles og gjorde det til en konkret anbefaling at benytte, så Google nemmere kan identificere den korrekte forfatter af artiklen.
Bruger du en af Googles værktøjer til at vurdere din Schema for artikler, vil du nu også opleve, at de påpeger manglen af Author.URL, hvis du ikke aktivt bruger denne.
“August 6: Added a new recommended author.url property to the Article structured data documentation. The url property helps Google disambiguate the correct author of the article.”
Author.URL i praksis. Som udgangspunkt vil de fleste plugins, pege på din norrmale authorside – dette kan dog ændres til eksempelvis din om-side, men husk at tilføje artikler til din om-side, i så tilfælde.
Som tidligere beskrevet er det svært for Google at identificere forfattere på tværs af websites. Er du vidende og aktiv inden for et givent emne, er der en stor chance for, at du udtaler dig på flere forskellige medier. Det kan med andre ord give Google et rigtigt godt indblik i dine fodspor rundt omkring på internettet.
Google forsøger allerede på dette med en teknik, de kalder for ”forsoning”. Den bruges til at forstå hvornår indhold rundt omkring på internettet tilhører den samme forfatter. Googles John Mueller fortalte om dette i Googles Search Central SEO hangout den 23. april 2021. Her spurgte en websiteejer, om det er vigtigst at inkludere sin e-mail på en forfatterside eller et link til en social medie-side. Her anbefaler John Mueller en social medie-side, som man linker til konsekvent, når man nævnes som forfatter, da denne så kan bruges som et unikt fodspor.
“Essentially what I see on our side is, when it comes to things like author pages, or information about the author, or information about entities in general behind a website, an article, or something, – what happens there is our systems try to recognize who that is, what that entity is, and we do that based on a number of different factors. And that does include things like links to profile pages for example, or visible information that we can find on these pages themselves. So, my recommendation here would be to at least link to a common, or kind of like a central place, where you say everything comes together for this author.”
Han kommer herefter også ind på, hvordan det er tæt på umuligt for Google at differentiere imellem personer med samme navn, hvis de ikke samtidig linker til noget unikt, der kan bruges til at identificere dem. Eksempelvis et Twitter-handle, som der ikke kan findes to identiske versioner af.
Google har tydeligvis udfordringer med at identificere folk korrekt, og vi kan ved at gøre brug af AuthorURL give dem mere konsekvente svar og endnu mere data at handle på.
Hvis Google kan forøge adaptionsraten af Author.URLs, vil det være en fantastisk mulighed for dem. Det kunne de eksempelvis gøre ved at tilbyde forfatterbilleder i SERPs for dem, der formåede at benytte implementeringen korrekt. Personligt tvivler jeg på, at vi får forfatterbilleder i SERPs igen, da de stjæler for meget blikfang fra Googles egne resultater, men noget lignende kunne sagtens blive en realitet for at skubbe på adaptionsraten.
Lad os sige, at du ved så meget om et emne, at du får lov til at skrive en artikel om det på N.Y. Times. Din viden er så stor, at du bliver annerkendt af et stort og respekteret medie. Den her kudos vil Google gerne spore. For hvis du er så dygtig, at du kan få lov til at udgive artikler på et sådant medie, så har du sikkert udgivet andre artikler på andre medier af lige så høj kvalitet?
Idéen er altså, at det du skriver og er afsender på, kan rangeres højere i søgeresultaterne på baggrund af din personlige ekspertise – ikke på baggrund af websitet, du har publiceret artiklen på. Selvom websitet ikke normalt rangerer vildt godt, så vil de artikler, du har forfattet, have en unaturlig høj rangering, da du som person er udvalgt til at blive vist mere prominent.
Da vi havde Google+, var selve hubben vi forbandt alt med Google+. På din Google+ profil kunne du linke videre til dine andre sociale medieprofiler og andre steder på internettet, hvor du var at finde, eksempelvis aviser eller magasiner, som du bidrog til. Samtidig linkede man retur til sin Google+ profil, hver gang det var muligt.
Author.URL er en adresse, du selv definerer. Jeg vil advokere for, at du bruger din om-side, hvis du skriver på en selvstændig blog og ellers skal du bruge dit forfatterarkiv.
Få fyldt forfattersiden ud med al relevant information om dig, både uddannelsesmæssig såvel som erhvervsmæssig erfaring og vigtigst af alt – links til unikke sider, der kan bekræfte din person (dine sociale medieprofiler).
Hvad skal den indeholde?
Ja. Det er helt klart min forventning, at det bliver en realitet, hvis det ikke allerede er det. Man kunne nemt forestille sig, at Google i nogle tilfælde øger synligheden af artikler skrevet af prominente personer inden for et givent emne.
Det vil dog kun være i de tilfælde, hvor Google er 100% sikker på hvem en given person er. Og effekten vil nok være så lille på nuværende tidspunkt, at den vil være svær at afkode i praksis.
Det er dog klart min forventning, at det vil udvikle sig over tid, efterhånden som Google bliver bedre og bedre til at objektivisere personer og kæde dem sammen med indhold rundt omkring på internettet.
Siden vi første gang hørte om AgentRank for over et årti siden, har det lydt som en ikke bare brugbar, men super nyttig funktion, der kan fremhæve ekstra troværdigt indhold i søgeresultaterne.
At det er et websites styrke, der bestemmer hvor godt en artikel skal være positioneret, giver naturligvis mening. Men det giver endnu bedre mening at bruge en kombination af forfatterens ekspertise og websitets autoritet i kombination.
Driver du et website, er der en god chance for, at du allerede på nuværende tidspunkt har bidt mærke i, at Google i større stil end de plejer, er begyndt at omskrive title-tags og vise andet indhold fra din side, som fx din websides sidetitel i de organiske søgeresultater. Hvorfor ændrer Google sidetitlerne og skal du gøre noget anderledes i den forbindelse? Få min vurdering på netop dette i denne artikel.
(mere…)
De organiske resultater skrumper og skrumper – organisk synlighed kræver bedre og bedre placeringer. For et par år siden var top-7 det nye top-10 i de organiske resultater, men vi ser efterhånden, at det kun er de øverste 5 resultater, der henter organisk trafik ind.
Dette sker i takt med, at Google Ads, lokale resultater og andre af Googles ejendomme er begyndt at tage mere og mere plads. Noget, der i dén grad har sat gang i udviklingen, er også introduktionen af hurtige svar direkte i søgeresultaterne, hvilket fører til utroligt mange no-click søgninger.
Har vi brug for flere resultatsider?
Der var dengang, hvor Googles brugere forvildede sig om på side to eller tre, hvis de ikke fandt hvad de søgte på første side af søgeresultatet. Den tid er efterhånden en saga blot. I dag er der langt større chance for, at brugeren omdefinerer sin forespørgsel, hvis denne ikke finder noget brugbart i toppen af Googles søgeresultat.
Google er med andre ord så gode til at forstå hensigten bag en søgning, at de næsten altid leverer de rigtige resultater. Derfor er det nærliggende at tro, at man har søgt forkert, frem for at Google leverer forkerte resultater. Eftersom Google er blevet meget bedre til at levere de rigtige resultater, særligt efter indførslen af kunstig intelligens, er behovet for flere sider med resultater ikke særligt stort. I langt de fleste tilfælde vil det kun være i forbindelse med dataindsamling eller research, at en bruger søger efter mere viden, end den man kan finde på den første side af en Google søgning.
For ti år siden var der masser af trafik at hente i 11-12 placeringer i Google, men det er der ikke i dag. Det bliver først for alvor sjovt, når vi lander på forsiden, dog med forbehold for de nederste resultater (6-10 placeringer).
6-10 placeringer er den nye side to af Google
For bare få år siden var der masser af trafik at hente ved en forsideplacering. En forsideplacering på et vigtigt søgeord var en sejr og noget, der ville give trafik og opmærksomhed. Men i dag er det endnu vigtigere at ligge på placeringerne 1-5 og ikke blot på forsiden for at få mange besøg.
Above the fold på en smartphone inkluderer ikke mange organiske resultater
En anden årsag til, at klikraten er faldet voldsomt i de organiske resultater på nedre placeringer, er at langt de fleste søgninger, der foretages i Google, foretages på en mobil enhed – og på en mobil enhed er der ikke plads til samme antal resultater. På nogle søgninger vil det slet ikke være muligt at finde de organiske resultater above the fold. Her vil der udelukkende være annoncer og andre uddrag fra Googles søgemaskine.
Særligt shopping annoncer træder meget prominent frem på smartphones og fylder ofte rigtigt meget af above the fold. Disse forekommer naturligvis sjældent på informationssøgninger, men er stort set altid til stede på transaktionsøgninger. (Læs mere om de forskellige søgetyper her)
Det er min umiddelbare forståelse og forventning, at det bliver tæt på umuligt at opnå gode placeringer på kommercielle søgninger organisk. Her vil Google hellere vise anmeldelser og brugscase scenarier, hvorimod direkte købsmuligheder listes som annoncer. Her er vi dog en del år ude i fremtiden og om det bliver en realitet, vil kun tiden vise.
Hvis dette bliver tilfældet, bliver content marketing endnu vigtigere, da 80% af alle søgninger i Google er informationssøgninger. Disse søgninger er på ingen måder i lige så høj grad præget af annoncer, da intentionen som udgangspunkt ikke er at købe.
Alt for få klikker på Googles annoncer, hvis du spørger Google
Googles største og eneste indtjeningskilde på deres største medie, deres søgemaskine, er ikke overraskende annoncekroner, som de tjener på deres annoncesystem Google Ads (tidligere Adwords).
Mange går i den tro, at annoncer tager langt de fleste kliks, men dette er ikke tilfældet. Langt de fleste brugere foretrækker faktisk at klikke på de organiske resultater. Ifølge denne undersøgelse fra 2018 modtager organiske placeringer i snit stadig 71.33% af alle kliks, hvilket efterlader under 30% af klikkene til annoncer.
På stærkt kommercielle søgninger kan der selvfølgelig være store forskelle og også de resultater, hvor Google Ads tager flere kliks end organiske, men i gennemsnit er det stadig de organiske resultater, der løber med sejren.
Dette er et problem for Googles indtjening, og derfor arbejder de kontinuerligt på at gøre synligheden af annoncer mere markant i søgeresultaterne. For eksempel ved at annoncerne bliver placeret mere prominente steder; i toppen af søgninger, fremfor ude i højre side ved siden af de organiske resultater, der tidligere var praksis.
Den gradvise ændring er dog så insignifikant, at de fleste ikke lægger mærke til de mange ændringer, der foretages. Det sker stille og roligt over en lang årrække.
Google inventory fylder i snit 40% af søgeresultaterne den dag i dag. Dette bestående af rige uddrag, knowledge panel, lokale placeringer, nyhedsbokse, annoncer, hurtige svar, folk spurgte også om mv.
Flere sidevisninger og færre kliks
Hvis du tager et kig i din Search Console og kigger på visninger og klik, vil du med stor sandsynlighed se, at dine klikrater er faldende og har været det i en længere periode. Særligt de sidste to år er det gået hurtigt ned af bakke, i mange vertikaler.
Det er slet ikke usandsynligt, at dit antal af visninger af organiske resultater samtidig er steget. Grundet den faldende klikrate har du måske ikke oplevet nogen vækst, selvom dine søgeord er gået frem i de organiske resulstater.
Hvordan skal man så angribe SEO fremadrettet?
Det bliver kun vigtigere og vigtigere at få afdækket alle tænkelige søgeord og udarbejde en strategi for at få dem implementeret som indhold på websitet. I stedet for at fokusere på de store generiske søgeord, der som ofte heller ikke konverterer særligt godt, bør du fokusere på volumen. Særligt longtail søgninger med lav konkurrence er blevet endnu mere interessante, fordi det her er nemmere at opnå en top-5-placering, end det er på mere prominente søgeord.
Du skal naturligvis ikke kun fokusere på de nemme og enkle søgeord, men på det hele. Sørg for at sprede din indsats ud, så du har mange flere resultater, der potentielt set kan give dig besøgende. Du skal altså med andre ord udvide antallet af søgninger, som dit website findes på og fokusere på at få oparbejdet top-5-placeringer på disse.
Rich snippets er udvidede uddrag baseret på mark-up code på dit website. Udvidede uddrag er en fantastisk måde at få sine resultater til at skille sig ud i søgeresultaterne, når det bliver vist ved en relevant forespørgsel.
Udover at tiltrække sig større opmærksomhed, vil et resultat med udvidede uddrag som ofte også være mere relevant og interessant for brugeren at klikke sig ind på. De kan derfor drastisk forøge de organiske klikrater. I 2021 er udvidede uddrag ikke til at komme uden om og noget alle bør arbejde med.
Har du udfordringer med at få dine udvidede uddrag vist i Googles søgeresultatsider? Så kan årsagen meget sandsynligt findes i denne artikel.
Det er vigtigt først og fremmest at slå fast, at der ingen garantier er for, at Google og andre søgemaskiner viser dine udvidede uddrag. Google forbeholder sig nemlig retten til ikke at håndtere dine strukturerede data.
Herudover er der rigtigt mange markeringer, som Google ikke understøtter fra det officielle Schema vocabulary. Af dem Google understøtter, er det kun en brøkdel, der rent faktisk fører til udvidede uddrag ude i SERPs. Det betyder naturligvis ikke, at du ikke bør implementere dem alligevel, da de stadig kan give en større forståelse for, hvordan dit website er sammensat og fungerer. Det er heller aldrig til at vide, hvilke uddrag Google næste gang lukker op for – eller for den sags skyld hvornår.
Personligt anbefaler jeg mange Schema-implementeringer, der ikke giver udvidede uddrag, men har naturligvis størst fokus på dem, der gør.
Google har udarbejdet en større guide til, hvordan man overholder deres kvalitetsstandarder ift. markup. Guiden kan du finde her: https://developers.google.com/search/docs/guides/intro-structured-data?hl=EN#quality-guidelines
Som udgangspunkt anbefaler Google, at man benytter JSON-LD som format, men understøtter også Microdata og RDFa. Herudover dikterer Google, at dine oplysninger skal være opdaterede og ikke forældede samt at den information du tagger, skal være originalt indhold skabt af dig eller dine brugere. Du må samtidig ikke lave markup af irrelevant indhold, ulovligt indhold eller indhold, der faciliterer skade på andre.
Grundlæggende ønsker Google ikke at vise struktureret data eller rich snippets, som det også kaldes, på sider hvor kvaliteten ikke er høj nok.
Det behøver som udgangspunkt ikke at have noget med din markering at gøre. Hvis Google ikke stoler på dit website, vises der heller ikke udvidede uddrag baseret på dine strukturerede data.
Dette har dog noget at gøre med en overordnet kvalitetsmæssig betragtning af dit website, og det er dermed ikke nødvendigvis direkte relateret til din implementering af struktureret data, men det påvirker muligheden for at få vist udvidede uddrag i søgeresultaterne.
Det er af samme årsag, at mange nye websites ikke har det store held med at få vist alle sine markeringer som udvidede uddrag.
Google ønsker ikke at vise bandeord eller vulgært sprog i deres søgeresultater. Derfor scanner de efter disse slags ord og sætninger og prøver på at holde dem ude af deres søgeresultater. Det er også gældende for sider, der befinder sig inden for brancher, hvor man oftest bruger et vulgært sprog, eksempelvis sexshops eller andre sider inden for denne industri.
Schema Markup, som danner grobund for de udvidede uddrag, som vi kan opnå ude i søgeresultaterne, er kun et markup og ikke indhold i sig selv. Det betyder også, at du kun må markere noget op, som allerede findes på websiden i forvejen og som brugerne kan se. Du må altså ikke markere noget med data, som ikke er der.
Et eksempel på dette kunne være, at du har implementeret FAQ-Schema tagging på en side, men du har ikke en boks med disse ofte stillede spørgsmål på selve siden, som brugerne besøger. Det er nemlig en form for cloaking. Du skal vise dine brugere det samme, som du viser søgemaskinerne.
I en verden, hvor populære CMS har et hav af udvidelser og plugins tilgængelige, kan det hurtigt ske, at man kommer til at gøre brug af flere forskellige markup-sprog, hvis man bruger forskellige typer af plugins, til forskellige markups. Vær derfor varsom med at bruge flere forskellige værktøjer og se, om du i stedet ikke kan finde et enkelt eller selv udarbejde og implementere din markup.
Blander du eksempelvis JSON-LD sammen med Microdata markeringer, vil dine udvidede uddrag ikke blive vist korrekt eller overhovedet vist, for den sags skyld. Ved at bruge forskellige kodninger gøre du det langt sværere at vedligeholde dine markups, og du øger samtidig risikoen for fejl og forkerte sammenhænge, som jo netop er en af essensen ved markups.
Den største og mest hyppige årsag til at udvidede uddrag ikke vises er naturligvis forkert implementering. Schema markup er meget stringent, og det må ikke indeholde fejl, hvis det skal kunne læses.
Hvis din strukturerede data verificerer i Googles værktøj til verificering, er din tagging som udgangspunkt i orden, også selvom andre mere stringente testværktøjer brokker sig over enkelte elementer.
Start derfor altid med at tjekke din kode i dette værktøj, inden du implementerer og tjek også gerne efter implementering, blot på URL-niveau, for at være sikker.
Du kan teste din markup her: https://developers.google.com/search/docs/advanced/structured-data
Du kan også bruge Googles Search Console til at holde øje med allerede eksisterende implementeringer. Dette finder du under feltet ”Forbedringer” – her kan du klikke dig ind på enkelte understøttede udvidede uddrag:
Der skal ikke særligt meget til at udløse en penalty, der gør, at du ikke længere kan vise nogen former for udvidede uddrag på dit website, uanset hvor meget du har markeret op. Udløseren vil i 9 ud af 10 tilfælde være, at du har tagget noget op, som ikke findes på siden, altså at du cloaker. Uanset om du gør det med vilje eller ubevidst, kan hammeren ramme.
Den eneste måde at få løst denne penalty på, er at få fjernet alt ikke retvisende schema markup og herefter bede om en ny bedømmelse.
Hvordan ved du, om du har fået en straf? Det gør du ved at åbne den Search Console konto, der er tilknyttet dit website. Herefter navigerer du til ’Manuelle handlinger’, hvor du vil se en besked fra Google.
Jeg har selv personligt været ramt af denne penalty, endda på denne blog, for nogle år siden. Dengang var der ikke tale om et bevidst forsøg fra min side af på at manipulere. Der var ganske enkelt tale om en fejl i et plugin, som ikke blev opdateret, når jeg fjernede indhold fra en side og derfor blev markeringen stadig liggende.
Det tog ca. 2 måneder fra jeg opdagede udfordringen og udbedret det, til jeg igen kunne vise udvidede uddrag i SERPs.
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.
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.
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.
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:
Der er stor forskel på om du kigger på gennemsnitsplaceringen for et søgeord eller en URL, mere om dette neden for.
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.
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.
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.
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.
Du kan læse mere om hvordan Google håndterer eksponeringer her
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.
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?
Se videoen og få en hurtig opsummering eller spring videoen over og læs artiklen efter videoen.
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.
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.
Herunder finder du en række af de punkter, du kan forbedre, hvis du vil sænke din LCP.
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).
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).
Udover CSS og Javascripts blokeringstid er der også andre mange andre former for ressourcer der kan påvirke LCP eksempelvis <img>-elementer, <video>-elementer og <image>-elementer og elementer der indeholder tekststrenge eller andre inline tekstelementer.
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.
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.