Auditoria de Acessibilidade para IA e Prontidão para Agentes

Sistemas de IA não podem citar, recomendar ou agir com base em conteúdo que não conseguem recuperar de forma confiável. Esta fase testa essa base antes que a equipe meça a visibilidade ou encomende conteúdo destinado a mecanismos de resposta.

Fase: P4, Estágio A — Entender. Timebox: 3–5 dias úteis para um site de marketing típico; 5–10 para um grande e-commerce, marketplace ou aplicação fortemente renderizada no cliente. Responsável: o líder de SEO técnico é responsável, com a engenharia executando testes de busca e renderização, o líder de conteúdo revisando a extraibilidade, e um responsável comercial ou jurídico decidindo a política de crawlers.

Por que esta fase vem aqui

Uma auditoria técnica convencional pergunta se mecanismos de busca podem rastrear, renderizar, indexar e ranquear o site. Esta fase pergunta se crawlers de IA, sistemas de recuperação e agentes orientados a tarefas conseguem alcançar e interpretar as mesmas informações úteis. Eles podem usar diferentes user agents, caminhos de busca, capacidades de renderização, timeouts e métodos de extração. Uma página indexável ainda pode retornar uma casca vazia, parede de consentimento, desafio de bot ou fragmentos desconectados para um cliente de IA.

Uma auditoria de acessibilidade para IA portanto pertence ao lado da auditoria de linha de base técnica , não no final da produção de conteúdo. Renderização no lado do cliente significa que JavaScript constrói conteúdo importante após o HTML inicial chegar. Sistemas de recuperação podem não executar esse código, podem parar antes de sua conclusão, ou podem extrair apenas a resposta inicial. Se o nome do produto, resposta, preço, disponibilidade ou evidência existem apenas após a execução de JavaScript, a otimização posterior de conteúdo não pode reparar a falha de acesso.

Esta fase consome as contas verificadas, análises, logs de crawler, fontes de sitemap, conjunto de URLs críticas e mapa de propriedade da fase de acesso, rastreamento e fontes de dados . Executá-la antes deixa a equipe incapaz de distinguir uma ausência genuína de falta de acesso. Executá-la após a medição de linha de base contamina a linha de base: zero citações podem refletir um site inacessível, não conteúdo fraco ou demanda.

Pular esta fase desperdiça trabalho: redatores melhoram trechos que um crawler nunca recebe, desenvolvedores adicionam esquema atrás de um desafio, ou a equipe confunde um llms.txt válido com prontidão em todo o site. Acesso, extração, compreensão e ação são capacidades separadas.

Entradas e saídas

As entradas tornam os testes reproduzíveis. As saídas formam um contrato com P5: a medição começa somente após falhas de acesso conhecidas serem corrigidas ou explicitamente aceitas.

A lista de verificação

Teste o conjunto de URLs representativo, não apenas a página inicial, e preserve evidências reproduzíveis.

1. Decida o acesso de crawlers deliberadamente

O que fazer: faça um inventário das regras de crawlers de IA no robots.txt , controles de bot de CDN, firewalls de aplicação web, camadas de consentimento e configuração de origem. Por que é importante: uma permissão no robots é apenas uma preferência; um serviço de borda ainda pode bloquear a solicitação, enquanto um bloqueio acidental por curinga não é política. Como fazer: compare as regras ativas com a matriz de políticas, busque URLs representativas com user agents aplicáveis e registre o trade-off. Ferramenta: AmICited Robots.txt & Sitemaps, um cliente de solicitação aprovado e logs de CDN/origem. Concluído quando: toda família de crawler tem uma decisão aprovada de permitir, bloquear ou condicional, e o comportamento ativo corresponde a ela.

2. Compare a resposta sem JavaScript com a página útil

O que fazer: compare o HTML inicial com a página normal do navegador. Por que é importante: um cliente de recuperação pode não executar scripts que inserem respostas, ofertas, links ou dados de produto. Como fazer: teste todo template importante antes da hidratação, o processo que anexa comportamento de aplicação ao HTML do servidor. Ferramenta: um navegador sem script ou cliente HTTP mais a página renderizada. Concluído quando: a resposta inicial contém o título, H1, conteúdo primário, fatos principais e links de descoberta; qualquer exceção tem evidência e um responsável.

