LUNES 21 SEPTIEMBRE 2026Newsletter ☕
Rrankeandola.com
Inicio / Noticias / Industria SEO

Google penalizará el secuestro del botón ir atrás y cómo proteger tu sitio después de junio de 2026

Google amplía sus políticas de SPAM para prohibir de forma explícita el back button hijacking, con dos meses de margen para que los editores auditen su código antes de que empiecen las sanciones.

Caro Echeverri
Caro Echeverri | Co-fundadora, estratega SEO & GEO
· 9 min de lectura
𝕏in🔗
Ilustración sobre las nuevas políticas de Google contra prácticas engañosas de navegación, con un usuario pulsando el botón atrás del navegador y avisos sobre experiencia de usuario y cumplimiento de directrices.

Google ha ampliado sus políticas de SPAM para prohibir de forma explícita el back button hijacking o secuestro del botón atrás y lo ha metido en la misma categoría que el malware. La decisión se anunció el 13 de abril de 2026 en el Google Search Central Blog a través de un comunicado firmado por Chris Nelson en representación del equipo de calidad de Google Search y las sanciones automáticas y manuales empezarán a aplicarse el 15 de junio de 2026. Dos meses de margen para poner la casa en orden, eh?

Si gestionas un sitio web, supervisas la estrategia SEO de un cliente o administras la monetización de un medio digital, esta actualización te toca, porque Google ha definido con precisión la práctica y la ha clasificado como violación explícita bajo la categoría de prácticas maliciosas (malicious practices), la misma en la que viven el malware y el software dañino. 

Esto es un salto cualitativo importante respecto a versiones anteriores de la política, donde esta conducta vivía en una zona gris.

La razón detrás del movimiento es proteger la experiencia de usuario y preservar la confianza en el ecosistema web, quizá Google se cansó de años de abusos técnicos donde ciertos editores y redes publicitarias han manipulado el historial de los navegadores para obligar a los usuarios a permanecer en sus páginas, consumir anuncios no solicitados o ser redirigidos a ofertas de afiliación sin su consentimiento.

Te contamos lo que quiere decir esto y cómo puedes proteger a tu web. 

Qué es el back button hijacking y cómo funciona técnicamente

Cuando alguien navega por internet y hace clic en el botón atrás del navegador, tiene una expectativa lógica y predecible de volver inmediatamente a la página donde estaba antes que normalmente es la página de resultados de Google. 

Captura de pantalla de Google Chrome con la página principal de Google y una flecha roja señalando el botón «Ir Atrás» del navegador.
Diseño y dirección editorial Rankeandola. Imagen creada con asistencia de IA (ChatGPT).


El secuestro del botón atrás rompe esta expectativa de navegación de forma intencionada, porque ocurre cuando un sitio web intercepta los eventos de navegación del usuario y bloquea su capacidad para regresar a la fuente original y en lugar de permitir la salida limpia, la web ejecuta scripts que manipulan la pila de historial del navegador, o browser history stack.

Comparativa entre una navegación web normal y el secuestro del botón atrás, mostrando cómo una práctica engañosa altera el historial para redirigir al usuario a una página no visitada.
Diseño y dirección editorial Rankeandola. Imagen creada con asistencia de IA (ChatGPT).


Las manifestaciones más habituales de la práctica de back button hijacking 

Hay cuatro patrones que Google va a perseguir activamente como la inyección de páginas no visitadas en el historial mediante llamadas a la API de historial de HTML5, del tipo history.pushState o history.replaceState, que agregan entradas ficticias al historial del navegador para que cuando el usuario pulse atrás retroceda a una URL duplicada o a una landing interna que jamás visitó. 

La redirección forzada a ofertas o publicidad, donde el código escucha el evento popstate y ejecuta un redireccionamiento automático hacia una página con anuncios flotantes u ofertas de afiliación. 

Los bucles infinitos de navegación, donde el sitio captura el intento de retorno y recarga la misma página con parámetros cambiados, obligando al usuario a hacer clic decenas de veces seguidas en atrás para escapar. 

