Communitygithub.com

wvvb/redação-de-site

Use ao escrever, reescrever, revisar ou otimizar textos para um site, landing page, homepage, seção hero, página de produto, página de recurso, fluxo de onboarding, headline ou CTA. Esclareça para quem é o site, expresse o problema real ou o resultado desejado do visitante, explique como o produto o resolve e faça com que o texto soe natural, específico, atraente e crível, em vez de genérico ou gerado por IA. Use também para mensagens de site, posicionamento e auditorias de texto.

O que é redação-de-site?

Esta habilidade é um guia abrangente de copywriting para websites, focado em escrever textos que ressoam com o visitante ao invés de listar features do produto. Ela fornece princípios, regras não negociáveis, e uma metodologia para compor mensagens, desde a identificação do problema do visitante até a escrita de headlines e CTAs eficazes. A habilidade enfatiza a importância de soar natural e específico, evitando jargões de marketing e estruturas genéricas. Suporta plataformas como Claude Code, Cursor e Codex, e é útil para desenvolver copy que realmente conecte com o público-alvo, transformando visitantes em usuários engajados. O guia inclui exemplos práticos, como o caso 'Queryance', e sugere o uso de etiquetas de evidência para diferenciar práticas comprovadas de preferências editoriais.

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/wvvb/website-coprighting/tree/HEAD/website-copywriting

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Copywriting para Websites

Um site deve fazer a pessoa certa reconhecer sua situação, entender o que o produto faz e saber o que fazer em seguida.

Princípio: Escreva da realidade do visitante para fora, não da lista de funcionalidades do produto para dentro. O texto deve soar como uma pessoa que entende do trabalho, não como um profissional de marketing explicando como o marketing funciona.

Esta é uma habilidade de redação e design de informação, não um detector de IA e não uma fórmula rígida de conversão. Não otimize para soar "humano" às custas da verdade, acessibilidade ou precisão.

Etiquetas de Evidência

Versão 1.1. As etiquetas aparecem apenas em alegações de eficácia: afirmações de que algo melhora reconhecimento, compreensão, confiança ou conversão. Obrigações e etapas de fluxo de trabalho não são classificadas.

  • [E] evidência direta verificada: estudo revisado por pares ou teste documentado medindo o efeito declarado, com tamanho de efeito e limites.
  • [P] prática plausível: útil sem evidência medida direta para este público.
  • [S] preferência de estilo editorial. Itens de estilo são classificados em references/evidence.md; eles não são marcados inline nesta habilidade.

Nenhuma regra nesta habilidade é [E] para conversão de landing page. Trate conselhos de conversão como uma hipótese a ser testada no site real e nunca prometa um aumento sem medição. Alegações de eficácia não rotuladas aqui são práticas consultivas em [P]; obrigações e etapas de fluxo de trabalho não são classificadas. A classificação completa por item, fontes e experimentos candidatos estão em references/evidence.md.

Regras Inegociáveis

  1. Lidere com relevância. Nomeie um problema, tarefa ou resultado específico que o visitante pretendido reconheça. Chegue ao produto rápido o suficiente para que o visitante entenda o que está sendo oferecido. [P]
  2. Explique a conexão causal. Mostre o que o produto realmente faz para ajudar. Não substitua mecanismos por promessas. [P]
  3. Soe natural. Prefira linguagem cotidiana, substantivos específicos e verbos comuns. Mantenha a precisão técnica para públicos técnicos.
  4. Não use travessões ou meios-traços no texto proposto para o site. Substitua-os por ponto final, vírgula, dois pontos ou uma reformulação natural. Preserve a pontuação original ao citar material de origem. Se o usuário solicitar explicitamente um estilo diferente, siga-o.
  5. Sem emoções fabricadas. Não invente dor, urgência, medo, estatísticas, prova social, resultados ou recursos.
  6. Sem modelo obrigatório. Não dê a todo site a mesma sequência Problema / Agitação / Solução / Recursos / Depoimentos / CTA. Escolha as seções com base no que os visitantes precisam para decidir.
  7. Não reescreva apenas para reescrever. Se o original for mais claro, mantenha-o. Faça a menor alteração que melhore a compreensão.

