Copywriter e Desenvolvedor: a Dupla Que Constrói Páginas Que Convertem

Imagine um copywriter que escreve a manchete perfeita para uma página de captação. No dia da publicação, essa manchete sai do editor de texto e vira uma imagem PNG dentro de um banner. O título real da aba do navegador continua dizendo ‘Página inicial’. O formulário logo abaixo pede nome, telefone, e-mail, empresa, cargo e uma mensagem livre antes do primeiro clique. O texto está certo. O código não deixou ele funcionar.

O problema está na passagem de um para o outro, e ninguém ali errou sozinho. Copywriter escreve para convencer, desenvolvedor escreve para o navegador e para o Google entenderem a página. Quando os dois trabalham sem trocar informação sobre como a página é montada, a conversão perde nos dois lados: no texto que fica invisível para quem lê rápido, e no código que entrega esse texto atrasado ou fora da estrutura certa.

Hierarquia de títulos: o que o Google lê antes do visitante

A documentação do Google Search Central sobre títulos explica que o título exibido nos resultados de busca não vem só da tag <title>: o sistema também observa cabeçalhos como o <h1> e qualquer texto grande e visualmente proeminente na página. A orientação é que o título principal seja distinto de qualquer outro texto da página e se destaque como o elemento mais proeminente, evitando termos vagos como ‘Início’ e repetição desnecessária da mesma palavra.

Isso muda a forma de revisar uma página pronta. Não basta a manchete estar redigida bem: o ideal é que ela esteja numa tag de título real, como <h1> ou <h2>, e não dentro de uma imagem. A mesma documentação lista texto grande e em destaque visual entre os sinais que o Google considera para gerar o título na busca, então um <div> com fonte grande também pode ser lido assim. A tag de cabeçalho certa deixa esse sinal explícito e não depende de estilo.

O mesmo documento do Google Search Central sobre títulos exibidos na busca também recomenda marcar a marca do site de forma concisa, separada do título da página por um delimitador simples, como dois pontos. E a diretriz de conteúdo útil do Google reforça que a prioridade é o conteúdo pensado para quem lê, não para manipular posição no ranking, questionando se o texto deixaria o leitor com a sensação de ter aprendido o suficiente para resolver o que veio buscar. Um título bem escrito e bem marcado serve às duas coisas ao mesmo tempo.

Texto que carrega rápido em vez de imagem com texto

A métrica LCP (Largest Contentful Paint), descrita pelo web.dev, mede o tempo até o maior elemento visível na tela (imagem, bloco de texto ou vídeo) terminar de renderizar. Os limites oficiais, medidos no percentil 75 dos carregamentos em celular e desktop, são: até 2,5 segundos é bom, entre 2,5 e 4 segundos precisa melhorar, acima de 4 segundos é considerado ruim.

O próprio documento do web.dev usa como exemplo a página de resultados do Google: nela, o maior elemento acaba sendo um parágrafo de texto, exibido antes mesmo de imagens e logotipo terminarem de carregar. É a mesma lógica que vale para uma landing page. Uma chamada escrita em HTML real, com uma fonte do sistema ou uma fonte web já carregada, tende a aparecer assim que o navegador processa o CSS. Uma chamada com o mesmo texto embutido dentro de um JPG ou PNG depende do download e da decodificação daquela imagem, competindo por banda com todo o resto de peso visual da página.

Na prática, isso quer dizer que a decisão de ‘colocar o texto dentro da imagem do banner’, comum em templates prontos, tem custo de performance mensurável. Trocar esse texto por HTML real, com a mesma hierarquia de título discutida acima, ajuda a página a entrar no intervalo bom de LCP com menos esforço de otimização de imagem depois. O tema de velocidade de página é tratado com mais detalhe em Site Lento Perde Venda: Como Deixar Seu Site Rápido (Core Web Vitals).

Chamada visível: contraste que garante que o botão seja lido

O critério 1.4.3 do WCAG 2.1 (Contraste Mínimo) exige uma proporção de contraste de 4,5:1 para texto normal, entendido como texto menor que 18 pontos sem negrito ou menor que 14 pontos em negrito. Para texto grande (18 pontos ou mais sem negrito, 14 pontos ou mais em negrito), a exigência cai para 3:1. O próprio documento do WCAG converte esses tamanhos para pixel: 14 pontos equivalem a aproximadamente 18,5px e 18 pontos a aproximadamente 24px.

Aplicado a um botão de chamada para ação, isso significa que a cor do texto e a cor de fundo escolhidas por quem desenha a página precisam passar nesse número, não só parecer bonitas na tela do designer. Um botão em cinza claro sobre fundo branco pode estar certo do ponto de vista de marca e, ainda assim, reprovar no teste de contraste, o que tira parte da audiência da leitura da chamada antes mesmo de ela decidir clicar ou não.

Formulário curto: cada campo é uma chance de desistência

