SEO após migrar do WordPress para o 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 uma URL canônica diferente da indicada pelo usuário" e "Não encontrado (404) — validação falhou". Suas páginas de melhor desempenho podem estar passando por saltos desnecessários em redirecionamentos. E você pode estar mantendo dois sitemaps com conteúdo sobreposto 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 análise de tráfego (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 duplicados 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 sobre URLs canônicas 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 os saltos adicionais.
Compare com seus dados de análise de tráfego. 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 nos levou a fazer a verificação de redirecionamentos descrita acima.
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 passa 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 artigo 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://www.yourdomain.com/insights/$slug;
}
return 301 https://www.yourdomain.com/$slug;
}
# Multi-segment paths — just strip the slash
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$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á. Os demais caminhos no nível raiz recebem, pela mesma regra, um único redirecionamento que remove a barra; os caminhos com vários segmentos correspondem à segunda regra, a genérica. Após a implantação, 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ê está mantendo dois sitemaps que podem ficar fora de sincronia. 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 artigos 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. Você pode manter as duas, mas, se os e-mails duplicados atrapalharem, escolha uma. Se seus subdomínios são projetos separados, a propriedade de prefixo de URL é mais limpa — ela informa apenas sobre URLs sob aquele prefixo exato, como as do seu host www 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 artigos 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 implantar as 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 vigor imediatamente para novos rastreamentos. Alterações no sitemap são captadas em poucos dias. A confusão sobre URLs canônicas — 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 canônica por várias semanas.
A combinação de redirecionamentos limpos e um único sitemap de referência dá ao Google o sinal mais claro possível; uma propriedade consolidada no GSC facilita o acompanhamento dos relatórios restantes. No nosso caso, os avisos de “URL canônica duplicada” começaram a diminuir dentro de duas semanas após a implantação dessas correções.
Lidamos regularmente com esse tipo de migração como parte do nosso trabalho de desempenho e migração do WordPress. Se você está enfrentando problemas de SEO pós-migração, entre em contato.