Uma landing page criada com IA pode parecer pronta e ainda falhar no ponto mais importante: promessa errada, CTA sem destino, formulário incompleto, layout quebrado no celular, asset ausente ou Version publicada no Site incorreto.

O checklist de QA existe para transformar “parece bom” em critérios de aceite. Ele não precisa atrasar a entrega. Quando conteúdo, experiência e publicação são verificados em gates curtos, a equipe corrige problemas antes de enviar tráfego ou apresentar a URL ao cliente.

Use este roteiro depois que a estrutura e a copy estiverem aprovadas, antes da publicação e novamente na URL pública.

O que QA deve responder

Uma revisão completa responde a quatro perguntas:

  1. A página diz o que foi aprovado?
  2. A experiência funciona para quem vai acessar?
  3. O pacote representa a versão certa e pode ser publicado?
  4. A URL pública entrega exatamente essa versão?

Não misture preferência com defeito. “Quero outra imagem” pode ser ajuste editorial. “A imagem não carrega” é falha de qualidade. A distinção ajuda a liberar uma URL de revisão sem tratar toda opinião como bloqueio técnico.

Defina severidade antes de revisar

Classifique os achados para evitar discussões no fim do prazo.

Severidade Exemplo Decisão
bloqueante oferta errada, CTA quebrado, segredo no pacote, destino incorreto não publicar
alta formulário falha, mobile impede leitura, prova sem fonte corrigir antes de enviar tráfego
média hierarquia confusa, texto alternativo inadequado, metadado genérico corrigir na versão atual quando possível
baixa refinamento visual sem impacto no objetivo registrar para próxima revisão

O responsável pela campanha define o que libera a versão. O agente pode encontrar e organizar problemas, mas não deve rebaixar risco comercial, jurídico ou de privacidade.

Gate 1: conteúdo e oferta

Compare a página com o briefing aprovado, não com a última resposta do agente.

Mensagem principal

  • o H1 identifica valor para o público correto;
  • a primeira dobra deixa claro o que está sendo oferecido;
  • o CTA principal descreve uma ação real;
  • a sequência das seções responde às objeções prioritárias;
  • o tom corresponde à marca e ao canal da campanha.

Veracidade

  • preço, desconto e condição comercial estão atualizados;
  • números e estatísticas têm fonte autorizada;
  • depoimentos pertencem a pessoas ou empresas aprovadas;
  • logos, selos e marcas de clientes têm permissão;
  • garantias e comparações não foram inventadas;
  • placeholders como “Lorem ipsum”, datas genéricas ou nomes fictícios foram removidos.

Destinos

  • CTA principal aponta para a URL correta;
  • CTAs secundários não competem com o objetivo;
  • links de política, termos e contato funcionam;
  • telefone, email e endereço pertencem à operação certa;
  • parâmetros de campanha seguem a convenção definida.

Uma landing tecnicamente perfeita ainda é inadequada quando envia o público para a oferta errada. Esse gate exige aprovação humana.

Gate 2: experiência e responsividade

Teste a página em uma largura pequena e outra grande. Não confie apenas na prévia do editor.

Layout

  • nenhum conteúdo importante fica cortado;
  • texto mantém tamanho e largura legíveis;
  • botões têm área de toque suficiente;
  • elementos não se sobrepõem;
  • tabelas, cards e grids reorganizam sem rolagem lateral inesperada;
  • cabeçalho e elementos fixos não escondem o conteúdo.

Interação

  • todos os links e botões respondem;
  • foco de teclado é visível;
  • ordem de navegação faz sentido;
  • menus, accordions e modais podem ser abertos e fechados;
  • animações não impedem leitura ou ação;
  • estados de hover não são a única forma de transmitir informação.

Formulário

Quando houver captura de dados, verifique:

  • rótulos claros;
  • campos obrigatórios identificados;
  • validação compreensível;
  • estado de envio;
  • mensagem de sucesso e de erro;
  • destino real dos dados;
  • consentimento e links necessários;
  • ausência de chaves privadas no código entregue ao navegador.

Não envie um lead real apenas para “ver se funciona” sem saber onde os dados serão armazenados. Use um teste autorizado e remova o registro quando o processo exigir.

Gate 3: acessibilidade básica

O objetivo não é declarar conformidade a partir de uma lista curta. É eliminar falhas evidentes antes da publicação.

  • existe um único H1 coerente;
  • headings seguem uma hierarquia compreensível;
  • imagens informativas têm alternativa textual adequada;
  • imagens decorativas não repetem informação;
  • campos têm rótulos associados;
  • contraste permite ler texto e identificar controles;
  • foco é perceptível;
  • a página pode ser percorrida por teclado;
  • links fazem sentido fora do contexto de “clique aqui”;
  • conteúdo importante não depende apenas de cor, animação ou áudio.

Peça ao agente para executar os checks disponíveis no projeto, mas revise manualmente a experiência principal. Ferramentas encontram sintomas; não confirmam que a mensagem é compreensível.

Gate 4: metadados, analytics e privacidade

