Google Search Console og SEO-ordliste

Klik

Et klik tælles, når en bruger klikker på et resultat i Google Søgning, Discover eller Nyheder, som fører brugeren til en side uden for Google.

Klik, der holder brugeren inde i Google, for eksempel en præcisering af søgningen, der starter en ny søgning, tælles ikke. Hvis du klikker på et resultat, går tilbage og klikker på det samme link igen, tælles det én gang; klikker du på et andet link, tælles det igen. Klikdata krediteres den kanoniske URL, som Google valgte, ikke nødvendigvis den URL, brugeren landede på. Klik i Search Console og sessioner i GA4 måler forskellige ting og stemmer sjældent overens, se GSC-klik vs. GA4-sessioner.

I GSC Magic: Dashboardets oversigt viser daglige klik og et kort med top-søgeforespørgsler og topsider med ændringen i klik i forhold til den foregående periode.

Relateret: Visninger, CTR (klikrate), Session (GA4), Kanonisk URL

CTR (klikrate)

CTR er klik divideret med visninger, vist som en procentdel for hele dit websted eller for en enkelt søgeforespørgsel, side, land eller enhed.

CTR afhænger i høj grad af placeringen og af den type resultat, der vises, så sammenlign den mellem søgeforespørgsler eller sider på lignende placeringer i stedet for med et enkelt mål. Den afhænger også af aggregeringen: når flere af dine sider vises for én søgeforespørgsel, er CTR grupperet pr. ejendom generelt højere end CTR grupperet pr. side, fordi ejendommen får én visning og beholder klikket. Hvis visningerne holder sig stabile, men klikkene falder, foreslår Google, at du tjekker, om din titel og dit snippet stadig beskriver siden godt.

I GSC Magic: report_ctr_outliers viser sider, hvis CTR er under halvdelen af dit websteds median-CTR på samme placering.

Relateret: Klik, Visninger, CTR-afviger (side med lav CTR), Gennemsnitlig placering

Kilder: support.google.com, support.google.com, developers.google.com

Gennemsnitlig placering

Gennemsnitlig placering er gennemsnittet af den øverste placering, dit websted eller din side havde i Google-søgeresultaterne, og tælles kun for søgninger, hvor den fik en visning.

Hvis én søgeforespørgsel viser dit websted på placering 2, 4 og 6 og en anden på 3, 5 og 9, tæller Search Console 2 og 3 og rapporterer et gennemsnit på 2,5. Hvert resultatelement optager én placering: alle links i et videnspanel eller i en AI-oversigt deler elementets placering, og annoncer optager ingen placering. Et resultat, der aldrig blev set, for eksempel på side 3, registrerer ingen placering, og derfor viser nogle celler en tankestreg. Placeringen beregnes kun for Google Søgning, ikke for Discover eller Nyheder, og din egen søgning kan vise en anden rang, fordi resultater afhænger af placering og historik. Google anbefaler at følge ændringer over tid i stedet for at læse en enkelt værdi.

I GSC Magic: report_quick_wins bruger gennemsnitlig placering til at finde par af søgeforespørgsel og side, der ligger på placering 4 til 20 med mange visninger.

Relateret: Visninger, Striking distance-søgeord (hurtige gevinster), AI-oversigter og AI-tilstand (AI Overviews, AI Mode), Kerneopdatering (core update)

Søgeforespørgsel

En søgeforespørgsel er et søgeord, der fik dit websted til at optræde i Google-resultaterne; fanen Søgeforespørgsler i Performance-rapporten grupperer klik og visninger efter den.

Tabellen Søgeforespørgsler er aldrig komplet. Nogle søgeforespørgsler skjules af privatlivshensyn (anonymiserede søgeforespørgsler), og på grund af interne grænser gemmer og viser Search Console kun de vigtigste rækker. Filtre for søgeforespørgsler skelner ikke mellem store og små bogstaver. For søgetypen Web: multimodal, for eksempel Google Lens-søgninger, findes ingen tekstsøgeforespørgsel, så dimensionen mangler. Læs mere i hvorfor Search Console skjuler nogle søgeforespørgsler.

I GSC Magic: gsc_query_analytics returnerer op til 25.000 søgeforespørgselsrækker pr. anmodning via Search Analytics API.

Relateret: Anonymiserede søgeforespørgsler, Grænsen på 1.000 rækker, Brand- og ikke-brand-søgeforespørgsler, Side (dimension)

Side (dimension)

Dimensionen Side grupperer Performance-data efter den URL, som et søgeresultat pegede på efter omdirigeringer, normalt krediteret sidens kanoniske URL.

Når en bruger klikker på en dubleret URL, krediterer Search Console klikket til den kanoniske URL, som Google valgte, og som du kan tjekke med URL-inspektionsværktøjet. Når du vælger fanen Sider, skifter tabelaggregeringen fra ejendom til side, så hver URL, der vises for en søgeforespørgsel, får sin egen visning. Diagrammet forbliver aggregeret pr. ejendom, hvilket er den sædvanlige årsag til, at tabeltotalen og diagramtotalen afviger.

