Ordliste for Google Search Console og SEO

Klikk

Et klikk telles når en bruker klikker på et resultat i Google Søk, Discover eller Nyheter som tar dem til en side utenfor Google.

Klikk som holder brukeren inne i Google, for eksempel en presisering av søket som starter et nytt søk, telles ikke. Å klikke på et resultat, gå tilbake og klikke på samme lenke igjen teller én gang; å klikke på en annen lenke teller på nytt. Klikkdata tilskrives den kanoniske URL-en Google valgte, ikke nødvendigvis URL-en brukeren landet på. Klikk i Search Console og økter i GA4 måler ulike ting og stemmer sjelden overens, se klikk i GSC mot økter i GA4.

I GSC Magic: Oversikten i dashbordet viser daglige klikk og et kort med topp søkeord og sider, med endringen i klikk mot forrige periode.

Relatert: Visninger, CTR (klikkrate), Økt (GA4), Kanonisk URL

CTR (klikkrate)

CTR er klikk delt på visninger, vist som en prosentandel for hele nettstedet eller for ett søkeord, én side, ett land eller én enhet.

CTR avhenger sterkt av posisjon og av hvilken type resultat som vises, så sammenlign den mellom søkeord eller sider på lignende posisjoner i stedet for mot et fast mål. Den avhenger også av aggregering: når flere av sidene dine vises for ett søk, er CTR gruppert per nettsted generelt høyere enn CTR gruppert per side, fordi nettstedet får én visning og beholder klikket. Hvis visningene holder seg stabile mens klikkene faller, foreslår Google at du sjekker om tittelen og utdraget fortsatt beskriver siden godt.

I GSC Magic: report_ctr_outliers lister sider der CTR er under halvparten av nettstedets median-CTR på samme posisjon.

Relatert: Klikk, Visninger, CTR-avvik (side med lav CTR), Gjennomsnittlig posisjon

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

Gjennomsnittlig posisjon

Gjennomsnittlig posisjon er gjennomsnittet av den øverste posisjonen nettstedet eller siden din hadde i Google-resultatene, og telles bare for søk der den fikk en visning.

Hvis ett søk viser nettstedet ditt på posisjon 2, 4 og 6 og et annet på 3, 5 og 9, teller Search Console 2 og 3 og rapporterer et gjennomsnitt på 2,5. Hvert resultatelement opptar én posisjon: alle lenker i et kunnskapspanel eller en AI-oversikt deler elementets posisjon, og annonser opptar ingen posisjon. Et resultat som aldri ble sett, for eksempel på side 3, registrerer ingen posisjon, og derfor viser noen celler en strek. Posisjon beregnes bare for Google Søk, ikke for Discover eller Nyheter, og ditt eget søk kan vise en annen rangering fordi resultatene avhenger av sted og historikk. Google anbefaler å følge endringer over tid i stedet for å lese en enkelt verdi.

I GSC Magic: report_quick_wins bruker gjennomsnittlig posisjon til å finne søkeord- og sidepar som rangerer fra 4 til 20 med mange visninger.

Relatert: Visninger, Striking distance-søkeord (raske gevinster), AI-oversikter og AI-modus, Kjerneoppdatering

Søkeord

Et søkeord er søket som førte til at nettstedet ditt dukket opp i Google-resultatene; i Ytelsesrapporten grupperes klikk og visninger etter det.

Søkeordstabellen er aldri komplett. Noen søk skjules av personvernhensyn (anonymiserte søk), og på grunn av interne grenser lagrer og viser Search Console bare de viktigste radene. Søkefiltre skiller ikke mellom store og små bokstaver. For søketypen Web: multimodal, som søk med Google Lens, finnes det ingen tekstlig søkeforespørsel, så dimensjonen mangler. Les mer om hvorfor Search Console skjuler noen søk.

I GSC Magic: gsc_query_analytics returnerer opptil 25 000 søkeordrader per forespørsel gjennom Search Analytics API.

Relatert: Anonymiserte søk, Grensen på 1 000 rader, Søkeord med og uten merkevare, Side (dimensjon)

Side (dimensjon)

Dimensjonen Side grupperer ytelsesdata etter URL-en et søkeresultat lenket til etter omdirigeringer, vanligvis tilskrevet sidens kanoniske URL.

Når en bruker klikker på en duplikat-URL, tilskriver Search Console klikket til den kanoniske URL-en Google valgte, som du kan sjekke med URL-inspeksjonen. Å velge fanen Sider bytter tabellaggregeringen fra nettsted til side, så hver URL som vises for et søk, får sin egen visning. Diagrammet forblir aggregert per nettsted, og det er den vanlige årsaken til at tabellsummen og diagramsummen er ulike.

Relatert: Kanonisk URL, URL-inspeksjon, Søkeord, Visninger

