Entras en una web desde Google, lees un rato, pulsas el botón atrás para volver a los resultados y la página se queda donde estaba, o te lleva a un anuncio que nunca pediste. Si eres el dueño de esa web, lo más probable es que no hayas escrito ese código y que no sepas si Google lo vigila. Desde el 15 de junio de 2026 existe una política concreta contra esa práctica, y te cuento cómo la compruebo yo cuando audito webs con publicidad y widgets de terceros.
Qué dice la política de Google y qué ha cambiado desde junio
El 13 de abril de 2026 Google Search Central anunció en su blog que el back button hijacking, el secuestro del botón atrás, pasa a ser una infracción explícita de su política de prácticas maliciosas, con posible acción manual o degradación automática, y fijó el 15 de junio de 2026 como fecha de aplicación. La documentación de políticas de spam, actualizada por última vez el 28 de agosto de 2026, lo define así: “Back button hijacking is when a site interferes with user browser navigation by manipulating the browser history or other functionalities, preventing them from using their back button to immediately get back to the page they came from”. Traducido por mí, ocurre cuando un sitio manipula el historial del navegador u otras funciones e impide volver de inmediato a la página de origen con el botón atrás.
Un matiz del anuncio me parece el más importante para quien tiene una pyme con publicidad: Google reconoce que “some instances of back button hijacking may originate from the site's included libraries or advertising platform”, es decir, que algunos casos pueden venir de las librerías o de la plataforma publicitaria que el sitio incluye. El código ajeno que cuelga de tu dominio cuenta como tuyo.
Conviene separar dos mecanismos que algunos titulares mezclan: Chrome aplica una intervención que salta las entradas del historial creadas sin interacción del usuario, y la documentación de Chromium (versión 127) la describe como algo que afecta solo a los botones atrás y adelante del navegador y no a history.back(). La política de Search es otro mecanismo que puede acabar en acción manual o en degradación de la web en los resultados; ambos pueden coincidir en un mismo sitio y se tratan por separado, y no he comprobado si la intervención de Chrome sigue igual en la versión estable actual.
Hay además una contradicción curiosa: según Barry Schwartz en SERoundtable, Google había dicho antes que Search no penalizaba esto y cambió de postura, y el propio post de 2026 sostiene que siempre ha ido contra Search Essentials, con un aviso de 2013 como antecedente. Mi lectura es que la práctica llevaba años mal vista y que ahora Google la hace sancionable de forma explícita.
A 18 de octubre de 2026 nadie sabe con precisión cuánto se está aplicando: no he encontrado casos públicos de sanciones desde junio ni cifras fiables, y Google no ha explicado cómo lo detecta, así que cualquier porcentaje o mecanismo que leas por ahí es especulación.
Cómo compruebo en diez minutos si mi web secuestra el botón atrás
Estos pasos son método propio de mis auditorías; Google no los publica como procedimiento oficial, y sirven para dar con el culpable, que suele ser un script que nadie recuerda haber instalado.
- Empieza por una prueba de navegación real: busca una de tus páginas en Google, entra desde el resultado, espera unos segundos, toca algo y pulsa el botón atrás del navegador, tanto en móvil como en escritorio y, si haces campañas, entrando desde un anuncio. Apunta cualquier caso en que te quedes en la misma página o te lleven a una pantalla intermedia o a otra web.
- Abre las DevTools de Chrome, pulsa Ctrl+Mayús+F en Windows o Cmd+Opción+F en Mac para buscar en todos los ficheros y localiza
history.pushState,history.replaceStateypopstate, fijándote en qué script vive cada coincidencia. Un listener depopstateque te redirige al pulsar atrás merece sospecha; para verlo en vivo pega en la consolaconst o = history.pushState; history.pushState = function (...a) { console.trace('pushState', a); return o.apply(this, a); }, interactúa con la página y lee la traza, que señala qué script llama (técnica de depuración propia que solo registra llamadas posteriores). - Aísla al tercero apagando candidatos de uno en uno: si cargas etiquetas con Google Tag Manager, puedes pausarlas en un espacio de trabajo de prueba y repetir la navegación sin tocar el código, y lo mismo vale para plugins de publicidad y widgets. Imagina una tienda WordPress con una red de anuncios y un widget de «te puede interesar» que alguien instaló hace dos años: el culpable aparece cuando, al apagar el widget, el botón atrás vuelve a funcionar.
- Documenta el hallazgo (URL, fichero del script, proveedor, dispositivo y pasos que lo reproducen), porque esa evidencia es la que enviarás al proveedor.
El uso legítimo del History API y dónde está la línea
El History API es la base de cualquier aplicación de una sola página: cuando filtras un listado o cambias de pestaña, pushState actualiza la URL sin recargar y el botón atrás sigue funcionando como esperas. Eso es uso normal, y mi duda razonable, porque no he visto quejas documentadas, es si una web así podría caer en un falso positivo; la definición de Google habla de impedir volver de inmediato a la página de origen.
Mi criterio práctico, que no está en ninguna guía de Google, cabe en una pregunta: si entras desde Google, no tocas nada y pulsas atrás, ¿vuelves a los resultados con un solo clic? Si la respuesta es sí, lo demás (filtros o paginación) forma parte de la navegación normal porque cada entrada nueva del historial la ha provocado una acción tuya; si te quedas en la misma página o te reenvían a un anuncio, para mí hay manipulación aunque el código sea de un proveedor.
Sobre el motivo hay dos lecturas: Glenn Gabe lo relaciona con inflar las señales de engagement y con monetización agresiva (en su análisis escribe que “Disabling, or hijacking the back button, is a tricky and deceptive tactic”, es decir, una táctica engañosa, según mi traducción), y otros lo ven como un fallo de integración publicitaria. A mí me encaja más lo segundo en las pymes, donde el script suele llegar con un partner o una actualización, pero la definición de Google habla del efecto sobre el usuario y no de la intención, así que el motivo no te protege.
Pasos a seguir cuando el culpable es un tercero o llega una acción manual
La responsabilidad es tuya aunque el código venga de fuera, así que mi orden de actuación empieza por retirar o desactivar el script localizado y avisar al proveedor con la evidencia del paso 4 (URL, fichero, traza y pasos para reproducirlo), y termina repitiendo la prueba de navegación completa para confirmar que todo está limpio. Si no responde o no puede corregirlo, toca cambiar de proveedor.
Después abre el informe de Acciones manuales de Search Console y comprueba si Google te ha notificado algo. Si aparece una acción por esta causa y ya has corregido el problema, puedes solicitar la reconsideración desde ese mismo informe, explicando qué encontraste y cómo has comprobado la corrección; no conozco plazos publicados por Google y no puedo prometerte recuperación ni fecha. Si no aparece nada, tampoco puedo asegurarte que estés a salvo de una degradación automática, porque Google no ha explicado cómo detecta esta práctica, y por eso repito la prueba cada vez que añado un script nuevo.
Si tras la prueba no localizas el script, o dependes de varios proveedores y no puedes aislarlos, es justo el tipo de punto que reviso en una auditoría técnica, y puedes escribirme para que lo veamos.
Fuentes comprobadas por última vez el 18 de octubre de 2026; si Google amplía la documentación o publica casos, actualizaré el artículo.
Preguntas frecuentes
¿Es lo mismo la intervención de Chrome que la política de spam de Google?
Son dos mecanismos distintos, porque según la documentación de la versión 127, Chrome salta entradas del historial creadas sin activación del usuario, mientras que la política de Search puede terminar en acción manual o en degradación en los resultados. Una web puede verse afectada por una, por otra o por ambas, y cada una se corrige por separado.
¿Usar el History API en una web SPA me expone a una sanción?
La definición de Google se centra en impedir volver de inmediato a la página de la que vienes, y el enrutado o los filtros no lo hacen por sí mismos. Si tu web pasa mi prueba del clic único desde la entrada de Google estás en buena posición, aunque es un criterio mío y Google no lo ofrece como garantía.
¿Cómo sé si tengo una acción manual por esto?
Revisa el informe de Acciones manuales de Search Console: si Google ha aplicado una, aparece ahí con su descripción y, una vez corregido el problema, puedes solicitar la reconsideración desde el mismo informe. Que no haya ninguna no descarta una degradación automática, porque Google no ha detallado cómo la detecta.
¿Cuántas webs han sido sancionadas desde junio?
No hay datos públicos verificados ni voy a inventarlos, y como Google tampoco ha detallado cómo detecta el secuestro del botón atrás, lo sensato es comprobar tu propia web con la prueba de navegación y la revisión de scripts.
Desarrollo, SEO, GEO y tecnología con una visión de negocio.