3. Teste a extraibilidade do DOM renderizado

O que fazer: extraia o conteúdo principal do Document Object Model (DOM) renderizado, a representação estruturada da página no navegador, sem navegação, texto de consentimento ou variantes ocultas. Por que é importante: receber texto não é o mesmo que identificar o texto correto; ruído de template pode corromper a recuperação. Como fazer: compare o título extraído, resposta, editor, datas, fatos e links com a fonte visível em páginas longas, esparsas e comerciais. Ferramenta: inspeção do navegador, extração de texto e código-fonte da página. Concluído quando: o registro preserva o significado principal e os fatos sem posição visual ou seletores não documentados.

4. Inspecione a árvore de acessibilidade

O que fazer: revise a árvore de acessibilidade: papéis, nomes, estados, cabeçalhos, marcos e controles. Por que é importante: a semântica distingue cabeçalhos de decoração, botões de ícones e conteúdo primário de navegação. Como fazer: teste templates críticos para um H1, cabeçalhos ordenados, controles nomeados, marcos, links descritivos e alternativas de imagem significativas. Ferramenta: verificador de Árvore de Acessibilidade do AmICited e inspeção do navegador. Concluído quando: a pontuação atinge o limiar, nenhum controle crítico carece de nome, e a região principal e a próxima ação são identificáveis.

5. Valide a cobertura e veracidade dos dados estruturados

O que fazer: compare fatos visíveis com dados estruturados , marcações padronizadas como Schema.org JSON-LD. Por que é importante: a marcação esclarece entidades, ofertas, autoria e datas, mas marcação imprecisa comunica o fato errado. Como fazer: valide esquemas aplicáveis e reconcilie nomes, URLs, preços, moeda, disponibilidade, datas, avaliações e identificadores com os sistemas de origem. Ferramenta: validador, HTML renderizado e registros de origem. Concluído quando: templates críticos têm marcação aplicável válida, valores correspondem a fatos visíveis, e todo aviso material é resolvido ou explicado.

6. Revise llms.txt como um guia, não um portão

O que fazer: verifique se /llms.txt resume com precisão a organização e linka para recursos públicos canônicos. É um guia proposto em texto simples, não um controle de acesso ou sinal de ranqueamento garantido. Por que é importante: um mapa conciso reduz ambiguidade; um desatualizado desorienta agentes. Como fazer: verifique status, estrutura Markdown, descrição, destinos, URLs canônicos e responsável. Ferramenta: revisão de llms.txt do AmICited e busca direta. Concluído quando: o arquivo, se usado, não tem links quebrados/privados e um responsável pela manutenção; ausência é um achado de melhoria, não prova de invisibilidade.

7. Amostre trechos autocontidos

O que fazer: revise definições, respostas, fatos, comparações, etapas e limitações recuperados de forma independente. Por que é importante: a recuperação pode separar um parágrafo de seu cabeçalho; “funciona melhor para eles” então perde seu sujeito e comparação. Como fazer: leia pelo menos 20 trechos sem seu título ou parágrafo anterior. Ferramenta: saída de extração e revisão editorial. Concluído quando: cada um nomeia seu sujeito, responde a uma pergunta identificável, preserva condições ou unidades e evita referências não resolvidas.

8. Confirme a clareza da entidade canônica

O que fazer: verifique se o site declara quem é a organização, o que ela oferece e como suas marcas, produtos, pessoas, locais e perfis se relacionam. Uma entidade canônica é a coisa real primária à qual um nome se refere. Por que é importante: nomes inconsistentes, logotipos antigos, descrições conflitantes e URLs de perfil desconectados facilitam mesclar duas entidades ou dividir uma em várias. Como fazer: compare a página inicial, página Sobre, detalhes de contato, dados estruturados, perfis sociais, páginas de autor, nome legal e perfis importantes de terceiros. Ferramenta: ficha de fatos da entidade, páginas renderizadas e saída de dados estruturados. Concluído quando: uma ficha de fatos aprovada resolve nome oficial, apelidos, URL canônica, logotipo, descrição, propriedade, ofertas principais e perfis de mesma entidade, com conflitos registrados para correção.