Utseende i søk

Utseende i søk er en dimensjon i Ytelsesrapporten som grupperer data etter resultattypen eller funksjonen siden din viste seg i, for eksempel omtaleutdrag, videoer eller produktoppføringer.

Filteret lister bare typer der nettstedet ditt har registrert visninger. Gruppering etter utseende i søk aggregerer tabellen per side. Klikk tilskrives en URL, ikke en URL pluss en funksjon, så et filtrert klikktall kan inneholde klikk på en vanlig lenke til samme side. Noen eldre typer, som FAQ- og How-to-resultater, er oppført av Google som utgåtte.

I GSC Magic: gsc_query_analytics kan gruppere eller filtrere ytelsesdata etter utseende i søk.

Relatert: Strukturerte data og berikede resultater, Søketype, Side (dimensjon)

Kilder: support.google.com

Søketype

Søketype er filteret i Ytelsesrapporten som skiller trafikk fra Web (tekstbasert eller multimodal), Bilder, Video og Nyheter i Google Søk.

Web: tekstbasert dekker søk skrevet inn i den vanlige søkelinjen; Web: multimodal dekker søk gjort med bilder, inkludert Google Lens, Circle to Search og bildesøk i Chrome. Bilder, Video og Nyheter dekker de tilsvarende fanene. Discover og Google Nyheter har egne ytelsesrapporter. Google anbefaler å analysere søketyper hver for seg når du undersøker et fall, og API-ens radgrense gjelder per søketype.

Relatert: Utseende i søk, Grensen på 1 000 rader, Kjerneoppdatering

Land og enhet

I Ytelsesrapporten grupperer Land data etter hvor søket kom fra, og Enhet etter datamaskin, mobil eller nettbrett.

Begge dimensjonene aggregeres per nettsted. Google oppgir at forespørsler uten dimensjonene søkeord eller side, som land, enheter og utseende i søk, vises og eksporteres i sin helhet, og dermed ikke påvirkes av den daglige radgrensen. Sammenligning av datamaskin og mobil kan vise en strek for posisjon når en side ikke hadde visninger på én enhet.

I GSC Magic: gsc_query_analytics godtar land og enhet som dimensjoner og filtre.

Relatert: Grensen på 1 000 rader, Gjennomsnittlig posisjon, Søkeord

Dataferskhet og foreløpige data

Dataferskhet er hvor raskt Search Console viser ytelsesdata; de nyeste tallene kan være foreløpige og fortsatt under innsamling, og tegnes med en stiplet linje.

24-timersvisningen viser de siste tilgjengelige 24 timene med noen timers forsinkelse, i timepunkter og i nettleserens tidssone. Andre visninger bruker stillehavstid og viser komplette dager som standard. I Search Analytics API returnerer dataState "final" (standard) bare ferdigstilte data, mens "all" inkluderer ferske data og "hourly_all" legger til timefordelingen. Googles API-veiledning oppgir at data vanligvis er tilgjengelige etter 2 til 3 dager.

I GSC Magic: Den hostede synkroniseringen oppdaterer de siste fire dagene hver sjette time, fordi Google reviderer nylige tall.

Relatert: 16 måneders datalagring, Klikk, Visninger

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

Anonymiserte søk

Anonymiserte søk er søk Search Console holder utenfor tabellene for å beskytte personvernet, fordi de ikke ble utført av mer enn noen få dusin brukere over to til tre måneder.

De telles fortsatt med i diagramsummene med mindre du bruker et søkefilter, så summen av tabellradene er vanligvis lavere enn totalen. Filtre fjerner dem helt: søk som inneholder et ord, pluss søk som ikke inneholder det, blir til sammen mindre enn den ufiltrerte totalen. Se hvorfor Search Console skjuler noen søk.

I GSC Magic: GSC Magic leser det samme Search Analytics API-et og kan derfor heller ikke hente anonymiserte søk.

Relatert: Søkeord, Grensen på 1 000 rader, Søkeord med og uten merkevare

Grensen på 1 000 rader

Search Console-grensesnittet viser og eksporterer høyst 1 000 rader per tabell; Search Analytics API returnerer opptil 25 000 rader per forespørsel, med paginering.

Google oppgir at API-ens øvre grense er 50 000 rader per dag per nettsted per søketype, som ikke nødvendigvis nås i alle tilfeller. API-et returnerer 1 000 rader som standard; rowLimit hever dette til 25 000 og startRow går gjennom resten. Forespørsler uten dimensjonene søkeord eller side returnerer alle data. For den mest komplette søkeordlisten peker Google på bulkeksporten til BigQuery. Detaljer i grensen på 1 000 rader forklart og guiden til Search Console API.

I GSC Magic: gsc_query_analytics ber om opptil 25 000 rader per søk, så en AI-agent jobber med langt mer enn grensesnittets 1 000 rader.

