Gerir WordPress Multisite e busca com IA é diferente de cuidar de um site único, porque uma decisão técnica vale para toda a rede, mas o resultado de visibilidade aparece separado em cada subsite. Esse modelo, também chamado de GEO, exige pensar em dois níveis ao mesmo tempo: o da instalação compartilhada e o do site individual que a IA vai ler. Este guia faz parte do guia de Visibilidade em IA da FULL e mostra como organizar uma rede inteira sem deixar nenhum site para trás na resposta sintetizada.

O que é uma rede WordPress multisite

Uma rede WordPress Multisite é uma única instalação do WordPress que hospeda vários sites independentes sob a mesma base de código e o mesmo banco de dados. Em vez de instalar o WordPress 50 vezes para 50 sites, você ativa o recurso 1 vez e cria os domínios adicionais, que compartilham núcleo, plugins e temas, mas mantêm conteúdo, endereço e identidade próprios.

Na prática, o multisite é o motor por trás de redes de franquias com uma página por unidade, marcas com sites por país ou por linha de produto e portais com versões por idioma. A vantagem é operacional: uma equipe central atualiza a base e governa tudo de um lugar só. O desafio nasce justamente daí, porque a IA não enxerga a rede, ela enxerga cada site. Cada subsite tem a sua URL, o seu público e a sua disputa por citação, e precisa ser tratado como um competidor isolado quando o assunto é visibilidade.

Por que a visibilidade em IA é por site, não por rede

A visibilidade em IA é por site porque os modelos de linguagem avaliam cada URL pelo seu próprio conteúdo, contexto e sinais de confiança, não pela instalação que a serve. Para o ChatGPT ou o Perplexity, 2 subsites da mesma rede são 2 fontes distintas, e 1 pode ser citado enquanto o outro nunca aparece.

Isso muda a forma de planejar. A infraestrutura compartilhada cria a ilusão de que ajustar o conjunto resolve tudo, quando só estabelece a fundação. A McKinsey (2026) trata a busca com IA como uma nova porta de entrada da internet, e nela a citação depende do que cada subsite pública: profundidade do conteúdo, schema correto, entidades conectadas e resposta direta que a IA consegue extrair. Uma rede pode ter 80 sites com base técnica impecável e ver só 10 sendo citados, porque os outros 70 têm conteúdo raso ou entidades mal definidas. A régua é sempre o site, não a rede.

Robots.txt e llms.txt em uma instalação compartilhada

Em uma rede multisite, os 2 arquivos que guiam a IA, robots.txt e llms.txt, precisam estar corretos por site, e esse é o ponto que mais gera erro silencioso. O WordPress gera 1 robots.txt virtual por domínio, então cada subsite tem o seu, mas a regra que libera os crawlers de IA precisa valer para todos, não só para o principal.

O risco concreto é liberar GPTBot, PerplexityBot e Google-Extended só no site raiz e deixar os subsites barrando esses agentes por um plugin de segurança da rede. Aí dezenas de sites ficam fechados para a IA sem ninguém perceber. O llms.txt segue a mesma lógica: é um mapa do site escrito para modelos de linguagem e deve ir na raiz de cada subsite, apontando as páginas daquele domínio. Um llms.txt único da rede não serve, porque cada domínio cobre um tema diferente. Se um plugin já estiver bloqueando o acesso, vale conferir como corrigir o robots.txt que bloqueia páginas.

Sitemap e Schema: O que se herda e o que se ajusta

Sitemap e schema são gerados por site no multisite, mas a configuração que os produz costuma ser herdada da rede, e é aí que mora o problema. Cada 1 dos subsites tem o seu sitemap.xml e o seu schema, porém os 2 refletem os ajustes do plugin de SEO da rede, que nem sempre cabem em todo contexto.

O sitemap por site é quase sempre saudável, já que o plugin lista as URLs do domínio automaticamente. O schema é onde a herança falha. Um schema de Organization definido uma vez para a rede repete a mesma marca em sites que deveriam ter identidades diferentes, confundindo a IA sobre qual entidade pública o quê. O ideal é padronizar os tipos na rede, como Article e FAQPage, e ajustar os campos de identidade por site, para cada subsite declarar a sua marca. Schema quebrado ou genérico faz a IA ignorar a página como fonte confiável. O diagnóstico está em como corrigir o schema markup quebrado.

Consistência de entidade e NAP entre os sites da rede

A consistência de entidade e de NAP entre os sites da rede é o sinal que mais pesa para a IA confiar em uma marca multisite, e o mais difícil de manter em escala. NAP reúne 3 dados, nome, endereço e telefone, e quando eles, junto com a definição de entidade, variam entre subsites que pertencem à mesma organização, a IA recebe um sinal ambíguo e perde confiança.