Decida o que o visitante precisa entender

Antes de editar, inspecione o material fornecido pelo usuário: página ao vivo, captura de tela, texto atual, briefing ou código-fonte. Determine:

  • Público: Quem precisa disso? Use uma função ou situação reconhecível em vez de "todos".
  • Gatilho: Que evento faz com que eles busquem ajuda agora?
  • Tarefa: O que eles estão tentando realizar?
  • Obstáculo: Por que a abordagem atual falha ou exige muito esforço?
  • Custo: O que o obstáculo realmente significa para eles? Tempo perdido, perguntas sem resposta, confusão, risco ou dinheiro. Inclua apenas consequências apoiadas pelo contexto.
  • Mudança desejada: O que tornaria a próxima hora, dia ou fluxo de trabalho melhor?
  • Mecanismo do produto: Como o produto causa essa mudança, em termos concretos?
  • Evidência: O que é demonstrado, documentado ou verificado?
  • Ação: O que eles podem realmente clicar, experimentar, solicitar ou ler em seguida?

Mantenha uma distinção clara entre fatos e suposições. Se detalhes estiverem faltando, use linguagem conservadora e rotule suposições materiais em sua explicação ao usuário. Não invente clientes ou fluxos de trabalho específicos.

Construa um modelo de problema interno

Use isto como auxílio de raciocínio, nunca como texto a ser publicado:

Alguém em [situação real] está tentando [tarefa], mas [obstáculo]. Eles querem [resultado]. O produto ajuda por [mecanismo específico].

Em seguida, destile-o em um momento reconhecível. O momento é mais importante que uma categoria abstrata.

  • Abstrato: "Equipes financeiras precisam de fluxos de reconciliação simplificados."
  • Concreto: "O total de pagamento e seus registros de transação não coincidem."
  • Abstrato: "Melhore a observabilidade em implantações distribuídas."
  • Concreto: "Uma implantação falhou. Você está pesquisando três serviços para encontrar o erro."

Um bom título pode começar com o problema ou com o resultado desejado. Escolha o que mais rapidamente diz ao visitante pretendido: "Isso é para mim." Um título que começa com o problema não é automaticamente melhor se o público já sabe exatamente o que quer.

Componha a mensagem

Pense nestes beats internamente. Não os imprima como seis seções idênticas do site.

  1. Reconhecimento: Uma situação real que o visitante experimentou ou pode imaginar.
  2. Significância: O que permanece sem solução, difícil, caro ou incerto. Uma consequência específica geralmente é suficiente.
  3. Alívio: O que se torna possível ou mais simples.
  4. Mecanismo: Como o produto leva o visitante até lá.
  5. Credibilidade: Um exemplo real, demonstração, capacidade, limitação ou fonte que ganha confiança.
  6. Próxima ação: Um CTA cujo destino cumpre sua promessa.

A primeira tela geralmente deve entregar reconhecimento, a solução e um mecanismo crível sem exigir que o visitante role. Não gaste meia página dramatizando um problema que o visitante já entende.

Escreva o hero

  • Título: Um pensamento claro sobre a tarefa, problema ou resultado desejado do visitante. Especificidade vence inteligência.
  • Apoio: Nomeie quem ajuda e descreva como funciona em uma ou duas frases naturais. Remova quaisquer palavras que não mudem a compreensão do leitor.
  • CTA: Uma ação real como "Veja um exemplo", "Leia a documentação", "Experimente o demo" ou "Fale com o mantenedor", somente se essa ação existir.
  • Visual: Se houver um ou for solicitado, prefira um fluxo de trabalho real, estado da interface ou exemplo de dados antes/depois em vez de metáforas decorativas abstratas.

O título e o apoio devem fazer trabalhos diferentes. Não diga a mesma promessa três vezes em palavras diferentes.

Explique a solução como uma causa, não um slogan

Para cada recurso importante, raciocine através de:

O que faz -> o que muda para o visitante -> por que isso importa -> o que respalda a afirmação.

