Astro é o melhor substituto para WordPress em 2026 para sites com muito conteúdo -- blog, docs, páginas de marketing -- porque envia zero JavaScript por padrão e supera WordPress nos Core Web Vitals em 60-80 pontos. Migrei uma dúzia de sites WordPress para Astro nos últimos dois anos, variando de blogs pessoais com 50 posts a portais de documentação com 3.000 páginas, e os resultados são consistentemente dramáticos: tempos de carregamento sub-segundo, scores Lighthouse acima de 95, e contas de hospedagem que caem de $99/mês para literalmente zero.

Este não é um guia "apenas exporte XML e reze". Vou guiá-lo através do processo exato que uso, incluindo as armadilhas que o morderão se você não planejar -- URLs quebrados, imagens faltantes, shortcodes órfãos, e a questão do sistema de comentários que confunde todos.

Índice

Por que Astro em vez de WordPress

WordPress é superengenheirado para a maioria dos sites de conteúdo. Você está executando PHP, MySQL, um servidor web, uma camada de cache, e provavelmente uma dúzia de plugins apenas para servir o que é fundamentalmente conteúdo estático. Cada carregamento de página acessa um banco de dados. Cada plugin é um possível buraco de segurança. Cada atualização é uma oração para que nada quebre.

Astro inverte esse modelo. Ele pré-renderiza suas páginas para HTML estático no tempo de build. Sem banco de dados. Sem runtime do lado do servidor. Sem PHP. A saída é HTML simples, CSS e -- apenas quando você opta explicitamente -- JavaScript.

Aqui está o que vejo consistentemente entre migrações:

Métrica WordPress (Gerenciado) Astro (Estático) Melhoria
Desempenho Lighthouse 34-55 95-100 +60-80 pts
First Contentful Paint 2.8-4.2s 0.4-0.8s ~80% mais rápido
Total Blocking Time 200-800ms 0-10ms ~98% redução
Tamanho da Página (post típico) 1.5-3.5 MB 80-250 KB ~90% menor
Time to Interactive 4-8s 0.5-1.0s ~85% mais rápido
Requisições HTTP 60-130 8-15 ~85% menos

Estes não são cherry-picked. São médias de migrações reais. Sites WordPress com plugins de cache e CDNs ainda não conseguem se aproximar de um build Astro estático porque estão fundamentalmente fazendo mais trabalho por requisição.

O Aspecto de Segurança

WordPress é o CMS mais atacado da internet. Não porque seja ruim, mas porque é onipresente e possui uma grande superfície de ataque -- execução PHP, acesso a banco de dados, upload de arquivos, XML-RPC, endpoints da REST API, páginas de login de administrador. A cada mês surgem novas vulnerabilidades de plugins.

Sites Astro implantados em um CDN têm essencialmente zero superfície de ataque. Não há servidor para explorar, nenhum painel de administração para força bruta, nenhum banco de dados para injeção. Seu site é uma pasta de arquivos HTML sentada em uma rede de borda global.

A Experiência do Desenvolvedor

Se você já tentou personalizar um tema WordPress, conhece a dor: tags de template PHP misturadas com HTML, a hierarquia de templates que requer memorização, arquivos functions.php que crescem em monstros inmanteníveis, conflitos constantes de plugins.

Astro usa uma arquitetura baseada em componentes com um formato de arquivo que parece HTML com superpotências. Você pode usar componentes React, Vue, Svelte ou Solid dentro de páginas Astro -- mas apenas quando realmente precisa de interatividade. Para um blog ou site de marketing, você provavelmente não precisa.

---
// src/pages/blog/[...slug].astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
const { Content } = await post.render();
---

<BlogLayout title={post.data.title} description={post.data.excerpt}>
  <article>
    <h1>{post.data.title}</h1>
    <time datetime={post.data.date.toISOString()}>
      {post.data.date.toLocaleDateString()}
    </time>
    <Content />
  </article>
</BlogLayout>

Essa é uma página de post de blog dinamicamente completa. Tente fazer isso no WordPress com a mesma clareza.

Astro vs Next.js vs Gatsby para Migração WordPress

Astro

Astro foi construído especificamente para sites de conteúdo. Sua "arquitetura de ilhas" significa que você envia zero JS a menos que um componente específico precise. Content collections oferecem manipulação de markdown type-safe com validação de esquema integrada. Tempos de build são rápidos, o modelo mental é simples, e você não precisa entender React para usá-lo. Para blogs, docs e sites de marketing, é a escolha óbvia em 2026. Se você está explorando essa rota, nosso time de desenvolvimento Astro tratou migrações em cada escala.