Relateret: Kanonisk URL, URL-inspektion, Søgeforespørgsel, Visninger

Søgeudseende

Søgeudseende er en dimension i Performance-rapporten, der grupperer data efter den resultattype eller funktion, din side optrådte i, for eksempel anmeldelsessnippets, videoer eller produktlister.

Filteret viser kun typer, hvor dit websted har registreret visninger. Gruppering efter søgeudseende aggregerer tabellen pr. side. Klik tildeles en URL, ikke en URL plus funktion, så et filtreret klikantal kan indeholde klik på et almindeligt link til den samme side. Nogle ældre typer, for eksempel FAQ- og How-to-rich results, er angivet af Google som forældede.

I GSC Magic: gsc_query_analytics kan gruppere eller filtrere performance-data efter søgeudseende.

Relateret: Strukturerede data og rich results, Søgetype, Side (dimension)

Kilder: support.google.com

Søgetype

Søgetype er filteret i Performance-rapporten, der adskiller trafik fra Web (tekstbaseret eller multimodal), Billeder, Video og Nyheder i Google Søgning.

Web: tekstbaseret dækker søgeforespørgsler, der skrives i den almindelige søgelinje; Web: multimodal dækker søgninger med billeder, herunder Google Lens, Circle to Search og Chrome-billedsøgning. Billeder, Video og Nyheder dækker de tilsvarende faner. Discover og Google Nyheder har deres egne performance-rapporter. Google anbefaler at analysere søgetyper separat, når man undersøger et fald, og API’ets rækkegrænse gælder pr. søgetype.

Relateret: Søgeudseende, Grænsen på 1.000 rækker, Kerneopdatering (core update)

Land og enhed

I Performance-rapporten grupperer Land data efter, hvor søgningen kom fra, og Enhed grupperer efter skrivebord, mobil eller tablet.

Begge dimensioner aggregeres pr. ejendom. Google angiver, at anmodninger uden dimensionerne søgeforespørgsel eller side, for eksempel lande, enheder og søgeudseende, vises og eksporteres fuldt ud, så de påvirkes ikke af den daglige rækkegrænse. Når man sammenligner skrivebord og mobil, kan placeringen vise en tankestreg, hvis en side ikke havde visninger på den ene enhed.

I GSC Magic: gsc_query_analytics accepterer land og enhed som dimensioner og filtre.

Relateret: Grænsen på 1.000 rækker, Gennemsnitlig placering, Søgeforespørgsel

Datafriskhed og foreløbige data

Datafriskhed er, hvor hurtigt Search Console viser performance-data; de nyeste tal kan være foreløbige og stadig under indsamling, og de tegnes med en stiplet linje.

24-timersvisningen viser de sidste 24 tilgængelige timer med få timers forsinkelse, i timepunkter og i din browsers tidszone. Andre visninger bruger Pacific Time og viser komplette dage som standard. I Search Analytics API returnerer dataState “final” (standard) kun afsluttede data, mens “all” inkluderer friske data, og “hourly_all” tilføjer timeopdelingen. Googles API-guide bemærker, at data typisk er tilgængelige efter 2 til 3 dage.

I GSC Magic: Den hostede synkronisering opdaterer de seneste fire dage hver sjette time, fordi Google reviderer de nyeste tal.

Relateret: Dataopbevaring i 16 måneder, Klik, Visninger

Kilder: support.google.com, developers.google.com, developers.google.com, developers.google.com

Anonymiserede søgeforespørgsler

Anonymiserede søgeforespørgsler er søgninger, som Search Console udelader af sine tabeller for at beskytte privatlivet, fordi de ikke blev foretaget af mere end nogle få dusin brugere over to til tre måneder.

De tælles stadig med i diagrammets totaler, medmindre du anvender et filter for søgeforespørgsler, så summen af tabelrækkerne er normalt lavere end totalen. Filtre fjerner dem helt: søgeforespørgsler, der indeholder et ord, plus søgeforespørgsler, der ikke indeholder det, giver tilsammen mindre end den ufiltrerede total. Se hvorfor Search Console skjuler nogle søgeforespørgsler.

I GSC Magic: GSC Magic læser det samme Search Analytics API, så det kan heller ikke gendanne anonymiserede søgeforespørgsler.

Relateret: Søgeforespørgsel, Grænsen på 1.000 rækker, Brand- og ikke-brand-søgeforespørgsler

Grænsen på 1.000 rækker

Search Console-grænsefladen viser og eksporterer højst 1.000 rækker pr. tabel; Search Analytics API returnerer op til 25.000 rækker pr. anmodning med paginering.

Google angiver API’ets øvre grænse som 50.000 rækker pr. dag pr. websted pr. søgetype, hvilket ikke nødvendigvis nås i alle tilfælde. API’et returnerer 1.000 rækker som standard; rowLimit hæver det til 25.000, og startRow bladrer gennem resten. Anmodninger uden dimensionerne søgeforespørgsel eller side returnerer alle data. Til den mest komplette søgeforespørgselsliste peger Google på bulkdataeksporten til BigQuery. Detaljer i grænsen på 1.000 rækker forklaret og guiden til Search Console API.

