Como validamos qualidade antes de entregar

O quality gate que barra 30% dos deploys na primeira tentativa

Nenhum site Presence sai sem passar por 5 validações automáticas e 1 revisão humana. Em média, 30% dos projetos falham em pelo menos uma validação na primeira rodada e precisam de ajuste antes da entrega. A gente não esconde isso — é exatamente o ponto. Se o gate não barrasse nada, ele seria inútil. As 5 validações automáticas são: Lighthouse score acima de 90, Schema.org válido no Google Rich Results Test, llms.txt acessível e com conteúdo estruturado, links internos funcionando sem 404, e responsividade testada em 3 breakpoints. Se qualquer uma falha, o deploy é bloqueado até a correção.

Lighthouse: o número que não mente

A gente roda Lighthouse CI em todo build. O threshold é 90 em performance, acessibilidade e SEO. Não é vanity metric — é o mínimo pra garantir que o site carrega rápido em 3G brasileiro. Nos primeiros projetos a gente aceitava 80 e achava bom. Até perceber que sites com score 80 tinham LCP de 3.2 segundos, e o Google penalizava nas buscas. Subimos pra 90 e o LCP médio caiu pra 1.4 segundos. A diferença parece pequena mas impacta direto no bounce rate. O ajuste mais comum quando o Lighthouse falha é imagem não otimizada — a IA às vezes gera referências a imagens pesadas que precisam ser comprimidas manualmente.

Schema.org: validação que o concorrente ignora

Cada site sai com pelo menos 3 tipos de Schema: Organization ou LocalBusiness, WebSite com SearchAction e BreadcrumbList. Projetos com FAQ ganham FAQPage. A gente valida usando a API do Google Rich Results Test de forma automática no pipeline. Em 94% dos casos o Schema sai correto direto do Claude. Nos outros 6%, o erro mais frequente é campo obrigatório faltando — geralmente telephone ou address em LocalBusiness. O Claude tem uma tendência a omitir campos quando o briefing não menciona telefone. A gente aprendeu a incluir "use placeholder se não informado" no prompt. Parece detalhe, mas Schema incompleto não gera rich results, e o cliente perde visibilidade gratuita no Google.

Teste de llms.txt: o diferencial invisível

O llms.txt é um arquivo na raiz do site que diz aos motores de IA quem é o negócio, o que faz e como faz. A gente valida esse arquivo com uma query simulada: passamos o conteúdo do llms.txt pra um modelo de IA e perguntamos "O que essa empresa faz?". Se a resposta for precisa e completa, passou. Se o modelo confundir o negócio ou omitir o diferencial principal, o llms.txt precisa de reescrita. Esse teste parece excessivo, mas foi o que separou os sites que apareceram no Perplexity em 48 horas dos que demoraram semanas. Nos nossos testes internos, sites com llms.txt bem estruturado foram citados 3x mais em respostas de IA do que sites sem.

Revisão humana: os 6 pontos que eu checo pessoalmente

Depois de todas as validações automáticas, eu abro o site e checo 6 coisas: o headline principal faz sentido pra quem não conhece o negócio? O CTA está visível sem scroll? O tom de voz está adequado pro público do cliente? Tem algum texto genérico que a IA deixou escapar? A navegação mobile funciona com polegar? As cores têm contraste suficiente pra leitura? Isso leva 3 minutos. Em 70% dos projetos não preciso mudar nada. Nos outros 30%, o ajuste mais comum é trocar um headline que a IA fez formal demais. A IA escreve "Soluções integradas para o seu negócio" e o cliente é uma loja de açaí. O humano troca pra algo que faz sentido.