Next.js

Next.js é um framework de aplicação completa. Ele manipula autenticação, server-side rendering, rotas de API, middleware e centenas de outras coisas que você não precisa para um blog. Você enviará o runtime React para cada visitante, quer ele precise de interatividade ou não (os server components do App Router ajudam, mas a linha de base do bundle ainda é mais pesada). Next.js faz sentido quando você está construindo um produto SaaS ou um site com funcionalidade dinâmica pesada -- painéis de usuário, e-commerce, recursos em tempo real. Para uma migração de conteúdo do WordPress? É excessivo. Dito isto, se seu site realmente precisa desses recursos, nosso time de Next.js pode ajudá-lo a descobrir a arquitetura correta.

Gatsby

Gatsby está efetivamente em modo de manutenção. A Netlify a adquiriu em 2023, e o desenvolvimento desacelerou para um ritmo de caracol. A camada de dados GraphQL que uma vez pareceu inteligente agora se sente como complexidade desnecessária. Tempos de build para sites grandes são dolorosos. O ecossistema de plugins está obsoleto. Eu recomendaria fortemente contra iniciar um novo projeto Gatsby em 2026. Se você está atualmente no Gatsby, migrar para Astro é na verdade mais fácil do que migrar do WordPress porque seu conteúdo provavelmente já está em markdown.

Recurso Astro Next.js Gatsby
JS padrão enviado 0 KB ~85-100 KB ~70-90 KB
Content collections Integrado, type-safe Configuração manual Camada GraphQL
Tempo de build (1000 posts) ~30-45s ~60-90s ~120-300s
Curva de aprendizado Baixa Média-Alta Média
Melhor para Sites de conteúdo Aplicações web Projetos legados
Desenvolvimento ativo Muito ativo Muito ativo Mínimo
Suporte SSR Opcional Padrão Limitado

Guia de Migração em 7 Passos

Aqui está o processo exato que sigo. Sem enrolação.

Passo 1: Audite Seu Site WordPress

Antes de tocar em qualquer código, você precisa saber com o que está lidando. Faça login no seu administrador WordPress e faça um inventário.

# Se você tiver WP-CLI instalado (você deveria)
wp post list --post_type=post --format=csv --fields=ID,post_title,post_name,post_date > posts.csv
wp post list --post_type=page --format=csv --fields=ID,post_title,post_name,post_date > pages.csv
wp plugin list --format=table
wp theme list --format=table

Documente cada plugin e o que faz. Você precisará encontrar equivalentes do Astro ou removê-los. Os comuns:

  • Yoast SEO → Gerenciamento integrado <head> do Astro + @astrojs/sitemap
  • Contact Form 7 → Formspree, Formspark, ou uma função serverless
  • WP Super Cache / W3 Total Cache → Não é necessário (seu site já é estático)
  • Wordfence / Sucuri → Não é necessário (sem servidor para proteger)
  • Plugin do Google Analytics → Tag de script direto ou integração Partytown
  • WooCommerce → Snipcart, Shopify Buy Button, ou uma plataforma de e-commerce dedicada

Passo 2: Exporte o Conteúdo do WordPress

Você tem duas opções: exportação XML ou REST API. Recomendo a exportação XML para a maioria dos sites porque captura tudo de uma vez.

No admin WordPress: Ferramentas → Exportar → Todos os Conteúdos → Baixar Arquivo de Exportação

Isto lhe dá um arquivo .xml contendo cada post, página, comentário, campo personalizado, categoria, tag e referência de mídia.

Para sites maiores (1000+ posts), a abordagem da REST API é mais confiável:

// scripts/export-wp.mjs
import fs from 'fs/promises';
import path from 'path';

const WP_URL = 'https://your-wordpress-site.com/wp-json/wp/v2';
const PER_PAGE = 100;

async function fetchAllPosts() {
  let page = 1;
  let allPosts = [];
  
  while (true) {
    const res = await fetch(
      `${WP_URL}/posts?per_page=${PER_PAGE}&page=${page}&_embed`
    );
    
    if (!res.ok) break;
    
    const posts = await res.json();
    if (posts.length === 0) break;
    
    allPosts = allPosts.concat(posts);
    console.log(`Fetched page ${page} (${allPosts.length} posts total)`);
    page++;
  }
  
  return allPosts;
}