I GSC Magic: gsc_query_analytics anmoder om op til 25.000 rækker pr. søgeforespørgsel, så en AI-agent arbejder med langt mere end grænsefladens 1.000 rækker.

Relateret: Søgeforespørgsel, Anonymiserede søgeforespørgsler, Dataopbevaring i 16 måneder, Søgetype

Kilder: developers.google.com, developers.google.com, support.google.com

Dataopbevaring i 16 måneder

Search Consoles Performance-rapport dækker de sidste 16 måneder; ældre dage forsvinder, medmindre du kopierer dataene et andet sted hen via API’et eller bulkdataeksporten.

Seksten måneder er nok til at sammenligne et aktuelt fald med de samme uger året før, hvilket er det tjek, Google foreslår for sæsonudsving. Til længere sammenligninger foreslår Google at hente data med Search Analytics API eller bulkdataeksport og gemme dem i dine egne systemer. Se 3 måder at beholde Search Console-data i mere end 16 måneder og hvordan GSC Magic gemmer historik.

I GSC Magic: Hos Pro og Agency hentes op til 16 måneders historik ved opgradering, og gemt historik slettes aldrig; Free beholder 14 dage.

Relateret: Sæsonudsving, Grænsen på 1.000 rækker, Indholdsforfald

Crawling og indeksering

Crawling og Googlebot

Crawling er den måde, Google finder og henter sider på; Googlebot er Google Søgnings crawler og findes i en smartphone- og en skrivebordsversion.

Google finder nye URL’er primært gennem links fra sider, den allerede kender, og gennem sitemaps, hvorefter den henter dem og gengiver JavaScript med en nyere version af Chrome. Fordi Google primært indekserer mobilversionen af de fleste websteder, kommer de fleste anmodninger fra Googlebot Smartphone. Til Google Søgning henter Googlebot de første 2 MB af en understøttet filtype (64 MB for PDF-filer). Hvis du blokerer crawling med robots.txt, forhindrer det ikke en URL i at optræde i resultaterne; brug noindex til det. Rapporten Crawl Stats viser antal anmodninger, svarstatuskoder og tilgængelighedsproblemer. Google accepterer ikke betaling for at crawle et websted oftere.

I GSC Magic: GSC Magic crawler ikke dit websted; det læser Googles URL-inspektionsdata samt Bings crawlstatistik og crawlproblemer.

Relateret: Indeksering, Crawl-budget, robots.txt, XML-sitemap

Kilder: developers.google.com, developers.google.com, support.google.com

Indeksering

Indeksering er den fase, hvor Google analyserer en crawlet side og gemmer den i Google-indekset; kun indekserede sider kan vises i Google Søgning.

Google Søgning fungerer i tre faser: crawling, indeksering og visning af resultater, og ikke alle sider kommer gennem hver fase. Google garanterer ikke, at en side bliver indekseret, selv om den følger Search Essentials. Rapporten Sideindeksering forklarer, hvorfor URL’er ikke er indekseret, for eksempel “Crawled – currently not indexed” (crawlet, bliver måske indekseret senere, ingen grund til at indsende igen) eller “Discovered – currently not indexed” (fundet, men crawlingen blev udsat for ikke at overbelaste webstedet). Se Search Console: ikke indekseret – årsager og løsninger.

I GSC Magic: report_index_health læser URL’erne i dine sitemaps, inspicerer dem med URL Inspection API og grupperer dem efter dækningsstatus.

Relateret: Crawling og Googlebot, URL-inspektion, noindex, Kanonisk URL

Crawl-budget

Crawl-budget er den mængde URL’er, Google kan og vil crawle på et websted, og den fastlægges af to faktorer: grænsen for crawlkapacitet og crawlebehovet.

Grænsen for crawlkapacitet forhindrer Googlebot i at overbelaste din server; crawlebehovet afhænger af webstedets størrelse, opdateringsfrekvens, sidekvalitet og relevans. Hvert værtsnavn har sit eget crawl-budget. Google siger, at guiden om crawl-budget primært er for meget store websteder (omkring 1 million sider eller mere, der ændrer sig ugentligt), websteder med 10.000 sider eller mere, der ændrer sig dagligt, eller websteder med mange URL’er i “Discovered – currently not indexed”. Hvis nye sider bliver crawlet samme dag, de udgives, er crawl-budget ikke dit problem.

Relateret: Crawling og Googlebot, XML-sitemap, Indeksering

Kanonisk URL

En kanonisk URL er den URL, som Google vælger som den mest repræsentative i en gruppe dublerede sider; det er den version, der normalt vises i søgeresultaterne.

