Ordlista för Google Search Console och SEO

Klick

Ett klick räknas när en användare klickar på ett resultat i Google Search, Discover eller Nyheter som tar dem till en sida utanför Google.

Klick som håller kvar användaren inom Google, till exempel en förfining av sökningen som startar en ny sökning, räknas inte. Att klicka på ett resultat, gå tillbaka och klicka på samma länk igen räknas en gång; att klicka på en annan länk räknas igen. Klickdata krediteras den kanoniska URL som Google valde, inte nödvändigtvis den URL användaren landade på. Klick i Search Console och sessioner i GA4 mäter olika saker och matchar sällan, se GSC-klick vs GA4-sessioner.

I GSC Magic: Dashboardens översikt visar dagliga klick och ett kort med de främsta sökfrågorna och sidorna, med förändringen i klick mot föregående period.

Relaterat: Visningar, CTR (klickfrekvens), Session (GA4), Kanonisk URL

CTR (klickfrekvens)

CTR är klick delat med visningar, visat i procent för hela webbplatsen eller för en enskild sökfråga, sida, land eller enhet.

CTR beror starkt på position och på vilken typ av resultat som visas, så jämför den mellan sökfrågor eller sidor på liknande positioner i stället för mot ett enda målvärde. Den beror också på aggregeringen: när flera av dina sidor visas för en sökfråga är CTR grupperat per webbplats oftast högre än CTR grupperat per sida, eftersom webbplatsen får en visning och behåller klicket. Om visningarna står stilla men klicken faller föreslår Google att du kontrollerar om titel och utdrag fortfarande beskriver sidan väl.

I GSC Magic: report_ctr_outliers listar sidor vars CTR ligger under hälften av webbplatsens median-CTR på samma position.

Relaterat: Klick, Visningar, CTR-avvikelse (sida med låg CTR), Genomsnittlig position

Källor: support.google.com, support.google.com, developers.google.com

Genomsnittlig position

Genomsnittlig position är medelvärdet av den högsta position din webbplats eller sida hade i Googles sökresultat, räknat bara för sökningar där den fick en visning.

Om en sökfråga visar din webbplats på positionerna 2, 4 och 6 och en annan på 3, 5 och 9, räknar Search Console 2 och 3 och rapporterar ett medelvärde på 2,5. Varje resultatelement upptar en position: alla länkar i en kunskapspanel eller en AI Overview delar elementets position, och annonser upptar ingen position. Ett resultat som aldrig sågs, till exempel på sidan 3, registrerar ingen position, vilket är varför vissa celler visar ett streck. Positionen beräknas bara för Google Search, inte Discover eller Nyheter, och din egen sökning kan visa en annan placering eftersom resultaten beror på plats och historik. Google rekommenderar att du följer förändringar över tid i stället för att läsa ett enskilt värde.

I GSC Magic: report_quick_wins använder genomsnittlig position för att hitta sökfråge- och sidpar som rankar 4 till 20 med många visningar.

Relaterat: Visningar, Striking distance-sökord (snabba vinster), AI Overviews och AI Mode, Core-uppdatering

Sökfråga

En sökfråga är en sökterm som ledde till att din webbplats visades i Googles resultat; fliken Sökfrågor i Prestandarapporten grupperar klick och visningar per sökfråga.

Tabellen Sökfrågor är aldrig komplett. Vissa sökfrågor döljs av integritetsskäl (anonymiserade sökfrågor), och på grund av interna gränser lagrar och visar Search Console bara de viktigaste raderna. Sökfrågefilter är inte skiftkänsliga. För söktypen Webb: multimodal, som sökningar med Google Lens, finns ingen textsökfråga, så dimensionen saknas. Läs mer i varför Search Console döljer vissa sökfrågor.

I GSC Magic: gsc_query_analytics returnerar upp till 25 000 sökfrågerader per anrop via Search Analytics API.

Relaterat: Anonymiserade sökfrågor, Gränsen på 1 000 rader, Varumärkessökningar och icke-varumärkessökningar, Sida (dimension)

Sida (dimension)

Dimensionen Sida grupperar prestandadata per den URL ett sökresultat länkade till efter omdirigeringar, oftast krediterat sidans kanoniska URL.

När en användare klickar på en dubblett-URL krediterar Search Console klicket till den kanoniska URL som Google valde, vilken du kan kontrollera med verktyget URL-granskning. Fliken Sidor byter tabellaggregering från webbplats till sida, så varje URL som visas för en sökfråga får sin egen visning. Diagrammet är fortfarande aggregerat per webbplats, vilket är den vanliga orsaken till att tabellsumman och diagramsumman skiljer sig.

Relaterat: Kanonisk URL, URL-granskning, Sökfråga, Visningar

Sökutseende

