Você também deve estar se perguntando, ou sendo perguntado com frequência: “qual plugin de IA a gente instala?”. A tentação é responder com um nome. Em poucos meses o nome muda, o plano sobe, e o site continua pedindo excerpt, pedido, deploy e alguém que saiba o que está no ar.
O que falta quase nunca é mais uma marca. É um mapa das integrações de IA no WordPress: por onde o site fala com Claude, ChatGPT, Cursor ou um fluxo no n8n; o que já está no core; o que ainda é experimento; o que só polui o painel. Este artigo entrega esse mapa, com o critério adotar agora, experimentar em lab ou só observar, alinhado ao pilar IA e WordPress: a combinação estratégica de 2026.
IA no WordPress não é um plugin: é um mapa de camadas. O critério é o que você adota agora versus o que só observar.
No IA+WP eu fecho nessa ordem: contrato aberto, Connector quando o core resolve, agente com permissão mínima, conteúdo legível para busca e para assistentes antes de prometer “aparecer no ChatGPT”.
O site é o ativo; o chat é cliente
Trocar de modelo ou de IDE não deveria obrigar a reescrever o WordPress. Quando obriga, o contrato estava no lugar errado: chave presa num plugin, markup que só aquele gerador entende, ou automação que ignora permissão e schema.
Na prática, quase todo caso útil cabe em um destes canais:
| Se você precisa… | Canal |
|---|---|
| Gerar no painel com provedor compartilhado | Connectors + AI Client (core 7.0+) |
| Declarar o que o site sabe fazer | Abilities (desde 6.9; schema + permissão) |
| Deixar o agente descobrir essas operações | MCP Adapter (experimental, out/2026) |
| Ligar script, n8n, Make, Zapier ou app própria | REST + Application Password |
| Operar produção sem plugin de agente no ar | SSH + WP-CLI (Proa) |
| Ensaiar no IDE antes do ar | Studio MCP (lab; não substitui produção) |
Prova em lab (Studio, Local ou equivalente): Connector ou Application Password só leitura; um cliente chama o site; depois outro no mesmo contrato. Se a troca exige reescrever conteúdo ou tema, conserte o canal antes de escalar.
Plugins (AI, Jetpack AI, AI Engine…) entram bem quando reutilizam Connector e Abilities; mal com segunda chave e markup opaco. O mesmo filtro vale para n8n/Make e para chat de atendimento (só com verdade do pedido no Woo/WordPress).
O que o WordPress 7 já resolve no painel
Desde o 7.0, AI Client e Connectors (Configurações → Connectors) são a base oficial: uma credencial (OpenAI, Anthropic, Google ou outro no registry) e plugins que pedem geração sem inventar login próprio. Abilities (desde 6.9, refinamentos na 7.1) fazem o site declarar operações descobertas, com permissão, em vez de o agente adivinhar endpoints. O plugin AI (1.4.0, outubro/2026) é a referência de experimentações nesse trilho (assistente no editor, alt, feeds Markdown, embeddings), não “mais um gerador”. Continua experimental.
Em site 7.0+: adote Connector se o painel gera com provedor; adote Abilities se integra ou desenvolve. Experimente o plugin AI opcional. Só observe busca semântica pronta no core, loop agentic nativo e embeddings/streaming de produto no Client (pós-7.1).
Quando o agente chama o site (e quando não)
Com Abilities publicadas, o MCP Adapter as projeta como ferramentas MCP em /wp-json/mcp/mcp-adapter-default-server (remoto: proxy + Application Password). Não há copiloto visual no admin: o Adapter é servidor. Em outubro/2026 está no WordPress.org e ainda experimental; 1.0 e core esperam a especificação estabilizar. Ensaio em ambiente de teste faz sentido; prometer que “o ChatGPT administra o site sozinho”, sem governança, não.
Se o cliente não deve ganhar plugin de agente, o canal que eu documento em produção é SSH + WP-CLI: Cursor no WordPress em produção.
Experimente Adapter em ambiente de teste, senha mínima, lista consciente do que fica público. Só observe escrita ampla no admin “porque é prático”.
Lab antes do ar
Errar barato continua sendo local: Studio com studio mcp e studio wp, Cursor ou Claude no IDE, Playground para prova. Studio Code segue em beta: útil no protótipo, frágil como fonte da verdade de produção. O critério de ativo editável não muda com o agente: página pública e editor alinhados; manutenção básica pelo painel também sem IA (criar sites com IA no WordPress moderno). Geradores de hospedagem (Hostinger AI, 10Web, ZipWP, Elementor AI…) são outro contrato de edição.
Adote lab + agente no IDE + ensaio antes de alterar o ar. Experimente Studio Code. Só observe “a hospedagem já é o WordPress com IA” quando você precisa de ativo seu.
Conteúdo, busca e o que assistentes realmente leem
Aqui misturam três intenções. Separá-las evita a ferramenta errada.
SEO (busca clássica): título, meta description, headings, FAQ, schema, performance, links. Ainda decide visibilidade no Google Search. Assistentes no editor aceleram excerpt, alt e rascunho: produtividade, não ranking.
GEO e AEO (citação e respostas): ser citável em respostas geradas: afirmações claras, FAQ real, schema. llms.txt (Yoast, Rank Math, AIOSEO) e feeds Markdown do plugin AI são sinais, não fator de ranking no Search. The SEO Framework (stack deste hub) só gera llms.txt quando um provedor anunciar consumo; nos logs deles, bots de IA quase não pedem o arquivo. No IA+WP mantenho um arquivo curto e curado à mão: clareza, não promessa de citação.
Adote conteúdo citável, schema e revisão humana. Experimente llms.txt ou feed Markdown. Só observe “garante aparecer no ChatGPT” / AI Overviews.
Loja e página do visitante
No Woo não há suite de IA nativa no core. Copy e chat continuam plugin ou serviço, com revisão no catálogo. O fio útil é o MCP em developer preview (produto/pedido no Woo 10.9+ via Adapter): vale ambiente de teste, não roadmap ancorado só nisso. Chat sem estoque, pedido ou processo só acelera resposta errada.
Do lado do visitante, WebMCP faz a página declarar ferramentas para o agente no navegador; não substitui o MCP do servidor (WordPress e WebMCP). Em outubro/2026 segue origin trial no Chrome (149–156). Lighthouse agêntico mede interface usável por agente, não posição no Search. Experimente um formulário anotado. Só observe WebMCP como SEO.
Cinco perguntas antes de instalar
- Qual canal resolve o caso (painel, agente externo, produção sem plugin, visitante)?
- Qual a permissão mínima (Application Password, Connector Approvals)?
- Consigo trocar o cliente de IA sem refazer o site?
- Foi ensaiado em lab, com OK humano, antes do ar?
- Onde fica a verdade do conteúdo e dos dados? (Se for “no chat”, pare.)
O que este mapa ainda não fecha
Estado em outubro/2026 (Make/Core, Make/AI, Woo, Studio, Chrome). Adapter sem 1.0; embeddings no core e WebMCP estável em todo navegador ainda abertos. Detalhe por superfície fica na pesquisa de camadas deste hub.
Perguntas frequentes
Qual a melhor integração de IA para WordPress hoje?
Não há um plugin único. Em 7.0+, comece por um Connector e um canal aberto (Abilities, MCP ou REST) conforme o caso; o mapa acima decide o restante.
Preciso do plugin AI canônico?
Não. O AI Client pede Connector. O plugin AI é opcional (experimentações nesse trilho).
MCP e WebMCP são a mesma coisa?
Não. MCP expõe o site a agentes e IDEs. WebMCP declara ferramentas na página para o navegador.
llms.txt melhora ranking ou citação?
Não é fator de ranking no Google Search. Pode ajudar alguns fluxos; consumo amplo ainda não é compromisso público. Clareza, FAQ e schema pesam mais (SEO e GEO/AEO).
Posso usar Claude, ChatGPT e Cursor no mesmo site?
Sim, com contrato estável (Abilities + MCP, ou REST). O cliente muda; o ativo no WordPress não.
O que levar daqui
Canal aberto → o que o core já resolve → só então Adapter, editor, Woo ou WebMCP, cada um com adotar, experimentar ou só observar. A marca do modelo é substituível. O WordPress, com contrato certo, é o que sobra quando a lista de plugins envelhecer de novo.