O que buscar em um fornecedor de design e desenvolvimento web: guia para quem toma a decisão

O design continua importando, mas não basta que o site tenha boa aparência. Convém pedir provas que a empresa possa verificar: que mecanismos de busca e assistentes de IA consigam ler o conteúdo, que pessoas com deficiência consigam usar o site, que ele carregue bem para visitantes reais e que as contas e os dados fiquem em nome da empresa. Uma promessa de «otimizar para IA» sem prova é um sinal de alerta.

Este guia foi pensado para quem decide ou aprova um orçamento, e não para quem programa. Cada critério explica por que importa para a empresa, o que pedir, como verificar e que sinal deve gerar dúvida. Os termos técnicos são explicados em palavras simples e, quando o detalhe é necessário, ele aparece sob o rótulo «Para a equipe técnica», que pode ser repassado diretamente à área de sistemas ou ao fornecedor.

Convém esclarecer de onde este texto é escrito. A CookingMetrics não projeta nem desenvolve sites para terceiros. Oferece consultoria e acompanhamento a equipes de desenvolvimento, principalmente auditorias para ecommerce e empresas B2B e B2B2C que implementam padrões em sites, lojas e aplicações web, e também desenvolve suas próprias aplicações e plataformas. Este artigo é escrito do ponto de vista de quem revisa o que um fornecedor entrega, não de quem o vende.

Em síntese

• Um fornecedor se avalia por entregáveis com prova e data, não por promessas. Este guia propõe dez critérios, cada um com o que pedir, como verificar e que sinal de alerta observar.
• O Google documenta, em uma página atualizada em 10 de dezembro de 2025, que não há requisitos adicionais para aparecer em suas respostas com IA e que não são necessários arquivos nem tags novas. Isso descreve o Google; não cobre outros sistemas.
• Este guia não apresenta evidência de que cumprir os dez critérios aumente posições, visitas, menções em respostas de IA ou vendas. Eles se justificam porque beneficiam as pessoas, os mecanismos de busca e a manutenção do site.
• O teste de aceitação é acordado por escrito antes da entrega: uma medição inicial com data e as mesmas ferramentas para medir de novo depois.
• Na medição própria de 4 de setembro de 2026, a CookingMetrics constatou que seu site anunciava um mapa que não existia, tinha um arquivo escrito mas não publicado e carregava seu conteúdo principal em 6,15 segundos. O que parecia resolvido no código não estava resolvido no site em funcionamento.

O que mudou: não são apenas pessoas com navegador que visitam

Um site recebe hoje visitas de pessoas com navegador, de robôs de mecanismos de busca e de assistentes ou agentes de inteligência artificial: programas que leem páginas para responder a uma pergunta ou para realizar uma tarefa em nome de alguém. Essa lista já existia em parte. O que muda é quanto do que se publica depende de uma máquina poder lê-lo sem ajuda.

Neste tema, três tipos de afirmação se misturam, e convém separá-los para não pagar por promessas:

• Documentado por quem opera o sistema. Por exemplo, o Google explica como processa as páginas e o que recomenda. É o mais sólido, desde que seja citado com sua data.
• Prática habitual do setor. Revisar o código de uma página ou percorrer uma compra com teclado são verificações difundidas, embora a documentação citada neste guia não as apresente como requisito.
• Hipótese. É plausível que os agentes que operam uma página tropecem onde tropeçam as pessoas que usam tecnologias assistivas, como formulários sem rótulos ou botões sem nome. É uma hipótese razoável; este guia não a demonstra e não a usa como argumento de venda.

Dez critérios, com sua prova

Os critérios se agrupam em três blocos: que o site possa ser lido e usado, que seja rápido e bem comunicado aos mecanismos de busca e aos robôs, e que a empresa mantenha o controle. Cada um tem quatro partes: por que importa para a empresa, o que pedir ao fornecedor, como verificar sem depender da palavra dele e que sinal de alerta deve gerar dúvida.

Bloco A: que o site possa ser lido e usado