const posts = await fetchAllPosts();
await fs.writeFile('wp-posts.json', JSON.stringify(posts, null, 2));
console.log(`Exported ${posts.length} posts`);

Passo 3: Estruture Seu Projeto Astro

npm create astro@latest my-new-site
cd my-new-site

# Adicione as integrações que você precisará
npx astro add mdx
npx astro add sitemap
npx astro add tailwind

# Instale dependências adicionais
npm install sharp @astrojs/rss

Recomendo começar com uma configuração mínima em vez de um tema. Temas adicionam complexidade que você não precisa durante a migração. Primeiro faça o conteúdo funcionar, depois estilize.

Passo 4: Converta o Conteúdo para Markdown

É aqui que o trabalho real acontece. Você precisa converter conteúdo HTML do WordPress em markdown limpo com frontmatter apropriado.

Eu uso um script Node.js personalizado com turndown para conversão de HTML para markdown:

npm install turndown @wordpress/block-serialization-default-parser

// scripts/convert-posts.mjs
import TurndownService from 'turndown';
import fs from 'fs/promises';
import path from 'path';

const turndown = new TurndownService({
  headingStyle: 'atx',
  codeBlockStyle: 'fenced',
});

// Lidar com HTML específico do WordPress
turndown.addRule('wpCaption', {
  filter: (node) => {
    return node.nodeName === 'DIV' && 
           node.className.includes('wp-caption');
  },
  replacement: (content, node) => {
    const img = node.querySelector('img');
    const caption = node.querySelector('.wp-caption-text');
    return `![${caption?.textContent || ''}](${img?.src || ''})\n`;
  },
});

const posts = JSON.parse(await fs.readFile('wp-posts.json', 'utf-8'));

for (const post of posts) {
  const slug = post.slug;
  const markdown = turndown.turndown(post.content.rendered);
  
  const frontmatter = `---
title: "${post.title.rendered.replace(/"/g, '\\"')}"
date: ${post.date}
excerpt: "${(post.excerpt.rendered || '').replace(/<[^>]*>/g, '').trim().replace(/"/g, '\\"')}"
categories: [${(post._embedded?.['wp:term']?.[0] || []).map(c => `"${c.name}"`).join(', ')}]
tags: [${(post._embedded?.['wp:term']?.[1] || []).map(t => `"${t.name}"`).join(', ')}]
featuredImage: "${post._embedded?.['wp:featuredmedia']?.[0]?.source_url || ''}"
draft: false
---`;

  const content = `${frontmatter}\n\n${markdown}\n`;
  
  await fs.mkdir('src/content/blog', { recursive: true });
  await fs.writeFile(`src/content/blog/${slug}.md`, content);
  console.log(`Converted: ${slug}`);
}

Passo 5: Baixe e Organize a Mídia

WordPress armazena mídia em diretórios wp-content/uploads/YYYY/MM/. Você precisa baixar tudo e atualizar referências.

# Rápido e sujo: wget mirror do seu diretório uploads
wget -r -np -nH --cut-dirs=2 -P public/uploads \
  https://your-wordpress-site.com/wp-content/uploads/

# Então find-and-replace URLs antigas em seus arquivos markdown
find src/content/blog -name '*.md' -exec sed -i '' \
  's|https://your-wordpress-site.com/wp-content/uploads/|/uploads/|g' {} +

Para migrações em produção, uso otimização de imagem do Astro com a biblioteca sharp para converter tudo para WebP e gerar tamanhos responsivos no tempo de build. Isso sozinho pode reduzir o payload de imagem em 40-60%.

Passo 6: Construa Layouts e Componentes

Crie seus layouts Astro para corresponder (ou melhorar) a estrutura do tema WordPress. No mínimo você precisará de:

  • src/layouts/BaseLayout.astro -- shell HTML, <head>, nav, footer
  • src/layouts/BlogLayout.astro -- template de post único
  • src/pages/blog/index.astro -- listagem de blog com paginação
  • src/pages/blog/[...slug].astro -- páginas de post dinâmicas
  • src/pages/index.astro -- página inicial

Passo 7: Teste, Redirecione, Implante

Construa localmente e verifique tudo:

npm run build
npm run preview

# Verifique links quebrados
npx linkinator http://localhost:4321 --recurse

Configure redirecionamentos (coberto em detalhe abaixo), configure seu DNS e implante. Vou cobrir opções de hospedagem na seção de comparação de custos.

Exportação de Dados WordPress para Content Collections do Astro

