Volver al blog

Google oculta URL de los resultados: redirecciones goto y qué hacer con el análisis de SERP

El 26 de agosto de 2026, Google confirmó el lanzamiento de google.com/goto: los enlaces en los resultados llevan a una redirección encriptada, y no al sitio. Además, solo aquellos que la búsqueda considera bots ven el cambio. Analizamos la mecánica de los tokens, el costo de 500 a 1000 consultas y cómo reestructurar la recopilación de datos en dos capas.

📅31 de agosto de 2026
Google oculta URL de los resultados: redirecciones goto y qué hacer con el análisis de SERP
```html

26 de agosto de 2026, Google confirmó oficialmente: los enlaces en los resultados de búsqueda ya no llevan directamente al sitio. En lugar de la dirección de la página en HTML, hay una redirección del tipo google.com/goto?url=... con un token encriptado. Lo más desagradable de esta historia es que los enlaces modificados no llegan a todos. Una persona común en el navegador ve URL directas. Se ocultan precisamente de aquellos a quienes Google ya ha considerado automatización.

Qué sucedió exactamente

Las primeras señales aisladas aparecieron el 23 de junio de 2026 — a las que prestó atención Alex Greenland. El 2 de julio, Brody Clark registró el fenómeno de manera masiva. Y el 26 de agosto, Derek Perkins, CEO de la plataforma de seguimiento de posiciones Nozzle, informó sobre un despliegue prácticamente completo, y Google confirmó el cambio oficialmente.

La formulación del representante de la empresa para Search Engine Roundtable fue deliberadamente general: Google tiene una "larga historia de aplicación de medidas técnicas contra formas evolutivas de abusos", y la empresa "regularmente toma medidas para proteger sus servicios y usuarios". No se especificó a quién considerar como abuso.

La mecánica es simple y, por lo tanto, dolorosa. Antes, en el marcado del resultado había una dirección lista — el parser la recogía junto con el título y el snippet en una sola solicitud. Ahora hay un enlace a una redirección intermedia de Google, y dentro hay un token protobuf: una cadena base64 con el prefijo CAES, seguida de un payload encriptado. No es posible desencriptarlo de su lado — no tiene la clave. La única forma de saber a dónde lleva el enlace es seguirlo.

Tres detalles que determinan el costo del asunto

  • El token es de un solo uso. El mismo enlace a la misma página por la misma solicitud recibe un nuevo token en cada visualización. No se podrá construir un directorio "token → URL" y reutilizarlo.
  • HEAD no ayuda. La solicitud HEAD devuelve 200 sin el encabezado Location — es decir, sin la dirección de destino. Se necesita un GET completo, que devuelve 302 con una latencia media de aproximadamente 59 ms.
  • No solo se afecta el núcleo orgánico. Las direcciones ocultas aparecen en resultados normales, videos, fuentes de AI Overviews, en el bloque "Preguntas similares" y en publicidad (direcciones aclk). En el estudio de Growtika se analizaron 493 enlaces en ocho consultas — cada uno ocultó su dirección de destino.

La aritmética resulta desagradable. Según la estimación de Perkins, para resolver todos los enlaces de cinco páginas de resultados por una sola consulta, se necesitan entre 500 y 1000 solicitudes. Una medición independiente de scraping.club, después de la deduplicación, da cifras más modestas de 295–565 — pero sigue siendo dos órdenes de magnitud más que una solicitud, que era lo que se utilizaba antes.

La cita clave de Perkins describe la esencia del cambio mejor que cualquier cifra: la limitación vinculante no son el ancho de banda ni el almacenamiento, sino los límites de tasa.

Por qué esto es un golpe a la automatización

Aquí es donde se encuentra lo más interesante. Según las observaciones de scraping.club, la sustitución de enlaces no es universal: un usuario común — ya sea conectado o en modo incógnito — sigue recibiendo URL directas. Las redirecciones llegan de manera constante a los clientes automatizados: scripts que levantan un navegador con banderas como --remote-debugging-port, y stacks headless con automatización completa.

La conclusión práctica que hay que entender antes de comenzar a reescribir el parser es: la aparición de enlaces goto en su respuesta es una señal diagnóstica. Esto significa que Google ya ha clasificado a su cliente como un bot. No se ha encontrado con un nuevo formato de resultados — ha visto cómo se ve el resultado para aquellos que han sido detectados. Y lo que hay que arreglar primero no es el parser de enlaces, sino los criterios por los cuales se distingue de un humano: banderas de inicio, orden de encabezados, huella TLS, comportamiento de la página. Hemos discutido la metodología de esta autoevaluación en el material sobre cómo obtener el mapa de detección del sitio a través de sus propios scripts.

Un detalle curioso que confirma la versión: la resolución de redirecciones de Google casi no está protegida. Según las mediciones de scraping.club, para seguir un enlace no se necesitan proxies, encabezados especiales ni suplantación de TLS — una biblioteca común requests funciona tan bien como un Chrome falsificado, y en volúmenes pequeños se pueden alcanzar más de 110 solicitudes por segundo sin restricciones visibles. Es decir, la barrera no es criptográfica ni de red. Es un impuesto por volumen: no lo bloquean, simplemente le envían una factura en solicitudes.

Segundo golpe consecutivo

El cambio no debe leerse en aislamiento del anterior. Del 12 al 14 de septiembre de 2025, Google desactivó el parámetro &num=100, que devolvía cien resultados en una sola página. Después de esto, para la misma profundidad de resultados se necesitaban aproximadamente diez veces más solicitudes.

Las consecuencias se notaron mucho más allá del scraping. Según el análisis de 319 propiedades, desglosado por Search Engine Land, el 87,7% de los sitios perdió impresiones en Search Console, y el 77,6% perdió parte de las consultas únicas que clasificaban. El tráfico real no cambió — la medición se rompió: la mayor parte de las "impresiones" en posiciones lejanas eran generadas no por personas, sino por rastreadores que tiraban de cien resultados.

Sumamos dos pasos: primero, los resultados se encarecieron diez veces en número de solicitudes, y ahora a cada resultado se le añadió una solicitud separada por su dirección. La estrategia es clara: Google está aumentando metódicamente el costo de producción de su propio scraping de resultados.

El contexto legal también es significativo. Las medidas técnicas se implementaron justo cuando el camino judicial falló: la demanda de Google contra SerpApi por DMCA fue desestimada — el tribunal estableció la frontera entre la protección de obras autorales y la regulación del acceso a hechos de dominio público, señalando que los hechos y las URL no son obras. Los detalles de esta decisión y sus consecuencias se discutieron en un material separado sobre el caso de Google contra SerpApi. No se logró prohibir — se logró encarecer.

Qué se rompe en los informes en este momento

La plataforma DemandSphere enumeró los fallos específicos que ocurren si no se toman medidas:

  1. El dominio de destino se colapsa en google.com. El parser registra honestamente lo que ve en el marcado — y toda la salida se convierte en "perteneciente a Google".
  2. Se rompe la correspondencia de las propias páginas. El sistema deja de reconocer sus URL y considera que ha caído de los resultados.
  3. Se distorsionan la cuota de voz y la atribución de los competidores — no hay más que contar, todos los enlaces están en un solo dominio.
  4. Se rompe la serie histórica justo en la fecha de despliegue. Esto es lo más engañoso: el gráfico mostrará un colapso que en realidad no ocurrió.

La buena noticia: los datos puramente posicionales sufren menos. DataForSEO ya informó el 5 de julio de 2026 que el 99,99% de los resultados orgánicos a través de su API ya se devuelven con direcciones directas. El problema se concentra en los bloques de resultados — según la estimación de Growtika, los enlaces goto se conservan en aproximadamente la mitad de los AI Overviews y en una cuarta parte de los bloques locales. Es decir, lo que hoy es más importante está sufriendo: las fuentes de respuestas de AI y los resultados locales.

Cómo reestructurar la recolección

La conclusión ingenieril de todo lo mencionado es dividir la recolección en dos capas con diferentes costos de solicitud.

  1. Primero, verifique si lo han detectado. Capture la misma salida con su parser y manualmente desde un navegador limpio. Enlaces directos en la ejecución manual y goto en la automática — esto es un veredicto para su camuflaje, no una propiedad de Google.
  2. Separe la recolección de resultados y la resolución de enlaces. La primera capa es pesada: renderizado, plausibilidad de comportamiento, IP de calidad. La segunda — un GET primitivo por 302, sin navegador y sin suplantación. Pasar la resolución a través del mismo stack costoso — es quemar presupuesto en vano.
  3. Cuente límites, no gigabytes. El cuello de botella se ha desplazado al número de solicitudes. Planifique un grupo de direcciones basado en los RPS requeridos, no en el volumen de tráfico.
  4. No intente almacenar en caché los tokens. Son de un solo uso. Tiene sentido almacenar en caché el resultado de la resolución — la combinación "solicitud + posición + dominio", no el token mismo.
  5. Marque la fecha de ruptura en los datos históricos. El 26 de agosto de 2026 debe estar en los informes como un hito claro, de lo contrario, la falla metodológica se interpretará como una caída en la visibilidad.
  6. Verifique los bloques por separado. La orgánica puede estar en orden, pero los AI Overviews y el bloque local no. Pruebe estos como entidades independientes.

Qué proxies y dónde

De la división en dos capas se deriva también la división de la infraestructura — y esto es notablemente más barato que hacer todo a través de un solo grupo.

La recolección de los resultados mismos es la parte más sensible. Aquí es importante no destacarse entre los usuarios comunes, y precisamente esta capa determina si verá enlaces directos o goto. Para esto se utilizan proxies residenciales, y para tareas geodependientes como los resultados locales — móviles, donde la IP se ve absolutamente natural para la región específica.

En cambio, la resolución de redirecciones, como han mostrado las mediciones, no presenta requisitos especiales: un GET común, sin suplantación, alta velocidad. Esta es una tarea clásica para proxies de centro de datos — barato, rápido, con muchos flujos paralelos. La diferencia de costo entre los dos enfoques con 500–1000 solicitudes adicionales por cada solicitud de resultados se convierte en un artículo decisivo del presupuesto.

Conclusión

Google no cerró el acceso a los resultados — lo hizo más caro y, a su vez, convirtió el formato de respuesta en un indicador de detección. Para el mercado, esto significa la continuación de la tendencia iniciada con la desactivación de &num=100: la recolección masiva de datos de búsqueda deja de ser barata por defecto y se convierte en una tarea ingenieril con una economía clara.

Prácticamente, la conclusión se reduce a dos puntos. Si ve enlaces goto — comience con el camuflaje, no con el parser: es posible que tenga que reparar algo diferente a lo que parece. Si el camuflaje está en orden, pero aún hay redirecciones — separe las capas de recolección y no pague un precio premium por solicitudes que no lo necesitan.

```