A proposta soa eficiente: em vez de manter dez instalações do WordPress, mantenha uma que serve dez sites. Uma atualização, um backup, um ambiente.

Em alguns cenários, isso é exatamente o que resolve o problema. Em outros, cria uma dependência entre sites que deveriam ser independentes — e a descoberta acontece tarde, porque sair de um multisite é consideravelmente mais trabalhoso que entrar.

Este guia explica o que efetivamente é compartilhado, o que permanece isolado e em quais situações a arquitetura compensa.

O que é compartilhado e o que não

A tabela que resolve a maior parte das dúvidas:

Elemento	Compartilhado	Consequência
Núcleo do WordPress	Sim	Uma atualização para todos
Plugins instalados	Sim	Mesma versão em toda a rede
Temas instalados	Sim	Mesmo conjunto disponível
Ativação de plugins	Não	Cada site ativa o que usa
Conteúdo	Não	Posts e páginas isolados
Usuários	Parcialmente	Base comum, permissões por site
Configurações	Não	Cada site tem as suas
Banco de dados	Mesmo banco	Tabelas separadas por site
Arquivos enviados	Mesmo servidor	Pastas separadas por site

Duas linhas explicam a maior parte dos problemas e das vantagens.

Plugins e temas são instalados uma vez para a rede inteira. Isso é a origem da eficiência — e também da rigidez: se um cliente precisa de um plugin que outro não pode ter, ele estará instalado para todos, ainda que ativado só onde é necessário.

O banco é o mesmo, com tabelas separadas por site. Isso significa que o crescimento de um site afeta o banco que todos usam, e que operações de manutenção alcançam a estrutura inteira.

O que a arquitetura resolve bem

As vantagens reais, sem exagero:

Manutenção centralizada. Uma atualização do núcleo, de um plugin ou de um tema vale para todos os sites. Em uma rede com dezenas de sites, isso é uma economia de tempo substancial.

Consistência. Todos os sites rodam as mesmas versões, o que elimina a heterogeneidade que torna a manutenção imprevisível — o problema tratado no artigo sobre hospedagem WordPress para agências.

Gestão de usuários. Uma pessoa pode ter acesso a vários sites da rede sem contas duplicadas, com permissões diferentes em cada um.

Recursos compartilhados. Um tema desenvolvido internamente fica disponível para todos os sites, sem precisar ser instalado em cada um.

Custo de infraestrutura. Uma instalação consome menos que várias, especialmente em sites pequenos.

O que a arquitetura complica

Com a mesma clareza, porque é aqui que as decisões erradas aparecem:

Atualizações afetam todos. Um plugin atualizado que quebra um site quebra em todos que o usam, ao mesmo tempo. Não existe atualizar um e observar antes de seguir.

Plugins incompatíveis não podem conviver. Se um site precisa de um plugin que conflita com outro necessário em um site diferente, não há solução limpa.

Um problema pode derrubar a rede. Uma falha no núcleo, no banco ou no servidor afeta todos os sites simultaneamente.

Separar um site é trabalhoso. Extrair as tabelas de um site da rede, migrar arquivos e ajustar referências é um projeto — bem mais complexo que mover uma instalação independente.

Alguns plugins não funcionam bem em rede. Nem todo plugin é construído considerando esse cenário, e o comportamento em rede pode ser inesperado.

Backup e restauração ficam menos granulares. Restaurar um único site exige extrair a parte dele de um backup que cobre a rede inteira.

O item da separação é o que mais gera arrependimento: entrar em um multisite é simples; sair não é. Essa assimetria deveria pesar na decisão inicial mais do que costuma pesar.

A questão dos endereços

Uma decisão que precisa ser tomada na instalação e é difícil de reverter.

Uma rede pode organizar os sites de duas formas: em subdomínios ou em subpastas do domínio principal. Há também a possibilidade de cada site ter domínio próprio, com configuração adicional.

O que considerar:

• Subpastas funcionam bem quando os sites são partes de um mesmo conjunto, e compartilham a autoridade do domínio principal para busca.
• Subdomínios dão mais separação e são adequados quando os sites são entidades distintas, ainda que da mesma organização.
• Domínios próprios são necessários quando cada site precisa de identidade completamente independente — e é o cenário mais comum em carteiras de clientes.

A escolha entre as duas primeiras é feita na instalação e alterá-la depois é complexo, envolvendo mudança de estrutura de endereços e redirecionamentos. Vale decidir com calma.

E vale a ressalva de SEO: cada site da rede tem a própria autoridade, e o multisite não faz com que um transfira reputação para outro automaticamente. A vantagem de subpastas nesse aspecto é a mesma de qualquer subpasta, como tratado no artigo sobre onde hospedar landing pages.

Quando compensa

Os cenários em que a arquitetura é a resposta certa:

• Sites de uma mesma organização: filiais, unidades, campi, regionais. Eles devem mesmo se comportar de forma parecida.
• Redes editoriais com marcas ou seções que compartilham estrutura e equipe.
• Portais de franquias, com identidade comum e conteúdo local.
• Sites institucionais por departamento dentro de uma mesma empresa.
• Projetos com muitos sites pequenos e idênticos, criados a partir de um modelo comum.

O fio condutor: todos são sites do mesmo dono, com necessidades semelhantes e sem exigência de independência. É exatamente o cenário em que o compartilhamento é vantagem em vez de restrição.

Um sinal adicional: quando os sites são criados e removidos com frequência, a rede simplifica muito — criar um site novo em uma rede existente leva segundos.

Quando evitar

Com a mesma firmeza:

Carteira de clientes distintos. É o caso mais comum de uso equivocado. Clientes diferentes têm necessidades diferentes de plugins, precisam de isolamento de dados e, principalmente, vão embora um dia — e separar um site da rede é um projeto.

