Idiomas

Redirecionamentos JavaScript

O que é um redirecionamento JavaScript, como o pipeline de renderização do Google o trata de forma diferente de um 301 no servidor, quando é um último recurso aceitável e como implementar e detectar um — além de onde o meta refresh e a History API se encaixam.

Publicado pela primeira vez: 27 de jun. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2
1 sinal de evidência nesta página

Um redirecionamento JavaScript envia usuários e rastreadores para uma nova URL com código no lado do cliente (window.location.replace() ou .href). É o tipo de redirecionamento menos confiável porque o Google só o vê após a renderização — que pode ser atrasada ou falhar completamente, sem um prazo fixo em ambos os casos. A ordem oficial de preferência do Google é no servidor (301/302/307/308) → meta refresh → JavaScript, e seus documentos dizem claramente: use redirecionamentos JS apenas se você não puder fazer os outros dois. Uma vez que o Google interpreta um com sucesso, o destino se torna um sinal de canonicalização — mas isso não é uma garantia comprovada de PageRank idêntico ou resultados de ranqueamento em comparação a um 301, então trate-o como último recurso, não como uma substituição equivalente. Use-os em plataformas restritas sem acesso ao servidor, para páginas de erro SPA que apontam para um 404 real, e pouco mais. Se você precisar usar um, use window.location.replace() no <head>, remova a URL de origem do seu sitemap e aponte links internos para o destino final. Meta refresh é um redirecionamento separado no nível de HTML, e history.pushState()/replaceState() não são redirecionamentos.

TL;DR — Um redirecionamento JavaScript é um redirecionamento no lado do cliente (window.location.replace(), .href, .assign()) que o Google só processa após a renderização — fase três de rastreamento → renderização → indexação. Um 301 no lado do servidor é visto no momento do rastreamento; um redirecionamento JS espera na fila de renderização, e o Google não dá um prazo fixo para essa espera — ela pode ser rápida ou pode demorar bastante, e a renderização pode falhar completamente. A ordem de preferência documentada do Google é lado do servidor → meta refresh → JavaScript, e os documentos dizem para usar redirecionamentos JS apenas quando você não pode fazer os outros dois. Uma vez que o Google os interpreta com sucesso, o destino se torna um sinal permanente de canonicalização — até o Google os usou em seu próprio blog quando nada mais funcionou — mas isso não é prova documentada de resultados idênticos de PageRank ou ranqueamento em comparação com um 301, então eles são um último recurso, não um sinal de spam. Os usos legítimos são plataformas restritas sem configuração de servidor e páginas de erro SPA que apontam para um 404 real. Implemente com window.location.replace() no <head>, remova a origem do seu sitemap, aponte os links internos novamente e confirme que o Googlebot consegue buscar o JS. Meta refresh é no nível de HTML (0s = permanente, qualquer atraso = temporário), e history.pushState()/replaceState() não são redirecionamentos de forma alguma.

O que conta como um redirecionamento JavaScript

A navegação por script depende de renderização e execução, portanto não é equivalente em nível de protocolo a um redirecionamento HTTP. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript redirects O processamento é possível, não uma garantia de tempo exato ou de indexação. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search

Um redirecionamento JavaScript navega o navegador para uma nova URL com código no lado do cliente. Os métodos comuns e como eles diferem:

  • window.location.replace("url") — navega e remove a URL original do histórico da sessão. Este é o que deve ser usado: o botão voltar pula a origem do redirecionamento em vez de levar o usuário direto de volta.
  • window.location.href = "url" — navega, mas mantém a original no histórico, então o botão voltar retorna para a página que redireciona (e pode criar um loop). document.location.href e window.location.assign("url") se comportam da mesma forma.
  • history.pushState() / history.replaceState() — não são redirecionamentos. Eles reescrevem a barra de endereço sem qualquer navegação ou sinal HTTP, então os rastreadores não os tratam como redirecionamentos. SPAs os usam para mudanças de URL dentro do aplicativo; eles precisam de links <a href> reais (ou navegações reais) para serem rastreáveis.

A linha divisória que importa: .replace(), .href e .assign() todos disparam uma navegação real de documento (a diferença entre eles é apenas o que acontece com o histórico da sessão), enquanto pushState()/replaceState() nunca navegam — eles mexem no estado do histórico e na barra de endereço e nada mais. Nenhum dos quatro é um 301 HTTP; “redirecionamento” aqui é uma abreviação para navegação no lado do cliente, não um código de status.

