Google goto: omdirigeringer i søkeresultatene

#Har Google bekreftet goto-omdirigeringene

Bekreftelsen er én og kort. I svaret til Search Engine Land 26. august 2026 skrev Google:

Jeg har en lang historie med å ta i bruk tekniske tiltak mot stadig nye former for misbruk, og vi tar jevnlig grep for å beskytte tjenestene og brukerne våre.

Google, Search Engine Land, egen oversettelse

Det er alt. Det finnes ingen dokumentasjon, ingen beskrivelse av tokenformatet, ingen referrer-policy, ingen startdato. Resten kommer fra observasjoner, og det er verdt å vite hvem sine.

De første meldingene kom 23. juni (Alex Greenland) og 2. juli (Brodie Clark), så det gikk to måneder fra første observasjon til bekreftelse. Google kalte det et tiltak mot misbruk, og konteksten er tydelig: selskapet saksøkte tidligere SerpAPI for scraping og tapte de sentrale DMCA-kravene. Når retten ikke stanset lesingen av resultatene, gjorde teknikken det.

#Slik fungerer google.com/goto-omdirigeringen

Fram til 26. august var lenken i et organisk resultat en vanlig <a href="https://dittnettsted.no/innlegg/">. Et verktøy som hentet HTML-en til resultatene, hadde straks en liste over adresser og posisjoner.

Nå fører href til https://www.google.com/goto?url= etterfulgt av en tegnstreng som ser ut som base64, men ikke er det i noen offentlig kjent form. Nettleseren sender en forespørsel til denne adressen, Googles server svarer med kode 302 og en Location-header til den egentlige siden, og nettleseren følger etter. Brukeren ser ett klikk og én side. I statuslinjen før klikket ser brukeren derimot en Google-adresse, ikke din, og det er den eneste synlige forskjellen.

Dette er ikke noen ny idé. Google Ads har i årevis sendt annonseklikk gjennom sin egen mellomadresse, og i organiske resultater dukket en lignende omdirigering /url?q= opp for innloggede brukere allerede rundt 2009, bare med måladressen skrevet i klartekst. Det nye er ikke omdirigeringen, men at måladressen ikke lenger kan leses uten å utføre en forespørsel.

#Endrer Google goto referrer i analyseverktøy

De fleste alarmistiske tekstene handler om referrer og attribusjon. Det er verdt å dempe med to fakta.

For det første har Google ikke publisert noen referrer-policy for goto. Hver artikkel som med sikkerhet sier hva du vil se i Google Analytics, beskriver egne observasjoner, ikke en regel.

For det andre, og viktigere: dataene du nå skulle miste, mistet du for lenge siden. I 2011 sluttet Google å sende søkeordet i referrer for innloggede brukere (det beryktede «not provided»), og i årene etter ble det utvidet til all trafikk. Siden da får nettleseren bare origin fra Google, altså https://www.google.com/, uten sti og uten parametere. GA4, Matomo, Umami og Plausible har i årevis klassifisert et slikt besøk som google / organic utelukkende ut fra domenet. En omdirigering via google.com/goto endrer ikke domenet.

Våre egne data bidrar ikke med noe her, og det sier vi rett ut: i Umami på wppoland.com samler vi ikke inn referrer i det hele tatt, feltet source betyr hos oss stedet på siden hendelsen kom fra, ikke hvor brukeren kom fra. Trafikken fra søkemotoren styrer vi fra Search Console, og den ser, ifølge Search Engine Land, ikke goto-omdirigeringene, fordi den teller klikk fra egne logger, ikke fra HTML.

Hva du bør sjekke hvis du bruker GA4 eller et annet verktøy med referrer: sammenlign andelen google / organic i uken 8. til 17. august med uken 22. til 31. august. Hvis andelen falt, mens klikkene i Search Console i samme vindu ble stående, betyr det at en del besøk endret klassifisering, og da er det verdt å lete videre. Hvis begge grafene følger hverandre, er det ingenting å reparere. Hos oss er klikkene fra Search Console i disse to vinduene 223 og 226, så på Googles side rørte ingenting seg.

#Hvordan påvirker Google goto rangeringsverktøy

En rank tracker som til nå gjorde én forespørsel per søk og leste hundre adresser fra HTML, får i dag hundre tokens. For å finne ut hvem som ligger på sjuende plass, må den sende en forespørsel til google.com/goto for det sjuende tokenet og lese Location-headeren. For hele første side og tilleggsblokkene anslår Nozzle dette til 500 til 1000 forespørsler per søk.

Konsekvensene er tre, og hver av dem dukker opp i rapportene dine i ulik form.

Den første er kostnaden, som verktøyene skyver over på prisene eller på lesefrekvensen. En daglig måling kan bli en måling hver tredje dag uten varsel, og posisjonsgrafen begynner å se trappetrinnformet ut.

Den andre er hull. Google begrenser forespørselsfrekvensen på residensielle adresser, så et verktøy som må gjøre tusen forespørsler i stedet for én, treffer oftere en sperre midt i lesingen. I rapporten ser du resultat for posisjon 1 til 4 og manglende data videre, eller posisjonen «ikke funnet» for en side som i Search Console har klikk fra samme dag.