1. O conteúdo importante está na página como o servidor a entrega

• Por que importa para a empresa: muitos sites modernos montam a página no navegador do visitante com um programa chamado JavaScript. Um robô ou um assistente que não executa esse programa pode receber uma página quase vazia. O Google indica que as páginas passam por uma fila antes de seu JavaScript ser executado e recomenda que o servidor entregue a página já montada (o que se chama renderização no servidor ou pré-renderização), entre outros motivos porque nem todos os robôs executam JavaScript (JavaScript SEO basics, página atualizada em 4 de março de 2026, consultada em 27 de outubro de 2026).
• O que pedir: que os textos, os títulos, os links e os preços importantes estejam na página como o servidor a entrega, sem depender de um programa que é executado depois.
• Como verificar: pedir a alguém da equipe que abra uma página-chave, clique com o botão direito e escolha «exibir código-fonte», e procure um parágrafo do texto principal. Se ele não aparece ali, depende de um programa que é executado depois.
• Para a equipe técnica: a mesma verificação com curl sobre a URL. O inspetor do navegador não serve, porque mostra o conteúdo já processado.
• Sinal de alerta: que a demonstração se limite a capturas de tela do navegador, ou que o código-fonte seja um contêiner vazio.

2. A acessibilidade é acordada por escrito e testada

• Por que importa para a empresa: acessibilidade significa que pessoas com deficiência visual, motora, auditiva ou cognitiva possam usar o site. Existe uma norma de referência, as Diretrizes de Acessibilidade para Conteúdo Web 2.2 (WCAG 2.2), uma Recomendação do W3C publicada em 12 de dezembro de 2024 e compatível com a versão 2.1. Ela permite acordar um nível de conformidade concreto em vez de uma intenção (WCAG 2.2).
• O que pedir: um nível de conformidade escrito no contrato (por exemplo, o nível AA) com base nas WCAG 2.2, com as páginas que serão avaliadas.
• Como verificar: pedir o relatório de testes feitos por pessoas: percorrer o fluxo principal apenas com teclado, fazê-lo com um leitor de tela e revisar o contraste das cores, com as páginas testadas e a data. O resultado de uma ferramenta automática é um ponto de partida, não a prova completa.
• Para a equipe técnica: a versão 2.2 acrescenta critérios como o tamanho mínimo dos alvos de toque (2.5.8, nível AA) e a autenticação acessível (3.3.8, nível AA).
• Sinal de alerta: um «overlay», isto é, um complemento instalado sobre o site que promete corrigir a acessibilidade sem modificá-lo, apresentado como garantia de conformidade. Em 22 de abril de 2025, a Comissão Federal de Comércio dos Estados Unidos aprovou uma ordem final contra a accessiBe que a proíbe de afirmar, sem evidências, que seus produtos automatizados tornam qualquer site conforme com as WCAG ou o mantêm conforme, e exige que pague um milhão de dólares (comunicado da FTC). A ordem alcança essa empresa; não resolve o que vale para outros fornecedores nem para essa tecnologia em geral.

3. Os formulários, o carrinho e o pagamento podem ser concluídos

• Por que importa para a empresa: é o trecho em que a venda ou o contato se concretiza. Se uma pessoa que usa tecnologias assistivas não consegue concluí-lo, a empresa perde essa operação. Os agentes que operam uma página teriam de superar os mesmos obstáculos; é a hipótese apresentada acima e um tema à parte. Para este critério basta que o percurso funcione para as pessoas.
• O que pedir: que cada campo tenha seu rótulo, que todo o percurso possa ser concluído com o teclado, que os erros sejam explicados com texto e que o acesso a uma conta não dependa apenas de um teste cognitivo, em linha com o critério 3.3.8 das WCAG 2.2.
• Como verificar: fazer uma compra de teste usando apenas o teclado e, depois, com um leitor de tela.
• Sinal de alerta: elementos que parecem botões mas não são, janelas pop-up que prendem o usuário sem saída e opções que só aparecem ao passar o cursor.

