Back button hijacking: el nuevo spam que Google persigue en tu SEO

Google ha puesto fecha y nombre a una de esas prácticas digitales que el usuario normal no sabe explicar, pero sí maldecir. El back button hijacking SEO deja de ser un truco molesto escondido en capas de JavaScript, publicidad y “optimización de retención” para convertirse en una infracción explícita de sus políticas contra el spam. Desde el 15 de junio de 2026, las páginas que manipulen el botón atrás del navegador podrán enfrentarse a acciones manuales o a degradaciones automáticas en los resultados de búsqueda. No hablamos de una recomendación suave, ni de una sugerencia con voz de tutorial corporativo. Hablamos de Google diciendo: esto ya entra en la categoría de prácticas maliciosas.

El fenómeno es sencillo de reconocer. Un usuario entra en una web desde Google, lee, se cansa, pulsa atrás y, en vez de volver a los resultados, cae en otra página interna, en una recomendación no pedida, en un anuncio, en una URL que jamás visitó o en una especie de bucle pegajoso. Eso es back button hijacking: interferir en la navegación normal mediante la manipulación del historial del navegador o de otras funciones para impedir que el usuario vuelva inmediatamente a la página anterior. Técnicamente puede parecer una filigrana. En experiencia de usuario es un portazo. En SEO, desde ahora, es una señal de riesgo.

El secuestro del botón atrás deja de ser una travesura técnica

Durante años, el botón atrás ha sido una especie de contrato silencioso entre usuario y navegador. No tiene glamour. No sale en los informes de tendencias. Nadie presume en LinkedIn de “estrategia avanzada de botón atrás”, aunque visto lo visto tampoco conviene dar ideas. Pero es una pieza básica de confianza: entras, miras, sales. La web funciona porque el usuario conserva cierto control sobre la visita, incluso cuando la página está llena de banners, módulos de recomendación, pop-ups con complejo de portero de discoteca y scripts que cargan como una procesión bajo la lluvia.

El back button hijacking rompe ese contrato. Lo hace de forma especialmente irritante porque no se presenta como una barrera visible, sino como una pequeña trampa en la mecánica del navegador. El usuario no percibe una decisión editorial, comercial o técnica. Percibe que algo falla. Pulsa atrás y la web le contradice. Pulsa otra vez y el sitio insiste. La sensación es muy concreta: estar dentro de una habitación con el pomo de la puerta trucado. A veces el abuso parece torpe, casi cutre; otras veces está muy integrado en sistemas de monetización, páginas de afiliación, medios con publicidad agresiva o sitios que priorizan páginas vistas sobre satisfacción real.

Google no lo ha colocado por casualidad dentro de las prácticas maliciosas. El matiz importa. No lo trata como un simple problema de usabilidad, ni como una mala decisión de diseño. Lo define como una conducta que crea un desajuste entre lo que el usuario espera y lo que realmente ocurre. Y ese desajuste es el corazón del spam moderno: no siempre se ve como texto oculto, enlaces artificiales o páginas generadas en masa. A veces tiene forma de experiencia manipulada, de navegación torcida, de pequeñas trampas que no roban datos pero sí roban control.

La novedad llega, además, en un momento muy delicado para muchos equipos SEO. Google lleva tiempo afinando su discurso contra las técnicas que explotan señales de confianza sin aportar valor real: abuso de reputación del sitio, contenidos escalados, redirecciones engañosas, funcionalidades falsas, manipulación de usuario. En ese paisaje, el back button hijacking en SEO encaja como un ladrillo más en el muro: si una web necesita atrapar al lector para inflar métricas, quizá el problema no está en el botón atrás. Quizá está en todo lo demás.

Cómo funciona: historial del navegador, JavaScript y una puerta falsa

La parte técnica no exige ponerse bata blanca. Los navegadores mantienen un historial de sesión: una pila de páginas o estados por los que el usuario ha pasado. En sitios modernos, especialmente en aplicaciones de una sola página o interfaces cargadas con JavaScript, la web puede utilizar la History API para añadir o reemplazar entradas del historial mediante métodos como pushState o replaceState. Bien usado, esto permite que una aplicación web actualice contenido sin recargar toda la página y, aun así, respete la navegación hacia atrás y hacia delante. Nada raro. Internet no sería el mismo sin esa flexibilidad.

