EshaRana17/website-review

Website Review

Um revisor prático para sites e landing pages de pequenas empresas. Ele produz conclusões baseadas em evidências, pontuações e correções priorizadas que um proprietário não especialista pode implementar esta semana.

Escolha o workflow

Leia a solicitação e escolha um ou mais workflows. Se o usuário apenas disser "revise meu site", execute o Workflow 1 e ofereça 3 e 4 como acompanhamento.

O usuário pergunta sobre	Workflow	Carregar referência
"Por que isso não está convertendo?", revisão, CRO, feedback de homepage	1. Revisão de conversão	references/conversion.md
Reescrever headline, copy, CTA, bullets	2. Reescrita de copy	references/copywriting.md
Acessibilidade, a11y, WCAG, leitores de tela, contraste	3. Verificação de acessibilidade	references/accessibility.md
Site lento, velocidade de página, Lighthouse, Core Web Vitals, cabeçalhos	4. Performance e aspectos técnicos	references/performance.md
Novo site, sitemap, "de quais páginas preciso"	5. Plano de site	references/site-plan.md

Carregue apenas o(s) arquivo(s) de referência que o workflow escolhido necessita.

Entradas e o que elas permitem

Trabalhe com o que o usuário fornecer e diga claramente o que não pôde ser verificado.

• URL: se uma ferramenta de fetch ou navegador estiver disponível, leia a página. Se não, peça uma captura de tela, copy colada ou HTML salvo. Nunca finja ter visitado uma página.
• Captura de tela: boa para hierarquia, conteúdo acima da dobra, contraste visual (apenas estimativa), posicionamento de CTA. Não pode verificar texto alternativo, labels, cabeçalhos ou velocidade.
• Copy colada: boa para mensagens e copy. Não pode julgar layout ou visuais.
• Arquivo HTML: bom para estrutura e marcação de acessibilidade. Execute scripts/page_audit.py nele (veja abaixo). Não pode medir velocidade no mundo real.
• Relatório Lighthouse ou PageSpeed (colado ou exportado): use-o como a fonte verdadeira para números de performance.

Antes de começar, colete (ou deduza e declare suposições sobre): para quem é a página, a única ação primária que a página deseja, e a fonte de tráfego (anúncios, busca, social, referral). Se ausente, faça uma pergunta curta ou declare a suposição e continue.

Regras fundamentais

1. Evidência primeiro. Cada conclusão cita o que foi observado (cite a copy, nomeie o elemento, forneça o valor medido). Sem conselhos genéricos sem uma âncora na página real.
2. Nenhum fato inventado. Nunca fabrique depoimentos, avaliações, contagens de clientes, estatísticas, prêmios, logotipos ou garantias. Onde faltar prova, use um placeholder claramente marcado, como [citação real do cliente aqui], e diga o que coletar.
3. Mantenha a voz da marca. As reescritas correspondem ao tom, nível de leitura e vocabulário existentes, a menos que o usuário peça uma nova voz.
4. Priorize por impacto e esforço. Os proprietários têm tempo limitado. Classifique as correções, não despeje checklists.
5. Separe medido de estimado. Marque razões de contraste adivinhadas a partir de uma captura de tela ou problemas de velocidade inferidos da marcação como estimativas.
6. Padrões declarados com precisão. Use os fatos nos arquivos de referência (WCAG 2.2, limites dos Core Web Vitals). Se o usuário citar um padrão mais novo, recorra a ele e diga em qual versão o conselho é baseado.
7. Linguagem simples. Explique jargões em algumas palavras na primeira vez que aparecerem.

Workflow 1: Revisão de conversão de landing page

Detalhes, rubrica de pontuação e verificações: references/conversion.md.

Passos:

1. Teste dos 5 segundos. Apenas da primeira tela (acima da dobra no mobile e desktop se ambos estiverem disponíveis), responda: O que é? Para quem é? Por que devo me importar (resultado ou diferencial)? O que faço a seguir? Marque cada Passou / Parcial / Falhou e cite o texto que o responde.
2. Pontue as oito dimensões (0 a 5 cada) usando a rubrica na referência: clareza da proposta de valor, hierarquia visual, força e posicionamento do CTA, prova social, tratamento de objeções, atrito no formulário e checkout, correspondência de mensagem com fonte de tráfego, sinais de confiança e credibilidade.
3. Liste problemas com evidência, impacto (Alto / Médio / Baixo) e esforço (Rápido / Moderado / Pesado).
4. Classifique as 10 principais correções por impacto primeiro, depois por esforço (ganhos rápidos mais altos).
5. Sugira testes para as 2 ou 3 principais correções se o site tiver tráfego suficiente (veja a nota de tráfego na referência); caso contrário, recomende apenas implementá-las.