Sökutseende är en dimension i Prestandarapporten som grupperar data per den resultattyp eller funktion din sida visades i, som recensionssnippets, videor eller produktlistningar.

Filtret listar bara de typer för vilka din webbplats har registrerat visningar. Gruppering per sökutseende aggregerar tabellen per sida. Klick kopplas till en URL, inte till en URL plus funktion, så ett filtrerat klickantal kan innehålla klick på en vanlig länk till samma sida. Vissa äldre typer, som FAQ- och How-to-rich results, är enligt Google utfasade.

I GSC Magic: gsc_query_analytics kan gruppera eller filtrera prestandadata per sökutseende.

Relaterat: Strukturerad data och rich results, Söktyp, Sida (dimension)

Källor: support.google.com

Söktyp

Söktyp är filtret i Prestandarapporten som skiljer trafik från Webb (textbaserad eller multimodal), Bilder, Video och Nyheter i Google Search.

Webb: textbaserad omfattar sökfrågor som skrivs i den vanliga sökrutan; Webb: multimodal omfattar sökningar med bilder, inklusive Google Lens, Circle to Search och bildsökning i Chrome. Bilder, Video och Nyheter motsvarar respektive flik. Discover och Google Nyheter har egna prestandarapporter. Google rekommenderar att analysera söktyper separat när du utreder ett tapp, och API:ets radgräns gäller per söktyp.

Relaterat: Sökutseende, Gränsen på 1 000 rader, Core-uppdatering

Land och enhet

I Prestandarapporten grupperar Land data per var sökningen kom ifrån och Enhet per dator, mobil eller surfplatta.

Båda dimensionerna aggregeras per webbplats. Google uppger att förfrågningar utan dimensionerna sökfråga eller sida, som länder, enheter och sökutseende, visas och exporteras i sin helhet och därför inte påverkas av den dagliga radgränsen. En jämförelse mellan dator och mobil kan visa ett streck för position när en sida inte hade några visningar på en av enheterna.

I GSC Magic: gsc_query_analytics accepterar land och enhet som dimensioner och filter.

Relaterat: Gränsen på 1 000 rader, Genomsnittlig position, Sökfråga

Datafärskhet och preliminära data

Datafärskhet är hur snabbt Search Console visar prestandadata; de nyaste siffrorna kan vara preliminära och fortfarande samlas in, och ritas med en streckad linje.

24-timmarsvyn visar de senaste tillgängliga 24 timmarna med några timmars fördröjning, i timpunkter och i webbläsarens tidszon. Övriga vyer använder Stillahavstid och visar kompletta dagar som standard. I Search Analytics API returnerar dataState ”final” (standard) bara färdigställda data, medan ”all” inkluderar färsk data och ”hourly_all” lägger till timuppdelningen. Googles API-guide noterar att data vanligtvis är tillgängliga efter 2 till 3 dagar.

I GSC Magic: Den hostade synkroniseringen uppdaterar de senaste fyra dagarna var sjätte timme, eftersom Google reviderar färska siffror.

Relaterat: 16 månaders datalagring, Klick, Visningar

Källor: support.google.com, developers.google.com, developers.google.com, developers.google.com

Anonymiserade sökfrågor

Anonymiserade sökfrågor är sökningar som Search Console utelämnar ur tabellerna för att skydda integriteten, eftersom de inte ställdes av mer än några dussin användare under två till tre månader.

De räknas ändå med i diagrammets summor om du inte använder ett sökfrågefilter, så summan av tabellraderna är oftast lägre än totalen. Filter utesluter dem helt: sökfrågor som innehåller ett ord plus sökfrågor som inte innehåller det summerar till mindre än den ofiltrerade totalen. Se varför Search Console döljer vissa sökfrågor.

I GSC Magic: GSC Magic läser samma Search Analytics API och kan därför inte heller återställa anonymiserade sökfrågor.

Relaterat: Sökfråga, Gränsen på 1 000 rader, Varumärkessökningar och icke-varumärkessökningar

Gränsen på 1 000 rader

Search Consoles gränssnitt visar och exporterar högst 1 000 rader per tabell; Search Analytics API returnerar upp till 25 000 rader per anrop, med sidindelning.

Google uppger att API:ets övre gräns är 50 000 rader per dag och webbplats och söktyp, vilket inte alltid nås. API:et returnerar 1 000 rader som standard; rowLimit höjer det till 25 000 och startRow bläddrar genom resten. Förfrågningar utan dimensionerna sökfråga eller sida returnerar all data. För den mest kompletta sökfrågelistan hänvisar Google till bulkdataexporten till BigQuery. Detaljer i gränsen på 1 000 rader förklarad och guiden till Search Console API.

I GSC Magic: gsc_query_analytics begär upp till 25 000 rader per sökfråga, så en AI-agent arbetar med långt fler än gränssnittets 1 000 rader.

