Redirecionamento Meta Refresh
O que é um redirecionamento meta refresh, sua posição entre redirecionamentos no servidor e em JavaScript, a diferença entre versões instantânea e atrasada e por que ele é desencorajado.
Idiomas
Meta refresh é uma tag HTML <meta http-equiv="refresh"> ou o cabeçalho HTTP Refresh, não um código de status. O servidor retorna 200, e o navegador navega depois do carregamento. Para o Google, content="0" é permanente e valores maiores que 0 são temporários. Use somente como último recurso sem acesso ao servidor, prefira atraso zero, adicione canonical e link alternativo e substitua por 301 assim que puder.
TL;DR — Um redirecionamento meta refresh é uma linha de HTML — uma tag
Evidence for this claim Google supports instant and delayed meta refresh redirects but recommends server-side permanent redirects when possible. Scope: Google redirect processing and implementation preference. Confidence: high · Verified: Google Search Central: Redirects Evidence for this claim Timed redirects can create accessibility problems, particularly when users cannot control the time limit. Scope: WCAG timing guidance; not a search-ranking claim. Confidence: high · Verified: W3C WCAG: Timing Adjustable<meta http-equiv="refresh">— que manda o navegador ir para outra URL depois que a página carrega. Não é um código de status HTTP como 301. O servidor entrega primeiro uma página normal; depois, o navegador executa o redirecionamento. Funciona, mas é mais lento e desajeitado que um redirecionamento real no servidor, por isso use-o apenas quando não houver alternativa.
O que é um redirecionamento meta refresh
A maioria dos redirecionamentos acontece no servidor. Você solicita uma URL e, antes de receber qualquer página, o servidor responde “isso mudou — vá para cá” (um 301 ou 302). Um meta refresh funciona de outro modo. O servidor devolve uma página normal e funcional (200 OK) e, dentro do HTML dessa página, há uma instrução que manda o navegador ir para outro lugar:
<meta http-equiv="refresh" content="0;url=https://example.com/newlocation">A tag fica no <head> da página. O número antes do ponto e vírgula indica quantos segundos esperar; url= informa o destino. Como quem age é o navegador, não o servidor, trata-se de um redirecionamento no lado do cliente.
Instantâneo ou atrasado
Há duas variantes; a diferença é apenas esse número:
- Instantâneo —
content="0;url=...". O navegador muda de endereço assim que a página termina de carregar. Se você precisar usar meta refresh, prefira esta versão. O Google a trata como redirecionamento permanente (semelhante a 301). - Atrasado —
content="5;url=..."(qualquer valor maior que 0). O navegador exibe a página por alguns segundos e depois muda. O Google o trata como temporário, e o atraso é a característica historicamente associada à reputação de spam.
Por que se recomenda evitá-lo
O meta refresh funciona, mas é mais fraco que um redirecionamento no servidor porque o navegador só executa a instrução quando a página é considerada totalmente carregada — a própria condição de disparo do padrão HTML. Um redirecionamento no servidor ocorre antes de qualquer página carregar. A orientação do Google coloca os redirecionamentos no servidor em primeiro lugar, o meta refresh no meio e JavaScript por último.
A regra simples é: use um 301 real sempre que puder. Recorra ao meta refresh somente em hospedagens nas quais você realmente não consiga configurar um redirecionamento no servidor, como algumas opções estáticas. Mesmo assim, use a versão instantânea (0) e substitua-a por um 301 assim que possível.
Quer ver a redação exata do Google, o aspecto de acessibilidade e como detectar esses redirecionamentos? Abra a aba Avançado.
TL;DR — Meta refresh é uma tag HTML
Evidence for this claim Google supports instant and delayed meta refresh redirects but recommends server-side permanent redirects when possible. Scope: Google redirect processing and implementation preference. Confidence: high · Verified: Google Search Central: Redirects Evidence for this claim Timed redirects can create accessibility problems, particularly when users cannot control the time limit. Scope: WCAG timing guidance; not a search-ranking claim. Confidence: high · Verified: W3C WCAG: Timing Adjustable<meta http-equiv="refresh">(ou o cabeçalhoRefreshinserido pelo servidor), não um status3xx: o servidor retorna200, e o navegador só navega depois que a página termina de carregar. Para o Google, a versão instantânea (content="0") é permanente, como 301/308; a atrasada (> 0) é temporária. Por depender do carregamento completo, fica entre redirecionamentos no servidor e em JavaScript na ordem de confiabilidade do Google. Mueller disse que ela “should just work” (tradução) «simplesmente deveria funcionar», mas não a recomenda por causa do histórico do botão Voltar e do tempo de processamento. Use-a apenas sem acesso ao servidor, prefira0, combine comrel=canonicale um link alternativo visível e troque por um 301 real assim que puder.
Não é um código de status
Este é o ponto essencial. Meta refresh não é uma resposta HTTP 3xx. O servidor retorna um 200 OK comum, com o corpo completo da página; no <head>, uma diretiva HTML manda o navegador agir depois do carregamento:
<!-- Instant: treated by Google as permanent -->
<meta http-equiv="refresh" content="0;url=https://example.com/newlocation">Existe um equivalente no servidor — o cabeçalho HTTP Refresh — que faz o mesmo, mas é inserido por código do servidor em vez de ficar na marcação:
HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocationAté a versão em cabeçalho retorna 200, não 3xx. Em ambos os casos, é o navegador que navega, e não o servidor.
Instantâneo ou atrasado — a distinção do Google
O Google traça a linha pelo número de segundos. Em Redirecionamentos e a Pesquisa Google, afirma que “differentiates between two kinds of meta refresh redirects” (tradução) «diferencia dois tipos de redirecionamento meta refresh»:
- Instantâneo (
content="0") — “Triggers as soon as the page is loaded… Google Search interprets instantmeta refreshredirects as permanent redirects.” (tradução) «É acionado assim que a página carrega… A Pesquisa Google interpreta redirecionamentos meta refresh instantâneos como permanentes.» Para canonicalização, fica na mesma categoria de 301/308: o Google o segue e usa como sinal de que o destino deve ser canônico. - Atrasado (
contentmaior que 0) — “Triggers only after an arbitrary number of seconds… Google Search interprets delayedmeta refreshredirects as temporary redirects.” (tradução) «É acionado somente após um número arbitrário de segundos… A Pesquisa Google interpreta redirecionamentos meta refresh atrasados como temporários.» Como em 302/303/307, outros sinais ainda podem indexar o destino, mas o redirecionamento não indica mudança permanente.
Minha ordenação no guia da Ahrefs sobre 11 tipos de redirecionamento reflete isso: para mudanças permanentes, 308 / 301 → meta refresh 0 → JavaScript → crypto; o meta refresh atrasado cai no nível temporário, junto de 302/303/307.
A posição na ordem de preferência do Google
A documentação do Google publica uma tabela “ordered by how likely Google is able to interpret [the redirect] correctly” (tradução) «ordenada pela probabilidade de o Google interpretar o redirecionamento corretamente». Para redirecionamentos permanentes: HTTP 301 → HTTP 308 → meta refresh (0 seconds) → JavaScript location → crypto. O meta refresh ocupa o degrau intermediário: abaixo do servidor e acima do JavaScript.
O Google é explícito nos dois limites. No superior: “If server-side redirects aren’t possible to implement on your platform, meta refresh redirects may be a viable alternative.” (tradução) «Se não for possível implementar redirecionamentos no servidor em sua plataforma, meta refresh pode ser uma alternativa viável.» No inferior: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (tradução) «Use redirecionamentos JavaScript apenas se não puder usar os de servidor ou meta refresh.» É a escada inteira em duas frases, coerente com o hub de redirecionamentos.
Duas “ordens” diferentes — não as confunda
Há uma sutileza que confunde desenvolvedores. A MDN publica uma ordem diferente, mas ela descreve a ordem de execução no navegador quando vários mecanismos coexistem, não a confiabilidade para SEO: HTTP primeiro, depois JavaScript e meta refresh por último, pois “the <meta> redirect happens after the page is completely loaded, which is after all scripts have executed.” (tradução) «o redirecionamento <meta> ocorre depois que a página carrega por completo, após a execução de todos os scripts».
Assim, JavaScript “vence” meta refresh na ordem temporal da MDN, enquanto meta refresh “vence” JavaScript na ordem de confiabilidade do Google. Ambas estão corretas. A MDN pergunta qual dispara primeiro no navegador; o Google, qual é interpretado com mais segurança para busca. Separe esses eixos e a contradição desaparece.
Por que depender do carregamento torna o método mais fraco
Um meta refresh só dispara depois que a página está totalmente carregada. Segundo a referência da MDN sobre <meta http-equiv>, “the timer starts when the page is completely loaded, which is after the load and pageshow events have both fired.” (tradução) «o cronômetro começa quando a página termina de carregar, depois que os eventos load e pageshow são disparados». Isso vale até para content="0": “instantâneo” significa nenhum atraso adicional após o carregamento, não tempo decorrido zero.
Para ser preciso, meta refresh não é processado na etapa de renderização JavaScript do Google como window.location; ele é lido diretamente do <head> HTML analisado. A fraqueza está na dependência do carregamento completo — rede e recursos bloqueadores — e, nas variantes atrasadas, na espera arbitrária.
O que o padrão HTML realmente especifica
O algoritmo de atualização declarativa do padrão HTML é mais preciso que “espera a página carregar”; alguns detalhes importam na auditoria:
- Momento devido. A atualização vence depois do carregamento completo do documento e, para um elemento
<meta>, de sua inserção — o que ocorrer por último — com ajustes pelas preferências do usuário. - URLs relativas. O destino é resolvido em relação à URL do documento; audite o endereço absoluto, não apenas o texto em
url=. - A primeira vence. Depois que o documento é marcado para atualização declarativa, instruções posteriores são ignoradas. Duas tags
<meta refresh>conflitantes, ou uma tag e um cabeçalho, são defeito de autoria. - Destinos
javascript:são rejeitados. O algoritmo encerra sem navegar. - A execução não é garantida. A navegação pode ser cancelada, ajustada por preferências, bloqueada pelo sandbox, exposta na interface do navegador ou simplesmente não ocorrer.
- Histórico. O padrão especifica tratamento replace, substituindo a entrada atual. Isso contrasta com a formulação “meta refresh always leaves the source page in history” (tradução) «meta refresh sempre deixa a página de origem no histórico». Não trate essa observação dependente de navegador e versão como regra universal.
John Mueller resumiu o motivo para não recomendar o recurso (relatado pelo Search Engine Roundtable, 2018): meta refresh “should just work,” (tradução) «simplesmente deveria funcionar», mas há dois problemas — UX (“it keeps the page in browser history, afaik” (tradução) «mantém a página no histórico do navegador, até onde sei») e tempo de processamento, porque o Google precisa analisar a página. “Once processed, it’s just like a redirect.” (tradução) «Depois de processado, é como um redirecionamento.»
Por que é desencorajado — o peso histórico
Além das razões de UX e processamento, o meta refresh carrega uma reputação. Na era do spam dos anos 2000, era um veículo comum para páginas doorway: a página ranqueava para uma consulta e quase instantaneamente levava o visitante a um destino menos relevante. Nenhuma política atual do Google cita “meta refresh” pelo nome; as políticas definem redirecionamentos enganosos e abuso de doorway como categorias gerais. Trate isso como contexto histórico, não como citação explícita de política atual.
Há também uma falha concreta apontada por Mueller em 2018 (via Search Engine Journal): um site enviava páginas de listagem a uma página de pagamento compartilhada. “So if you do this across your pages there’s a big chance we’ll follow this redirect and think ‘Oh, this payment page is actually what you want to have indexed and not the actual content.’” (tradução) «Se você fizer isso em várias páginas, há grande chance de seguirmos o redirecionamento e entendermos que a página de pagamento é o conteúdo que você quer indexar.» Muitas fontes apontando para um destino genérico podem fazer esse destino ser indexado no lugar do conteúdo.
Nada disso torna um uso isolado e legítimo um risco de penalidade. A documentação atual do Google o chama de “a viable alternative” (tradução) «uma alternativa viável» quando o redirecionamento no servidor não é possível. O risco está no padrão e na intenção, não no mecanismo.
Evidence for this claim Google says meta refresh can be a viable alternative when server-side redirects are not possible, while permanent server-side redirects are recommended whenever possible for a URL move. Scope: meta refresh and HTTP Refresh interpretation Confidence: high · Verified: Redirects and Google SearchAcessibilidade: a mesma distinção entre instantâneo e atrasado
A orientação de acessibilidade quase espelha a de SEO, com uma ressalva: as técnicas WAI do W3C são exemplos para atender aos critérios WCAG, não regras obrigatórias. O requisito é o critério 2.2.1, Tempo Ajustável. Ainda assim, o W3C prefere redirecionamento no servidor e, quando o lado do cliente é necessário, as técnicas suficientes H76 e G110 pedem atraso zero (content="0"), conteúdo limitado ao redirecionamento e um link visível. Um meta refresh atrasado sem pausa, extensão ou desativação pode falhar, pois muda de página antes que usuários de tecnologias assistivas terminem a leitura. A nota de acessibilidade da MDN descreve o mesmo risco: usuários “may be unable to read through and understand the page’s content before being automatically redirected.” (tradução) «podem não conseguir ler e compreender o conteúdo antes do redirecionamento automático».
Portanto, mecanismo de busca e órgão de padrões chegam à mesma regra: instantâneo é aceitável; atrasado é arriscado. É outro motivo para preferir content="0".
Quando é um último recurso legítimo
Use meta refresh somente quando realmente não puder criar um redirecionamento no servidor. Casos reais:
- Hospedagens estáticas sem configuração de servidor, como GitHub Pages, sem regras
.htaccess/nginx. - Geradores de sites estáticos cujos “aliases” produzem meta refresh, não 301. O Hugo é um exemplo; seu frontmatter
aliases:gera pequenos arquivos HTML. Veja SEO para Hugo. - Exportações de plataformas no-code e alguns geradores de documentação que só emitem HTML estático.
Se não houver alternativa, implemente-o bem:
- Prefira o instantâneo (
content="0") — sinal permanente e melhor acessibilidade. - Combine com
rel="canonical"apontando para o destino. - Inclua um link alternativo visível e clicável para quem desativa a atualização automática.
- Não o empilhe em uma cadeia de redirecionamentos.
- Substitua-o por um 301 real assim que tiver acesso ao servidor. É uma ponte, não um destino.
Como detectar meta refresh no site
Crawlers como Screaming Frog, Sitebulb, Ahrefs Site Audit e Semrush geralmente o sinalizam com gravidade baixa a média, não como erro crítico. Em poucas URLs isoladas, corrija quando for conveniente; uso amplo em páginas importantes merece prioridade. Para uma URL, veja o código-fonte ou use curl e procure http-equiv="refresh" no <head>; há comandos prontos na aba Scripts.
Evite afirmações categóricas sobre link equity. A frase da central da Ahrefs de que meta refresh “does not pass much or any link juice” (tradução) «transmite pouco ou nenhum valor de link» é questionável: a tabela do Google coloca a versão instantânea na mesma categoria de interpretação permanente que 301, mas isso não promete paridade de PageRank ou ranqueamento. Nem o Google nem o padrão HTML documentam equivalência; trate tanto “passa o mesmo valor” quanto “passa pouco ou nada” como não comprovados.
Uma página-fonte com meta refresh ainda tem sua própria resposta HTTP e seu próprio documento HTML. Audite, nesta ordem: status e cabeçalhos da origem, incluindo Refresh; HTML bruto versus o que o navegador analisa; primeira diretiva efetiva e destino absoluto; classificação instantânea/permanente ou atrasada/temporária; canonical, robots e indexabilidade da origem; resposta final; controles e preferências que podem impedir a navegação; cache e histórico no navegador e versão testados; links internos para a origem; e o plano para substituir tudo por um redirecionamento no servidor. As abas Checklists e Scripts transformam isso em etapas e comandos.
Resumo de IA
Uma síntese da versão Avançado:
- Não é código de status. Meta refresh é uma tag HTML
<meta http-equiv="refresh">ou o cabeçalhoRefresh. O servidor retorna200; o navegador navega depois do carregamento completo. - Instantâneo ou atrasado.
content="0"é permanente para o Google, como 301/308;content > 0é temporário, como 302/303/307. - No meio da ordem do Google. Servidor → meta refresh → JavaScript → crypto. O Google o considera alternativa quando o servidor não está disponível e recomenda JavaScript somente depois dele.
- Duas “ordens”. Na execução da MDN, JavaScript vem antes de meta refresh; na confiabilidade do Google, meta refresh vem antes de JavaScript. São perguntas diferentes.
- Por que é mais fraco. O padrão HTML aguarda o carregamento e permite cancelamento por preferências; não há garantia de 100%. Mueller disse que “should just work” (tradução) «simplesmente deveria funcionar», mas citou histórico do navegador e custo de análise; o padrão atual especifica replace no histórico.
- Link equity não comprovado. A categoria de interpretação permanente não promete paridade de PageRank com 301.
- Acessibilidade. As técnicas suficientes H76/G110 pedem atraso zero, conteúdo apenas de redirecionamento e link alternativo; são exemplos, não regras obrigatórias. Atraso sem controle pode falhar o critério 2.2.1.
- Use apenas como último recurso. Em GitHub Pages,
aliasesdo Hugo e hosts estáticos/no-code, prefira0, adicionerel=canonicale link visível, evite cadeias e troque por 301 quando puder.
Documentação oficial
Documentação de fonte primária sobre meta refresh e sua posição.
- Redirecionamentos e a Pesquisa Google — tabela de preferência, distinção instantâneo/atrasado e enquadramento de “alternativa viável”.
- Políticas contra spam da Pesquisa Google — define redirecionamentos enganosos e abuso de doorway como categorias gerais; não cita meta refresh explicitamente.
MDN
<meta http-equiv>— mecânica no cliente: o cronômetro começa após o carregamento completo.- Cabeçalho HTTP
Refresh— equivalente inserido pelo servidor. - Redirecionamentos em HTTP — ordem de execução no navegador, diferente da ordem de SEO do Google.
W3C / WCAG
- H76: usar meta refresh para redirecionamento instantâneo no cliente — servidor preferido; sem ele, atraso zero e conteúdo limitado ao redirecionamento como técnica suficiente.
- G110: usar redirecionamento instantâneo no cliente — versão geral da mesma técnica.
- F41: falha por meta refresh com tempo limite — como atraso sem controle pode falhar 2.2.1; a página da técnica não é o requisito em si.
Citações das fontes
Declarações registradas. Cada link leva ao trecho citado.
Google — documentação de redirecionamentos da Pesquisa Google
- “The following table explains the various ways you can use to set up permanent and temporary redirects, ordered by how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance of being interpreted correctly by Google).” (tradução) «A tabela explica as formas de configurar redirecionamentos permanentes e temporários, ordenadas pela probabilidade de o Google interpretá-las corretamente.» Ir para a citação
- “If server-side redirects aren’t possible to implement on your platform, meta refresh redirects may be a viable alternative.” (tradução) «Se não for possível implementar redirecionamentos no servidor em sua plataforma, meta refresh pode ser uma alternativa viável.» Ir para a citação
- “Google differentiates between two kinds of meta refresh redirects: Instant meta refresh redirect: Triggers as soon as the page is loaded in a browser. Google Search interprets instant meta refresh redirects as permanent redirects. Delayed meta refresh redirect: Triggers only after an arbitrary number of seconds set by the site owner. Google Search interprets delayed meta refresh redirects as temporary redirects.” (tradução) «O Google diferencia dois tipos: o instantâneo dispara assim que a página carrega e é interpretado como permanente; o atrasado dispara após os segundos definidos pelo proprietário e é interpretado como temporário.» Ir para a citação
- “Place the meta refresh redirect either in the <head> element in the HTML or in the HTTP header with server-side code.” (tradução) «Coloque o meta refresh no elemento <head> do HTML ou no cabeçalho HTTP com código no servidor.» Ir para a citação
- “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (tradução) «Use JavaScript apenas se não puder usar redirecionamentos no servidor ou meta refresh.» Ir para a citação
- “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 toda URL rastreada, a renderização pode falhar; nesse caso, um redirecionamento JavaScript talvez nunca seja visto.» Ir para a citação
John Mueller, Google (tweets relatados pelo Search Engine Roundtable, 2 de março de 2018)
- “A meta refresh type redirect should just work. We don’t recommend it for 2 reasons: UX (it keeps the page in browser history, afaik) & processing time (we need to parse the page to see it). Once processed, it’s just like a redirect.” (tradução) «Um redirecionamento meta refresh deveria funcionar. Não o recomendamos por UX — mantém a página no histórico, até onde sei — e pelo tempo para analisar a página. Depois de processado, é como um redirecionamento.» Ir para a citação
John Mueller, Google (hangout da Central para Webmasters, julho de 2018, relatado pelo Search Engine Journal)
- “So if you do this across your pages there’s a big chance we’ll follow this redirect and think ‘Oh, this payment page is actually what you want to have indexed and not the actual content,’ and in that case we won’t have the content indexed.” (tradução) «Se você fizer isso em várias páginas, há grande chance de seguirmos o redirecionamento e entendermos que a página de pagamento é o que deve ser indexado, e não o conteúdo real.» Ir para a citação
MDN
- “The timer starts when the page is completely loaded, which is after the load and pageshow events have both fired.” (tradução) «O cronômetro começa quando a página termina de carregar, depois dos eventos load e pageshow.» Ler a documentação
- “When possible, use HTTP redirects and don’t add <meta> element redirects.” (tradução) «Quando possível, use redirecionamentos HTTP e não adicione redirecionamentos com <meta>.» Ler a documentação
Qual redirecionamento devo usar?
Meta refresh é uma alternativa, não a primeira escolha. Comece pela opção mais forte que você consegue implementar.
Choosing a redirect when meta refresh is on the table
Mitos e erros sobre meta refresh
Equívocos comuns e o que realmente é verdade.
“Meta refresh é um redirecionamento HTTP / código 3xx.”
Não. É uma tag HTML ou o cabeçalho Refresh que o navegador executa depois de uma resposta 200 e do carregamento completo, não um status enviado antes do conteúdo.
“Um meta refresh de 0 segundo dispara antes de a página carregar.”
Não. Segundo a MDN, “the timer starts when the page is completely loaded.” (tradução) «o cronômetro começa quando a página termina de carregar». content="0" significa nenhum atraso adicional, não tempo zero.
“Meta refresh é igual a redirecionamento JavaScript.” Não exatamente. Ambos são no cliente, mas meta refresh é declarado no HTML; JavaScript exige execução de script. O Google coloca meta refresh acima de JS em confiabilidade; a MDN coloca JS síncrono antes na execução.
“Meta refresh não transmite link equity / PageRank.” Essa afirmação não tem suporte, assim como a oposta. O Google põe a versão instantânea na mesma categoria de interpretação permanente de 301/308, mas não promete paridade de PageRank, equity ou ranqueamento.
“Meta refresh sempre é spam e causa penalidade.” Falso. Há associação histórica com doorway, mas um uso legítimo em host estático não é sinal de spam. O Google o chama de “a viable alternative” (tradução) «uma alternativa viável». O risco é o padrão e a intenção.
“Alguns segundos de atraso são uma cortesia de UX.” Depende. Valor maior que 0 recebe tratamento temporário do Google e atraso sem controle é o padrão que as técnicas de acessibilidade evitam. A conformidade depende do critério 2.2.1 no caso concreto.
“Meu crawler sinalizou meta refresh; é crítico.” Exagero em casos isolados. Ferramentas como Screaming Frog o classificam como aviso de baixa gravidade. Substitua por 301 quando puder, mas priorize redirecionamentos quebrados, loops e sinais de indexação ausentes — salvo uso amplo ou em páginas valiosas.
Se você precisar publicar meta refresh — checklist
Use somente depois de confirmar que o redirecionamento no servidor realmente não está disponível:
- Confirmei que não há opção no servidor (hospedagem,
.htaccess/nginx, CDN ou framework). - Usei a forma instantânea,
content="0". - A tag está no
<head>, eurl=aponta ao destino final. - Adicionei
rel="canonical"para o destino. - Incluí um link alternativo visível e clicável.
- O destino retorna
200limpo, não 404, redirecionamento ou erro. - Registrei a substituição por 301 real quando houver acesso ao servidor.
Auditoria de meta refresh em todo o site
- Rastreei o site e exportei as URLs sinalizadas.
- Verifiquei status HTTP e cabeçalhos, inclusive
Refresh, não apenas HTML. - Identifiquei a primeira diretiva efetiva e resolvi
url=como URL absoluta. - Classifiquei instantâneo/permanente ou atrasado/temporário e auditei canonical, robots e indexabilidade da origem.
- Separei casos isolados de uso amplo ou em páginas de alto valor.
- Procurei várias páginas apontando para um destino genérico de pagamento.
- Marquei versões atrasadas como questão de SEO e acessibilidade.
Meta refresh — resumo rápido
As duas variantes
| Variante | Sintaxe | Tratamento do Google | Acessibilidade |
|---|---|---|---|
| Instantânea | content="0;url=..." | Permanente (como 301/308) | Técnica suficiente (H76/G110) |
| Atrasada | content="5;url=..." (qualquer > 0) | Temporária (como 302/303/307) | Pode falhar 2.2.1 (padrão F41) |
Preferência do Google para redirecionamentos permanentes, do mais forte ao mais fraco
| Posição | Método | Observações |
|---|---|---|
| 1 | 301 / 308 (servidor) | Melhor: dispara antes do carregamento |
| 2 | Meta refresh 0 | Permanente, mas lento e dependente do carregamento |
| 3 | location em JavaScript | Exige renderização; pode não ser visto se ela falhar |
| 4 | Redirecionamento crypto | Último recurso; nem todo bot oferece suporte |
Duas ordens — não as confunda
| Pergunta | Ordem |
|---|---|
| Google — confiabilidade para SEO | servidor → meta refresh → JavaScript → crypto |
| MDN — tempo de execução no navegador | HTTP → JavaScript → meta refresh |
Fatos rápidos
- Não é status: o servidor retorna
200, e o navegador navega após o carregamento. - O cabeçalho
Refresh:é o equivalente inserido pelo servidor, ainda com200. - “Instantâneo” significa atraso zero após o carregamento.
- Mueller citou histórico do navegador e custo de análise; o padrão especifica replace.
- Paridade de link equity/PageRank com 301 não é documentada.
- Crawlers o tratam com gravidade baixa a média.
- Use só sem acesso ao servidor, como GitHub Pages,
aliasesdo Hugo e hosts estáticos/no-code.
Como detectar e interpretar tags meta refresh
Verifique uma URL na linha de comando
# Fetch the page and look for the meta refresh tag in the HTML
curl -s https://example.com/old-page/ | grep -i 'http-equiv=["'"'"']*refresh'
# Also check for the server-side Refresh header (case-insensitive)
curl -sI https://example.com/old-page/ | grep -i '^refresh:'Uma página meta refresh retorna 200, não 3xx; portanto, um curl -I que observa apenas status não a encontra. Inspecione especificamente o corpo e o cabeçalho Refresh.
Extraia o destino com uma expressão regular
O atributo content reúne atraso e URL em N;url=.... O comando extrai os dois:
curl -s https://example.com/old-page/ \
| grep -io 'content=["'"'"']*[0-9]\+; *url=[^"'"'"'>]*'
# → content="0;url=https://example.com/newlocation"Se o primeiro número for 0, é instantâneo e permanente para o Google; qualquer valor maior que 0 é atrasado e temporário.
XPath (para DOM renderizado ou analisador XML/HTML)
//meta[translate(@http-equiv,'REFSH','refsh')='refresh']/@contenttranslate() normaliza o atributo em minúsculas para corresponder a Refresh, REFRESH ou refresh.
Console do Chrome DevTools — inspecione a página atual
// Is there a meta refresh on this page, and where does it point?
const m = document.querySelector('meta[http-equiv="refresh" i]');
console.log(m ? m.getAttribute('content') : 'no meta refresh');Bookmarklet — sinalize meta refresh na página aberta
javascript:(()=>{const m=document.querySelector('meta[http-equiv="refresh" i]');alert(m?('Meta refresh: '+m.getAttribute('content')):'No meta refresh tag on this page');})();Salve como favorito. Ao clicar, ele informa se há meta refresh e mostra o valor de content, útil antes que a atualização leve você a outra URL.
Duas ordens, duas perguntas
Meta refresh aparece em duas ordens que parecem contraditórias até você nomear o eixo medido.
| Ordem | Pergunta | Sequência | Significado |
|---|---|---|---|
| Execução no navegador | Qual mecanismo dispara primeiro? | HTTP → JavaScript → meta refresh | Meta refresh espera o carregamento; JavaScript síncrono pode executar antes |
| Confiabilidade do Google | Qual é interpretado com mais segurança? | 301/308 no servidor → meta refresh instantâneo → JavaScript | HTML analisado é mais confiável que redirecionamento dependente de renderização JS |
Use o modelo em três etapas:
- Identifique a pergunta. Depurar o navegador é problema de ordem de execução; escolher mecanismo de migração para SEO é problema de confiabilidade.
- Não transforme tempo em recomendação. JavaScript disparar antes não o torna preferido pelo Google.
- Escolha a camada mais forte disponível. O padrão é redirecionamento permanente no servidor. Sem acesso, use meta refresh instantâneo (
0) com canonical e link alternativo, e substitua-o quando houver controle do servidor.
A mesma separação explica por que meta refresh “instantâneo” não é instantâneo na rede: ele adiciona atraso zero somente depois do carregamento, enquanto o redirecionamento no servidor chega antes do corpo do documento.
Teste seus conhecimentos: redirecionamentos meta refresh
Cinco perguntas rápidas sobre o funcionamento do meta refresh. Escolha uma resposta e confira.
Recursos que valem seu tempo
Meus textos relacionados
- 11 tipos de redirecionamento e seu impacto em SEO (Ahrefs, com Joshua Hardwick) — a escada completa, incluindo meta refresh 0 entre servidor e JavaScript.
- Problemas e boas práticas de SEO para JavaScript (Ahrefs) — renderização e por que JavaScript fica abaixo de meta refresh.
- O que é meta refresh e por que é considerado crítico? (Central da Ahrefs) — enquadramento do Site Audit; a afirmação “doesn’t pass link juice” (tradução) «não transmite valor de link» não é sustentada pela documentação do Google.
Minhas palestras
- Como a busca funciona (SlideShare) — rastreamento, renderização, indexação e ranqueamento, o pipeline que um redirecionamento no cliente precisa atravessar. Ressalva: “Este é meu entendimento dos sistemas… não será 100% completo ou preciso.”
Do setor
- Redirecionamentos e a Pesquisa Google — fonte primária para a distinção e a ordem.
- Google diz que meta refresh funciona, mas não é recomendado — relato da fala de Mueller.
- Google alerta que meta refresh pode indexar o conteúdo errado — falha da página de pagamento.
- Redirecionamentos em HTTP (MDN) — ordem de execução no navegador.
- Redirecionamentos com meta refresh (Sitebulb) — fluxo de auditoria.
- Redirecionamento interno (Meta Refresh) (Screaming Frog) — detecção e gravidade.
- Redirecione um site do GitHub Pages com este recurso HTTP — exemplo sem acesso ao servidor.
Registro de alterações
Atualizado em 13 de ago. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.
Atualizado em 13 de ago. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.
Atualizado em 18 de jul. de 2026.
Resumo editorial e detalhes registrados da alteração.Detalhes da alteração
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
-
As notas detalhadas sobre as alterações estão disponíveis atualmente em inglês.
Não é possível fazer a comparação completa — nenhum instantâneo anterior foi arquivado para esta revisão.