Três anos atrás peguei um blog de um cliente, 400 posts, 60 mil visitas orgânicas mensais, oito anos de PageRank acumulado, e migrei para um front-end Next.js brilhante. Dentro de seis semanas havíamos perdido 34% daquele tráfego. Não porque o novo site era lento. Não porque o conteúdo desapareceu. Porque fui negligente com quatro coisas específicas que vou detalhar neste post para você não repetir meu erro.
WordPress headless com Next.js é genuinamente brilhante para performance e experiência do desenvolvedor. Mas Google não se importa com seu score do Lighthouse se suas canonical tags estão erradas, seu XML sitemap aponta para o domínio antigo, e seus structured data desapareceram em algum lugar entre WPGraphQL e getStaticProps. A migração em si é a parte perigosa. Acertar é principalmente questão de disciplina, não magia.
---
Por Que Esta Migração Quebra SEO Em Primeiro Lugar
A coisa que a maioria dos tutoriais deixa passar batido é esta: WordPress faz uma quantidade enorme de trabalho pesado de SEO para você sem você perceber. Yoast ou Rank Math está gerando suas meta tags. WordPress core está tratando sua estrutura de permalink. Seu tema provavelmente está outputando algum tipo de markup de schema. Seu XML sitemap se regenera automaticamente toda vez que você publica.
Quando você puxa a camada de conteúdo para Next.js via API WPGraphQL e a serve de um novo front-end, toda aquela infraestrutura vira seu problema para replicar. Cada. Peça. Uma.
O outro problema é a estrutura de URL. A maioria dos sites WordPress tem /category/post-slug/ ou /year/month/post-slug/ ou apenas /post-slug/. Next.js oferece uma tela em branco para roteamento. Essa tela em branco é um cemitério de rankings se você não planejar cuidadosamente.
Os Dois Modos de Falha que Vejo Constantemente
A primeira é times que migram as URLs também e ainda quebram as coisas, geralmente porque redirects são aplicados de forma inconsistente ou o novo sitemap fica ativo antes dos redirects. A segunda é times que intencionalmente mudam a estrutura de URL (frequentemente para limpá-la) e tratam o mapeamento de redirects como um detalhe menor. Ambos são corrigíveis. Nenhum dos dois é aceitável.
---
Audite Antes de Tocar em Qualquer Coisa
Não escreva uma única linha de código Next.js antes de ter um inventário completo de URLs. Uso Screaming Frog, rastreio o site WordPress ativo, exporto todas as URLs indexáveis e jogo em uma planilha. Para um site de 400 páginas isso é talvez uma hora de trabalho. Para um site de 4 mil páginas ainda é só uma hora, porque a ferramenta faz automaticamente.
O que você está capturando:
- Cada URL canônico atualmente indexado
- O status HTTP de cada um (identifique 404s e 301s que já existem)
- O meta title e description de cada página
- Quais páginas têm structured data (use o Rich Results Test ou inspecione apenas o fonte)
- Links internos de entrada, para você saber quais páginas linkam para quais.
Também puxe seus top 50 páginas do Google Search Console ordenadas por cliques. Essas são as que você não pode se dar ao luxo de errar. Sinalize-as na planilha. Trate-as como dependências de produção.
Seahawk tinha um cliente de e-commerce no final de 2022 -- loja WooCommerce de 1.200 produtos mudando para uma estrutura headless. Passamos dois dias inteiros no audit antes de escrever código. O cliente achava que estávamos perdendo tempo. Salvamos as 90 mil sessões orgânicas mensais deles.
---
Configurando WordPress como um Verdadeiro Headless CMS
Essa parte é principalmente direta. Instale WPGraphQL e exponha seu conteúdo via GraphQL API. Mas há algumas coisas que valem ser deliberado sobre.
Mantenha Yoast (ou Rank Math) Rodando no Lado do WordPress
Mesmo que você não esteja mais servindo WordPress como front-end público, mantenha seu plugin de SEO ativo. WPGraphQL for Yoast SEO (ou a extensão equivalente do Rank Math) expõe todos os meta de SEO, títulos, descrições, URLs canônicas, dados OG, diretivas de robots, diretamente através da API GraphQL. Isso significa que você pode consultá-la a partir de Next.js e renderizá-la exatamente como Yoast pretendia.
Essa foi a lição daquele drop de tráfego de 2019 que mencionei. Eu tinha assumido que conseguiríamos regenerar títulos a partir do título do post + nome do site em Next.js. Conseguíamos. Mas o Yoast tinha customizado manualmente meta titles para cerca de 80 dos posts com melhor desempenho, e a gente apagou tudo isso. Oito semanas para se recuperar.
Desabilite o Front-End do WordPress com Cuidado
Uma vez que você está pronto para apontar tráfego para Next.js, você NÃO quer WordPress servindo seu próprio front-end simultaneamente. Conteúdo duplicado em escala. A forma mais limpa é colocar um robots.txt em sua instalação WordPress com Disallow: / enquanto seu site Next.js vai ao ar, depois eventualmente fazer firewall da URL do WordPress inteiramente para que seja acessível apenas internamente ou via VPN.
Não pule a etapa do robots.txt. Já vi times bloquearem WordPress no nível do CDN e depois descobrirem que o Googlebot tinha uma rota em cache. Leva meses para limpar.
---
Replicando a Estrutura de URLs Exatamente
Minha recomendação padrão forte: mantenha suas URLs idênticas. Mesmo slug, mesma estrutura de permalink, mesmo comportamento de trailing slash. Quanto mais as rotas do Next.js espelharem as rotas do WordPress, menos redirects você precisará, e menos risco você carrega.
Dynamic routes do Next.js tornam isso fácil. Se seus posts WordPress vivem em /blog/[slug], crie pages/blog/[slug].js. Pronto.
Onde fica bagunçado é com archive de categorias, páginas de autor, páginas de tag, e archives paginados (/blog/page/2/). WordPress gera tudo isso automaticamente. Em Next.js você está construindo eles mesmo. Muitos times deprioritizam esses e depois se perguntam por que a cobertura de crawl caiu.
Aqui está meu checklist numerado para paridade de URL:
- Posts/páginas individuais, combine o slug exatamente, incluindo qualquer subpasta.
- Arquivos de categoria, recrie /category/[slug]/ com getStaticPaths puxando todas as categorias de WPGraphQL.
- Arquivos de tag, igual acima, não pule estes se recebem tráfego orgânico.
- Arquivos de autor, verifique o Search Console primeiro; se receberem zero cliques, você pode fazer 301 para a homepage
- Arquivos paginados, /blog/page/[num]/ vale a pena preservar se você tem muitos posts
- Páginas de anexo, quase sempre faça 301 delas para o post pai; elas são peso morto de SEO no WordPress também
- URLs de feed, /feed/ deve fazer 301 para seu novo feed RSS se tiver um, ou retornar 410 se não tiver
---
Redirecionamentos: A Parte Que Todo Mundo Subestima
Se você estiver mudando qualquer URL, o que eu questionaria, mas às vezes é necessário, seu mapa de redirecionamento precisa ser construído antes do lançamento e testado em um ambiente de staging.
No Next.js, redirecionamentos vivem em next.config.js. Para sites pequenos (menos de 200 redirecionamentos) isso é adequado. Para qualquer coisa maior, coloque-os em um arquivo JSON e importe-o, ou use middleware para lidar com eles dinamicamente. O edge middleware do Vercel é excelente para tabelas de redirecionamento grandes porque roda antes da página ser renderizada, zero penalidade de latência.
O formato em next.config.js:
``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``
permanent: true envia um 301. Use para todas as mudanças de URL genuínas. Não use 302 (temporário) a menos que você realmente tenha a intenção de revertê-lo, Google trata eles de forma muito diferente.
Teste cada redirecionamento antes do lançamento. Uso um script bash simples que passa pela planilha e faz curl de cada URL antiga verificando uma resposta 301 para o destino correto. Leva dez minutos para escrever, economiza horas de pânico pós-lançamento.
---
Meta Tags, URLs Canônicas e Dados Estruturados no Next.js
É aqui que a maioria das migrações perde pontos silenciosamente. O conteúdo está lá, as URLs funcionam, mas os sinais de SEO estão errados.
Meta Tags
Use next-seo. É o padrão. Passe para ele os dados que você consultou do WPGraphQL Yoast. Seu app.js recebe uma configuração DefaultSeo, e cada página recebe um componente NextSeo com as sobrescrituras específicas da página. Pegue o título, descrição, título OG, imagem OG, URL canônica e diretivas de robots diretamente da resposta GraphQL do Yoast, não reinvente.
Uma coisa que pega as pessoas: URLs canônicas. No WordPress, o Yoast define canônicas automaticamente. No Next.js você precisa passar a canônica explicitamente. Se esquecer, o Next.js renderizará páginas sem a tag canônica, e se você tiver query strings em qualquer lugar (paginação, filtros), você terá problemas de conteúdo duplicado mais rápido do que esperaria.
Dados Estruturados
Temas e plugins WordPress frequentemente geram JSON-LD automaticamente. Isso desaparece em headless. Você precisa reconstruir. Para artigos, use o schema Article. Para produtos, Product. Para negócios locais, LocalBusiness. Escrevo esses como componentes React que aceitam props e retornam uma tag <script type="application/ld+json">. Um componente por tipo de schema, reutilizado em toda a app.
Verifique cada tipo de schema que você tinha antes na Rich Results Test antes da migração. Documente. Recrie. Teste os novos com a mesma ferramenta após o lançamento.
O XML Sitemap
Não use um sitemap estático. Gere-o dinamicamente. Para sites pequenos, getServerSideProps em uma rota /sitemap.xml funciona. Para sites grandes com milhares de posts, gere o sitemap no tempo de construção via um script customizado e exporte para a pasta public/. Vercel roda isso a cada deployment, seu sitemap está sempre atualizado.
Envie a nova URL do sitemap para o Google Search Console no primeiro dia do novo site ao vivo. Não no terceiro dia. No primeiro dia.
---
Monitoramento Pós-Lançamento (A Janela de 90 Dias)
A migração não termina no lançamento. Termina quando seus rankings se estabilizarem, o que a documentação do Google sugere que pode levar de algumas semanas a alguns meses dependendo do crawl budget e autoridade do site.
O que monitoro toda semana no primeiro mês:
- Google Search Console → relatório Coverage procurando por novos 404s ou URLs 'Excluded' que não deveriam estar excluídos
- Search Console → Performance, compare clicks and impressions week-on-week para suas top 50 pages
- Recrawl do Screaming Frog do site novo para pegar qualquer 404 interno ou tags canonical mal configuradas
- Core Web Vitals, sim, o site Next.js deveria ser mais rápido, mas verifique nos field data (CrUX), não só no Lighthouse
Se vir uma queda significativa nas primeiras duas ou três semanas, não entre em pânico imediatamente. Quase sempre há uma flutuação de curto prazo enquanto o Google re-rastreia e re-indexa. O que você procura é quedas sustentadas após a semana quatro. Esse é o sinal de que algo estrutural está errado.
Lá em finais de 2022, projeto diferente do de e-commerce, a gente lançou uma migração Next.js para um blog SaaS e viu uma queda de 20% em impressões na segunda semana. Descobrimos que nosso sitemap gerado dinamicamente estava incluindo páginas com noindex porque não tínhamos filtrado a query do WPGraphQL direito. Arrumamos em quatro horas. Os rankings se recuperaram em três semanas. O monitoramento pegou antes de piorar.
---
FAQ
Quanto tempo leva uma migração de WordPress para Next.js?
Honestamente, depende mais da complexidade do site do que da quantidade de posts. Um site institucional com 100 páginas e URLs limpas pode ser feito corretamente em duas a três semanas. Um blog com 2.000 posts, tipos de post customizados, campos ACF e integração WooCommerce é um projeto de mínimo seis a oito semanas se você estiver fazendo o trabalho de SEO corretamente junto com o desenvolvimento. Não deixe ninguém te contar que é um trabalho de fim de semana.
Devo usar o Pages Router ou o App Router no Next.js?
A partir de meados de 2024 estou usando App Router por padrão em projetos novos. Mas se seu time está mais confortável com Pages Router e essa migração é time-sensitive, use o que vocês conhecem. As implicações de SEO são mínimas, ambos suportam static generation, server-side rendering e dynamic routes. O package next-seo tem suporte a App Router agora também.
Preciso sair do WordPress hosting completamente?
Não. WordPress pode ficar no host atual, WP Engine, Kinsta, Cloudways, qualquer um que vocês usem, e funcionar puramente como content API. O front-end Next.js faz deploy em Vercel ou Netlify. Os dois se comunicam via HTTP. Alguns clientes na verdade preferem isso porque o time editorial fica com o WordPress admin que já conhecem.
E quanto aos plugins WordPress que afetam SEO, tipo redirects gerenciados em Redirection?
Exporte antes de migrar. O plugin Redirection tem export em CSV. Pegue todos os redirects existentes e adicione no seu next.config.js ou edge middleware. Não assuma que vão funcionar automaticamente, porque vivem no banco de dados WordPress e Next.js não sabe que existem.
Meu ranking no Google vai cair não importa o quê?
Quase sempre tem alguma volatilidade no curto prazo. Uma migração bem executada com zero mudanças de URL, redirects apropriados (onde necessário), meta e structured data replicados, e sitemap resubmetido deveria estabilizar em quatro a seis semanas. As quedas que durou meses que vi foram todas causadas por erros técnicos específicos, não pela migração em si.
---
A migração não é a parte difícil. A parte difícil é a disciplina de fazer cada passo chato e sem glamour, o audit, o redirect mapping, a recriação de schema, antes de escrever qualquer código Next.js esperto. Acerta essa ordem e você sai do outro lado com um front-end mais rápido e os mesmos rankings de antes. Possivelmente melhores, uma vez que as melhorias de Core Web Vitals começarem a ter efeito.