El resumen en 30 segundos
El 26 de agosto de 2026, Google confirmó que los enlaces de los resultados de búsqueda ahora pasan por google.com/goto?url=[token cifrado] antes de llegar al destino. Barry Schwartz lo informó en Search Engine Roundtable y Search Engine Land, y un portavoz de Google confirmó que forma parte de "medidas técnicas de largo plazo contra formas en evolución de abuso".
Si tu equipo extrae URLs de destino de los resultados de búsqueda de Google (seguimiento de rankings, scraping de SERP, recolección de datos para IA), una premisa acaba de romperse: la URL real ya no se ve en el enlace. Está cifrada en un token que el navegador sigue como un redireccionamiento normal.
La buena noticia: tiene arreglo, y el arreglo es más pequeño de lo que la mayoría cree. El token no se puede descifrar, pero se resuelve con una sola petición HTTP extra y, como es determinista, se puede cachear. Este artículo te guía por un arreglo de 30 minutos: detectar el cambio, resolverlo con seguridad y confirmar que tus informes siguen mostrando las páginas correctas. Si no haces scraping de SERP ni comparas rankings con URLs extraídas de esas páginas, salta a "Lo que el cambio no afecta". Nada cambia en tu sitio.
Qué cambió exactamente
Durante años, el enlace de un resultado de Google llevaba el destino real dentro del propio enlace:
<a href="https://yoursite.com/landing-page?utm_...">...Ahora ese mismo resultado puede llevar un enlace de tránsito:
<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...Al seguirlo, Google devuelve un redireccionamiento HTTP hasta el destino. Dos puntos importantes sobre su funcionamiento:
- El token está cifrado y es a prueba de manipulación. Según una ingeniería inversa independiente (publicada en agosto de 2026), se compone de un marcador de 1 byte, un identificador de clave de 4 bytes y datos en formato Tink. Cambias un carácter y Google responde con HTTP 400. No puedes falsificar un token ni decodificar la URL sin las claves de Google.
- El token es determinista. La misma URL de destino siempre genera el mismo token. Eso solo ya hace barato todo el arreglo: resuélvelo una vez y usa la caché del token.
Derek Perkins, de Nozzle, observó un despliegue cercano al "100%" en varios proveedores de IP residenciales, y por eso esta vez es más que un experimento.
Lo que sobrevive al cambio
Sigue siendo legible | Ha desaparecido |
|---|---|
La URL visible bajo el fragmento (normalmente el dominio) | La URL exacta del destino dentro del |
El parámetro | La comparación directa de URLs en el nivel del enlace |
Títulos de resultados, fragmentos y rankings | Cualquier decodificación de enlaces en el cliente |
Que el parámetro ved sobreviva vale la pena: los datos de posición y tipo de clic que los seguimientos de rankings leían de los enlaces de resultados siguen ahí. Lo único oculto es la URL de destino.
Lo que el cambio no afecta
- Rankings y tráfico. El sistema de clasificación de Google no tiene relación con los enlaces que renderiza.
- Los datos de Google Search Console. Las posiciones, impresiones y clics en GSC vienen de datos internos de Google y no se ven afectados.
- Los rastreadores que visitan tu sitio. Googlebot, GPTBot y cualquier bot que rastree tus páginas no toca
google.com/goto. Solo aparece en los enlaces que Google te muestra. - Bing y otros buscadores. Es un cambio solo de Google.
Los afectados son solo quienes ejecutan pipelines que leen enlaces de las tablas de resultados de Google. Si eres de esos, lo notarás; si no, el cambio es solo ruido.
Comprueba si estás afectado
Ejecuta las cuatro comprobaciones. Las dos primeras tardan cinco minutos; las dos últimas son una conversación con tu proveedor.
Comprobación | Cómo | Si ves esto |
|---|---|---|
1. Datos de SERP en crudo | Busca | Cualquier coincidencia = tu fuente ya está tokenizada |
2. Muestra de SERP real | Ejecuta una consulta habitual, haz clic derecho en un resultado y copia el enlace | Un enlace |
3. Columna de URL en tu herramienta | Trae tu último informe de palabras clave: ¿la columna de URL muestra | La herramienta está guardando enlaces de tránsito |
4. Patrones de deriva de ranking | Compara los cambios de URLs monitoreadas de esta semana con los cambios reales que hiciste en el sitio | Brechas grandes tras una semana tranquila = problema de parser, no de ranking |
Si todo está limpio, no va contigo: marca esta página y sigue adelante.
Si encuentras una coincidencia, los cuatro pasos siguientes devuelven la precisión al pipeline. Cada paso dice qué hacer, cómo es una buena salida y cómo recuperarse cuando no ocurre.
Paso 1: Detecta los tokens donde aparecen
Qué hacer. En tu script de extracción de SERP, recoge todos los enlaces de resultados y marca todo lo que empiece por https://www.google.com/goto?url= (combina también el /goto?url= desnudo que aparece en algunas superficies y el url= seguido de una carga con formato base64). Registra el índice de marcado por consulta: ese es tu indicador de despliegue. Y, por la observación de Derek Perkins: el despliegue no es uniforme entre rangos de IP, así que haz el seguimiento por proveedor y no en conjunto.
Resultado esperado. Un goto_rate por consulta. El 0% significa que tu fuente aún devuelve enlaces directos; el 100%, tokenización completa.
Comprobación de calidad. Ejecuta la misma consulta dos veces desde dos IP distintas. Si una está tokenizada y la otra no, se ha producido una partición de rangos de IP y hay que tratar ambos lados.
Recuperación. Si la muestra da cero coincidencias pero sospechas de tokenización, comprueba si tu extracción está leyendo un DOM renderizado por JavaScript en lugar del HTML crudo. Los tokens pueden aparecer en el marcado renderizado aunque la respuesta cruda siga en el formato antiguo.
Paso 2: Resuelve un token con un solo redireccionamiento
Qué hacer. Cuando el resultado lleve un token, sigue el enlace desde el servidor con el seguimiento de redireccionamientos desactivado y lee la cabecera Location:
curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i locationLa respuesta es un HTTP 3xx hacia el destino real. Consérvala. Dos reglas hacen este paso barato y seguro:
- Cachea por token, no por URL. Como la tokenización es determinista, basta una resolución por token. Guarda
token -> resolved_urly reutilízalo para siempre. - Nunca rastrees `google.com/goto` como una página. Google añadió
Disallow: /goto?a su propio robots.txt a finales de julio de 2026. Ese destino está pensado explícitamente para no ser descargado por rastreadores; un fetcher correcto sigue ligeramente el enlace del token y lee solo la cadena de redireccionamientos; un fetcher mal construido indexa o archiva la propia URL goto y ensucia tus datos. A finales de julio ya había casi 3.750 URLs así indexadas en el propio google.com.
Comprobación de coste antes de salir: un primer barrido de SERPs con cientos de resultados supone cientos de peticiones extra a google.com, justo la clase de carga que vigila la detección de bots de Google. La caché determinista lo reduce a una petición por token único, así que no ahorres en este paso.
Resultado esperado. Una tabla de mapeo estable entre tokens y destinos. Comprueba diez tokens aleatorios en el navegador: cada uno debe caer en una página razonable.
Comprobación de calidad. Confirma que la longitud del token es estable entre URLs distintas y que las URLs de destino idénticas siempre producen el mismo token. Si deja de cuadrar, hubo rotación de claves (ver Paso 5).
Recuperación. Un token que devuelve 400 está falsificado, truncado o proviene de una sesión caducada; rehaz el scrape de la SERP y vuelve a intentar. Dos fallos seguidos suelen significar HTML antiguo en el archivo, no un token roto.
Paso 3: Guarda el destino, no el envoltorio
Qué hacer. El resto del pipeline (el mapeo de palabra clave a página, las comprobaciones de indexación, la auditoría de esquemas) debe ver la URL de destino. Así que, tras el Paso 2, guarda tres campos por resultado: resolved_url, token y accessed_at. Saca los enlaces goto de la columna de URL de cualquier informe; una URL de google.com en un informe de palabras clave es un error de calidad de datos en más de una docena de formas.
Si no puedes añadir el resolvedor esta semana, el paso intermedio seguro es omitir el destino por completo en lugar de guardar el token: los datos de posición y ranking siguen teniendo sentido y solo queda vacía la columna de URL. Una herramienta que dice con todas las letras "sin URL" es mucho más fácil de interpretar que una que informa de una cadena de token como dirección real.
Resultado esperado. Un informe en el que el 100% de las filas son URLs http(s) de tus dominios y cero filas de google.com.
Comprobación de calidad. Compara los datos a nivel de URL con Search Console para diez palabras clave. Las filas deben coincidir. Si Search Console da una posición para una URL que tu informe dice "no encontrada", hay un hueco en el resolvedor o en el analizador.
Recuperación. Si una parte pequeña de las URLs sigue fallando al resolverse, registra sus tokens por separado. La mayoría de los fallos remiten a los dos culpables del Paso 2: HTML antiguo o un muro de detección de bots en la petición siguiente.
Paso 4: Confirma qué hace tu proveedor
Qué hacer. Si dependes de una herramienta de seguimiento de rankings o de una SERP API (incluidas las construidas sobre datos de Google con scraping), el despliegue ya lleva semanas. Haz estas cinco preguntas y contrasta con ellas cualquier cambio en los informes:
Pregunta | Buena respuesta | Cuidado |
|---|---|---|
¿Resolvéis los tokens | Sí, antes de devolver los resultados | "Devolvemos las URLs tal cual" |
¿La columna de URL puede ser | Nunca | "Rara vez" = sigue roto |
¿Cacheís los tokens resueltos? | Sí, porque son deterministas | Resolver en cada llamada quema créditos |
¿Los créditos o precios cambian por los redireccionamientos? | Sin cambios previstos | Cobro extra por cada seguimiento |
¿Usáis IP residenciales? | Sí | Las IP de centros de datos se tokenizaron antes y pueden tratarse distinto |
Resultado esperado. O un arreglo confirmado o una razón clara para irte. En 30 días deberías poder fusionar las URLs de tus informes con el registro de cambios del sitio sin ruido.
Vía de recuperación. Sin mejora del proveedor en una semana: sustituye ese punto de datos por el Google Search Console API para los rankings, porque viene directamente de los datos del propio Google y nunca ve un token. El precio es menos detalle a nivel de enlace; aceptable si tus decisiones necesitan precisión y no funciones de terceros.
Paso 5: Vigila el siguiente paso
El mecanismo no se queda quieto. Vigila tres cosas cada mes:
- Rotación de claves. La muestra de ingeniería inversa encontró cuatro identificadores de clave en circulación, con uno dominante ("ee47aa4d", en torno al 62% de los tokens). Si aparece una quinta clave y la cuota dominante empieza a moverse, espera invalidación de caché: vuelve a resolver los tokens en la rotación.
- Expansión a otras superficies. También se ha visto
/gotoen enlaces de pago y otros tipos de resultado. Si tus herramientas tocan anuncios o imágenes, amplía la búsqueda del Paso 1. - Endurecimiento continuado. Esto forma parte de una secuencia más larga: renderizado JavaScript forzado (principios de 2025), el lanzamiento de SearchGuard, el cierre del
&num=100(septiembre de 2025) y la demanda DMCA bajo la Sección 1201 contra SerpApi (diciembre de 2025). Cada uno está documentado por separado; el artículo de ingeniería inversa junta la mayoría. Espera que conseguir la URL final sea más difícil, no más fácil.
Verificación del resultado final
- [ ] El detector del Paso 1 corre en CI o programado y registra
goto_ratepor consulta - [ ] Todos los tokens de la muestra resuelven a destinos reales, contrastados en el navegador
- [ ] Cero URLs
google.com/gotoen tus informes (busca en la última exportación) - [ ] Diez palabras clave coinciden con Search Console línea a línea
- [ ] El proveedor confirmó la estrategia de resolución, o los datos de ranking ya van por la GSC API
- [ ] Hay una comprobación de rotación de claves dedicada en tu ritmo mensual
Preguntas frecuentes
¿Esto afecta a mis rankings o mi tráfico? No. Lo que cambia es la ruta del clic; el sistema de clasificación, los resultados y lo que ve el buscador no cambian. Tu rendimiento orgánico solo corre riesgo si una herramienta que operas empieza a informar de datos malos.
¿Se puede decodificar un token de goto? No desde fuera. Es una carga cifrada en formato Tink y cambiar un carácter devuelve HTTP 400, así que tampoco se puede falsificar. El camino posible es seguir el redireccionamiento y leer la cabecera Location, exactamente lo que hace el navegador.
¿Puede un scraper seguir enlaces `/goto`? En la práctica, seguir un enlace con token a través del redireccionamiento es lo que hace un clic del navegador, pero Google ha bloqueado /goto? en su robots.txt y los términos limitan el acceso automatizado a los resultados de búsqueda. Si haces scraping de SERP, ya estás en el lado equivocado de esos términos; este despliegue no lo cambia, solo lo hace más pesado. Elige tu postura de cumplimiento antes de construir el resolvedor.
¿Tengo que cambiar algo en mi sitio? No. El cambio está todo en los enlaces que Google renderiza. Lo que debes revisar son las herramientas que leen el SERP en tu nombre; eso es el Paso 4.
Autora: Olivia Stone, investigadora de inteligencia de SERP en Auspia (analiza más de 25.000 consultas). Escribe sobre análisis de SERP, patrones de ranking y cómo los cambios en los resultados de búsqueda afectan a los datos de posición.
