Meta refresh e redirecionamento JavaScript: o Google segue?

O Google segue, sim, tanto o meta refresh quanto o redirecionamento em JavaScript (window.location). Mas segue de um jeito menos direto e menos confiável do que um 301 enviado pelo servidor, e essa diferença é o que define quando vale a pena usá-los. O redirecionamento no servidor acontece antes de qualquer HTML ser entregue. Os outros dois só existem depois que a página foi baixada e, no caso do JavaScript, depois que ela foi renderizada.

A regra prática é simples: se você consegue configurar um redirecionamento no servidor, na CDN ou no painel da hospedagem, use esse. Meta refresh e JavaScript são o plano B para quem está em hospedagem estática, em um CMS que não expõe o servidor ou em uma plataforma que só deixa editar o HTML. Este texto explica como cada um é processado, quais sinais chegam ao destino, quais erros são comuns e como montar o plano B com o menor prejuízo possível. A escolha entre os códigos 301 e 302 fica fora daqui, porque ela só existe no lado do servidor.

Como o Google processa cada tipo de redirecionamento

Um redirecionamento no servidor devolve um código de status (301, 302, 307, 308) e um cabeçalho Location. O rastreador lê isso na primeira resposta e sabe o destino sem precisar interpretar a página. É o método mais barato, mais rápido e mais previsível, e por isso a documentação do Google o coloca como preferência sempre que possível.

O meta refresh vive dentro do HTML, na forma de uma tag meta com http-equiv="refresh" e um atraso em segundos seguido da URL de destino. O servidor responde 200, entrega a página, e só então o rastreador encontra a instrução. Como está no HTML bruto, ela é visível logo na fase de rastreamento, sem depender de renderização.

O redirecionamento em JavaScript usa comandos como window.location.href, window.location.replace() ou location.assign(). O servidor também responde 200, mas a instrução só aparece quando o script é executado. Isso significa que o Google precisa enfileirar a página para renderização, executar o código e só então descobrir que ela aponta para outro lugar. Esse passo extra pode levar de instantes a um atraso considerável, dependendo da fila e dos recursos disponíveis.

Na prática, os três chegam ao mesmo lugar, que é o Google associar a URL antiga à nova. A diferença está no caminho: um é lido na resposta, outro no HTML e o último no resultado da renderização. Cada etapa a mais é uma chance de algo dar errado.

O que o Google faz com o meta refresh

A documentação do Google sobre redirecionamentos descreve o meta refresh como um método suportado. O ponto de atenção é o atraso. Um refresh instantâneo, com zero segundo, tende a ser tratado como um redirecionamento definitivo. Um refresh com atraso, como os clássicos "você será redirecionado em 5 segundos", tende a ser tratado como temporário, o que muda qual URL o Google prefere manter no índice.

Isso tem uma consequência direta para quem migra de domínio em hospedagem estática. Se o objetivo é transferir a identidade da página antiga para a nova, o atraso deve ser zero. Uma contagem regressiva é ruim para o usuário e ruim como sinal, porque diz ao buscador que a página antiga continua existindo e pode voltar.

A sintaxe correta para o caso instantâneo é uma tag meta dentro do head, com o conteúdo "0; url=https://exemplo.com.br/nova-pagina/". Use sempre a URL absoluta, com protocolo e domínio, e coloque a tag o mais alto possível no head, antes de scripts e folhas de estilo pesadas, para que ela seja lida logo.

Um detalhe pouco lembrado: o meta refresh também pode ser usado sem URL, para recarregar a mesma página a cada N segundos. Isso não é redirecionamento, e páginas que se recarregam sozinhas causam problemas de usabilidade e de acessibilidade. Se você encontrar isso em uma auditoria, trate como um defeito à parte.

O que o Google faz com o redirecionamento em JavaScript

O Googlebot renderiza páginas com um navegador baseado em Chromium, então executa window.location e segue o destino. A documentação de JavaScript e SEO do Google diz que esse método funciona, mas o classifica como último recurso, para quando nenhuma das opções no servidor é possível.

