Gerir mais de 100 websites com WordPress Multisite

Gerir meia dúzia de websites é fácil. Gerir mais de 100 websites para um grupo global ou uma rede de franchising é um problema logístico, a menos que use a arquitetura certa. Em 2026, o WordPress Multisite continua a ser a forma nativa de gerir uma grande frota de sites a partir de uma única instalação WordPress.

Eis como desenhar, governar e escalar uma rede de 100 sites.

Resposta curta: o WordPress Multisite continua a funcionar muito bem em 2026 quando precisa de controlo centralizado, código partilhado e uma governação coerente em muitos sites. Passa a ser a escolha errada quando precisa de isolamento rigoroso dos dados, de uma infraestrutura radicalmente diferente para cada site ou de autonomia total para cada equipa.

Saiba mais sobre o desenvolvimento WordPress empresarial na WPPoland.

#Atualizar 100 sites WordPress a partir de um só código

A principal vantagem do Multisite é ter uma única base de código central para gerir. Tudo o resto neste guia assenta nisso.

#Atualizações centralizadas

Quando é lançada uma correção de segurança, atualiza-a uma vez ao nível da rede e o novo código fica ativo nos 100 sites no mesmo instante. Com 100 instalações separadas, a mesma correção significa 100 atualizações, e cada site que fica à espera permanece exposto durante mais tempo.

A esta escala há um pormenor que conta: uma atualização do core também pode alterar o esquema da base de dados. O código é partilhado, mas cada site tem as suas próprias tabelas, por isso, depois de uma atualização do core, o WordPress pede-lhe que execute Actualizar a rede. O manual da Administração da rede descreve-o assim: a funcionalidade Actualizar a rede «irá percorrer cada site, cinco de cada vez, e garantir que todas as alterações à base de dados são aplicadas» (tradução própria). Os sites desativados são ignorados e recebem a atualização quando um administrador desse site inicia sessão depois da reativação.

#Biblioteca partilhada

Temas e plugins são partilhados. Se quiser atualizar as cores da marca corporativa, altera um tema e a alteração reflete-se em todos os sites regionais que o utilizam.

Gerir os recursos partilhados:

• Tema corporativo: um tema principal (parent theme), com as variações de cada marca como temas filhos
• Plugins essenciais: SEO, segurança, cache e analítica instalados uma vez pelo Super Admin
• Plugins obrigatórios (must-use): os ficheiros em mu-plugins são carregados em todos os sites e não podem ser desativados site a site

#Coerência da marca e o seu limite

Tipos de letra, cores e espaçamentos definidos no theme.json do tema aplicam-se a todos os sites que usam esse tema. O limite está na base de dados: o manual observa que «as alterações de estilo feitas no Editor do site afetam apenas sites individuais» (tradução própria), porque ficam guardadas nas tabelas desse site. Se a coerência da marca for importante, mantenha o sistema de design nos ficheiros do tema, sob controlo de versões, e restrinja quem pode editar estilos no Editor do site.

#Como criar uma rede WordPress Multisite

O procedimento oficial é curto, e o guia Create a Network define a ordem:

1. Faça uma cópia de segurança da base de dados e dos ficheiros, verifique que as ligações permanentes amigáveis funcionam e desative todos os plugins ativos.
2. Se o WordPress correr a partir do seu próprio diretório, configure isso antes de ativar o Multisite.
3. Adicione define( 'WP_ALLOW_MULTISITE', true ); ao wp-config.php, acima da linha que indica o fim da edição. Isto ativa Ferramentas > Configuração da rede.
4. No ecrã Configuração da rede, escolha subdomínios ou subdiretórios e instale.
5. Adicione as linhas que o WordPress gera ao wp-config.php e ao .htaccess e depois inicie sessão novamente.

O manual de administração da rede acrescenta um ponto que poupa tempo em stacks modernas: o WordPress consegue gerar regras de reescrita para Apache e IIS, «mas não consegue gerar a configuração do Nginx» (tradução própria). Em Nginx, as regras do Multisite são escritas por si, a partir dos exemplos documentados.