Exemplo:

  • Capacidade: Execute SQL gerado contra arquivos Parquet, JSON e CSV na infraestrutura do cliente.
  • O que muda: O cliente pode investigar esses arquivos sem enviar seu conteúdo para um provedor de análise hospedado.
  • Significado: Seus dados permanecem dentro da infraestrutura que operam.
  • Escopo: Isso não prova que todo o sistema não tem riscos de segurança.

Use a parte mais relevante desta cadeia no hero. Coloque o resto em uma demonstração, seção de fluxo de trabalho, FAQ ou documentação conforme necessário.

Faça o texto parecer escrito por uma pessoa

Um texto que soa humano geralmente é mais específico, menos simétrico e menos ansioso para se explicar. Parece editado, não gerado em uma passada.

Favoreça

  • Uma situação concreta em vez de um rótulo de categoria.
  • Palavras familiares em vez de jargão conceitual.
  • Detalhes que só fazem sentido para este público e produto.
  • Descrições diretas em vez de entusiasmo vazio.
  • Ritmos de frase diferentes quando ajudam o leitor a seguir uma ideia.
  • Um exemplo útil que esclarece a afirmação.
  • Limites honestos, compensações práticas e termos técnicos precisos quando estes constroem confiança.
  • Transições naturais que seguem a ideia real, não frases de conexão pré-fabricadas.

Remova ou reescreva

  • Enchimento de marketing: "Desbloqueie", "potencialize", "perfeito", "inovador", "revolucionário", "de última geração", "revolucione", "empodere" e termos semelhantes quando substituem significado.
  • Contrastes falsos: "Não é apenas X. É Y." "Pare de fazer X. Comece a fazer Y." "O futuro do X chegou." Use contraste apenas quando explicar uma diferença real, em linguagem normal.
  • Estrutura anunciada: "Nesta seção, exploraremos..." "Vamos mergulhar." "Aqui está por que isso importa." Não diga aos visitantes que você vai explicar algo; explique-o.
  • Reafirmação repetitiva: Um título, subtítulo, três cartões de recursos e parágrafo de encerramento que todos fazem a mesma afirmação.
  • Seções perfeitamente simétricas: Três cartões com padrões gramaticais idênticos, contagens de palavras idênticas e um resumo arrumado apenas para completar o layout.
  • Significado superexplicado: "Isso capacita as empresas a assumir o controle de seu sucesso." Se a consequência é óbvia, pare de escrever.
  • Linguagem emocional vazia: "Diga adeus às dores de cabeça" ou "Nunca mais se preocupe" sem uma razão concreta.
  • Truques de conversação forçados: Perguntas retóricas repetidas, anedotas falsas, humor forçado, contrações excessivas e vulnerabilidade artificial.
  • Polimento sintático que soa não natural: Frases nominais densas, sequências de adjetivos e pontuação fazendo o trabalho de frases claras.

Não faça de uma lista de palavras proibidas sua estratégia de edição. Uma palavra pode ser apropriada no contexto certo. O requisito de pontuação acima é uma regra de estilo do projeto; a tarefa mais profunda é corrigir pensamento, estrutura e evidência. Um redator que apenas remove travessões e substitui "alavancar" por "usar" não resolveu o problema.

Edite em dois níveis

Passada estrutural:

  • O problema real do leitor está visível ou a página está falando sobre si mesma?
  • Cada seção ensina algo novo ou remove uma objeção real?
  • O produto aparece antes de o visitante perder o interesse?
  • O argumento é linear apenas porque o modelo padronizou um modelo?
  • Existem resumos desnecessários, rótulos de etapa repetitivos ou narrativas exageradas de antes versus depois?
  • O conteúdo segue como este visitante específico decide, em vez de um funil de vendas genérico?

Passada de frase:

  • Uma pessoa experiente realmente diria esta frase para outra pessoa?
  • Existe um substantivo ou verbo mais específico?
  • A frase pode ser cortada sem remover um fato?
  • A frase está tentando soar impressionante em vez de explicar algo?
  • Os fatos são precisos e os benefícios são sustentáveis?
  • Existem travessões ou meios-traços no texto proposto? Remova-os.

