Pular para o conteúdo
SEO e crawlers

Como desativar os recursos de IA do WordPress (núcleo x plugin, sem enrolação)

Descubra qual plugin, hospedagem ou mu-plugin está colocando aquele painel de IA, desligue com segurança e bloqueie rastreadores de IA no robots.txt sem perder tráfego de busca.

Publicado

Quase todo recurso de IA que as pessoas querem eliminar no WordPress vem de um plugin, da hospedagem ou do WordPress.com — e não do núcleo auto-hospedado. Antes de colar um trecho com remove_action no functions.php, abra sua lista de plugins e encontre o que realmente está renderizando aquele painel de IA, porque tentar remover um recurso que o núcleo nem entrega é muito esforço jogado fora em um site que já está se comportando mal.

Essa distinção importa porque as soluções são completamente diferentes. Um recurso de plugin tem um botão nas configurações. Um recurso injetado pela hospedagem vive no painel do provedor, não no admin do WordPress. E a outra pergunta, que costuma ser o que as pessoas realmente querem dizer com “desativar IA” — impedir que empresas de IA treinem com seus posts —, não é uma configuração do WordPress. É um problema de robots e de configuração de servidor.

O que é do núcleo e o que não é

O núcleo do WordPress auto-hospedado não entrega assistente de escrita com IA, chatbot ou gerador de imagens funcionando de saída. Se você vê um ícone de brilhinho de IA no editor de blocos, alguma coisa instalou aquilo.

De onde os recursos de IA realmente vêm:

OrigemRecurso típicoOnde desligar
JetpackBloco AI Assistant e painel no editorConfigurações do Jetpack, chave do módulo
Plugins de IA independentesGeradores de conteúdo, chatbots, criadores de texto alternativoTela de configurações do próprio plugin
Plugins de SEOSugestões de título e descrição por IAConfigurações do plugin, geralmente recurso a recurso
Construtores de páginaGeração de texto e imagem por IA na interface do builderConfigurações do builder ou painel da conta
Hospedagens gerenciadasAssistentes de IA injetados por mu-plugin ou pelo painelPainel de controle da hospedagem
WordPress.comFerramentas de escrita com IA hospedadasConfigurações da conta no WordPress.com, não no seu site

O projeto WordPress tem, sim, desenvolvimento relacionado a IA em andamento — plugins experimentais de recursos que um dia podem chegar ao núcleo. Se você está em uma versão recente e vê algo com cara de IA que não consegue atribuir a um plugin, confira primeiro a lista de plugins instalados e depois o changelog da sua versão, em vez de supor que existe um padrão do núcleo para filtrar. Essa ressalva é proposital: afirmações ligadas a versões específicas envelhecem rápido nessa área, e uma errada faz você editar arquivos à toa.

Descubra o que está colocando aquilo ali

Desative os plugins em lotes até o painel de IA sumir. É bruto, mas dá uma resposta definitiva em vez de um palpite.

Se você tem WP-CLI, liste primeiro tudo o que está ativo:

wp plugin list --status=active --field=name

Depois verifique o código injetado pela hospedagem, que não aparece na tela normal de plugins:

ls -la wp-content/mu-plugins/

Os must-use plugins carregam automaticamente e não podem ser desativados pelo admin. Se sua hospedagem colocou um assistente de IA ali, a única remoção limpa é pelo painel de controle dela — apagar o arquivo normalmente só faz ele reaparecer na próxima atualização da plataforma.

Desligando do jeito certo

Use a configuração do próprio plugin. Essa é a resposta sem graça e é a certa. O Jetpack, em especial, é construído com módulos que ligam e desligam de forma independente, então você desativa o AI Assistant e mantém estatísticas, backups ou o que mais usar. A maioria dos plugins de IA independentes tem uma caixa de ativar/desativar por recurso.

Se você não usa o plugin para mais nada, desative o plugin inteiro. Um plugin de IA que fica instalado mas “desligado” continua carregando código a cada requisição. Desativar é mais rápido, mais seguro e comprovadamente mais leve que qualquer filtro.

Remover o hook com remove_action é último recurso. Funciona de verdade, mas só quando você sabe exatamente o nome do hook, o callback e a prioridade que o plugin registrou, e só até o plugin renomear qualquer um deles:

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

O custo real: isso quebra em silêncio. Uma atualização do plugin muda o nome da classe, sua remoção deixa de corresponder, o painel de IA volta e nenhum erro avisa. Se você for por esse caminho, anote o que removeu e confira de novo depois de cada atualização daquele plugin.

O mesmo cuidado vale para cancelar o registro de painéis do editor pelo JavaScript. É um recurso legítimo, mas você está mexendo no registro de outro plugin usando um identificador em texto, e esse identificador não é um contrato público.

Não tente bloquear recursos de IA editando constantes do wp-config.php que você achou num post de fórum. Nenhuma constante do núcleo desliga IA de plugin de terceiro. Se um trecho de código afirma o contrário e você não consegue rastrear a constante até a documentação daquele plugin, ele não faz nada.

A outra pergunta: impedir o treinamento de IA com seu conteúdo

Isso é separado, e é onde mora a maior parte da ansiedade real. Desligar um painel do editor não muda nada sobre quem rastreia seus posts. Controlar isso acontece no robots.txt e, se você quiser que seja imposto de fato, no servidor.

O WordPress serve um robots.txt virtual, a menos que exista um arquivo real na raiz do site. Se houver um arquivo físico, o WordPress sai de cena por completo e é esse arquivo que os rastreadores recebem. Para editar o virtual, use um filtro:

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

Montar as regras na mão é onde as pessoas erram — um token errado não bloqueia nada, e um Disallow: / perdido no agente errado pode tirar você da busca normal. O gerador de robots.txt monta os blocos de rastreadores de IA junto com suas diretivas normais de busca, para você ver o arquivo inteiro antes de publicar.

