Google ha anunciado en su Search Central blog que añadirá una nueva categoría a su política de spam: el «back button hijacking», el truco que usan algunas webs para impedir que el usuario abandone la página cuando pulsa el botón atrás del navegador. La aplicación efectiva empieza el 15 de junio de 2026, dejando a los administradores de sitios dos meses para auditar su código. A partir de esa fecha, cualquier técnica que abuse de la History API del navegador (history.pushState, history.replaceState) para inyectar entradas falsas en el historial de navegación y atrapar al usuario en una página interstitial, un anuncio o el mismo sitio del que intentaba salir podrá recibir una penalización manual del equipo antispam o una caída algorítmica en el ranking. La cobertura es global y aplica a cualquier página indexada en Google Search.
La técnica del back button hijacking lleva años siendo una de las molestias más persistentes de la web. Al cargar una página, un script inyecta silenciosamente entradas falsas en el historial de navegación. Cuando el usuario pulsa atrás esperando volver a la página anterior, en su lugar acaba en una pantalla intermedia, un feed de recomendaciones, un anuncio o simplemente vuelve a la misma página que intentaba abandonar. En los casos más agresivos, hay que pulsar atrás una docena de veces para escapar. El abuso ha crecido en paralelo a la presión por engagement metrics y a la caída del tráfico de referidos provocada por las AI Overviews y las búsquedas zero-click. Toda una industria de scripts de monetización empaqueta hoy manipulación del historial junto a funciones que suenan legítimas como «scroll-depth analytics» o «exit-intent recovery».
La política nueva de Google es deliberadamente amplia. Cualquier técnica que inserte o reemplace «páginas engañosas o manipulativas» en el historial del navegador entra bajo el paraguas de prácticas maliciosas. Eso incluye overlays de salida activados por navegación atrás, scripts de popunder, y widgets de recomendación que interceptan el evento popstate para redirigir al usuario en lugar de soltarlo. El detalle clave para los administradores es que la responsabilidad recae en el dominio incluso cuando el código ofensor pertenece a un tercero. Google es explícito al respecto: avisa que algunos casos de back button hijacking «pueden originarse en las librerías incluidas o la plataforma publicitaria del sitio» e instruye a los webmasters a auditar todo su stack técnico, incluidas redes publicitarias, herramientas de A/B testing, módulos de consentimiento y widgets de engagement. Si un script de monetización empaquetado en tu paquete de analítica está manipulando el historial del navegador, la penalización aterriza en tu dominio.
El movimiento encaja en un patrón que Google viene desplegando desde marzo de 2024, cuando introdujo políticas contra el abuso de reputación de sitios, abuso de contenido escalado y abuso de dominios expirados. Esa actualización inicial fue la base para la batalla contra el «SEO parásito», el uso de la reputación de sitios web confiables para posicionar contenidos de baja calidad o engañosos en los primeros resultados. La presión sobre Google para combatir esas prácticas también ha venido de fuera: la Unión Europea inició una investigación dentro del marco del Digital Services Act sobre las prácticas antispam de Google, y la propia Google ha respondido defendiendo su política y argumentando que sus medidas protegen a los usuarios europeos del contenido engañoso. Una update de spam en agosto de 2025 refinó la detección. El back button hijacking es la última adición y va específicamente contra una técnica que cruza la línea entre prácticas SEO agresivas y mala experiencia de usuario.
Para los administradores de sitios, la guía operativa es clara: eliminar cualquier código que añada estados de historial al cargar la página solo para interceptar la navegación atrás, eliminar cualquier código que redirija al usuario cuando se pulsa atrás, eliminar cualquier overlay que aparezca específicamente porque el usuario intentó navegar fuera, y auditar cada script de terceros. La ignorancia no es defensa válida. Sitios que ya hayan recibido una acción manual pueden solicitar revisión a través de Google Search Console una vez resuelto el problema. La propia compañía reconoce en su post que los usuarios que se encuentran con back button hijacking reportan sentirse «manipulados» y se vuelven menos dispuestos a visitar sitios desconocidos, lo que erosiona la confianza no solo en el sitio ofensor sino en la web en su conjunto.
El componente regulatorio es interesante porque revela un dilema antiguo del gobierno de la web: ¿quién debe imponer las reglas? La política de spam de Google funciona como regulación de facto para cualquier sitio que dependa de tráfico orgánico, que es la inmensa mayoría de la web. Cuando Google decide que una práctica es inaceptable, el incentivo económico para cumplir es inmediato, posiblemente más eficaz que cualquier legislación. El Digital Services Act de la UE obliga a las plataformas a abordar patrones engañosos de diseño, pero los plazos de aplicación se extienden durante años. La fecha límite de Google son ocho semanas. Esa concentración de poder es problema y solución a la vez. Para los mil millones largos de personas que usan Google Search a diario, una web donde el botón atrás funciona como uno espera es una mejora inequívoca. Para los publishers que ya han lidiado con varias actualizaciones algorítmicas y políticas de spam, es una más a vigilar, especialmente en un momento donde la IA ya ha desplazado el modelo de tráfico clásico y donde los márgenes para experimentar con tácticas dudosas se reducen.
Mi valoración: la política es buena por usuario y dolorosa por industria. El back button hijacking es una de esas prácticas que casi todo el mundo odia y que sigue existiendo precisamente porque algunos modelos de monetización dependen de ella. Penalizarla con caída de ranking es la única forma realista de erradicarla, porque las multas del DSA tardan años. La parte preocupante para los publishers honestos es que los scripts ofensores muchas veces vienen empaquetados en redes publicitarias o consent management platforms sin que el sitio sepa lo que están haciendo a nivel técnico. Mi recomendación práctica para cualquier administrador de sitio: hacer una auditoría completa de todos los scripts de terceros antes del 15 de junio. Concretamente: abrir DevTools, navegar a una página, pulsar atrás y comprobar qué pasa. Si no vuelves donde esperabas, tienes un problema. Otra opción es probar herramientas como Google Tag Assistant o Lighthouse en modo móvil para identificar comportamientos anómalos. La fecha es real, la sanción puede ser severa, y la responsabilidad legal/SEO recae sobre el dominio aunque el código sea de un tercero.
Preguntas frecuentes
¿Cuándo entra en vigor? El 15 de junio de 2026. Google ha dejado dos meses de margen desde el anuncio para que los administradores auditen su código. ¿Qué riesgo corro si no actúo? Penalización manual del equipo de spam de Google o caída algorítmica en el ranking. Para un sitio que dependa de tráfico orgánico, ambas pueden ser devastadoras. ¿Qué pasa si el script es de un tercero? La responsabilidad recae igualmente en tu dominio. Google es explícito: hay que auditar todo el stack, incluidas redes publicitarias y herramientas externas.
☞ El artículo completo original de Natalia Polo lo puedes ver aquí
No hay comentarios.:
Publicar un comentario