Y los popunders y ventanas emergentes agresivas que se disparan al retroceder, reteniendo la atención del usuario contra su voluntad. A ver qué vamos a hacer los medios de comunicación que vivimos de esta práctica 😂, se nos acabó la fiesta. 

Desde el diseño de experiencia de usuario, estas técnicas son un dark pattern de manual que frustran al usuario, degradan la percepción de la marca que aloja el script y generan una sensación de engaño que, como señala el propio Chris Nelson en el comunicado oficial, hace que los usuarios pierdan la disposición a visitar sitios que no conocen.

Bueno, ya sabes que la Experiencia en el E-E-A-T atrapa todas estas facetas técnicas, aquí te contamos cómo funcionan las políticas de Google sobre Experiencia, Expertise, Autoridad y Confianza. 


Los hechos confirmados de la nueva política de Google para evitar que se secuestre el botón de ir atrás

Esto que sigue no es una sugerencia de buenas prácticas ni una recomendación opcional de Core Web Vitals, entonces, ojo 👀, porque Google ha elevado esta conducta al rango de violación explícita de sus directrices para editores y estos son los puntos centrales confirmados en la nota oficial del 13 de abril de 2026.

Aspecto clave

Detalle de la política oficial

Fecha de anuncio

13 de abril de 2026

Fecha de aplicación efectiva

15 de junio de 2026

Clasificación del incumplimiento

Prácticas maliciosas (malicious practices) dentro de las políticas de SPAM de Google Search, misma categoría que el malware

Tipos de sanción aplicables

Acciones manuales (manual actions) y degradaciones automáticas de clasificación (algorithmic demotions)

Mecanismo de recuperación

Corrección técnica y envío de solicitud de reconsideración (reconsideration request) desde Search Console

Responsabilidad técnica

Aplica tanto al código propio como a librerías de terceros o redes de anuncios integradas

Qué son exactamente las prácticas maliciosas

La inclusión del secuestro del botón de ir atrás dentro de esta categoría no es casual, la política sobre prácticas maliciosas de Google establece que estas acciones ocurren cuando existen inconsistencias entre las expectativas legítimas del usuario y el resultado real tras su interacción, provocando una experiencia engañosa, negativa o que pone en riesgo la seguridad y privacidad de quien navega. ¡Ay, qué la UX sea bendecida por siempre! 

Google aclara en su nota que la manipulación del historial para insertar páginas engañosas o de SPAM ya violaba conceptualmente los fundamentos de Google Search Essentials; sin embargo, debido al incremento constante de este comportamiento en la web abierta, la compañía ha considerado imprescindible hacer explicito el secuestro del botón atrás como infracción directa que conllevará pérdida inmediata de visibilidad orgánica.

Quién sale beneficiado y qué modelos de negocio están en riesgo con esta nueva medida

Como pasa con cada actualización de calidad o de políticas de SPAM, los efectos no se distribuirán de forma homogénea, habrá sectores que sufrirán un impacto dramático y otros que verán reforzados en su posicionamiento gracias a ofrecer una navegación limpia. <3

Modelos de negocio en riesgo elevado

Los sitios de arbitraje de tráfico y las redes de contenidos sensacionalistas son los primeros en la línea de fuego. Portales que compran tráfico barato en redes sociales o plataformas de descubrimiento para monetizarlo con densidad extrema de publicidad programática, porque en estos entornos, el secuestro del botón de ir atrás se usa de forma sistemática para forzar una segunda o tercera impresión de anuncios antes de que el usuario logre salir.

Los sitios de afiliación basados en ofertas de salida o exit-intent affiliate sites, también quedan expuestos. Proyectos de recomendación de productos que redirigen el botón atrás hacia enlaces de afiliados de última oportunidad donde la intención comercial era capturar la conversión antes del rebote, pero la implementación técnica mediante alteración del historial pasa a ser penalizable.

Las plataformas de descarga de software y contenido multimedia son otro objetivo claro, porque suelen atrapar al usuario en cadenas de redirecciones tras iniciar una descarga, haciendo imposible volver al motor de búsqueda con un solo clic. ¡Es lo más incómodo del mundo!

