Et klikk på et organisk Google-resultat fører ikke lenger direkte til nettstedet ditt. Fra 26. august 2026, da Google bekreftet utrullingen, går hver lenke i resultatene gjennom google.com/goto?url= med et kodet token, og først deretter sender Googles server nettleseren videre til den egentlige adressen. For brukeren endres ingenting, for rangeringene heller ikke. Det som endres, er hva verktøyene som leser resultatene fra HTML ser, og det er det eneste området der noe må sjekkes. Denne teksten skiller det Google har bekreftet fra det bransjen legger til, og sier konkret hva du bør sjekke i analyseverktøyene og i WordPress.
Hva Google har bekreftet, og hva som er antakelser
Bekreftelsen er én og kort. I svaret til Search Engine Land 26. august 2026 skrev Google:
We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.
(Oversatt: vi 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.)
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.
| hva vi vet | kilde | status |
|---|---|---|
lenken har formen google.com/goto?url= med et kodet token | SEO-observasjoner siden juni 2026 | bekreftet gjentatte ganger |
| serveren svarer med en 302-omdirigering til måladressen | observasjoner fra verktøy | bekreftet |
| tokenet kan ikke dekodes lokalt | Nozzle, SerpAPI | bekreftet gjennom forsøk |
| utrulling nær 100 prosent på residensielle adresser | Derek Perkins, Nozzle | måling fra ett selskap |
| Search Console uendret | Search Engine Land | gjengivelse, ikke dokument |
| referrer-policy | ingen | ukjent |
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.
Mekanismen, i tre steg
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.
Referrer: hvorfor apokalypsen ikke kom i august, for den kom i 2011
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.
Rangeringsverktøy: her ligger den egentlige kostnaden
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.
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.
Hva det endrer i WordPress: ingenting, med to unntak
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 med goto i referrer-stien 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.
Hva vi ikke vet, og hvordan handle likevel
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:
- 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.
- 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.
- 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.
