Redirects 301: quando usar, como configurar e como verificar

Resumo: Um redirect 301 avisa navegadores e mecanismos de busca que uma URL foi movida de forma permanente. O Google trata 301 e 308 como um sinal forte de que o destino deve ser a URL canônica; 302 e 307 são temporários e mantêm a URL antiga. Todo site deve responder em um único endereço: http://, https://, www e sem www precisam redirecionar para a mesma URL final, em um único salto. Mantenha os redirects por pelo menos um ano, atualize os links internos para o endereço final e verifique a cadeia inteira, não só onde ela termina.

Quando funcionam, os redirects são invisíveis. Quando não funcionam, os sintomas são vagos: o ranqueamento se divide entre www e sem www, uma migração perde tráfego por meses, a página inicial demora um segundo a mais para carregar porque passa por três endereços. A maioria desses problemas pode ser encontrada em um minuto, seguindo cada versão do seu endereço até o fim.

Este guia cobre os tipos de redirect e como o Google os trata, as versões de host que todo site precisa unificar, cadeias e loops, a configuração nos servidores mais comuns, como funciona o nosso verificador de redirects gratuito e como corrigir cada problema que ele relata.

O que é um redirect

Um redirect é uma resposta que diz "este recurso está em outro lugar" e informa o novo endereço no cabeçalho Location. O navegador solicita o novo endereço automaticamente. Um redirect no servidor aparece assim na requisição:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

O código de status diz aos clientes como tratar a mudança. A MDN separa os redirects em permanentes, após os quais os crawlers "will update the original URL" (atualizam a URL original), e temporários, que os crawlers "don't memorize" (não memorizam).

A documentação de redirects do Google também classifica um meta refresh instantâneo (0 segundo) e uma mudança de location em JavaScript como permanentes, e um meta refresh com atraso como temporário. Ela recomenda redirects permanentes no servidor sempre que possível e diz para "only use JavaScript redirects if you can't do server-side or meta refresh redirects" (usar redirects em JavaScript apenas se não for possível fazer no servidor ou com meta refresh), porque a renderização pode falhar.

Por que os redirects importam para SEO

Eles consolidam duplicatas. O guia de canonicalização do Google lista os redirects como "a strong signal that the target of the redirect should become canonical" (um sinal forte de que o destino do redirect deve se tornar canônico). Sem eles, sinais como links podem ficar divididos entre várias URLs com o mesmo conteúdo.

Eles levam as páginas movidas por uma migração. Quando as URLs mudam, um 301 de cada URL antiga para a nova equivalente diz ao Google para trocá-las no índice e leva quem chega por links antigos à página certa.

Eles protegem o HTTPS. O Google "prefers HTTPS pages over equivalent HTTP pages as canonical" (prefere páginas HTTPS a páginas HTTP equivalentes como canônicas), e o mesmo guia lista o redirect de HTTP para HTTPS como uma forma de reforçar isso.

Eles custam tempo. Cada salto é mais uma ida e volta antes de a página começar a carregar. Em redes móveis, uma cadeia de três redirects é um atraso perceptível antes de qualquer coisa aparecer.

Um site, um endereço

Para um crawler, estes são quatro sites diferentes, mesmo que mostrem a mesma página:

http://example.com/
http://www.example.com/
https://example.com/
https://www.example.com/

Escolha um, normalmente a versão HTTPS com ou sem www, e faça as outras três responderem com um único 301 direto para ele. A escolha entre www e sem www é questão de gosto; o que importa é que apenas uma versão responda com 200. Verifique também se o certificado TLS cobre example.com e www.example.com, ou o redirect de https://www falha antes de ser executado.

A mesma regra vale dentro do site: se /pricing e /pricing/ respondem 200, escolha uma forma e redirecione a outra.

Cadeias e loops

Uma cadeia é um redirect que leva a outro redirect. A mais comum é quando protocolo e host são tratados em etapas separadas:

http://www.example.com/  301 →  https://www.example.com/  301 →  https://example.com/