Relaterat: Sökfråga, Anonymiserade sökfrågor, 16 månaders datalagring, Söktyp

Källor: developers.google.com, developers.google.com, support.google.com

16 månaders datalagring

Search Consoles Prestandarapport omfattar de senaste 16 månaderna; äldre dagar faller bort om du inte kopierar datan någon annanstans via API:et eller bulkdataexporten.

Sexton månader räcker för att jämföra ett aktuellt tapp med samma veckor året innan, vilket är kontrollen Google föreslår för säsongsvariation. För längre jämförelser föreslår Google att du hämtar data med Search Analytics API eller bulkdataexporter och lagrar dem i dina egna system. Se 3 sätt att behålla Search Console-data längre än 16 månader och hur GSC Magic lagrar historik.

I GSC Magic: Pro och Agency fyller på upp till 16 månader vid uppgradering och rensar aldrig lagrad historik; Free behåller 14 dagar.

Relaterat: Säsongsvariation, Gränsen på 1 000 rader, Innehållsförfall

Genomsökning och indexering

Genomsökning och Googlebot

Genomsökning är hur Google upptäcker och hämtar sidor; Googlebot är Googles crawler för Google Search, med en version för mobil och en för dator.

Google hittar nya URL:er främst via länkar från sidor den redan känner till och via sitemaps, hämtar dem sedan och renderar JavaScript med en aktuell version av Chrome. Eftersom Google i första hand indexerar mobilversionen av de flesta webbplatser kommer de flesta förfrågningarna från Googlebot Smartphone. För Google Search hämtar Googlebot de första 2 MB av en filtyp som stöds (64 MB för PDF:er). Att blockera genomsökning med robots.txt hindrar inte en URL från att visas i resultaten; använd noindex för det. Rapporten Genomsökningsstatistik visar antal förfrågningar, svarskoder och tillgänglighetsproblem. Google tar inte betalt för att genomsöka en webbplats oftare.

I GSC Magic: GSC Magic genomsöker inte din webbplats; det läser Googles URL-granskningsdata och Bings genomsökningsstatistik och genomsökningsproblem.

Relaterat: Indexering, Genomsökningsbudget, robots.txt, XML-sitemap

Källor: developers.google.com, developers.google.com, support.google.com

Indexering

Indexering är steget där Google analyserar en genomsökt sida och lagrar den i Googles index; bara indexerade sidor kan visas i Google Search.

Google Search fungerar i tre steg: genomsökning, indexering och visning av resultat, och inte alla sidor tar sig igenom varje steg. Google garanterar inte att en sida indexeras även om den följer Search Essentials. Rapporten Sidindexering förklarar varför URL:er inte indexeras, till exempel ”Genomsökt – inte indexerad för närvarande” (genomsökt, kan indexeras senare, ingen ny inskickning behövs) eller ”Upptäckt – inte indexerad för närvarande” (hittad, men genomsökningen schemalades om för att inte överbelasta webbplatsen). Se Search Console: inte indexerad – orsaker och åtgärder.

I GSC Magic: report_index_health läser URL:erna i dina sitemaps, granskar dem med URL Inspection API och grupperar dem per täckningsstatus.

Relaterat: Genomsökning och Googlebot, URL-granskning, noindex, Kanonisk URL

Genomsökningsbudget

Genomsökningsbudget är den uppsättning URL:er som Google kan och vill genomsöka på en webbplats, styrd av två faktorer: gränsen för genomsökningskapacitet och genomsökningsefterfrågan.

Gränsen för genomsökningskapacitet hindrar Googlebot från att överbelasta din server; genomsökningsefterfrågan beror på webbplatsens storlek, uppdateringsfrekvens, sidkvalitet och relevans. Varje värdnamn har sin egen genomsökningsbudget. Google säger att guiden om genomsökningsbudget främst gäller mycket stora webbplatser (runt 1 miljon sidor eller fler som ändras varje vecka), webbplatser med 10 000 sidor eller fler som ändras dagligen, eller webbplatser med många URL:er i ”Upptäckt – inte indexerad för närvarande”. Om nya sidor genomsöks samma dag de publiceras är genomsökningsbudgeten inte ditt problem.

Relaterat: Genomsökning och Googlebot, XML-sitemap, Indexering

Kanonisk URL

En kanonisk URL är den URL som Google väljer som mest representativ ur en uppsättning dubblettsidor; det är versionen som vanligtvis visas i sökresultaten.

Dubbletter kommer från HTTP- och HTTPS-versioner, mobil- och dator-URL:er, sorterings- och filterparametrar eller regionala varianter. Du kan ange en preferens med rel="canonical", omdirigeringar och sitemaps, men Google behandlar det som en antydan, inte en regel, och kan välja en annan URL. Search Console krediterar klick och visningar till den kanoniska URL:en. Jämför den användardeklarerade och den Google-valda kanoniska URL:en i verktyget URL-granskning.