El grupo más vulnerable y, probablemente el más numeroso, es el de sitios legítimos que delegan la monetización en redes publicitarias opacas como medios de comunicación o blogs con buen contenido que han implementado etiquetas de publicidad de proveedores secundarios sin verificar la calidad del código. Así que, si un script de terceros inyecta código de back-hijacking para inflar sus propios eCPM, el dominio principal sufre las consecuencias algorítmicas o manuales, aunque nadie del equipo editorial supiera lo que estaba pasando.

Hace unos días analizamos el código de una plataforma de anuncios con video y nos dieron una respuesta de Claude… Ya te digo yo que es que no hay con quién. 😂

Los sitios web ganadores de esta actualización

Los editores orientados a la experiencia del usuario y a la identidad de marca ganan terreno relativo, especialmente los que priorizan retención orgánica basada en calidad del contenido, navegación transparente y tiempos de respuesta rápidos. 

El interlinking bien gestionado será una buena señal para esta nueva capa de la Experiencia. 

También los proyectos adaptados a GEO y AEO, porque en la era de la búsqueda generativa por IA los motores no solo analizan el texto, evalúan también las señales implícitas de interacción y satisfacción del usuario. Así que, los sitios que respetan el control de la navegación refuerzan sus señales de confianza, aumentan su probabilidad de ser citados en respuestas generativas.

Tres implicaciones prácticas para la estrategia de SEO de esta política

La primera es que la UX de salida ya es un factor directo de SPAM duro. Tradicionalmente, la optimización para los buscadores se centraba en cómo el usuario entra y consume la página, pero a partir del 15 de junio de 2026, la forma en que la página permite la salida del usuario es formalmente revisada por los algoritmos de detección de spam. Nos cambia el marco.

La segunda es que los equipos de SEO ya no pueden trabajar aislados del área de desarrollo (que nunca deberían hacerlo, porque casi que el 60 % del SEO es técnico más que estratégico, aunque muchos me funen por decirlo) y de la monetización, porque un script publicitario introducido por el equipo de ventas puede arruinar meses de trabajo de posicionamiento orgánico y la única forma de evitarlo es que el stack tecnológico se revise de forma coordinada.

La tercera es que una acción manual por prácticas maliciosas suele desindexar o desplazar severamente las URLs afectadas de las SERPs, reduciendo el tráfico orgánico a niveles marginales hasta que el problema sea subsanado y aprobado por el equipo de calidad, como pasa cuando tienes mucho contenido en temáticas penalizables como casinos, apuestas, pornografía y similares. Es que esto ya representaría una caída dura que se siente en los resultados de forma inmediata. 

Lo que nunca deberías hacer en tu web

Frente a un anuncio de esta magnitud es habitual que algunos desarrolladores o consultores SEO intenten buscar atajos técnicos para preservar los ingresos por publicidad o la retención forzada sin ser detectados, pero nosotros creemos que hay cosas que, definitivamente, no se deberían hacer. 

Camuflar la manipulación con detección de user-agents

Oh! ya los vi. Crear condicionales en JavaScript para que la alteración del historial solo se ejecute cuando el usuario sea un humano en un dispositivo móvil y se desactive cuando Googlebot inspeccione la página es una pésima idea. 

Esta práctica se encuadra dentro del cloaking, una de las infracciones más graves y penalizadas históricamente por Google, porque los sistemas de evaluación de calidad usan renderizadores dinámicos e inspecciones basadas en comportamiento real de usuario, no solo el user-agent declarado.

Sustituirlo por modales invasivos de intercepción a la salida del usuario

Cambiar la inyección de historial por scripts agresivos de beforeunload que desplieguen diálogos emergentes bloqueantes del tipo seguro que deseas salir, mira esta oferta, no resuelve el problema de fondo. 

Aunque un evento beforeunload nativo del navegador es técnicamente distinto a manipular la API history, el uso de popups engañosos o bloqueos de interfaz también contraviene las directrices generales de experiencia en la página de Google Search.

Asumir que tu proveedor de anuncios se encarga de todo

Muchas redes de publicidad programática de segundo nivel o intercambios de tráfico prometen maximizar el eCPM mediante tecnologías avanzadas de retención; pero en la práctica, muchas de estas soluciones se basan precisamente en el secuestro del botón de ir atrás. Así que confiar ciegamente en que el proveedor de anuncios corregirá el código por su cuenta expone a tu sitio web a una sanción directa que llegará al dominio principal, no al proveedor.

