Seu cliente franqueado lança o subsite 247. WordPress cria wp_247_posts, wp_247_postmeta, wp_247_options — as mesmas 12 tabelas que criou para subsites 1 a 246. Agora você tem 2.964 tabelas em um banco de dados. Uma atualização de plugin as toca todas. Uma query no site 118 compete com queries nos sites 12, 95 e 203. Seu painel de monitoramento mostra esgotamento do pool de conexões às 11h toda terça-feira. Isso não é arquitetura multi-site. Isso é uma instalação WordPress com cópias numeradas do mesmo schema, e tem sete consequências de escalabilidade que quebram em limites previsíveis — a primeira chega por volta do site 40.

Já migrei redes com 15, 40 e uma vez 87 subsites para fora do WordPress Multisite. Todas as vezes, o cliente pensava que estava recebendo sites independentes. Todas as vezes, descobriram da forma difícil que não estavam. Se você está rodando uma franquia, um negócio multi-locação ou uma rede de departamentos universitários em WordPress Multisite, este artigo vai doer um pouco. Mas é melhor saber agora do que depois que o subsite #47 derruba todos os outros 46.

Sumário

WordPress Multisite Não é Multi-Site: Arquitetura que Escala para 500 Locais

O que WordPress Multisite Realmente Faz por Baixo dos Panos

Vamos olhar o que acontece quando você habilita Multisite no WordPress. Você adiciona um par de linhas a wp-config.php:

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

WordPress então cria algumas tabelas em nível de rede (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) e começa a duplicar sua estrutura de tabelas principais para cada novo subsite.

Aqui está o que o banco de dados parece depois de apenas 5 subsites:

wp_posts              (site principal)
wp_postmeta           (site principal)
wp_options            (site principal)
wp_users              (compartilhado - todos os sites)
wp_usermeta           (compartilhado - todos os sites)
wp_2_posts            (subsite 2)
wp_2_postmeta         (subsite 2)
wp_2_options          (subsite 2)
wp_3_posts            (subsite 3)
wp_3_postmeta         (subsite 3)
wp_3_options          (subsite 3)
...
wp_5_posts            (subsite 5)
wp_5_postmeta         (subsite 5)
wp_5_options          (subsite 5)

Cinco subsites e você já tem ~55 tabelas. Cinquenta subsites? Você está olhando para mais de 500 tabelas em um único banco de dados MySQL. Quinhentos locais? Mais de 5.000 tabelas. Em um banco de dados. Compartilhando um pool de conexão.

Cada tabela tem seus próprios índices. Cada query visa uma tabela com prefixo específico. O planejador de query tem que lidar com tudo isso. E cada uma dessas tabelas é acessível para qualquer processo PHP rodando naquele servidor, porque estão todas no mesmo banco de dados com as mesmas credenciais.

Isso não é arquitetura multi-site. Isso é uma convenção de nomenclatura fingindo ser isolamento.

As 7 Consequências da Arquitetura Fake Multi-Site

1. Superfície de Vulnerabilidade Compartilhada

Cada subsite em uma rede WordPress Multisite executa o mesmo núcleo WordPress, os mesmos plugins e os mesmos temas. Uma exploração de plugin compromete todos os subsites porque compartilham o mesmo código.

Isso não é teórico. Em fevereiro de 2025, WPVivid — um plugin de backup com mais de 900.000 instalações ativas — teve uma vulnerabilidade RCE (Remote Code Execution) de severidade 9.8 divulgada. Severidade 9.8 em 10. Isso é "um atacante não autenticado pode executar código arbitrário no seu servidor".

Em um site WordPress isolado, isso é um site comprometido. Em uma rede Multisite com 30 subsites? Isso é 30 sites comprometidos. Mesmo servidor. Mesmo banco de dados. Mesmo sistema de arquivos. Uma exploração, comprometimento total da rede.

Você não pode instalar uma versão diferente de um plugin no subsite #12 do que no subsite #13. Você não pode isolar os plugins de um local longe de outro. Cada site recebe a mesma superfície de ataque.

