Prompts para desenvolvimento web: 5 para a entrega

O site não atrasa por causa de código

Quem entrega site sabe: o layout fecha, o tema fica pronto, o formulário envia. Aí o projeto para. Falta o texto dos requisitos que ninguém escreveu, falta a política de privacidade, falta decidir como as URLs vão ficar, falta a copy da landing que o cliente ia mandar “semana que vem”. A entrega escorrega semanas por causa de texto, não de código.

Esse texto tem uma característica boa: é altamente estruturado. Tem forma conhecida, campos obrigatórios e pouca margem para invenção — exatamente o feitio em que um modelo de linguagem rende, desde que você entregue o dado bruto e a restrição. Os cinco prompts abaixo cobrem os pontos onde a entrega costuma travar.

1. Requisitos que cabem numa página

Transforme a conversa abaixo em um documento de requisitos.

O QUE O CLIENTE DISSE: [cole as mensagens/anotações da reunião, cru]
PRAZO E ORÇAMENTO: [o que já está acordado]
O QUE JÁ EXISTE: [site atual, CMS, integrações, quem hospeda]

Entregue: (1) o que o site precisa FAZER, em frases verificáveis;
(2) o que está fora deste projeto, listado explicitamente;
(3) as decisões que ainda dependem do cliente, com a data em que
cada uma trava o cronograma se não for tomada.

Regras: nada de "moderno", "clean", "intuitivo" — só requisito que
alguém consegue testar depois. Se a conversa não define algo,
liste como pendência, não invente o valor.

O bloco 3 é o que salva o cronograma. A maioria dos atrasos não vem de tarefa mal estimada: vem de decisão do cliente que ficou sem dono e sem data. Variações em prompts para escrever requisitos de projeto.

2. Estrutura de URL: a decisão que você não desfaz

Slug é das poucas coisas do projeto que custa caro mudar depois — cada alteração vira redirect, e redirect esquecido vira 404 indexado.

Proponha a estrutura de URLs para o site abaixo.

NEGÓCIO: [o que vende, para quem]
PÁGINAS E SEÇÕES: [lista do sitemap, mesmo bagunçada]
O QUE JÁ ESTÁ NO AR: [URLs atuais, se houver migração]

Entregue: (1) o padrão de URL por tipo de página, com exemplo real;
(2) onde usar categoria na URL e onde não usar, com o motivo;
(3) se houver migração, o mapa DE→PARA das URLs atuais.

Regras: sem data na URL de página institucional. Sem palavra de
navegação ("home", "index", "pagina"). Cada slug precisa fazer
sentido lido sozinho, fora do site.

O item 3 é o que evita o buraco clássico da migração: o site novo sobe bonito e o tráfego some porque cinquenta URLs antigas caíram em 404. Base em prompts para estrutura de URL do site.

3. Política de privacidade sem copiar a do concorrente

Escreva um rascunho de política de privacidade para o site abaixo.

O QUE O SITE COLETA: [formulários, cookies, analytics, pixel,
chat, checkout — liste tudo, inclusive o que é de terceiro]
PARA QUE USA CADA DADO: [contato, remarketing, entrega, suporte]
COM QUEM COMPARTILHA: [Google, Meta, gateway, CRM, e-mail]
ONDE FICA HOSPEDADO: [país/provedor]

Estruture por finalidade: cada dado coletado aparece junto do
motivo, do prazo de guarda e de com quem é compartilhado.

Regras: não escreva sobre coleta que eu não listei. Marque como
[VERIFICAR COM ADVOGADO] qualquer trecho que afirme obrigação
legal específica.

Isso gera um rascunho, não uma peça jurídica — e a diferença importa, porque política de privacidade errada é exposição real, não detalhe de conformidade. O ganho aqui é outro: o levantamento do que o site coleta costuma revelar dois ou três rastreadores que ninguém lembrava de ter instalado. Ponto de partida em prompts para política de privacidade do site.

4. Schema: o markup que ninguém escreve à mão

Gere a marcação de schema.org (JSON-LD) para a página abaixo.

TIPO DE PÁGINA: [institucional, produto, artigo, serviço local...]
CONTEÚDO REAL DA PÁGINA: [cole o texto]
DADOS DA EMPRESA: [nome, endereço, telefone, horário, redes]

Entregue o JSON-LD pronto para colar, e depois uma lista das
propriedades que ficaram vazias e por quê.

Regras: só marque o que EXISTE visível na página. Nada de nota,
avaliação ou preço que não esteja no conteúdo colado — markup de
coisa que não está na página é motivo de ação manual do Google.

A regra final não é preciosismo: marcar avaliação que não aparece na página é uma das causas mais comuns de perda de rich result. Se o assunto interessa, vale ler também como preparar o site para o Discover.

5. A copy da landing que o cliente ia mandar

Escreva a copy da landing page abaixo.

OFERTA: [o que é, quanto custa, o que acontece depois do clique]
PÚBLICO: [quem é, o que já tentou antes, do que desconfia]
PROVA QUE TEMOS: [números, casos, tempo de mercado — só o real]
CONCORRENTE: [o que ele promete]

Entregue: título, subtítulo, 3 blocos de benefício ancorados em
prova, tratamento das 3 objeções mais prováveis, e o CTA.

Regras: nenhum benefício sem a prova correspondente da lista.
Se faltar prova para um bloco, deixe o bloco de fora em vez de
escrever promessa genérica.

Essa restrição — benefício só com prova — é o que separa landing que converte de landing que soa igual a todas as outras. E resolve o problema real: o cliente não mandava o texto porque não sabia o que escrever, não porque estava sem tempo. Mais em prompts para cópia de página de destino e em prompts para marcação de esquema.

A linha que não dá para terceirizar

Repare no padrão dos cinco: você entrega dado bruto e proibição, o modelo devolve estrutura. Nenhum pede que ele decida por você, invente número ou afirme obrigação legal. Onde falta informação, a instrução é sempre a mesma — marcar como pendência, não preencher.

É a mesma disciplina que vale do outro lado do projeto, no texto que fica entre a agência e o cliente. A máquina escreve rápido; quem assina a entrega continua sendo você.