Bloco B: que seja rápido e bem comunicado aos mecanismos de busca e aos robôs

4. O desempenho é medido com visitantes reais

• Por que importa para a empresa: o Google publica três métricas, chamadas Core Web Vitals, para medir a experiência: quanto tempo leva para aparecer o conteúdo principal (LCP), quanto tempo a página leva para responder a um clique ou toque (INP) e quanto o conteúdo se move enquanto carrega (CLS).
• O que pedir: uma meta escrita: LCP de 2,5 segundos ou menos, INP de 200 milissegundos ou menos e CLS de 0,1 ou menos, medidos de modo que pelo menos três em cada quatro visitas cumpram o limite (o percentil 75), separadamente em dispositivos móveis e em desktop (Web Vitals, página atualizada em 31 de outubro de 2024, consultada em 27 de outubro de 2026).
• Como verificar: exigir dados de campo, isto é, medições de visitantes reais, e não um único teste de laboratório. Um teste pontual serve para depurar; não diz como o site carrega para quem o usa.
• Sinal de alerta: uma pontuação de laboratório apresentada como prova de entrega, sem dados de campo e sem data.

5. O mapa do site, os endereços e os redirecionamentos funcionam

• Por que importa para a empresa: o mapa do site (sitemap) é um arquivo que lista as páginas que se quer que os mecanismos de busca descubram. Se anuncia endereços que não existem, é um erro simples de detectar que deixa dúvidas sobre o restante do trabalho. Em uma migração, os redirecionamentos evitam que os endereços antigos deixem de funcionar.
• O que pedir: um mapa existente e declarado no arquivo de regras para robôs (robots.txt), um endereço preferencial para cada página (o canonical) e, se houver migração, uma tabela que indique para qual endereço novo vai cada endereço antigo.
• Como verificar: abrir cada endereço anunciado e confirmar que carrega com o código de resposta 200 («correto»). O que um mapa do site deve conter é explicado em Sitemaps XML: boas práticas para Bing e Google.
• Sinal de alerta: um robots.txt que anuncia um mapa que responde 404 («não encontrado»). É exatamente o que encontramos em nosso próprio site, como se explica mais adiante.

6. Os dados estruturados descrevem o que a página mostra

• Por que importa para a empresa: os dados estruturados são tags, invisíveis para o visitante, que descrevem o conteúdo (um produto, um preço, uma avaliação) em um formato que as máquinas leem. Se dizem algo diferente do que se vê, descumprem as regras do Google.
• O que pedir: tags apenas do conteúdo que uma pessoa pode ver na página.
• Como verificar: comparar as tags com o texto visível. As políticas do Google exigem que os dados estruturados descrevam conteúdo visível para as pessoas e reflitam o que a página contém (políticas de dados estruturados, página atualizada em 10 de julho de 2026, consultada em 27 de outubro de 2026).
• Sinal de alerta: tags geradas por um modelo com dados que a página não mostra, como avaliações ou preços ausentes do texto visível. Nada disso garante resultados em destaque nos mecanismos de busca nem menções em respostas de IA.

7. As regras de acesso para robôs estão definidas com critério

• Por que importa para a empresa: o arquivo robots.txt é uma página pública que indica aos robôs quais áreas do site podem visitar. Content Signals é uma declaração adicional que indica o que se pode fazer com o conteúdo depois de baixado (buscar, responder ou treinar modelos); não bloqueia o acesso. Decidir quanto do seu conteúdo os assistentes podem usar é uma decisão de negócio, não apenas técnica. O tema é explicado em Content Signals no robots.txt.
• O que pedir: um arquivo documentado, com regras explícitas para os robôs de IA e uma decisão sobre Content Signals aprovada pela empresa.
• Como verificar: ler o arquivo no endereço público do site (seu-dominio/robots.txt), e não o que está no repositório do fornecedor, e testar o que ocorre com cada robô. O método está no teste de acessibilidade para bots.
• Sinal de alerta: um arquivo copiado de outro modelo, com blocos que se contradizem, ou um filtro de segurança que bloqueia robôs que o arquivo permite.