As content collections do Astro são um de seus melhores recursos. Elas oferecem acesso type-safe ao seu conteúdo markdown com validação de esquema. Aqui está como configurá-las adequadamente para conteúdo WordPress migrado.

Definindo Seu Esquema

// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    date: z.coerce.date(),
    excerpt: z.string().optional(),
    categories: z.array(z.string()).default([]),
    tags: z.array(z.string()).default([]),
    featuredImage: z.string().optional(),
    draft: z.boolean().default(false),
  }),
});

export const collections = { blog };

A beleza disto: se qualquer um dos seus posts migrados tiver frontmatter faltando ou malformado, Astro lhe dirá no tempo de build com uma mensagem de erro clara. Sem mais falhas silenciosas.

Tratando Shortcodes do WordPress

Esta é a armadilha que a maioria dos guias de migração pula. Se seus posts WordPress usarem shortcodes como [gallery], [caption], [embed], ou qualquer shortcode personalizado de plugins, eles aparecerão como texto bruto em seu markdown.

Você tem três opções:

  1. Pré-processar durante a conversão -- Escreva regras regex em seu script de conversão para transformar shortcodes em equivalentes markdown ou HTML
  2. Use MDX -- Converta posts afetados para .mdx e crie componentes Astro que substituam shortcodes
  3. Encontre e substitua manualmente -- Para sites pequenos, às vezes é a abordagem mais rápida
// Exemplo: convertendo shortcode de galeria WordPress durante conversão
function convertShortcodes(content) {
  // [gallery ids="1,2,3"]
  content = content.replace(
    /\[gallery ids="([^"]+)"\]/g,
    (match, ids) => {
      const imageIds = ids.split(',');
      return imageIds.map(id => `![](/uploads/gallery/${id.trim()}.jpg)`).join('\n');
    }
  );
  
  // [youtube url="..."]
  content = content.replace(
    /\[youtube[^\]]*url="([^"]+)"[^\]]*\]/g,
    (match, url) => `<iframe src="${url}" width="560" height="315" frameborder="0"></iframe>`
  );
  
  return content;
}

Consultando Conteúdo

Uma vez que seu conteúdo está em collections, consultá-lo é direto:

---
// src/pages/blog/index.astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

const posts = (await getCollection('blog'))
  .filter(post => !post.data.draft)
  .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
---

<BlogLayout title="Blog">
  <ul>
    {posts.map(post => (
      <li>
        <a href={`/blog/${post.slug}/`}>
          <h2>{post.data.title}</h2>
          <time>{post.data.date.toLocaleDateString()}</time>
          <p>{post.data.excerpt}</p>
        </a>
      </li>
    ))}
  </ul>
</BlogLayout>

Preservando SEO: Redirecionamentos 301, Sitemap e Schema

Esta seção é crítica. Uma migração mal executada pode destruir anos de equidade de SEO da noite para o dia. Não pule nada disto.

Estrutura de URL e Redirecionamentos 301

WordPress padroniza URLs como /2024/03/my-post-title/ ou /?p=123. Você precisa mapear cada URL antiga para seu equivalente Astro novo.

Primeiro, gere uma lista completa de URLs antigas:

# Usando WP-CLI
wp post list --post_type=post,page --field=url > old-urls.txt

# Ou rastreie o sitemap
curl -s https://your-site.com/sitemap.xml | grep -oP '<loc>\K[^<]+'

Para Vercel, crie um vercel.json na raiz do seu projeto:

{
  "redirects": [
    { "source": "/2024/03/my-old-post/", "destination": "/blog/my-old-post/", "permanent": true },
    { "source": "/:year(\\d{4})/:month(\\d{2})/:slug/", "destination": "/blog/:slug/", "permanent": true },
    { "source": "/category/:slug/", "destination": "/blog/category/:slug/", "permanent": true },
    { "source": "/feed/", "destination": "/rss.xml", "permanent": true }
  ]
}

Para Netlify, use _redirects na sua pasta public/:

