Detección del secuestro del botón atrás: guía de auditoría SEO técnica

Un sitio web que atrapa a sus visitantes solía ser simplemente una mala experiencia de usuario (UX). Ahora es una infracción por spam. Google ha incorporado el secuestro del botón atrás (back button hijacking) en su política de Prácticas Maliciosas, lo que cambia las prioridades de cualquier auditoría SEO técnica. Si su proceso de rastreo todavía trata esto como un caso aislado para el equipo de seguridad, es momento de incluirlo en su lista de tareas estándar.

Esta guía detalla qué aspectos cubre realmente esta política de Google, por qué la mayoría de los rastreadores no son capaces de detectar el problema y cómo auditarlo de manera práctica en todo un sitio web con miles de URL sin tener que pagar un coste adicional por el renderizado de JavaScript.

Qué cubre ahora la política de Prácticas Maliciosas de Google

El secuestro del botón atrás consiste en una manipulación del historial del navegador. Una página se carga y, en lugar de permitir que el usuario haga clic en “atrás” y regrese a los resultados de búsqueda o a la página anterior de la que venía, el sitio intercepta esa acción. Se fuerza al usuario a avanzar de nuevo, a menudo hacia un anuncio, una página intermedia (interstitial) o un sitio de baja calidad que nunca solicitó visitar.

Google solía tratar esto principalmente como una señal de experiencia de usuario oculta dentro de sus evaluaciones de calidad más generales. Al incluirlo explícitamente en su política de Prácticas Maliciosas, lo sitúa en la misma categoría que las redirecciones engañosas y el encubrimiento (cloaking). Se trata de un cambio muy importante: ya no es solo “molesto”, sino que se clasifica como una infracción directa, lo que puede desencadenar una acción manual o una degradación algorítmica por sí sola.

Para los propietarios de sitios web, esto significa que la vieja excusa de “es solo cosa de la red de anuncios, no nuestra” ya no es válida. Si este comportamiento se ejecuta en su dominio, es su responsabilidad directa solucionarlo, independientemente del script de terceros que lo haya causado. Un ejemplo común en el mundo real: un medio de comunicación inserta un reproductor de vídeo de terceros y el contenedor de anuncios de ese reproductor reescribe el historial del navegador al cargarse. El editor del sitio nunca escribió ese código, pero la infracción aparecerá igualmente en su Search Console. Las redes de anuncios, las rutas mal configuradas en aplicaciones de página única (SPA) y los scripts de retención agresivos son los sospechosos habituales; y los tres ejecutan este comportamiento mediante JavaScript en el lado del cliente.

Por qué la mayoría de los rastreadores no detectan este problema

El mecanismo detrás del secuestro del botón atrás se ejecuta casi siempre a través de la History API del navegador, específicamente mediante las funciones history.pushState() y history.replaceState(). Estas funciones permiten que una página reescriba el historial de sesión del navegador sin necesidad de recargar la página por completo. Si se utilizan correctamente, dan soporte a la navegación fluida en las aplicaciones de página única modernas. Si se usan de forma maliciosa, insertan entradas falsas en el historial para que, al pulsar el botón atrás, el usuario no regrese a donde esperaba.

Aquí radica el problema de la auditoría: esta manipulación ocurre por completo en JavaScript, después de que se haya cargado el HTML inicial. Un rastreador (crawler) que solo descarga el HTML sin procesar nunca ejecuta los scripts, nunca detecta las llamadas a pushState y reporta que la página está perfectamente limpia. Podría realizar un rastreo completo del sitio, obtener cero errores y, aun así, tener una infracción de políticas que los sistemas de Google sí detectan, ya que Google renderiza las páginas simulando el comportamiento de un navegador real.

Esta brecha técnica es exactamente lo que ha convertido al renderizado de JavaScript en una función premium en la mayoría de los rastreadores comerciales. Los proveedores saben que el procesamiento de renderizado es costoso a gran escala, por lo que limitan su uso, ya sea por número de URL o restringiéndolo a planes de pago costosos. Este modelo de precios crea un punto ciego para cualquiera que audite un sitio web grande con una versión gratuita: se obtienen resultados basados en HTML estático y una falsa sensación de seguridad. Para analizar detalladamente cómo gestionan los rastreadores este equilibrio de costes, puede consultar nuestra comparativa de alternativas a Screaming Frog, donde explicamos en qué herramientas se restringe el renderizado de JS.

Seodisias renderiza JavaScript en su versión gratuita y sin límites de URL, por lo que este tipo de problemas aparece en un rastreo estándar, sin necesidad de contratar una auditoría de pago independiente.