Na linha de comandos, o WP-CLI faz a mesma conversão com wp core multisite-convert, que cria as tabelas do Multisite e adiciona as constantes ao wp-config.php. Acrescente --subdomains para uma rede baseada em domínios.

#Multisite com subdomínios ou com subdiretórios

A escolha decide o aspeto dos URLs dos sites e aquilo que o servidor tem de suportar. O guia de preparação da rede enumera as regras:

Não é possível criar uma rede quando o endereço do WordPress usa uma porta diferente de 80 ou 443. Mudar de tipo mais tarde é possível, mas pesado: alterar SUBDOMAIN_INSTALL e as regras de reescrita, segundo o mesmo guia, «não migra os endereços dos sites existentes nem configura DNS, virtual hosts, certificados TLS, redirecionamentos e cookies» (tradução própria). Num plano de 100 sites, decida uma vez e teste em staging.

#WordPress multi-network e sharding da base de dados

Para organizações que já ultrapassaram uma única rede, as configurações multi-network agrupam os sites em várias redes dentro de uma só instalação. O core suporta o modelo de dados, mas a interface de gestão vem de plugins como o WP Multi Network.

#Agrupamento regional

Pode ter uma rede para a Europa, uma rede para as Américas e uma rede para a região APAC, todas dentro de uma única instalação. Cada rede tem as suas próprias definições e a sua própria lista de plugins ativados na rede.

No WP-CLI, cada rede tem um ID numérico. wp site create --network_id=2 adiciona um site à segunda rede e wp site list --network=2 lista apenas os sites dessa rede.

#Sharding com um drop-in db.php

Para evitar que a base de dados se torne um gargalo, um drop-in db.php como o HyperDB distribui as tabelas dos sites por vários servidores de base de dados e envia as leituras para réplicas.

Estratégias de sharding:

• Por região: cada rede regional tem o seu próprio servidor de base de dados
• Por volume: os sites com mais tráfego recebem servidores dedicados
• Híbrida: uma combinação das duas, com base na carga medida

#O que é partilhado e o que é de cada site

O manual de administração acrescenta ainda que ativar um plugin na rede «não altera o local onde o plugin guarda os seus dados» (tradução própria). Se as definições são globais da rede ou de cada site depende da forma como cada plugin está escrito, por isso confirme isso antes de aprovar um plugin para a rede.

#SSO e funções de utilizador no WordPress Multisite

Com 100 sites, é provável que tenha centenas de utilizadores. Não é possível geri-los à mão.

#Integração de SSO

Integre o seu Multisite com um fornecedor de identidade como o Okta ou o Microsoft Entra ID (antigo Azure AD). Quando um colaborador sai da empresa, o acesso aos 100 websites é revogado num único sítio. Isso fecha a lacuna das contas órfãs, uma porta de entrada comum em sites antigos.

#Controlos do Super Admin

Defina que sites podem ativar que plugins. Uma equipa de marketing regional não deve poder instalar um plugin arriscado que possa deitar abaixo a rede inteira. O WordPress impõe parte disto por omissão: numa rede, segundo o manual, os administradores de site «não podem instalar novos temas ou plugins e não podem editar os perfis dos utilizadores do seu site» (tradução própria). Só o Super Admin o pode fazer.

Hierarquia de funções recomendada:

Funções personalizadas, como um gestor de SEO com acesso apenas aos metacampos, são possíveis com um plugin de funções ou com código, e são definidas site a site.

#Acesso aos plugins para administradores de site

Por omissão, os administradores de site nem sequer veem o ecrã Plugins. O ecrã Opções da rede tem uma opção Opções do menu que o ativa. Mesmo assim, os administradores de site só podem ativar ou desativar plugins que o Super Admin instalou; os plugins ativados na rede aparecem como Activado na rede, sem opção para os desativar.

Um plugin também pode declarar Network: true no seu cabeçalho, o que o torna exclusivo da rede.

#Temas por site