El problema aparece cuando esa capacidad se usa para colocar entradas artificiales o engañosas en el historial. En vez de servir para que el usuario vuelva al estado anterior de una aplicación, se emplea para desviar su salida. La web puede insertar un paso intermedio que no existía, empujar al usuario hacia una página de “recomendaciones”, abrir un anuncio disfrazado de navegación natural o mantenerlo dentro del dominio aunque su intención sea regresar a Google. La trampa no siempre se ve en la URL a primera vista. A veces solo se nota en el gesto: atrás, sorpresa, fastidio.

No todo el secuestro viene del código principal de la web. Google ha señalado un punto especialmente incómodo para publishers, ecommerce y proyectos con monetización publicitaria: algunas instancias pueden proceder de librerías externas, plataformas de anuncios, configuraciones de terceros o scripts importados. Ese detalle es importante porque desmonta una excusa muy habitual: “eso no lo hemos programado nosotros”. A Google le importa menos quién escribió la línea de código que el efecto sobre el usuario. Si ocurre en tu web, ocurre bajo tu responsabilidad técnica y editorial. Bonito marrón, sí. Pero bastante lógico.

Aquí conviene separar el uso legítimo de la History API del abuso. Una tienda online puede usar estados de navegación para filtros, paginación, variantes de producto o pasos de checkout. Un medio puede tener navegación dinámica entre secciones. Una herramienta SaaS puede actualizar paneles sin recargar. Nada de eso es spam por sí mismo. El criterio real no es la tecnología, sino la intención y el resultado: si el botón atrás devuelve al usuario donde espera, la implementación respira. Si lo manda a una página que no pidió o lo mantiene atrapado, empieza el olor a quemado.

No todo uso de History API es sospechoso

La web moderna se apoya en JavaScript para mil cosas razonables. Confundir cualquier manipulación del historial con back button hijacking sería tan absurdo como prohibir los cuchillos porque alguien corta mal el jamón. Las aplicaciones de una sola página necesitan reconstruir estados, conservar filtros, restaurar scroll, mantener formularios y permitir que el usuario navegue sin sentirse dentro de una pantalla congelada. La History API existe para eso: para hacer que una experiencia dinámica siga siendo navegable.

La línea roja aparece cuando la web deja de acompañar al usuario y empieza a conducirlo contra su voluntad. Un ejemplo legítimo sería una galería de productos donde cada cambio de filtro genera una URL compartible y el botón atrás devuelve al filtro anterior. Un ejemplo turbio sería una página que, al pulsar atrás, mete al usuario en un artículo recomendado, en una landing comercial o en una pantalla intermedia diseñada para arañar una página vista más. Hay una diferencia muy sencilla: en el primer caso se conserva el contexto; en el segundo se fabrica un desvío.

El SEO técnico debería leer esta actualización como una advertencia contra el cinismo de baja intensidad. Durante mucho tiempo algunas prácticas han sobrevivido porque no parecían suficientemente graves, porque no eran malware, porque no ocultaban texto, porque no vendían enlaces, porque “solo” mejoraban métricas de permanencia. Ese “solo” es el problema. Google está diciendo que manipular el recorrido del usuario también forma parte del ecosistema spam cuando altera expectativas básicas. Y pocas expectativas son tan básicas como que el botón atrás haga de botón atrás.

Por qué Google lo mete en prácticas maliciosas

La decisión de Google tiene un componente evidente de experiencia de usuario, pero también uno de salud del buscador. Cuando alguien llega desde una página de resultados y no puede volver con normalidad, el daño no lo sufre solo el sitio que lo atrapa. También se contamina la percepción del propio buscador. El usuario piensa: he salido de Google hacia una web que me ha metido en un túnel raro. Puede que culpe a la página, puede que culpe al navegador, puede que culpe a Internet en general, ese saco sin fondo. Pero la experiencia de búsqueda queda manchada.

Por eso el back button hijacking SEO no debe analizarse como una simple técnica de retención. En realidad, es una interferencia en la relación entre Google, la web y el usuario. La búsqueda funciona con una promesa: te llevo a una respuesta útil y tú puedes volver si no te sirve. Si la página rompe esa salida natural, convierte una visita en una captura. No es fidelización. Es pegamento barato. Y el pegamento barato deja residuos.