Relatert: Søkeord, Anonymiserte søk, 16 måneders datalagring, Søketype

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

16 måneders datalagring

Ytelsesrapporten i Search Console dekker de siste 16 månedene; eldre dager faller ut med mindre du kopierer dataene et annet sted via API-et eller bulkeksporten.

Seksten måneder er nok til å sammenligne et nylig fall med de samme ukene året før, som er kontrollen Google foreslår for sesongvariasjon. For lengre sammenligninger foreslår Google å hente data med Search Analytics API eller bulkeksport og lagre dem i egne systemer. Se 3 måter å beholde Search Console-data utover 16 måneder og hvordan GSC Magic lagrer historikk.

I GSC Magic: Pro og Agency etterfyller opptil 16 måneder ved oppgradering og sletter aldri lagret historikk; Free beholder 14 dager.

Relatert: Sesongvariasjon, Grensen på 1 000 rader, Innholdsforfall

Gjennomsøking og indeksering

Gjennomsøking og Googlebot

Gjennomsøking er hvordan Google oppdager og laster ned sider; Googlebot er gjennomsøkeren til Google Søk, med en smarttelefon- og en datamaskinversjon.

Google finner nye URL-er hovedsakelig gjennom lenker fra sider den allerede kjenner, og gjennom områdekart, og henter dem deretter og kjører JavaScript med en nyere versjon av Chrome. Fordi Google først og fremst indekserer mobilversjonen av de fleste nettsteder, kommer de fleste forespørslene fra Googlebot Smartphone. For Google Søk henter Googlebot de første 2 MB av en støttet filtype (64 MB for PDF-er). Å blokkere gjennomsøking med robots.txt hindrer ikke en URL i å vises i resultatene; bruk noindex til det. Rapporten Gjennomsøkingsstatistikk viser antall forespørsler, svarkoder og tilgjengelighetsproblemer. Google tar ikke betalt for å gjennomsøke et nettsted oftere.

I GSC Magic: GSC Magic gjennomsøker ikke nettstedet ditt; den leser Googles URL-inspeksjonsdata og Bings gjennomsøkingsstatistikk og gjennomsøkingsproblemer.

Relatert: Indeksering, Gjennomsøkingsbudsjett (crawl budget), robots.txt, XML-områdekart

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

Indeksering

Indeksering er trinnet der Google analyserer en gjennomsøkt side og lagrer den i Google-indeksen; bare indekserte sider kan vises i Google Søk.

Google Søk fungerer i tre trinn: gjennomsøking, indeksering og visning av resultater, og ikke hver side kommer gjennom alle trinnene. Google garanterer ikke å indeksere en side selv om den følger Search Essentials. Rapporten Sideindeksering forklarer hvorfor URL-er ikke er indeksert, for eksempel «Gjennomsøkt – foreløpig ikke indeksert» (gjennomsøkt, kan bli indeksert senere, ingen grunn til å sende inn på nytt) eller «Oppdaget – foreløpig ikke indeksert» (funnet, men gjennomsøkingen ble planlagt på nytt for å unngå å overbelaste nettstedet). Se ikke indeksert i Search Console: årsaker og løsninger.

I GSC Magic: report_index_health leser URL-ene i områdekartene dine, inspiserer dem med URL Inspection API og grupperer dem etter dekningsstatus.

Relatert: Gjennomsøking og Googlebot, URL-inspeksjon, noindex, Kanonisk URL

Gjennomsøkingsbudsjett (crawl budget)

Gjennomsøkingsbudsjettet er mengden URL-er Google kan og vil gjennomsøke på et nettsted, styrt av to faktorer: grensen for gjennomsøkingskapasitet og etterspørselen etter gjennomsøking.

Grensen for gjennomsøkingskapasitet hindrer Googlebot i å overbelaste serveren din; etterspørselen etter gjennomsøking avhenger av nettstedets størrelse, oppdateringsfrekvens, sidekvalitet og relevans. Hvert vertsnavn har sitt eget gjennomsøkingsbudsjett. Google sier veiledningen hovedsakelig er for svært store nettsteder (rundt 1 million sider eller mer som endres ukentlig), nettsteder med 10 000 sider eller mer som endres daglig, eller nettsteder med mange URL-er i «Oppdaget – foreløpig ikke indeksert». Hvis nye sider gjennomsøkes samme dag de publiseres, er ikke gjennomsøkingsbudsjettet problemet ditt.

Relatert: Gjennomsøking og Googlebot, XML-områdekart, Indeksering

Kanonisk URL

En kanonisk URL er URL-en Google velger som den mest representative fra et sett med duplikatsider; det er versjonen som vanligvis vises i søkeresultatene.

