Como criar uma rede de microsites com agente de IA e um só painel

Criar uma rede de microsites com agente de IA não é apenas pedir várias páginas e publicar tudo em sequência. O desafio real aparece depois: saber qual endereço pertence a cada campanha, qual versão está ativa, quem aprovou o conteúdo e onde fazer a próxima atualização.

Com uma estrutura simples, o agente pode acelerar a criação e a publicação enquanto o Site no Ar concentra Sites, URLs, arquivos e domínios em um só painel. O ganho não vem de produzir dezenas de páginas sem critério. Vem de transformar cada microsite em uma unidade identificável, verificável e fácil de manter.

O que conta como um microsite nessa operação

Um microsite é um destino com objetivo e ciclo de vida próprios. Pode ser uma página de evento, uma campanha regional, um lançamento, um material rico ou uma oferta para um segmento específico.

No Site no Ar, existem duas formas principais de representar essa estrutura:

• um Site para cada microsite, com slug, URL, deploy e domínio próprios;
• um Site com várias Páginas, quando os destinos pertencem ao mesmo projeto e podem ser publicados como um pacote.

Essa distinção é importante. Arquivos HTML adicionais dentro do mesmo pacote viram rotas, mas continuam compartilhando o Site e seu ciclo de publicação. Sites separados aparecem individualmente no painel e podem evoluir sem republicar os demais.

Quando separar em Sites

Prefira um Site por microsite quando:

• cada campanha precisa de uma URL independente;
• equipes ou clientes diferentes aprovam cada destino;
• os calendários de publicação não coincidem;
• cada microsite pode receber um domínio próprio;
• você precisa atualizar ou encerrar um destino sem tocar nos outros;
• analytics e handoff precisam ficar claramente associados a uma iniciativa.

Exemplo de inventário:

Cada Site consome uma unidade do limite da conta. Antes de criar a rede, peça ao agente para consultar uso e limites. Isso evita desenhar uma operação maior do que o plano comporta.

Quando manter várias Páginas no mesmo Site

Um Site multipágina costuma ser melhor quando:

• as páginas compartilham navegação e identidade;
• todas pertencem à mesma campanha;
• o deploy deve ativar o conjunto inteiro;
• assets e componentes são mantidos em um único projeto;
• as rotas fazem sentido sob o mesmo endereço.

Um pacote pode ter esta forma:

index.html
produto-a.html
produto-b.html
obrigado.html
assets/styles.css
assets/logo.svg

index.html responde em /. Os demais HTMLs viram rotas como /produto-a e /obrigado. CSS, JavaScript, imagens e fontes preservam os caminhos enviados.

O guia de Publicação detalha esse contrato e explica como organizar os arquivos em public/, editar pela Session e publicar uma Version.

Comece pelo registro mestre, não pelo prompt

Antes de gerar qualquer código, crie uma tabela que represente a rede. Para cada microsite, registre:

• objetivo e público;
• Site ID;
• slug e URL pública;
• pasta ou repositório de origem;
• versão de conteúdo aprovada;
• responsável;
• domínio próprio, se houver;
• data do último deploy;
• estado: rascunho, revisão, ativo, pausado ou encerrado.

O Site ID deve ser a referência operacional. O slug forma o endereço público, mas pode mudar. Nas operações seguintes, o agente deve usar o identificador retornado pela plataforma, não tentar reconhecer o destino por um nome parecido.

Padronize sem transformar tudo em clone

Uma rede fica mais fácil de manter quando compartilha uma base. Defina como invariantes:

• tokens de cor, tipografia e espaçamento;
• componentes de cabeçalho, prova e CTA;
• regras de responsividade e acessibilidade;
• metadados mínimos de SEO;
• eventos de analytics aprovados;
• estrutura de arquivos e checklist de publicação.

Separe como dados variáveis:

• público;
• problema e promessa;
• oferta;
• provas autorizadas;
• imagens;
• CTA;
• slug e domínio.

O agente pode aplicar essas diferenças a uma base comum, mas não deve inventar depoimentos, métricas, clientes ou condições comerciais para preencher lacunas.

Um prompt para planejar a rede

Antes de pedir a publicação, use um prompt de planejamento:

Quero criar uma rede de microsites a partir da tabela abaixo.

Para cada linha:
- identifique objetivo, público, conteúdo aprovado, CTA e responsável;
- recomende Site separado ou Página no mesmo Site;
- explique a decisão em uma frase;
- proponha um slug curto, sem criar nada ainda;
- aponte campos ausentes e pare quando houver decisão de negócio.

Invariantes da rede:
- mesma base visual e técnica;
- responsividade e acessibilidade básica;
- metadados de SEO por destino;
- nenhuma estatística, prova ou integração inventada.