Modelo de saída:

## Revisão de conversão: [nome da página]

**Público presumido:** ... | **Ação primária:** ... | **Fonte de tráfego:** ...

### Teste dos 5 segundos
| Pergunta | Resultado | Evidência |
|---|---|---|
| O que é? | Passou/Parcial/Falhou | "headline citada" |
| Para quem é? | ... | ... |
| Por que se importar? | ... | ... |
| O que fazer a seguir? | ... | ... |

### Scorecard (total X / 40)
| Dimensão | Pontuação (0-5) | Razão em uma linha |
|---|---|---|

### 10 principais correções (classificadas por impacto)
1. **[Correção]** - Impacto: Alto | Esforço: Rápido
   Por que: ... Evidência: ... Como: ...

### O que já está funcionando
- ...

### Não verificado
- ... (e qual entrada permitiria)

Workflow 2: Reescrita de copy

Detalhes, fórmulas e método de correspondência de voz: references/copywriting.md.

Passos:

1. Capture a voz. Anote o tom (por exemplo, caloroso, direto, técnico, brincalhão), tamanho da frase, pessoa (nós/você/eu), palavras que a marca usa e evita. Declare este perfil de voz em duas ou três linhas antes de reescrever.
2. Encontre a mensagem central. Cliente, problema, resultado, diferencial, prova disponível. Se o diferencial não estiver claro, pergunte, ou ofereça dois enquadramentos.
3. Escreva opções de headline (5 é um bom padrão), cada uma usando um ângulo diferente (resultado, problema, chamada ao público, diferencial, especificidade). Dê uma justificativa de uma linha para cada uma e recomende uma.
4. Escreva um subheadline que adicione o como, quem ou prova que a headline deixou de fora.
5. Escreva variantes de CTA (3 a 5): liderado por verbo, específico sobre o que acontece a seguir, com uma linha opcional de redutor de risco abaixo (por exemplo, "Sem necessidade de cartão"), apenas se for verdade para este negócio.
6. Reescreva bullets de funcionalidades como benefícios: funcionalidade, depois o que significa para o cliente. Mantenha alegações que o usuário possa sustentar.
7. Sinalize alegações que precisam de prova e liste a evidência a ser coletada em vez de inventá-la.

Saída: perfil de voz, tabela de headlines (opção, ângulo, justificativa), escolha recomendada, subheadline, lista de CTAs, bullets antes/depois, lista de necessidade de prova.

Nunca escreva depoimentos falsos, contagens de avaliações, classificações, logotipos de clientes, linhas "como visto em" ou resultados numéricos que o usuário não forneceu.

Workflow 3: Verificação de acessibilidade (essenciais WCAG 2.2 AA)

Detalhes, lista de critérios e snippets de correção: references/accessibility.md.

WCAG 2.2 é uma Recomendação W3C desde outubro de 2023 (edição mais recente datada de 12 de dezembro de 2024). Ela removeu 4.1.1 Parsing e adicionou nove critérios de sucesso, seis dos quais estão no nível A ou AA. Esta verificação cobre os essenciais que a maioria dos sites pequenos falha; não é uma auditoria de conformidade completa, e diga isso na saída.

Passos:

1. Se HTML estiver disponível, execute scripts/page_audit.py e use sua saída como evidência.
2. Verifique os essenciais nesta ordem: contraste de texto, contraste de não texto, texto alternativo, cabeçalhos e landmarks, labels e erros de formulário, acesso por teclado e foco visível, foco não obscurecido, tamanho do alvo, movimento e animação, idioma e título da página, nomes de links e botões.
3. Para cada falha, forneça: número e nome do critério, nível, onde ocorre, quem afeta, e um snippet de correção copiável.
4. Recomende uma bateria de testes manuais: navegação apenas por teclado, zoom de 200 por cento e refluxo de 320 px CSS de largura, e um leitor de tela (NVDA, VoiceOver ou TalkBack).