Duplikater kommer fra HTTP- og HTTPS-versjoner, mobil- og datamaskin-URL-er, sorterings- og filterparametere eller regionale varianter. Du kan uttrykke en preferanse med rel="canonical", omdirigeringer og områdekart, men Google behandler det som et hint, ikke en regel, og kan velge en annen URL. Search Console tilskriver klikk og visninger til den kanoniske URL-en. Sammenlign den brukerdeklarerte og den Google-valgte kanoniske URL-en i URL-inspeksjonen.

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

Relatert: Omdirigering (301 mot 302), Side (dimensjon), URL-inspeksjon, hreflang

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

noindex

noindex er en regel, satt med en robots-metatagg eller en X-Robots-Tag HTTP-header, som ber Google fjerne en side fra søkeresultatene.

Google må gjennomsøke siden for å se regelen, så siden må ikke blokkeres av robots.txt; ellers kan den fortsatt vises i resultater hvis andre sider lenker til den. Google støtter ikke noindex i robots.txt. Etter at du legger til regelen, blir en side i resultatene til Google gjennomsøker den på nytt, noe som kan ta måneder for mindre viktige sider. Hvis robots.txt blokkerer siden, rapporterer URL-inspeksjonen at indeksering er tillatt, fordi Google ikke kan se noindex-regelen.

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

Relatert: robots.txt, Indeksering, URL-inspeksjon

robots.txt

robots.txt er en fil i roten av et nettsted som forteller gjennomsøkere hvilke URL-er de har tilgang til; den styrer gjennomsøking, ikke om en side blir indeksert.

Google beskriver den som en måte å administrere gjennomsøkertrafikk på og unngå å overbelaste serveren. En side som blokkeres av robots.txt, kan fortsatt indekseres uten beskrivelse hvis andre sider lenker til den, så bruk noindex eller passordbeskyttelse for å holde en side ute av Google. Ikke blokker CSS- eller JavaScript-filer Google trenger for å forstå siden.

I GSC Magic: Dashbordet kjører en rask gjennomgang av robots.txt og områdekart for hvert nettsted.

Relatert: noindex, Gjennomsøking og Googlebot, XML-områdekart

XML-områdekart

Et XML-områdekart er en fil som lister opp sidene, bildene, videoene og andre filene på nettstedet ditt, slik at søkemotorer kan finne og gjennomsøke dem mer effektivt.

Et områdekart kan også inneholde siste endringsdato og alternative språkversjoner. Det hjelper oppdagelsen, men garanterer ikke gjennomsøking eller indeksering. Google sier at små, godt lenkede nettsteder (omtrent 500 sider eller færre) kanskje ikke trenger ett, mens store, nye eller medietunge nettsteder har mest nytte av det. For mange nye eller endrede URL-er anbefaler Google å sende inn et områdekart i stedet for å be om indeksering én URL om gangen. Se områdekart sendt inn, men sidene er ikke indeksert.

I GSC Magic: gsc_list_sitemaps viser status og feil, gsc_submit_sitemap sender inn ett (Pro og Agency), og bing_submit_sitemap sender det til Bing.

Relatert: Gjennomsøking og Googlebot, Indeksering, robots.txt, IndexNow

URL-inspeksjon

URL-inspeksjon er Search Console-verktøyet som viser Googles indekserte versjon av en URL, hvorfor den er eller ikke er indeksert, og som kan sanntidsteste en side.

Den rapporterer indekseringsstatus, den Google-valgte kanoniske URL-en, siste gjennomsøking, strukturerte data som ble funnet, og et skjermbilde av den renderte siden. Sanntidstesten sjekker om en side kan være indekserbar, men kan ikke forutsi hvilken URL Google vil behandle som kanonisk. URL Inspection API returnerer bare den indekserte versjonen, har ingen sanntidstest og tillater 2 000 inspeksjoner per nettsted per dag. Se slik inspiserer du 500 URL-er med API-et.

I GSC Magic: gsc_inspect_url inspiserer én URL, og gsc_inspect_urls_batch inspiserer opptil 500 i ett kall innenfor Googles kvote.

Relatert: Be om indeksering, Indeksering, Kanonisk URL, Soft 404

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

Be om indeksering

Be om indeksering er en knapp i URL-inspeksjonen som ber Google gjennomsøke én enkelt URL; den garanterer ikke at siden blir indeksert.

Du må være eier eller full bruker av eiendommen. Det finnes en kvote for enkeltforespørsler, og å be om samme URL flere ganger gjør ikke gjennomsøkingen raskere. Gjennomsøking kan ta fra noen dager til noen uker. For mange URL-er anbefaler Google å sende inn et områdekart i stedet. Googles eget Indexing API er offisielt begrenset til sider med JobPosting- eller BroadcastEvent-markup. Se IndexNow mot Googles Indexing API.

