Google clasifica el “secuestro del botón Atrás” como spam

• La práctica de impedir que el usuario regrese a la página original cuando pulsa el botón Atrás del navegador, o de redirigirlo a páginas de anuncios o recomendaciones no deseadas
• Se añadió como una nueva infracción de la política de spam que prohíbe explícitamente este “secuestro del botón Atrás”
• Esta política entrará en vigor el 15 de junio de 2026, y las infracciones podrán recibir acciones manuales contra spam o degradación automática en el ranking
• Google considera que esta práctica perjudica la experiencia del usuario e interrumpe el flujo de navegación, por lo que la clasifica como una infracción explícita de la política sobre prácticas maliciosas
• Los operadores de sitios deben eliminar código o scripts externos que manipulen el historial de navegación del navegador y, si es necesario, pueden recuperarse mediante una solicitud de reconsideración en Search Console

---

Concepto de secuestro del botón Atrás

• Práctica que interfiere con la acción de volver a la página original cuando el usuario pulsa el botón “Atrás” del navegador
  • El sitio manipula la función de navegación del navegador para impedir que el usuario vuelva de inmediato a la página anterior
  • En su lugar, lo envía a páginas que no visitó, le muestra páginas de recomendaciones o anuncios no deseados, o bloquea la navegación normal

Motivos del endurecimiento de la política y medidas para operadores

• El objetivo principal es proteger la experiencia del usuario
  • El secuestro del botón Atrás interfiere con las funciones del navegador, rompe el flujo de navegación esperado y provoca en el usuario frustración y sensación de manipulación
  • Estas prácticas hacen que los usuarios se muestren reacios a visitar sitios desconocidos
• Google ya venía indicando que la inserción engañosa o manipuladora de páginas infringía la política de Search Essentials,
  y ante el aumento reciente de estos casos, ahora la designa como una infracción explícita de la política sobre “prácticas maliciosas” (malicious practices)
• Los operadores de sitios deben eliminar código o scripts que manipulen el historial de navegación del navegador del usuario
  • Como esto puede originarse en bibliotecas externas o plataformas publicitarias, es necesario revisar y eliminar el código, los imports y la configuración relacionados
• Si la visibilidad en búsqueda fue limitada por una acción manual, es posible recuperarla corrigiendo el problema y enviando una solicitud de reconsideración (reconsideration request) en Search Console
• Las consultas o comentarios adicionales pueden realizarse a través de la página de Google Search Central en LinkedIn o de la comunidad de soporte

[xguru]

Ah, ¡por fin!!! Todos los medios que hacían estas cosas deberían recibir un buen castigo.

[lazydonkey456]

¿No debería Google hacer algo primero con los anuncios NSFW, empezando por ahí? -_-?

[crawler]

Incluso si entras al sitio de Q&A de Microsoft, cuando presionas atrás se queda en un bucle infinito, así que ojalá de verdad arreglen este tipo de sitios.

Haya o no una redirección, desde el punto de vista del usuario, si presionas atrás deberías poder salir.
En este tipo de sitios siempre tienes que dejar presionado el botón de atrás para salir más de 2 niveles.

[eoeoe]

¡¡Normalizado!!

[GN⁺]

Opiniones en Hacker News

• Ojalá el navegador tuviera una función para desactivar todos los atajos de teclado de los sitios web
  En Brave configuré Ctrl+E para abrir una pestaña nueva, pero sitios como Discord me lo cambian al menú de emojis y es molesto

  • Ctrl+F también es un problema. No quiero que se abra el cuadro de búsqueda propio del sitio, quiero buscar palabras dentro de la página
  • Otro ejemplo: hay sitios que hacen que ctrl+click abra en la pestaña actual en vez de abrir una nueva. Lo veo seguido, sobre todo en sitios de e-commerce
  • Yo lo evito con un bookmarklet que bloquea todos los listeners de teclado. Si quieren, lo comparto
  • En vez de bloquearlo por completo, ojalá hubiera un sistema para que el sitio pidiera permiso para usar atajos. Así solo se lo permites a sitios confiables
  • En Firefox uso Vimium, así que los atajos base los maneja el plugin. Por ejemplo, con t abro una pestaña nueva, y si quiero usar atajos del sitio entro al modo insert con i. Está bien que el sitio use teclas sin conflicto como ctrl+k

• La política de indexación de Google últimamente ya no se entiende
  Mi sitio, que llevaba años apareciendo bien, de repente desapareció del índice. Es un blog simple, sin anuncios, con HTTPS y además enlazado desde otros sitios
  Pero los resultados de búsqueda de Google cada vez se alejan más de la información que uno quiere. Ojalá esta nueva política mejore algo

  • Puede ser “porque no tiene anuncios”. A Google no le interesa mostrar páginas sin publicidad
  • Esto va de Chrome, no de búsqueda. En los últimos años Google empezó a eliminar contenido con poco tráfico. Si hay mucho contenido parecido, ni lo indexa, sin importar la autoridad de la página. La búsqueda se está volviendo como TikTok. Primero van los resúmenes de IA, YouTube, noticias, mapas y productos. El contenido está muerto

