Desde maio de 2026, o WordPress traz no núcleo a infraestrutura pra IA. Isso é bem diferente de trazer IA.
Essa diferença responde quase inteira a pergunta de como integrar IA no WordPress este ano. Toda integração de verdade agora vai numa de duas direções: saída, quando o seu site chama um modelo de linguagem, ou entrada, quando um agente de IA de fora chama o seu site. A saída passa pelo WP AI Client, que vem no WordPress 7.0. A entrada passa pela Abilities API mais o MCP Adapter, que não está no núcleo.
Uns meses atrás escrevi sobre as cinco categorias de integração de IA no WordPress, mostrando como cada tipo se comporta em produção. Este post fica um nível acima: é sobre a infraestrutura em que as cinco categorias rodam agora.
O que "integração de IA" quer dizer no WordPress depois do 7.0
A camada de IA do WordPress 7.0 tem quatro peças: um cliente PHP que conversa com modelos sem depender de um provedor específico, um registro de ações declaradas, uma tela de configurações onde o dono do site guarda as credenciais, e uma API de Connectors por trás dessa tela, pra quem desenvolve registrar novos tipos de conexão. Segundo o guia de campo do WordPress 7.0, o núcleo cuida do roteamento das requisições e o dono do site gerencia as chaves de API em Configurações > Conectores. Nenhum provedor vem no núcleo. O projeto WordPress mantém três plugins oficiais de provedor, pra Anthropic, Google e OpenAI, e qualquer pessoa pode escrever outro.
Ou seja: uma instalação nova do WordPress 7.0 tem capacidade de IA e nenhum recurso de IA ao mesmo tempo. O recurso vem quando você instala alguma coisa por cima, seja um plugin de outra pessoa, seja código seu.
O WordPress 6.9 começou isso em dezembro de 2025, com a parte PHP da Abilities API. O 7.0 adicionou a parte JavaScript, pra habilidades do lado do cliente como inserir blocos ou andar pelo editor, que é o que importa pra agentes que operam no navegador. Tudo isso faz parte da iniciativa AI Building Blocks do projeto. Guarde o nome como termo de busca, porque os posts e as notas de desenvolvimento não usam uma nomenclatura consistente.
Saída: como o WordPress chama um modelo de IA
Integração de saída é o seu código PHP mandando um prompt e recebendo um resultado, com o núcleo decidindo qual provedor responde. No WordPress 7.0, a porta de entrada é wp_ai_client_prompt(), um construtor encadeável documentado na nota de desenvolvimento publicada em março de 2026:
$text = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' )
->using_temperature( 0.7 )
->generate_text();
if ( is_wp_error( $text ) ) {
return;
}
Se você vinha usando o pacote avulso wordpress/php-ai-client, a migração é um localizar e substituir: AI_Client::prompt() vira wp_ai_client_prompt(), e a dependência do Composer sai quando você passar a exigir o WordPress 7.0.
Pra produção, dois métodos desse construtor importam mais que o resto. is_supported_for_text_generation() diz se o site tem mesmo um provedor configurado antes de você mostrar um botão de IA, e não custa nada, porque consulta os recursos conhecidos do modelo em vez de fazer uma chamada. O filtro wp_ai_client_prevent_prompt deixa você bloquear prompts por completo, e é assim que você impede um usuário com papel de editor de gastar tokens num site onde só administrador deveria gerar alguma coisa.
Esse segundo existe porque geração sem limite é um ralo de dinheiro. Eu mantenho o WP-AutoInsight, um plugin de IA pra WordPress com mais de 6.000 downloads, e as perguntas que mais aparecem quase nunca são sobre a qualidade do modelo. São sobre quem no site pode disparar uma geração e quanto custa quando várias pessoas fazem isso no mesmo dia. O plugin oficial de IA do WordPress agora mostra o log de requisições no painel, e pra mim isso é a primeira vez que a plataforma admite, com honestidade, que esses recursos custam dinheiro.
A saída também é onde vivem os pipelines de conteúdo, e os maiores ganhos costumam acontecer totalmente fora do WordPress. Os pipelines de n8n que construí pra um cliente de e-commerce derrubaram o custo de produção de conteúdo entre 60% e 80%, e o WordPress era só o ponto final de publicação, não o cérebro da operação.
Entrada: como um agente de IA chama o seu site WordPress
Integração de entrada é o Claude, o Cursor ou qualquer outro cliente MCP listando o que o seu site sabe fazer e executando essas ações com as permissões que você deu. É a metade mais nova, e a que a maioria dos guias ainda explica errado.
Uma habilidade é uma ação declarada, com nome, esquema de entrada, esquema de saída e callback de permissão. Registrar uma habilidade deixa ela disponível pro núcleo e pra qualquer outro plugin ou ferramenta de automação que pergunte. Expor essa habilidade pra um agente de fora exige uma segunda peça: o MCP Adapter, mantido em WordPress/mcp-adapter, instalado como plugin ou com composer require wordpress/mcp-adapter. Segundo a documentação de instalação, ele pede WordPress 6.9 ou mais novo e PHP 7.4 ou mais novo. Não vem no núcleo, e nada indica que vá vir tão cedo.
Duas coisas pra conferir antes de copiar qualquer tutorial. Primeiro: se o guia manda instalar Automattic/wordpress-mcp, feche a aba. Esse repositório foi arquivado em 19 de janeiro de 2026, e o aviso de migração aponta pro adapter. Segundo: o adapter está na versão 0.6.0 e muda rápido. A 0.6.0 subiu o mínimo pra WordPress 6.9 e inverteu um padrão de exposição: habilidades marcadas com meta.public: true agora aparecem no servidor MCP padrão, a não ser que você desligue isso explicitamente com meta.mcp.public.
Se você cuida de site de cliente, leia esse parágrafo de novo com calma.
Um padrão que muda de direção entre versões menores é exatamente como um site acaba expondo mais do que o dono queria, e as verificações de capacidade que continuam valendo por baixo só são tão boas quanto o papel de usuário do WordPress que você usou pra conectar. Escrevi um post inteiro sobre o que acontece quando um agente de IA tem as chaves de tudo, e o MCP Adapter é a versão mais legítima e mais bem construída desse risco disponível hoje. Conecte primeiro com um usuário de permissões limitadas, em staging, antes de apontar qualquer coisa pra produção.
O que o WordPress 7.1 trouxe de fato pra IA
Pouca coisa, e vale dizer com todas as letras, porque muita cobertura deu a entender o contrário. O WordPress 7.1 "Mary Lou" saiu no prazo, em 19 de agosto de 2026, e a única novidade de IA foi na autenticação: a tela Connectors agora aceita login com nome de usuário e senha de aplicação, além de chave de API, segundo o anúncio da versão beta no WordPress.org. O sistema de Diretrizes que estava proposto ficou fora deste ciclo, e o trabalho maior no AI Client foi empurrado pra 7.2.
Como integrar IA no WordPress sem quebrar a produção
Escolha primeiro a direção, depois a menor superfície que essa direção permite.
Na saída, isso quer dizer um recurso só, um único papel de usuário autorizado a disparar, e log ligado desde o primeiro dia. Gerar texto alternativo de imagem é um bom primeiro alvo, porque o resultado é curto e um resultado ruim fica óbvio assim que você olha. Gerar rascunho é um péssimo primeiro alvo, pelos motivos contrários.
Na entrada, quer dizer uma habilidade só e um usuário com permissões limitadas, num site de staging. Registre a habilidade você mesmo em vez de ativar um pacote que você não escreveu, porque cada habilidade exposta é uma função que um agente pode chamar enquanto você dorme.
As proporções surpreendem. Quando construí um chatbot RAG de produção em cima do catálogo WooCommerce ao vivo de um cliente canadense de saúde e bem-estar, integrar o modelo levou horas. Todo o resto levou meses: manter o bot longe dos dados dos clientes, fazer ele responder com base em SKUs reais em vez de SKUs plausíveis, deixar os textos de conformidade onde o regulador espera, e garantir que um prompt mal-intencionado não transformasse o chat de suporte numa máquina de dar desconto. A chamada de IA foi, com folga, a parte barata do projeto.
Pro lado do desenvolvimento, quando a IA escreve o plugin em vez de morar dentro dele, o post sobre Claude para desenvolvimento WordPress mostra o fluxo de trabalho que eu uso de verdade.
Então, o que construir primeiro
Se você publica conteúdo e quer IA no editor, instale o plugin oficial de IA, conecte um provedor e acompanhe o log de requisições por um mês antes de adicionar um segundo recurso.
Se você é dev e entrega pra cliente, registre habilidades pras coisas que o seu plugin já faz. Esse trabalho se paga duas vezes, uma pelos recursos de IA do núcleo e outra por qualquer agente que aparecer no ano que vem, e custa um esquema e um callback de permissão.
Se você quer que o Claude administre o seu site diretamente, o MCP Adapter é o caminho oficial. Ele também está abaixo da 1.0, então merece um usuário de permissões limitadas em staging, e não uma conta de administrador e muito otimismo.
E se alguém te disser que o WordPress 7.0 resolveu a integração com IA, pergunte: em qual direção?
Se você está tentando decidir se o seu site deve chamar um modelo, responder a um agente ou nenhum dos dois, essa decisão é boa parte do que eu faço em integração de IA no WordPress. O formulário de contato é o jeito mais rápido de começar essa conversa.