I GSC Magic: gsc_inspect_url returnerar både den deklarerade och den Google-valda kanoniska URL:en för en URL.

Relaterat: Omdirigering (301 vs 302), Sida (dimension), URL-granskning, hreflang

Källor: developers.google.com, developers.google.com

noindex

noindex är en regel, satt med en robots-metatagg eller en X-Robots-Tag-HTTP-rubrik, som säger till Google att ta bort en sida från sökresultaten.

Google måste genomsöka sidan för att se regeln, så sidan får inte blockeras av robots.txt; annars kan den fortfarande visas i resultaten om andra sidor länkar till den. Google stöder inte noindex i robots.txt. När du har lagt till regeln ligger sidan kvar i resultaten tills Google genomsöker den igen, vilket kan ta månader för mindre viktiga sidor. Om robots.txt blockerar sidan rapporterar URL-granskning att indexering är tillåten, eftersom Google inte kan se noindex-regeln.

I GSC Magic: gsc_inspect_url och report_index_health visar när Google hittade en noindex-regel på en URL.

Relaterat: robots.txt, Indexering, URL-granskning

robots.txt

robots.txt är en fil i roten av en webbplats som talar om för crawlers vilka URL:er de får komma åt; den styr genomsökning, inte om en sida indexeras.

Google beskriver den som ett sätt att hantera crawler-trafik och undvika att överbelasta din server. En sida som blockeras av robots.txt kan fortfarande indexeras utan beskrivning om andra sidor länkar till den, så använd noindex eller lösenordsskydd för att hålla en sida borta från Google. Blockera inte CSS- eller JavaScript-filer som Google behöver för att förstå sidan.

I GSC Magic: Dashboarden kör en snabb granskning av robots.txt och sitemap för varje webbplats.

Relaterat: noindex, Genomsökning och Googlebot, XML-sitemap

XML-sitemap

En XML-sitemap är en fil som listar sidorna, bilderna, videorna och andra filerna på din webbplats så att sökmotorer lättare kan hitta och genomsöka dem.

En sitemap kan också innehålla senaste ändringsdatum och alternativa språkversioner. Den hjälper till att upptäcka innehåll men garanterar inte genomsökning eller indexering. Google säger att små webbplatser med bra länkning (cirka 500 sidor eller färre) kanske inte behöver någon, medan stora, nya eller medietunga webbplatser har mest nytta av en. För många nya eller ändrade URL:er rekommenderar Google att skicka in en sitemap i stället för att begära indexering en URL i taget. Se sitemap inskickad men sidorna indexeras inte.

I GSC Magic: gsc_list_sitemaps visar status och fel, gsc_submit_sitemap skickar in en (Pro och Agency), och bing_submit_sitemap skickar den till Bing.

Relaterat: Genomsökning och Googlebot, Indexering, robots.txt, IndexNow

URL-granskning

URL-granskning är Search Consoles verktyg som visar Googles indexerade version av en URL, varför den är eller inte är indexerad, och som kan testa en sida live.

Det rapporterar indexeringsstatus, den Google-valda kanoniska URL:en, senaste genomsökning, strukturerad data som hittats och en skärmbild av den renderade sidan. Livetestet kontrollerar om en sida kan vara indexerbar men kan inte förutsäga vilken URL Google kommer att behandla som kanonisk. URL Inspection API returnerar bara den indexerade versionen, har inget livetest och tillåter 2 000 granskningar per webbplats och dag. Se så granskar du 500 URL:er med API:et.

I GSC Magic: gsc_inspect_url granskar en URL och gsc_inspect_urls_batch granskar upp till 500 i ett anrop inom Googles kvot.

Relaterat: Begär indexering, Indexering, Kanonisk URL, Soft 404

Källor: support.google.com, developers.google.com, developers.google.com

Begär indexering

Begär indexering är en knapp i verktyget URL-granskning som ber Google genomsöka en enskild URL; den garanterar inte att sidan indexeras.

Du måste vara ägare eller fullständig användare av webbplatsen. Det finns en kvot för enskilda förfrågningar, och att begära samma URL flera gånger gör inte genomsökningen snabbare. Genomsökning kan ta från några dagar till några veckor. För många URL:er rekommenderar Google att skicka in en sitemap i stället. Googles separata Indexing API är officiellt begränsat till sidor med markup för JobPosting eller BroadcastEvent. Se IndexNow vs Google Indexing API.

I GSC Magic: Det valfria verktyget gsc_request_indexing använder Googles Indexing API, som Google bara stöder för sidor med JobPosting och BroadcastEvent.

Relaterat: URL-granskning, XML-sitemap, IndexNow, Indexering