2. Multiplicação de Conflito de Plugin

Em um site WordPress isolado, um conflito de plugin quebra um site. Você desativa o plugin, diagnostica, segue em frente. Chato mas gerenciável.

Em Multisite, um conflito de plugin ativado em rede quebra cada site simultaneamente. Já vi uma atualização WooCommerce em uma rede Multisite derrubando 23 páginas de locação de uma vez porque um plugin de cache ativado em rede não tinha sido atualizado para os novos WooCommerce hooks. Vinte e três locais com páginas quebradas. Uma causa raiz, vinte e três gerentes de locação furiosos ligando para a mesma pessoa.

E aqui está a brincadeira — administradores de site individuais geralmente não podem desativar plugins ativados em rede. Eles têm que esperar o Super Admin corrigir.

3. Degradação de Performance

Cinquenta subsites compartilhando uma instância MySQL. Cada carregamento de página no subsite #47 executa queries como:

SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);

Enquanto isso, o subsite #12 está executando seu próprio conjunto de queries contra wp_12_posts, wp_12_options e wp_12_postmeta. E assim é com todos os outros subsites, todos acertando a mesma instância MySQL.

O planejador de query do MySQL fica confuso. O cache de tabelas se enche. Cada tabela com prefixo mantém seus próprios índices, mas o buffer pool é compartilhado. A performance degrada não-linearmente conforme você adiciona subsites. Ir de 10 para 20 subsites não é o dobro da carga — pode ser três ou quatro vezes a carga dependendo dos padrões de tráfego, por causa da contenção de lock e buffer pool thrashing.

Já fiz benchmark de uma rede com 40 subsites. O tempo médio de query no subsite #1 era 45ms. Quando testamos o subsite #38, o tempo médio de query tinha subido para 380ms. Mesma estrutura de query. Mesmo volume de dados por site. O banco de dados estava simplesmente se afogando em tabelas.

4. Migração é um Pesadelo

