Adicionar como fonte preferencial no Google
Os sites WordPress sempre foram desenvolvidos pensando nas pessoas. Quando alguém acessa uma página, navega pelo site, preenche um formulário, clica em um botão ou cria uma conta. O navegador está no centro dessa experiência, e é por isso que os desenvolvedores estruturam o site em torno das ações que as pessoas realizam na tela.
Os agentes de IA nem sempre funcionam dessa forma; eles podem obter informações, chamar funções e realizar tarefas sem precisar acessar uma página ou abrir o wp-admin. O WordPress está se adaptando por meio de ferramentas como a Abilities API e o MCP Adapter, que fornecem ao software meios mais diretos de descobrir e usar as funcionalidades do site.
À medida que essas interações se tornam mais comuns, os desenvolvedores têm outro tipo de usuário a considerar. Desenvolver WordPress para pessoas e agentes de IA muda a maneira como você pensa sobre APIs, permissões, autenticação, desempenho e o que acontece quando algo dá errado.
Os agentes de IA não usam o WordPress da mesma forma que as pessoas
As pessoas conseguem entender as coisas à medida que interagem. Elas podem examinar um menu, identificar pistas visuais, reler uma instrução ou testar outro botão quando algo não funciona na primeira tentativa.
Os agentes não têm a mesma flexibilidade. Eles precisam de um caminho de acesso mais claro, com ações definidas, entradas estruturadas, uma maneira de se autenticar e respostas que possam interpretar de forma confiável.
Isso muda algumas das premissas básicas da arquitetura do WordPress:
| Interação voltada para humanos | Interação preparada para agentes |
|---|---|
| Menus de navegação e botões | Funcionalidades detectáveis |
| Formulários | Entradas estruturadas e APIs |
| Telas de login | Autenticação programática |
| Retorno visual | Respostas e erros estruturados |
| Visualizações de páginas e sessões | Chamadas de API e execuções de ferramentas |
Também é importante distinguir agentes de crawlers. Os crawlers têm como principal função recuperar ou indexar informações. Os agentes podem ir além e realizar ações em nome de um usuário. Isso pode significar verificar o estoque, recuperar informações da conta, criar um rascunho, enviar dados ou acionar um fluxo de trabalho.
Quando um software pode fazer mais do que ler conteúdo, a arquitetura precisa considerar permissões, autenticação, estados de falha e as consequências de cada ação. Portanto, um site que funciona bem para agentes de IA precisa de mais do que conteúdo fácil de encontrar pelas máquinas. Ele precisa de maneiras claramente definidas para que as máquinas interajam com o WordPress de forma segura e confiável.
Projete funcionalidades, não apenas páginas
O design tradicional para a web começa com uma jornada do usuário. Alguém acessa uma página, navega pelo site, preenche um formulário e chega a uma tela de confirmação.
Um agente de IA pode ignorar completamente esse caminho. Ele não precisa visualizar a interface se puder acessar diretamente a função subjacente.
Essa função pode pesquisar na documentação, verificar o estoque, enviar uma solicitação de orçamento ou criar um rascunho. Em vez de pedir a um agente que reproduza as mesmas etapas realizadas por uma pessoa na tela, os desenvolvedores podem disponibilizar essas ações em um formato que o software consiga entender e usar.
A Abilities API do WordPress oferece aos desenvolvedores uma maneira mais organizada de disponibilizar essa funcionalidade. Em vez de fazer uma ferramenta externa interagir com uma página ou extrair informações do HTML, você pode definir uma ação diretamente, juntamente com os dados necessários, o que ela retorna e quem pode usá-la.
Isso não significa que todos os botões precisem de um equivalente acessível por máquinas. A pergunta mais útil é: quais funções valem a pena disponibilizar, quem deve poder usá-las e quais limites devem ser aplicados.
Para os desenvolvedores, isso adiciona uma nova pergunta ao processo de planejamento: o que este site pode permitir que pessoas e máquinas façam com segurança?
A autenticação e as permissões se tornam mais importantes
Quando um agente de IA pode realizar ações dentro do WordPress, a pergunta deixa de ser “Ele consegue se conectar?” e passa a ser “O que ele realmente deve ter permissão para fazer?”
Essa distinção é importante à medida que mais softwares operam com suas próprias credenciais e permissões. O relatório Identity Security Landscape 2025, da CyberArk, constatou que 68% das organizações não têm controles de segurança de identidade para IA. Conceder acesso a um agente é fácil. Manter esse acesso limitado à tarefa em questão exige mais planejamento.
Para cada funcionalidade voltada para máquinas, os desenvolvedores precisam responder a algumas perguntas básicas:
- Quem está fazendo a solicitação?
- Em nome de quem está agindo?
- Quais informações podem ser lidas?
- O que pode ser alterado?
- Quais ações exigem aprovação adicional?
Mantenha o acesso do agente vinculado à tarefa que ele está realizando. Uma ferramenta que pesquisa na documentação não tem motivo para editar artigos, e uma ferramenta que cria rascunhos não precisa necessariamente publicá-los. Ao lidar com ações como alterar contas, excluir conteúdo ou processar pagamentos, o nível de exigência deve ser muito maior.
A Abilities API do WordPress ajuda os desenvolvedores a definir esses limites. Cada habilidade pode incluir suas próprias verificações de permissão, além de entradas e saídas definidas. Isso oferece mais controle do que fornecer credenciais de administrador a um serviço externo e confiar que ele usará apenas o necessário.
Grande parte disso se resume às práticas comuns de segurança. Tudo o que um agente envia ainda precisa ser verificado antes que o WordPress realize qualquer ação. As credenciais também não devem ficar expostas em prompts, no código do frontend ou em registros. Se o agente estiver prestes a realizar uma ação cara ou difícil de desfazer, esse é um bom momento para interromper o processo e solicitar aprovação humana.
A necessidade de realizar uma tarefa não deve conceder a um agente amplo acesso ao WordPress. Dê a ele apenas a permissão necessária para realizar a tarefa em questão e nada além disso.
O uso por máquinas muda os requisitos de desempenho
Os visitantes humanos navegam em um ritmo natural. Eles carregam uma página, leem, clicam em algo e aguardam a próxima resposta. Os agentes de IA podem agir muito mais rápido. Eles podem enviar várias solicitações em poucos segundos enquanto coletam contexto, acionam ferramentas, comparam resultados e executam uma tarefa com várias etapas.
As regras normais de segurança não desaparecem apenas porque um agente está envolvido. O WordPress ainda precisa verificar o que recebe, e as credenciais ainda precisam permanecer fora dos prompts, do código do frontend e dos registros. Se o fluxo de trabalho chegar a um ponto em que possa realizar uma alteração cara ou difícil de reverter, uma pessoa deverá intervir antes que ele prossiga.
Os fluxos de trabalho executados por máquinas podem exigir muito mais do WordPress do que uma pessoa navegando pelo site, portanto, vale a pena reduzir o trabalho adicional. Isso pode significar combinar chamadas à API, armazenar em cache respostas de operações somente leitura, limitar quantas solicitações são executadas simultaneamente ou mover tarefas mais lentas para segundo plano. Limites de solicitações e timeouts adequados também podem impedir que um único fluxo de trabalho automatizado monopolize os recursos de todos os demais.
O objetivo é evitar que o WordPress realize mais trabalho do que a tarefa realmente exige. Se um agente precisar de três informações, por exemplo, um endpoint bem projetado pode ser melhor do que várias solicitações separadas, cada uma acionando suas próprias operações no banco de dados.
Os timeouts são complicados porque a solicitação pode ter sido processada mesmo que o agente nunca receba a resposta. Se ele enviar a mesma solicitação novamente, isso pode não ser um problema para uma consulta. Isso importa muito mais se a primeira solicitação tiver criado ou alterado algo. Antes de tentar novamente, o agente precisa de uma maneira de verificar se a tarefa já foi concluída.
As demandas mais amplas da infraestrutura de IA já estão bem documentadas. O ponto principal é mais específico: o planejamento de desempenho não pode mais pressupor que todas as interações aconteçam na velocidade humana.
À medida que os agentes se tornam outro tipo de usuário do WordPress, a infraestrutura precisa lidar com picos de atividade executada por máquinas sem permitir que esses fluxos de trabalho tornem o site mais lento para as pessoas que o utilizam simultaneamente.
Os agentes precisam de respostas previsíveis e fluxos de trabalho observáveis
Os agentes precisam entender claramente o que aconteceu após cada solicitação. Se a resposta for vaga, eles ficarão sem saber se a tarefa ainda está em execução, se falhou completamente ou se foi concluída sem enviar uma resposta.
Fluxos de trabalho mais longos dificultam ainda mais a recuperação quando algo dá errado. Se uma etapa retornar um resultado pouco claro, o agente poderá repeti-la, avançar para outra etapa ou continuar antes que a tarefa anterior seja realmente concluída.
Isso nem sempre é um problema. Recuperar a mesma documentação duas vezes é praticamente inofensivo. Criar o mesmo pedido duas vezes não é inofensivo. O mesmo se aplica à publicação ou exclusão de conteúdo. O agente precisa de uma maneira de verificar o que já aconteceu antes de enviar a solicitação novamente.
A API da Kinsta faz isso em algumas ações mais demoradas por meio de um ID de operação. Em vez de manter a solicitação aberta, ela retorna um ID que o software pode verificar mais tarde para saber se a tarefa ainda está em execução ou se foi concluída.
Você também precisa de visibilidade suficiente para descobrir o que deu errado quando um fluxo de trabalho falha. Uma mensagem de erro final pode não fornecer muitas informações. Talvez seja necessário verificar qual solicitação travou, se o WordPress acionou outro serviço, o que aconteceu no banco de dados ou se o agente enviou a mesma solicitação mais de uma vez.
O Kinsta APM e os registros do servidor podem ajudar a rastrear essa atividade, enquanto um ambiente de teste oferece às equipes um local mais seguro para testar fluxos de trabalho executados por agentes antes que eles possam afetar os dados de produção.
Com um visitante humano, um fluxo de trabalho com problemas geralmente se torna evidente rapidamente. Alguém vê o erro e o relata. Com um agente, a falha pode permanecer oculta em várias etapas automatizadas. Respostas previsíveis e um alto nível de observabilidade facilitam muito a identificação e a correção desses problemas.
A camada de hospedagem também pode ter uma interface para máquinas
Uma arquitetura preparada para agentes não se limita ao próprio WordPress. Considere duas camadas voltadas para máquinas: o site e a infraestrutura que oferece suporte a ele.
No nível do WordPress, a Abilities API e o MCP Adapter podem disponibilizar conteúdo e funcionalidades para ferramentas externas. Um agente pode recuperar dados, criar conteúdo ou acionar o fluxo de trabalho de um plugin. No nível da hospedagem, as APIs podem disponibilizar tarefas operacionais que, de outra forma, exigiriam que alguém as realizasse por meio de um painel de controle.
A API da Kinsta oferece aos desenvolvedores acesso programático a tarefas como recuperar informações de sites e ambientes, gerenciar domínios, gerenciar o cache e realizar outras operações de hospedagem. Isso possibilita fluxos de trabalho que vão além do próprio aplicativo WordPress. Uma ferramenta pode verificar um ambiente antes de realizar uma ação, acionar uma tarefa de infraestrutura ou incorporar informações a um processo automatizado mais amplo.
A Kinsta também demonstrou um servidor MCP desenvolvido com base em sua API, que permite que um cliente de IA use determinadas funções de hospedagem como ferramentas. Isso pode incluir inspecionar ambientes, limpar o cache, clonar um site ou verificar informações de plugins sem exigir que alguém navegue pelo MyKinsta em cada etapa.
Um agente pode fazer muitas coisas sem ter acesso a toda a conta de hospedagem. Se ele precisar apenas limpar o cache, verificar um ambiente ou recuperar dados de plugins, deverá poder acessar somente esses recursos. Não há vantagem em conceder permissões mais amplas apenas porque a conexão existe.
O MyKinsta continua cuidando das tarefas realizadas por pessoas, como verificar configurações, solucionar problemas e gerenciar sites no dia a dia. As APIs são úteis quando essas mesmas tarefas de hospedagem precisam se conectar a outra solução, seja um processo de implantação, uma ferramenta interna, um fluxo de trabalho de agência ou um sistema de IA.
As agências devem incluir a preparação para agentes nas revisões de arquitetura
Você não precisa forçar a inclusão de agentes de IA ou MCP em todos os projetos WordPress neste momento. A decisão mais inteligente é evitar escolhas que dificultem a adição desses fluxos de trabalho mais tarde, especialmente se um cliente voltar a solicitá-los depois que o site já estiver desenvolvido.
Em um novo projeto ou em uma grande reformulação, vale a pena perguntar:
- Quais tarefas os clientes ou funcionários poderiam delegar a um agente no futuro?
- Quais dados ou funções do site o software deve poder acessar?
- Quais ações devem sempre exigir uma etapa de aprovação humana?
- Como o agente comprovará sua identidade e o que tem permissão para fazer?
- O que acontecerá se o tráfego automatizado aumentar rapidamente?
- Como a equipe identificará e solucionará problemas quando um fluxo de trabalho falhar?
Essas respostas podem influenciar tudo, desde a escolha de plugins e o design da API até as permissões e a hospedagem. Elas também afetam decisões menores. Um fluxo de trabalho incorporado a uma tela administrativa criada para uma única finalidade é mais difícil de reutilizar posteriormente do que uma função que outro sistema pode chamar diretamente.
O estudo de caso da Sod mostra como esse tipo de flexibilidade pode funcionar na prática. A agência gerencia mais de 400 sites WordPress e usa a API da Kinsta para automatizar tarefas que, de outra forma, exigiriam supervisão manual.
Não se trata de um fluxo de trabalho de agentes de IA, mas ele demonstra o valor de uma infraestrutura que oferece ao software uma maneira compatível de interagir com as operações de hospedagem, em vez de exigir que todas as tarefas sejam realizadas por meio de um painel de controle.
Esse tipo de flexibilidade se torna mais útil à medida que as expectativas dos clientes mudam. Um fluxo de trabalho que começa hoje como uma automação interna pode posteriormente se conectar a um assistente de IA, um cliente MCP ou outro sistema empresarial. Se a função subjacente já tiver uma interface organizada e permissões adequadas, adicionar essa nova camada será muito mais fácil.
O mesmo princípio se aplica ao planejamento para agentes. As agências não precisam automatizar todos os fluxos de trabalho agora. Elas precisam evitar desenvolver sites com base na premissa de que uma pessoa sempre recuperará informações, executará ações ou gerenciará o sistema subjacente.
Incluir a preparação para agentes nas revisões de arquitetura oferece aos clientes mais flexibilidade para adotar novos fluxos de trabalho mais tarde, sem precisar reformular o site desde o início.
Desenvolva para as pessoas e para o software que atua em nome delas
O WordPress ainda precisa funcionar primeiro para as pessoas. Páginas, formulários, navegação e uma experiência do usuário sólida não deixarão de existir. O que muda é que essas opções não são mais as únicas maneiras pelas quais alguém, ou algo, pode usar o site.
Uma parcela cada vez maior desse trabalho começa a ser realizada sem que ninguém precise navegar pelo WordPress. Um agente pode recuperar informações, acionar uma ação e avançar para a próxima etapa em poucos segundos. Isso torna a estrutura interna muito mais importante. Os desenvolvedores precisam saber exatamente o que o agente pode acessar, quanto acesso ele tem, se o site consegue acompanhar a demanda e onde procurar quando algo falha.
Você não precisa reformular todos os sites WordPress em torno de agentes de IA hoje. Mas precisa deixar de presumir que todas as interações futuras começarão com uma pessoa abrindo um navegador. A hospedagem gerenciada para WordPress da Kinsta oferece aos desenvolvedores o desempenho, a visibilidade e as ferramentas necessários para oferecer suporte a visitantes humanos e fluxos de trabalho cada vez mais automatizados.
Seu próximo cliente ainda pode ser humano. A diferença é que um software poderá interagir com seu site em nome dele.
Carlo é um apaixonado por webdesign e desenvolvimento frontend. Ele tem mais de 10 anos de experiência com WordPress e colaborou com diversas universidades e instituições educacionais na Itália e na Europa. Carlo já publicou inúmeros artigos e guias sobre WordPress, tanto em sites italianos quanto internacionais, além de revistas impressas. Você pode seguir ele no LinkedIn e no X.