Ignorar la revisión de bibliotecas y plugins antiguos

Si utilizas gestores de contenido como WordPress, Shopify o Drupal, es común tener instalados plugins antiguos de exit popup, social share bar o lead generation que no se han actualizado en años. De verdad. 

Muchos de estos complementos usaban manipulaciones de history.pushState para forzar vistas de página adicionales y dejarlos activos por desidia puede desencadenar una acción manual inesperada por un código que ni siquiera recordabas tener instalado.

Framework de auditoría y remediación técnica para evitar el secuestro del botón de ir atrás

Para garantizar que tu sitio esté limpio y protegido desde el 15 de junio de 2026, este es el proceso de auditoría técnica que estamos ejecutando en Rankeandola. Siéntete libre de decirnos si lo harías mejor o si hay algo que debemos mejorar en este proceso para que sea casi, casi “infalible”.

Captura de Chrome DevTools que muestra cómo detectar el secuestro del botón atrás revisando eventos popstate, hashchange y modificaciones de la API History como pushState y replaceState.
Diseño y dirección editorial Rankeandola. Imagen creada con asistencia de IA (ChatGPT).

Paso 1. Auditoría de código en el frontend

El equipo de desarrollo frontend debe realizar una búsqueda exhaustiva en los archivos fuente JavaScript identificando las llamadas a la API del navegador de tipo window.history.pushState, window.history.replaceState, window.addEventListener con evento popstate y window.onpopstate.

No toda llamada a pushState o replaceState es SPAM, las aplicaciones de una sola página construidas con React, Vue, Angular, Next.js o similares usan legítimamente estas APIs para actualizar la URL visible cuando el usuario navega dinámicamente entre secciones sin recargar la página. 

La regla de oro que aplica Google es esta, el uso de la API de historial es legítimo si refleja la navegación real del usuario dentro de la aplicación y es SPAM si inserta URLs no solicitadas, impide volver a la página de origen o cambia el destino del botón atrás a un sitio de terceros o contenido publicitario.

Paso 2. Auditoría de scripts de terceros

Como el aviso de Google resalta que muchas incidencias vienen de bibliotecas integradas, hay que inventariar y probar todos los scripts externos. A ver, que sé que la documentación es una pesadilla, pero sí que creemos que documentar es la única manera de sobrevivir a los peligros. 

Redes de monetización publicitaria, incluidos scripts de cabecera de header bidding, proveedores de anuncios nativos y widgets de contenido recomendado; herramientas de analítica y CRO, incluidos scripts de mapas de calor, herramientas de A/B testing y widgets de captación de leads. 

Y todas las etiquetas integradas a través de Google Tag Manager, especialmente las de código personalizado con HTML custom dentro de los contenedores.

Paso 3. Prueba de navegación limpia en dispositivos reales

La verificación manual sigue siendo la más honesta, así que abre una ventana de incógnito en tu navegador, entra a Google, busca una palabra clave donde posiciona tu sitio web, haz clic en el resultado, interactúa brevemente con la página desplazándote y haciendo clic en elementos visuales y pulsa el botón atrás una sola vez. 

El resultado esperado es volver inmediatamente a la SERP de la que partiste, si la página se recarga, abre un anuncio, cambia la URL pero te mantiene en el sitio o te dirige a otra landing, tienes una vulnerabilidad que hay que corregir. Repite la prueba en desktop, iOS y Android, porque muchos scripts se activan solo en móvil.

Paso 4. Protocolo en caso de recibir una acción manual por parte de Google

Si después del 15 de junio de 2026 detectas una bajada fuerte de tráfico o recibes una notificación en Search Console, entra a Seguridad y acciones manuales en el panel lateral, lee el informe específico donde se indicará el incumplimiento por prácticas maliciosas y secuestro del botón atrás, identifica y elimina el script, plugin o red publicitaria causante, realiza los despliegues en producción verificando la corrección en todas las plantillas del sitio y finalmente haz clic en solicitar revisión en Search Console. 