Källor: developers.google.com, developers.google.com

Soft 404

En soft 404 är en sida som returnerar statuskoden 200 men ser ut som en felsida eller tom sida för Google, som rapporterar den och inte indexerar den.

Google rekommenderar att du returnerar statuskoden 404 för sidor som verkligen inte finns, och att lägga till mer information på sidor som ska finnas kvar så att de inte ser ut som fel. För att se vad Google ser, kör ett livetest i URL-granskning och öppna skärmbilden av den renderade sidan.

Relaterat: URL-granskning, Indexering, Omdirigering (301 vs 302)

Omdirigering (301 vs 302)

En omdirigering skickar besökare och crawlers från en URL till en annan; en 301 är permanent och signalerar att målet bör vara kanoniskt, en 302 är tillfällig.

Med permanenta omdirigeringar (301, 308, omedelbar metarefresh) visar Google vanligtvis mål-URL:en i resultaten. Med tillfälliga (302, 303, 307) följer Google omdirigeringen men använder den inte som kanonisk signal, så käll-URL:en kan ligga kvar i resultaten. Omdirigeringar på serversidan är mest tillförlitliga; Googles crawlers följer som standard upp till 10 hopp. Search Console krediterar klick till den slutliga URL:en efter omdirigeringar.

Relaterat: Kanonisk URL, Soft 404, Sida (dimension)

Källor: developers.google.com, developers.google.com

hreflang

hreflang är en annotering som talar om för Google vilka sidor som är språk- eller regionversioner av samma innehåll, så att rätt version kan visas för användaren.

Du kan deklarera den i HTML-länktaggar, HTTP-rubriker eller i sitemap-filen; de tre metoderna är likvärdiga. Varje version måste lista sig själv och alla andra versioner, med fullständiga URL:er. Google använder inte hreflang för att upptäcka en sidas språk. Sidor på samma språk för olika regioner är dubbletter, så Google rekommenderar att kombinera hreflang med kanonisering.

Relaterat: Kanonisk URL, XML-sitemap, Land och enhet

Källor: developers.google.com, developers.google.com

Strukturerad data och rich results

Strukturerad data är ett standardiserat format, oftast med schema.org-vokabulär och ofta skrivet som JSON-LD, som beskriver en sidas innehåll för Google och kan göra den valbar för rich results.

Rich results är sökresultat med förbättrad visning, som recensionsstjärnor, receptdetaljer eller produktpriser. En sida behöver alla obligatoriska egenskaper för att vara valbar, och markup som bryter mot Googles riktlinjer för strukturerad data kan göra den ovalbar. Google föreslår att du testar markup med Rich Results Test under utvecklingen och följer rapporterna om rich results i Search Console efter driftsättning. Typer av rich results visas också i dimensionen Sökutseende.

I GSC Magic: gsc_inspect_url rapporterar de rich results som Google hittade på en URL.

Relaterat: Sökutseende, URL-granskning, CTR (klickfrekvens)

Core Web Vitals och sidhastighet

Core Web Vitals

Core Web Vitals är Googles tre mått på riktiga användares upplevelse: Largest Contentful Paint (laddning), Interaction to Next Paint (respons) och Cumulative Layout Shift (visuell stabilitet).

Gränsvärdena för bra värden är LCP inom 2,5 sekunder, INP på 200 millisekunder eller mindre och CLS på 0,1 eller mindre, mätt vid 75:e percentilen av sidladdningar, separat för mobil och dator. En sida klarar sig när alla tre når målet. Google säger att bra Core Web Vitals stämmer med det som Googles kärnrankningssystem belönar, som en del av sidupplevelsen. Search Consoles rapport Core Web Vitals visar hur dina sidor presterar.

I GSC Magic: cwv_get_origin, cwv_get_url och cwv_history läser Core Web Vitals från riktiga användare, och dashboarden visar ett Core Web Vitals-kort per webbplats.

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

Källor: web.dev, developers.google.com

LCP (Largest Contentful Paint)

LCP mäter laddning: tiden tills den största bilden, textblocket eller videon i visningsområdet har renderats. Bra är 2,5 sekunder eller mindre.

LCP mäts från det att användaren först navigerade till sidan, så den inkluderar serverns svarstid, omdirigeringar och anslutningsuppbyggnad. Använd 75:e percentilen av sidladdningar, uppdelad på mobil och dator, för att bedöma om de flesta besökare får en bra upplevelse.

I GSC Magic: cwv-verktygen returnerar LCP vid 75:e percentilen med andelen bra, förbättringsbara och dåliga laddningar.

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

Källor: web.dev

INP (Interaction to Next Paint)

INP mäter respons: hur lång tid sidan tar på sig att synligt svara på klick, tryck och tangenttryckningar. Bra är 200 millisekunder eller mindre, dåligt över 500.