Una lista de verificación práctica para auditar el secuestro del botón atrás

Abrir manualmente las herramientas de desarrollo y observar la pila de historial funciona para una sola página, pero no es viable para un sitio con diez mil URL. Esto es lo que debe comprobar en una auditoría y por qué es importante cada punto:

Comprobar window.history.length al cargar la página. Una carga de página legítima normalmente añade una sola entrada al historial del navegador. Si una página genera múltiples entradas en el mismo instante en que se carga, antes de cualquier interacción del usuario, es una señal clara de que se está precargando un historial falso diseñado para interceptar el botón atrás más adelante.

Marcar los scripts de redirección que se activan sin interacción del usuario. El uso legítimo de pushState responde a un clic, a un cambio de pestaña o al envío de un formulario. El uso malicioso a menudo se activa mediante un temporizador o inmediatamente al cargar la página. Un rastreo con renderizado completo permite capturar la secuencia de eventos del historial vinculados a la carga de la página frente a los vinculados a la interacción activa; la diferencia entre ambos es la clave.

Buscar patrones conocidos de ventanas emergentes ocultas (pop-under) y redirecciones en el DOM renderizado y en las fuentes de los scripts. Las redes publicitarias que recurren a esta técnica suelen reutilizar patrones de código reconocibles en muchos sitios. El análisis del contenido renderizado le permite buscar estos patrones en la página ejecutada real, no solo en el código fuente estático, ya que el script infractor suele inyectarse de forma dinámica.

Cruzar los datos con páginas que tengan una alta densidad de anuncios. El secuestro del botón atrás está estrechamente relacionado con configuraciones de monetización agresivas. Si un segmento del rastreo muestra que este comportamiento se concentra en las páginas de una red de anuncios específica o en una plantilla concreta, esa debe ser su prioridad de corrección, en lugar de planificar una reestructuración de todo el sitio web.

La razón por la que este proceso debe ejecutarse como un rastreo automatizado y no como una comprobación manual aleatoria es la escala. Un medio digital o un comercio electrónico con miles de páginas basadas en plantillas puede presentar este problema en un único formato de anuncio y estar libre en el resto del sitio. Esto no se descubre abriendo diez páginas en un navegador; se detecta renderizando todo el sitio web y comparando el comportamiento del historial a través de los diferentes patrones de URL.

Integrar esta comprobación en el flujo de trabajo SEO técnico habitual

Esta verificación no debe ser una reacción puntual ante una actualización de las políticas de Google. Debe formar parte de las auditorías periódicas en las que ya se comprueban enlaces rotos, redirecciones, etiquetas meta ausentes y regresiones en las Core Web Vitals. Si está formalizando este proceso recurrente, nuestra lista de verificación para auditorías SEO con IA es el lugar ideal para añadir el secuestro del botón atrás como un punto permanente, junto con el resto de comprobaciones estructurales que se vuelven a ejecutar tras cada gran despliegue.

También existe un argumento práctico de privacidad para realizar esta comprobación de forma local. Las empresas con acuerdos publicitarios confidenciales o rediseños de sitios web antes de su lanzamiento oficial no siempre quieren que los datos de sus rastreos salgan de sus sistemas. Dado que Seodisias ejecuta el rastreo localmente en Windows, macOS o Linux, los resultados renderizados y cualquier script detectado permanecen en el propio equipo del auditor, en lugar de pasar por un servicio en la nube de terceros. Para las agencias que auditan sitios de clientes bajo acuerdos de confidencialidad (NDA), esto es un aspecto fundamental.

Nada de esto requiere un nuevo presupuesto para herramientas. Solo se necesita orientar el rastreo hacia la señal correcta: el comportamiento de la pila del historial al cargar la página, correlacionado con su inventario de anuncios y scripts, y analizado con un motor que realmente ejecute JavaScript en lugar de omitirlo.

Conclusión

Google no ha inventado un nuevo desafío técnico, sino que ha reclasificado uno ya existente. El secuestro del botón atrás ha sido técnicamente posible desde el lanzamiento de la History API; lo que ha cambiado es que ahora conlleva un riesgo directo de penalización en lugar de ser solo una frustración para la experiencia del usuario. El trabajo de auditoría es sencillo una vez que se dispone de un rastreador que renderiza JavaScript sin restringir esa capacidad detrás de una suscripción de pago o un límite de URL.

Ejecute un rastreo completo de su sitio web con el renderizado de JavaScript activado y compruebe primero el comportamiento del historial en sus plantillas con mayor carga publicitaria. Descargue Seodisias y realice esa auditoría hoy mismo de forma gratuita, local y sin límites de URL.