Meta refresh (<meta http-equiv="refresh" content="0;url=...">) é frequentemente agrupado com redirecionamentos JS, mas é uma diretiva HTML analisada antes de o JavaScript ser executado — uma categoria separada e mais confiável, abordada abaixo.

Como o Google processa um redirecionamento JavaScript

Este é o ponto crucial. O pipeline do Google funciona em etapas, e um redirecionamento JS e um redirecionamento no lado do servidor são capturados em etapas diferentes:

  1. Rastreamento — O Googlebot busca a URL e lê o HTML bruto. Um 301/302/307/308 no lado do servidor é visto aqui mesmo.
  2. Fila de renderização — páginas que retornam 200 esperam para serem renderizadas. Os documentos do Google observam que a página “may stay on this queue for a few seconds, but it can take longer than that.” (tradução) «pode permanecer nesta fila por alguns segundos, mas pode levar mais tempo do que isso.» O Google não publica um prazo fixo de nível de serviço além disso, então trate a espera como imprevisível — pode ser rápida, ou pode se arrastar — em vez de assumir qualquer número específico de dias ou semanas.
  3. Renderização + indexação — O Chromium headless executa o JavaScript. Este é o primeiro momento em que um redirecionamento JS existe no que diz respeito ao Google.

A mesma ideia que apresento em Crawling e em JavaScript SEO se aplica aqui: a renderização é uma etapa separada da busca, e qualquer coisa que dependa dela herda esse atraso e esse risco.

E o risco é real. Google: “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (tradução) «Embora o Google tente renderizar cada URL que o Googlebot rastreou, a renderização pode falhar por vários motivos. Isso significa que, se você definir um redirecionamento JavaScript, o Google pode nunca vê-lo se a renderização do conteúdo falhar.» (Google Search Central) Durante a janela antes de o redirecionamento ser processado — e para sempre, se a renderização falhar — o Google pode manter a página de origem vazia em seu índice.

Ordem de preferência oficial do Google

A documentação de redirecionamentos estabelece uma hierarquia do mais confiável ao menos confiável:

  1. Redirecionamentos no servidor — 301/308 (permanentes), 302/307 (temporários). Melhores para tudo: vistos no momento do rastreamento, inequívocos.
  2. Meta refresh — nível de HTML. Um meta refresh de 0 segundo é tratado como um redirecionamento permanente (como um 301); qualquer meta refresh atrasado é tratado como temporário.
  3. Redirecionamentos JavaScript — último recurso.

As palavras do Google: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (tradução) «Use redirecionamentos JavaScript apenas se você não puder fazer redirecionamentos no servidor ou meta refresh.» Redirecionamentos permanentes passam o sinal canônico para o destino; os temporários mantêm o original nos resultados. (Como isso interage com a seleção canônica está em Canonicalização.)

A própria documentação de redirecionamentos do Google lista a navegação por localização JavaScript entre seus métodos de redirecionamento permanente e diz que o destino se torna o sinal de canonicalização depois que o Google o interpreta — portanto, a afirmação simplista de que “redirecionamentos JS não transmitem PageRank” é falsa. O que a documentação não estabelece é que o resultado seja idêntico, imediato ou tão confiável quanto um 301 no servidor — ela descreve o sinal canônico, não uma garantia de fluxo de PageRank equivalente, ranqueamento ou tempo. O enquadramento honesto: um 301 transmite o sinal no momento do rastreamento com quase certeza; um redirecionamento JS o transmite apenas se e quando a renderização for bem-sucedida, e o Google não promete que o resultado corresponderá ao de um 301 um a um. Essa lacuna — não a equidade perdida — é o custo real de escolher JavaScript.

Isso também explica por que redirecionamentos JS não são um gatilho de penalidade por si só. Eles só se tornam um problema de spam quando usados para cloaking — mostrar uma página aos rastreadores e redirecionar os usuários para algo diferente, ou enviar usuários móveis para um domínio não relacionado. A política de redirecionamentos sorrateiros do Google trata dessa intenção, não da técnica.

Quando um redirecionamento JavaScript é a ferramenta certa