INP observerar latensen för alla interaktioner under ett besök och rapporterar ungefär den långsammaste, med undantag för extremvärden. Det ersatte First Input Delay (FID), som bara mätte indatafördröjningen för den första interaktionen. Långa JavaScript-uppgifter på huvudtråden är en vanlig orsak till dålig INP.

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

Källor: web.dev

CLS (Cumulative Layout Shift)

CLS mäter visuell stabilitet: det största utbrottet av oväntade layoutförskjutningar under en sidas livstid. Bra är 0,1 eller mindre, dåligt är över 0,25.

En layoutförskjutning sker när ett synligt element flyttar sig mellan renderade bildrutor utan användarens inverkan, till exempel när en bild utan angivna mått eller en sen annons trycker ner texten. Förskjutningar som ligger mindre än en sekund från varandra grupperas i ett sessionsfönster, och det största fönstret är CLS-värdet.

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

Källor: web.dev

CrUX (Chrome UX Report)

CrUX är Googles publika dataset över hur riktiga Chrome-användare upplever webbplatser, och datakällan för fältdata bakom Core Web Vitals i Googles verktyg.

Ursprung och sidor tas bara med om de är offentligt upptäckbara och har tillräckligt många besökare för ett statistiskt signifikant urval, så många sidor med låg trafik saknar data. Google Search använder CrUX som underlag för rankningsfaktorn för sidupplevelse. PageSpeed Insights visar CrUX som sin fältdata och faller tillbaka på data på ursprungsnivå när en sida har för få prover.

I GSC Magic: cwv-verktygen frågar CrUX om ett ursprung eller en URL; sidor utan tillräckligt mycket Chrome-trafik returnerar inga data.

Relaterat: Core Web Vitals, PageSpeed Insights och Lighthouse, LCP (Largest Contentful Paint)

Källor: developer.chrome.com

PageSpeed Insights och Lighthouse

PageSpeed Insights rapporterar en sidas CrUX-data från riktiga användare och kör Lighthouse, ett verktyg med öppen källkod som granskar prestanda, tillgänglighet, bästa praxis och SEO i en simulerad labbmiljö.

Fältdata visar vad riktiga besökare upplevde över tid; labbdata från Lighthouse är en enda kontrollerad körning som är användbar för felsökning men kan missa flaskhalsar i verkligheten. PSI:s Core Web Vitals-bedömning använder fältdata: en sida eller ett ursprung godkänns när 75:e percentilen för LCP, INP och CLS är bra. Lighthouse körs också i Chrome DevTools, från kommandoraden eller som en Node-modul.

I GSC Magic: psi_run_audit kör Lighthouse via PageSpeed Insights, och dashboardens Core Web Vitals-kort kan starta en granskning.

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

Källor: developers.google.com, developer.chrome.com

SEO-analys

Striking distance-sökord (snabba vinster)

Striking distance-sökord är sökfrågor där en sida redan rankar strax utanför toppresultaten, ofta position 4 till 20, med tillräckligt många visningar för att ge klick.

Det här är en branschterm inom SEO, inte ett mått i Search Console. Vanlig metod: filtrera Prestandarapporten per sökfråga och sida, behåll rader med genomsnittlig position strax under topplaceringarna och meningsfulla visningar, och förbättra sedan den befintliga sidan i stället för att skriva en ny. Kom ihåg att genomsnittlig position är ett medelvärde, så kontrollera trenden. Se så hittar du striking distance-sökord och 7 snabba SEO-vinster.

I GSC Magic: report_quick_wins returnerar sökfråge- och sidpar på position 4 till 20 med många visningar, sorterade efter potentiella extraklick.

Relaterat: Genomsnittlig position, Visningar, CTR-avvikelse (sida med låg CTR)

Källor: support.google.com

Kannibalisering av sökord

Kannibalisering av sökord innebär att två eller fler sidor på din webbplats konkurrerar om samma sökfråga och delar visningar och klick i stället för att en sida rankar bra.

Det är en branschterm inom SEO snarare än ett begrepp från Google. I Search Console syns det som en sökfråga där visningarna sprids över flera URL:er som ibland byter plats över tid. Inte varje överlapp är ett problem: olika avsikter kan förtjäna olika sidor, och varumärkessökningar visar ofta många URL:er. Vanliga åtgärder är att slå ihop sidor med en 301-omdirigering, skilja deras avsikt åt eller justera interna länkar. Se kannibalisering av sökord i Search Console.

I GSC Magic: report_cannibalization listar sökfrågor där två eller fler av dina sidor var och en får en betydande andel av visningarna.

Relaterat: Sökfråga, Sida (dimension), Kanonisk URL, Omdirigering (301 vs 302)

Källor: support.google.com