Tokens que os grandes operadores publicam e dizem respeitar:

TokenOperadorO que cobre
GPTBotOpenAIRastreamento para treinamento de modelos
ChatGPT-UserOpenAIBuscas disparadas pelo pedido de um usuário
ClaudeBotAnthropicRastreamento
Google-ExtendedGoogleUso do seu conteúdo para treinar o Gemini, não o rastreamento em si
Applebot-ExtendedAppleUso para o treinamento dos modelos generativos da Apple
PerplexityBotPerplexityRastreamento
CCBotCommon CrawlArquivo em massa usado no treino de muitos modelos

Duas ressalvas honestas. Primeira: o robots.txt é voluntário. Operadores bem-comportados seguem; qualquer um que queira ignorar, ignora. Segunda: bloquear não sai de graça. Alguns desses tokens definem se você aparece nas respostas geradas por IA que citam e linkam seu site. Bloqueie todos e você perde essa fonte de tráfego junto com a exposição ao treinamento. Decida com qual das duas você realmente se importa.

Para impor de fato, em vez de fazer um pedido educado, bloqueie no servidor. No .htaccess do Apache:

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

Strings de user-agent são falsificadas com facilidade, então isso barra o tráfego honesto porém indesejado, e não um raspador determinado. Bloquear por faixa de IP verificada no seu CDN ou firewall é mais forte, e a maioria dos CDNs hoje já oferece uma regra de bot de IA com um clique, bem mais fácil de manter que uma lista escrita à mão.

O que não funciona

O llms.txt é uma proposta, não um padrão. É um arquivo markdown sugerido que descreve seu site para modelos de linguagem. Nenhum grande operador se comprometeu a tratá-lo como controle de acesso. Adicionar não custa nada e pode ajudar na forma como os modelos leem você, mas não bloqueia coisa alguma.

As meta tags noai e noimageai são respeitadas por quase ninguém. Elas nasceram da política de uma plataforma, não de um acordo entre empresas. Adicioná-las não faz mal; esperar que funcionem, sim.

Um plugin que promete “bloquear IA” normalmente só escreve regras de robots. Tudo bem, e é exatamente o que você mesmo faz em dez linhas. Não é uma barreira jurídica nem técnica, e nenhum plugin transforma isso em uma.

Bloquear rastreadores de IA não remove o conteúdo que já está em um modelo treinado. Nada que você adicione hoje tira retroativamente seus posts de um modelo lançado no ano passado. As regras do robots valem só daqui para frente.

Ainda vendo um painel de IA

Se todos os plugins estão desligados e o painel continua ali, confira de novo a pasta wp-content/mu-plugins/, depois o painel da sua hospedagem e, por fim, se você não está no WordPress.com em vez de auto-hospedado — lá as chaves ficam nas configurações da conta, não no admin do site. E se o recurso voltar depois de uma atualização de plugin, essa é a assinatura de um trecho de código de desligamento por hook que parou de corresponder, e não de um padrão do núcleo se impondo.

FAQ

Perguntas

O núcleo do WordPress tem recursos de IA que eu preciso desativar?

O núcleo do WordPress auto-hospedado não inclui assistente de escrita com IA, chatbot ou gerador de imagens que funcione por padrão. Os painéis de IA no editor quase sempre vêm de um plugin instalado, de um plugin injetado pela hospedagem ou de uma integração do painel do provedor. Confira sua lista de plugins antes de escrever qualquer código para remover algo que talvez nem exista no núcleo.

Como desligo o Jetpack AI Assistant?

Desative o módulo AI Assistant na tela de configurações do Jetpack, em vez de mexer no código. O Jetpack é construído com módulos que ligam e desligam de forma independente, então desativar esse módulo remove o painel do editor e mantém o resto do Jetpack funcionando. Se você não usa nenhum outro recurso do Jetpack, desativar o plugin inteiro é mais simples e mais leve.

O remove_action consegue desativar um recurso de IA de plugin?

Às vezes, mas é frágil. Só funciona se você souber exatamente o hook, o callback e a prioridade que o plugin registrou, e uma atualização do plugin pode renomear qualquer um desses e trazer o recurso de volta silenciosamente. Use a própria configuração do plugin quando ela existir e trate o desligamento por hook como último recurso, que precisa ser testado de novo depois de cada atualização.

Bloquear rastreadores de IA no robots.txt funciona de verdade?

Só para os rastreadores que decidem obedecer. Grandes operadores como OpenAI, Anthropic, Google e Apple publicam tokens de user-agent que dizem respeitar, e bloquear esses vale a pena. As regras do robots não são uma trava, então quem age de má-fé e as buscas disparadas por usuários podem ignorá-las. O bloqueio no servidor é a camada que realmente impõe a regra.

Qual a diferença entre bloquear um rastreador de IA e bloquear a busca por IA?

Alguns operadores usam tokens separados para treinamento e para responder perguntas ao vivo. Bloquear o token de treinamento mantém seu conteúdo fora do treino do modelo, mas você continua aparecendo nas respostas de IA; já bloquear o token de busca ou de user-agent pode tirar você dos resultados gerados por IA que citariam e linkariam seu site. Decida qual troca faz sentido antes de bloquear os dois.

O llms.txt é um padrão que eu deveria implementar?

Não, o llms.txt é uma proposta da comunidade, não um padrão ratificado, e nenhum grande operador de IA se comprometeu a tratá-lo como mecanismo de controle de acesso. Adicionar o arquivo é inofensivo e barato, mas não o encare como substituto das diretivas do robots.txt ou do bloqueio no servidor. A padronização nessa área ainda está em andamento.