O guia de boas práticas de formulário de cadastro do web.dev recomenda pedir o mínimo possível de informação, coletando dados extras só quando há um benefício claro para quem está preenchendo. O mesmo guia orienta não duplicar campos só para conferir que o dado foi digitado certo, por exemplo pedir o e-mail duas vezes: a alternativa sugerida é enviar um código de confirmação depois.

Já o guia de fundamentos de formulário do web.dev especifica três números concretos: rótulo posicionado acima do campo, para que a pessoa escaneie o formulário rápido e associe cada rótulo ao campo certo; área de toque de botão de pelo menos 48px; e tamanho de fonte de pelo menos 16px (1rem) nos campos, porque um tamanho menor faz o Safari do iOS aplicar zoom automático na página quando o campo recebe foco.

Aqui a divisão de trabalho fica clara: cabe ao copywriter decidir quais campos realmente precisam existir naquele formulário, olhando o que a conversa exige para começar, e cabe ao desenvolvedor decidir como cada campo que sobrou é codificado, com rótulo, espaçamento e tipo de campo corretos para não travar em uma tela de celular.

Texto alternativo: acessibilidade e leitura de imagem pelo Google

O critério 1.1.1 do WCAG 2.1 (Conteúdo Não Textual) exige que todo conteúdo não textual apresentado ao usuário tenha uma alternativa em texto que sirva ao mesmo propósito. Na prática, toda imagem com função de comunicar algo precisa de um atributo alt que descreva isso.

A documentação de SEO de imagens do Google trata o alt text como o atributo mais importante de metadado de uma imagem: ele melhora a acessibilidade para quem não consegue ver a imagem, incluindo usuários de leitor de tela ou de conexão de baixa velocidade, e o Google usa esse texto, junto com visão computacional e o conteúdo da página, para entender do que a imagem trata. O mesmo documento alerta contra encher o alt text de palavras-chave repetidas.

Essa é uma linha que deveria sair da caneta do copywriter, não ficar em branco ou virar o nome do arquivo. Uma frase real, descrevendo o que a imagem mostra e por que ela está ali, serve ao mesmo tempo para quem usa leitor de tela e para o rastreador do Google.

Fluxo de trabalho: texto antes do layout, revisão na página real

Ordem que evita retrabalho: o copywriter fecha o texto final antes do layout ser fechado em código, o desenvolvedor constrói a estrutura em torno desse texto real (não de um texto de preenchimento genérico, que quase nunca tem o mesmo tamanho do texto final em português), e a última revisão acontece na página publicada ou em um link de teste real, não em um documento de texto.

O motivo do último ponto é simples: hierarquia de título, tempo de carregamento, contraste do botão e tamanho de campo de formulário só aparecem juntos na página de verdade. Uma manchete pode ler bem em um documento e ainda assim sair sem a marcação de título certa, competir com uma imagem pesada pelo mesmo carregamento, ou cair sobre um fundo que reprova no contraste mínimo. Revisar comparando texto e página renderizada, e ajustando os dois lados quando algo não bate, é o que fecha esse ciclo. Testar variações reais de texto e layout na própria página, e não só na intuição de quem escreveu, é o tema de Teste A/B na Prática: Como Descobrir o Que Converte na Sua Página.

Modelos de parceria entre copywriter e desenvolvedor

Na prática, essa dupla se organiza de formas diferentes conforme o tamanho do projeto e da agência:

• Freelancer avulso por projeto: copywriter e desenvolvedor contratados separadamente para uma página específica, com um briefing comum definindo prazo e formato de entrega do texto.
• Parceria fixa (retainer): os dois profissionais mantêm um fluxo contínuo com a mesma agência ou empresa, o que reduz o tempo de alinhamento a cada nova página.
• Agência com dev white label: a agência de copywriting ou marketing mantém o relacionamento com o cliente e subcontrata um desenvolvedor para a parte técnica, sem expor esse segundo fornecedor.
• Squad interno: copywriter e desenvolvedor participam juntos desde o briefing, o que evita boa parte do retrabalho descrito nas seções anteriores.

Os modelos de parceria entre agência e desenvolvedor, incluindo como funciona a divisão de responsabilidade e pagamento, estão detalhados em Parceria com Desenvolvedor: Modelos, Fluxo e Como Funciona na Prática e em Dev White-Label: Como Agências Entregam Sites sem Equipe de Desenvolvimento. Para quem escreve o texto e quer entender o que pedir de um desenvolvedor antes de fechar a página, o ponto de partida é Como Escrever Textos que Vendem: Copy para Quem Não É Redator.

Nenhum dado de contraste, velocidade ou formulário citado aqui substitui uma medição da própria página. Ferramentas de auditoria e o próprio código-fonte da página mostram o número real de cada projeto.

Quer uma página onde o texto e o código trabalham juntos desde o briefing? A Codech desenvolve landing pages e sites com hierarquia de título, tempo de carregamento e formulário pensados junto com o texto, não depois dele.

Falar no WhatsApp Ir para Contato