google.com/goto: leggere Location con HEAD

Google Search non mette più sempre l’URL finale nell’href del risultato. I risultati organici puntano a https://www.google.com/goto?url=CAES…. Non è il vecchio google.com/url?q=…: il parametro non è un URL codificato. Non si decodifica.

Google deve comunque conoscere la destinazione. La mette nell’header HTTP Location quando richiedi /goto. È questa la lettura che usiamo.

Esempi in curl, Python e Node: github.com/automdev/google-goto-url-fix. L’API Google Search di Autom fa l’hop sul server.

Il rollout e il perché: google.com/goto: l'anti-scraping di Google.

Una frase

Non seguire il redirect. Leggi 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 chiede solo gli header. GET con redirect: "manual" (o allow_redirects=False) fa la stessa lettura. A volte Google risponde 402 (o un altro status) con Location: leggi l’header anche se non è un 3xx.

curl

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

-I è HEAD. Senza -L, curl non segue. La riga Location: è l’URL reale.

La stessa lettura con 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"))

Se HEAD è vuoto, ritenta con GET senza seguire:

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 un browser, un 3xx in redirect: "manual" può arrivare come opaqueredirect e nascondere l’header. In Node, gli header sono visibili.

Perché non decodificare CAES?

Il blob non è un protobuf di URL pubblico. È un riferimento opaco. Solo Google conosce la destinazione e la mette in Location all’hop. Ricostruire un URL da un nome visibile ("LinkedIn · Satya Nadella") è una cattiva idea.

L’href è /goto. La pagina conosce ancora l’URL.

Google non può nascondere del tutto la destinazione. Gli serve l’URL reale per disegnare la SERP: dominio visibile, favicon, blocco di attribuzione. Quei valori sono ancora sulla pagina, di solito in uno script di dati in fondo, e in uno store interno (W_jd) che legge il JavaScript della SERP.

Per questo, in alcuni browser, i link «si puliscono» dopo un movimento del mouse: uno script legge W_jd e riscrive ogni href /goto con l’URL reale. Copre solo l’organico sotto #rso div[data-rpos] con blocco di attribuzione. Le AI Overviews restano su /goto. Serve una pagina live e quel primo movimento del mouse. Un fetch headless dell’HTML non lo attiva. Chrome spesso lascia gli href /goto com’è.

Un’altra fuga sta sul link «Traduci questa pagina». Se la lingua dell’UI non coincide con quella dei risultati, Google aggiunge quel controllo e l’URL pulito spesso sta lì. Il latino (Accept-Language: la) compare quasi sempre, perché quasi nessuna pagina è in latino.

Sono spiegazioni di ciò che la pagina contiene ancora. Sono fragili: Google può rinominare W_jd, cambiare lo script o togliere il controllo di traduzione. Non danno nemmeno un campo API stabile.

La lettura che regge resta Location su /goto. Niente DOM live, niente evento mouse, niente trucco di lingua.

In Autom

L’API Google Search risolve già /goto e restituisce l’URL finale 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"}'

Codice e README: github.com/automdev/google-goto-url-fix.