I GSC Magic: Det valgfrie verktøyet gsc_request_indexing bruker Googles Indexing API, som Google bare støtter for JobPosting- og BroadcastEvent-sider.

Relatert: URL-inspeksjon, XML-områdekart, IndexNow, Indeksering

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

Soft 404

En soft 404 er en side som returnerer en 200-suksesskode, men som ser ut som en feilside eller tom side for Google, som rapporterer den og ikke indekserer den.

Google anbefaler å returnere statuskoden 404 for sider som virkelig ikke finnes, og å legge til mer informasjon på sider som skal bestå, slik at de ikke ser ut som feil. For å se hva Google ser, kjør en sanntidstest i URL-inspeksjonen og åpne skjermbildet av den renderte siden.

Relatert: URL-inspeksjon, Indeksering, Omdirigering (301 mot 302)

Omdirigering (301 mot 302)

En omdirigering sender besøkende og gjennomsøkere fra én URL til en annen; en 301 er permanent og signaliserer at målet bør være kanonisk, en 302 er midlertidig.

Med permanente omdirigeringer (301, 308, umiddelbar meta refresh) viser Google vanligvis mål-URL-en i resultatene. Med midlertidige (302, 303, 307) følger Google omdirigeringen, men bruker den ikke som kanonisk signal, så kilde-URL-en kan bli stående i resultatene. Omdirigeringer på serversiden er de mest pålitelige; Googles gjennomsøkere følger opptil 10 hopp som standard. Search Console tilskriver klikk til den endelige URL-en etter omdirigeringer.

Relatert: Kanonisk URL, Soft 404, Side (dimensjon)

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

hreflang

hreflang er en annotering som forteller Google hvilke sider som er språk- eller regionvarianter av samme innhold, slik at brukerne kan få den riktige.

Du kan deklarere den i HTML-lenketagger, HTTP-headere eller områdekartet; de tre metodene er likeverdige. Hver versjon må liste seg selv og alle andre versjoner, med fullstendige URL-er. Google bruker ikke hreflang til å oppdage språket på en side. Sider på samme språk for ulike regioner er duplikater, så Google anbefaler å kombinere hreflang med kanonisering.

Relatert: Kanonisk URL, XML-områdekart, Land og enhet

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

Strukturerte data og berikede resultater

Strukturerte data er et standardisert format, hovedsakelig med schema.org-vokabular og ofte skrevet som JSON-LD, som beskriver innholdet på en side for Google og kan gjøre den kvalifisert for berikede resultater.

Berikede resultater er søkeresultater med forbedret visning, som vurderingsstjerner, oppskriftsdetaljer eller produktpriser. En side trenger alle obligatoriske egenskaper for å være kvalifisert, og markup som bryter Googles retningslinjer for strukturerte data, kan gjøre den ikke-kvalifisert. Google foreslår å teste markup med Rich Results Test under utviklingen og følge rapportene om berikede resultater i Search Console etter utrulling. Typer berikede resultater vises også i dimensjonen utseende i søk.

I GSC Magic: gsc_inspect_url rapporterer de berikede resultatene Google oppdaget på en URL.

Relatert: Utseende i søk, URL-inspeksjon, CTR (klikkrate)

Core Web Vitals og sidehastighet

Core Web Vitals

Core Web Vitals er tre Google-måltall for den faktiske brukeropplevelsen: Largest Contentful Paint (lasting), Interaction to Next Paint (respons) og Cumulative Layout Shift (visuell stabilitet).

Gode terskler er LCP innen 2,5 sekunder, INP på 200 millisekunder eller mindre og CLS på 0,1 eller mindre, målt ved 75. persentil av sidevisninger, separat for mobil og datamaskin. En side består når alle tre møter målet. Google sier at gode Core Web Vitals stemmer med det kjernerangeringssystemene belønner, som en del av sideopplevelsen. Core Web Vitals-rapporten i Search Console viser hvordan sidene dine presterer.

I GSC Magic: cwv_get_origin, cwv_get_url og cwv_history leser Core Web Vitals fra reelle brukere, og dashbordet viser et Core Web Vitals-kort per nettsted.

Relatert: 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 lasting: tiden til det største bildet, den største tekstblokken eller videoen i visningsområdet er rendret. Bra er 2,5 sekunder eller mindre.

LCP måles fra brukeren først navigerte til siden, så den inkluderer servertid, omdirigeringer og oppsett av tilkoblingen. Bruk 75. persentil av sidevisninger, delt på mobil og datamaskin, for å vurdere om de fleste besøkende får en god opplevelse.

I GSC Magic: cwv-verktøyene returnerer LCP ved 75. persentil med andelen gode sidevisninger, sidevisninger som kan forbedres, og dårlige sidevisninger.

