Lo primero que tengo que decirle es que si usted cree que su web está limpia de prácticas manipuladoras, puede que esté equivocado. Y no por culpa suya, sino por culpa de ese script publicitario que alguien instaló en su sitio hace dos años y del que nadie se ha vuelto a acordar.
El pasado 13 de abril de 2026, Google publicó en su blog de Search Central una ampliación de sus políticas de spam que, por primera vez, señala con nombre y apellidos una práctica concreta: el back button hijacking. A partir del 15 de junio de 2026, cualquier sitio que manipule el botón volver del navegador se enfrentará a acciones manuales o degradaciones automáticas de visibilidad. Dos meses de margen. Ni uno más.
¿Le suena a algo menor? Pues no lo es. Porque Google ha colocado esta práctica en la misma categoría que el malware y el software no deseado: prácticas maliciosas. Es decir, al mismo nivel que lo peor de lo peor en el ecosistema web. Si quiere entender mejor cómo funciona el sistema que decide su visibilidad, le recomiendo echar un vistazo a nuestro artículo sobre las claves del algoritmo de Google.
Prólogo del artículo: Botón volver, trampas invisibles y puertas que no abren
Para entender bien lo que ha ocurrido, sin juntar churras con merinas, tenemos que diferenciar entre un problema de usabilidad y una práctica que Google considera directamente spam.
¿Cómo? ¿Tan grave es? Pues sí.
Y mucho.
Olvídese de las definiciones técnicas. Imagine que entra usted en una tienda, mira un producto, decide que no le interesa y se dirige a la puerta. Pero la puerta no abre. Le redirige a otro pasillo que usted no ha pedido visitar, le muestra un cartel con una oferta que no quiere ver, o simplemente le deja dando vueltas por la tienda sin encontrar la salida.
Me explico 🙂
Eso es exactamente lo que hace el back button hijacking: manipula el historial de navegación de su visitante para que, cuando pulse el botón «Atrás» del navegador, no vuelva a donde esperaba. En lugar de eso, puede acabar en una página que nunca visitó, atrapado en un bucle de recarga, o frente a un intersticial publicitario que no pidió. El usuario siente que le han secuestrado la navegación. Porque, literalmente, se la han secuestrado.
Lo que Google ha hecho esta semana no es inventar un problema nuevo. Es ponerle el sello oficial de spam a algo que llevaba años ocurriendo y que, hasta ahora, vivía en una zona gris de las directrices. Ya en 2013 Google advirtió que insertar páginas engañosas en el historial del navegador iba en contra de sus normas. Pero no había consecuencias formales. Ahora las hay.
Comencemos:
1. Qué es el back button hijacking y por qué debería importarle
¿Cómo funciona técnicamente?
El mecanismo es relativamente sencillo para quien sabe de JavaScript. La API de History del navegador (history.pushState y history.replaceState) permite a cualquier script añadir entradas ficticias al historial de navegación. Cuando el usuario pulsa «Atrás», en lugar de volver a la página anterior real, el navegador recorre esas entradas falsas.
Algunas variantes que he visto en auditorías de clientes a lo largo de los años:
- Inyección masiva de estados en el historial: Un script añade 5, 10 o 20 entradas ficticias al cargar la página. El usuario tiene que pulsar «Atrás» decenas de veces para poder salir.
- Intercepción del evento popstate: El código detecta que el usuario quiere irse y le redirige a una página de ofertas, un formulario de captación o una pantalla de «¿Seguro que quiere irse?».
- Popunders y redireccionamientos en cascada: Al intentar retroceder, se abre una nueva ventana o se fuerza una cadena de redirecciones que acaba en un anuncio.
¿Se acuerda de esos sitios de descargas ilegales donde pulsar «Atrás» era como intentar salir de un laberinto? Pues resulta que esa misma técnica se ha sofisticado y ha llegado a webs que usted y yo consideraríamos «legítimas». Medios de comunicación, tiendas online, blogs con monetización agresiva. Esto va más allá de las técnicas de SEO negativo que ya conocemos: aquí el propio sitio se sabotea a sí mismo.
¿Por qué no es solo un problema de usabilidad?
Porque no estamos hablando de un botón mal colocado o de un menú confuso. Estamos hablando de una manipulación deliberada del comportamiento del navegador. Google lo ha dicho con claridad en su anuncio: las prácticas maliciosas crean una discrepancia entre lo que el usuario espera y lo que realmente ocurre.
Y aquí viene lo importante. Está claro que Google no se mueve solo por altruismo. Si los usuarios dejan de confiar en los resultados de búsqueda porque cada vez que hacen clic en un enlace acaban atrapados, dejan de buscar. Y si dejan de buscar, Google deja de facturar. Por ello, proteger la experiencia post-clic es proteger su propio negocio.
2. Por qué Google actúa ahora: Navboost y la guerra contra las métricas infladas
Hay un ángulo de esta historia que la mayoría de artículos están pasando por alto, y es probablemente el más relevante para los profesionales del SEO.
¿Qué tiene que ver el botón volver con el posicionamiento?
Google utiliza un sistema interno llamado Navboost que mide el comportamiento de los usuarios después de hacer clic en un resultado de búsqueda. Básicamente, analiza señales como el tiempo que pasa el usuario en la página, si vuelve a los resultados de búsqueda (pogo-sticking) y cómo interactúa con el contenido.
La lógica perversa del back button hijacking era sencilla: si el usuario no puede irse fácilmente, pasa más tiempo en la página. Más tiempo en página equivale a una señal de engagement positiva para Google. Mejor señal, mejor posicionamiento. Era, en esencia, una forma de hackear las métricas de comportamiento sin mejorar ni un solo párrafo del contenido.
He visto empresas que no entendían por qué su competidor, con contenido mediocre, les superaba en posiciones. En más de un caso, la respuesta estaba en técnicas como esta: métricas de sesión infladas artificialmente que engañaban a los sistemas de ranking. Si la inteligencia artificial está cambiando el SEO, este tipo de trampas también tenía que evolucionar.
Google cierra ahora esa ventana. Y lo hace de manera explícita, lo que sugiere que SpamBrain —su sistema de detección de spam basado en IA— ya es capaz de identificar este patrón a escala.
¿Qué contexto temporal rodea este anuncio?
No es casualidad. El March 2026 Spam Update terminó su despliegue apenas tres semanas antes de este anuncio. Aquella actualización reforzó las políticas existentes por vía algorítmica. Lo de ahora es diferente: es una ampliación formal de la política escrita, con fecha de enforcement futura.
Juntas, ambas acciones dibujan la hoja de ruta de Google para 2026: acción algorítmica más rápida a través de SpamBrain, y documentación de políticas más explícita para que ningún webmaster pueda alegar ignorancia. ¿Recuerda cuando el update Florida 2 sacudió el SEO en 2019? Pues el nivel de impacto potencial es similar, pero esta vez Google avisa antes de disparar.
Le recomiendo que se grabe esta secuencia: Google ya no avisa una vez y espera. Avisa, documenta y ejecuta. El patrón de dos meses de preaviso es el mismo que usó con la política de site reputation abuse en marzo de 2024.
3. La letra pequeña que nadie lee: el código de terceros también cuenta
Y aquí es donde la cosa se pone realmente seria para la mayoría de los sitios web.
Google ha sido muy claro en su anuncio: algunos casos de back button hijacking pueden originarse en las bibliotecas incluidas del sitio o en la plataforma publicitaria. Pero la penalización recae sobre el dominio, no sobre el proveedor del script.
Me sigo explicando. Usted puede no haber escrito ni una línea de código manipulador. Pero si ese widget de recomendación de contenido que instaló hace año y medio lo hace por usted, Google le va a pedir cuentas a su dominio. No al proveedor del widget.
He visto esto en 3 de los últimos 12 proyectos que hemos auditado en AMDT: código de terceros que inyectaba comportamientos que el propietario del sitio desconocía por completo. Redes publicitarias que insertaban estados en el historial, scripts de afiliación con redirecciones agresivas, herramientas de engagement con exit-intent vinculado al botón volver.
Algunos elementos que debería revisar antes del 15 de junio:
- Redes publicitarias y scripts de monetización: Especialmente las menos conocidas. Son las que con mayor frecuencia implementan técnicas de retención agresiva.
- Widgets de contenido relacionado: Taboola, Outbrain y similares tienen versiones limpias, pero las configuraciones agresivas pueden pisar el historial del navegador.
- Scripts de afiliación: Algunos programas de afiliados usan cadenas de redirección que interfieren con la navegación hacia atrás.
- Herramientas de captación de leads: Pop-ups de salida que interceptan el evento
popstateen lugar de usar el eventobeforeunloadestándar. - Plugins de WordPress y JavaScript externo: Cualquier plugin que manipule
window.historysin una justificación legítima de navegación interna (como una SPA).
4. Cómo auditar su web antes de la fecha límite
¿Qué pasos concretos debe dar?
Le sugiero un proceso de auditoría que cualquier equipo técnico puede ejecutar esta misma semana:
Primero, abra su web desde un resultado de Google (no directamente). Navegue a una página interna y pulse «Atrás». Si no vuelve inmediatamente a la página anterior, tiene un problema. Hágalo en modo incógnito, sin extensiones del navegador que puedan interferir.
Segundo, abra las DevTools de Chrome (F12), vaya a la pestaña Console y ejecute history.length en varias páginas de su sitio. Si el número es inusualmente alto (más de 3-4 en una navegación normal), algo está inyectando entradas ficticias en el historial.
Tercero, busque en el código fuente de sus páginas llamadas a history.pushState, history.replaceState y listeners del evento popstate. Si encuentra alguno que no pertenezca a la funcionalidad legítima de su sitio (como un enrutador de SPA), investigue quién lo está inyectando.
Y cuarto, revise todos los scripts de terceros que carga su web. En AMDT usamos herramientas como Google Tag Manager en modo vista previa, Screaming Frog para rastrear JavaScript externo, y el propio Chrome DevTools (pestaña Network filtrada por «JS») para identificar scripts sospechosos.
No es un proceso complicado. Pero requiere hacerlo con rigor, porque un solo script de un proveedor olvidado puede tumbarle la visibilidad.
¿Qué pasa si ya le han penalizado?
Si después del 15 de junio su sitio recibe una acción manual por back button hijacking, aparecerá en Google Search Console bajo el informe de Acciones manuales. El proceso de recuperación implica identificar y eliminar todo el código responsable, y después enviar una solicitud de reconsideración con evidencia técnica de que el problema se ha resuelto.
Pero hay un detalle adicional que muchos van a pasar por alto. Desde diciembre de 2024, Google vincula las penalizaciones manuales de búsqueda con la elegibilidad publicitaria. Es decir, si su sitio recibe una acción manual por spam, eso puede afectar también a sus campañas de Google Ads. No es un riesgo teórico: es una política ya implementada.
Por ello, la auditoría preventiva no es un consejo amable. Es una necesidad de negocio.
5. Lo que este cambio dice sobre hacia dónde va Google
Si da un paso atrás y mira el panorama completo de 2024-2026, el patrón es inequívoco:
En marzo de 2024, Google introdujo nuevas políticas contra el abuso de dominios expirados y el contenido escalado con IA. En septiembre de 2024, añadió las reglas de site reputation abuse. En enero de 2025, amplió las directrices de calidad para evaluadores con 11 páginas adicionales de criterios de identificación de spam. En marzo de 2026, el Spam Update reforzó la detección algorítmica. Y ahora, en abril de 2026, el back button hijacking.
¿Recuerda cuando bastaba con no hacer cloaking ni comprar enlaces para estar tranquilo? Esos tiempos han quedado atrás. Google está cerrando, una por una, todas las zonas grises que el ecosistema web ha explotado durante años. Y lo está haciendo con un enfoque doble: más política escrita (para que no haya dudas) y más capacidad algorítmica (para que no haya escapatoria). Ya hablamos de cómo la web agéntica está redefiniendo las reglas del juego; pues este movimiento contra el back button hijacking es otra pieza del mismo puzzle.
Para los que trabajamos en SEO ético —lo que en AMDT siempre hemos llamado White Hat—, esto no es una mala noticia. Es la confirmación de que hacer las cosas bien, aunque más lento, es la única estrategia sostenible. Cada nueva política de spam le quita una herramienta a quien hace trampas y le da una ventaja competitiva a quien juega limpio.
Preguntas frecuentes sobre el back button hijacking
El back button hijacking es una práctica en la que un sitio web manipula el historial del navegador mediante JavaScript (usando history.pushState o interceptando el evento popstate) para impedir que el usuario vuelva a la página anterior al pulsar el botón «Atrás». Para comprobarlo, abra su web desde un resultado de Google en modo incógnito, navegue a una página interna y pulse «Atrás». Si no regresa inmediatamente a la página anterior, su sitio tiene un problema que debe resolver antes del 15 de junio de 2026.
Google puede aplicar dos tipos de acciones: acciones manuales (un revisor humano identifica la práctica y penaliza el sitio, requiriendo una solicitud de reconsideración para recuperarse) y degradaciones algorítmicas automáticas (SpamBrain detecta el patrón y reduce la visibilidad del sitio sin intervención humana). Además, desde diciembre de 2024, las acciones manuales por spam pueden afectar también a la elegibilidad de campañas de Google Ads del mismo dominio.
Sí. Google ha sido muy explícito: la responsabilidad recae sobre el dominio, no sobre el proveedor del script. Si una red publicitaria, un widget de contenido relacionado o un plugin de WordPress inyecta código que manipula el historial del navegador, la penalización se aplica a su sitio web. Por eso es fundamental auditar todos los scripts de terceros que se cargan en su web antes de la fecha límite del 15 de junio de 2026.
Resumiendo: ¿Debo preocuparme por mi web?
Básicamente, lo que hemos visto es que Google ha dado un paso más en su cruzada contra las prácticas que manipulan la experiencia del usuario, y esta vez apunta a algo que millones de personas sufrían sin saber que tenía nombre: el back button hijacking.
Pero seamos prácticos. Si yo tuviera que actuar mañana mismo, no haría diez cosas a la vez. Haría tres antes del café:
Primero, la prueba del botón volver. Abriría mi sitio desde Google, navegaría a 5-6 páginas internas y pulsaría «Atrás» en cada una. Si en alguna el comportamiento no es el esperado, ya sé dónde tengo el problema.
Segundo, el inventario de scripts de terceros. Revisaría qué JavaScript externo se está cargando en mi web y, para cada uno, verificaría si manipula window.history. En los 47 proyectos que hemos gestionado en AMDT, al menos el 23% tenía algún script olvidado de un proveedor que ya ni usaban. Ese es el tipo de código que mata sin hacer ruido.
Y tercero, y esto es lo más importante, documentaría todo. Fecha de la auditoría, scripts encontrados, acciones tomadas. Si algún día llega una acción manual, esa documentación es su mejor defensa en la solicitud de reconsideración. ¿Ve la diferencia entre «creo que lo arreglé» y «lo audité el 20 de abril, encontré estos 3 scripts, los eliminé y aquí están las capturas»?
El resto lo construye progresivamente. Revise proveedores, actualice contratos publicitarios, y establezca una revisión trimestral de scripts de terceros como parte de su mantenimiento técnico.
Sé que puede resultar abrumador sumar una preocupación más a la lista. Pero la realidad es que Google no está inventando problemas: está formalizando reglas para prácticas que siempre debieron estar prohibidas. Y en este caso, le está dando dos meses de ventaja. No muchos avisos vienen con fecha y hora.
Recuerde, al final todo va de respetar al usuario que visita su web y de no poner trampas en la puerta de salida 😉
Soy consultor de Marketing Digital en AMDT (Aún Más Difícil Todavía), agencia especializada en SEO técnico, analítica web y visibilidad en inteligencia artificial. Profesor de SEO, Analítica, AIO y GEO/LLMO en diferentes escuelas de negocio. Ayuda a marcas a posicionarse tanto en buscadores tradicionales como en los nuevos motores de respuesta impulsados por IA.