Ativar um tema na rede não muda nenhum site para esse tema. Apenas o torna disponível. Um tema também pode ser ativado para um único site a partir do ecrã Editar site, separador Temas. Os novos sites recebem o tema predefinido mais recente, a menos que defina WP_DEFAULT_THEME no wp-config.php com o nome da pasta do seu tema corporativo, o que poupa um passo manual em cada novo site.

#Como distribuir conteúdo numa rede WordPress Multisite

Os sites de uma rede não partilham conteúdo por omissão. O manual compara uma rede a «uma versão em miniatura do WordPress.com» (tradução própria) e remete para plugins para a partilha. Planeie a distribuição de conteúdo como uma funcionalidade que acrescenta, não como algo que já vem incluído.

#Publicar um comunicado em todos os sites

Os plugins de difusão (broadcast) permitem publicar uma vez um comunicado corporativo global e copiá-lo para os 100 sites. Os candidatos típicos são comunicados de imprensa, novidades de produto, avisos de segurança e de conformidade e campanhas sazonais.

#Pesquisa global

Use o Elasticsearch (através do ElasticPress) para oferecer uma barra de pesquisa capaz de encontrar conteúdo em todos os sites da rede. A pesquisa nativa do WordPress consulta as tabelas de um único site.

#Ler conteúdo de outros sites

Cada site expõe a sua própria REST API, por isso um site central pode ir buscar artigos aos sites regionais por HTTP. Dentro do PHP, switch_to_blog() e restore_current_blog() permitem ao código ler diretamente as tabelas de outro site, e é assim que funciona a maioria dos plugins de distribuição de conteúdo.

#Lista de verificação de desempenho do WordPress Multisite para mais de 100 sites

#Redis para Multisite

• Chaves por site: a cache de objetos identifica os dados pelo ID do site, por isso os sites não se sobrepõem na cache uns dos outros
• Grupos globais: utilizadores e opções da rede ficam em cache uma única vez para toda a rede
• Alertas de memória: um site grande pode encher a cache partilhada

#Limites de carregamento por site

As Opções da rede também controlam o armazenamento. Por omissão, o espaço de carregamento de cada site está limitado a 50 MB e o tamanho máximo de cada ficheiro carregado a 1500 KB, ambos editáveis. Os tipos de ficheiro permitidos são uma lista da rede; acrescentar um tipo a essa lista «NÃO irá funcionar» (tradução própria) se ele não for também permitido através do filtro upload_mimes. Com 100 sites, defina estes limites de forma deliberada, em vez de os aumentar a cada reclamação.

#Automatizar o WordPress Multisite com WP-CLI e CI/CD

#Implementações automatizadas

Numa rede com mais de 100 sites, as implementações manuais não escalam:

• Pipeline de CI/CD: cada alteração ao código passa por testes automáticos em staging
• Implementação gradual: quando gere várias redes ou instalações, envie primeiro para o grupo mais pequeno
• Reversão: mantenha a versão anterior pronta a ser reposta

#WP-CLI à escala

O WP-CLI é a principal ferramenta para gerir uma rede a partir da linha de comandos. Os comandos abaixo vêm da referência oficial de comandos do WP-CLI:

# Atualizar o core uma vez e depois executar a atualização da base de dados em todos os sites
wp core update
wp core update-db --network

# Ativar um plugin para toda a rede
wp plugin activate my-plugin --network

# Ativar um plugin apenas em cada site da rede 2
wp site list --network=2 --field=url | xargs -I {} wp plugin activate my-plugin --url={}

# Contar os artigos publicados em cada site
wp site list --field=url | while read url; do
  echo "$url $(wp post list --post_type=post --post_status=publish --format=count --url="$url")"
done

#Comandos do ciclo de vida de um site

Arquivar e desativar são operações reversíveis, e na prática a Administração da rede trata o arquivamento da mesma forma que a desativação. Marcar como spam torna o site indisponível para todos. Eliminar remove o site, por isso use --keep-tables nos seus scripts até ter uma cópia de segurança verificada.