8. A rede de distribuição e o cache estão configurados e documentados

• Por que importa para a empresa: uma CDN (rede de distribuição de conteúdo) guarda cópias do site em servidores próximos ao visitante. Com o cache ativo, não é preciso montar a página de novo a cada visita, de uma pessoa ou de um robô. Sem ele, cada visita chega ao servidor principal.
• O que pedir: cache ativo para as páginas públicas e as regras do filtro de segurança (o firewall) documentadas, com exceções para os robôs legítimos.
• Como verificar: pedir à equipe técnica que mostre o estado do cache de uma página-chave.
• Para a equipe técnica: na Cloudflare, o cabeçalho cf-cache-status em DYNAMIC indica que a resposta não está sendo servida do cache. O guia técnico da Cloudflare para SEO e GEO explica a configuração.
• Sinal de alerta: que cada visita chegue ao servidor principal.

Bloco C: que a empresa mantenha o controle

9. As contas ficam em nome da empresa

• Por que importa para a empresa: as ferramentas em que se vê como o site se comporta e quem o visita (Google Search Console, Bing Webmaster Tools, Microsoft Clarity, a análise de dados, o gerenciador de tags) e os serviços que sustentam o site (o domínio, o DNS, a CDN) são ativos da empresa. Se a conta está em nome do fornecedor e a relação termina, os dados e a configuração ficam do lado dele.
• O que pedir: que todas essas contas estejam em nome da empresa, com o fornecedor como usuário com permissões enquanto trabalha.
• Como verificar: que alguém da empresa consiga entrar em cada ferramenta, ver quem são os proprietários e receba por escrito uma lista de acessos.
• Sinal de alerta: contas criadas com o e-mail do fornecedor, ou um DNS ao qual a empresa não consegue acessar.

Conteúdo exclusivo

Para leitores com conta

Entregar contas e continuidade

Prepare um inventário de titularidade, funções e recuperação com verificações, sem compartilhar segredos.

Entre para acessar esta seção →

Trabalhamos para oferecer conteúdos da melhor qualidade; por isso algumas destas explicações não são públicas.

10. A mensuração está documentada e existe uma medição inicial

• Por que importa para a empresa: sem uma medição prévia, ninguém pode demonstrar se a entrega melhorou alguma coisa. E se a mensuração não está documentada, depende de quem a instalou.
• O que pedir: um plano de mensuração com os eventos-chave (por exemplo, uma compra ou um formulário enviado) e o tratamento do consentimento dos visitantes, e uma medição inicial com data, feita antes da entrega.
• Como verificar: disparar os eventos em um ambiente de teste e compará-los com o plano. Depois da entrega, repetir as medições iniciais com as mesmas ferramentas.
• Sinal de alerta: «mensuração instalada» sem documento, sem lista de eventos e sem teste.

Conteúdo exclusivo

Para leitores com conta

Comparar propostas com as mesmas evidências

Diferencie requisitos indispensáveis, respostas pendentes e demonstrações em uma matriz editável.

Entre para acessar esta seção →

Trabalhamos para oferecer conteúdos da melhor qualidade; por isso algumas destas explicações não são públicas.

Por onde começar se houver pouco tempo

Se não for possível verificar os dez critérios, cinco são baratos de verificar e não exigem saber programar: o código-fonte de uma página-chave (critério 1), o relatório de acessibilidade com testes de pessoas (critério 2), o mapa do site e os endereços anunciados (critério 5), a titularidade das contas (critério 9) e a medição inicial (critério 10). É um critério da CookingMetrics baseado no custo de verificá-los; não há evidência de que sejam os de maior impacto.

O que nenhum fornecedor deveria prometer

