Google classifica “sequestro do botão Voltar” como spam

• Prática que impede que o usuário volte à página original ao pressionar o botão Voltar do navegador, ou o redireciona para páginas indesejadas de anúncios ou recomendações
• Esse “sequestro do botão Voltar” foi adicionado como novo item de violação da política de spam, sendo explicitamente proibido
• A política está prevista para entrar em vigor em 15 de junho de 2026 e, em caso de violação, podem ser aplicadas ações manuais contra spam ou rebaixamento automático no ranking
• O Google considera que essa prática prejudica a experiência do usuário e atrapalha o fluxo de navegação, classificando-a como violação explícita da política de práticas maliciosas
• Operadores de sites devem remover códigos ou scripts externos que manipulem o histórico de navegação do navegador e, se necessário, podem se recuperar por meio de uma solicitação de reconsideração no Search Console

---

Conceito de sequestro do botão Voltar

• Prática que interfere na tentativa do usuário de retornar à página original ao pressionar o botão “Voltar” do navegador
  • O site manipula a função de navegação do navegador para impedir que o usuário volte imediatamente à página anterior
  • Em vez disso, o usuário é levado para páginas que não visitou, vê páginas indesejadas de recomendações ou anúncios, ou tem a navegação normal bloqueada

Motivo do reforço da política e ações para operadores

• O objetivo principal é a proteção da experiência do usuário
  • O sequestro do botão Voltar interfere nas funções do navegador, quebra o fluxo de navegação esperado e causa no usuário frustração e sensação de estar sendo manipulado
  • Esse tipo de prática também faz com que os usuários fiquem relutantes em visitar sites desconhecidos
• O Google já vinha tratando inserções de páginas enganosas ou manipuladoras como violação da política Search Essentials e,
  com o aumento recente desse tipo de comportamento, passou a classificá-lo como violação explícita da política de “práticas maliciosas” (malicious practices)
• Operadores de sites devem remover códigos ou scripts que manipulem o histórico de navegação do navegador do usuário
  • Como isso pode ocorrer em bibliotecas externas ou plataformas de anúncios, é necessário revisar e remover códigos, imports e configurações relacionados
• Se a visibilidade na busca tiver sido limitada por uma ação manual, é possível recuperar após corrigir o problema por meio de uma solicitação de reconsideração (reconsideration request) no Search Console
• Dúvidas adicionais ou feedback podem ser enviados pela página do Google Search Central no LinkedIn ou pela comunidade de suporte

[xguru]

Ah, finalmente!!! Todos esses veículos de imprensa que faziam esse tipo de coisa têm mesmo é que levar uma paulada

[lazydonkey456]

Será que o Google não deveria primeiro dar um jeito nos anúncios NSFW, tipo, antes de mais nada? -_-?

[crawler]

O site de Q&A da Microsoft também, quando eu entro e aperto voltar, às vezes entra em loop infinito; queria muito que consertassem esse tipo de site.

Tenha redirecionamento ou não, do ponto de vista do usuário, ao apertar voltar a página deveria sair.
Nesses sites, sempre preciso segurar o botão de voltar e sair mais de 2 níveis de profundidade.

[eoeoe]

Normalizado!!

[GN⁺]

Comentários do Hacker News

• Eu queria que o navegador tivesse um recurso para desativar todos os atalhos de um site
  No Brave, configurei Ctrl+E para abrir uma nova aba, mas sites como o Discord trocam isso pelo menu de emoji, o que é bem irritante

  • Ctrl+F também é um problema. Em vez de abrir a caixa de busca própria do site, eu quero procurar palavras dentro da página
  • Outro exemplo são sites que mudam ctrl+click, que em vez de abrir em nova aba passa a abrir na aba atual. Vejo isso com frequência, especialmente em sites de e-commerce
  • Eu bloqueio esse tipo de coisa com um bookmarklet que desativa todos os listeners de teclado. Posso compartilhar se alguém quiser
  • Em vez de bloquear totalmente, seria bom existir um sistema em que o site tivesse que pedir permissão para usar atalhos. Aí bastaria permitir só para sites confiáveis
  • No Firefox eu uso o Vimium, então os atalhos padrão seguem o plugin. Por exemplo, t abre uma nova aba, e para usar atalhos do site eu entro no modo insert com i. Teclas sem conflito, como ctrl+k, podem continuar livres para o site usar, o que é bom

• Hoje em dia a política de indexação do Google não faz mais sentido para mim
  Meu site, que aparecia bem há anos, de repente sumiu do índice. É só um blog simples, sem anúncios, com HTTPS ativado e com links vindos de outros sites
  Mas os resultados do Google ultimamente estão ficando cada vez mais distantes da informação que eu quero. Espero que essa nova política traga alguma melhora

  • Pode até ser “porque não tem anúncios”. O Google não tem interesse em destacar páginas sem publicidade
  • Isso é sobre o Chrome, não sobre busca. Nos últimos anos, o Google começou a remover conteúdo com pouco tráfego. Se houver muito conteúdo parecido, ele nem indexa, independentemente da autoridade da página. A busca está ficando parecida com o TikTok. Resumos por IA, YouTube, notícias, mapas e produtos vêm primeiro. O conteúdo morreu

