Por que migrar de WordPress pra Astro?

Performance (Lighthouse 95+ contra 40-70 do WP médio), zero plugin pra atualizar, sem brecha de segurança em plugins desatualizados, hospedagem grátis na Vercel/Cloudflare e SEO técnico nativo. Trocou banco PHP+MySQL por arquivo estático servido via CDN.

Quanto tempo leva uma migração WordPress → Astro?

Site institucional pequeno: 1-2 semanas. Blog com 50-200 posts: 2-3 semanas. Site com e-commerce ou área logada: depende, geralmente não vale migrar (Astro é pra estático). Inclui exportar conteúdo, refazer design, redirects 301 e validação SEO.

WordPress é melhor que Astro pra blog?

Não. Astro com Content Collections é mais rápido, mais seguro e mais barato pra rodar. Cliente que quer editar texto sem dev pode usar Decap CMS ou Sanity como camada acima do Astro. Mantém vantagem de performance + UX de admin.

Como migrar posts do WordPress pra Astro?

Export XML do WP → script de conversão pra Markdown → importa em src/content/blog. Imagens migram via download em batch. Redirects 301 das URLs antigas pra novas via redirects.json na Vercel. Processo dura 2-4 dias dependendo do volume.

WordPress pra Astro: como migrar sem perder SEO

Por que migrar

WordPress funciona. Milhões de sites rodam nele e não precisam mudar. A migração faz sentido quando o site é basicamente conteúdo estático (institucional, LP, portfólio, blog) e a performance está sofrendo por causa da stack.

O caso típico: site com tema comprado, 8-12 plugins ativos, Lighthouse entre 50 e 70, LCP acima de 3 segundos. O dono do site paga R$ 50-100/mês de hospedagem compartilhada e gasta horas por mês atualizando plugins pra evitar vulnerabilidades. O site faz o que uma página HTML estática faria, mas com 10x mais complexidade.

No Family Pilates, era exatamente isso. WordPress com tema comprado, Lighthouse 65, LCP de 3.2 segundos. Depois da migração pra Astro com deploy na Vercel: Lighthouse 98, LCP 0.8s, hospedagem grátis, zero plugins pra manter.

A migração não é obrigatória. É uma decisão técnica que faz sentido quando performance, custo de manutenção e SEO técnico são prioridade. Se o site funciona bem em WordPress e o cliente está satisfeito, não tem motivo pra mexer.

Antes de começar: inventário do que existe

A migração que dá errado é a que começa pelo código sem mapear o que já existe. Antes de tocar em qualquer arquivo, faço um inventário completo:

URLs existentes. Liste todas as URLs do site atual. Cada uma precisa continuar funcionando ou ter redirect. URL que retorna 404 depois da migração é posição perdida no Google.

O jeito mais rápido: exporte o sitemap.xml do WordPress (geralmente em seusite.com/sitemap.xml). Se não tem sitemap, use o Screaming Frog (versão gratuita até 500 URLs) pra rastrear todas as páginas.

Meta tags atuais. Anote o title e description de cada página. Se estão bem configurados (keyword no title, description entre 120-160 chars), mantenha idênticos no Astro. Se estão genéricos, aproveite a migração pra otimizar.

Schema.org. Verifique se o site atual tem dados estruturados. A maioria dos sites WordPress não tem, ou tem o básico que o Yoast gera automaticamente. De qualquer forma, anote o que existe pra não perder.

Conteúdo. Textos, imagens, documentos. Copie tudo. Imagens precisam ser re-otimizadas de qualquer forma (WebP, dimensões corretas), então é uma boa hora pra fazer isso.

Funcionalidades. O que o site faz além de mostrar conteúdo? Formulário de contato? Agendamento? Blog com comentários? Cada funcionalidade precisa de equivalente no Astro ou de uma decisão consciente de remover.

Estrutura de URLs: não mude se não precisar

A regra mais importante da migração: mantenha as mesmas URLs. Se a página de serviços era seusite.com/servicos, ela continua sendo seusite.com/servicos no Astro.

No Astro, a estrutura de pastas dentro de src/pages/ define as URLs:

src/pages/
  index.astro          → seusite.com/
  servicos.astro       → seusite.com/servicos/
  sobre.astro          → seusite.com/sobre/
  contato.astro        → seusite.com/contato/
  blog/
    [slug].astro       → seusite.com/blog/nome-do-post/

Se o WordPress usava estrutura diferente (ex: seusite.com/?p=123 ou seusite.com/2024/01/nome-do-post), você precisa de redirects.

Redirects: o que salva seu SEO

Toda URL antiga que muda precisa de redirect 301 (permanente). O redirect diz pro Google: “essa página mudou de endereço, transfira a autoridade pra URL nova.”

Na Vercel, configure no vercel.json:

{
  "redirects": [
    { "source": "/2024/01/nome-do-post", "destination": "/blog/nome-do-post", "permanent": true },
    { "source": "/?p=123", "destination": "/servicos", "permanent": true }
  ]
}

No Netlify, use o arquivo _redirects:

/2024/01/nome-do-post  /blog/nome-do-post  301
/?p=123  /servicos  301

Não pule esse passo. URL sem redirect retorna 404. O Google indexa o 404, remove a página antiga do índice, e você perde a autoridade acumulada. Dependendo do volume de tráfego orgânico, o impacto pode ser grande.