• Posições nem menções em respostas de IA. Ninguém controla o que um mecanismo de busca ordena nem o que um assistente cita. A página do Google sobre seus recursos de IA indica que não há requisitos adicionais para aparecer nos AI Overviews nem no AI Mode e que não é preciso criar arquivos legíveis por máquina, arquivos de texto para IA nem tags novas (AI features and your website, página atualizada em 10 de dezembro de 2025, consultada em 27 de outubro de 2026).
• Um efeito do llms.txt. É um arquivo proposto para orientar os modelos de linguagem. Essa página do Google não o menciona e não fala por outros sistemas. Publicá-lo custa pouco; o que a evidência deste guia não sustenta é prometer um efeito. No nosso caso, o arquivo estava escrito e não tinha sido publicado.
• «Otimização para IA» como pacote à parte. Se um fornecedor a vende, convém perguntar que entregável concreto ela inclui e com que prova se verifica. Se a resposta for uma lista de boas intenções, é um sinal de alerta.

Protocolos para agentes: quando são necessários e quando não

É possível que uma proposta inclua siglas como MCP, WebMCP, catálogo de API, descoberta de OAuth ou protocolos de comércio. São padrões novos para que os agentes de IA não apenas leiam um site, mas executem ações nele. O anúncio da Cloudflare sobre sua pontuação de prontidão para agentes indica que vários deles estão em desenvolvimento, que o cartão de servidor MCP é um rascunho, que poucos sites adotam os padrões mais recentes e que as verificações de comércio são executadas, mas não contam para a pontuação (Introducing the Agent Readiness score, publicado em 17 de abril de 2026, consultado em 27 de outubro de 2026).

Um critério razoável é que só há caso de uso se o site oferece algo que um agente possa executar, como uma API, uma ação ou um catálogo consultável. Diante de uma proposta que inclua esses protocolos, convém perguntar quem vai usá-los, como serão testados e quem os manterá. Uma lista de protocolos como entregável, sem caso de uso, é um sinal de alerta.

Como transformar a lista em um acordo

O teste de aceitação transforma os dez critérios em um acordo verificável. Convém defini-lo antes da entrega e por escrito:

• Antes: uma medição inicial com data que inclua o código-fonte das páginas-chave, o estado do mapa do site e do robots.txt, os dados de campo de desempenho, o relatório de acessibilidade e a lista de contas com seus proprietários.
• Depois: as mesmas medições, com as mesmas ferramentas e os mesmos endereços, para que a comparação faça sentido.
• Quem verifica: idealmente, uma pessoa alheia à equipe que construiu o site.
• O que consta no contrato: cada critério com seu limite e seu método de verificação, a data de entrega e o que acontece se não for cumprido.

Uma ferramenta como o isitagentready.com serve como diagnóstico de partida, com limites que se explicam em o que o isitagentready.com mede e o que deixa de fora.

Conteúdo exclusivo

Para leitores com conta

Uma ficha operacional de escopo e aceitação

Defina entregável, condições de teste, responsáveis e recuperação em um exemplo de formulário.

Entre para acessar esta seção →

Trabalhamos para oferecer conteúdos da melhor qualidade; por isso algumas destas explicações não são públicas.

Perguntas para levar à reunião com o fornecedor

• Que parte do conteúdo é montada no navegador do visitante e que parte o servidor entrega já montada?
• Que nível das WCAG 2.2 se compromete e quem fará os testes com pessoas?
• Com que dados de campo o desempenho será medido e qual é a meta por escrito?
• Quem é o proprietário de cada conta, do domínio e do DNS?
• Que medição inicial é entregue antes de começar e como será repetida depois?
• O que inclui exatamente a «otimização para IA» e com que prova se verifica?
• Que protocolos para agentes são propostos, para que caso de uso e quem os mantém?
• O que acontece se um critério acordado não for cumprido na entrega?

Conteúdo exclusivo

Para leitores com conta

Uma reunião que termina com evidências

Aprofunde respostas comerciais e registre promessas, demonstrações e pendências por requisito.

Entre para acessar esta seção →

Trabalhamos para oferecer conteúdos da melhor qualidade; por isso algumas destas explicações não são públicas.

Um caso próprio: o que não estava em funcionamento