• No Firefox dá para configurar para a página não conseguir modificar o histórico do navegador
  Segundo este método no superuser.com, basta desativar browser.history.allowPushState em about:config

  • Mas na maioria dos casos não é pushstate; a página está fazendo um redirecionamento automático. Aí você precisa apertar voltar duas vezes
  • SPAs usam a History API para gerenciar o histórico de navegação interna. Bloquear isso pode até causar perda de dados
  • Só como referência, browser.history.allowPushState foi deprecated depois do Firefox 47. Hoje em dia quase não há problema com sites manipulando o histórico. Ainda assim, é surpreendente que no Chrome o sequestro do botão voltar continue existindo. Eu resolvi isso no Firefox com um UserScript específico para bloquear keycodes

• No começo achei que fosse sobre Android
  Apps Android fazem muito esse tipo de sequestro de UX, como “aperte voltar duas vezes para sair”. Apps de feed como Reddit, TikTok e Instagram são exemplos clássicos

  • Eu também achei no começo que fosse sobre Android e fiquei me perguntando por que o artigo falava tanto em “browser”
  • Queria muito que o Google aplicasse essa política também no Android. Os piores infratores são os apps

• Eu queria que começassem a aplicar essa política pelo LinkedIn
  Você clica num link em um e-mail ou post, vai para a publicação, mas quando aperta voltar acaba caindo no feed.
  Isso é feito combinando location.replace(...) e history.pushState() para manipular o histórico

  • O Reddit faz a mesma coisa ao interceptar o voltar. Você vai a um post do Reddit pelo Google e, ao voltar, cai no feed principal do Reddit
  • O Gmail também tem um problema de UX parecido. Em e-mails de convite, o assunto tem um botão “Aceitar”, então dá para clicar sem querer enquanto você rola a página
  • Eu lido com esses sites sempre abrindo links em nova aba. Fechar a aba virou meu novo botão de voltar. Se a aba não me interessar, eu só fecho
  • O Facebook também funciona assim. Graças à explicação, agora entendi o mecanismo
  • Ainda assim, é discutível se isso viola a nova política. Navegação baseada em hash pode ser tecnicamente válida

• Os sites da Microsoft também sofrem bastante com esse problema do voltar

  • O Azure Portal é um exemplo clássico. Você aperta voltar sem saber o que vai acontecer. Parece o “botão da sorte” do Android
  • Mas no caso da Microsoft, parece menos algo malicioso como redirecionamento de anúncios e mais um simples problema de arquitetura de redirecionamento em JS
  • A Epic Store também, no celular, não deixa voltar na página de pagamento. Não sei se é intencional ou só um erro de UX
  • Ontem mesmo encontrei um site assim. Nem apertando voltar rápido adiantava, então acabei fechando a aba

• Essa medida é um bom primeiro passo, mas ainda não é suficiente
  Eu não quero que site nenhum sequestre meu botão voltar.
  O que eu mais odeio são pop-ups do tipo “Tem certeza que quer sair? Você ainda não assinou nossa newsletter”

  • Em SPAs isso às vezes é necessário como exceção. É preciso rastrear corretamente o caminho percorrido pelo usuário dentro do app. Mas o princípio deveria ser: “deve funcionar do jeito que o usuário espera”
  • Avisos como “Tem certeza de que quer sair sem salvar?” são úteis. Mas deveria existir uma configuração de permissão por site
  • Como alguém que opera um app SaaS, eu uso esse tipo de aviso porque, se o usuário sair no meio do preenchimento de um formulário, os dados se perdem. Mas ainda fico pensando qual comportamento é melhor do ponto de vista do usuário
  • Forçar a abertura em nova aba também é um tipo de sequestro. Isso deveria ser totalmente proibido. Acho até que sanções legais seriam necessárias

• Dizer que “a experiência do usuário vem em primeiro lugar” é irônico
  Justamente vindo de empresas que mostram pop-ups confusos de “Open in app” para empurrar o usuário ao aplicativo
  Texto relacionado: Those obnoxious sign-in windows

• Este é um ótimo momento para voltar a divulgar o padrão Post/Redirect/Get
  Como explica a Wikipedia, fazer um redirecionamento após o envio do formulário deixa a UX muito mais fluida

  • Como desenvolvedor das antigas, eu adoro esse padrão. Parece que a geração React de hoje em dia não conhece muito isso
  • Descobri isso hoje pela primeira vez. Era por isso que aparece o pop-up “Deseja reenviar o formulário?” quando esse padrão não é usado. Foi útil até aprender o nome

• O framework SPA do Google, Angular, também pode causar sequestro do voltar ao usar redirect routes
  Isso é explicado na documentação oficial do Angular

  • Mas no roteamento interno de SPAs isso muitas vezes é inevitável por causa da UX do app. Nesses casos, o sequestro só deveria ser permitido para manter a navegação interna natural