Depois de configurar os redirects, teste todos. Abra cada URL antiga no navegador e confirme que redireciona pra URL nova. Ferramentas como o Screaming Frog fazem isso automaticamente pra listas grandes.

Migrando o conteúdo

Textos

Copie o conteúdo do WordPress e converta pra Markdown ou diretamente pra componentes Astro. Se o site tem blog, Astro trabalha nativamente com arquivos .md na pasta src/content/.

Pra páginas institucionais (home, sobre, serviços), o conteúdo vai direto nos arquivos .astro. Sem banco de dados, sem CMS, sem painel admin. O texto fica no código. Pra sites pequenos (5-15 páginas), isso é vantagem: menos complexidade, menos pontos de falha.

Se o cliente precisa editar conteúdo sem mexer em código, considere um headless CMS (Decap, Tina, Contentful). Mas na minha experiência, a maioria dos sites institucionais não precisa de edição frequente. O cliente muda o site 2-3 vezes por ano. Pra isso, uma entrega pontual resolve melhor que um CMS.

Imagens

Não copie as imagens no formato original. Essa é a hora de otimizar tudo:

Converta pra WebP (squoosh.app ou bulk converter)
Redimensione pra 2x a resolução de exibição (imagem de 800px no layout vira 1600px)
Use o componente <Image> do Astro que otimiza automaticamente no build
Adicione alt text descritivo (80-125 caracteres, com keyword quando natural)

No WordPress, imagens geralmente estão em /wp-content/uploads/. Baixe todas, otimize e coloque em src/assets/ ou public/images/ no projeto Astro.

Detalhei o processo completo de otimização de imagens no post sobre por que seu site carrega lento.

Formulários

WordPress usa Contact Form 7, Gravity Forms ou WPForms. No Astro, formulários estáticos podem enviar pra serviços como Formspree, Netlify Forms ou um endpoint customizado.

Pra clínicas e negócios locais, geralmente substituo o formulário por botão de WhatsApp direto. A taxa de conversão é maior e o atendimento é mais rápido. Se o formulário é essencial (ex: captação de lead com email), Formspree integra em 5 minutos.

SEO técnico: o que configurar no Astro

Meta tags

No Astro, meta tags ficam no <head> do layout principal. Crie um componente SEO.astro reutilizável:

---
const { title, description, image, url } = Astro.props;
---
<title>{title} | Nome da Empresa</title>
<meta name="description" content={description} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:image" content={image} />
<meta property="og:url" content={url} />
<link rel="canonical" href={url} />

Cada página passa seus próprios valores. Sem plugin, sem configuração complexa. Uma função que faz o trabalho que no WordPress precisa do Yoast ou RankMath.

Schema.org

JSON-LD direto no <head>. Sem plugin. O Schema que recomendo pra cada tipo de página:

Home: Organization ou LocalBusiness
Blog: BlogPosting com author, datePublished, dateModified
FAQ: FAQPage
Navegação: BreadcrumbList

Implementar cada um leva minutos. O impacto em rich snippets pode ser grande. Detalhei a implementação completa no post sobre SEO técnico pra devs.

Sitemap

Instale @astrojs/sitemap e configure no astro.config.mjs:

import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://seusite.com',
  integrations: [sitemap()],
});

O sitemap é gerado automaticamente no build. Registre no Google Search Console depois do deploy.

Fontes: pare de depender do Google Fonts

WordPress carrega Google Fonts com requisição externa. Isso adiciona latência e bloqueia renderização do texto.

No Astro, faça self-hosting:

Baixe as fontes em woff2
Coloque em public/fonts/
Declare com @font-face no CSS global
Use font-display: swap e preload no <head>

Esse processo é o padrão em todos os meus projetos. No Family Pilates uso Fraunces e Satoshi self-hosted. Na Soline, fontes customizadas servidas do mesmo servidor. Zero requisição externa pra tipografia.

Deploy e DNS

Com o site Astro pronto, o deploy na Vercel leva 5 minutos:

Push o código pro GitHub
Conecte o repositório na Vercel
A Vercel detecta Astro automaticamente e faz o build
Configure o domínio customizado no painel da Vercel
Aponte o DNS do domínio pra Vercel (registro CNAME ou A)

O HTTPS é automático. O CDN global é automático. Não tem servidor pra configurar, não tem certificado pra renovar.

A hospedagem que custava R$ 50-100/mês no WordPress agora custa R$ 0 na Vercel (plano gratuito). O site carrega mais rápido, é mais seguro (não tem painel admin exposto) e não precisa de manutenção de plugins.

Depois do deploy: validação

Nos primeiros 7 dias após a migração, monitore:

Google Search Console: erros de rastreamento, páginas não indexadas, 404s
Teste todos os redirects manualmente
Compare Lighthouse antes e depois (screenshot do WordPress vs Astro)
Verifique se o sitemap novo foi aceito pelo Google
Monitore tráfego orgânico (queda temporária de 5-10% é normal nas primeiras 2 semanas)

Queda temporária no tráfego orgânico acontece em toda migração. O Google precisa rastrear as páginas novas, processar os redirects e recalcular posições. Em 2-4 semanas, o tráfego volta ao normal. Se os redirects estão corretos e as meta tags estão mantidas, geralmente volta acima do que era antes por causa da melhoria em performance.

No GPM2 e no Tok Final, ambos construídos em Astro desde o início, o Lighthouse bate 95+ e o SEO técnico vem configurado de fábrica. Pra sites migrados de WordPress, o salto de performance é ainda mais visível.