Entregue primeiro uma tabela de arquitetura para aprovação.

Esse checkpoint evita que o agente transforme uma lista de campanhas em uma coleção de destinos difíceis de governar.

Publique em lotes pequenos

Depois da aprovação, trabalhe em lotes de dois ou três microsites. Para cada lote:

1. gere os arquivos;
2. revise copy, CTA e metadados;
3. confirme o mapeamento entre pasta e Site;
4. publique um destino por vez;
5. acompanhe cada deploy até o estado final;
6. abra as URLs e teste os caminhos críticos;
7. atualize o registro mestre.

Publicar em lote não significa disparar tudo sem checkpoints. O próprio contrato impede dois deploys simultâneos no mesmo Site; em Sites diferentes, a separação continua útil para isolar falhas e registrar resultados.

Fluxo com MCP

Depois de seguir a Configuração do MCP, o agente pode listar os Sites existentes, criar os que foram aprovados e publicar os arquivos mantidos no workspace de cada Site.

O fluxo de cada microsite é:

1. listar os Sites e localizar o Site ID correto;
2. criar um Site apenas se o destino ainda não existir;
3. chamar get_context e inspecionar os arquivos atuais;
4. alterar a Session pelas file tools;
5. confirmar public/index.html e public/sitemap.xml;
6. iniciar o deploy;
7. acompanhar até success, failed ou worker_upload_failed;
8. abrir a URL final e registrar o resultado.

Cada Site tem sua própria Session. Por isso, revise o destino e o diff antes de chamar deploy.

Um prompt para publicar com controle

Use o MCP do Site no Ar para publicar o lote aprovado abaixo.

Antes de alterar qualquer coisa:
- consulte uso e limites da conta;
- liste os Sites existentes;
- mostre o mapeamento pasta -> Site ID -> slug -> URL;
- pare se houver destino ambíguo ou slug já usado.

Depois da minha confirmação, publique um microsite por vez.
A página inicial deve ficar em public/index.html e o sitemap em public/sitemap.xml.
Acompanhe cada deploy até o estado final e abra a URL publicada.

No fim, entregue uma tabela com Site ID, slug, URL, deploy, status
e qualquer pendência. Não crie Sites extras para corrigir conteúdo.

Domínios próprios entram depois da validação

Valide primeiro cada microsite no endereço <slug>.sitenoar.app. Quando conteúdo, formulário e tracking estiverem aprovados, conecte o domínio próprio ao Site correto.

Um domínio raiz e um subdomínio são hostnames diferentes. Se ambos precisam funcionar, configure ambos. O passo a passo de Domínios próprios mostra os registros DNS e os estados de validação e SSL.

Registre o hostname no inventário da rede. Não confie apenas em uma planilha de marketing se a plataforma mostra o vínculo real entre hostname e Site.

Atualizações devem preservar o destino

Quando um microsite mudar, publique uma nova versão no mesmo Site. Criar outro Site para cada correção fragmenta histórico, URLs e analytics.

Antes de republicar, peça ao agente para confirmar:

• Site ID;
• slug e URL atuais;
• pasta de origem;
• arquivos que serão substituídos;
• versão de conteúdo aprovada.

Depois do deploy, verifique a URL e atualize a data da última publicação. O guia sobre como republicar um Site com agente de IA aprofunda esse fluxo.

Meça cada microsite como uma hipótese

O painel e o MCP podem apresentar analytics por Site, incluindo visualizações, visitantes, páginas, referenciadores, países, dispositivos e caminhos com erro 404. Use esses dados para responder perguntas específicas:

• o destino recebeu tráfego da campanha esperada?
• qual página concentrou visitas?
• existem links apontando para rotas ausentes?
• o microsite continua útil ou deve ser encerrado?

Não compare apenas volume bruto entre iniciativas diferentes. Registre o objetivo de cada microsite e avalie o resultado dentro desse contexto.

Checklist de governança da rede

Antes de considerar a operação pronta, confirme:

• todo microsite tem objetivo, responsável e estado;
• Site ID, slug e URL estão registrados;
• Sites separados foram usados apenas quando há independência real;
• o pacote de cada Site contém index.html;
• CTAs, links, imagens e metadados foram verificados;
• domínios próprios apontam para o Site correto;
• republicações preservam o destino;
• Sites encerrados estão identificados e não recebem tráfego por engano.

Comece com três destinos reais

Escolha três iniciativas que já existem. Monte o registro mestre, decida quais precisam de Sites separados e publique primeiro URLs de revisão. Só então conecte domínios e amplie a rede.

Com essa disciplina, o agente deixa de ser apenas um gerador rápido de páginas. Ele passa a operar um processo repetível, enquanto o Site no Ar mantém cada destino, versão e URL visível em um só lugar.