Dubletter opstår fra HTTP- og HTTPS-versioner, mobil- og skrivebords-URL’er, sorterings- og filtreringsparametre eller regionale varianter. Du kan angive en præference med rel="canonical", omdirigeringer og sitemaps, men Google behandler det som et hint, ikke en regel, og kan vælge en anden URL. Search Console krediterer klik og visninger til den kanoniske URL. Sammenlign den brugerangivne og den Google-valgte kanoniske URL i URL-inspektionsværktøjet.

I GSC Magic: gsc_inspect_url returnerer både den angivne og den Google-valgte kanoniske URL for en URL.

Relateret: Omdirigering (301 vs. 302), Side (dimension), URL-inspektion, hreflang

Kilder: developers.google.com, developers.google.com

noindex

noindex er en regel, der sættes med et robots-metatag eller en X-Robots-Tag-HTTP-header, og som fortæller Google at fjerne en side fra søgeresultaterne.

Google skal crawle siden for at se reglen, så siden må ikke være blokeret af robots.txt; ellers kan den stadig vises i resultaterne, hvis andre sider linker til den. Google understøtter ikke noindex i robots.txt. Når du har tilføjet reglen, bliver en side i resultaterne, indtil Google crawler den igen, hvilket kan tage måneder for mindre vigtige sider. Hvis robots.txt blokerer siden, rapporterer URL-inspektionen indeksering som tilladt, fordi Google ikke kan se noindex-reglen.

I GSC Magic: gsc_inspect_url og report_index_health viser, når Google fandt en noindex-regel på en URL.

Relateret: robots.txt, Indeksering, URL-inspektion

robots.txt

robots.txt er en fil i roden af et websted, der fortæller crawlere, hvilke URL’er de må tilgå; den styrer crawling, ikke om en side bliver indekseret.

Google beskriver den som en måde at styre crawlertrafik på og undgå at overbelaste din server. En side, der blokeres af robots.txt, kan stadig blive indekseret uden en beskrivelse, hvis andre sider linker til den, så brug noindex eller adgangskodebeskyttelse for at holde en side ude af Google. Bloker ikke CSS- eller JavaScript-filer, som Google har brug for at forstå siden.

I GSC Magic: Dashboardet kører en hurtig gennemgang af robots.txt og sitemap for hvert websted.

Relateret: noindex, Crawling og Googlebot, XML-sitemap

XML-sitemap

En XML-sitemap er en fil, der lister sider, billeder, videoer og andre filer på dit websted, så søgemaskiner lettere kan finde og crawle dem.

En sitemap kan også indeholde seneste ændringsdato og alternative sprogversioner. Den hjælper med at blive fundet, men garanterer ikke crawling eller indeksering. Google siger, at små websteder med gode interne links (omkring 500 sider eller færre) måske ikke har brug for en, mens store, nye eller medietunge websteder har størst gavn af den. Ved mange nye eller ændrede URL’er anbefaler Google at indsende en sitemap i stedet for at anmode om indeksering af én URL ad gangen. Se sitemap indsendt, men sider ikke indekseret.

I GSC Magic: gsc_list_sitemaps viser status og fejl, gsc_submit_sitemap indsender én (Pro og Agency), og bing_submit_sitemap sender den til Bing.

Relateret: Crawling og Googlebot, Indeksering, robots.txt, IndexNow

URL-inspektion

URL-inspektion er Search Console-værktøjet, der viser Googles indekserede version af en URL, hvorfor den er eller ikke er indekseret, og som kan liveteste en side.

Den rapporterer indekseringsstatus, den Google-valgte kanoniske URL, seneste crawling, fundne strukturerede data og et skærmbillede af den gengivne side. Livetesten tjekker, om en side kan være indekserbar, men kan ikke forudsige, hvilken URL Google vil behandle som kanonisk. URL Inspection API returnerer kun den indekserede version, har ingen livetest og tillader 2.000 inspektioner pr. websted pr. dag. Se hvordan du inspicerer 500 URL’er med API’et.

I GSC Magic: gsc_inspect_url inspicerer én URL, og gsc_inspect_urls_batch inspicerer op til 500 i ét kald inden for Googles kvote.

Relateret: Anmod om indeksering, Indeksering, Kanonisk URL, Soft 404

Kilder: support.google.com, developers.google.com, developers.google.com

Anmod om indeksering

Anmod om indeksering er en knap i URL-inspektionsværktøjet, der beder Google om at crawle en enkelt URL; den garanterer ikke, at siden bliver indekseret.

Du skal være ejer eller fuld bruger af ejendommen. Der er en kvote for enkeltanmodninger, og gentagne anmodninger for samme URL gør ikke crawlingen hurtigere. Crawling kan tage fra få dage til få uger. Ved mange URL’er anbefaler Google at indsende en sitemap i stedet. Googles separate Indexing API er officielt begrænset til sider med JobPosting- eller BroadcastEvent-markup. Se IndexNow vs. Google Indexing API.

I GSC Magic: Det valgfrie værktøj gsc_request_indexing bruger Googles Indexing API, som Google kun understøtter til JobPosting- og BroadcastEvent-sider.