O primeiro risco é a dependência da renderização. Se o script estiver bloqueado no robots.txt, se der erro antes de chegar à linha do redirecionamento ou se depender de uma ação do usuário (um clique, um evento de rolagem), o Google pode nunca ver o redirecionamento. O teste que vale é abrir a inspeção de URL no Search Console e conferir o HTML renderizado. Se o destino não aparece ali, o redirecionamento não está sendo tratado como você imagina.

O segundo risco é a variação de comportamento entre rastreadores. O Google renderiza JavaScript, mas nem todo rastreador faz isso. Outros buscadores, ferramentas de auditoria, pré-visualizadores de links em redes sociais e muitos robôs de coleta leem apenas o HTML bruto. Para eles, a URL antiga continua sendo uma página normal, com status 200, e o destino nunca é descoberto.

O terceiro risco é o redirecionamento condicional. Um script que redireciona só em certos dispositivos, países ou depois de ler um cookie pode levar o Google a ver um comportamento diferente do que o usuário vê. Se o script manda o Googlebot para um lugar e os visitantes para outro, isso se aproxima de cloaking. Mantenha o redirecionamento incondicional e igual para todos.

O quarto risco são os erros que disfarçam um 404. Um padrão comum em aplicações de página única é enviar para a página inicial ou para uma rota de erro via JavaScript quando o conteúdo não existe. O servidor respondeu 200, então o Google vê uma página válida que termina em um conteúdo vazio ou genérico, e isso costuma ser classificado como soft 404. Quando o conteúdo realmente sumiu, a resposta honesta é um status 404 ou 410 do servidor.

Meta refresh, JavaScript e 301: o que muda na prática

A comparação útil não é sobre qual é melhor em teoria, e sim sobre o que cada um garante. O 301 garante que qualquer cliente HTTP, com ou sem navegador, receba a instrução. O meta refresh garante isso a qualquer cliente que leia HTML. O JavaScript só garante para quem executa scripts.

Existem quatro eixos em que as diferenças aparecem, e eles estão listados ao final desta seção.

Quanto à transferência de sinais como links recebidos, o Google afirma tratar os redirecionamentos que consegue interpretar como sinal de que a URL nova é a canônica. Só que essa afirmação depende de ele ter visto e entendido o redirecionamento. Quanto mais indireto o método, maior a chance de a consolidação ser mais lenta ou parcial, e em uma migração grande isso aparece como uma janela mais longa de oscilação de tráfego.

• Velocidade de descoberta: o 301 é lido na primeira resposta. O meta refresh é lido assim que o HTML é analisado. O JavaScript espera a renderização, que pode ocorrer bem depois do rastreamento.
• Clareza do sinal: o 301 declara de forma inequívoca que a mudança é definitiva. O meta refresh depende do atraso para ser interpretado como definitivo ou temporário. O JavaScript não carrega nenhuma semântica de permanência.
• Compatibilidade: o 301 funciona em qualquer cliente. O meta refresh funciona na maioria, inclusive leitores de tela configurados para isso. O JavaScript exige um motor de scripts.
• Experiência do usuário: o 301 é praticamente invisível. O meta refresh e o JavaScript exigem carregar a página antiga antes, o que adiciona um salto perceptível em conexões lentas e pode gerar uma piscada em branco.

Quando você realmente não tem outra opção

Existem cenários legítimos em que o redirecionamento no servidor não está disponível. O mais frequente é a hospedagem estática simples, como o GitHub Pages, que serve arquivos sem permitir regras de redirecionamento. Outro é um CMS ou construtor de sites hospedado que só deixa editar o conteúdo e, às vezes, o head das páginas. Há também o caso de uma equipe de marketing que controla o HTML, mas depende de outro time para mexer na infraestrutura.

