Migração de WordPress para Next.js: como mudar sem perder posições no Google

Vale a pena quando o WordPress virou o problema, e não apenas porque é antigo. Os gatilhos mais comuns são uma pilha de plugins que ninguém entende por completo, atualizações que esperam meses e necessidades de login ou de acesso para as quais o núcleo do WordPress não foi feito. Se o site está atualizado, usa poucos plugins bem mantidos e a equipe edita páginas todos os dias, reforçar o WordPress costuma custar menos e trazer menos risco do que migrar.

• Muitos plugins se acumulam para cobrir login, formulários, áreas de membros ou pagamentos, cada um com o próprio calendário de atualizações.
• Ninguém é responsável pelas atualizações, então os patches do núcleo, do tema e dos plugins esperam semanas ou meses.
• Você precisa de MFA, SSO ou acesso por perfis projetados dentro do produto, e não adicionados com plugins.
• O conteúdo muda pouco, ou uma equipe de desenvolvimento já cuida dele.
• O site virou um portal ou um aplicativo que o WordPress mal consegue sustentar.

Fique e reforce o WordPress quando o contrário for verdade: remova plugins sem uso, use uma hospedagem gerenciada confiável, aplique patches em poucos dias, mantenha backups e coloque um firewall de aplicação web na frente. Uma falha de segurança sozinha raramente justifica uma migração. Quando surge uma falha no núcleo como a CVE-2026-87902, a primeira tarefa é atualizar; a migração é uma decisão separada, que pode ser tomada com calma depois. Nossos guias sobre a segurança do WordPress em comparação com um site sob medida e sobre a CVE-2026-87902 tratam dos dois assuntos.

Existem dois caminhos principais. No primeiro, o WordPress continua como CMS headless: os editores mantêm o painel do WordPress, e um front-end em Next.js busca o conteúdo e monta as páginas públicas. A própria documentação para desenvolvedores do WordPress descreve sua REST API como uma forma de levar o conteúdo do WordPress para aplicações totalmente separadas, utilizável por qualquer linguagem capaz de fazer requisições HTTP e ler JSON. No segundo caminho, o WordPress é aposentado e o conteúdo vai para outro CMS headless ou para um painel administrativo sob medida, criado para a sua equipe.

O headless costuma ser o primeiro passo menor, mas mantém um painel do WordPress que precisa ser atualizado e protegido. Uma reconstrução completa remove o WordPress de vez e custa mais no início. Escolha com base em quem edita o conteúdo, com que frequência e quanto do sistema antigo você aceita continuar mantendo.

Este é o processo que seguimos nas migrações de WordPress. Cada etapa deixa algo registrado por escrito, para que nada dependa da memória no dia do lançamento.

1. 1

   Auditar o site

   Listar cada página, tipo de post, formulário, perfil de usuário e plugin, e anotar o que cada plugin realmente faz pelo negócio. Reunir as URLs atuais do sitemap, de um rastreamento e do Search Console para não esquecer páginas com tráfego ou links recebidos.

2. 2

   Mapear URLs antigas para novas

   Dar a cada endereço antigo um destino em uma única planilha: posts, páginas, arquivos de categorias e tags, páginas de autor, feeds e arquivos de mídia em /wp-content/uploads/. Cada linha vira um redirecionamento permanente.

3. 3

   Reconstruir e decidir como o conteúdo será editado

   Refazer os templates em Next.js e escolher entre WordPress headless, outro CMS headless ou um painel sob medida, conforme quem edita e com que frequência.

4. 4

   Mover conteúdo, usuários e dados

   Importar posts, páginas, mídias e contas, comparar manualmente uma amostra com o site antigo e reconstruir o login com o modelo de acesso necessário, como acesso por perfis, MFA ou SSO.

5. 5

   Lançar e monitorar

   Fazer a troca, testar os redirecionamentos, enviar o novo sitemap e acompanhar no Search Console os erros e as páginas que sumiram. Depois do lançamento, as atualizações de dependências e o monitoramento continuam como parte do trabalho.

O Google trata uma troca de plataforma que altera URLs como uma mudança de site. O guia do Search Central sobre mudanças de site com alteração de URLs (atualizado em 20 de agosto de 2026) recomenda redirecionamentos permanentes no servidor, como 301 ou 308, um mapa completo das URLs antigas para as novas e manter os redirecionamentos pelo maior tempo possível, no mínimo um ano. O guia também diz que, em um site de porte médio, pode levar algumas semanas ou mais até o Google mostrar as novas URLs no lugar das antigas, então alguma oscilação após o lançamento é normal.

• Redirecione cada URL antiga direto para a página nova mais próxima. Evite cadeias e não mande muitas URLs antigas para a página inicial.
• No Next.js, declare os redirecionamentos no next.config com permanent: true, que retorna um 308. A documentação do Next.js observa que as plataformas de hospedagem podem limitar essa lista (a Vercel permite 1.024) e sugere um mapa de redirecionamentos lido pelo Proxy a partir de 1.000.
• Dê a cada página nova uma tag canonical que aponte para ela mesma. No Next.js isso é definido com alternates.canonical na Metadata API.
• Gere um sitemap das novas URLs com app/sitemap.ts e envie-o no Search Console; mantenha o sitemap antigo até o novo ter sido enviado.
• Use redirecionamentos no servidor, não em JavaScript. A documentação do Google sobre redirecionamentos diz para usar redirecionamentos em JavaScript apenas quando não for possível fazê-los no servidor nem com meta refresh.
• Mantenha o site verificado no Search Console, confira toda semana os relatórios de indexação e de sitemaps após o lançamento e atualize os links internos para que o site não dependa dos próprios redirecionamentos.