Relateret: URL-inspektion, XML-sitemap, IndexNow, Indeksering

Kilder: developers.google.com, developers.google.com

Soft 404

En soft 404 er en side, der returnerer en 200-succeskode, men som ligner en fejl eller en tom side for Google, som rapporterer den og ikke indekserer den.

Google anbefaler at returnere en 404-statuskode til sider, der reelt ikke findes, og at tilføje mere information til sider, der skal blive, så de ikke ligner fejl. For at se, hvad Google ser, kan du køre en livetest i URL-inspektionen og åbne skærmbilledet af den gengivne side.

Relateret: URL-inspektion, Indeksering, Omdirigering (301 vs. 302)

Omdirigering (301 vs. 302)

En omdirigering sender besøgende og crawlere fra én URL til en anden; en 301 er permanent og signalerer, at målet bør være kanonisk, mens en 302 er midlertidig.

Med permanente omdirigeringer (301, 308, øjeblikkelig meta refresh) viser Google normalt mål-URL’en i resultaterne. Med midlertidige (302, 303, 307) følger Google omdirigeringen, men bruger den ikke som kanonisk signal, så kilde-URL’en kan blive i resultaterne. Serveromdirigeringer er de mest pålidelige; Googles crawlere følger op til 10 hop som standard. Search Console krediterer klik til den endelige URL efter omdirigeringer.

Relateret: Kanonisk URL, Soft 404, Side (dimension)

Kilder: developers.google.com, developers.google.com

hreflang

hreflang er en annotation, der fortæller Google, hvilke sider der er sproglige eller regionale versioner af samme indhold, så brugerne kan få den rigtige.

Du kan angive den i HTML-linktags, HTTP-headere eller sitemappen; de tre metoder er ækvivalente. Hver version skal liste sig selv og alle andre versioner med fuldt kvalificerede URL’er. Google bruger ikke hreflang til at registrere en sides sprog. Sider på samme sprog til forskellige regioner er dubletter, så Google anbefaler at kombinere hreflang med kanonisering.

Relateret: Kanonisk URL, XML-sitemap, Land og enhed

Kilder: developers.google.com, developers.google.com

Strukturerede data og rich results

Strukturerede data er et standardiseret format, oftest med schema.org-ordforråd og ofte skrevet som JSON-LD, der beskriver en sides indhold for Google og kan gøre den berettiget til rich results.

Rich results er søgeresultater med forbedret visning, for eksempel anmeldelsesstjerner, opskriftsdetaljer eller produktpriser. En side skal have alle påkrævede egenskaber for at være berettiget, og markup, der bryder Googles retningslinjer for strukturerede data, kan gøre den uegnet. Google foreslår at teste markup med Rich Results Test under udviklingen og følge rapporterne om rich results i Search Console efter udrulningen. Typer af rich results vises også i dimensionen Søgeudseende.

I GSC Magic: gsc_inspect_url rapporterer de rich results, Google fandt på en URL.

Relateret: Søgeudseende, URL-inspektion, CTR (klikrate)

Core Web Vitals og sidehastighed

Core Web Vitals

Core Web Vitals er tre Google-målinger af den faktiske brugeroplevelse: Largest Contentful Paint (indlæsning), Interaction to Next Paint (responsivitet) og Cumulative Layout Shift (visuel stabilitet).

Gode tærskler er LCP inden for 2,5 sekunder, INP på 200 millisekunder eller mindre og CLS på 0,1 eller mindre, målt ved 75-percentilen af sideindlæsninger, separat for mobil og skrivebord. En side består, når alle tre opfylder målet. Google siger, at gode Core Web Vitals stemmer overens med det, kernesystemerne belønner, som en del af sideoplevelsen. Search Consoles Core Web Vitals-rapport viser, hvordan dine sider klarer sig.

I GSC Magic: cwv_get_origin, cwv_get_url og cwv_history læser Core Web Vitals fra faktiske brugere, og dashboardet viser et Core Web Vitals-kort pr. websted.

Relateret: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), CrUX (Chrome UX Report)

Kilder: web.dev, developers.google.com

LCP (Largest Contentful Paint)

LCP måler indlæsning: tiden indtil det største billede, den største tekstblok eller den største video i viewporten er gengivet. Godt er 2,5 sekunder eller mindre.

LCP måles fra det øjeblik, brugeren først navigerede til siden, så den omfatter servertid, omdirigeringer og etablering af forbindelsen. Brug 75-percentilen af sideindlæsninger, opdelt på mobil og skrivebord, til at vurdere, om de fleste besøgende får en god oplevelse.

I GSC Magic: cwv-værktøjerne returnerer LCP ved 75-percentilen med andelen af gode, forbedringskrævende og dårlige indlæsninger.

Relateret: Core Web Vitals, INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), PageSpeed Insights og Lighthouse

Kilder: web.dev

INP (Interaction to Next Paint)

INP måler responsivitet: hvor lang tid siden er om at reagere synligt på klik, tryk og tastetryk. Godt er 200 millisekunder eller mindre, dårligt over 500.