Innehållsförfall

Innehållsförfall är en gradvis, ihållande minskning av en sidas sökklick över flera månader, till skillnad från ett plötsligt tapp orsakat av ett tekniskt problem eller en uppdatering.

Det är en branschterm inom SEO. Typiska orsaker är föråldrad information, nyare konkurrerande sidor eller förändrat sökintresse. Att jämföra flera perioder i följd skiljer en stadig nedgång från en dålig vecka; att titta på samma månader året innan utesluter säsongsvariation. Se så upptäcker du innehållsförfall.

I GSC Magic: report_content_decay listar sidor vars klick föll i var och en av de tre senaste perioderna (28 dagar vardera som standard).

Relaterat: Säsongsvariation, 16 månaders datalagring, Core-uppdatering

CTR-avvikelse (sida med låg CTR)

En CTR-avvikelse är en sida eller sökfråga vars klickfrekvens ligger klart under vad andra resultat på samma position på din webbplats får.

Eftersom CTR sjunker med positionen betyder låg CTR bara något när den jämförs på liknande positioner. Avvikelser har ofta en titel eller ett utdrag som inte matchar sökfrågan, eller så konkurrerar de med ett rich result eller en AI Overview på samma resultatsida. Google föreslår att du granskar titel och utdrag när visningarna står stilla men klicken faller. Se sökord med låg CTR i Search Console.

I GSC Magic: report_ctr_outliers flaggar sidor vars CTR ligger under hälften av webbplatsens median-CTR på samma position.

Relaterat: CTR (klickfrekvens), Genomsnittlig position, Striking distance-sökord (snabba vinster)

Varumärkessökningar och icke-varumärkessökningar

Varumärkessökningar innehåller ditt varumärkesnamn, felstavningar av det eller dina unika produkter; icke-varumärkessökningar är alla andra sökningar som visar din webbplats.

Varumärkessökningar rankar oftast högre och får fler klick, medan icke-varumärkessökningar visar hur nya människor hittar dig. Search Console har ett filter för varumärkessökningar i Prestandarapporten, klassificerat av ett AI-assisterat system snarare än en sökordslista. Google säger att det bara är tillgängligt för webbplatser på domännivå med tillräckligt många sökfrågor och visningar, och att det kan felklassificera vissa sökfrågor.

I GSC Magic: report_brand_split delar sökfrågor efter de varumärkestermer du anger och returnerar klick, visningar och klickandel för varje grupp.

Relaterat: Sökfråga, CTR (klickfrekvens), Anonymiserade sökfrågor

Säsongsvariation

Säsongsvariation är en återkommande uppgång eller nedgång i sökefterfrågan vid samma tid varje år, till exempel högtider, som ändrar trafiken utan att rankingen ändras.

Googles guide om trafiktapp föreslår att du ställer in Prestandarapporten på de senaste 16 månaderna för att se om ett tapp upprepas varje år, och kontrollerar de främsta sökfrågorna i Google Trends för att se om efterfrågan föll över hela webben. Om visningarna föll medan positionen hölls är efterfrågan den troliga orsaken. Se säsongsvariation vs verkliga rankningstapp.

I GSC Magic: Eftersom Pro och Agency behåller lagrad historik längre än 16 månader kan agenter jämföra samma period över mer än ett år.

Relaterat: 16 månaders datalagring, Innehållsförfall, Core-uppdatering

Core-uppdatering

En core-uppdatering är en betydande, bred förändring av Googles rankningssystem, som görs flera gånger per år och tillkännages på Googles lista över rankningsuppdateringar.

Core-uppdateringar riktar sig inte mot specifika webbplatser. Google rekommenderar att du väntar tills utrullningen är klar och sedan jämför en hel vecka efteråt med en vecka innan den började. Ett litet tapp, som från position 2 till 4, kräver ingen drastisk åtgärd; ett stort, ihållande tapp kräver en ärlig bedömning av hela webbplatsens hjälpsamhet. Google noterar att vissa effekter syns inom dagar, andra inom flera månader. Se checklistan för organiska trafiktapp.

I GSC Magic: report_traffic_drops jämför en period med perioden före och listar de sidor eller sökfrågor som förlorade eller vann flest klick.

Relaterat: Genomsnittlig position, Säsongsvariation, Söktyp

Källor: developers.google.com, developers.google.com

Bing och IndexNow

Bing Webmaster Tools

Bing Webmaster Tools är Microsofts motsvarighet till Search Console: sökprestanda, genomsöknings- och indexdata, URL-inskickning och sökordsanalys för Bing.