Mantenha o mesmo domínio, se puder. Trocar de plataforma e de domínio ao mesmo tempo torna os problemas mais difíceis de rastrear. Se o domínio precisar mudar, o guia do Google inclui nas etapas a ferramenta de mudança de endereço do Search Console.

O WordPress multisite roda vários sites a partir de uma única instalação. A documentação do WordPress descreve redes baseadas em caminhos (subdiretórios) ou em domínios (domínios ou subdomínios), em que cada site mantém as próprias tabelas de conteúdo e apenas a tabela de usuários é compartilhada. Isso define o plano.

• Trate cada site como uma migração própria, com seu mapa de URLs, seu sitemap e suas verificações no Search Console.
• Decida cedo se os usuários compartilhados ficam em um único sistema de contas ou são separados por site, e como os administradores da rede vão gerenciar todos os sites depois.
• Liste quais plugins e temas estão ativos em toda a rede, porque um único plugin pode sustentar funções em todos os sites.
• Uma única aplicação Next.js pode atender vários domínios, e seus redirecionamentos podem filtrar pelo nome do host, então um só código pode guardar os mapas de redirecionamento de todos os sites.
• Migre um site primeiro, acompanhe o tráfego de busca dele por algumas semanas e depois migre os demais.

Seja uma equipe local ou remota, por exemplo uma empresa do Reino Unido que trabalha com uma agência de outro país, peça estas respostas por escrito antes de assinar.

• O mapa completo de redirecionamentos faz parte do escopo escrito, e quem o confere após o lançamento?
• Como a nossa equipe vai editar e publicar conteúdo depois do lançamento, e vocês vão treiná-la?
• Quais plugins serão reconstruídos, quais serão substituídos por um serviço e quais serão descartados?
• Como as contas de usuário e os logins serão migrados, e o que os usuários verão na primeira vez que entrarem?
• O domínio e as URLs serão mantidos, e por quanto tempo vocês vão monitorar a busca após o lançamento?
• Quem é o titular do código, da hospedagem, do CMS e das contas do domínio?
• Quais horas do nosso expediente coincidem com o de vocês, e em quanto tempo vocês respondem?
• Quem atualiza as dependências após o lançamento, e isso está no contrato?
• Podemos ver migrações ou plataformas de conteúdo que vocês já construíram?

O prazo e o custo dependem mais do conteúdo e das URLs do que do código. Os principais fatores são:

• O número de templates de página distintos e de tipos de post personalizados.
• Quantas URLs precisam de redirecionamento, incluindo arquivos de listagem e arquivos de mídia.
• Formulários, pagamentos, áreas de membros e integrações com CRM ou ERP que os plugins cuidavam.
• Se o WordPress continua como CMS headless ou é substituído.
• As contas de usuário e o modelo de login, principalmente com MFA ou SSO.
• Redes multisite e idiomas adicionais, cada um com as próprias URLs.

Os números publicados variam muito e vêm principalmente de agências. Como exemplo, a Kolonell, um estúdio web remoto, publicou em 8 de outubro de 2026 uma estimativa para pequenas empresas do Reino Unido: de £13.000 a £30.000 sem VAT para uma mudança para Next.js headless, em 10–14 semanas (cerca de 2 semanas de auditoria e definição de escopo, 6–8 semanas de desenvolvimento e migração e 2–4 semanas de testes e lançamento em fases). Considere isso como o preço de uma agência, não como valor de mercado. Algumas agências vendem um sprint de migração a preço fechado; pergunte o que está incluído, principalmente redirecionamentos e treinamento dos editores.

Não publicamos preços fechados. A nossa consulta gratuita começa pelos problemas que você tem hoje, e não por uma reconstrução: uma chamada de 30 minutos com um engenheiro, uma revisão do seu site WordPress com a recomendação de atualizar, reforçar ou migrar, e uma recomendação por escrito com uma estimativa aproximada de custo. Se continuar no WordPress for a melhor resposta, é isso que a recomendação vai dizer.

• Serviço de migração de WordPress para Next.js (em inglês)
• WordPress ou site sob medida: migrar é mais seguro? (em inglês)
• CVE-2026-87902 do WordPress: o que fazer (em inglês)
• O que é um CMS headless?
• Agende uma consulta gratuita e uma revisão do WordPress (em inglês)

• Google Search Central: Site moves with URL changes (updated 20 August 2026)
• Google Search Central: Redirects and Google Search (updated 14 April 2026)
• Next.js docs: redirects in next.config.js (updated 30 June 2026)
• Next.js docs: How to handle redirects in Next.js (updated 19 August 2026)
• Next.js docs: sitemap.xml file convention (updated 18 August 2026)
• Next.js docs: generateMetadata, alternates and canonical (updated 19 August 2026)
• WordPress Developer Resources: REST API Handbook (accessed 1 November 2026)
• WordPress Developer Resources: Multisite (accessed 1 November 2026)
• Kolonell: WordPress to Next.js migration cost for UK SMBs, agency estimate (8 October 2026)