Em 4 de setembro de 2026, medimos o cookingmetrics.com com os critérios públicos de Agent Readiness da Cloudflare e publicamos o resultado completo em O que aprendemos ao revisar nosso site para agentes de IA. Cada ponto foi verificado com uma requisição HTTP nessa data:

• /sitemap.xml, /sitemap_index.xml e /wp-sitemap.xml retornavam 404, embora o robots.txt anunciasse um deles.
• O llms.txt retornava 404: o arquivo estava escrito e revisado no repositório e nunca foi publicado.
• A página inicial respondia com cf-cache-status: DYNAMIC, isto é, sem cache.
• O LCP de campo era de 6,15 s no desktop e de 6,20 s no celular, frente a uma meta de 2,5 s.

A lição não é sobre nenhum fornecedor: é sobre a distância entre o que está resolvido no código e o que está resolvido no site em funcionamento. É a distância que um teste de aceitação independente busca fechar, e é também a razão pela qual cada critério desta lista é verificado sobre o site real e não sobre o código.

Limites desta lista

• Não é um conjunto de garantias. Não há evidência, neste guia, de que cumprir os dez critérios aumente posições, visitas, menções em respostas de IA ou vendas. Eles se justificam por seu valor para as pessoas, os mecanismos de busca e a manutenção.
• Alcance das fontes. O que se cita do Google descreve o Google. O que se cita da Cloudflare descreve uma ferramenta e um conjunto de padrões em evolução.
• Nem todos os critérios se aplicam igualmente. Um site com pouco conteúdo dinâmico precisa menos do critério 1; um site sem catálogo nem formulários, menos do critério 3.
• Vigência. A documentação oficial muda. Cada dado leva a data de atualização de sua página e a de consulta, e convém verificá-lo de novo antes de incorporá-lo a um contrato.

O que fazer depois

O próximo passo é fazer a medição inicial antes de aceitar a entrega: solicitar os endereços, abrir o código-fonte das páginas-chave, percorrer o fluxo principal com teclado e revisar quem é proprietário de cada conta. Para saber se o acordado foi cumprido, repetem-se as mesmas medições depois, e as diferenças são registradas com data.

Se desejar que revisemos o que o seu fornecedor entregou, conheça nosso serviço de SEO técnico e o de SEO para buscas com IA. Revisamos e acompanhamos a sua equipe de desenvolvimento; não desenvolvemos o site.

Perguntas frequentes

Preciso refazer o design para que os assistentes de IA me encontrem?

Este guia não apresenta evidência de que um redesign seja necessário para isso. O Google indica que não há requisitos adicionais para seus recursos de IA. O que convém revisar é o estado atual: se o conteúdo depende de JavaScript, se o site responde com os códigos corretos e se a acessibilidade pode ser verificada. Essa revisão pode indicar ajustes pontuais ou uma reconstrução, conforme o caso.

Um overlay de acessibilidade basta para cumprir as WCAG?

A conformidade com as WCAG se verifica no site, com testes, e não é garantida por instalar um complemento. A ordem da FTC mencionada acima proíbe uma empresa de afirmar o contrário sem evidências; não alcança outros fornecedores. Antes de confiar em um overlay, convém pedir o relatório de testes sobre as páginas reais.

É necessário publicar o llms.txt?

O Google não o menciona entre os requisitos de seus recursos de IA, e essa página não cobre outros sistemas. Publicá-lo custa pouco, e prometer um efeito não tem respaldo no que este guia cita.

Quem deve ser o proprietário das contas do Google Search Console e de análise de dados?

A empresa. O fornecedor pode ter permissões de usuário enquanto trabalha, mas a propriedade das contas, do domínio e do DNS deve estar em nome de quem é dono do site.

Quem deveria fazer essas verificações?

Idealmente, alguém alheio à equipe que construiu o site. Pode ser um auditor externo ou uma pessoa da própria empresa que siga os passos de cada critério; os mais simples, como abrir o código-fonte ou revisar a titularidade das contas, não exigem saber programar.