Den tredje er variasjon som ikke er variasjon i rangeringene. Hvis verktøyet tar stikkprøver i stedet for å måle, kan to påfølgende avlesninger av samme søkeord avvike fordi utvalget var ulikt, ikke SERP-en. Augustbølgene med «ubekreftet volatilitet», som Barry Schwartz beskrev 1. til 3., 5. til 6. og 12. til 13. august, faller nøyaktig sammen med testperioden for goto. Vi påstår ikke at det er den eneste årsaken. Vi påstår at et verktøy som endret lesemetode i denne perioden, ikke er et troverdig vitne til rangeringsvolatilitet.

I BotGuard-rapporten fra oktober 2026 beskriver RESONEO sin egen måling: mellom 20. og 22. august la Google til fire familier av nettlesertester på resultatsidene (innstillinger nettleseren oppgir, tekstgjengivelse, pekerpresisjon og grafikkortet via WebGPU), og WebGPU-testen forsvant 5. oktober. Funnene bygger på RESONEOs egne nettleserforsøk og analyse av koden Google leverer, og Google har ikke kunngjort noen av testene. RESONEOs konklusjon for rangeringssporing er at en resultatside verktøyet får tak i, ikke garanterer en pålitelig måling.

Praktisk regel: fra 26. august er Search Console den eneste kilden som ikke endret metode. Hvis rank trackeren og Search Console ikke er enige, har Search Console rett og trackeren et hull. Før du melder et posisjonsfall til kunden, sammenlign visninger og gjennomsnittsposisjon for samme side i Search Console for samme dag.

#Krever Google goto endringer i WordPress

Ingen temafil, ingen utvidelse og ingen serverinnstilling påvirker hvordan Google bygger lenken i sine resultater. Ingenting må bygges om, ingen headere må legges til, det finnes ingenting å «optimalisere for goto». Hvis noen selger deg en slik tjeneste, selger de luft.

De to unntakene gjelder utvidelser som baserer logikken sin på referrer.

Det første er gamle utvidelser som viser «søkeordet brukeren kom fra» og uthever det i innholdet. De jobber med parameteren q fra referrer, som Google ikke har sendt siden 2011. De var døde før goto og er døde etter. Hvis du fortsatt har en slik aktiv, fjern den, for den belaster hver forespørsel og gir ingenting.

Det andre er A/B- og personaliseringsutvidelser som sjekker om referrer inneholder google. for å vise en annen variant av siden. De får fortsatt origin google.com, så betingelsen fungerer, men etter 26. august er det verdt å verifisere den live: åpne et Google-resultat i privat modus og sjekk i serverloggene eller i utviklerverktøyene hvilken Referer som kom inn. Fem minutter, og svaret er hardt, ikke hentet fra en artikkel.

Det er én ting til som ingen skriver om: hurtigbuffer og egne omdirigeringer. Hvis serveren din har en regel som behandler forespørsler med uvanlig referrer som mistenkelige (noen konfigurasjoner for hotlink-beskyttelse og enkelte regler i applikasjonsbrannmurer), sjekk at google.com som referrer ikke havnet på blokkeringslisten. Det er sjeldent, men konsekvensen ville vært en 403-feil for brukere fra søkemotoren, og en slik feil viser Search Console med ukers forsinkelse.

#Er det lov å skrape Google-resultater for rangeringssporing

Google svarer skriftlig på dette, i retningslinjene mot søppelinnhold i Google nettsøk, i avsnittet om maskingenerert trafikk:

Maskingenerert trafikk (også kalt automatisert trafikk) betyr å sende automatiserte søk til Google. Dette omfatter skraping av resultater for å sjekke rangeringer og andre former for automatisert tilgang til Google Søk uten uttrykkelig tillatelse.

Google, retningslinjer mot søppelinnhold i Google nettsøk, egen oversettelse

Det samme avsnittet legger til at slik trafikk bruker ressurser, hindrer Google i å betjene brukerne og bryter både retningslinjene mot søppelinnhold og Googles vilkår for bruk. Goto endret altså ikke reglene for rangeringsverktøy. Å lese posisjoner ut av Googles HTML var utenfor disse reglene også før 26. august; goto gjorde det dyrt. Det forklarer også hvorfor Google kunne kalle endringen et tiltak mot misbruk uten å nevne noe verktøy: i språket i Googles egne dokumenter er et rangeringsverktøy automatisert trafikk.

For deg som eier av et nettsted har dette én praktisk følge. Et verktøy som måler posisjoner ved skraping, arbeider på et område Google når som helst og uten varsel kan snevre inn igjen, akkurat slik det skjedde med goto. Behandle dataene som et anslag, og bruk en offisiell kilde som referanse.

#Slik henter du posisjonsdata fra Google uten skraping

Google tilbyr to offisielle kanaler, og begge bygger på de samme dataene som resultatrapporten i Search Console.