La inclusión dentro de políticas spam también encaja con la evolución de Google hacia criterios más conductuales y menos ingenuos. Hubo una época en la que muchas discusiones SEO giraban alrededor de enlaces, densidades, etiquetas, canónicos y arquitectura. Todo eso sigue importando. Pero la calidad ya no se entiende solo como contenido indexable. También se mira la fricción, el engaño, la seguridad, la reputación, la utilidad real y la correspondencia entre expectativa y resultado. Un sitio puede tener buen contenido y, aun así, ofrecer una experiencia que huele a trastienda.

Las consecuencias pueden ser especialmente serias porque Google menciona dos vías de impacto: acciones manuales y degradaciones automáticas. Una acción manual implica que el sitio recibe una intervención específica por incumplimiento de políticas, visible en Search Console y con posibilidad de solicitar reconsideración tras corregir el problema. Una degradación automática puede ser más silenciosa, más difícil de aislar y más incómoda de explicar en una reunión de tráfico. Esa caída que todos miran como si fuera meteorología. Esa gráfica que se dobla y nadie quiere tocar.

Publishers, afiliados y webs con demasiadas capas

Los sitios más expuestos no son necesariamente los más pequeños ni los más chapuceros. De hecho, el riesgo puede ser mayor en proyectos con muchas capas técnicas: medios con varias plataformas de publicidad, redes de afiliación, gestores de consentimiento, módulos de recomendación, scripts de analítica, experimentos A/B, sistemas de paywall, notificaciones, widgets externos y tecnología heredada que nadie recuerda quién instaló. El back button hijacking puede estar en una esquina del stack como una cucaracha detrás del frigorífico. No se ve, pero ahí está.

Los publishers deben prestar atención porque el incentivo histórico ha sido claro: aumentar páginas vistas, reducir rebote, empujar contenido recomendado, maximizar sesiones. El problema es que la frontera entre recomendar y atrapar puede quedar hecha puré cuando el botón atrás se convierte en una herramienta comercial. Un módulo de recomendación visible es una cosa. Una navegación manipulada que aparece cuando el usuario intenta irse es otra. Y no, llamar “engagement” a lo segundo no lo vuelve elegante. Solo lo maquilla con PowerPoint.

En afiliación y lead generation el riesgo también es evidente. Muchas landings agresivas funcionan con embudos que intentan evitar la salida a toda costa. Algunas colocan pasos intermedios, formularios redundantes, páginas puente, descuentos falsos o comparativas que se abren como setas. Si además se manipula el historial, la práctica entra en una zona tóxica: el usuario llega buscando una respuesta y acaba empujado hacia una secuencia que no pidió. Google lleva años mirando con lupa las páginas que prometen utilidad y entregan fricción comercial. Esta actualización añade otra pieza a esa vigilancia.

El ecommerce tampoco queda fuera. Una tienda puede tener capas de personalización, pop-ups de carrito, recuperación de navegación, recomendaciones, filtros dinámicos y scripts de marketing. Todo eso puede ser legítimo. Pero si al pulsar atrás desde una ficha de producto el usuario acaba en una página promocional no solicitada, o si el sitio inserta estados artificiales para que salir cueste más, el riesgo deja de ser teórico. En SEO, las trampas pequeñas suelen tener una virtud desagradable: parecen rentables hasta que dejan de serlo de golpe.

Qué revisar antes de que el problema sea una sanción

La primera revisión debería ser manual, casi doméstica. Entrar en la web desde Google, desde redes, desde newsletters y desde campañas, navegar como usuario real, pulsar atrás en distintos puntos y observar. Sin consola todavía, sin diagnóstico de laboratorio. Solo mirar si el navegador hace lo que promete. En desktop y móvil. En Chrome, Safari, Firefox, Edge. En navegación normal y, cuando proceda, en modo incógnito. La prueba es tan básica que precisamente por eso muchos equipos no la hacen. Les parece poco sofisticada. Error clásico: despreciar lo sencillo porque no cabe en un dashboard.

Después llega la capa técnica. Conviene revisar eventos asociados a popstate, llamadas a history.pushState, usos de history.replaceState, rutas gestionadas por frameworks JavaScript y cualquier script que altere la navegación tras la llegada desde fuentes externas. No basta con mirar el código propio. Hay que revisar etiquetas del gestor de tags, proveedores de publicidad, plataformas de recomendación, scripts de afiliación, widgets de terceros y experimentos activos. El culpable puede no estar en la plantilla principal, sino en una etiqueta que alguien activó “temporalmente” en 2023. Temporalmente, esa palabra arqueológica.

