Dez testes para um site funcionar com agentes de IA

Um site está preparado para uma tarefa quando a pessoa ou o agente consegue concluí-la nas condições autorizadas. Uma soma de itens técnicos não substitui essa demonstração. Ler uma ficha, preparar uma cotação e confirmar uma compra são operações diferentes, com consequências e permissões próprias. Um portal pode passar no primeiro teste e ainda falhar nos outros dois.

O guia do web.dev consultado em outubro de 2026 relaciona operação por agentes à estrutura semântica e à estabilidade da interface. Isso orienta os testes, mas não estabelece uma certificação universal. Aqui, os dez sinais são uma proposta de auditoria: cada resultado precisa indicar tarefa, ambiente, evidência, responsável e condição de repetição.

O Portal Leadlovers, no guia sobre agentes no funil comercial, ajuda a formular a passagem entre informação, decisão e ação. Aplique essa lógica antes da tecnologia. Se o objetivo é responder dúvidas sobre entrega, o primeiro produto da auditoria é uma resposta correta com restrições visíveis. Expor uma ferramenta de pagamento nessa fase acrescenta trabalho sem resolver a dúvida.

Não aprove o conjunto por uma nota de oito em dez. Um único defeito que troca o destinatário do pedido pode inviabilizar a operação. Classifique cada falha pelo efeito: impede a tarefa, pode causar ação indevida, dificulta o uso ou melhora apenas a conveniência. Essa classificação ordena a correção.

Os primeiros testes verificam se a informação e os controles continuam disponíveis durante a tarefa. Registre o percurso completo, porque abrir a página sem erro não comprova que alguém consegue usá-la.

1. Conteúdo recuperável: abra a URL pública sem sessão e compare o HTML recebido com o texto renderizado. Registre onde aparece nome do produto, preço e restrições. A ausência no HTML inicial pede investigação da capacidade do consumidor pretendido, não migração automática de framework.
2. Interface estável: execute o caminho principal com carregamento lento e observe banners, imagens e mensagens tardias. O botão precisa continuar identificável, e um deslocamento não pode transformar a escolha em outra ação.
3. Controles compreensíveis: percorra o formulário por teclado e confira nomes acessíveis, rótulos, instruções e mensagens de erro. Um leitor de tela e um agente podem encontrar dificuldades relacionadas, mas passar num teste automatizado não demonstra acessibilidade completa.

Defina a entrada e a saída do teste antes de rodá-lo. Para uma ficha técnica, a entrada pode ser o código do componente e a saída, a especificação correta acompanhada da versão. Para o formulário, a saída inclui mostrar o erro junto do campo e preservar os demais valores preenchidos. Uma captura isolada da página aberta não comprova nenhuma dessas condições.

Use HTML nativo quando ele já expressa a ação: link para navegar, botão para executar, campo com rótulo para receber dado, porque o navegador e o agente já sabem o que cada um desses elementos faz. ARIA (atributos que descrevem a função e o estado de um elemento para tecnologias assistivas) pode complementar a semântica quando necessário. A contagem de landmarks ou a presença de um único h1, sozinhas, não explicam se a tarefa funciona. Teste o percurso e documente o elemento que falhou.

Permissão e descoberta precisam refletir a política da empresa e os destinos mantidos. Uma regra correta num arquivo não compensa um bloqueio involuntário na infraestrutura.

4. Permissões coerentes: compare a intenção da empresa com robots.txt, regras de CDN, autenticação e resposta HTTP. Diferencie busca, treinamento e visita solicitada pelo usuário. Um nome de robô enviado manualmente num teste não comprova a identidade do fornecedor.
5. Endereços úteis: siga os links de navegação e confira redirecionamentos, páginas removidas e URLs do sitemap. O destino precisa conter o material prometido, sem depender de uma pesquisa adicional por parte do comprador.