Os crawlers do Google "follow up to 10 redirect hops" (seguem até 10 saltos de redirect) (HTTP status codes and Google Search), então uma cadeia de dois saltos não faz a página se perder. Mas o guia de mudança de site do Google diz para "avoid chaining redirects" (evitar encadear redirects) e redirecionar "to the final destination directly" (diretamente para o destino final); se isso não for possível, mantenha as cadeias curtas, "ideally no more than 3 and fewer than 5" (idealmente no máximo 3 e menos de 5). Os visitantes pagam por cada salto de qualquer maneira.

Um loop é uma cadeia que nunca termina: A redireciona para B e B de volta para A, geralmente porque uma regra de HTTPS no servidor e outra na CDN entram em conflito. A MDN observa que os navegadores detectam loops e mostram um erro, então a página simplesmente fica inacessível.

Como configurar um redirect 301

Apache (.htaccess ou virtual host), unificando todas as versões em https://www.example.com:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Para uma única página, Redirect 301 /old-page https://www.example.com/new-page basta. Observe que um Redirect simples, sem código, envia um 302 por padrão, segundo a MDN.

Nginx, com um bloco server capturando todas as outras versões:

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate lines here for the 443 listener
    if ($host = example.com) { return 301 https://www.example.com$request_uri; }
    if ($scheme = http)      { return 301 https://www.example.com$request_uri; }
    # ... the site itself
}

Muitas configurações usam blocos server separados; qualquer uma funciona, desde que cada versão chegue ao endereço final em uma única etapa.

Next.js, em next.config.js:

module.exports = {
  async redirects() {
    return [
      { source: '/old-blog/:slug', destination: '/blog/:slug', permanent: true },
    ]
  },
}

A documentação do Next.js informa que permanent: true envia um 308 e permanent: false um 307, para preservar o método da requisição. O Google trata o 308 como permanente, então não há problema.

CDNs e hospedagens. A maioria das CDNs e dos painéis de hospedagem oferece regras de redirect e uma opção "sempre usar HTTPS". Use uma camada para cada função: se a CDN converte HTTP em HTTPS e o servidor de origem também redireciona hosts, você tem uma cadeia de dois saltos, ou um loop se as duas discordarem.

WordPress. O endereço do site em Configurações › Geral define o host canônico; o WordPress redireciona os outros hosts para ele. Para redirects de páginas, use um plugin de redirect ou o gerenciador de redirects do seu plugin de SEO, e prefira regras no servidor para unificar o host.

Como funciona o verificador de redirects da Searvia

O verificador de redirects usa o mesmo mecanismo do nosso verificador de SEO de sites: você informa um domínio e ele audita a página inicial e os arquivos ao redor com 38 verificações em cerca de 20 segundos, mostrando primeiro as três verificações que são o foco desta ferramenta. Veja o que elas fazem.

Redirects e versões duplicadas (prioridade média). O verificador pega o domínio informado, remove o www. e abre quatro endereços: http:// e https://, cada um com e sem www. Ele segue cada um por até seis redirects e registra onde termina e o código de status de cada salto. Uma versão passa se terminar no mesmo esquema e host do endereço final da sua página inicial usando apenas redirects permanentes (301 ou 308). O resultado:

• Falha se alguma versão terminar em outro lugar, por exemplo https://example.com respondendo com a própria página enquanto https://www.example.com é o seu site principal, ou se uma versão terminar em um loop de redirect ou precisar de mais de seis redirects.
• Alerta se alguma versão usar um redirect temporário (302, 303 ou 307), ou se o endereço informado precisar de mais de um salto, contado a partir de https:// mais o host informado, antes de responder.
• Aprovado se todas as versões chegarem ao mesmo site com redirects permanentes e o endereço principal precisar de um salto ou nenhum.

O relatório lista cada uma das quatro versões com a URL final, os códigos de redirect no caminho (por exemplo 301 › 301) e um check ou um X. Versões que não resolvem ou não podem ser acessadas, por exemplo um host www sem registro DNS, são deixadas de fora em vez de reprovar.

HTTPS (prioridade alta). Ele solicita http:// mais o seu host sem seguir redirects. Passa se o site funcionar em HTTPS e a requisição HTTP responder com um 3xx cujo Location comece com https://. Falha com "HTTP does not redirect to HTTPS" ou "The site does not work over HTTPS." Se o HTTP simples não responder, o redirect não pode ser testado, e a verificação mostra uma observação em vez de aprovação ou falha.

Status da página (prioridade alta). A página final deve responder com status 2xx. Um 4xx ou 5xx reprova.

O que ele não testa

• Meta refresh e redirects em JavaScript. Apenas redirects HTTP são seguidos. Uma versão que redireciona com uma meta tag aparece como terminando nela mesma.
• Páginas internas. Somente os endereços da página inicial são testados. Para redirects de páginas após uma migração, faça o crawl da lista de URLs antigas.
• Contagem de saltos por versão. O alerta de saltos conta apenas os saltos do seu endereço principal; uma cadeia permanente de dois saltos em http://www mostra os códigos na tabela (301 › 301), mas não reduz o resultado. Use curl para ver a URL de cada salto.

Para ver cada salto com sua URL e código:

curl -sIL http://www.example.com/ | grep -iE '^(HTTP|location)'

Como ler o resultado

A nota geral abrange as 38 verificações, ponderadas por prioridade (alta 10, média 5, baixa 2; um alerta vale metade), com uma lista "Fix these first" e um link de relatório compartilhável.

Como corrigir cada problema relatado pelo verificador

1. Algumas versões não redirecionam para a principal

1. Defina o endereço final: https://www.example.com ou https://example.com.
2. Na tabela do relatório, anote quais versões terminam na URL errada.
3. Adicione um 301 de cada uma delas direto para o endereço final, mantendo o caminho ($request_uri no Nginx, $1 no Apache).
4. Se a versão desviada terminar em um host totalmente diferente, verifique o DNS: um registro A antigo do www pode apontar para uma página de estacionamento ou para uma hospedagem anterior.
5. Confirme que as tags canonical, o sitemap e os links internos também usam o endereço final; um redirect que contradiz a canonical envia sinais conflitantes.
6. Execute novamente o verificador de redirects.

2. O endereço passa por vários redirects

1. Execute o comando curl -sIL no endereço informado e leia a cadeia.
2. Una as etapas: uma regra que envie toda versão não final direto para a URL final, como nos exemplos de Apache e Nginx acima.
3. Se a CDN e a origem redirecionam ambas, deixe que apenas uma faça isso. Normalmente a CDN cuida do HTTP para HTTPS e a origem não faz nada, ou a origem faz os dois e a CDN apenas repassa as requisições.
4. Atualize os links que você controla: o link do logotipo, a navegação, assinaturas de e-mail, perfis em redes sociais e destinos de anúncios devem apontar para o endereço final.

3. O HTTP não redireciona para HTTPS

1. Confirme que o HTTPS funciona, com um certificado válido que cubra tanto o domínio sem www quanto o www.
2. Adicione um redirect permanente de cada URL http:// para o equivalente https://, mantendo o caminho.
3. Quando tudo funcionar em HTTPS, considere o HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains), para que os navegadores pulem totalmente a requisição HTTP. O Google lista o HSTS como outra forma de reforçar o HTTPS como canônico. O verificador de security headers testa isso.