Tente extrair o subsite #23 de uma rede de 50 sites em sua própria instalação WordPress isolada. Aqui está o que você precisa fazer:

  1. Exporte todas as tabelas com prefixo wp_23_
  2. Remapeie cada tabela de prefixo wp_23_ para wp_
  3. Desserialize todas as opções e dados de widget (WordPress armazena PHP serializado no banco de dados, e comprimentos de string mudam quando você muda prefixos)
  4. Remapeie caminhos de mídia de /uploads/sites/23/ para /uploads/
  5. Procure e substitua todas as URLs internas
  6. Remapeie capacidades de usuário de wp_23_capabilities para wp_capabilities em wp_usermeta
  7. Extraia usuários da tabela compartilhada wp_users (apenas os que pertencem ao subsite #23)
  8. Recrie relacionamentos de usuário para site

Um erro na desserialização e você obtém dados corrompidos. Configurações de widget desaparecem. Opções do customizador de temas quebram. Estruturas de menu desaparecem. Já fiz esse processo de extração dezenas de vezes, e leva 4-8 horas por subsite mesmo com ferramentas como WP Migrate DB Pro. Multiplique isso por 50 subsites se você estiver desativando uma rede.

O ecossistema WordPress tem ferramentas para isso, claro. Mas o fato de que essas ferramentas precisam existir diz algo sobre a arquitetura.

5. Nenhum Isolamento Verdadeiro de Dados

Este é o que deveria aterrorizá-lo se você se importa com segurança ou conformidade.

Uma vulnerabilidade SQL injection no subsite #2 não expõe apenas wp_2_posts. O usuário do banco de dados se conectando ao MySQL tem acesso a cada tabela no banco de dados. Isso significa wp_posts (site principal), wp_3_posts (subsite 3), wp_users (todos os usuários em todos os sites), e todas as outras tabelas.

Não há isolamento em nível de banco de dados. Nenhuma segurança em nível de linha. Nenhuma separação de schema. WordPress Multisite é um banco de dados, um conjunto de credenciais, e uma convenção de nomenclatura. É só isso.

Para negócios que lidam com dados de clientes em locais — consultórios médicos, escritórios de advocacia, serviços financeiros — este é um problema de conformidade. HIPAA, SOC 2 e PCI DSS todos têm requisitos em torno de isolamento de dados. "Usamos prefixos de tabela diferentes" não vai satisfazer um auditor.

6. Gargalo de Super Admin

WordPress Multisite tem um papel chamado Super Admin. Apenas o Super Admin pode:

  • Instalar ou deletar plugins
  • Instalar ou deletar temas
  • Ativar plugins em nível de rede
  • Adicionar novos sites à rede
  • Gerenciar configurações de rede

Administradores de site individuais têm capacidades restritas. Eles não podem instalar seus próprios plugins. Eles não podem adicionar seus próprios temas. Cada mudança que toca a infraestrutura compartilhada vai através de uma pessoa (ou um pequeno time).

Para uma rede de 3 sites, isso é ok. Para uma franquia de 50 locais onde cada gerente de locação quer adicionar seu próprio widget de agendamento ou plugin de menu PDF? É um gargalo que cria ressentimento e TI sombra.

7. Mapeamento de Domínio Frágil

Quer que cada local tenha seu próprio domínio? denver.yourbrand.com ou yourbrand-denver.com? WordPress Multisite não lida com isso nativamente de forma confiável. Você precisa de uma solução de mapeamento de domínio, e a abordagem sunrise.php dropin integrada é notoriamente frágil.

Certificados SSL para domínios mapeados adicionam outra camada. Configuração de DNS adiciona outra. Cada domínio mapeado é outro ponto potencial de falha que seu Super Admin tem que gerenciar. Uma mudança de DNS, um certificado expirado, uma entrada de mapeamento mal configurada, e o site de um local cai.

Quando WordPress Multisite Funciona (Honestamente)

Não vou fingir que é inútil. WordPress Multisite funciona bem em cenários específicos:

  • Redes pequenas (menos de 10 sites) onde todos os sites são gerenciados pelo mesmo time
  • Sites de departamento universitário onde o controle centralizado é realmente desejado
  • Espelhos dev/staging/production para o mesmo projeto
  • Redes de blogs onde o isolamento de conteúdo não é crítico

Se você tem 5-8 sites, um sysadmin competente, e você não precisa de isolamento de dados entre sites — Multisite é ok. Os problemas começam quando você tenta escalá-lo para dezenas ou centenas de locais.

WordPress Multisite Não é Multi-Site: Arquitetura que Escala para 500 Locais - arquitetura

A Arquitetura Que Realmente Escala para 500 Locais

Aqui está a abordagem alternativa que usamos na Social Animal para negócios multi-locação: uma arquitetura headless com Next.js no frontend e Supabase (PostgreSQL) no backend, usando Row-Level Security (RLS) para verdadeiro isolamento de dados.

A ideia central: em vez de duplicar tabelas para cada local, você tem um conjunto de tabelas com uma coluna location_id. Políticas de segurança em nível de banco de dados garantem que queries retornem apenas dados para o local autorizado. E em vez de 500 instalações WordPress separadas fingindo ser independentes, você tem um deployment de aplicação onde /locations/[slug] dinamicamente renderiza a página de cada local de uma linha do banco de dados.

Como Row-Level Security Realmente Funciona

-- Criar a tabela de locais
CREATE TABLE locations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  slug TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  address TEXT,
  phone TEXT,
  hours JSONB,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Criar a tabela de páginas com isolamento de local
CREATE TABLE pages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  location_id UUID REFERENCES locations(id),
  title TEXT NOT NULL,
  content JSONB,
  slug TEXT NOT NULL,
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Habilitar RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;

-- Política: gerentes de locação só podem ver páginas de seu próprio local
CREATE POLICY "location_isolation" ON pages
  FOR ALL
  USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));