Relatert: 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 respons: hvor lang tid siden bruker på å svare synlig på klikk, trykk og tastetrykk. Bra er 200 millisekunder eller mindre, dårlig over 500.

INP observerer ventetiden for alle interaksjoner i et besøk og rapporterer omtrent den tregeste, uten å regne med avvikende enkeltverdier. Den erstattet First Input Delay (FID), som bare målte inndataforsinkelsen for den første interaksjonen. Lange JavaScript-oppgaver på hovedtråden er en vanlig årsak til dårlig INP.

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

Kilder: web.dev

CLS (Cumulative Layout Shift)

CLS måler visuell stabilitet: den største bygen av uventede layoutforskyvninger i løpet av en sides levetid. Bra er 0,1 eller mindre, dårlig er over 0,25.

En layoutforskyvning skjer når et synlig element flytter seg mellom rendrede bilder uten brukerinput, for eksempel når et bilde uten angitte dimensjoner eller en sen annonse skyver teksten ned. Forskyvninger mindre enn ett sekund fra hverandre grupperes i et øktvindu, og det største vinduet er CLS-scoren.

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

Kilder: web.dev

CrUX (Chrome UX Report)

CrUX er Googles offentlige datasett over hvordan ekte Chrome-brukere opplever nettsteder, og kilden til feltdata bak Core Web Vitals i Googles verktøy.

Et opphav (origin) og enkeltsider er bare med hvis de er offentlig oppdagbare og har nok besøkende til en statistisk signifikant prøve, så mange sider med lav trafikk har ingen data. Google Søk bruker CrUX til å informere rangeringsfaktoren for sideopplevelse. PageSpeed Insights viser CrUX som feltdata og faller tilbake til data på opphavsnivå når en side har for få prøver.

I GSC Magic: cwv-verktøyene spør CrUX om et opphav eller en URL; sider uten nok Chrome-trafikk returnerer ingen data.

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

Kilder: developer.chrome.com

PageSpeed Insights og Lighthouse

PageSpeed Insights rapporterer CrUX-feltdata for en side og kjører Lighthouse, et verktøy med åpen kildekode som reviderer ytelse, tilgjengelighet, beste praksis og SEO i et simulert laboratorium.

Feltdata viser hva ekte besøkende opplevde over tid; labdata fra Lighthouse er én kontrollert kjøring som er nyttig for feilsøking, men kan overse virkelige flaskehalser. Core Web Vitals-vurderingen i PSI bruker feltdata: en side eller et opphav består når 75. persentil av LCP, INP og CLS er god. Lighthouse kjører også i Chrome DevTools, fra kommandolinjen eller som en Node-modul.

I GSC Magic: psi_run_audit kjører Lighthouse gjennom PageSpeed Insights, og Core Web Vitals-kortet i dashbordet kan starte en gjennomgang.

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

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

SEO-analyse

Striking distance-søkeord (raske gevinster)

Striking distance-søkeord er søk der en side allerede rangerer like utenfor de øverste resultatene, ofte posisjon 4 til 20, med nok visninger til å vinne klikk.

Dette er et SEO-faguttrykk, ikke et måltall i Search Console. Den vanlige metoden: filtrer Ytelsesrapporten etter søkeord og side, behold rader med gjennomsnittlig posisjon like under topplasseringene og meningsfulle visninger, og forbedre deretter den eksisterende siden i stedet for å skrive en ny. Husk at gjennomsnittlig posisjon er et gjennomsnitt, så sjekk trenden. Se slik finner du striking distance-søkeord og 7 raske SEO-gevinster.

I GSC Magic: report_quick_wins returnerer søkeord- og sidepar på posisjon 4 til 20 med mange visninger, sortert etter potensielle ekstra klikk.

Relatert: Gjennomsnittlig posisjon, Visninger, CTR-avvik (side med lav CTR)

Kilder: support.google.com

Kannibalisering av søkeord

Kannibalisering av søkeord er når to eller flere sider på nettstedet ditt konkurrerer om samme søk og deler visninger og klikk, i stedet for at én side rangerer godt.

Det er et SEO-faguttrykk, ikke et Google-uttrykk. I Search Console vises det som ett søkeord med visninger spredt over flere URL-er, noen ganger med vekslende plasseringer over tid. Ikke all overlapp er et problem: ulike intensjoner kan fortjene ulike sider, og merkevaresøk viser ofte mange URL-er. Vanlige tiltak er å slå sammen sider med en 301-omdirigering, skille intensjonene eller justere interne lenker. Se kannibalisering av søkeord i Search Console.

I GSC Magic: report_cannibalization lister søkeord der to eller flere av sidene dine hver får en meningsfull andel av visningene.

Relatert: Søkeord, Side (dimensjon), Kanonisk URL, Omdirigering (301 mot 302)

Kilder: support.google.com

Innholdsforfall

