Sabe aquele site que você clica no botão voltar e nada acontece? Ou pior: te joga para uma página de anúncios que você nunca pediu para visitar? O Google finalmente decidiu que isso é spam — e quem não se adaptar até 15 de junho vai sentir o impacto direto no ranking.

A nova política, anunciada oficialmente no Google Search Central Blog em 13 de abril de 2026, classifica o chamado “back button hijacking” como prática maliciosa. Na prática, isso significa que sites que manipulam o histórico do navegador para prender ou redirecionar o usuário vão receber penalidades manuais ou rebaixamento automático nos resultados de busca.

E a real é que isso afeta muito mais gente do que parece. Se você usa redes de anúncios, widgets de recomendação de conteúdo ou qualquer script de terceiros, seu site pode estar fazendo isso sem você saber.

O Que Exatamente é “Back Button Hijacking”?

Vamos direto ao ponto. Back button hijacking é qualquer técnica que impede o usuário de usar o botão voltar do navegador normalmente. Em vez de retornar à página anterior (o comportamento esperado), o usuário experimenta uma dessas situações:

• O botão não faz nada — você clica, clica, clica e continua na mesma página
• Redireciona para uma página desconhecida — geralmente cheia de anúncios ou recomendações não solicitadas
• Cria um loop infinito — você volta e é redirecionado de novo para a página que tentou sair
• Insere páginas fantasma no histórico — o usuário precisa clicar “voltar” dezenas de vezes para finalmente escapar

Eu já vi sites de notícias grandes fazendo isso. Você entra por um resultado do Google, lê a matéria, clica voltar e… cai numa página de “artigos recomendados” que você nunca acessou. O site literalmente inventou uma entrada no seu histórico de navegação para te prender ali.

Como Funciona Por Trás dos Panos

Para quem é dev, a mecânica por trás é conhecida — e, ironicamente, usa APIs legítimas do navegador de forma abusiva.

A History API como arma

O JavaScript oferece dois métodos principais para manipular o histórico do navegador:

// Adiciona uma nova entrada no histórico
history.pushState(stateObj, title, url);

// Substitui a entrada atual do histórico
history.replaceState(stateObj, title, url);

No uso legítimo, essas APIs são fundamentais para Single Page Applications (SPAs). Quando você navega no Gmail ou no Twitter sem a página recarregar, é o pushState trabalhando. O problema começa quando sites usam essas APIs para injetar entradas falsas no histórico.

O truque clássico

// Script malicioso que sequestra o botão voltar
// 1. Salva o estado atual
const originalState = history.state;

// 2. Substitui o estado atual por um "trap"
history.replaceState({ trap: true }, '', window.location.href);

// 3. Empurra o estado original de volta (parece que nada mudou)
history.pushState(originalState, '', window.location.href);

// 4. Quando o usuário clica "voltar", cai no trap
window.addEventListener('popstate', function(event) {
  if (event.state && event.state.trap) {
    // Redireciona para página de anúncios
    window.location.replace('https://site.com/ads-recomendados');
  }
});

Percebe a elegância sinistra? O usuário não vê nada de diferente na página. Mas o histórico do navegador foi silenciosamente manipulado. Quando ele clica “voltar”, o navegador vai para o estado trap — que imediatamente redireciona para outra página.

Variações mais agressivas

Alguns sites vão além:

// Spam de entradas no histórico
for (let i = 0; i < 50; i++) {
  history.pushState(null, '', window.location.href);
}

// O usuário precisa clicar "voltar" 50+ vezes para sair

Outros usam beforeunload ou unload events para disparar redirecionamentos no momento em que o usuário tenta sair. E tem ainda os que combinam meta refresh com manipulação do histórico para criar loops virtualmente impossíveis de escapar.

Por Que o Google Demorou Tanto?

Essa é a pergunta que não quer calar. Back button hijacking existe desde os anos 2000. Sites de downloads duvidosos já faziam isso com pop-ups e window.open antes mesmo do HTML5 existir. Então por que só agora em 2026?

A resposta tem a ver com escala. O que antes era coisa de site pirata virou técnica mainstream. Redes de anúncios legítimas começaram a usar variações mais sofisticadas. Widgets de “conteúdo recomendado” — aqueles que aparecem no final de artigos de portais grandes — frequentemente injetam entradas no histórico.

O Google já tinha mecanismos contra spam, mas o back button hijacking caía numa zona cinza. Não era explicitamente proibido nas diretrizes. Sites podiam argumentar que estavam “melhorando a experiência do usuário” com páginas de recomendação. Agora, não mais.