En esa solicitud proporciona una explicación transparente y detallada de la causa técnica identificada, las medidas correctivas adoptadas y la confirmación de que el sitio cumple estrictamente con las políticas de spam. Cuanto más específica sea la explicación, más rápida suele ser la revisión.

Captura de Google Search Console con el informe de rendimiento de búsqueda y flechas señalando la sección de Seguridad y acciones manuales y la opción Acciones manuales.
Diseño y dirección editorial Rankeandola. Imagen creada con asistencia de IA (ChatGPT).

Cómo pasar de retener al usuario con “trampas” a construir autoridad real

No debemos analizar esta actualización de forma aislada como un simple cambio reglamentario de Google, porque representa la aceleración de una tendencia que ya casi que es imparable en la evolución del marketing digital, la erradicación de técnicas de fricción y la priorización de la experiencia del usuario como factor de ranking central.

Durante años, parte del sector del SEO y la monetización web funcionó bajo la métrica obsesiva de retener la sesión como sea; se pensaba que forzar una página vista adicional mediante un truco técnico mejoraba las métricas de permanencia o aumentaba el inventario publicitario disponible, pero la realidad ha demostrado justo lo contrario en tres frentes:

  • La retención forzada destruye la lealtad de marca, porque un usuario atrapado por una táctica engañosa no consume el contenido de forma receptiva, su única prioridad cognitiva es encontrar la manera de cerrar la pestaña o huir del sitio y la tasa de rechazo posterior de esa marca se dispara. Las métricas infladas distorsionan tus datos de analítica. 

  • Forzar impresiones mediante redirecciones falsas altera las métricas de pageviews, pages per session y bounce rate en GA4, entregándote datos falsificados sobre el rendimiento real de tu audiencia. 

  • El ecosistema GEO y AEO exige máxima fiabilidad, porque si un sitio es etiquetado como fuente de patrones oscuros o SPAM de navegación, perderá la capacidad de ser citado como fuente de autoridad en los resúmenes generativos y esa capacidad no se recupera fácilmente ni corrigiendo el problema.

El cambio estratégico que sí creemos que se debe implantar es pasar de una mentalidad de captura agresiva a una de atracción por valor. 

Si quieres que el usuario permanezca en tu sitio cuando intenta salir, no bloquees su navegador, ofrécele navegación contextual interna relevante, arquitectura de información clara, enlaces recomendados de alto valor y un rendimiento técnico impecable. 

Todo lo demás se conviertió, a partir del 15 de junio, en un riesgo de negocio con nombre y apellidos.

Qué hacer si trabajas SEO en mercados de habla hispana

La política se aplica globalmente, lo que quiere decir que no hay una versión suave para España ni una versión dura para Latinoamérica. Sin embargo, hay dos escenarios operativos que merece la pena tener en cuenta si trabajas con mercados hispanohablantes.

Primero, el mercado hispanohablante concentra un volumen importante de sitios monetizados con redes de publicidad de segundo y tercer nivel, especialmente en portales de descarga, contenido sensacionalista y afiliación. 

Esos sitios están estadísticamente más expuestos que los medios de referencia en inglés y muchos de sus propietarios no leen las notas oficiales de Google Search Central hasta que el tráfico ya se cayó. Si trabajas SEO para clientes en este segmento, el próximo mes debería incluir una conversación explícita sobre esto.

Segundo, la ventana de dos meses terminó en agosto, más o menos, y en Latinoamérica coincide con un periodo intenso de campañas comerciales. Entonces, esperar a después para auditar es esperar la sanción. 

La revisión conviene hacerla pronto, cuando aún exista margen de despliegue y pruebas sin presión de calendario comercial.

Banner de diagnóstico SEO con una lupa auditando un sitio web según criterios de Google como contenido útil, experiencia de usuario, datos estructurados, seguridad y privacidad.


Caro Echeverri
SOBRE QUIEN ESCRIBE
Co-fundadora, estratega SEO & GEO

18 años ayudando a las marcas a lograr mejores resultados digitales a través de SEO para generar ventas, embudos de conversión digital, procesos comercial y de captación.

Sigue leyendo