Innholdsforfall er en gradvis, vedvarende nedgang i en sides klikk fra søk over flere måneder, i motsetning til et plutselig fall fra et teknisk problem eller en oppdatering.

Det er et SEO-faguttrykk. Typiske årsaker er utdatert informasjon, nyere konkurrerende sider eller endret søkeinteresse. Å sammenligne flere påfølgende perioder skiller en jevn nedgang fra én dårlig uke; å sjekke de samme månedene året før utelukker sesongvariasjon. Se slik oppdager du innholdsforfall.

I GSC Magic: report_content_decay lister sider der klikkene falt i hvert av de tre siste vinduene (28 dager hver som standard).

Relatert: Sesongvariasjon, 16 måneders datalagring, Kjerneoppdatering

CTR-avvik (side med lav CTR)

Et CTR-avvik er en side eller et søkeord der klikkraten ligger klart under hva andre resultater på samme posisjon på nettstedet ditt får.

Fordi CTR faller med posisjonen, betyr lav CTR bare noe når den sammenlignes på lignende posisjoner. Avvik har ofte en tittel eller et utdrag som ikke samsvarer med søket, eller konkurrerer med et beriket resultat eller en AI-oversikt på samme resultatside. Google foreslår å gå gjennom tittel og utdrag når visningene holder seg men klikkene faller. Se søkeord med lav CTR i Search Console.

I GSC Magic: report_ctr_outliers flagger sider der CTR er under halvparten av nettstedets median-CTR på samme posisjon.

Relatert: CTR (klikkrate), Gjennomsnittlig posisjon, Striking distance-søkeord (raske gevinster)

Søkeord med og uten merkevare

Søkeord med merkevare inneholder merkevarenavnet ditt, feilstavinger av det eller dine unike produkter; søkeord uten merkevare er alle andre søk som viser nettstedet ditt.

Søkeord med merkevare rangerer vanligvis høyere og får flere klikk, mens søkeord uten merkevare viser hvordan nye personer finner deg. Search Console har et filter for merkevaresøk i Ytelsesrapporten, klassifisert av et AI-assistert system og ikke av en søkeordliste. Google sier at det bare er tilgjengelig for eiendommer på toppnivå med nok søk og visninger, og at det kan feilklassifisere enkelte søk.

I GSC Magic: report_brand_split deler søkeord etter merkevaretermene du oppgir, og returnerer klikk, visninger og klikkandel for hver gruppe.

Relatert: Søkeord, CTR (klikkrate), Anonymiserte søk

Sesongvariasjon

Sesongvariasjon er en gjentakende økning eller nedgang i søkeetterspørselen til samme tid hvert år, som høytider, som endrer trafikken uten at rangeringen endres.

Googles veiledning om trafikkfall foreslår å sette Ytelsesrapporten til de siste 16 månedene for å se om fallet gjentar seg hvert år, og å sjekke toppsøk i Google Trends for å se om etterspørselen falt på hele nettet. Hvis visningene falt mens posisjonen holdt seg, er etterspørselen den sannsynlige årsaken. Se sesongvariasjon mot reelle tap av rangering.

I GSC Magic: Fordi Pro og Agency beholder lagret historikk utover 16 måneder, kan agenter sammenligne samme periode på tvers av mer enn ett år.

Relatert: 16 måneders datalagring, Innholdsforfall, Kjerneoppdatering

Kjerneoppdatering

En kjerneoppdatering er en betydelig, bred endring i Googles rangeringssystemer, gjort flere ganger i året og kunngjort på Googles liste over rangeringsoppdateringer.

Kjerneoppdateringer retter seg ikke mot bestemte nettsteder. Google anbefaler å vente til utrullingen er ferdig, og deretter sammenligne en hel uke etterpå med en uke før den begynte. Et lite fall, for eksempel fra posisjon 2 til 4, krever ingen drastiske tiltak; et stort, vedvarende fall krever en ærlig vurdering av hvor nyttig hele nettstedet er. Google påpeker at noen endringer slår inn i løpet av dager, andre i løpet av flere måneder. Se sjekklisten for fall i organisk trafikk.

I GSC Magic: report_traffic_drops sammenligner en periode med den forrige og lister sidene eller søkeordene som mistet eller vant flest klikk.

Relatert: Gjennomsnittlig posisjon, Sesongvariasjon, Søketype

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

Bing og IndexNow

Bing Webmaster Tools

Bing Webmaster Tools er Microsofts motstykke til Search Console: søkeytelse, gjennomsøkings- og indeksdata, innsending av URL-er og søkeordsresearch for Bing.