O Que Muda na Prática: Manual Actions e Demotions

O Google vai aplicar dois tipos de punição:

1. Ação Manual (Manual Spam Action)

Um revisor humano do Google examina seu site, confirma a violação, e aplica uma penalidade direta. Isso aparece no Google Search Console como uma notificação.

Consequências de uma ação manual:

• Páginas específicas ou o site inteiro podem ser removidos dos resultados de busca
• A recuperação exige correção do problema + envio de um pedido de reconsideração
• O processo de revisão pode levar semanas
• Desde 2025, penalidades manuais de spam também afetam a elegibilidade para anúncios — ou seja, você pode perder o Google Ads junto

2. Rebaixamento Automático (Algorithmic Demotion)

Sistemas automatizados do Google detectam o comportamento e rebaixam o ranking do site sem intervenção humana. Isso é mais traiçoeiro porque:

• Não aparece como notificação no Search Console
• Você percebe só pela queda de tráfego orgânico
• A recuperação é mais lenta — precisa esperar o algoritmo reavaliar o site
• Pode afetar todo o domínio, não apenas as páginas infratoras

Seu Site Está Fazendo Isso Sem Você Saber?

Essa é a parte mais perigosa. Muitos donos de sites não fazem ideia de que seus próprios sites estão sequestrando o botão voltar. Os culpados mais comuns:

Redes de anúncios

Scripts de ad networks frequentemente manipulam o histórico para garantir que o usuário veja mais impressões. Se você usa qualquer rede além do Google AdSense (e às vezes até com ele), audite seus scripts.

Widgets de recomendação de conteúdo

Taboola, Outbrain, e similares já foram flagrados injetando entradas no histórico. Se você usa algum desses serviços, verifique imediatamente.

Pop-ups e modais com “deep linking”

Alguns sistemas de pop-up criam entradas no histórico para cada modal aberto. Quando o usuário clica voltar, fecha o pop-up em vez de voltar à página anterior. Parece útil, mas o Google pode interpretar como hijacking.

SPAs mal implementadas

Se sua Single Page Application usa pushState de forma excessiva ou incorreta, pode criar problemas. Frameworks modernos como Next.js e Nuxt geralmente lidam bem com isso, mas implementações customizadas podem criar situações onde o botão voltar não funciona como esperado.

Como Auditar Seu Site

Antes de 15 de junho, faça essa checklist:

Teste manual

1. Abra seu site pelo Google (pesquise algo e clique no resultado)
2. Navegue por 2-3 páginas internas
3. Clique no botão voltar do navegador
4. Verifique se cada clique leva exatamente à página anterior
5. Repita com JavaScript desabilitado e compare

Teste técnico

# No Chrome DevTools, abra o console e monitore mudanças no histórico
# Cole isso antes de navegar no site:

(function() {
  const origPush = history.pushState;
  const origReplace = history.replaceState;

  history.pushState = function() {
    console.warn('pushState chamado:', arguments);
    console.trace();
    return origPush.apply(this, arguments);
  };

  history.replaceState = function() {
    console.warn('replaceState chamado:', arguments);
    console.trace();
    return origReplace.apply(this, arguments);
  };
})();

Esse snippet intercepta todas as chamadas à History API e mostra no console exatamente quando e de onde elas vêm. Se você ver chamadas que não reconhece, provavelmente são de scripts de terceiros.

Auditoria de scripts de terceiros

# Liste todos os scripts externos carregados na sua página
# No console do Chrome:
performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script' && !r.name.includes(location.hostname))
  .map(r => r.name)

Cada script nessa lista é um potencial culpado. Revise um por um.

O Que Fazer Se Seu Site Está Vulnerável

Passo 1: Identifique a fonte

Use as técnicas de auditoria acima para encontrar qual script está manipulando o histórico.

Passo 2: Remova ou substitua

Se é um script de anúncios, entre em contato com a rede e pergunte se eles já estão em conformidade. Se não estiverem, troque de provider.

Se é um widget de recomendação, verifique as configurações — muitos oferecem opção de desabilitar manipulação do histórico.

Passo 3: Implemente proteção

Para garantir que nenhum script de terceiros manipule o histórico sem sua permissão:

// Congela a History API para scripts não autorizados
// Coloque isso ANTES de qualquer script de terceiros