Antes de aceitar o plano B, vale verificar se sua plataforma tem uma alternativa nativa. Netlify e Cloudflare Pages aceitam um arquivo de regras de redirecionamento que gera respostas 301 reais. A Vercel permite declarar redirecionamentos na configuração do projeto. Muitos construtores de sites e e-commerces têm um menu de redirecionamentos de URL no painel, e esse recurso costuma gerar um 301 de verdade. Um CDN ou proxy na frente do site, como a Cloudflare, também pode aplicar regras de redirecionamento sem tocar na hospedagem de origem. Se qualquer uma dessas opções existe, ela vence o meta refresh.

Quando nada disso é possível, a ordem de preferência é esta: meta refresh instantâneo combinado com um link canônico apontando para o destino, e o JavaScript só como complemento, nunca como única barreira. O meta refresh é legível no HTML bruto, então atinge mais rastreadores do que o script.

Uma página de redirecionamento bem montada reúne vários elementos. No head ficam a tag de refresh com zero segundo, o link rel="canonical" com a URL de destino e, opcionalmente, um script curto com location.replace para o mesmo endereço. No corpo entra um link comum para o destino, com texto como "Esta página mudou para o novo endereço", o que serve de rede de segurança para quem tem scripts e refresh desativados. O uso de replace no lugar de href evita que a página antiga fique no histórico do navegador, o que impede o botão Voltar de prender o visitante em um ciclo.

Erros comuns que quebram o redirecionamento

Cadeias de redirecionamento são o erro mais caro. A URL A leva por meta refresh à B, que por JavaScript leva à C, e cada salto exige mais uma rodada de rastreamento e renderização. O Google segue um número limitado de saltos, e uma cadeia mista torna a depuração difícil. Aponte sempre para o destino final, não para a etapa seguinte.

Outro erro é redirecionar tudo para a página inicial. Se mil URLs antigas mandam para a home, o Google pode tratar isso como soft 404, porque o destino não corresponde ao conteúdo original. Redirecione página a página, para a equivalente mais próxima. Se não existe equivalente, é melhor deixar a página sumir com um 404 ou 410 do que fabricar um destino irrelevante.

Também é frequente bloquear no robots.txt a página antiga ou o arquivo de script que contém a lógica. Se o rastreador não pode ler a página, ele não vê o meta refresh. Se não pode carregar o script, não executa o redirecionamento. Em ambos os casos a URL antiga permanece no índice como se nada tivesse mudado.

O último erro é esquecer a consistência dos sinais. Se a URL antiga tem um canonical apontando para si mesma enquanto o redirecionamento leva ao destino, o Google recebe instruções contraditórias. O canonical, o redirecionamento, o sitemap e os links internos precisam apontar todos para a mesma URL final.

Como verificar se o Google entendeu o redirecionamento

A primeira checagem é a inspeção de URL no Search Console, aplicada à URL antiga. Na visualização do HTML renderizado, procure o destino. Em seguida confira, na seção de indexação, qual canônica o Google escolheu. Se ele ainda indica a URL antiga como canônica depois de semanas, é sinal de que o redirecionamento não foi interpretado ou de que outros sinais o contradizem.

A segunda checagem é ver o que um cliente sem JavaScript enxerga. Um comando curl na URL antiga mostra o HTML bruto e o status devolvido. Se a tag de refresh aparece ali, o método está acessível a rastreadores simples. Se o destino só surge quando você abre no navegador, o redirecionamento depende de scripts.

A terceira é olhar o relatório de páginas do Search Console e os logs do servidor, quando disponíveis. As URLs antigas devem migrar de indexadas para o estado de página com redirecionamento, e o destino deve ganhar impressões gradualmente. Se a URL antiga continua recebendo rastreamentos de forma regular por meses, vale reavaliar o método e tentar migrar para um 301 real assim que a plataforma permitir.

Por fim, lembre que o redirecionamento por meta refresh ou JavaScript é uma solução que pode ser substituída. Documente quais URLs dependem dele. Quando a hospedagem mudar ou o CMS passar a oferecer redirecionamento no servidor, troque todos de uma vez e remova as páginas de ponte, em vez de deixá-las acumulando no site.