INP observerer latenstiden for alle interaktioner i et besøg og rapporterer cirka den langsomste og ser bort fra ekstreme værdier. Den erstattede First Input Delay (FID), som kun målte inputforsinkelsen ved den første interaktion. Lange JavaScript-opgaver på hovedtråden er en almindelig årsag til dårlig INP.

Relateret: Core Web Vitals, LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift)

Kilder: web.dev

CLS (Cumulative Layout Shift)

CLS måler visuel stabilitet: den største ansamling af uventede layoutskift i løbet af en sides levetid. Godt er 0,1 eller mindre, dårligt er over 0,25.

Et layoutskift sker, når et synligt element flytter sig mellem gengivne billeder uden brugerinput, for eksempel når et billede uden angivne mål eller en sen annonce skubber teksten ned. Skift mindre end et sekund fra hinanden grupperes i et sessionsvindue, og det største vindue er CLS-scoren.

Relateret: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint)

Kilder: web.dev

CrUX (Chrome UX Report)

CrUX er Googles offentlige datasæt om, hvordan rigtige Chrome-brugere oplever websteder, og den datakilde med feltdata, der ligger bag Core Web Vitals i Googles værktøjer.

Oprindelser og sider er kun med, hvis de er offentligt findbare og har nok besøgende til en statistisk signifikant stikprøve, så mange sider med lav trafik ikke har data. Google Søgning bruger CrUX til at informere sideoplevelsesfaktoren i rangeringen. PageSpeed Insights viser CrUX som sine feltdata og falder tilbage til data på oprindelsesniveau, når en side har for få stikprøver.

I GSC Magic: cwv-værktøjerne forespørger CrUX for en oprindelse eller URL; sider uden nok Chrome-trafik returnerer ingen data.

Relateret: Core Web Vitals, PageSpeed Insights og Lighthouse, LCP (Largest Contentful Paint)

Kilder: developer.chrome.com

PageSpeed Insights og Lighthouse

PageSpeed Insights rapporterer en sides CrUX-feltdata fra rigtige brugere og kører Lighthouse, et open source-værktøj, der tester ydeevne, tilgængelighed, bedste praksis og SEO i et simuleret laboratorium.

Feltdata viser, hvad rigtige besøgende oplevede over tid; laboratoriedata fra Lighthouse er en enkelt kontrolleret kørsel, som er nyttig til fejlfinding, men kan overse flaskehalse i den virkelige verden. PSI’s Core Web Vitals-vurdering bruger feltdata: en side eller oprindelse består, når 75-percentilen af LCP, INP og CLS er God. Lighthouse kører også i Chrome DevTools, fra kommandolinjen eller som et Node-modul.

I GSC Magic: psi_run_audit kører Lighthouse via PageSpeed Insights, og dashboardets Core Web Vitals-kort kan starte en gennemgang.

Relateret: CrUX (Chrome UX Report), Core Web Vitals, LCP (Largest Contentful Paint)

Kilder: developers.google.com, developer.chrome.com

SEO-analyse

Striking distance-søgeord (hurtige gevinster)

Striking distance-søgeord er søgeforespørgsler, hvor en side allerede rangerer lige uden for de øverste resultater, ofte placering 4 til 20, med nok visninger til at vinde klik.

Det er et SEO-praksisbegreb, ikke en Search Console-metrik. Den sædvanlige metode: filtrér Performance-rapporten efter søgeforespørgsel og side, behold rækker med en gennemsnitlig placering lige under de øverste pladser og med meningsfulde visninger, og forbedr derefter den eksisterende side i stedet for at skrive en ny. Husk, at gennemsnitlig placering er et gennemsnit, så tjek udviklingen. Se hvordan du finder striking distance-søgeord og 7 hurtige SEO-gevinster.

I GSC Magic: report_quick_wins returnerer par af søgeforespørgsel og side på placering 4 til 20 med mange visninger, sorteret efter potentielle ekstra klik.

Relateret: Gennemsnitlig placering, Visninger, CTR-afviger (side med lav CTR)

Kilder: support.google.com

Keyword-kannibalisering

Keyword-kannibalisering er, når to eller flere sider på dit websted konkurrerer om den samme søgeforespørgsel og deler visninger og klik i stedet for at én side rangerer godt.

Det er et SEO-praksisbegreb snarere end et Google-begreb. I Search Console viser det sig som én søgeforespørgsel med visninger spredt over flere URL’er, som nogle gange bytter plads over tid. Ikke enhver overlapning er et problem: forskellige intentioner kan fortjene forskellige sider, og brand-søgeforespørgsler viser ofte mange URL’er. Almindelige løsninger er at slå sider sammen med en 301-omdirigering, skærpe deres respektive intention eller justere de interne links. Se keyword-kannibalisering i Search Console.

I GSC Magic: report_cannibalization viser søgeforespørgsler, hvor to eller flere af dine sider hver får en betydelig andel af visningerne.