API:et ger programmatisk åtkomst till trafik- och rankningsstatistik, länk- och sökordsdetaljer, genomsökningsstatistik samt inskickning av URL:er och sitemaps. Search Performance visar 16 månaders historik. AI Performance, som introducerades som offentlig förhandsversion i februari 2026, visar hur ofta dina sidor citeras i Microsoft Copilot och Bings AI-genererade svar. Se guiden till Bing Webmaster Tools API och Bing Webmaster Tools i GSC Magic.

I GSC Magic: Med din Bing-API-nyckel lägger GSC Magic till Bing-verktyg för sökfråge- och sidstatistik, genomsökningsdata, sökordsanalys och URL-inskickning, plus report_google_vs_bing.

Relaterat: IndexNow, GEO (generativ sökmotoroptimering), XML-sitemap

Källor: learn.microsoft.com, blogs.bing.com, blogs.bing.com

IndexNow

IndexNow är ett öppet protokoll som låter en webbplats direkt meddela deltagande sökmotorer, bland annat Bing, Naver, Seznam.cz, Yandex och Yep, att en URL har lagts till, uppdaterats eller tagits bort.

Du lägger en nyckelfil på din webbplats för att bevisa ägarskap och skickar sedan en URL eller en batch till en IndexNow-slutpunkt; en inskickning delas med alla deltagande motorer. Ett HTTP 200-svar betyder bara att URL:en togs emot, inte att den kommer att indexeras. Google finns inte med bland de deltagande motorerna. Se så sätter du upp IndexNow med en AI-agent.

I GSC Magic: indexnow_generate_key skapar en nyckel och indexnow_submit skickar upp till 10 000 URL:er per anrop (Pro och Agency, med din IndexNow-nyckel).

Relaterat: Bing Webmaster Tools, Begär indexering, XML-sitemap

Källor: indexnow.org, indexnow.org, indexnow.org

Google Analytics 4

Session (GA4)

I Google Analytics 4 är en session en period då en användare interagerar med din webbplats eller app; på webben avslutas den som standard efter 30 inaktiva minuter.

En session startar när någon öppnar appen eller visar en sida medan ingen session är aktiv, och GA4 loggar en session_start-händelse. Det finns ingen maximal längd, och tidsgränsen kan ändras i inställningarna för dataströmmen. Sessioner är inte samma sak som klick i Search Console, se varför siffrorna inte matchar och GA4 i GSC Magic.

I GSC Magic: ga_run_report läser sessioner från GA4 skrivskyddat, per valfri dimension som landningssida eller sessionskälla.

Relaterat: Klick, Nyckelhändelse (GA4), Hänvisningstrafik, Trafik från AI-assistenter

Källor: support.google.com

Nyckelhändelse (GA4)

En nyckelhändelse är en GA4-händelse som du markerar som viktig för din verksamhet, som ett köp eller en registrering; nyckelhändelser hette tidigare konverteringar i Analytics.

Varje insamlad händelse kan markeras som nyckelhändelse. Google använder nu ”konvertering” för åtgärder som mäts för Google Ads-kampanjer och budgivning, så antalet konverteringar och nyckelhändelser kan skilja sig.

I GSC Magic: ga_list_key_events listar de nyckelhändelser som är konfigurerade på en GA4-webbplats.

Relaterat: Session (GA4), Hänvisningstrafik

Källor: support.google.com

Hänvisningstrafik

I GA4 är Hänvisning standardkanalen för besökare som kommer via icke-annonslänkar på andra webbplatser eller appar, som bloggar och nyhetssajter.

GA4 tilldelar sessioner till standardkanaler med hjälp av källa och medium. Organiska sökresultat, inklusive Googles AI Overviews och AI Mode, hamnar i Organisk sökning, och igenkända AI-assistenter har en egen kanal, AI-assistent. Direkt omfattar besök via en sparad länk eller en inskriven URL.

Relaterat: Trafik från AI-assistenter, Session (GA4), Nyckelhändelse (GA4)

Källor: support.google.com

Trafik från AI-assistenter

Trafik från AI-assistenter är besök från länkar i chattassistenter som ChatGPT, Gemini, Claude eller Copilot, som GA4 grupperar i kanalen AI-assistent när den känner igen hänvisaren.

Sedan maj 2026 sätter GA4 medium till ai-assistant och kanal till AI-assistent när hänvisaren matchar en igenkänd assistent; kanalen utesluter Googles AI Overviews och AI Mode, som räknas som Organisk sökning. Kanalen beror på hänvisaren, så assistentbesök som kommer utan hänvisare räknas inte där. Trafik är inte samma sak som citeringar. Se mät ChatGPT- och Perplexity-trafik i GA4.

I GSC Magic: Dashboarden räknar GA4-sessioner från AI-assistentkällor som ChatGPT, Perplexity, Claude och Gemini; den mäter besök, inte citeringar.

Relaterat: Hänvisningstrafik, Session (GA4), GEO (generativ sökmotoroptimering), AI Overviews och AI Mode