-- Política: público pode ler páginas publicadas para qualquer local
CREATE POLICY "public_read" ON pages
  FOR SELECT
  USING (published = true);

Com essa configuração, um gerente de locação em Denver que de alguma forma cria uma query maliciosa fisicamente não pode acessar dados de Austin. O banco de dados força isso. Não a camada de aplicação. Não uma convenção de nomenclatura. O banco de dados em si.

Comparação de Arquitetura: Tabelas com Prefixo vs Segurança em Nível de Linha

Aqui está uma representação visual das duas arquiteturas:

Arquitetura WordPress Multisite:

┌─────────────────────────────────────────────┐
│        Banco de Dados MySQL Único            │
│                                             │
│  wp_posts          (site principal)         │
│  wp_options        (site principal)         │
│  wp_2_posts        (Denver)                 │
│  wp_2_options      (Denver)                 │
│  wp_3_posts        (Austin)                 │
│  wp_3_options      (Austin)                 │
│  wp_4_posts        (Seattle)                │
│  wp_4_options      (Seattle)                │
│  ... x 500 locais = 5.000+ tabelas         │
│                                             │
│  ⚠️  UM conjunto de credenciais DB           │
│  ⚠️  UM processo PHP acessa TODAS tabelas   │
│  ⚠️  ZERO isolamento em nível de BD         │
└─────────────────────────────────────────────┘

Arquitetura Next.js + Supabase:

┌─────────────────────────────────────────────┐
│     Banco de Dados PostgreSQL Único         │
│                                             │
│  locations    (500 linhas, uma por local)   │
│  pages        (conteúdo por local)          │
│  media        (imagens por local)           │
│  staff        (time por local)              │
│  reviews      (reviews por local)           │
│                                             │
│  ✅  Políticas RLS forçam isolamento        │
│  ✅  Usuário Denver NÃO PODE queryar Austin │
│  ✅  5 tabelas total, não 5.000             │
│  ✅  Índices padrão, planos de query ótimos │
└─────────────────────────────────────────────┘

Um banco de dados em ambos os casos. Mas o modelo de isolamento é fundamentalmente diferente. RLS é forçado no nível do engine PostgreSQL — não é algo que a aplicação possa contornar.

Fator WordPress Multisite Next.js + Supabase
Tabelas em 500 locais ~5.500+ ~5-15
Isolamento de dados Nenhum (convenção de nomenclatura apenas) RLS forçado por banco de dados
Superfície de vulnerabilidade Uma exploração = todos os sites Isolamento de auth por locação
Conflitos de plugin Interrupção em nível de rede N/A (sem arquitetura de plugin)
Adicionar um local Criar subsite + configurar Inserir linha de banco de dados
Remover um local Processo de extração complexo Deletar linhas com CASCADE
Mapeamento de domínio Plugin necessário, frágil Reescrita de middleware, nativa
Tempo de build/deploy N/A (PHP em runtime) ~30s build incremental
TTFB (médio, não-cacheado) 800ms-2s+ 50-150ms (edge)
Hosting mensal (500 sites) $200-800/mês (WP gerenciado) $25-75/mês (Supabase + Vercel)
Recuperação de comprometimento Remediação de rede completa Rodar chaves, redeploy

Implementação: Next.js + Supabase para Sites Multi-Locação

Aqui está como o roteamento funciona na prática com Next.js:

// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const supabase = createClient();
  const { data: locations } = await supabase
    .from('locations')
    .select('slug');
  
  return locations?.map(({ slug }) => ({ slug })) ?? [];
}

export default async function LocationPage({ 
  params 
}: { 
  params: { slug: string } 
}) {
  const supabase = createClient();
  
  const { data: location } = await supabase
    .from('locations')
    .select(`
      *,
      pages(*),
      staff(*),
      reviews(*, rating)
    `)
    .eq('slug', params.slug)
    .single();
  
  if (!location) notFound();
  
  return (
    <div>
      <h1>{location.name}</h1>
      <LocationHero location={location} />
      <LocationServices pages={location.pages} />
      <LocationTeam staff={location.staff} />
      <LocationReviews reviews={location.reviews} />
    </div>
  );
}