(function() {
  const allowedCallers = [
    '/js/app.js',      // seu script principal
    '/js/router.js'    // seu router
  ];

  const origPush = history.pushState.bind(history);
  const origReplace = history.replaceState.bind(history);

  function isAllowed() {
    const stack = new Error().stack;
    return allowedCallers.some(caller => stack.includes(caller));
  }

  history.pushState = function(...args) {
    if (!isAllowed()) {
      console.error('Blocked unauthorized pushState from:', new Error().stack);
      return;
    }
    return origPush(...args);
  };

  history.replaceState = function(...args) {
    if (!isAllowed()) {
      console.error('Blocked unauthorized replaceState from:', new Error().stack);
      return;
    }
    return origReplace(...args);
  };
})();

Essa abordagem é agressiva, mas eficaz. Bloqueia qualquer chamada à History API que não venha dos seus próprios scripts.

Passo 4: Monitore continuamente

Adicione um teste automatizado no seu CI/CD:

// Puppeteer test para detectar back button hijacking
const puppeteer = require('puppeteer');

async function testBackButton(url) {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  // Monitora chamadas ao pushState
  let pushCount = 0;
  await page.evaluateOnNewDocument(() => {
    const orig = history.pushState;
    history.pushState = function() {
      window.__pushCount = (window.__pushCount || 0) + 1;
      return orig.apply(this, arguments);
    };
  });

  await page.goto(url, { waitUntil: 'networkidle0' });

  pushCount = await page.evaluate(() => window.__pushCount || 0);

  // Se houve pushState sem navegação do usuário, possível hijacking
  if (pushCount > 0) {
    console.warn(`⚠️ ${pushCount} pushState calls detectados sem interação`);
  }

  await browser.close();
  return pushCount;
}

Quem Mais Vai Ser Afetado

Não são só sites pequenos. Vários segmentos vão precisar correr para se adaptar:

Portais de notícias que usam heavy ad scripts e conteúdo recomendado. Se você já entrou num UOL ou R7 da vida e ficou preso clicando voltar, sabe do que estou falando.

E-commerces com sistemas de pop-up agressivos. Aquele “Espere! Tem um cupom de 10% antes de sair!” que cria uma entrada no histórico? Pode ser enquadrado.

Sites de receita e how-to que usam scroll infinito com pushState para cada seção. Se o usuário não consegue voltar ao Google com um clique, é problema.

Agregadores de conteúdo que abrem artigos em frames ou iframes com navegação própria que conflita com o botão voltar.

O Navegador Também Está Se Defendendo

O Google não está sozinho nessa luta. Os próprios navegadores já vinham implementando proteções:

• Chrome 65+ já tinha uma “back-forward cache intervention” que ignora certas entradas suspeitas do histórico
• Firefox implementou detecção de pushState abuse em 2024
• Safari é historicamente o mais agressivo — já bloqueia vários padrões de hijacking nativamente

A diferença agora é que o Google está atacando pelo lado do Search, não só do browser. Mesmo que o navegador permita a manipulação, o site vai ser penalizado nos resultados de busca.

Deadline: 15 de Junho de 2026

O Google deu dois meses de aviso. A política foi anunciada em 13 de abril e a enforcement começa em 15 de junho de 2026. Esse é o timeline:

Se você é dono de site, webmaster, ou dev responsável por um projeto web, a hora de agir é agora. Não espere até junho para descobrir que seu tráfego orgânico despencou 80%.

E Se Eu Receber Uma Penalidade?

Caso seu site seja penalizado depois de 15 de junho:

1. Acesse o Google Search Console
2. Verifique a seção Ações Manuais
3. Identifique e remova o comportamento infrator
4. Envie um pedido de reconsideração explicando as correções
5. Aguarde a revisão (geralmente 1-4 semanas)

Para rebaixamentos automáticos, não há notificação. Você vai precisar monitorar seu tráfego orgânico via Search Console ou Google Analytics e correlacionar quedas com a data de enforcement.

“Pages that are engaging in back button hijacking may be subject to manual spam actions or automated demotions, which can impact the site’s performance in Google Search results.” — Google Search Central Blog

Parece aviso educado, mas na prática é uma sentença de morte para sites que dependem de tráfego orgânico e não se adaptarem.

Uma coisa é certa: essa política já deveria existir há pelo menos dez anos. Se você é usuário, vai finalmente parar de ficar preso em sites que sequestram seu navegador. Se você é dev ou dono de site, tem exatamente dois meses para garantir que seu site não está na lista negra. E se você é de uma ad network que ainda faz isso… boa sorte.