Corrigindo SEO Após uma Migração do WordPress para Astro: Cadeias de Redirecionamento, Sitemaps e Limpeza no GSC
Depois de migrar do WordPress para o Astro, seu site fica mais rápido para compilar, mais rápido para carregar e mais barato de hospedar. Mas se as URLs do blog mudaram durante a migração — por exemplo, de /post-slug/ para /insights/post-slug — você provavelmente tem problemas de SEO que só aparecem semanas depois, quando o Google termina de rastrear o site novamente.
O Google Search Console vai começar a enviar e-mails sobre "Duplicado, o Google escolheu um canonical diferente do indicado pelo usuário" e "Não encontrado (404) — validação falhou". Suas páginas de melhor desempenho podem estar perdendo autoridade de links por causa de saltos desnecessários em redirecionamentos. E você pode ter dois sitemaps competindo entre si sem nem perceber.
Este guia mostra como encontrar e corrigir esses problemas. Passamos por todos eles na nossa própria limpeza de SEO pós-migração do WordPress para o Astro e documentamos as soluções aqui.
O Que Você Vai Precisar
- Acesso SSH ao seu servidor (configuração do nginx)
- Acesso ao Google Search Console para sua propriedade
curlinstalado localmente- Ferramenta de analytics (usamos o Plausible auto-hospedado)
O Que Isso Resolve
- Cadeias de redirecionamento com múltiplos saltos (2 ou mais) reduzidas a um único 301
- Sitemaps conflitantes consolidados em uma única fonte gerada automaticamente
- Páginas com noindex removidas do sitemap
- Propriedades desatualizadas no GSC e sitemaps legados do WordPress eliminados
- Confusão de canonical entre estruturas de URL antigas e novas resolvida
Passo 1: Diagnosticar Cadeias de Redirecionamento
Verifique quantos redirecionamentos suas principais URLs percorrem. Se as URLs do WordPress tinham barra no final e as do Astro não têm, você provavelmente tem uma cadeia de dois saltos: um redirecionamento remove a barra e outro adiciona o novo prefixo de caminho.
curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\n" \
-o /dev/null "https://yourdomain.com/old-post-slug/"
Se a saída mostrar Hops: 2, você tem uma cadeia de redirecionamento. Execute isso para suas cinco páginas com mais tráfego — são elas que mais sofrem com a perda de autoridade de links.
Compare com seus dados de analytics. Se você vir o mesmo artigo aparecendo em múltiplas variantes de URL (com barra, sem barra, com novo prefixo), seus redirecionamentos não estão consolidando o tráfego. Nós vimos nosso artigo mais acessado dividido em três variantes de URL no Plausible, o que confirmou o problema de cadeia.
Passo 2: Corrigir o nginx para Redirecionamentos de Salto Único
A regra padrão do nginx para remover a barra final tem esta aparência:
location ~ ^(.+)/$ { return 301 $1; }
Ela remove a barra final, mas não sabe nada sobre a mudança de caminho do seu blog. A requisição então cai em uma segunda regra que redireciona /slug para /insights/slug. Dois saltos.
Substitua por uma regra que leva o blog em conta — ela verifica se o slug corresponde a um post e redireciona diretamente para a URL final:
# Blog slugs with trailing slash — single-hop to /insights/
location ~ ^/([^/]+)/$ {
set $slug $1;
if (-f /usr/share/nginx/html/insights/$slug/index.html) {
return 301 https://yourdomain.com/insights/$slug;
}
return 301 https://yourdomain.com/$slug;
}
# Multi-segment paths — just strip the slash
location ~ ^(.+)/$ { return 301 $1; }
A primeira regra trata os slugs no nível raiz (as antigas URLs do WordPress). Ela verifica se existe uma página correspondente em /insights/ e redireciona diretamente para lá. Caminhos que não são do blog caem na remoção genérica de barra. Após o deploy, verifique:
curl -sL -w "Hops: %{num_redirects}\n" -o /dev/null \
"https://yourdomain.com/your-top-post-slug/"
# Expected: Hops: 1
Passo 3: Consolidar os Sitemaps
Verifique se você tem mais de um sitemap. Um padrão comum após a migração: um sitemap.xml estático criado manualmente durante a transição, mais um sitemap-index.xml gerado automaticamente pela integração @astrojs/sitemap do Astro.
# Check both curl -sI "https://yourdomain.com/sitemap.xml" | head -1 curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
Se ambos retornarem 200, você tem sitemaps em conflito. Verifique qual deles o robots.txt referencia:
curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap
A solução: exclua o sitemap.xml estático do seu diretório public/, atualize o robots.txt para referenciar o sitemap-index.xml e deixe a integração do Astro cuidar de tudo. Novos posts aparecerão automaticamente a cada build.
Verifique também se o sitemap estático lista páginas com noindex. Se o seu sitemap.xml inclui páginas como /legal ou /privacy-policy que têm <meta name="robots" content="noindex">, você está enviando sinais contraditórios ao Google. O sitemap gerado automaticamente pelo @astrojs/sitemap pode ser configurado com regras de filtro para excluir essas páginas corretamente.
Passo 4: Limpar o Google Search Console
Abra o GSC e verifique duas coisas: propriedades e sitemaps.
Propriedades: Se você tiver tanto uma propriedade de domínio (sc-domain:yourdomain.com) quanto uma propriedade de prefixo de URL (https://www.yourdomain.com/), estará recebendo alertas duplicados para os mesmos problemas. Escolha um. Se seus subdomínios são projetos separados, a propriedade de prefixo de URL é mais limpa — ela reporta apenas o tráfego de produção.
Sitemaps: Vá em Indexação → Sitemaps. Remova qualquer sitemap antigo do WordPress ainda registrado lá (post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml etc.). Envie o novo sitemap-index.xml como o único sitemap.
Validação de 404: Vá em Indexação → Páginas → "Não encontrado (404)" e veja quais URLs estão listadas. Se forem caminhos antigos do WordPress que não existem mais e não deveriam existir (páginas de produtos do WooCommerce, páginas de autor, URLs de feed), elas serão desindexadas com o tempo. Se forem posts do blog que deveriam redirecionar, suas regras no nginx precisam ser atualizadas. Depois de corrigir os redirecionamentos, clique em "Validar correção" para acionar um novo rastreamento.
Passo 5: Verificar Tudo
Execute estas verificações após fazer o deploy das correções:
# 1. Redirect chains resolved
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\n" \
-o /dev/null "https://yourdomain.com/your-top-post/"
# Expected: Hops: 1, URL ends in /insights/your-top-post
# 2. robots.txt points to generated sitemap
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Expected: sitemap-index.xml
# 3. Old static sitemap returns 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Expected: 404
# 4. Generated sitemap returns 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Expected: 200
# 5. Non-www redirects to www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" \
"https://yourdomain.com/insights"
# Expected: 301 https://www.yourdomain.com/insights
Quanto Tempo Leva para o Google se Atualizar
Redirecionamentos de salto único entram em efeito imediatamente para novos rastreamentos. Alterações no sitemap são captadas em poucos dias. A confusão de canonical — em que o Google prefere a URL antiga em vez da nova — demora mais para se resolver. O Google trata a tag <link rel="canonical"> como uma sugestão, não uma diretriz. Se a URL antiga tem mais backlinks e histórico de cliques, o Google pode continuar escolhendo-a como canonical por várias semanas.
A combinação de redirecionamentos limpos, um único sitemap autoritativo e uma propriedade consolidada no GSC dá ao Google o sinal mais claro possível. No nosso caso, os avisos de "Canonical duplicado" começaram a diminuir dentro de duas semanas após o deploy dessas correções.
Lidamos regularmente com esse tipo de migração como parte do nosso trabalho de performance e migração do WordPress. Se você está enfrentando problemas de SEO pós-migração, entre em contato.