/2024/03/my-old-post/  /blog/my-old-post/  301
/category/*            /blog/category/:splat  301
/feed/                 /rss.xml  301

Para Cloudflare Pages, use _redirects (mesmo formato que Netlify) ou Bulk Redirects no painel.

Geração de Sitemap

A integração @astrojs/sitemap manipula isto automaticamente:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

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

Após implantar, envie seu novo sitemap no Google Search Console imediatamente. Também envie uma solicitação de remoção para qualquer URLs que não existem mais e não são redirecionadas.

Dados Estruturados / Markup de Schema

Se Yoast estava manipulando seu markup de schema, você precisa replicá-lo. Crie um componente reutilizável:

---
// src/components/ArticleSchema.astro
const { title, date, excerpt, image, author = 'Your Name' } = Astro.props;

const schema = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": title,
  "datePublished": date,
  "description": excerpt,
  "image": image,
  "author": {
    "@type": "Person",
    "name": author
  }
};
---

<script type="application/ld+json" set:html={JSON.stringify(schema)} />

Feed RSS

Não se esqueça de seus assinantes RSS:

// src/pages/rss.xml.js
import rss from '@astrojs/rss';
import { getCollection } from 'astro:content';

export async function GET(context) {
  const posts = await getCollection('blog');
  return rss({
    title: 'Your Site',
    description: 'Your description',
    site: context.site,
    items: posts.map(post => ({
      title: post.data.title,
      pubDate: post.data.date,
      description: post.data.excerpt,
      link: `/blog/${post.slug}/`,
    })),
  });
}

Comparação de Custos de Hospedagem

É aqui que o caso de negócio para migração se torna impossível de ignorar.

Cenário de Hospedagem Custo Mensal Custo Anual Notas
WP Engine (WordPress Gerenciado) $30-60 $360-720 Planos Startup-Growth
Kinsta (WordPress Gerenciado) $35-70 $420-840 Planos Starter-Business
Flywheel (WordPress Gerenciado) $15-30 $180-360 Planos Tiny-Personal
Auto-hospedado (DigitalOcean + manutenção) $12-24 $144-288 Mais seu tempo para atualizações
Astro em Vercel (Hobby) $0 $0 100GB largura de banda/mês
Astro em Netlify (Gratuito) $0 $0 100GB largura de banda/mês
Astro em Cloudflare Pages (Gratuito) $0 $0 Largura de banda ilimitada
Astro em Vercel (Pro) $20 $240 1TB largura de banda, recursos de equipe

Para a grande maioria dos sites de conteúdo -- blogs, portfólios, sites de documentação, sites de marketing -- os níveis gratuitos em Vercel, Netlify ou Cloudflare Pages são mais que suficientes. Você está servindo arquivos estáticos de um CDN global. Um site recebendo 100.000 visualizações de página por mês mal arranharão os limites de camada gratuita.

Deixe-me esclarecer a matemática. Se você está pagando $50/mês por hospedagem WordPress gerenciada, são $600/ano. Ao longo de três anos, são $1.800. Adicione licenças de plugin premium (Yoast Premium em $99/ano, Elementor Pro em $59/ano, WP Rocket em $59/ano), e você está olhando para $800-$1.000 anualmente para um site de conteúdo que poderia ser hospedado gratuitamente.

A migração em si é um custo único. Se você cuidar disso, é seu tempo. Se você contratar um time como o nosso através de nossos serviços de desenvolvimento de CMS headless, o ROI normalmente se equilibra em 6-12 meses apenas a partir das economias de hospedagem -- sem contar as melhorias de desempenho e SEO. Veja nossa página de preços para detalhes específicos.

Mas e quanto aos Recursos Dinâmicos?

A objeção mais comum: "Meu site WordPress tem formulários de contato, pesquisa, comentários e e-commerce."

  • Formulários de contato: Formspree (camada gratuita: 50 submissões/mês), Formspark, ou uma função serverless simples
  • Pesquisa: Pagefind (gratuito, executa inteiramente no cliente, construído para sites estáticos) -- é incrível
  • Comentários: Giscus (gratuito, apoiado por GitHub), ou Disqus se precisar
  • E-commerce: Snipcart, Shopify Lite, ou Stripe Checkout
  • Inscrições em newsletter: Chamadas diretas de API para ConvertKit, Mailchimp, ou Buttondown

Nenhum destes requer um servidor. Nenhum deles adiciona custo significativo.

FAQ

Quanto tempo leva a migração de WordPress para Astro?

Para um blog típico com 50-200 posts, espere 1-2 semanas de trabalho em tempo parcial se estiver fazendo por conta própria. A conversão de conteúdo geralmente é um dia de trabalho com um bom script. Construir os layouts e componentes Astro leva 2-4 dias dependendo da complexidade do design. Testes, configuração de redirecionamento e implantação levam mais 1-2 dias. Para sites maiores (500+ posts) ou sites com tipos de post personalizados complexos e dependências de plugins, orçamento 3-6 semanas. Se preferir deixar conosco, entre em contato com nosso time -- geralmente completamos migrações em 2-4 semanas.

O Astro pode manipular um blog WordPress com 1000+ posts?

Absolutamente. Migrei sites com mais de 3.000 posts e os tempos de build permaneceram abaixo de 2 minutos. As content collections são otimizadas para grandes conjuntos de dados, e como tudo compila para HTML estático, não há penalidade de desempenho em tempo de execução independentemente do volume de conteúdo. A etapa de build é o único lugar onde escala importa, e o desempenho de build do Astro é excelente -- significativamente mais rápido que Gatsby ou Next.js para conteúdo estático em escala.

O Astro suporta comentários do WordPress?

Não nativamente, e honestamente isso é um recurso, não um bug. Comentários do WordPress são um ímã de spam que requer moderação constante. Para sites Astro, as melhores opções são: Giscus (usa GitHub Discussions -- gratuito, sem rastreamento, ótimo para públicos de desenvolvedores), Disqus (o velho confiável, tem anúncios em camada gratuita), Commento (focado em privacidade, $5/mês), ou uma solução personalizada usando um banco de dados como Turso ou Supabase com uma rota de API Astro. Se você deseja preservar comentários WordPress existentes, exporte-os e exiba-os como conteúdo estático, então use um desses serviços para novos comentários a partir de agora.

O Astro é mais rápido que WordPress?

Nem de perto. Um site Astro estático vai superar até mesmo a configuração WordPress mais otimizada porque elimina o gargalo fundamental: processamento do lado do servidor. WordPress tem que executar PHP, consultar um banco de dados, montar a página e enviar -- para cada requisição (a menos que em cache). Astro pré-constrói tudo. Seus visitantes recebem HTML pré-renderizado diretamente de um nó de borda de CDN perto deles. As melhorias típicas são 80-90% tempos de carregamento mais rápidos e melhorias de score Lighthouse de 60-80 pontos.

O que acontece com meu admin WordPress e editor WYSIWYG?

Você perde o painel de administração do WordPress. Para a maioria dos desenvolvedores, isso é um alívio. Você editará arquivos markdown diretamente, o que é mais rápido e portável. Se você tem editores de conteúdo não-técnicos que precisam de uma interface visual, considere a abordagem headless: mantenha WordPress rodando como um backend de conteúdo e use Astro como o frontend. Ou combine Astro com um CMS headless como Sanity, Contentful, Storyblok, ou Keystatic (que tem um editor baseado em GitHub que é genuinamente bom). Nossos serviços de desenvolvimento de CMS headless podem ajudá-lo a escolher o backend de conteúdo certo para seu time.

Meus rankings do Google cairão após migrar?

Eles não devem, e na maioria dos casos melhoram -- mas apenas se você manipular redirecionamentos corretamente. Cada URL antiga deve ainda funcionar ou fazer 301-redirect para seu equivalente novo. Envie seu novo sitemap para o Google Search Console no mesmo dia em que lançar. Monitore o relatório de Cobertura de Índice pelos primeiros 30 dias. Vi sites ganharem 15-30% de tráfego orgânico dentro de 2-3 meses de migração puramente a partir de melhorias nos Core Web Vitals, já que Google usa sinais de experiência de página como fator de ranking.

Posso manter WordPress como um CMS headless e usar Astro para o frontend?

Sim, e essa é uma ótima abordagem de meio-termo. Você mantém a experiência de admin e editor do WordPress, mas se livra do frontend PHP inteiramente. Astro busca conteúdo da REST API do WordPress (ou WPGraphQL) no tempo de build e gera páginas estáticas. Você ainda precisa hospedar WordPress em algum lugar, então não economizará em custos de hospedagem, mas você obtém todos os benefícios de desempenho do frontend. Para times que estão fortemente investidos no fluxo de trabalho de edição do WordPress, essa geralmente é a escolha pragmática.

Preciso saber React ou qualquer framework JavaScript para usar Astro?

Não. Os componentes Astro usam um formato de arquivo .astro que parece HTML com um bloco de script de frontmatter. Se você consegue escrever HTML e CSS, você pode construir um site Astro. Frameworks JavaScript (React, Vue, Svelte) são opcionais -- você só os traria se precisasse de componentes interativos do lado do cliente como um widget de pesquisa, um formulário com validação, ou um carrossel de imagens. Para um blog ou site de marketing, você pode construir o site inteiro sem tocar em React.