O caso típico é a rede de franquias. Cada unidade tem o seu subsite com NAP próprio, o que está correto, mas a entidade da marca-mãe precisa ser declarada de forma idêntica em todos, conectada à mesma referência externa. Sem isso, a IA trata cada unidade como uma marca solta, sem ver que pertencem à mesma rede. Conectar as entidades a bases como a Wikidata, num processo de entity grounding, diz à IA que aqueles sites formam um conjunto reconhecível e com autoridade. O conceito está em entidades e Knowledge Graph para IA.

Como medir share of voice por site e agregado

No multisite, o Share of Voice em IA precisa ser medido em 2 camadas: por site, para saber quem é citado, e agregado, para enxergar a saúde da rede inteira. Medir só o total esconde subsites invisíveis, e medir só o individual perde a visão de conjunto que orienta a estratégia da rede.

Share of Voice em IA é a fatia de citações que uma marca recebe em respostas geradas, comparada à dos concorrentes. Por site, a leitura revela quais subsites já viraram fonte recorrente e quais nunca aparecem, expondo o desequilíbrio que a média esconde. Agregada, mostra se a rede ganha ou perde espaço no tempo. A tabela resume os dois níveis e o que cada um responde.

O erro mais caro: Configurar o principal e esquecer os subsites

O erro mais caro em multisite é configurar a camada de visibilidade em IA apenas no site principal e presumir que ela se propaga, quando na verdade os outros subsites continuam invisíveis. É um equívoco silencioso, porque só 1 site, o raiz, aparece bem nos testes e dá a falsa sensação de que a rede toda está coberta.

A causa é a confusão entre o que é da instalação e o que é do site. Liberar crawlers, publicar llms.txt e ajustar schema parecem tarefas únicas, mas só valem para o domínio onde foram aplicadas, a menos que a configuração seja desenhada para alcançar a rede. Quando a equipe central testa o principal, vê o GPTBot liberado e o llms.txt no ar, e encerra o trabalho, dezenas de subsites podem seguir fechados. O resultado é uma rede que parece otimizada e está majoritariamente ausente da busca com IA. A lista completa de armadilhas está em erros que tornam um site invisível para a IA.

A boa prática: Padronizar a base e checar cada subsite

A boa prática em WordPress Multisite e busca com IA é dividir o trabalho em 2 frentes: padronizar a base GEO na rede e validar cada subsite individualmente. A base resolve a fundação de 1 vez só, e a checagem por site garante que nenhum domínio ficou para trás na herança ou na ativação.

Padronizar a base é definir, no nível da rede, as regras gerais: liberação dos crawlers de IA, llms.txt por site, tipos de schema e formato answer-first como padrão. Checar cada subsite é verificar, por domínio, se o robots.txt libera os bots, se o llms.txt está na raiz, se o schema reflete a identidade certa e se as entidades estão conectadas. A tabela separa o que se resolve na rede do que exige conferência site a site.

Como a FULL cuida de visibilidade em IA em redes multisite

A FULL acompanha mais de 150 mil sites WordPress ativos no Brasil, e boa parte dessa escala vive em redes multisite de franquias, marcas e portais. Por isso WordPress Multisite e busca com IA é um cenário que a gente conhece de perto: a gente testa, nos próprios sites monitorados, o que faz um subsite ser citado pela IA e o que o deixa fora da resposta. A camada de visibilidade em IA da FULL foi pensada para funcionar em rede, não só em site único.

Na prática, a abordagem da FULL separa o que é base do que é por site exatamente como este guia descreve. Na FULL, a liberação dos crawlers, o llms.txt e os tipos de schema entram como padrão da instalação, enquanto a validação roda subsite a subsite para garantir que nenhum domínio ficou invisível. A leitura da FULL é que a busca com IA é a nova porta de entrada da descoberta de marca, e que redes multisite têm tudo para liderar nesse canal, porque padronizam com poucos cliques o que um site avulso faria no improviso. Essa é a aposta da FULL para quem opera dezenas de domínios na mesma rede. O Brasil vive uma janela de 12 a 18 meses de vantagem, e montar essa base agora, em até 30 dias de organização, custa menos do que recuperar terreno depois. Para acompanhar a evolução do GEO Suite e entrar na lista de espera, veja o plugin de GEO para WordPress da FULL e o guia de como preparar o WordPress para a busca com IA.

Perguntas frequentes sobre WordPress multisite e busca com IA

Próximos passos para uma rede multisite visível na IA

Gerir WordPress Multisite e busca com IA é menos sobre repetir tarefas em cada site e mais sobre desenhar uma base que alcance a rede e uma rotina de verificação que não deixe nenhum subsite escapar. Comece aceitando que a infraestrutura é compartilhada, mas a citação é individual, e divida o trabalho nas duas frentes: padronizar a fundação GEO e validar domínio por domínio. Para transformar isso em prática, use o checklist de GEO para WordPress em cada subsite e aprofunde a base de conhecimento no guia de Visibilidade em IA da FULL.