Quando os sites têm necessidades técnicas divergentes. Um cliente com loja virtual e outro com site institucional simples não se beneficiam do mesmo conjunto de plugins.

Quando a independência é requisito. Se um site não pode sair do ar por causa de outro, eles não deveriam compartilhar instalação.

Quando há exigência de isolamento de dados. Dados de clientes diferentes no mesmo banco podem contrariar compromissos contratuais.

Quando são poucos sites. Abaixo de um punhado, a economia de manutenção não compensa a complexidade adicional.

Sobre o primeiro item, a formulação que vale como regra: multisite é para sites de um mesmo dono; carteira de clientes pede instalações independentes, ainda que no mesmo servidor. A padronização que uma agência busca pode ser obtida com processo e ferramentas de gestão, sem acoplar os sites.

Alternativas que atendem o mesmo objetivo

Se o objetivo é reduzir o trabalho de manter vários sites, existem caminhos menos acoplados:

1. Instalações independentes no mesmo servidor, com padronização de versões, plugins e rotinas. Entrega boa parte do ganho sem o acoplamento.
2. Ferramentas de gestão centralizada, que administram várias instalações de um painel único.
3. Processo documentado de criação e manutenção, que é o que realmente reduz tempo — e funciona em qualquer arranjo.
4. Um modelo base de instalação, replicado em cada site novo, garantindo consistência desde o início.

A primeira alternativa merece atenção porque resolve o problema real de quem administra carteiras: a heterogeneidade é o que custa caro, não o número de instalações. Dez instalações independentes com o mesmo conjunto de plugins e a mesma rotina são bem mais fáceis de manter que dez ambientes diferentes — e não criam dependência entre elas.

Se você já tem um multisite

Para quem herdou ou criou uma rede e avalia se vale manter:

Sinais de que está funcionando: os sites têm necessidades semelhantes, as atualizações raramente quebram algo, ninguém precisa de plugin exclusivo, e não há previsão de separar sites.

Sinais de que vale reconsiderar: pedidos de plugins que não podem ser instalados por afetarem outros, sites com necessidades divergentes crescendo, clientes que podem sair, ou uma atualização que já derrubou vários sites de uma vez.

Se a decisão for sair, vale saber: é um projeto por site, envolvendo extração de tabelas, migração de arquivos, ajuste de referências e redirecionamentos. Fazer isso de forma planejada, um site por vez, é bem melhor que fazer sob pressão quando um cliente pede a saída.

Conclusão

Multisite compartilha núcleo, plugins e temas entre vários sites, e isso é vantagem quando os sites devem mesmo se comportar de forma parecida — filiais, unidades, redes editoriais, franquias. Nesses casos, a manutenção centralizada economiza tempo real.

O mesmo compartilhamento vira restrição quando os sites precisam ser independentes: uma atualização afeta todos, plugins incompatíveis não convivem e um problema derruba a rede inteira.

E a assimetria que deveria pesar mais na decisão: entrar em um multisite é simples, sair é um projeto por site. Para carteiras de clientes, instalações independentes padronizadas entregam boa parte do ganho sem esse custo. Conheça o Cloud Server para WordPress da TBF Host e avalie o ambiente adequado ao seu conjunto de sites.

Perguntas frequentes

O que o WordPress Multisite compartilha entre os sites?

Núcleo, plugins e temas instalados são compartilhados — uma atualização vale para todos. Conteúdo, configurações e permissões são isolados por site. O banco é o mesmo, com tabelas separadas, e os arquivos ficam no mesmo servidor, em pastas distintas.

Multisite serve para uma agência gerenciar sites de clientes?

Em geral não. Clientes distintos têm necessidades diferentes de plugins, precisam de isolamento de dados e um dia vão embora — e separar um site da rede é um projeto. A regra prática é que multisite serve para sites de um mesmo dono; carteira de clientes pede instalações independentes.

Quais as principais desvantagens do Multisite?

Atualizações afetam todos os sites ao mesmo tempo, plugins incompatíveis não podem conviver, um problema no núcleo ou no banco derruba a rede inteira, separar um site é trabalhoso, alguns plugins não funcionam bem em rede e backup e restauração ficam menos granulares.

Quando o Multisite compensa?

Quando os sites são de uma mesma organização e devem se comportar de forma parecida: filiais, unidades, campi, redes editoriais, franquias e sites institucionais por departamento. Também quando sites são criados e removidos com frequência, já que criar um novo na rede leva segundos.

Subdomínio ou subpasta no Multisite?

Subpastas funcionam quando os sites são partes de um mesmo conjunto; subdomínios dão mais separação entre entidades distintas da mesma organização; domínios próprios são necessários quando cada site precisa de identidade independente. A escolha entre as duas primeiras é feita na instalação e é complexa de reverter.

É difícil separar um site de um Multisite?

É um projeto: envolve extrair as tabelas daquele site, migrar arquivos, ajustar referências e configurar redirecionamentos. Bem mais complexo que mover uma instalação independente. Essa assimetria — entrar é simples, sair não — deveria pesar mais na decisão inicial do que costuma pesar.

Existe alternativa ao Multisite para reduzir trabalho de manutenção?

Sim: instalações independentes no mesmo servidor, com padronização de versões, plugins e rotinas. O que custa caro em carteiras de sites é a heterogeneidade, não o número de instalações — dez ambientes iguais são muito mais fáceis de manter que dez diferentes, sem criar dependência entre eles.

Como saber se meu Multisite ainda faz sentido?

Vale reconsiderar quando aparecem pedidos de plugins que não podem ser instalados por afetarem outros sites, quando as necessidades entre eles divergem, quando há clientes que podem sair da rede, ou quando uma atualização já derrubou vários sites de uma vez.