Relateret: Søgeforespørgsel, Side (dimension), Kanonisk URL, Omdirigering (301 vs. 302)

Kilder: support.google.com

Indholdsforfald

Indholdsforfald er et gradvist, vedvarende fald i en sides søgeklik over flere måneder, i modsætning til et pludseligt fald fra et teknisk problem eller en opdatering.

Det er et SEO-praksisbegreb. Typiske årsager er forældet information, nyere konkurrerende sider eller ændret søgeinteresse. Sammenligning af flere på hinanden følgende perioder skiller en jævn glidebane fra en dårlig uge; et tjek af de samme måneder året før udelukker sæsonudsving. Se hvordan du opdager indholdsforfald.

I GSC Magic: report_content_decay viser sider, hvis klik faldt i hvert af de sidste tre vinduer (28 dage hver som standard).

Relateret: Sæsonudsving, Dataopbevaring i 16 måneder, Kerneopdatering (core update)

CTR-afviger (side med lav CTR)

En CTR-afviger er en side eller søgeforespørgsel, hvis klikrate ligger godt under, hvad andre resultater på samme placering på dit websted får.

Fordi CTR falder med placeringen, betyder en lav CTR kun noget, når den sammenlignes ved lignende placeringer. Afvigere har ofte en titel eller et snippet, der ikke matcher søgeforespørgslen, eller som konkurrerer med et rich result eller en AI-oversigt på samme resultatside. Google foreslår at gennemgå titel og snippet, når visningerne holder, men klikkene falder. Se søgeord med lav CTR i Search Console.

I GSC Magic: report_ctr_outliers markerer sider, hvis CTR er under halvdelen af dit websteds median-CTR på samme placering.

Relateret: CTR (klikrate), Gennemsnitlig placering, Striking distance-søgeord (hurtige gevinster)

Brand- og ikke-brand-søgeforespørgsler

Brand-søgeforespørgsler indeholder dit brandnavn, dets stavefejl eller dine unikke produkter; ikke-brand-søgeforespørgsler er alle andre søgninger, der viser dit websted.

Brand-søgeforespørgsler rangerer normalt højere og får flere klik, mens ikke-brand-søgeforespørgsler viser, hvordan nye mennesker finder dig. Search Console har et brandfilter i Performance-rapporten, som klassificerer med et AI-assisteret system i stedet for en søgeordsliste. Google siger, at det kun er tilgængeligt for ejendomme på topniveau med nok søgeforespørgsler og visninger, og at det kan fejlklassificere nogle søgeforespørgsler.

I GSC Magic: report_brand_split opdeler søgeforespørgsler efter de brandord, du angiver, og returnerer klik, visninger og klikandel for hver gruppe.

Relateret: Søgeforespørgsel, CTR (klikrate), Anonymiserede søgeforespørgsler

Sæsonudsving

Sæsonudsving er en tilbagevendende stigning eller et fald i søgeefterspørgslen på samme tid hvert år, for eksempel helligdage, som ændrer trafikken uden ændret rangering.

Googles guide til trafikfald foreslår at sætte Performance-rapporten til de sidste 16 måneder for at se, om et fald gentager sig hvert år, og at tjekke top-søgeforespørgsler i Google Trends for at se, om efterspørgslen faldt på hele nettet. Hvis visningerne faldt, mens placeringen holdt, er efterspørgslen den sandsynlige årsag. Se sæsonudsving vs. reelle rangeringstab.

I GSC Magic: Fordi Pro og Agency gemmer historik i mere end 16 måneder, kan agenter sammenligne samme periode på tværs af mere end et år.

Relateret: Dataopbevaring i 16 måneder, Indholdsforfald, Kerneopdatering (core update)

Kerneopdatering (core update)

En kerneopdatering er en betydelig, bred ændring af Googles søgerangeringssystemer, som sker flere gange om året og annonceres på Googles liste over rangeringsoppdateringer.

Kerneopdateringer rammer ikke bestemte websteder. Google anbefaler at vente, til udrulningen er færdig, og derefter sammenligne en hel uge efter med en uge før, den begyndte. Et lille fald, for eksempel fra placering 2 til 4, kræver ingen drastisk handling; et stort, vedvarende fald kræver en ærlig vurdering af hele webstedets hjælpsomhed. Google bemærker, at nogle ændringer virker i løbet af dage, andre i løbet af flere måneder. Se tjeklisten for fald i organisk trafik.

I GSC Magic: report_traffic_drops sammenligner en periode med den foregående og viser de sider eller søgeforespørgsler, der tabte eller vandt flest klik.

Relateret: Gennemsnitlig placering, Sæsonudsving, Søgetype

Kilder: developers.google.com, developers.google.com

Bing og IndexNow

Bing Webmaster Tools

Bing Webmaster Tools er Microsofts modstykke til Search Console: søgeydeevne, crawl- og indeksdata, URL-indsendelse og søgeordsforskning for Bing.