La auditoría también debería separar intención de consecuencia. Puede que un equipo no haya buscado manipular la salida, pero una configuración concreta genere el efecto. En ese caso el problema sigue existiendo. Google no evalúa el estado de ánimo del desarrollador, sino el resultado que vive el usuario. Si el botón atrás no devuelve al origen esperado, la implementación debe corregirse. Punto. No hay que montar un juicio moral ni escribir una novela rusa sobre la intención del plugin.

Hay señales complementarias que pueden ayudar: quejas de usuarios, grabaciones de sesión, mapas de comportamiento, cambios bruscos en navegación interna tras pulsaciones de atrás, páginas con entradas inexplicables desde estados previos, tasas anómalas de rebote “recuperado” o secuencias raras en analítica. Pero cuidado con convertirlo todo en numerología. La prueba definitiva sigue siendo funcional: el usuario pulsa atrás y vuelve donde esperaba. El resto son pistas alrededor del cadáver.

Si Search Console muestra una acción manual, el camino debe ser ordenado: identificar la causa, eliminar o desactivar el comportamiento, comprobar en varios navegadores, documentar los cambios y enviar una solicitud de reconsideración cuando proceda. Si aún no hay acción manual, mejor. La ventana antes del 15 de junio de 2026 sirve precisamente para limpiar antes de que Google empiece a aplicar la política. Aquí no hay épica. Hay higiene técnica.

El botón atrás también forma parte del SEO

La actualización deja una enseñanza incómoda para cierta cultura SEO: no todo lo que sube una métrica mejora un negocio. Una página vista arrancada a la fuerza no vale lo mismo que una lectura voluntaria. Una sesión alargada mediante fricción no equivale a interés. Un usuario atrapado no es un usuario fidelizado. Es alguien que recuerda tu marca con la misma ternura con la que uno recuerda una puerta giratoria atascada en agosto.

El back button hijacking SEO obliga a mirar el posicionamiento desde una perspectiva menos estrecha. El SEO ya no puede limitarse a indexación, enlazado interno, intención de búsqueda y contenido. También tiene que entrar en conversaciones de producto, desarrollo, monetización y legalidad de la experiencia. No para convertirse en policía de todo, sino porque muchas decisiones ajenas al contenido terminan afectando a visibilidad orgánica. Un script publicitario puede tumbar una mejora editorial. Una prueba A/B puede abrir una grieta de spam. Un widget barato puede salir carísimo.

La buena noticia es que la solución no exige reinventar la web. Exige respetar una norma casi infantil: no manipular la salida del usuario. Usar la History API para restaurar estados legítimos, sí. Usarla para fabricar callejones, no. Recomendar contenido, sí. Obligar al usuario a pasar por recomendaciones cuando intenta volver, no. Monetizar, sí. Convertir la navegación en una ratonera, tampoco. Parece obvio, pero Internet lleva décadas demostrando que lo obvio necesita mantenimiento.

A medio plazo, esta política puede empujar a muchos sitios a revisar acuerdos con proveedores externos. Durante años se ha instalado código de terceros con una mezcla de fe, prisa y resignación. “Lo pide monetización”, “lo trae el partner”, “lo usan otros medios”, “no afecta al SEO”. Pues quizá sí afecta. Google ha dejado claro que las librerías incluidas y las plataformas publicitarias también deben revisarse si provocan el comportamiento sancionable. La responsabilidad de una web no termina donde empieza el script de otro.

Cuando el truco sale más caro que la visita

El botón atrás parece pequeño, pero resume una idea enorme: el usuario debe poder irse. Y si puede irse sin sentirse engañado, tal vez vuelva. Esa es la parte que algunos embudos han olvidado mientras perseguían páginas vistas como quien recoge monedas del suelo sin mirar si viene un camión. Google ha convertido el back button hijacking en spam explícito porque la navegación manipulada no es una anécdota técnica; es una ruptura de confianza.

Para el SEO español, el aviso llega con fecha, margen y suficiente claridad. No hay misterio esotérico ni necesidad de buscar teorías en foros a las tres de la mañana. Hay que revisar la web, detectar cualquier manipulación del historial, limpiar scripts propios y de terceros, probar la navegación real y dejar que el botón atrás haga su trabajo. Qué cosa tan revolucionaria: que un botón sirva para lo que dice. En tiempos de automatización, IA, GEO y promesas infladas, a veces la ética digital empieza por ahí, por una flecha humilde en la esquina del navegador.