Leia o resultado como um visitante, não como um escritor. Se soar como um discurso ensaiado, simplifique o pensamento em vez de adicionar mais truques de "humanização".

Use a psicologia com responsabilidade

Use princípios psicologicamente úteis como lentes de diagnóstico, não como desculpas para manipular pessoas. Cada princípio abaixo é [P].

  • Reconhecimento: As pessoas se engajam quando podem identificar a situação sendo descrita. [P]
  • Facilidade cognitiva: Linguagem concreta e um caminho coerente reduzem o esforço. [P]
  • Cheiro de informação: Títulos e CTAs devem prever com precisão o que vem a seguir. [P]
  • Controle: As pessoas querem saber o que podem inspecionar, alterar, manter ou desfazer. [P]
  • Confiança: Evidência, mecanismos reais e limites reconhecidos podem ser mais úteis do que grandes alegações. [P]
  • Motivação: O texto deve se conectar a algo que o visitante deseja alcançar, não inventar insegurança ou pressão. [P]

Evite escassez falsa, prova social, economias de custo inventadas, comparações de desempenho não suportadas, padrões manipuladores ou garantias implícitas.

A arquitetura da página é situacional

Não produza a mesma landing page para um CLI de desenvolvedor, um produto de operações financeiras e um utilitário de consumo.

Para públicos especialistas ou desenvolvedores: Geralmente lidere com a tarefa prática ou resultado técnico. Mostre um comando, interface, exemplo, detalhe de arquitetura ou link de documentação cedo. Evite explicar demais um problema familiar.

Para compradores operacionais: Lidere com um incidente ou responsabilidade reconhecível. Explique o que eles podem investigar, prevenir ou concluir, depois mostre o fluxo de trabalho e as restrições.

Para categorias desconhecidas: Defina o produto cedo, ancore-o em uma situação conhecida e mostre como alguém realmente o usaria. Novidade por si só não é uma proposta de valor.

Para uma página de recurso único ou já clara: Faça uma alteração precisa. Não adicione uma longa história de problema.

Cada seção deve ganhar seu lugar respondendo a uma pergunta ou objeção real. Se não o fizer, remova-a.

Exemplo: Queryance

Versão fraca, focada em recursos

Análise de código aberto para operações financeiras. Converta linguagem natural em SQL e execute-o em arquivos Parquet, JSON e CSV em sua infraestrutura.

Isso descreve a maquinaria primeiro. Faz os visitantes descobrirem o motivo para se importar.

Versão do Problema Humano

Descubra por que seus números de pagamento não coincidem.

Queryance ajuda equipes financeiras de SaaS a investigar diferenças entre seus registros. Faça uma pergunta, revise o SQL e execute-o contra arquivos Parquet, JSON ou CSV em sua própria infraestrutura.

CTA: Fale com o mantenedor

A primeira frase nomeia um trabalho real. A segunda explica para quem é o produto e como funciona. O CTA é apropriado apenas se uma forma de contatar o mantenedor realmente existir.

Uma versão que tenta demais

Ainda afogado no caos financeiro?

Pare de perder tempo com planilhas desatualizadas. Desbloqueie a reconciliação sem esforço com a próxima geração de operações financeiras inteligentes.

Isso inventa emoção, apoia-se em clichês do setor e nunca explica o mecanismo. É mais curto que a boa versão, mas menos informativo.

Estes exemplos são pontos de partida, não padrões obrigatórios. Se clientes reais usam linguagem diferente, favoreça a linguagem deles após verificar o que significam.

Modos de execução

Siga o escopo da solicitação do usuário.

Auditoria

Forneça os 3 a 5 principais problemas específicos de texto ou hierarquia. Cite o texto relevante, descreva o que um visitante entenderia errado ou perderia e recomende correções direcionadas. Identifique o que já está funcionando. Não reivindique melhorias de conversão sem medição.

Reescrita

Forneça texto pronto para produção para as seções solicitadas, usando a voz da marca existente do site

...

[truncado para tradução]

Habilidades Relacionadas