4. O site não funciona em HTTPS

Instale um certificado (o Let's Encrypt é gratuito e a maioria das hospedagens automatiza o processo), garanta que ele cubra todos os nomes de host que você usa e depois adicione o redirect de HTTP para HTTPS do passo 3. Conteúdo misto, ou seja, scripts ou imagens ainda carregados por http://, é a próxima coisa a limpar.

5. A página inicial não responde com 200

Um 5xx indica problema no servidor; verifique os logs de erro. Um 403 costuma significar que um firewall ou uma proteção contra bots está recusando requisições automatizadas, o que pode estar barrando também os crawlers dos buscadores. Um 404 na página inicial geralmente indica que um redirect leva os visitantes a um caminho que não existe mais. Corrija o destino e verifique de novo.

6. Redirects temporários, loops ou cadeias longas

1. Encontre a linha com um X e leia seus códigos. Um 302, 303 ou 307 entre versões de host deve virar 301 ou 308; verifique o servidor, a CDN e qualquer plugin, já que o temporário costuma ser um padrão (um Redirect simples no Apache envia 302).
2. Um loop geralmente significa que duas camadas discordam, como uma CDN que envia HTTPS para HTTP enquanto a origem envia HTTP para HTTPS. Desative uma delas.
3. Para uma cadeia com mais de seis saltos, substitua-a por uma única regra que vá direto ao endereço final, como no passo 2.

Redirects durante uma migração

Quando as URLs mudam, as regras no nível do host acima são só o começo. A orientação de mudança de site do Google acrescenta:

1. Mapeie cada URL antiga para a nova equivalente, usando sitemaps, logs do servidor, analytics e o seu CMS. Redirecionar tudo para a página inicial não é um mapeamento.
2. Redirecione diretamente para o destino final, nunca para uma URL que redirecione de novo.
3. Dê a cada nova URL uma canonical autorreferente, atualize os links internos e garanta que todos os sitemaps listem as novas URLs.
4. Mantenha os redirects pelo maior tempo possível, em geral pelo menos um ano.

Para sites internacionais, mais uma regra do Google: evite redirecionar automaticamente os visitantes entre versões de idioma com base na localização ou no idioma do navegador, porque "the Googlebot crawler usually originates from the USA" (o Googlebot normalmente se origina nos EUA) e pode nunca ver as outras versões (sites multirregionais). Nosso guia de hreflang cobre a alternativa.

Exemplo prático (hipotético)

O exemplo a seguir é hipotético, não são dados reais. A Bramble & Co, uma loja de móveis inventada, migrou para uma nova plataforma. O verificador de redirects relata:

O domínio sem www em https:// respondeu com o site completo em vez de redirecionar: a nova plataforma atendia os dois hosts, e só o servidor antigo tinha a regra de host. Os códigos também mostraram que http://bramble.example/ levava dois saltos e que o primeiro era um 302. A equipe adicionou uma única regra 301 na CDN para todas as versões não finais, removeu o redirect de HTTPS da própria plataforma para evitar uma cadeia e executou a verificação de novo: as quatro versões agora terminam em https://www.bramble.example/ em um único salto.

Checklist de redirects de 15 minutos

1. Execute o verificador de redirects gratuito no seu domínio.
2. Confirme que as quatro versões terminam em um único endereço.
3. Confira os códigos de cada versão no relatório (ou com curl -sIL): um salto, status 301 ou 308.
4. Verifique se as canonicals, o sitemap e os links internos usam o endereço final.
5. Garanta que o certificado cubra tanto o domínio sem www quanto o www.
6. Depois de uma migração, teste uma amostra de URLs antigas e mantenha os redirects por pelo menos um ano.

Como a Searvia ajuda

O verificador de redirects gratuito segue cada versão do seu endereço e verifica o HTTPS e o status da página inicial em um único relatório compartilhável. Em uma conta Searvia, a auditoria do site faz o crawl do site inteiro toda semana e sinaliza links internos que apontam para redirects, URLs redirecionadas ou quebradas no sitemap e páginas que retornam erros, para que você possa linkar direto para os endereços finais em todo lugar. O monitoramento de uptime verifica seu site 24 horas por dia e avisa quando ele sai do ar ou quando o certificado está prestes a expirar, que é quando os redirects de HTTPS mais costumam quebrar. Para a ordem completa das verificações técnicas, veja nosso guia de auditoria de SEO técnico.