9. Teste o tempo de resposta e a confiabilidade da busca

O que fazer: meça status, Time to First Byte (TTFB), redirecionamentos, timeouts e consistência da resposta sob user agents normais e de crawler relevantes. TTFB é o intervalo desde o início da solicitação até a chegada do primeiro byte de resposta. Por que é importante: 403s, 429s, respostas 5xx intermitentes, longas cadeias de redirecionamento ou origens lentas tornam o conteúdo não confiável mesmo quando uma única visita de navegador é bem-sucedida. Como fazer: execute a amostra repetível definida na tabela de limiares de mais de uma localização de rede quando a geografia importa, depois reconcilie falhas com logs e Core Web Vitals. Ferramenta: monitor de solicitações, logs de CDN/origem e AmICited Web Vitals. Concluído quando: URLs críticas satisfazem os limiares de confiabilidade e latência ou têm gravidade, causa, responsável e data de reteste.

10. Avalie WebMCP e protocolos de comércio onde criam valor

O que fazer: teste WebMCP e prontidão para comércio apenas onde o modelo de negócio suporta ações de agentes. WebMCP é uma forma emergente de um site expor ferramentas, como busca, reserva ou adicionar um item ao carrinho. Comércio agêntico abrange descoberta de produtos e transações assistidas por agentes, incluindo protocolos como ACP ou UCP. Por que é importante: conteúdo legível suporta respostas; ferramentas explícitas e dados comerciais suportam ação confiável sem screen scraping. Como fazer: mapeie tarefas valiosas do usuário, inspecione ferramentas ou protocolos declarados, valide descrições de entrada e saída e verifique confirmação, autenticação, permissão, preço, inventário e comportamento de erro. Ferramenta: verificações WebMCP e Comércio Agêntico do AmICited mais um ambiente de teste controlado. Concluído quando: capacidades aplicáveis são detectadas e testáveis com segurança, ou a verificação é marcada como não aplicável com uma justificativa de modelo de negócio aprovada e gatilho de revisão.

Ferramentas no AmICited

Abra https://app.amicited.com/accessibility para a auditoria consolidada e a explicação do recurso Acessibilidade para IA e Prontidão para Agentes . O produto reporta leituras independentes em vez de ocultar diferentes tipos de falha dentro de uma única pontuação mesclada.

1. Use o resumo para verificar a Pontuação de Acessibilidade para Agentes e registre cada componente, não apenas o estado geral.
2. Use Robots.txt & Sitemaps para verificar a cobertura de robots.txt e sitemap , depois compare a regra declarada com uma busca ativa no estilo crawler.
3. Use a revisão de arquivo para revisar llms.txt e abra cada destino listado.
4. Use o verificador de página para inspecionar a árvore de acessibilidade de uma página para cada template crítico.
5. Use as verificações de prontidão para verificar prontidão WebMCP e verificar prontidão para comércio agêntico quando essas capacidades se aplicarem.
6. Abra https://app.amicited.com/audit/web-vitals para verificar Core Web Vitals e conectar desempenho de campo com testes de solicitação em condições de crawler.

Regras de decisão

Estes são limiares operacionais de aceitação, não alegações sobre algoritmos de ranqueamento. Aperte-os para jornadas críticas de receita ou conteúdo regulado, e registre qualquer alternativa antes do teste para que o resultado não seja ajustado posteriormente.

Pontuações nunca substituem evidências concretas. Uma pontuação de acessibilidade de 85 não desculpa um botão de checkout sem rótulo, e uma permissão no robots não supera uma página de desafio retornada para a solicitação real. “Não verificado” é desconhecido, não uma aprovação nem um zero.

Entregável: o registro de achados de prontidão para agentes

