Migração de WordPress Multisite para Next.js

WordPress Multisite Era Uma Boa Ideia em 2012

WordPress Multisite fazia sentido em 2012. Em 2026, cada subsite que você adiciona torna a migração que eventualmente precisará mais difícil. As tabelas com prefixo crescem. Os dados serializados se acumulam. O plugin de mapeamento de domínio adiciona outra dependência. Cada ano no Multisite é um ano de débito técnico que você pagará durante a migração.

A questão não é se você vai migrar. É quando.

Migramos redes Multisite com 5 subsites e redes com 80+. O padrão técnico é o mesmo toda vez: extrair tabelas com prefixo, desserializar anos de dados de opções acumulados, mapear usuários compartilhados para um sistema de autenticação moderno e construir uma arquitetura multi-tenant que realmente escala. A diferença é escopo, não complexidade.

Por Que Sair do WordPress Multisite

Redes Multisite acumulam categorias específicas de débito técnico que crescem com o tempo.

Proliferação de Tabelas com Prefixo

Cada subsite cria seu próprio conjunto de tabelas: wp_2_posts, wp_2_postmeta, wp_2_options, wp_3_posts, e assim por diante. Uma rede com 25 sites tem 250+ tabelas. Consultar entre subsites requer uniões entre todas elas. Não há busca nativa entre sites, nenhuma API de conteúdo unificada, nenhuma forma de agregar sem SQL personalizado.

Dados Serializados em Todos os Lugares

WordPress armazena dados complexos como strings serializadas PHP. Grupos de campos ACF, configurações de widgets, URLs de site, configurações de plugin — tudo serializado. Essas strings codificam comprimentos de string (s:23:"https://old-domain.com"), o que significa que você não pode fazer uma simples localização e substituição de URLs sem quebrar a serialização. Cada migração que toca dados serializados precisa de desserialização adequada, transformação e re-serialização. Sem atalhos.

Usuários Compartilhados, Funções Fragmentadas

A tabela wp_users é em todo o rede. Um usuário pode ser admin no subsite 2, editor no subsite 5 e subscriber no subsite 12. Essas funções vivem como arrays serializados em wp_usermeta sob chaves como wp_2_capabilities. Extrair isso em um modelo de autenticação sensato significa analisar a função de cada usuário por subsite — o que é tão tedioso quanto parece.

Fragilidade de Plugin e Atualização

Plugins ativados na rede afetam todos os subsites simultaneamente. Uma atualização de plugin que quebra um subsite quebra o admin para cada subsite. Plugins específicos do site criam conflitos de versão. A base de código compartilhada significa que cada mudança é um possível apagão em toda a rede.

Degradação de Desempenho em Escala

Redes Multisite com 10+ subsites veem 40-60% carregamentos de página mais lentos em comparação com instalações WordPress independentes. Análise de dados serializados, conexões de banco de dados compartilhadas e overhead de plugin tudo se acumula. As pontuações do Lighthouse mobile normalmente ficam entre 35-55. Não ótimo.

O Que Você Obtém: Arquitetura Multi-Tenant Next.js + Supabase

A arquitetura alvo substitui toda a rede Multisite por uma única aplicação Next.js apoiada por Supabase, usando Row Level Security para isolamento de tenant.

Multi-Tenancy Baseada em Rotas

Em vez de subdomínios ou subdiretórios gerenciados pelo WordPress, cada localização obtém uma rota limpa: /locations/[slug]. Componentes compartilhados (navbar, footer, elementos de marca) renderizam de um único layout. O conteúdo específico da localização é extraído do Supabase filtrado por location_id. Um codebase, uma implantação, localizações ilimitadas.

Supabase RLS para Isolamento de Dados

As políticas de Row Level Security impõem que gerentes de localização vejam apenas seus próprios dados, enquanto admins de rede veem tudo. Sem hacks de filtragem no nível da aplicação. O próprio banco de dados impõe acesso:

CREATE POLICY "location_isolation" ON posts
  FOR ALL USING (
    auth.uid() IN (
      SELECT user_id FROM user_locations
      WHERE location_id = posts.location_id
    )
  );

Isso elimina uma classe inteira de bugs de autorização que afligem configurações WordPress multi-tenant.

Dashboard Admin Moderno

Gerentes de localização obtêm um dashboard de propósito específico: adicionar localizações, editar conteúdo por localização, gerenciar mídia. Não mais clicar através do comutador de admin de rede do WordPress. Nenhuma mais confusão "Super Admin" vs "Site Admin".

Nosso Processo de Migração em 7 Fases

Fase 1: Auditoria de Rede (1-2 Semanas)

Mapeamos cada subsite em sua rede — estrutura de URL, volume de conteúdo, plugins usados, tipos de post personalizados, campos personalizados, configuração de mapeamento de domínio. Consultamos wp_blogs para enumerar subsites, então rastreamos cada um via REST API e consultas de banco de dados diretas.

Identificamos conteúdo compartilhado (em toda a rede) versus conteúdo específico do site. Plugins compartilhados versus plugins específicos do site. Código personalizado em child themes, mu-plugins e plugins ativados na rede com funcionalidade personalizada.

O resultado é um documento de especificação de migração com um inventário de conteúdo subsite por subsite.

Fase 2: Design de Arquitetura (1 Semana)

Projetamos o schema Supabase: tabela locations, tabelas de conteúdo com chaves estrangeiras location_id, políticas RLS por tabela. Projetamos a estrutura de rota Next.js e mapeamos cada URL antiga para seu equivalente novo para redirecionamentos 301.

