Google reescribe los enlaces de sus resultados para encarecer el scraping
El buscador sirve ahora los resultados orgánicos como google.com/goto?url=..., con un identificador opaco que obliga a pedirle a Google el destino. Desde finales de agosto el patrón es constante sin sesión iniciada.
Google ha empezado a reescribir los enlaces orgánicos de su buscador. En lugar de exponer la URL de destino en el HTML, los resultados apuntan a google.com/goto?url=..., y el salto a la página real se produce por redirección. El cambio se vio primero en un porcentaje pequeño de páginas de resultados; desde finales de agosto de 2026 aparece de forma consistente cuando navegas sin sesión iniciada o en modo privado.
El envoltorio no es nuevo, pero esto sí
Google lleva años usando google.com/url?q=[destino codificado], donde la URL objetivo se lee en la query string. El formato goto es otra cosa. El href del resultado es /goto, el parámetro url lleva una codificación propia de Google que no es un base64 del destino y, en la práctica, se comporta como una referencia opaca al registro del índice. No se puede decodificar sin preguntar al servidor: la URL real viaja en la cabecera Location de esa respuesta.
Para quien construye un índice a partir de datos de SERP, la receta cambia: se lanza una petición HEAD a /goto y se lee Location, sin seguir la redirección hasta la página final. Google necesita conocer el destino para pintar el resultado (dominio, favicon, atribución), así que quedan copias de la URL en la página, pero eso es otra cosa distinta de leer la cabecera.
Por qué lo hace
El movimiento encaja en la campaña de Google contra la extracción automatizada de resultados, en especial la de crawlers de IA y scrapers de SEO que se llevan miles de URLs del HTML para montar su propio índice sin volver a tocar Google. Con goto, cada resultado exige una petición de vuelta solo para conocer el destino. Es más lento, más ruidoso, y le da a Google una señal clara cuando un mismo cliente resuelve cientos de enlaces en secuencia.
Súmalo a lo anterior: la retirada del parámetro &num=100, que permitía traerse hasta cien resultados por consulta, y el endurecimiento de BotGuard y SearchGuard. La dirección es siempre la misma, subir el coste de extraer el buscador a lo bruto. De fondo está también la demanda contra SerpAPI, que dejó ver cómo funciona ese filtro.
Los proveedores de APIs de SERP ya se están moviendo. El que documentó el cambio ha actualizado su pipeline para resolver los enlaces leyendo Location sin seguirlo, de modo que sus clientes siguen recibiendo la URL final en los mismos campos estructurados, sin tocar la integración.
Queda por ver si esto es un experimento que se consolida o un paso intermedio. La superficie afectada ya no es una porción anecdótica de las páginas de resultados, y el formato de la redirección puede volver a moverse: quien dependa de datos de SERP hará bien en tratar la resolución de enlaces como una pieza que hay que vigilar, no como algo que se configura una vez y se olvida.
