Google.com/goto: La actualización antiextracción de Google dificulta extraer todos los resultados
Google ha añadido una solicitud adicional entre los resultados de búsqueda y las páginas de destino, creando un conflicto directo con las herramientas que recopilan URL de resultados a gran escala. El cambio, conocido como google.com/goto: la actualización antiextracción de Google, reemplaza muchos enlaces orgánicos directos por direcciones de redirección opacas de Google.
El resultado de búsqueda sigue pareciendo familiar para una persona. Su título, dominio mostrado, favicon y descripción permanecen visibles. Sin embargo, el enlace subyacente ahora puede apuntar a google.com/goto?url=... en lugar de a la página del editor.
Esta distinción importa porque el valor codificado no revela la URL completa de destino. Un navegador puede pedir a Google que la resuelva automáticamente. Un scraper debe realizar otra solicitud, gestionar la respuesta y evitar activar las defensas de Google.
Google describe el despliegue como una medida técnica contra el abuso. El cambio no bloquea por completo la recopilación automatizada. En su lugar, transforma una tarea económica de análisis de HTML en una secuencia más ruidosa de solicitudes que Google puede observar.
Este es el conflicto central. Los usuarios de búsqueda siguen necesitando enlaces salientes fiables, mientras Google busca un mayor control sobre el acceso automatizado a sus resultados. Las empresas de API SERP, plataformas SEO, investigadores y desarrolladores de IA ahora operan dentro de esa tensión.
Google.com/goto: La actualización antiextracción de Google modifica la capa de enlaces
Google no ha cambiado lo que muestra un resultado orgánico, pero sí ha cambiado cómo el software llega al destino del resultado.
Un resultado tradicional de Google colocaba la página de destino directamente dentro del atributo href del elemento ancla. El software podía descargar una página de resultados de búsqueda, analizar su HTML y extraer varias URL completas.
La nueva estructura inserta una redirección controlada por Google. El ancla del resultado puede apuntar a una dirección /goto que contiene un valor que a menudo comienza por CAES. Ese valor representa el destino sin publicarlo como texto legible.
Cuando una persona hace clic en el resultado, el navegador solicita la dirección /goto. Google devuelve entonces una redirección HTTP que envía el navegador a la página real. La transición suele ser demasiado rápida para que el usuario la perciba.
Google confirmó el despliegue el 26 de agosto de 2026. Un portavoz afirmó que la empresa implementa regularmente medidas técnicas contra abusos en evolución para proteger sus servicios y usuarios. La confirmación describió la redirección como una de esas medidas.
La empresa no publicó una especificación técnica del token. Tampoco explicó todas las señales que determinan qué navegadores, regiones o sesiones reciben los enlaces reescritos.
Las primeras observaciones aparecieron antes de la confirmación. Especialistas en búsqueda informaron del patrón en junio y julio, cuando todavía parecía una prueba limitada. A finales de agosto, varios proveedores de datos estaban viendo un despliegue mucho más amplio.
La confirmación del despliegue informó de una cobertura casi completa entre varios proveedores de IP residenciales. Esa estimación procedía de Derek Perkins, de la empresa de seguimiento de rankings Nozzle, no de Google.
Autom, un proveedor de API de datos de búsqueda, informó de una evolución similar. Su equipo encontró por primera vez /goto en una pequeña proporción de páginas de resultados. Más tarde observó el formato de forma consistente en sesiones sin iniciar sesión y de navegación privada.
El análisis técnico del proveedor afirma que el parámetro opaco no puede convertirse en el destino mediante una decodificación local ordinaria. En cambio, el destino llega a través de la respuesta de redirección.
Este formato difiere del antiguo envoltorio /url de Google. Ese envoltorio a menudo incluía un destino legible y codificado como URL en su cadena de consulta. El software podía extraer ese valor sin volver a contactar con Google.
Con /goto, el resultado de búsqueda visible y el destino utilizable se convierten en piezas de datos separadas. Google sigue mostrando información suficiente para que una persona evalúe el resultado. Sin embargo, el código fuente de la página ya no garantiza una URL saliente reutilizable.
Ese es el cambio significativo. Google ha trasladado la resolución del destino del HTML estático a una interacción con su propio servidor.
Por qué una redirección adicional presiona a los proveedores de datos de búsqueda
La redirección crea un coste marginal por cada resultado resuelto, y ese coste se acumula en los sistemas de recopilación de gran volumen.
Un scraper básico antes solo necesitaba una solicitud para recopilar varios destinos orgánicos de una página de resultados de búsqueda. Con el nuevo formato, puede necesitar la solicitud original más una solicitud de resolución por cada token /goto único.
Pensemos en un servicio que supervisa muchas consultas en distintas ubicaciones, dispositivos e idiomas. Puede recopilar varias páginas por cada consulta y repetir esa recopilación durante el día. Una solicitud adicional por resultado se convierte rápidamente en un trabajo considerable de infraestructura.
El coste no se limita al ancho de banda. Cada resolución añade latencia, gestión de conexiones, lógica de reintentos y otra oportunidad de fallo. También crea un flujo identificable de solicitudes dirigidas al endpoint de redirección de Google.
Google puede observar con qué rapidez un cliente resuelve enlaces. Puede comparar esas solicitudes con cookies, identidades de red, características del navegador y actividad de búsqueda anterior. Google no ha revelado qué señales utiliza en este caso.
Esto hace que la actualización sea más que un nuevo formato de análisis. Crea un punto de control en el servidor entre la obtención de la página de resultados y el conocimiento de cada destino exacto.
El seguimiento tradicional de posiciones ilustra esta presión. Un rastreador de posiciones debe identificar qué página se posiciona para una consulta, no solo qué dominio aparece. Las rutas exactas importan cuando un sitio tiene varias páginas compitiendo por el mismo tema.
Una herramienta que almacena la redirección de Google en vez de la URL del editor puede producir registros engañosos. Podría informar de resultados ausentes, fusionar páginas distintas o hacer que los cambios de página de destino parezcan cambios de posicionamiento.
Las API de búsqueda enfrentan un problema relacionado. Sus clientes esperan URL de destino limpias y estructuradas. Esos clientes no deberían tener que entender el actual envoltorio de enlaces de Google ni reescribir sus integraciones cada vez que cambie el formato.
Autom afirma que modificó su pipeline para resolver enlaces /goto manteniendo sus campos de respuesta existentes. Este enfoque traslada la carga de compatibilidad de los clientes de API al proveedor de datos.
Esta solución sigue dependiendo de que el servicio de redirección de Google permanezca disponible para el recolector. También presupone que el comportamiento actual de las respuestas se mantendrá estable. Google no ha asumido ningún compromiso sobre ninguna de esas condiciones.
Los productos de búsqueda e investigación con IA enfrentan otra forma de presión. Algunos sistemas utilizan API de búsqueda comerciales, mientras otros recopilan páginas de resultados mediante su propia infraestructura. Ambos enfoques dependen de un acceso predecible a las URL de origen.
La redirección no impide que un modelo lea un destino después de que alguien se lo proporcione. Afecta al proceso previo de descubrimiento que encuentra, clasifica y recupera fuentes antes de que comience el análisis.
Los trabajadores del conocimiento pueden percibir el efecto de forma indirecta. Un asistente de investigación puede pasar por alto fuentes cuando su conector de búsqueda gestiona mal las URL de redirección. También puede almacenar envoltorios de Google donde los usuarios esperan enlaces estables de los editores.
Esto hace que la procedencia sea más difícil de inspeccionar. Un registro de investigación fiable debería conservar la página que respaldó una afirmación, no una dirección temporal de enrutamiento propiedad del motor de búsqueda.
Por tanto, los equipos que desarrollan sistemas internos de investigación deberían mantener la identidad de la fuente separada de los metadatos de descubrimiento. Una base de conocimiento de IA con capacidad de búsqueda solo sigue siendo útil cuando sus citas se resuelven en documentos duraderos.
La presión inmediata recae sobre los intermediarios de datos de búsqueda. El riesgo posterior alcanza a cualquier producto que trate su salida como una infraestructura de fuentes fiable.
La verdadera disputa es entre resultados abiertos y resolución controlada
Google sigue publicando una página de resultados legible, pero controla cada vez más las acciones necesarias para convertir esa página en datos reutilizables.
No se trata simplemente de Google frente a una empresa de scraping. La principal disputa enfrenta dos modelos técnicos de acceso a resultados de búsqueda de cara al público.
El primer modelo trata una página de resultados como un documento. Un cliente la descarga, lee los enlaces incrustados en el HTML y decide qué hacer después. Gran parte de la web temprana funcionaba mediante este patrón sencillo.
El segundo modelo trata los resultados como un servicio interactivo. Lo que el usuario ve sigue siendo accesible, pero los valores importantes solo están disponibles mediante solicitudes adicionales regidas por la plataforma.
El despliegue de /goto acerca Google Search al segundo modelo. Lo hace sin eliminar los resultados orgánicos ni obligar a los usuarios normales a adoptar un nuevo flujo de trabajo.
Esta sutileza es importante. Calificar la actualización como una prohibición del scraping exagera su efecto. Los enlaces siguen pudiendo resolverse, y las pruebas independientes muestran que los desarrolladores aún pueden recuperar sus destinos.
ScrapingBee probó /goto en navegadores, sesiones automatizadas y configuraciones de red. Sus experimentos de redirección concluyeron que el token podía decodificarse estructuralmente, pero no convertirse localmente en la URL original.
La empresa informó de que una solicitud HTTP GET con las redirecciones automáticas desactivadas devolvía una respuesta 302 y una cabecera Location. Esa cabecera contenía la dirección de destino.
Sus pruebas también determinaron que las solicitudes HEAD se comportaban de forma distinta. Devolvían respuestas 200 sin la cabecera de ubicación necesaria, obligando a los recolectores a usar GET para una resolución fiable.
Ese hallazgo entra en conflicto con la recomendación inicial de Autom de leer la ubicación usando HEAD. La diferencia puede reflejar cambios de comportamiento, condiciones de prueba o múltiples variantes del despliegue.
Los desarrolladores no deberían tratar ninguno de los métodos como un contrato permanente. Una implementación defensiva puede probar el comportamiento de las respuestas, admitir más de un envoltorio y registrar los fallos sin corromper las URL almacenadas.
ScrapingBee midió 50 resoluciones con una mediana de aproximadamente 3,27 segundos cuando se procesaban de forma secuencial. Cinco workers redujeron la mediana a aproximadamente 1,23 segundos en su entorno.
Estas cifras proceden de las pruebas de un proveedor, no de una referencia universal. La ubicación de red, la reutilización de conexiones, las respuestas de Google y la limitación de solicitudes pueden producir resultados diferentes.
Aun así, el experimento aclara la compensación. La actualización añade fricción, pero una concurrencia moderada puede absorber parte de ella. Eso hace más probable que la medida transforme los costes en lugar de eliminar el scraping.
La interacción con el servidor también brinda a Google opciones que los enlaces estáticos no ofrecían. Puede ajustar las respuestas, cambiar formatos de token, aplicar controles de velocidad o distinguir entre tipos de cliente.
Google ya controla la propia página de resultados de búsqueda. Sin embargo, las URL salientes directas limitaban la participación de la empresa después de que un cliente recibiera el HTML. /goto extiende esa participación a la resolución del destino.
El cambio sigue otros esfuerzos que han complicado la recopilación a gran escala. Google ha reforzado las defensas contra el tráfico automatizado y ha cambiado parámetros de las páginas de resultados que los recolectores utilizaban anteriormente para conjuntos de resultados más grandes.
Cada ajuste individual puede sortearse mediante ingeniería. En conjunto, hacen que el acceso no oficial sea menos predecible y aumentan el valor de una infraestructura de recopilación mantenida.
Este cambio también expone una simetría incómoda. Google construye su índice rastreando otros sitios web, mientras restringe los sistemas automatizados que recopilan la presentación que Google hace de ese índice.
Las actividades no son idénticas. Googlebot sigue los controles de los editores, construye un producto de búsqueda y opera bajo sistemas de rastreo documentados. Los scrapers de SERP recopilan las páginas de clasificación generadas por Google, a menudo fuera de una relación con una API compatible.
Aun así, los editores y desarrolladores perciben el desequilibrio. Google espera que la web abierta siga siendo técnicamente accesible mientras hace que su propia capa de agregación sea progresivamente más difícil de reutilizar.
Un muy comentado hilo de la comunidad reflejó esa disputa. Alcanzó 472 puntos y 369 comentarios en la instantánea proporcionada con esta historia.
Algunos participantes consideraron la actualización una protección razonable del servicio. Otros la describieron como otro cercamiento en torno a información derivada de sitios web públicos. Varios se centraron en el desafío práctico de ingeniería en lugar del debate sobre políticas.
La interpretación más sólida se sitúa entre ambas posturas. Google no ha cerrado sus resultados de búsqueda, pero ha hecho que la reutilización a gran escala dependa más de interacciones controladas por Google.
La actualización añade fricción, no un bloqueo total del scraping
La mayor incertidumbre es si `/goto` seguirá siendo un formato de redirección manejable o se convertirá en una capa de un sistema de aplicación más estricto.
El mecanismo actual tiene límites visibles. Un scraper puede solicitar cada redirección y leer su destino. Algunas copias de la URL subyacente también pueden permanecer en otras partes de la página renderizada.
Google necesita información de destino para mostrar dominios, favicons, migas de pan y atribución. Según el formato del resultado, los recopiladores pueden reconstruir parte de la identidad sin resolver cada enlace.
Eso no siempre produce la página de destino exacta. Un dominio mostrado no puede distinguir una página de producto de un artículo de soporte en el mismo sitio. El texto de las migas de pan también puede omitir parámetros o componentes de la ruta.
El despliegue tampoco es uniforme. ScrapingBee informó de /goto en Chrome, Edge, Playwright y su propio entorno de recopilación. Brave y LibreWolf devolvieron enlaces directos durante el mismo esfuerzo de pruebas.
Safari devolvió otro envoltorio de Google en lugar del mismo formato /goto. Cambiar la ubicación del proxy no eliminó la redirección de forma fiable.
Estos resultados sugieren variaciones entre clientes, pero no revelan las reglas de selección de Google. El tipo de navegador puede correlacionarse con el resultado sin causarlo directamente.
Los tokens también parecían portables en las pruebas de ScrapingBee. Los tokens recopilados mediante una conexión podían resolverse más tarde a través de otro cliente sin las cookies ni el proxy originales.
Siguieron siendo utilizables durante más de 24 horas en esos experimentos. Se desconoce su vida útil máxima, y Google podría cambiar las reglas de portabilidad o expiración sin previo aviso.
Esa incertidumbre debería orientar las decisiones de ingeniería. Un recopilador de producción no debería almacenar tokens opacos como si fueran identificadores permanentes. Debe resolver y validar los destinos cerca del momento de recopilación.
También debería conservar el envoltorio original para diagnóstico. Mantener ambos valores ayuda a los equipos a distinguir un cambio de clasificación de un fallo del resolvedor o de una nueva variante de respuesta de Google.
Los reintentos requieren límites cuidadosos. Una resolución agresiva puede amplificar el patrón de solicitudes que el cambio parece diseñado para detectar. Los reintentos sin límite también pueden generar costes mayores durante interrupciones parciales.
Los sistemas de recopilación deberían deduplicar los tokens idénticos antes de resolverlos. ScrapingBee encontró tokens repetidos en algunas páginas de resultados, lo que permite evitar solicitudes duplicadas innecesarias.
Los proveedores también necesitan monitorización en varios límites. Deberían seguir la proporción de resultados que usa cada envoltorio, las tasas de éxito de resolución, los códigos de respuesta y las distribuciones de latencia.
Un aumento repentino de URL de Google en la salida para clientes es un incidente de análisis, no una prueba de que los editores hayan desaparecido de la búsqueda. Separar esas condiciones evita falsas alarmas sobre las clasificaciones.
Los equipos de analítica tienen una pregunta distinta. Quieren saber si la redirección modifica la atribución de referencias cuando una persona llega al sitio de un editor.
Una redirección del lado del servidor aún puede llevar al destino esperado y preservar señales de referencia utilizables. La atribución real depende del comportamiento del navegador, los encabezados, la configuración de analítica y la implementación de Google.
No existe una base verificada para afirmar que el despliegue destruye ampliamente la atribución orgánica. Los operadores de sitios deberían inspeccionar sus propias solicitudes de llegada y clasificaciones analíticas antes de sacar esa conclusión.
La guía general sobre redirecciones de Google explica cómo interpreta su rastreador los tipos comunes de redirección. No documenta /goto como una superficie de integración pública para recopiladores de terceros.
Esa diferencia importa. La documentación de Google Search Central indica a los editores cómo redirigir sus propias páginas. No promete un comportamiento estable para los envoltorios de enlaces salientes de Google Search.
Los usuarios enfrentan una disyuntiva menor pero real. Al pasar el cursor sobre un resultado, pueden ver una dirección de Google en lugar del destino completo. El dominio mostrado aún aporta contexto, pero la vista previa de estado del navegador resulta menos informativa.
Eso puede debilitar una comprobación de seguridad habitual. Un usuario prudente puede querer inspeccionar el destino exacto antes de abrirlo, especialmente cuando varias páginas comparten títulos similares.
Google puede argumentar que sus etiquetas de dominio visibles y sus protecciones contra abusos siguen siendo eficaces. Los críticos pueden responder razonablemente que una etiqueta controlada por la plataforma no equivale a inspeccionar el enlace real.
Ninguna de las dos preocupaciones demuestra que el despliegue perjudique a la mayoría de los usuarios. Muestra que las medidas contra la automatización pueden alterar la transparencia incluso cuando la experiencia de clic parece no cambiar.
La evidencia actual respalda una conclusión limitada. /goto eleva los costes de recopilación, rompe analizadores simplistas y amplía el control de Google sobre la resolución de destinos.
No respalda la afirmación más contundente de que Google ha hecho imposible el scraping de búsquedas. Los proveedores ya han demostrado rutas de resolución funcionales, aunque esas rutas conllevan nuevos riesgos operativos.
Lo que la actualización anti-scraping de Google obliga a los equipos a vigilar a continuación
Tres señales determinarán si esto se convierte en una actualización rutinaria de analizadores o en un cambio duradero en la economía de los datos de búsqueda.
La primera señal es la cobertura del formato de enlaces. Los proveedores deberían medir con qué frecuencia aparecen URL directas, envoltorios /url y tokens /goto en distintos navegadores, regiones y estados de sesión.
Una combinación estable reforzaría la idea de que Google opera un sistema de control segmentado. Un movimiento rápido hacia enlaces /goto universales reforzaría la interpretación anti-scraping.
Una reversión hacia enlaces directos debilitaría la conclusión más amplia. Sugeriría que los problemas de compatibilidad, las preocupaciones de los usuarios o los resultados experimentales pesaron más que el control adicional.
La segunda señal es el comportamiento del resolvedor. Los equipos deberían seguir si una simple solicitud GET continúa devolviendo un encabezado 302 Location utilizable sin una sesión de navegador.
Si esa ruta permanece disponible, los proveedores experimentados pueden tratar la actualización como un coste adicional de infraestructura. Los scrapers básicos dejarán de funcionar, pero los sistemas mantenidos pueden seguir operando.
Nuevos requisitos de autenticación, vidas útiles cortas de los tokens, límites de tasa estrictos o tokens vinculados al cliente aumentarían materialmente la barrera. Indicarían que Google está endureciendo el punto de control en lugar de limitarse a reescribir enlaces.
Los cambios en el comportamiento de HEAD y GET también merecen atención. Los primeros informes contradictorios muestran por qué los proveedores necesitan pruebas directas en lugar de depender de una única receta de implementación.
La tercera señal es la calidad de los datos dentro de los productos de SEO e IA. Los clientes deberían vigilar páginas de destino ausentes, URL de Google duplicadas, volatilidad de clasificación sin explicación o citas que se detengan en envoltorios de redirección.
Estos síntomas demostrarían que algunos proveedores no se han adaptado por completo. Una salida estable sugeriría que los proveedores absorbieron el cambio sin trasladar mucha carga a los clientes.
Los compradores de datos de búsqueda deberían formular preguntas concretas a los proveedores. ¿El servicio devuelve el destino final? ¿Conserva los parámetros canónicos? ¿Cómo etiqueta los resultados no resueltos?
También deberían preguntar si las posiciones informadas cambiaron debido al formato del enlace. Una herramienta de clasificación debe separar los errores de recopilación de los movimientos reales en el ordenamiento de Google.
Los equipos de productos de IA necesitan comprobaciones similares en torno a las citas. Cada afirmación recuperada debería conectar con la URL final del editor, con los fallos de recopilación visibles para los operadores.
La próxima declaración pública de Google también importa, aunque la empresa podría ofrecer pocos detalles adicionales. Una explicación formal sobre la protección de usuarios o las categorías de abuso acotaría el debate sobre la intención.
La declaración actual confirma que /goto es una medida de protección. No dice si los rastreadores de IA, las herramientas de SEO, la medición de clics u otra clase de abuso motivaron el diseño.
Los conflictos legales podrían aportar más contexto. Google ha impugnado a algunas empresas que recopilan y revenden resultados de búsqueda, lo que muestra que los controles técnicos coexisten con la presión legal.
Sin embargo, /goto afecta a una gama más amplia de clientes que cualquier demandado individual. Investigadores, herramientas de accesibilidad, extensiones de navegador y sistemas internos de monitorización pueden encontrar los mismos envoltorios.
Los próximos meses revelarán si Google distingue entre esos usos. Las restricciones uniformes favorecerían a los proveedores centralizados de datos que puedan mantener grandes sistemas de resolución.
El acceso selectivo podría producir un mercado distinto. Los socios compatibles y las interfaces aprobadas ganarían importancia, mientras que la recopilación no oficial sería menos fiable.
Para los desarrolladores, la respuesta inmediata es sencilla. Traten los enlaces de resultados de búsqueda como datos variables, validen los destinos, conserven el contexto de diagnóstico y supervisen los fallos del resolvedor por separado de los cambios de clasificación.
Para los compradores, la tarea es verificar. Pregunten si su proveedor de SEO, monitorización o investigación se ha adaptado antes de confiar en un cambio inesperado en sus informes.
Para los trabajadores del conocimiento, revisen las citas cuando un sistema de investigación automatizado devuelva un envoltorio de Google. Una respuesta útil debería conducir a la fuente subyacente, no detenerse en la capa de enrutamiento del motor de búsqueda.
Google.com/goto: la actualización anti-scraping de Google no es, por tanto, ni un bloqueo total ni una redirección cosmética. Es una barrera arquitectónica colocada en un punto valioso de la cadena de datos de búsqueda.
Observe si esa barrera sigue suponiendo una solicitud barata. Si incorpora comprobaciones de identidad más estrictas, tokens de vida más corta o límites más ajustados, la reparación del analizador de hoy se convertirá en una disputa de acceso mayor.
