Alternativa ao Drupal multisite: mantenha o Drupal no site principal e repense a cauda longa

White label / Alternativa ao Drupal multisite

O Drupal é o CMS em que grandes órgãos públicos e universidades confiam para seus maiores e mais estruturados sites, e para eles costuma ser a escolha certa. O Drupal multisite estende a mesma base de código a muitos sites menores. Isso funciona enquanto você tem uma equipe Drupal à altura. Quando um departamento quer um site de cinco páginas e a fila para conseguir um é de três meses, o problema não é o Drupal; é usar uma ferramenta de site principal para um trabalho de cauda longa.

Agendar uma demonstração · O preço é sob medida para o seu volume e a sua configuração, e você recebe seu preço exato na chamada. 0% de taxa por transação.

Atualizado: 25 de outubro de 2026

Resumo

Documentação do Drupal: o multisite serve 'sites separados e independentes' a partir de uma base de código; cada um tem seu próprio banco de dados, configuração, arquivos e domínio.
Código compartilhado significa um único caminho de atualização para todos os sites, e todos esperam pelo mais lento. O suporte de segurança do Drupal 7 terminou em 5 de janeiro de 2025, o que obrigou muitas redes a encarar isso.
A We.Inc cuida da cauda longa: cada departamento ou unidade recebe o próprio site criado com IA, com a sua marca, regras centrais e aprovação em uma etapa antes de publicar.
Uma divisão costuma ser o melhor: Drupal para o site principal e o conteúdo estruturado, um criador para os sites pequenos.

O que é o Drupal multisite

A documentação do Drupal resume em uma linha: "O Drupal tem um recurso que permite servir sites separados e independentes a partir de uma única base de código." E: "Cada site tem seu próprio banco de dados, configuração, arquivos e domínio base ou URL."

É um formato diferente do WordPress Multisite. Sites Drupal em multisite compartilham código (núcleo, módulos, temas), mas não dados. Os benefícios são reais: um lugar para aplicar correções, um conjunto de módulos revisado pela sua equipe, conteúdo independente por site. O custo é que todo site anda na velocidade do código compartilhado. Uma atualização de módulo, um upgrade do núcleo ou uma troca de versão do PHP é uma mudança em todos eles.

O muro do upgrade

A maioria das organizações descobriu o custo do código compartilhado numa troca de versão principal. O próprio site do Drupal informa que "o suporte de segurança do Drupal 7 terminou em 5 de janeiro de 2025" (fim de vida do Drupal 7). Uma rede de 150 sites de departamentos em Drupal 7 não tinha um upgrade para planejar; tinha 150 migrações de conteúdo para uma nova versão principal, além de cada módulo e tema personalizado.

Se você passou por isso, ou ainda está passando, vale perguntar quais desses 150 sites realmente precisaram do Drupal. Uma resposta típica de equipes web de universidades e prefeituras é esta:

Tipo de site	Parcela típica da rede	Precisa do Drupal?
Site principal, notícias, diretório, catálogo de cursos ou serviços	Poucos	Muitas vezes sim: conteúdo estruturado, integrações, muitos editores
Departamentos grandes com seus próprios tipos de conteúdo	Alguns	Às vezes
Departamentos pequenos, programas, laboratórios, eventos, unidades	A maioria	Raramente: poucas páginas, um editor, mudanças ocasionais
Sites de campanha e pontuais	Muitos, de vida curta	Não

As duas últimas linhas são onde o tempo de uma equipe Drupal desaparece: pedidos de sites novos, editores que esquecem como o admin funciona e sites que ninguém mais assume.

O que um criador faz diferente nessas linhas

Na We.Inc, o dono de cada site pequeno é uma conta sob a sua marca. Ele entra em um portal com o seu nome e cores, descreve o site de que precisa e a IA o cria. Ele edita visualmente. Você decide centralmente o que ele pode fazer e se as alterações esperam aprovação.

*Configurações da marca aplicadas ao portal de todos os donos: logo, cores, fonte, estilo de botão.*

Designer do portal do cliente com opções de cantos, claro ou escuro, layout do login e itens de menu, com pré-visualização ao vivo

*O portal em que os donos dos sites entram é desenhado uma vez, de forma central.*

Não há lista de módulos para manter segura em toda a rede, porque os recursos (blog, formulários, loja, configurações de SEO) fazem parte do criador e são ativados por dono. Não há upgrade compartilhado para agendar.

Um cliente aberto com limite de sites, chaves por cliente e a opção Publicar exige minha aprovação

*Chaves por dono. Um laboratório ganha blog e formulários; um site curto de campanha não precisa de loja nem de domínio próprio.*

Onde o Drupal é claramente a melhor ferramenta

Preferimos que você mantenha o Drupal a comprar a coisa errada:

Conteúdo estruturado em escala. Catálogos de cursos, diretórios de equipe, buscadores de serviços e qualquer coisa com muitos campos e visualizações.
Integrações profundas. Sistemas acadêmicos, sistemas de identidade, gateways de pagamento e feeds de dados que seus desenvolvedores construíram sobre o Drupal.
Fluxo editorial complexo. Revisão em várias etapas com vários papéis em sequência. Nossa aprovação é de uma etapa: o site vai ao ar quando o dono da marca aprova.
Papéis granulares. O sistema de permissões do Drupal é muito mais granular. O nosso tem dono, admin e membro, além de perfis fixos de equipe e chaves por dono.
Equipes com desenvolvedores Drupal produtivos e satisfeitos.

Uma arquitetura dividida que funciona

O padrão que vemos dar certo não é "substituir o Drupal", e sim "parar de colocar tudo no Drupal":

Mantenha o site principal e os sites estruturados no Drupal. São eles que justificam o custo.
Mova os sites pequenos para o criador em lotes. Reconstrua a partir do conteúdo, sem portar temas. Redirecione as URLs antigas.
Use os mesmos padrões de marca nos dois. Cores, logo e fontes definidos nas configurações de marca do criador para combinar com o tema do Drupal.
Faça links, não incorpore. Os sites pequenos apontam para o diretório ou catálogo do site principal em vez de copiá-lo.
Escreva uma única política de governança para os dois. Quem pode pedir um site, quem aprova, quando ele é revisado e quando é desativado. Nosso modelo de política de governança traz o texto.

Fila de aprovação com um site aguardando e botões para aprovar e publicar ou pedir alterações

*A fila de aprovação para sites cujos donos precisam de aval. Uma etapa, feita pelo dono da marca.*

Perguntas para fazer a qualquer plataforma de cauda longa

Escolhendo a gente ou não, faça estas perguntas antes de tirar sites pequenos do Drupal:

Pergunta	Por que importa	Nossa resposta
Conseguimos extrair o código de cada site?	Evita a próxima migração forçada	Sim: download em ZIP ou sincronização com o GitHub
Quem pode publicar sem revisão?	Risco de política e de reputação	Por dono, com aprovação em uma etapa
Há registro de quem mudou as configurações?	Prestação de contas	Registro de auditoria das ações da organização
Cada site pode ter seu próprio domínio?	Departamentos muitas vezes têm domínios antigos	Sim, quando você permite para aquele dono
Que acessibilidade o resultado atende?	Dever legal de órgãos públicos	Feito para ajudar você a atender a WCAG 2.1 AA; sua equipe precisa testar
Quais certificações vocês têm?	Compras	Não alegamos nenhuma; peça nossa documentação de segurança na demonstração

Diálogo de exportação com as abas GitHub, ZIP, Vercel e Domain e uma opção de repositório privado

*Exportando um site: para o GitHub, como ZIP ou para outro lugar. Sua próxima migração, se houver, começa a partir de código real.*

Para órgãos públicos, o dever de acessibilidade vale qualquer que seja a plataforma. Nosso guia do prazo do ADA Title II explica as datas. Isto é informação geral, não aconselhamento jurídico.

Agende uma demonstração com a sua lista de sites Drupal e marcaremos quais nós moveríamos e quais deixaríamos como estão.

Fontes

Última verificação em 2026-10-25.

Drupal.org, Multisite Drupal: base de código única; banco de dados, configuração, arquivos e domínio próprios por site.
Drupal.org, Drupal 7 end of life: suporte de segurança encerrado em 5 de janeiro de 2025.

Traga sua lista de sites Drupal

Agende uma demonstração de 30 minutos. Mostramos o criador com a sua marca, vemos quantos sites de clientes você pretende operar e passamos seu preço exato.

Agendar uma demonstração

Quer ver o tour completo antes? Conheça o criador de sites white label

Perguntas que os compradores fazem

O Drupal multisite é igual ao WordPress Multisite?

Não. A documentação do Drupal descreve o multisite como sites separados servidos a partir de uma base de código, cada um com seu próprio banco de dados, configuração, arquivos e domínio. O WordPress Multisite compartilha uma instalação e um banco de dados, com tabelas por site.

Devemos substituir nosso site principal em Drupal pela We.Inc?

Geralmente não. Sites grandes e estruturados, com integrações e fluxo complexo, são onde o Drupal é forte. A We.Inc se encaixa nos muitos sites pequenos ao redor dele.

A We.Inc tem fluxos editoriais em várias etapas?

Não. A aprovação é de uma etapa: o dono clica em Publicar e o site vai ao ar quando o dono da marca aprova. Etapas adicionais de aval precisam acontecer fora da plataforma.

Isto é aconselhamento jurídico sobre prazos de acessibilidade?

Não. É informação geral. Confirme as regras que se aplicam a você com sua própria assessoria jurídica.