Back Button Hijacking: o que é e como evitar a punição do Google
Você clica em “voltar” no navegador esperando retornar ao resultado do Google e, em vez disso, cai em outra página, em uma lista de recomendações ou em um beco sem saída. Essa prática tem nome, back button hijacking (sequestro do botão voltar), e desde 2026 o Google a trata de forma explícita como violação das suas políticas de spam. Para quem tem um site, ou contrata a criação e a manutenção de um, vale entender o que mudou e como se proteger.
Resposta rápida
Back button hijacking é quando um site manipula o histórico do navegador e impede o visitante de voltar imediatamente à página de onde veio. Em 13 de abril de 2026, o Google divulgou que a prática passa a ser violação da categoria de práticas maliciosas, com aplicação a partir de 15 de junho de 2026. Páginas nessa situação podem sofrer ação manual ou rebaixamento automático nos resultados. A prevenção passa por testar o botão voltar em todo o site e revisar scripts e bibliotecas de terceiros, porque o problema pode vir de código que o dono do site nem escreveu.
O que é back button hijacking e o que não é
O navegador guarda uma lista das páginas visitadas em cada aba. Quando o visitante aperta “voltar”, ele espera retornar ao item anterior dessa lista. No back button hijacking, o site interfere nessa navegação: manipula o histórico ou outras funções do navegador para que o botão não leve imediatamente à página anterior. Na prática, o visitante pode ser enviado a páginas que nunca visitou, receber recomendações que não pediu ou simplesmente ficar impedido de navegar normalmente.
É importante separar a prática do uso legítimo da tecnologia. A History API, descrita na documentação da MDN, existe para que aplicações de página única atualizem o conteúdo sem recarregar a página e, ainda assim, mantenham o botão voltar funcionando de forma coerente. Um menu, uma galeria ou um filtro de produtos que registra seus estados no histórico não é o problema. O problema surge quando o histórico é usado para segurar o visitante dentro do site.
O que mudou na política do Google
O Google publicou o comunicado no blog Google Search Central em 13 de abril de 2026. Por ele, o back button hijacking passa a ser uma violação explícita da categoria de práticas maliciosas das políticas de spam, ao lado de problemas como malware e software indesejado. A documentação de spam do Google informa que sites que violam as políticas podem aparecer mais abaixo nos resultados ou deixar de aparecer.
Quem já usava algum script desse tipo recebeu um prazo de dois meses, e a aplicação da regra foi marcada para 15 de junho de 2026. As consequências possíveis são a ação manual de spam e o rebaixamento automático, e ambos podem afetar o desempenho do site na busca. Se o site for atingido por uma ação manual e o problema for corrigido, o dono pode enviar uma solicitação de reconsideração pelo Search Console.
Como o back button hijacking acontece na prática
Do ponto de vista técnico, o recurso do navegador envolvido é a History API, com métodos como pushState e replaceState e o evento popstate, que dispara quando o visitante navega pelo histórico. Segundo a MDN, esses recursos permitem criar entradas de histórico e reagir quando o usuário volta ou avança. Em uso correto, isso mantém a navegação previsível. Em uso abusivo, um script pode acrescentar entradas artificiais ou reagir ao evento para exibir outro conteúdo no lugar do retorno esperado.
O ponto que mais interessa a quem contrata um site é que o Google reconhece que parte dos casos pode vir de bibliotecas incluídas no site ou de plataformas de terceiros. A orientação é revisar a implementação técnica e remover ou desativar o código, as importações ou as configurações responsáveis. Ou seja, a responsabilidade recai sobre o site, mesmo quando o script não foi escrito por quem o administra.
Como verificar se o seu site tem back button hijacking
A boa notícia é que o teste é simples e não exige ferramenta paga. Vale repetir o roteiro abaixo em páginas importantes, como a home, as páginas de serviço, de produto e os artigos do blog.
- Teste o caminho vindo do Google: pesquise por uma página do seu site, entre nela e aperte “voltar”. Você deve retornar direto aos resultados da busca.
- Teste a navegação interna: entre pela home, abra uma página de produto ou artigo e aperte “voltar” uma vez. O esperado é chegar à página anterior, sem telas intermediárias.
- Teste em celular e em mais de um navegador: o comportamento pode mudar conforme o dispositivo e o navegador, e boa parte dos acessos hoje vem do celular.
- Desligue scripts de terceiros em ambiente de teste: com o gerenciador de tags em modo de visualização, ou em uma cópia do site, desative um grupo de scripts por vez e veja se o comportamento muda.
- Revise plugins, temas e widgets: pop-ups de saída, recomendações de conteúdo, chats e ferramentas de conversão adicionados nos últimos meses são os primeiros suspeitos.
- Consulte o Search Console: veja as mensagens e o relatório de ações manuais para confirmar que não há aviso relacionado à navegação.
Se algo estranho aparecer, registre a URL e o passo a passo exato. Isso acelera o diagnóstico pelo desenvolvedor e evita correções no escuro. Esse teste combina bem com as demais verificações descritas em SEO técnico essencial: 7 auditorias para levar seu site ao topo do Google.
Como corrigir e evitar o problema
A correção depende de onde o comportamento nasce, mas o princípio é o mesmo: o botão voltar deve fazer o que o visitante espera. Em geral, estas ações ajudam a resolver e a prevenir:
- Remover ou desativar o script, o plugin ou a configuração responsável, em vez de apenas esconder o efeito.
- Trocar a ferramenta problemática por uma alternativa que não altere o histórico do navegador, ou pedir a correção ao fornecedor.
- Em aplicações de página única, usar a History API apenas para refletir mudanças reais de tela, sem criar entradas artificiais.
- Para captação de contatos, preferir formatos que não dependam do botão voltar, como um convite dentro do conteúdo ou um formulário na própria página. As ideias de 3 táticas para gerar leads de alto valor no seu site mostram caminhos que respeitam a navegação.
- Criar uma rotina de revisão: antes de publicar qualquer novo script de terceiros, testar o botão voltar.
Depois de corrigir, confirme o resultado com o mesmo roteiro de testes. Se o site tiver sofrido ação manual, documente o que foi feito e envie a solicitação de reconsideração pelo Search Console, aguardando a análise do Google.
Quem é responsável: empresa, agência ou fornecedor
Como a origem pode ser interna ou externa, ajuda deixar claro quem investiga cada parte. A tabela abaixo é um ponto de partida, e a divisão real depende do contrato e da estrutura de cada projeto.
| Origem provável | O que verificar | Quem costuma resolver |
|---|---|---|
| Código do tema ou do sistema próprio | Rotas, componentes de página e scripts de navegação | Equipe de desenvolvimento |
| Plugins e widgets | Pop-ups de saída, recomendações, chats | Quem administra o site |
| Tags no gerenciador de tags | Scripts adicionados por marketing ou mídia | Marketing, com apoio técnico |
| Bibliotecas e plataformas incorporadas | Versão, configurações e opções de navegação | Fornecedor, com apoio do desenvolvedor |
Para agências, o recado é de processo: qualquer tag nova, publicada por qualquer time, deve passar por um teste de navegação antes de ir ao ar. Esse passo cabe no mesmo fluxo do checklist de SEO técnico para agências e evita surpresas depois da entrega.
Perguntas frequentes sobre back button hijacking
O que significa back button hijacking em português?
É o “sequestro do botão voltar”. Acontece quando o site manipula o histórico do navegador e impede o visitante de retornar imediatamente à página de onde veio.
Quando o Google começou a aplicar a regra?
O comunicado foi publicado em 13 de abril de 2026, e a aplicação da regra foi marcada para 15 de junho de 2026. Como as políticas podem mudar, vale conferir a documentação de spam do Google.
Um script de terceiros pode causar o problema no meu site?
Sim. O Google reconhece que parte dos casos pode vir de bibliotecas ou plataformas incluídas no site e orienta o dono a revisar a implementação e remover ou desativar o que for responsável. Por isso, vale tratar o tema como responsabilidade do site.
Usar a History API em um site de página única é proibido?
Não. A MDN descreve a API justamente para esse tipo de aplicação. O que a política combate é a manipulação do histórico para impedir o retorno imediato do visitante.
Como pedir nova análise depois de corrigir?
Se o site tiver sofrido ação manual e o problema estiver resolvido, o dono pode enviar uma solicitação de reconsideração pelo Search Console, explicando o que foi corrigido.
Resumo
- Back button hijacking é a manipulação do histórico para impedir o retorno imediato à página anterior.
- Desde 15 de junho de 2026, a prática é tratada como violação de spam pelo Google, com possível ação manual ou rebaixamento automático.
- O problema pode vir de scripts, plugins e bibliotecas de terceiros, e a responsabilidade de revisar é do site.
- Teste o botão voltar em páginas-chave, no celular e com scripts desligados, e crie uma rotina de revisão para cada novo script.
Quer revisar a navegação e a base técnica do seu site?
A Volvee é parceira técnica de empresas e agências de marketing em web design, sites, e-commerce, manutenção, SEO e performance. Se você quer avaliar o seu projeto ou conversar sobre a revisão técnica de um site, peça um orçamento pelo formulário da Volvee, chame no WhatsApp (11) 99709-8288 ou escreva para contato@volvee.com.br.
Fontes
Informações conferidas em 26 de outubro de 2026.