A decisão não começa por liberar uma quantidade mínima de bots. Começa pelo material que pode ser público e pelo consumidor que precisa acessá-lo. O roteiro para separar permissões de busca, treinamento e visita solicitada ajuda a transformar uma política genérica em regras específicas. Informação confidencial deve permanecer protegida por controles de acesso.

Um site pequeno pode funcionar com um sitemap simples; outro pode precisar dividir arquivos por volume ou manutenção. A auditoria deve verificar cobertura e validade, sem exigir quatro sitemaps temáticos ou datas atualizadas a cada publicação de código quando o conteúdo da página não mudou. Registre uma URL retirada, uma recém-publicada e uma revisada para conferir os três caminhos de manutenção.

Compare as diferentes representações da mesma informação e a forma como são atualizadas. O objetivo é encontrar divergências que possam mudar a decisão do comprador.

6. Dados equivalentes: compare os fatos visíveis com a marcação estruturada, os feeds e a resposta de eventual API. A unidade de preço, a disponibilidade e a entidade responsável devem representar a mesma oferta.
7. Documentação utilizável: se houver llms.txt, abra as páginas indicadas e execute uma tarefa que realmente o consuma. Sem consumidor identificado, marque este teste como não aplicável, com justificativa.
8. Atualização verificável: confira quem revisou a informação, o que mudou e se a data exibida corresponde ao histórico. Uma troca de rodapé não revalida automaticamente uma especificação antiga.

O guia do Google para recursos generativos não exige llms.txt nem marcação especial de IA. Logo, esses artefatos não devem funcionar como pedágio para aprovar um site. Também não há motivo para reprovar vários blocos JSON-LD apenas por serem vários. Procure contradições, identificação inconsistente e propriedades que não correspondem ao conteúdo.

Para preços e estoque, a idade aceitável depende do negócio. Um catálogo de consulta pode tolerar informação diária claramente datada; uma reserva pode exigir verificação na execução. Escreva essa condição no contrato da tarefa. Quando a fonte está vencida, o agente deve mostrar a limitação e encaminhar a confirmação, em vez de apresentar um número antigo como disponível.

Os últimos testes verificam se a operação reconhece erros e recupera falhas sem produzir uma ação indevida. Execute-os antes de ampliar o escopo do agente.

9. Correção rastreável: envie um erro simulado pelo canal de teste, acompanhe o recebimento e confira a alteração no local que distribui o dado. Registre quem encerra a ocorrência e qual evidência confirma a correção.
10. Confirmação e recuperação: prepare uma operação relevante, revise dados e limites antes da execução e simule falha ou repetição. A interface precisa distinguir rascunho, envio confirmado e resultado desconhecido.

A política de correção deve refletir a capacidade real da equipe. Não invente três correções passadas para preencher um requisito. Se nunca houve ocorrência registrada, publique o canal e comece o histórico com transparência. O objetivo é permitir correção, não produzir uma aparência de maturidade.

Uma transação exige testes além da interface. Verifique autorização no servidor, escopo da conta e comportamento de repetição. Se houve demora depois de enviar, consultar o estado é mais seguro que repetir cegamente. Para decidir quais operações podem avançar sozinhas, use o método de classificar impacto antes de ampliar a autonomia.

Imagine a distribuidora fictícia Vale Peças. O objetivo do piloto é preparar uma cotação de três itens e entregá-la ao vendedor. O agente pode consultar catálogo público e preencher um rascunho; não pode negociar desconto, reservar estoque ou emitir pedido, decisões que continuam com o vendedor. A equipe seleciona dez tarefas com códigos reais de teste, incluindo um item descontinuado e uma quantidade acima do estoque.

Na primeira rodada, oito tarefas chegam ao rascunho correto. Uma escolhe a unidade errada porque a página diz "caixa", enquanto o formulário mostra apenas um número. Outra envia duas solicitações depois de uma demora. A taxa de conclusão de oito em dez não autoriza lançamento: duplicação e unidade ambígua são falhas bloqueadoras desse escopo, porque cada uma pode gerar um pedido que o cliente não fez.

