Toda agência que cresce chega a um ponto em que a hospedagem dos clientes deixa de ser um detalhe operacional e vira uma decisão de negócio.
Dez sites em dez contas diferentes, cada uma com seu painel, sua fatura e sua senha, funcionam. Quarenta, não. A partir de certo volume, o tempo gasto entrando em painéis diferentes, aplicando a mesma atualização quarenta vezes e conferindo se o backup rodou passa a custar mais do que a diferença entre qualquer plano.
Este artigo trata das formas de estruturar isso — concentrar, separar ou combinar — com os critérios de custo, risco e operação de cada arranjo. E com a parte que raramente é discutida: o que acontece quando um cliente sai.
Os três arranjos possíveis
Na prática, agências estruturam a hospedagem de uma destas formas:
1. Conta por cliente, contratada pelo cliente
Cada cliente contrata a própria hospedagem, e a agência apenas acessa. A propriedade é do cliente, a fatura também.
A favor: nenhum custo de infraestrutura para a agência, nenhuma responsabilidade contratual pela disponibilidade, saída limpa quando o cliente troca de fornecedor.
Contra: ambientes heterogêneos, com provedores, versões e recursos diferentes em cada site. Isso multiplica o trabalho de manutenção e torna qualquer padronização impossível.
2. Conta por cliente, contratada pela agência
A agência contrata cada hospedagem e repassa o custo, com ou sem margem.
A favor: ambiente padronizado, controle total, relação comercial única com o provedor.
Contra: a agência assume a responsabilidade pela disponibilidade e passa a ter contas a gerenciar, faturas a repassar e — o ponto crítico — a propriedade dos ambientes em seu nome.
3. Ambiente consolidado
Vários sites em um único servidor administrado pela agência.
A favor: custo por site cai conforme a carteira cresce, ambiente totalmente padronizado, operações repetidas feitas uma vez.
Contra: um problema no servidor afeta todos os clientes ao mesmo tempo, e a agência assume integralmente a operação de infraestrutura.
Não existe arranjo correto universal. O que existe é adequação ao tamanho da carteira, ao perfil dos clientes e à capacidade técnica da agência.
O ponto de virada
A pergunta prática: a partir de quando consolidar compensa?
A conta tem dois lados, e o primeiro é o mais fácil de esquecer.
O custo de infraestrutura é direto: some o que se paga hoje em contas separadas e compare com o custo de um servidor mais a administração dele.
O custo operacional é o que decide. Estime quanto tempo se gasta por mês com: entrar em painéis diferentes, aplicar atualizações site a site, verificar backups, atender chamados de ambientes que se comportam de formas distintas e diagnosticar problemas em configurações não padronizadas.
Multiplique isso pelo custo da hora da equipe. Em carteiras médias, esse número costuma superar a diferença de infraestrutura com folga — e é por isso que a consolidação raramente é decidida por preço de plano.
Há também um custo que não aparece em planilha: ambientes heterogêneos impedem processos. Não é possível criar uma rotina de manutenção repetível quando cada site se comporta de um jeito. A padronização é o que permite transformar manutenção em processo, e processo é o que permite crescer sem contratar proporcionalmente.
O risco concentrado
A contrapartida da consolidação precisa ser dita com a mesma clareza.
Em contas separadas, um problema afeta um cliente. Em um ambiente consolidado, um problema afeta todos ao mesmo tempo — e a agência é o único ponto de contato para todos eles.
Isso muda a natureza de alguns itens que antes eram opcionais:
- Backup com restauração testada deixa de ser boa prática e vira requisito contratual implícito.
- Monitoramento com alerta precisa existir, porque descobrir pelo cliente é inaceitável quando são quarenta clientes.
- Plano de resposta a incidente com responsável definido e canal de comunicação com os clientes.
- Ambiente de homologação para testar antes de aplicar em produção — em escala, uma atualização ruim propaga o erro.
- Isolamento entre sites, para que um site comprometido não alcance os vizinhos.
O último item merece atenção: em um ambiente consolidado, a segurança de cada site passa a ser um problema coletivo. Um cliente que instala um plugin pirata expõe potencialmente toda a carteira, dependendo de como o ambiente está isolado.
Os requisitos de operação de um ambiente próprio estão detalhados no artigo sobre Cloud Server gerenciado ou autogerenciado — e a decisão entre esses dois modelos pesa mais para uma agência do que para um cliente único, porque a indisponibilidade afeta a reputação com muitos clientes de uma vez.
A pergunta que quase ninguém faz: e quando o cliente sai?
Este é o ponto mais consequente do artigo e o menos discutido em conteúdo sobre o tema.
Clientes saem. Trocam de agência, internalizam o marketing, encerram operações. E o arranjo escolhido determina o quanto isso é simples.
Em conta contratada pelo cliente, a saída é trivial: revogam-se os acessos e pronto.
Em conta contratada pela agência, é preciso transferir a conta ou migrar o site — e, se não houver clareza contratual, começa uma conversa desconfortável sobre a quem pertence o quê.
Em ambiente consolidado, o site precisa ser extraído do servidor e migrado para onde o cliente indicar. Isso é trabalho, e precisa estar previsto.
Três medidas evitam atrito:
- Definir em contrato de quem é o domínio, de quem é a hospedagem, de quem é o código e o que acontece no encerramento.
- Manter o domínio sempre no nome do cliente, com a agência como acesso delegado. Domínio em nome da agência é a origem mais comum de conflito, e o mais fácil de evitar.
- Prever a extração no contrato: prazo, formato de entrega e se há custo associado.
O item 2 vale como regra fixa, independentemente do arranjo. Um domínio registrado em nome da agência dá a ela um poder que, na prática, ninguém quer exercer — e que envenena a relação no momento da saída.
O que padronizar
Padronização é o que transforma manutenção em processo. O que vale fixar em toda a carteira:
- Versão de PHP e de banco de dados, dentro do suporte.
- Conjunto base de plugins — segurança, backup, cache, SEO —, com as mesmas ferramentas em todos os sites.
- Estrutura de usuários e permissões, com acessos nomeados e nível mínimo necessário.
- Rotina de atualização, com dia definido e ambiente de teste.
- Política de backup, com frequência e retenção iguais.
- Monitoramento, com os mesmos indicadores e o mesmo canal de alerta.
- Documentação por site, registrando particularidades — o que evita depender da memória de uma pessoa.
O item dos acessos merece nota: credenciais compartilhadas entre a equipe são um problema de segurança e de continuidade. Acessos nomeados permitem revogar individualmente quando alguém sai, e mostram quem fez o quê quando algo dá errado.
Multisite: quando faz sentido e quando não
Uma dúvida recorrente em agências, e vale delimitar.
O modo multisite do WordPress permite rodar vários sites em uma única instalação, compartilhando núcleo, plugins e temas.
Faz sentido quando os sites são realmente semelhantes: filiais de uma mesma empresa, unidades de uma rede, portais regionais de uma organização. O compartilhamento é uma vantagem quando eles devem mesmo se comportar igual.
Não faz sentido para uma carteira de clientes distintos, e por razões concretas: uma atualização de plugin afeta todos os sites simultaneamente; um plugin incompatível com um cliente não pode ser instalado só para ele sem afetar a instalação; separar um site para migrá-lo quando o cliente sai é bem mais trabalhoso que mover uma instalação independente; e a superfície de segurança é compartilhada.
A regra prática: multisite é para sites de um mesmo dono. Carteira de clientes pede instalações independentes, ainda que no mesmo servidor.
O modelo comercial
Estruturada a hospedagem, resta como cobrar. As formas mais comuns:
| Modelo | Como funciona | Consideração |
|---|---|---|
| Repasse direto | Cliente paga o custo, sem margem | Simples, mas a agência trabalha de graça |
| Repasse com margem | Custo mais percentual | Comum, exige transparência |
| Pacote de manutenção | Valor fixo incluindo hospedagem e horas | Previsível para os dois lados |
| Cliente contrata direto | Agência só administra | Sem receita recorrente, sem risco |
O terceiro modelo é o que mais se alinha à operação real: hospedagem sozinha é commodity, e cobrar apenas por ela coloca a agência competindo com preço de provedor. Um pacote que inclui atualização, backup verificado, monitoramento e suporte cobra pelo que efetivamente dá trabalho — e é mais defensável quando o cliente compara valores.
Vale um alerta comercial: prometer disponibilidade é assumir um compromisso que depende de terceiros. Se a agência oferece garantia de tempo no ar, ela precisa estar coberta pelo que o provedor garante a ela. Isso é item de contrato nos dois sentidos.
Um roteiro de decisão
- Levante a carteira: quantos sites, qual o porte de cada um, quais os provedores atuais.
- Meça o tempo operacional gasto por mês com manutenção e suporte.
- Compare o custo de infraestrutura atual mais o operacional com o cenário consolidado.
- Avalie a capacidade técnica da equipe para operar um ambiente próprio — ou o custo de contratar gestão.
- Defina a política contratual de domínio, propriedade e saída antes de mudar qualquer coisa.
- Padronize primeiro, consolide depois. Padronização traz ganho mesmo sem mudar de arranjo.
- Migre em ondas, começando pelos sites de menor criticidade.
O passo 6 é o mais subestimado: boa parte do ganho operacional vem da padronização, não da consolidação. Uma agência com quarenta sites em contas separadas, mas com o mesmo conjunto de plugins, a mesma rotina e a mesma política de backup, já opera muito melhor do que uma com quarenta ambientes diferentes.
Conclusão
Estruturar a hospedagem de uma carteira é uma decisão de negócio, não de plano. O que decide não é o preço da mensalidade, e sim o tempo operacional que ambientes heterogêneos consomem — e a capacidade da agência de operar o que escolher.
Consolidar reduz custo por site e permite processos repetíveis, ao preço de concentrar risco e assumir a operação de infraestrutura. Manter contas separadas dilui o risco e limita a padronização. Os dois arranjos são defensáveis, e a escolha depende do tamanho da carteira e da equipe.
Independentemente do caminho, duas coisas valem sempre: domínio no nome do cliente e política de saída definida em contrato. Se você está avaliando como estruturar a sua carteira, conheça a hospedagem WordPress da TBF Host e verifique quais recursos de gestão em volume estão disponíveis.
Perguntas frequentes
Vale a pena consolidar os sites dos clientes em um servidor?
Depende do tamanho da carteira e da capacidade técnica da agência. O custo por site cai conforme a carteira cresce e a padronização permite processos repetíveis, mas um problema no servidor passa a afetar todos os clientes simultaneamente, e a agência assume integralmente a operação de infraestrutura.
O que muda no risco quando uma agência consolida sites?
Um problema deixa de afetar um cliente e passa a afetar todos ao mesmo tempo, com a agência como único ponto de contato. Isso transforma em requisitos itens antes opcionais: backup com restauração testada, monitoramento com alerta, plano de resposta a incidente, ambiente de homologação e isolamento entre os sites.
Devo usar WordPress Multisite para os sites dos meus clientes?
Em geral não. O multisite faz sentido quando os sites são realmente semelhantes e do mesmo dono, como filiais ou unidades de uma rede. Para clientes distintos, ele traz problemas: atualizações afetam todos de uma vez, plugins não podem ser instalados isoladamente e separar um site na saída de um cliente é bem mais trabalhoso.
Em nome de quem deve ficar o domínio do cliente?
Sempre no nome do cliente, com a agência como acesso delegado. Domínio registrado em nome da agência é a origem mais comum de conflito no encerramento da relação e o problema mais fácil de evitar — ele dá à agência um poder que, na prática, ninguém quer exercer.
Como cobrar pela hospedagem dos sites dos clientes?
Os modelos mais comuns são repasse direto, repasse com margem, pacote de manutenção com valor fixo e o cliente contratando diretamente. O pacote de manutenção costuma se alinhar melhor à operação real, porque cobra pelo que dá trabalho — atualização, backup verificado, monitoramento e suporte — em vez de competir com preço de provedor.
O que padronizar em uma carteira de sites WordPress?
Versão de PHP e de banco, conjunto base de plugins, estrutura de usuários e permissões com acessos nomeados, rotina de atualização com dia definido, política de backup com frequência e retenção iguais, monitoramento com os mesmos indicadores e documentação por site registrando particularidades.
O que acontece com o site quando o cliente troca de agência?
Depende do arranjo. Em conta contratada pelo cliente, basta revogar acessos. Em conta contratada pela agência, é preciso transferir ou migrar. Em ambiente consolidado, o site precisa ser extraído do servidor. Em todos os casos, prazo, formato de entrega e eventual custo devem estar previstos em contrato.
Por onde começar a organizar a hospedagem de uma agência?
Pela padronização, não pela consolidação. Boa parte do ganho operacional vem de ter o mesmo conjunto de plugins, a mesma rotina de atualização e a mesma política de backup em todos os sites — mesmo que eles continuem em contas separadas. Consolidar depois é uma segunda etapa.