API-et gir programmatisk tilgang til trafikk- og rangeringstall, lenke- og søkeorddetaljer, gjennomsøkingsstatistikk og innsending av URL-er og områdekart. Search Performance viser 16 måneders historikk. AI Performance, lansert som offentlig forhåndsvisning i februar 2026, viser hvor ofte sidene dine siteres i Microsoft Copilot og Bings AI-genererte svar. Se guiden til Bing Webmaster Tools API og Bing Webmaster Tools i GSC Magic.

I GSC Magic: Med Bing API-nøkkelen din legger GSC Magic til Bing-verktøy for søkeord- og sidestatistikk, gjennomsøkingsdata, søkeordsresearch og innsending av URL-er, samt report_google_vs_bing.

Relatert: IndexNow, GEO (generative engine optimization), XML-områdekart

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

IndexNow

IndexNow er en åpen protokoll som lar et nettsted varsle deltakende søkemotorer, inkludert Bing, Naver, Seznam.cz, Yandex og Yep, umiddelbart om at en URL er lagt til, oppdatert eller slettet.

Du hoster en nøkkelfil på nettstedet ditt for å bevise eierskap, og sender deretter én URL eller en bunke til et IndexNow-endepunkt; en innsending deles med alle deltakende motorer. Et HTTP 200-svar betyr bare at URL-en ble mottatt, ikke at den blir indeksert. Google står ikke på listen over deltakende motorer. Se slik setter du opp IndexNow med en AI-agent.

I GSC Magic: indexnow_generate_key lager en nøkkel, og indexnow_submit sender opptil 10 000 URL-er per kall (Pro og Agency, med din IndexNow-nøkkel).

Relatert: Bing Webmaster Tools, Be om indeksering, XML-områdekart

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

Google Analytics 4

Økt (GA4)

I Google Analytics 4 er en økt en periode der en bruker er i kontakt med nettstedet eller appen din; på nettet avsluttes den etter 30 inaktive minutter som standard.

En økt starter når noen åpner appen eller ser en side mens ingen økt er aktiv, og GA4 logger en session_start-hendelse. Det finnes ingen maksimal lengde, og tidsavbruddet kan endres i innstillingene for datastrømmen. Økter er ikke det samme som klikk i Search Console, se hvorfor tallene ikke stemmer og GA4 i GSC Magic.

I GSC Magic: ga_run_report spør skrivebeskyttet om GA4-økter, etter hvilken som helst dimensjon, som landingsside eller øktkilde.

Relatert: Klikk, Nøkkelhendelse (GA4), Henvisningstrafikk, Trafikk fra AI-assistenter

Kilder: support.google.com

Nøkkelhendelse (GA4)

En nøkkelhendelse er en GA4-hendelse du markerer som viktig for virksomheten din, for eksempel et kjøp eller en registrering; nøkkelhendelser ble tidligere kalt konverteringer i Analytics.

Enhver innsamlet hendelse kan merkes som en nøkkelhendelse. Google bruker nå «konvertering» om handlinger som måles for Google Ads-kampanjer og budgivning, så antall konverteringer og nøkkelhendelser kan avvike.

I GSC Magic: ga_list_key_events lister nøkkelhendelsene som er konfigurert på en GA4-eiendom.

Relatert: Økt (GA4), Henvisningstrafikk

Kilder: support.google.com

Henvisningstrafikk

I GA4 er Henvisning standardkanalen for besøkende som kommer via lenker som ikke er annonser på andre nettsteder eller i apper, som blogger og nyhetssider.

GA4 plasserer økter i standardkanaler ved hjelp av kilde og medium. Organiske søkeresultater, inkludert Googles AI-oversikter og AI-modus, går til Organisk søk, og anerkjente AI-assistenter har sin egen kanal, AI Assistant. Direkte dekker besøk fra en lagret lenke eller en skrevet URL.

Relatert: Trafikk fra AI-assistenter, Økt (GA4), Nøkkelhendelse (GA4)

Kilder: support.google.com

Trafikk fra AI-assistenter

Trafikk fra AI-assistenter er besøk fra lenker i chatassistenter som ChatGPT, Gemini, Claude eller Copilot, som GA4 grupperer i kanalen AI Assistant når den kjenner igjen henviseren.

Siden mai 2026 setter GA4 mediumet til ai-assistant og kanalen til AI Assistant når henviseren samsvarer med en anerkjent assistent; kanalen utelukker Googles AI-oversikter og AI-modus, som telles som Organisk søk. Kanalen avhenger av henviseren, så assistentbesøk som kommer uten en henviser, telles ikke der. Trafikk er ikke det samme som siteringer. Se slik sporer du trafikk fra ChatGPT og Perplexity i GA4.

I GSC Magic: Dashbordet teller GA4-økter fra AI-assistentkilder som ChatGPT, Perplexity, Claude og Gemini; det måler besøk, ikke siteringer.

Relatert: Henvisningstrafikk, Økt (GA4), GEO (generative engine optimization), AI-oversikter og AI-modus