Entregue um único registro de achados, não uma apresentação e um backlog separado de IA. Adicione cada achado à lista de prioridades de P2 com estes campos:

ID e título:
URLs/templates afetados:
Verificação e condição observada:
Condição/limiar esperado:
Evidência: timestamp, user agent, status, captura ou referência de log
Consequência para o negócio:
Gravidade: Crítico | Grave | Consultivo
Ação recomendada:
Responsável e aprovador:
Esforço e dependência:
Data de vencimento e data de reteste:
Decisão de política, se relevante:
Impacto na medição de P5:
Status: Aberto | Risco aceito | Corrigido | Verificado

Crítico significa que a falha impede acesso confiável, altera materialmente o significado extraído ou permite uma ação insegura. Grave significa que o acesso ou compreensão é degradado, mas um cliente representativo ainda consegue recuperar o conteúdo principal. Consultivo significa uma melhoria útil sem evidência de falha atual. Risco aceito requer o responsável nomeado, justificativa, escopo afetado, data de expiração ou revisão, e uma forma de detectar condições alteradas.

Desduplique por causa raiz: um desafio de CDN afetando crawlers convencionais e de IA é um item com múltiplos registros de evidência.

O que dá errado

Tratar a fase como opcional. Rastreamento de prompts e reescrita de conteúdo não podem compensar falhas de recuperação. Torne P4 uma condição de entrada para uma linha de base interpretável.

Bloquear por padrão e chamar retroativamente de política. Uma regra sem responsável pela decisão, justificativa ou data de revisão é configuração, não política. Apresente o trade-off entre descoberta e controle e obtenha uma decisão explícita.

Adicionar llms.txt e declarar conclusão. O arquivo não pode substituir regras de robots, bloqueios de CDN, HTML inicial vazio, marcação enganosa, trechos fracos ou timeouts. Trate-o como um guia dentro do conjunto mais amplo de evidências.

Testar apenas um user agent amigável ou a página inicial. Controles de borda variam por caminho, geografia, taxa e identidade. Teste todo template de alto valor e user agent na matriz de políticas.

Confundir aparência com extraibilidade. Uma página polida pode expor duplicatas ocultas, nomes de controle sem sentido ou uma resposta em branco sem script. Preserve evidências de código-fonte, DOM, árvore de acessibilidade e texto extraído separadamente.

Tratar desconhecido como falha ou sucesso. Reteste timeouts e crawlers não verificados; nunca converta evidência ausente em uma pontuação conveniente.

Instalar capacidades experimentais de agente sem caso de uso. Protocolos WebMCP ou de comércio devem expor ações valiosas e autorizadas. Lançar uma ação insegura ou imprecisa é pior do que marcar a capacidade como não aplicável.

Transferência para medição de linha de base

A fase de medição de linha de base recebe a lista de prioridades mesclada, pacote de evidências de teste, registro de política de crawlers, conjunto de URLs representativo e nota de prontidão. O responsável por P4 deve identificar qualquer limitação que altere a interpretação: famílias de crawler bloqueadas, templates inacessíveis, regiões intermitentes, trechos ausentes ou uma correção recente cujo efeito ainda não se propagou.

P5 pode prosseguir quando URLs críticas estão intencionalmente acessíveis às famílias de crawler incluídas na medição, conteúdo primário válido é extraível, e nenhum achado Crítico não resolvido tornaria uma pontuação zero ou baixa não interpretável. Pode prosseguir com anotações quando um bloqueio deliberado exclui um crawler conhecido ou um problema Grave afeta um template delimitado. Deve aguardar quando a intenção de acesso é desconhecida, páginas críticas falham na busca, ou o conteúdo extraído contradiz materialmente a fonte visível.

A transferência está completa quando o responsável por P5 pode responder a três perguntas sem reabrir a auditoria: quais agentes tinham acesso pretendido, quais páginas e fatos eles podiam recuperar de forma confiável, e quais limitações conhecidas devem aparecer junto à linha de base.

FAQ

Perguntas frequentes