#Monitorização e alertas por site

Cada site da rede precisa dos seus próprios alertas:

• Disponibilidade por site (o site principal pode estar no ar enquanto um subsite está em baixo)
• Core Web Vitals por site
• Erros de PHP por site (um plugin ativado num site pode causar erros apenas nesse site)
• Crescimento da base de dados por site

#Como mapear um domínio próprio para um site multisite

O mapeamento de domínios é nativo desde o WordPress 4.5, de acordo com o guia de mapeamento de domínios. Os passos:

1. Aponte o DNS do domínio para o servidor e estacione-o no domínio principal da rede.
2. Instale um certificado TLS para cada domínio; o guia recomenda SNI para os domínios adicionais.
3. Na Administração da rede, abra Sites, edite o site e defina o Endereço do site (URL) como o domínio completo, por exemplo https://example.com.
4. Se o início de sessão falhar com um erro de cookies, adicione define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); ao wp-config.php.

Com 100 marcas em 100 domínios, a renovação dos certificados torna-se a tarefa recorrente, por isso automatize-a no servidor.

#Quando não usar o multisite

O Multisite nem sempre é a resposta. O próprio manual avisa: se planeia sites que «partilham dados, ou partilham utilizadores» de forma fortemente interligada, «uma rede multisite pode não ser a melhor solução» (tradução própria). Evite-o se:

1. Requisitos únicos: o site A precisa de uma configuração de servidor completamente diferente ou de uma versão de PHP diferente da do site B.
2. Reputação do IP: se um site da rede for considerado fonte de spam, pode afetar a reputação de todos os outros sites no mesmo IP. Isto pesa sobretudo nos sites que dependem da entregabilidade do email.
3. Isolamento dos dados: um cliente exige, por razões legais, que os seus dados estejam numa base de dados completamente separada.
4. Autonomia das equipas: cada equipa precisa de escolher e instalar os seus próprios plugins.
5. Um site dominante: um único site concentra a maior parte do tráfego e precisa da sua própria infraestrutura.

#Alternativas ao Multisite

#Como migrar para o WordPress Multisite passo a passo

#Fase 1: auditoria

• Inventário de todos os sites existentes
• Análise dos plugins e temas em uso e da compatibilidade de cada um com o Multisite
• Requisitos de dados e de isolamento
• Integrações de cada site

#Fase 2: arquitetura

• Estrutura da rede (uma rede ou várias)
• Subdomínio ou subdiretório, decidido uma única vez
• Estratégia de base de dados
• Funções e permissões

#Fase 3: implementação

• Ambiente Multisite em staging
• Migração do conteúdo site a site
• SSO e governação
• Cache e CDN

#Fase 4: otimização

• Testes de carga
• Afinação da cache e da base de dados
• Formação para os administradores da rede
• Procedimentos escritos (runbooks) para atualizações e novos sites

O manual avisa que mudar um Multisite de sítio «é mais complicado do que mudar uma instalação única» (tradução própria), por isso teste o caminho de migração em staging antes da passagem para produção.

#Conclusão

O WordPress Multisite é uma ferramenta sólida para quem gere uma frota de sites. Oferece a eficiência da gestão centralizada com a flexibilidade da criação de conteúdo descentralizada.

Se está a planear escalar de 10 sites para 100 ou 1000, desenhar corretamente a arquitetura do seu Multisite desde o primeiro dia é a decisão técnica mais importante que vai tomar.

Uma rede desta dimensão falha quase sempre no mesmo sítio: plugins partilhados que um subsite não aguenta, tabelas que crescem sem vigilância e um processo de atualização que ninguém documentou. Se quiser desenhar essa arquitetura antes de crescer, conheça o nosso trabalho de desenvolvimento em WordPress Multisite.

#Recursos relacionados

• Desenvolvimento WordPress
• Otimização da velocidade do WordPress
• Auditoria de segurança WordPress
• Manutenção WordPress
• Desenvolvimento WooCommerce
• Contactar a WPPoland