Adicionando um novo local? Insira uma linha:

INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
  'portland-or',
  'Portland, OR',
  '123 Burnside St, Portland, OR 97209',
  '(503) 555-0142',
  '{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);

Isso é tudo. O próximo build a pega. Ou se você estiver usando ISR (Incremental Static Regeneration), ela aparece dentro de sua janela de revalidação sem um build.

Removendo um local? DELETE FROM locations WHERE slug = 'portland-or'; Deletes em cascata lidam com o resto. Nenhum processo de extração de 4-8 horas.

Para domínios customizados por local, middleware Next.js lida limpo:

// middleware.ts
import { NextResponse } from 'next/server';

const DOMAIN_MAP: Record<string, string> = {
  'yourbrand-denver.com': '/locations/denver-co',
  'yourbrand-austin.com': '/locations/austin-tx',
  // ... carregado de edge config em produção
};

export function middleware(request: Request) {
  const hostname = new URL(request.url).hostname;
  const rewritePath = DOMAIN_MAP[hostname];
  
  if (rewritePath) {
    return NextResponse.rewrite(new URL(rewritePath, request.url));
  }
  
  return NextResponse.next();
}

Nenhum plugin. Nenhum sunrise.php dropin. Nenhuma regra de mapeamento frágil. Apenas uma reescrita em edge.

Caminho de Migração: Saindo do WordPress Multisite

Se você está atualmente em WordPress Multisite com 20+ locais, aqui está o caminho realista de migração:

Fase 1: Exportação de Dados (1-2 semanas)

Extraía conteúdo de cada subsite usando a WordPress REST API ou WP-CLI. Não tente manualmente remapear tabelas com prefixo. Use a API — ela abstrai o pesadelo de prefixo.

# Exporte todos os posts do subsite 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json

# Exporte toda a mídia
wp media list --url=example.com/location-23 --format=json > location-23-media.json

Fase 2: Design de Schema (1 semana)

Designe seu schema Supabase em torno de seu modelo de conteúdo real, não do modelo post/postmeta do WordPress. Este é o momento de corrigir anos de dívida de modelo de dados acumulada.

Fase 3: Migração de Conteúdo (1-2 semanas)

Escreva scripts de migração que transformem conteúdo WordPress em seu novo schema. Lide com dados serializados, shortcodes e blocos Gutenberg.

Fase 4: Build de Frontend (3-4 semanas)

Construa o frontend Next.js. Este é onde você vê os ganhos reais de performance. Páginas que levavam 1,5 segundos no WordPress agora carregam em menos de 200ms.

Fase 5: DNS Cutover (1 dia)

Aponte seus domínios para a nova infraestrutura. Mantenha a rede antiga rodando como backup somente-leitura por 30 dias.

Para negócios que precisam de ajuda com esse processo de migração, documentamos nossa abordagem em nossa página de desenvolvimento de CMS headless. Já fizemos migrações suficientes para saber onde os corpos estão enterrados.

Números Reais: Comparação de Performance e Custo

Aqui estão dados de uma migração real que completamos em Q1 2025 — uma rede de prática odontológica com 34 locais:

Métrica WordPress Multisite (Antes) Next.js + Supabase (Depois)
TTFB Médio 1.240ms 89ms
Largest Contentful Paint 3.8s 1.1s
Custo de hosting mensal $347/mês (WP Engine) $45/mês (Vercel Pro + Supabase Pro)
Tempo para adicionar novo local 2-3 horas (setup manual) 15 minutos (inserir linha + conteúdo)
Tempo para atualizar todos os locais Atualizar plugin + rezar git push
Taxa de aprovação de Core Web Vitals 12 de 34 locais 34 de 34 locais
Incidentes de segurança (12 meses) 3 0

A redução de custo de hosting por si só pagou a migração dentro de 8 meses. As melhorias de performance impulsionaram aumentos mensuráveis em rankings de busca local para 28 de 34 locais em 90 dias.