Antes de publicar, confirme:

  • título da página específico;
  • descrição coerente com oferta e conteúdo;
  • favicon e imagem social, quando previstos;
  • idioma do documento;
  • canonical, quando fizer parte da estratégia;
  • eventos e parâmetros com nomes aprovados;
  • consentimento antes de scripts que o exijam;
  • ausência de informações pessoais em código, nomes de arquivo ou comentários;
  • ausência de tokens, .env, credenciais e endpoints privados no pacote.

Não peça para o agente inventar eventos ou uma política de consentimento. Esses itens devem vir do contrato de analytics e privacidade da campanha.

Gate 5: arquivos e build

A versão aprovada precisa virar um artefato reproduzível.

Confirme:

  • a fonte e a branch autorizadas;
  • o comando de build definido pelo projeto;
  • a pasta de saída atual, não uma build antiga;
  • index.html na raiz;
  • HTML, CSS e JavaScript sem referências a caminhos locais;
  • imagens, fontes e demais assets presentes;
  • nenhuma dependência de servidor que não exista no ambiente publicado;
  • nenhum arquivo-fonte, cache, dependência ou segredo desnecessário;
  • tamanho e formato de imagens adequados ao uso;
  • ausência de erros bloqueantes nos checks do projeto.

No Site no Ar, mantenha a home em public/index.html, os assets em seus caminhos e todas as rotas em public/sitemap.xml. A documentação de Publicação descreve esse contrato.

Gate 6: destino da publicação

Antes de qualquer upload, repita em voz alta operacional:

site_id: [identificador]
slug: [slug esperado]
url: [endereço esperado]
campanha: [nome e variação]
pacote: [caminho do artefato aprovado]

Pare quando:

  • houver dois Sites plausíveis;
  • o slug não corresponder ao handoff;
  • a campanha pedir atualização e o agente estiver prestes a criar outro Site;
  • domínio próprio aparecer sem autorização;
  • o pacote for diferente do artefato revisado;
  • o limite do plano impedir a operação pretendida.

Se for a primeira publicação nesse cliente, conclua antes a Configuração do MCP.

Gate 7: deploy e URL pública

Upload concluído não é entrega concluída. O agente deve iniciar o deploy, acompanhar o estado até sucesso ou falha e abrir a URL final.

Na página pública, confira novamente:

  • headline e oferta da versão aprovada;
  • CTA principal e destino;
  • imagens, fontes e estilos;
  • formulário ou interação essencial;
  • rotas adicionais;
  • layout no celular;
  • título e descrição;
  • domínio próprio, quando estiver no escopo;
  • ausência de conteúdo antigo.

Uma resposta técnica de sucesso prova que a operação terminou. Abrir a URL prova que o resultado entregue corresponde ao pedido.

Checklist copiável para o agente

Use este pedido como base:

Faça o QA desta landing page antes de publicar.


Fonte de verdade:
- briefing: [arquivo ou documento]
- fonte autorizada: [repositório e branch]
- saída esperada: [pasta]
- Site ID, slug e URL: [destino]


1. Conteúdo:
- compare público, oferta, prova, CTA e destinos com o briefing;
- aponte placeholders, afirmações sem fonte e dados ausentes;
- não reescreva decisões comerciais sem aprovação.


2. Experiência:
- verifique mobile e desktop, teclado, foco, links, assets e formulário;
- execute os checks definidos pelo projeto;
- classifique achados por severidade.


3. Pacote:
- gere a build atual;
- confirme index.html na raiz e todos os assets;
- rejeite segredos, .env, dependências e arquivos desnecessários.


4. Publicação:
- repita Site ID, slug, URL e pacote antes do upload;
- pare diante de destino ambíguo ou bloqueio de QA;
- use o MCP do Site no Ar somente depois da liberação.


5. Verificação:
- acompanhe o deploy até o estado final;
- abra a URL e reteste headline, CTA, assets, rotas e mobile;
- entregue um relatório com checks, falhas, URL e pendências.

Esse pedido autoriza execução técnica, não mudança de oferta ou destino.

Relatório de QA que ajuda o handoff

Evite terminar com “tudo certo”. Registre evidências:

versão revisada:
briefing de referência:
checks executados:
bloqueantes encontrados e corrigidos:
exceções aceitas e responsável:
site_id, slug e URL:
estado final do deploy:
elementos retestados na URL pública:
pendências e próxima decisão:

Esse relatório complementa o fluxo de entrega de landing pages para clientes e permite que outra pessoa entenda o que foi validado.

Quando a correção vier depois da publicação, preserve o Site e siga o guia de republicação com agente de IA. Criar outro endereço para esconder uma falha divide histórico e tráfego.

O critério final

Uma landing page está pronta para publicar quando o conteúdo corresponde à decisão aprovada, a experiência essencial funciona, o pacote representa a versão certa, o destino está confirmado e a URL pública foi verificada.

A IA acelera cada check e documenta evidências. A responsabilidade por promessa, dados, marca e liberação continua com a equipe. Esse é o equilíbrio que permite publicar rápido sem transformar velocidade em retrabalho.