Back button hijacking: la norma antispam de abril de 2026 que apunta a tus scripts de publicidad

¿Qué es el back button hijacking según Google?

Google lo define así en sus políticas sobre spam: el sitio «interfiere en la navegación del usuario manipulando el historial del navegador u otras funciones», lo que le impide usar el botón Atrás para volver de inmediato a la página de la que venía^[2]. La práctica se incluye en la categoría de prácticas maliciosas.

En su entrada del 13 de abril, Google describe los síntomas: el usuario aterriza en páginas que nunca ha visitado, recibe recomendaciones o anuncios que no ha pedido, o se queda bloqueado en su navegación^[1]. El caso típico: llegas desde Google, pulsas Atrás y, en lugar de volver a los resultados, caes en una página de artículos «que podrían interesarle».

¿Qué sanciones hay desde el 15 de junio de 2026?

Google publicó la norma dos meses antes de aplicarla, algo poco habitual que daba tiempo para corregir. Desde el 15 de junio de 2026, las páginas afectadas pueden ser objeto de «acciones manuales por spam o degradaciones automáticas»^[1]. Las dos no tienen la misma visibilidad para ti.

Una acción manual aparece en Search Console, en el informe correspondiente, y se retira tras la corrección mediante una solicitud de reconsideración^[1]. Una degradación automática, en cambio, no genera ninguna notificación: solo verás una caída de visibilidad, que corres el riesgo de atribuir por error a una actualización del algoritmo. Es el escenario más peligroso para una pyme que no vigila sus scripts.

¿Por qué tu web puede estar afectada sin que lo sepas?

Es la frase más importante de la entrada de Google: el secuestro «puede proceder de las bibliotecas incluidas por el sitio o de su plataforma publicitaria»^[1]. Por eso Google pide a los propietarios que revisen su implementación y que eliminen o desactiven el código, las importaciones o los ajustes responsables.

En las auditorías que hago, los sospechosos habituales son siempre los mismos: plataformas publicitarias que añaden módulos de «recirculación», widgets de contenido patrocinado, plugins de WordPress de ventanas emergentes de salida, aplicaciones de retención de Shopify y scripts de test A/B mal configurados. Ninguna de estas herramientas está prohibida en sí misma. Lo que causa el problema es su comportamiento con el botón Atrás.

La trampa es que este comportamiento a menudo solo aparece en móvil, o solo para los visitantes que llegan desde un buscador, o solo una de cada dos veces. Una prueba rápida desde tu ordenador, entrando directamente en tu web, no lo detectará.

¿Pueden los informes de spam provocar una acción manual?

Sí, desde abril de 2026. El 14 de abril, Google modificó su documentación para indicar que «ahora puede utilizar los informes de spam para tomar acciones manuales», y el 23 de abril aclaró cuándo y por qué, en respuesta a las reacciones que había provocado^[3]. Hasta entonces, estos informes servían oficialmente para mejorar los sistemas de detección.

La página de informes añade un detalle importante: si se toma una acción manual, el texto del informe se envía al propietario del sitio para que entienda el contexto^[4]. Google también rechaza los informes que contienen datos personales. En la práctica, un competidor o un usuario molesto puede ahora denunciar tu web, y esa denuncia puede acabar en una sanción si describe una infracción real.

Mi lectura: esto no convierte Search Console en una herramienta de denuncias entre competidores, porque Google comprueba la infracción antes de actuar. Pero una práctica molesta para los visitantes, como el secuestro del botón Atrás, es justo el tipo de cosa que la gente denuncia. Los dos anuncios de abril van de la mano.

Lo que pienso yo

Me parece una norma sana. El secuestro del botón Atrás infla artificialmente algunos indicadores (páginas vistas, impresiones publicitarias) a costa de la experiencia. Un visitante atrapado no vuelve, y recuerda la marca por malos motivos. Para la web de una pyme, el beneficio publicitario es casi siempre insignificante comparado con el riesgo.

El verdadero asunto es la gobernanza de los scripts. Muchas webs que audito cargan diez, quince o veinte scripts de terceros sin que nadie sepa ya quién los añadió. Esta norma es una buena ocasión para hacer inventario. Un sitio ligero, renderizado en el servidor y con pocas dependencias, como los construidos con Éclair CMS, reduce este riesgo de forma automática. La actualización antispam de junio, que detallo en mi checklist técnica de junio de 2026, demostró que Google no afloja la presión^[5].

¿Qué hacer en la práctica?

• Haz la prueba en condiciones reales: búsqueda en Google desde el móvil, clic en tu resultado, botón Atrás. Repítela en un artículo, una ficha de producto y la página de inicio.
• Pregunta por escrito a tu plataforma publicitaria si sus scripts modifican el historial del navegador y, ante la duda, desactiva los módulos de recirculación.
• En WordPress o Shopify, revisa los plugins de ventanas emergentes de salida y de retención añadidos en los últimos años.
• Consulta el informe de Acciones manuales de Search Console y, si hay sanción, corrige y envía una solicitud de reconsideración.

Un rastreador no basta para detectar este problema, porque depende del comportamiento real en un navegador. En cambio, nuestro rastreador Arachnide te ayuda a inventariar los scripts que se cargan en cada página, que es el primer paso.

Fuentes

1. Blog de Google Search Central, nueva política antispam sobre el back button hijacking (13 de abril de 2026)
2. Google Search Central, políticas sobre spam de la Búsqueda de Google (prácticas maliciosas)
3. Google Search Central, registro de cambios de la documentación (entradas del 14 y el 23 de abril de 2026)
4. Google Search Central, informar de un problema de calidad o de spam
5. Google Search Status Dashboard, actualización antispam de junio de 2026