Se você está avaliando custos para sua própria rede, nossa página de preços tem breakdowns transparentes para projetos multi-locação.

FAQ

WordPress Multisite é bom para gerenciar múltiplos locais?

Para um pequeno número de locais (menos de 10) com gerenciamento centralizado, WordPress Multisite pode funcionar. Mas não foi projetado para negócios multi-locação que precisam de operação independente, isolamento de dados ou alta performance em escala. A arquitetura de banco de dados compartilhado cria problemas de segurança, performance e operacionais que se agravam com cada local que você adiciona.

Quais são os maiores problemas com WordPress Multisite?

Os sete maiores problemas são: superfície de vulnerabilidade compartilhada (uma exploração atinge todos os sites), multiplicação de conflito de plugin (um conflito derruba cada site), degradação de performance não-linear, processo de migração/extração de pesadelo, zero isolamento de dados em nível de banco de dados, gargalo de Super Admin para todas as mudanças administrativas, e mapeamento de domínio frágil. Esses problemas são arquiteturais — não podem ser corrigidos com plugins ou melhor hosting.

WordPress Multisite pode lidar com 100+ sites?

Tecnicamente, sim. Praticamente, fica muito doloroso após 30-50 sites. Em 100 sites você está lidando com 1.100+ tabelas de banco de dados em uma instância MySQL única, degradação severa do planejador de query e complexidade operacional que requer staff de DevOps dedicado. Em 500 sites, é um não-iniciador para a maioria dos ambientes de hosting.

Qual é a melhor alternativa para WordPress Multisite para múltiplos locais?

Uma arquitetura headless usando Next.js ou Astro para o frontend com um banco de dados PostgreSQL (como Supabase) usando Row-Level Security fornece verdadeiro isolamento de dados, dramaticamente melhor performance, custos de hosting mais baixos e gerenciamento trivial de locais. Cada local é uma linha de banco de dados, não uma instalação WordPress inteira.

Como você migra de WordPress Multisite para uma arquitetura headless?

A abordagem mais segura é extrair conteúdo via WordPress REST API ou WP-CLI em vez de tentar manualmente remapear tabelas de banco de dados com prefixo. Exporte conteúdo por subsite, designe um schema limpo em seu banco de dados alvo, escreva scripts de transformação, construa o novo frontend e corte DNS. Planeje 6-10 semanas total para uma rede com 20+ sites.

WordPress Multisite afeta SEO?

Indiretamente, sim. A degradação de performance do WordPress Multisite leva a carregamentos de página mais lentos, que prejudicam pontuações de Core Web Vitals. Google confirmou que sinais de experiência de página influenciam rankings. Em nossos dados de migração, 82% dos locais viram rankings de busca local melhorados dentro de 90 dias de mover para uma arquitetura headless com TTFB sub-200ms.

WordPress Multisite é seguro para dados empresariais?

Não, se você define segurança como incluindo isolamento de dados entre locais. WordPress Multisite usa um banco de dados com um conjunto de credenciais. Uma SQL injection em qualquer subsite pode acessar dados de todo outro subsite. Para negócios sujeitos a HIPAA, SOC 2, PCI DSS ou requisitos de conformidade similares, a falta de isolamento em nível de banco de dados é uma responsabilidade significativa.

Quanto custa rodar WordPress Multisite vs uma alternativa headless?

Hosting WordPress gerenciado para Multisite típicamente custa $200-800/mês dependendo do número de sites e níveis de tráfego (planos Multisite WP Engine começam em $240/mês para seu tier Growth em 2026). Uma setup headless comparável em Vercel Pro ($20/mês) mais Supabase Pro ($25/mês) lida com o mesmo tráfego por uma fração do custo. O investimento inicial de build é maior para a abordagem headless, mas custos operacionais mensais são significativamente mais baixos. Sinta-se livre para entrar em contato se quiser uma comparação de custo específica para o tamanho de sua rede.