A correção inclui unidade no campo e na revisão final, além de identificação única da solicitação no sistema. Depois, a equipe repete os dois casos e os oito que já funcionavam. Nesta segunda rodada hipotética, dez rascunhos ficam corretos e nenhum pedido é emitido. Isso demonstra o percurso testado, sem provar desempenho em todo o catálogo.

O próximo teste muda deliberadamente uma condição: sessão expirada antes do envio. Se o sistema pede autenticação e preserva o rascunho, a recuperação funciona naquele cenário. Se perde os dados ou envia com outro usuário, o piloto volta para correção. O relatório registra versões e ambiente para permitir comparação posterior.

O custo também entra na decisão. Conte preparação das tarefas, revisão dos resultados, armazenamento dos registros e manutenção das integrações. Não guarde vídeos integrais de toda execução quando um log com identificador, etapas e capturas pontuais resolve a investigação. A política de retenção deve preservar evidências úteis e remover material redundante.

Prepare também um caso de informação insuficiente: o comprador pede uma peça, mas não informa a tensão. O resultado correto é pedir o dado que falta ou encaminhar ao vendedor, preservando o rascunho. Escolher a variante mais popular seria uma conclusão indevida. Esse teste avalia se o sistema reconhece o limite da informação, algo que não aparece numa auditoria apenas de carregamento ou marcação.

Inclua uma condição comercial vencida entre os dados de teste. A equipe deve saber se o agente está lendo a fonte atual, uma cópia em cache ou um documento antigo fornecido na conversa. Quando não houver como identificar a origem, registre essa limitação e suspenda a confirmação automática daquela condição. O problema precisa de uma resposta operacional definida, não de uma instrução vaga para "ter cuidado".

Por fim, teste a passagem para atendimento humano. O vendedor deve receber os itens escolhidos, as dúvidas pendentes e o estado do envio, sem exigir que o cliente repita tudo. Não transfira todo o histórico indiscriminadamente: envie o contexto necessário e respeite as permissões de quem recebe. Uma operação que falha de forma clara e recuperável pode oferecer mais confiança que uma demonstração perfeita sem caminho de exceção.

A ficha reúne objetivo, permissão e evidência num registro que outra pessoa consegue repetir. Use-a para aprovar uma tarefa específica e explicitar as condições ainda não testadas.

TAREFA AUDITADA
Objetivo e resultado permitido:
Público, navegador ou agente, versão e data:
Dados de entrada e origem:
Operações proibidas neste escopo:
Critérios de conclusão:
Casos: normal | dado ausente | sessão expirada | repetição | falha
Evidências: URL | etapa | resposta HTTP | registro | captura necessária
Falha encontrada e impacto:
Responsável e prazo:
Reteste e resultado:
Decisão: corrigir | testar mais | liberar neste escopo

Preencha uma ficha por tarefa crítica, reunindo os dez testes pertinentes. Marque "não aplicável" quando a funcionalidade não existe e "não verificado" quando faltou acesso ou evidência. Esses estados são diferentes de aprovado. Não transforme uma lacuna de informação em sinal verde para completar a planilha.

Encerre quando outra pessoa consegue repetir o caso, entender o resultado e verificar a recuperação. Mostre quais condições ficaram fora da avaliação, como idiomas, dispositivos ou operações de pagamento, para que ninguém leia o resultado como válido onde ele não foi testado. Amplie a cobertura a partir de erros observados e mudanças no produto. O roteiro de preparação de catálogo e compra com IA aprofunda a passagem do rascunho comercial para uma transação.

• Portal Leadlovers: agentes no funil comercial. Consulta em 6 de outubro de 2026.
• web.dev: construção de sites operáveis por agentes. Consulta em 6 de outubro de 2026.
• Google Search Central: orientação para recursos generativos. Consulta em 6 de outubro de 2026.
• Google Search Central: dados de organizações. Consulta em 6 de outubro de 2026.