Den første er Search Analytics API. Én forespørsel gir opptil 25 000 rader (standard er 1000), og du blar videre med parameteren startRow. Du kan gruppere dataene etter søk, side, land, enhet, søkevisning, dato og time. Parameteren dataState avgjør om du får bare ferdigstilte data (final, standardverdien), også ferske data (all) eller en oppdeling per time med delvise data (hourly_all). Posisjonen i API-et er gjennomsnittlig posisjon i søkeresultatene, ikke én enkelt måling på ett tidspunkt, som er det et rangeringsverktøy gir deg.

Den andre er masseeksport av data: Search Console planlegger en daglig eksport av resultatdata til BigQuery. Ifølge hjelpesiden inneholder eksporten alle resultatdata Search Console har for eiendommen, med unntak av anonymiserte søk.

Ingen av kanalene forteller deg hvem som ligger over deg på en bestemt frase, fordi begge bare dekker din egen eiendom. Det er nettopp den informasjonen goto gjorde dyr for skrapere, og Google tilbyr ingen offisiell erstatning for den. Trenger du konkurrentenes posisjoner, blir du værende hos et kommersielt verktøy og godtar hullene. Trenger du dine egne posisjoner, er API-et siden 26. august en stabilere kilde enn noe rangeringsverktøy.

#Slik sammenligner du klikk i Search Console med økter i GA4 etter goto

Sammenligningen som er foreslått over, gir bare mening hvis du vet hva hvert verktøy teller. I Search Console er et klikk, ifølge Googles hjelpeside om resultatberegninger, ethvert klikk som sender brukeren til en side utenfor Google Søk, Discover eller Nyheter, og et nytt klikk på det samme resultatet etter at brukeren har kommet tilbake, telles bare som ett klikk. Posisjonen er den øverste posisjonen en lenke til siden din har, gjennomsnittlig over søkene der den dukket opp. GA4 teller økter som den egne taggen registrerer på nettstedet ditt, altså en annen enhet. De to tallene har aldri vært like, og goto endrer ikke det.

Hvis du kobler Search Console til GA4, husk to begrensninger fra Googles dokumentasjon: data fra Search Console kommer til Analytics 48 timer etter at Search Console har samlet dem inn, og Search Console lagrer data for de siste 16 månedene. En sammenligning av uken etter 26. august er derfor komplett først to dager etter at uken er over.

To punkter til gjelder referrer. Med Chromes standard referrer-policy, strict-origin-when-cross-origin, har forespørsler mellom ulike opphav bare origin i Referer-headeren, og en forespørsel fra en HTTPS-side til en HTTP-side har ingen referrer i det hele tatt. Hvis nettstedet ditt fortsatt leverer sider over ukryptert HTTP, kan besøk fra Google havne som direkte trafikk i GA4, med eller uten goto. Ett spørsmål står også åpent: PPC Land skrev 27. august 2026 at det er uklart om et verktøy som løser opp en goto-lenke, registrerer et klikk. Det er en observasjon, ikke noe Google har dokumentert. Hvis det stemmer, kan trafikk fra rangeringsverktøy dukke opp i klikkrapportene, så et plutselig hopp i klikk i Search Console uten tilsvarende økning i GA4-økter er verdt å sjekke med dette i tankene.

#Slik sjekker du om Google goto påvirker nettstedet ditt

Vi kjenner ikke tokenformatet, og heller ikke om Google noen gang vil dokumentere det. Vi vet ikke om omdirigeringen vil omfatte alle land og resultattyper, eller bare de organiske hovedlenkene. Vi vet ikke hva formålet er utover det generelle «mot misbruk», selv om hendelsesforløpet rundt SerpAPI antyder svaret. Og vi vet ikke hvordan nettleserne vil oppføre seg i kommende versjoner, for referrer-policyen for 302-omdirigeringer avhenger av dem, ikke av Google.

Den operative beslutningen avhenger ikke av noen av disse hullene. Rangeringene er de samme som før 26. august. Search Console viser det samme som før. Brukeren havner der brukeren havnet før. Det eneste som endret seg, er troverdigheten til verktøy som leser resultatene utenfra, og dit må bevisbyrden flyttes: fra trackeren til Search Console.

Tre handlinger som lukker temaet:

1. Sammenlign i GA4 eller i ditt eget verktøy andelen organisk trafikk fra Google i vinduene før og etter 26. august. Hvis den falt, men klikkene i Search Console ikke gjorde det, har du et klassifiseringsproblem å undersøke. Hvis den ikke falt, er temaet lukket.
2. Sjekk datoer og hull i rank trackeren fra 20. august. Hver kunderapport fra denne perioden bør ha en kolonne med posisjonen fra Search Console ved siden av posisjonen fra verktøyet.
3. Fjern utvidelser som baserer seg på søkeordet fra referrer, og verifiser live de som sjekker referrer-domenet.

Google tok kartet over resultatene fra verktøyene, ikke trafikken fra deg. Det er forskjellen mellom en endring du må reagere på og en endring du må vite om. Denne er den andre.

Omdirigeringshygiene hører hjemme på samme GEO- og LLMO-sjekkliste som crawl-budsjett og siteringsklare URL-er.