google.com/goto: Location lezen met HEAD

Google Search zet de eind-URL niet altijd meer in het href van het resultaat. Organische resultaten wijzen naar https://www.google.com/goto?url=CAES…. Dit is niet de oude google.com/url?q=…: de parameter is geen gecodeerde URL. Je decodeert hem niet.

Google moet de bestemming toch kennen. Die komt in de HTTP-header Location wanneer je /goto opvraagt. Dat is de read die wij gebruiken.

Voorbeelden in curl, Python en Node: github.com/automdev/google-goto-url-fix. De Google Search-API van Autom doet die hop op de server.

De rollout en waarom: google.com/goto: Googles anti-scraping update.

Eén zin

Volg de redirect niet. Lees Location.

GET /goto?url=CAES…  HTTP/1.1
Host: www.google.com

HTTP/1.1 302 Found
Location: https://www.linkedin.com/in/satyanadella

HEAD vraagt alleen headers. GET met redirect: "manual" (of allow_redirects=False) leest hetzelfde. Google geeft soms 402 (of een andere status) met een Location: lees de header ook als het geen 3xx is.

curl

curl -sI --max-redirs 0 \
  -H 'Referer: https://www.google.com/search' \
  'https://www.google.com/goto?url=CAES...' \
  | grep -i '^location:'

-I is HEAD. Zonder -L volgt curl niet. De regel Location: is de echte URL.

Dezelfde read met GET:

curl -sD - -o /dev/null --max-redirs 0 \
  -H 'Referer: https://www.google.com/search' \
  'https://www.google.com/goto?url=CAES...' \
  | grep -i '^location:'

Python

import requests

goto = "https://www.google.com/goto?url=CAES..."
r = requests.head(
    goto,
    allow_redirects=False,
    headers={"Referer": "https://www.google.com/search"},
    timeout=10,
)
print(r.status_code, r.headers.get("Location"))

Als HEAD leeg is, opnieuw proberen met GET zonder te volgen:

r = requests.get(goto, allow_redirects=False, timeout=10)
print(r.headers.get("Location"))

Node

const res = await fetch(goto, {
  method: "HEAD",
  redirect: "manual",
  headers: { Referer: "https://www.google.com/search" },
});
console.log(res.status, res.headers.get("location"));

In een browser kan een handmatig 3xx binnenkomen als opaqueredirect en de header verbergen. In Node zijn de headers zichtbaar.

Waarom CAES niet decoderen?

De blob is geen publiek URL-protobuf. Het is een ondoorzichtige referentie. Alleen Google kent het doel en zet het bij de hop in Location. Uit een zichtbare naam ("LinkedIn · Satya Nadella") een URL plakken is een slecht idee.

Het href is /goto. De pagina kent de URL nog.

Google kan de bestemming niet helemaal verbergen. Het heeft de echte URL nodig om de SERP te tekenen: zichtbaar domein, favicon, attributieblok. Die waarden staan nog op de pagina, meestal in een datascript onderaan, en in een interne store (W_jd) die de SERP-JavaScript leest.

Daarom «schoonmaken» de links in sommige browsers na een muisbeweging: een script leest W_jd en herschrijft elk /goto-href naar de echte URL. Het dekt alleen organisch onder #rso div[data-rpos] met een attributieblok. AI Overviews blijven op /goto. Je hebt een live pagina nodig en die eerste muisbeweging. Een headless fetch van de HTML triggert het niet. Chrome laat de /goto-hrefs vaak staan.

Nog een lek zit op de link «Deze pagina vertalen». Als de UI-taal niet overeenkomt met de resultaattaal, voegt Google die control toe en staat de schone URL er vaak op. Latijn (Accept-Language: la) verschijnt bijna altijd, omdat bijna geen pagina in het Latijn is.

Dat zijn uitleg van wat de pagina nog bevat. Het is bros: Google kan W_jd hernoemen, het script wijzigen of de vertaalcontrol schrappen. Je krijgt er ook geen stabiel API-veld van.

De duurzame read blijft Location op /goto. Geen live DOM, geen muisevent, geen taaltruc.

Bij Autom

De Google Search-API lost /goto al op en geeft de eind-URL terug in organic_results[].link.

curl -s https://api.autom.dev/v1/google/search \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"linkedin.com/in satya nadella","gl":"us","hl":"en"}'

Code en README: github.com/automdev/google-goto-url-fix.