Há casos legítimos:

  • Plataformas limitadas. Algumas configurações de hospedagem compartilhada, CDN ou CMS não dão acesso a regras de redirecionamento no servidor. Um redirecionamento JS é uma alternativa válida — e, notavelmente, o Google usou redirecionamentos JS em seu próprio blog do Webmaster porque, como Gary Illyes disse, “that was the only thing we could use for 1:1 redirects, and it works on Google” (tradução) «essa era a única coisa que podíamos usar para redirecionamentos 1:1, e funciona no Google» (OnCrawl).
  • Tratamento de erros em SPA. O Google endossa explicitamente isso: “Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code.” (tradução) «Use um redirecionamento JavaScript para uma URL para a qual o servidor responda com um código de status HTTP 404.» (Google Search Central) Um aplicativo de página única que resolve uma rota inválida pode redirecionar para um endpoint 404 real para que o Google processe o erro corretamente em vez de indexar um soft 404.

Para migrações permanentes de URL, esta não é a ferramenta — use um 301. Faço o mesmo ponto em migrações de site: redirecionamentos JavaScript são um último recurso, e o Google pode nunca vê-los.

Geradores de site estático: a armadilha dos aliases do Hugo

Uma surpresa comum: o frontmatter aliases: do Hugo historicamente gerou páginas HTML de meta refresh, não redirecionamentos 301 no servidor — e outros geradores estáticos fizeram coisas semelhantes por padrão. Os padrões dos geradores mudam entre versões, então verifique a saída real da sua versão implantada atual em vez de assumir; se aliases: não estiver fornecendo 301s, você precisa de regras de redirecionamento no nível da plataforma (Netlify _redirects, Cloudflare Workers, Vercel vercel.json) além de (no Hugo) disableAliases: true. Eu abordo isso em detalhes em Hugo SEO.

Melhores práticas de implementação

Se um redirecionamento JavaScript for genuinamente sua única opção:

  • Use window.location.replace(), não .href. Como o Search Engine Journal coloca, redirecionamentos JS “normalmente usam a função window.location.replace() em vez de window.location.href para evitar loops de redirecionamento de UX” (SEJ).
  • Coloque-o no <head>, não no <body>. Os navegadores analisam HTML sequencialmente e executam scripts conforme os encontram, então “posicione redirecionamentos JavaScript no <head> em vez de <body> para minimizar atrasos” (OnCrawl).
  • Redirecione para o destino final em um único salto. Um redirecionamento JS para uma página que em si faz 301 para outro lugar cria uma cadeia; cadeias desperdiçam orçamento de rastreamento e podem aparecer no GSC como um erro de redirecionamento.
  • Remova a URL de origem do seu sitemap XML. Sitemaps devem listar URLs canônicas, indexáveis — não URLs que redirecionam.
  • Aponte os links internos para o destino, para que não passem pelo redirecionamento.
  • Certifique-se de que o Googlebot possa buscar o JS. Se o redirecionamento estiver em um script externo bloqueado por robots.txt, o Google não pode renderizá-lo e não verá o redirecionamento.

Como detectar redirecionamentos JavaScript

Eles não se anunciam como um 301 em um cabeçalho, então você precisa renderizar:

  • Um rastreador com renderização JS ativada. O OnCrawl recomenda rastrear com “renderização JavaScript habilitada (tempo limite mínimo de 5 segundos)”; Screaming Frog e Ahrefs Site Audit podem ambos renderizar. Sem renderização, uma página com redirecionamento JS apenas parece um 200 normal.
  • Chrome DevTools. A aba Network (com “Preserve log”) mostra a navegação no lado do cliente; a extensão Redirect Path também sinaliza isso.
  • No Search Console, um redirecionamento JS processado com sucesso aparece em Página com redirecionamento — o mesmo status de qualquer URL redirecionada, o que é normal para fontes não canônicas. Esse rótulo não é garantido em qualquer verificação, no entanto: ele reflete o que o Google buscou, renderizou, interpretou e canonicalizou no momento amostrado, então uma URL pode mostrar um status diferente (ou nenhum status de redirecionamento ainda) entre verificações sem que isso seja um erro de sua parte.

O que eu realmente faria

No servidor primeiro, sempre. Meta refresh (0 segundo) quando você pode editar HTML, mas não a configuração do servidor. JavaScript apenas quando ambos estiverem fora de questão — e então com window.location.replace() no <head>, um sitemap limpo e uma verificação de que o redirecionamento realmente renderiza para o Googlebot. Para qualquer coisa permanente ou de alto valor, a confiabilidade extra de um 301 vale quase qualquer esforço para obtê-lo.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.