Dets API giver programmatisk adgang til trafik- og rangeringstal, link- og søgeordsoplysninger, crawlstatistik og indsendelse af URL’er og sitemaps. Search Performance viser 16 måneders historik. AI Performance, der blev introduceret som offentlig forhåndsvisning i februar 2026, viser, hvor ofte dine sider citeres i Microsoft Copilot og Bings AI-genererede svar. Se guiden til Bing Webmaster Tools API og Bing Webmaster Tools i GSC Magic.

I GSC Magic: Med din Bing API-nøgle tilføjer GSC Magic Bing-værktøjer til søgeforespørgsels- og sidestatistik, crawl-data, søgeordsforskning og URL-indsendelse samt report_google_vs_bing.

Relateret: IndexNow, GEO (generativ engine-optimering), XML-sitemap

Kilder: learn.microsoft.com, blogs.bing.com, blogs.bing.com

IndexNow

IndexNow er en åben protokol, der lader et websted øjeblikkeligt fortælle deltagende søgemaskiner, herunder Bing, Naver, Seznam.cz, Yandex og Yep, at en URL er tilføjet, opdateret eller slettet.

Du hoster en nøglefil på dit websted for at bevise ejerskab og sender derefter én URL eller en batch til et IndexNow-endpoint; en indsendelse deles med alle deltagende motorer. Et HTTP 200-svar betyder kun, at URL’en er modtaget, ikke at den bliver indekseret. Google er ikke på listen over deltagende motorer. Se hvordan du sætter IndexNow op med en AI-agent.

I GSC Magic: indexnow_generate_key opretter en nøgle, og indexnow_submit sender op til 10.000 URL’er pr. kald (Pro og Agency, med din IndexNow-nøgle).

Relateret: Bing Webmaster Tools, Anmod om indeksering, XML-sitemap

Kilder: indexnow.org, indexnow.org, indexnow.org

Google Analytics 4

Session (GA4)

I Google Analytics 4 er en session en periode, hvor en bruger interagerer med dit websted eller din app; på nettet slutter den som standard efter 30 minutters inaktivitet.

En session starter, når nogen åbner appen eller ser en side, mens ingen session er aktiv, og GA4 logger en session_start-hændelse. Der er ingen maksimal længde, og timeouten kan ændres i indstillingerne for datastrømmen. Sessioner er ikke det samme som klik i Search Console, se hvorfor tallene ikke stemmer og GA4 i GSC Magic.

I GSC Magic: ga_run_report forespørger GA4-sessioner skrivebeskyttet, efter en hvilken som helst dimension som landingsside eller sessionskilde.

Relateret: Klik, Nøglehændelse (GA4), Henvisningstrafik, Trafik fra AI-assistenter

Kilder: support.google.com

Nøglehændelse (GA4)

En nøglehændelse er en GA4-hændelse, som du markerer som vigtig for din forretning, for eksempel et køb eller en tilmelding; nøglehændelser hed tidligere konverteringer i Analytics.

Enhver indsamlet hændelse kan markeres som nøglehændelse. Google bruger nu “konvertering” om handlinger, der måles for Google Ads-kampagner og budgivning, så antallet af konverteringer og nøglehændelser kan afvige.

I GSC Magic: ga_list_key_events viser de nøglehændelser, der er konfigureret på en GA4-ejendom.

Relateret: Session (GA4), Henvisningstrafik

Kilder: support.google.com

Henvisningstrafik

I GA4 er Referral den standardkanal, der dækker besøgende, som kommer via ikke-annoncelinks på andre websteder eller apps, for eksempel blogs og nyhedssites.

GA4 tildeler sessioner til standardkanaler ud fra kilde og medium. Organiske søgeresultater, herunder Googles AI-oversigter og AI-tilstand, går til Organic Search, og anerkendte AI-assistenter har deres egen kanal, AI Assistant. Direct dækker besøg fra et gemt link eller en indtastet URL.

Relateret: Trafik fra AI-assistenter, Session (GA4), Nøglehændelse (GA4)

Kilder: support.google.com

Trafik fra AI-assistenter

Trafik fra AI-assistenter er besøg fra links i chatassistenter som ChatGPT, Gemini, Claude eller Copilot, som GA4 grupperer i kanalen AI Assistant, når den genkender henviseren.

Siden maj 2026 sætter GA4 mediet til ai-assistant og kanalen til AI Assistant, når henviseren matcher en anerkendt assistent; kanalen udelukker Googles AI-oversigter og AI-tilstand, som tælles som Organic Search. Kanalen afhænger af henviseren, så assistentbesøg uden henviser tælles ikke der. Trafik er ikke det samme som citater. Se spor ChatGPT- og Perplexity-trafik i GA4.

I GSC Magic: Dashboardet tæller GA4-sessioner fra AI-assistentkilder som ChatGPT, Perplexity, Claude og Gemini; det måler besøg, ikke citater.

Relateret: Henvisningstrafik, Session (GA4), GEO (generativ engine-optimering), AI-oversigter og AI-tilstand (AI Overviews, AI Mode)