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 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…)
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.
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.
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.
330×490 (161700) / 375×667 (250125) = 0.646 (Impact Fraction)
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
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.
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.
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!
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/
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.
Du kan selvfølgelig også lave RSS feeds over nye produkter og løbende opdatere feedet. Dette vil sikre hurtig indeksering af produkter.