• En Firefox se puede configurar para que la página no pueda modificar el historial del navegador
  Según este método en superuser.com, basta con desactivar browser.history.allowPushState en about:config

  • Pero en la mayoría de los casos no es pushstate, sino que la página tiene una redirección automática. Por eso hay que pulsar atrás dos veces
  • Las SPA usan la History API para manejar el historial de navegación interno. Si bloqueas eso, incluso podrías perder datos
  • Como referencia, desde Firefox 47 browser.history.allowPushState está deprecated. Hoy en día casi no hay problemas con sitios manipulando el historial. Aun así, sorprende que en Chrome siga existiendo el secuestro del botón atrás. Yo lo resolví en Firefox con un UserScript para bloquear ciertos keycodes

• Al principio pensé que hablaban de Android
  Las apps de Android hacen mucho este tipo de secuestro de UX, como eso de “pulsa atrás dos veces para salir”. Los ejemplos clásicos son Reddit, TikTok e Instagram, que viven de feeds

  • Yo también pensé al principio que era sobre Android y me preguntaba por qué en el artículo seguían hablando de “browser”
  • Ojalá Google aplicara esta política también en Android. Lo peor son las apps

• Ojalá empezaran a aplicar esta política por LinkedIn
  Si haces clic en un enlace desde un correo o una publicación, llegas al post, pero al pulsar atrás regresas al feed
  Eso lo hacen combinando location.replace(...) con history.pushState() para manipular el historial

  • Reddit hace lo mismo: secuestra el botón atrás. Si entras a una publicación de Reddit desde Google y luego retrocedes, terminas en el feed principal de Reddit
  • Gmail también tiene un problema de UX parecido. En el asunto de correos de invitación aparece un botón de “Aceptar”, así que lo puedes tocar por accidente mientras haces scroll
  • Yo con estos sitios siempre respondo abriendo en una pestaña nueva. Cerrar la pestaña se volvió mi nuevo botón de atrás. Las pestañas que no me interesan, simplemente las cierro
  • Facebook también funciona así. Gracias a la explicación ahora entiendo cómo lo hacen
  • Aun así, no está claro si eso viola la nueva política. La navegación basada en hash podría seguir siendo técnicamente válida

• Los sitios de Microsoft también tienen mucho este problema con el botón atrás

  • El ejemplo clásico es Azure Portal. Pulsas atrás y nunca sabes qué va a pasar. Se siente como el “botón de la suerte” de Android
  • Aunque en el caso de MS parece menos una conducta maliciosa tipo redirección publicitaria y más un simple problema de diseño con redirecciones en JS
  • En móvil, Epic Store tampoco te deja volver desde la página de pago. No sé si es intencional o solo un error de UX
  • Ayer mismo me topé con un sitio así: aunque le di atrás rápido, no hubo caso y al final cerré la pestaña

• Esta medida es un buen primer paso, pero todavía se queda corta
  Yo no quiero que ningún sitio secuestre mi botón atrás.
  Lo que más odio son esos popups de “¿Seguro que quieres salir? Ni siquiera te suscribiste al newsletter”

  • En una SPA puede ser necesario como excepción. Hay que seguir correctamente la ruta que tomó el usuario dentro de la app. Pero el principio debería ser: “tiene que funcionar como el usuario espera”
  • Avisos como “¿Quieres salir sin guardar?” sí son útiles. Pero debería poder haber una configuración de permisos por sitio
  • Desde el lado de quien opera una app SaaS, usamos esas advertencias porque si el usuario sale por error mientras llena un formulario, puede perder datos. Aun así, sigo pensando cuál comportamiento es mejor para el usuario
  • Forzar la apertura en una pestaña nueva también es una forma de secuestro. Eso debería prohibirse por completo. Incluso creo que debería haber sanciones legales

• Eso de que “la experiencia del usuario es lo primero” suena irónico
  Lo dice una empresa que muestra popups confusos de “Open in app” para empujarte a usar la aplicación
  Artículo relacionado: Those obnoxious sign-in windows

• Este es un gran momento para volver a promover el patrón Post/Redirect/Get
  Como explica Wikipedia, si haces una redirección después de enviar un formulario, la UX se vuelve mucho más fluida

  • Como desarrollador de la vieja escuela, me encanta este patrón. Parece que la generación de React ya no conoce mucho estas cosas
  • Hoy lo conocí por primera vez. Ahora entiendo por qué aparece el popup de “¿Quieres reenviar el formulario?” cuando no se usa este patrón. Hasta aprendí su nombre

• El framework SPA de Google, Angular, también provoca secuestro del botón atrás cuando usas redirect routes
  Está explicado en la documentación oficial de Angular

  • Aun así, en el enrutamiento interno de una SPA muchas veces es inevitable por la UX de la app. En esos casos, el secuestro solo debería permitirse para mantener natural la navegación interna