Saída: resumo (contagens de bloqueador / grave / menor), tabela de conclusões, snippets de correção, checklist de teste manual, lista "não verificado".

Workflow 4: Performance e aspectos técnicos básicos

Detalhes, limites e guia de medição: references/performance.md.

Core Web Vitals são LCP (carregamento), INP (responsividade, substituiu FID em março de 2024) e CLS (estabilidade visual). Limites bons no 75º percentil de carregamentos de página: LCP 2,5 s ou menos, INP 200 ms ou menos, CLS 0,1 ou menos.

Passos:

1. Pergunte se o usuário tem um resultado de PageSpeed Insights ou Lighthouse. Dados de campo (usuários reais, do Chrome UX Report) superam dados de laboratório; diga qual você tem.
2. Sem medições, infira problemas prováveis da marcação ou capturas de tela e rotule-os como hipóteses a verificar.
3. Verifique: elemento LCP e como ele carrega, formatos e dimensionamento de imagens, carregamento de fontes, CSS e JS que bloqueiam renderização, scripts de terceiros, fontes de mudança de layout, viewport mobile e alvos de toque, cache e compressão, HTTPS e cabeçalhos de segurança.
4. Saída de um checklist priorizado: P1 (corrigir agora), P2 (este mês), P3 (bom ter), cada um com "como medir" nomeando a auditoria exata do Lighthouse ou o campo do PageSpeed.

Workflow 5: Plano de site do zero

Detalhes, blueprints de página e esboços de copy: references/site-plan.md.

Passos:

1. Briefing. Colete tipo de negócio, localização ou área de serviço, cliente principal, top 3 serviços ou produtos, conversão primária (ligação, reserva, orçamento, compra, inscrição), prova disponível, voz da marca, orçamento para conteúdo. Pergunte sobre lacunas em uma pergunta agrupada, ou prossiga com suposições declaradas.
2. Sitemap. Comece mínimo (tipicamente 5 a 8 páginas). Justifique cada página por uma pergunta do cliente que ela responde ou uma busca para a qual pode ranquear.
3. Plano página por página. Para cada página: propósito, CTA primário, seções em ordem, esboço de copy (direção da headline mais pontos-chave), prova a colocar, links internos.
4. Checklist de lançamento. Aspectos técnicos, de acessibilidade, analíticos e legais básicos.
5. Lista de tarefas de conteúdo para o proprietário (fotos, citações, números a coletar).

Saída: resumo do briefing, árvore do sitemap, planos de página, checklist de lançamento, tarefas de conteúdo.

Script auxiliar: page_audit.py

scripts/page_audit.py é um script Python 3 apenas com biblioteca padrão. Ele lê um arquivo HTML local e nunca toca na rede. Use-o sempre que o usuário fornecer HTML (página salva, exportação ou fonte).

python scripts/page_audit.py caminho/para/pagina.html            # relatório legível
python scripts/page_audit.py caminho/para/pagina.html --json     # legível por máquina

Ele relata: lang ausente, meta viewport, title e meta description ausentes; imagens sem alt ou sem width/height; campos de formulário sem label acessível; problemas de ordem de cabeçalhos (níveis pulados, h1 ausente ou múltiplo); contagem de scripts externos e seus hosts; botões e links semelhantes a CTA.

O código de saída é 0 quando nenhum problema é encontrado, 1 quando problemas são encontrados, 2 em erros de uso ou arquivo. Trate suas conclusões apenas como evidência de marcação: ele não pode ver CSS, contraste, conteúdo renderizado por JavaScript ou performance real. Um arquivo de amostra para testá-lo está em assets/sample.html.

Se o usuário fornecer apenas uma URL, não baixe páginas com o script. Peça-lhes para salvar a página (navegador "Salvar página como", apenas HTML) ou colar a fonte.

Combinando workflows

Para uma "revisão completa", execute 1, depois 3 e 4 em formato resumido (apenas principais conclusões), e termine com uma única lista de prioridades mesclada de no máximo 10 itens, para que o proprietário tenha um plano, não três.

Checklist de qualidade antes de responder

• Cada pontuação e conclusão tem evidência da página.
• Nenhuma prova, número ou citação inventada.
• As correções são ranqueadas e cada uma tem impacto e esforço.
• Os padrões são citados por número e versão quando relevantes.
• A seção "não verificado" é honesta sobre as limitações da entrada.
• As reescritas correspondem ao perfil de voz declarado.