O dashboard admin é prototipado: gerenciamento de localização, edição de conteúdo por localização, acesso baseado em funções. Cada decisão é documentada antes de escrevermos uma linha de código.

Fase 3: Exportação de Conteúdo (1-2 Semanas)

Aqui é onde as migrações Multisite ficam técnicas. Extraímos conteúdo através de dois canais:

WP REST API para conteúdo padrão — requisições autenticadas por subsite, tratando paginação em milhares de posts.

Consultas diretas de banco de dados para tudo o que a API não pode exibir: campos ACF armazenados em wp_2_postmeta, tabelas personalizadas criadas por plugins, opções serializadas contendo configuração crítica.

Os dados serializados são processados através do unserialize() do PHP ou da biblioteca phpserialize do Python. Referências de domínio incorporadas em opções serializadas (siteurl, home) são atualizadas antes da re-serialização. Uma busca e substituição ingênua em strings serializadas corrompe os prefixos de comprimento e quebra tudo — vimos isso dar errado, e limpá-lo é brutal.

Arquivos de mídia são baixados iterando /wp-content/uploads/sites/[id]/ por subsite. Os usuários são exportados da tabela wp_users em toda a rede com capacidades por site analisadas de entradas wp_usermeta serializadas.

Saída: arquivos JSON e CSV por subsite com todo conteúdo, usuários e mídia inventariados.

Fase 4: Build (2-6 Semanas)

A aplicação Next.js toma forma com multi-tenancy baseada em rotas. As tabelas Supabase são criadas com políticas RLS aplicadas. Componentes de layout compartilhados tratam consistência de marca. Modelos de página por localização renderizam zonas de conteúdo localizadas.

O dashboard admin suporta adição de localizações, edição de conteúdo de localização e visualização de dados agregados em todas as localizações. Formulários de contato, integrações de reserva e embeds de terceiros são reconstruídos ou migrados.

O cronograma depende da complexidade: uma rede com 5 subsites com páginas padrão leva 2 semanas. Uma rede com 40 subsites com sistemas de reserva personalizados, áreas de membership e layouts ACF complexos leva 6.

Fase 5: Importação de Conteúdo (1-2 Semanas)

Todo o conteúdo é importado em lote para Supabase com mapeamento de location_id. Cada tabela com prefixo wp_2_ mapeia para location ID 2. URLs de mídia são reescritas de /uploads/sites/23/image.jpg para caminhos de Armazenamento Supabase ou novas URLs de CDN usando transformações regex em todos os campos de conteúdo.

Os usuários WordPress são mapeados para Supabase Auth. Os hashes de senha são preservados — o rehashing bcrypt ocorre no primeiro login, então os usuários não precisam redefinir senhas.

Validamos selecionando 10% do conteúdo por subsite contra o original.

Fase 6: Mapeamento de Redirecionamento (1 Semana)

Cada URL antiga em todos os subsites obtém mapeamento para sua nova URL. Para subsites com domínio mapeado, o domínio antigo redireciona para o novo caminho /locations/[slug] com um 301. Subdomínios antigos (site2.example.com) redirecionam para /locations/site2.

Rastreamos cada sitemap antigo e verificamos se existe um 301 para cada URL. Novos sitemaps são enviados para Google Search Console por domínio anterior.

Fase 7: Lançamento e Monitoramento

O cutover de DNS acontece por domínio. Certificados SSL auto-provisionam via Vercel. Google Search Console recebe novas propriedades de domínio com novos sitemaps. Monitoramos por 30 dias: progresso de indexação, baselines de Core Web Vitals, rastreamento de 404.

O banco de dados WordPress antigo é arquivado. A hospedagem é cancelada após um período de monitoramento de 60 dias confirmar que tudo está estável.

Estratégia de Preservação de SEO

Migrações Multisite carregam risco real de SEO — você está potencialmente alterando URLs em dezenas de domínios de uma vez. Nossa abordagem:

• Mapeamento exaustivo de 301 — cada URL, cada subsite, cada domínio. Sem 404s.
• Envio de sitemap por domínio — cada domínio anterior obtém seu próprio sitemap enviado para GSC.
• Consistência de tag canonical — novas páginas carregam canonicals apropriados desde o primeiro dia.
• Verificação de paridade de conteúdo — diff automatizado garante que nenhum conteúdo seja perdido ou truncado durante importação.
• Preservação de backlink — auditamos backlinks por subsite e garantimos que 301s capturem todo equity de link de entrada.

Os clientes geralmente veem melhoria de tráfego orgânico de 25-50% dentro de 90 dias, principalmente de ganhos de Core Web Vitals sozinhos.

Cronograma e Preço

Tamanho de Rede	Subsites	Cronograma	Investimento
Pequeno	5-10	4-6 semanas	$15.000 - $30.000
Médio	10-25	6-8 semanas	$30.000 - $60.000
Grande	25-50	8-12 semanas	$60.000 - $100.000
Enterprise	50+	10-16 semanas	$80.000 - $150.000+

O preço escala com o volume de dados serializados, tipos de post personalizados, complexidade de função de usuário e integrações de terceiros por subsite. Redes com uso pesado de ACF ou funcionalidade de plugin personalizada tendem para a extremidade superior.

Cada contrato começa com uma auditoria de migração gratuita. Mapeamos sua rede, estimamos escopo e lhe damos uma proposta de preço fixo antes que qualquer trabalho comece.