Prompts para SEO: o que a IA acelera e como conferir

A maior parte do que se lê sobre "prompts para SEO" trata de gerar texto: um rascunho de artigo, um esboço de pauta, uma variação de parágrafo. Mas boa parte do trabalho operacional de SEO não é escrita de conteúdo — é tarefa estruturada e repetitiva: agrupar uma planilha de palavras-chave por intenção, rascunhar um bloco de dados estruturados, escrever uma expressão regular para filtrar um log, montar um mapa de redirecionamento depois de uma migração, ou gerar variações de title e meta description para um lote de páginas. Esse tipo de tarefa segue um padrão claro, não depende de voz de marca, e é exatamente onde um modelo de linguagem rende mais por minuto gasto.

O problema é que o modelo não sabe se o regex está certo, se o schema usa uma propriedade que existe de fato no vocabulário do schema.org, ou se o destino de um redirecionamento realmente retorna 200. Ele sabe produzir algo com a forma certa — e forma certa não é a mesma coisa que resultado correto. Este texto passa por cinco dessas tarefas, com uma forma de estruturar o prompt para cada uma e, principalmente, o que checar antes de qualquer saída ir para produção.

Agrupar palavras-chave por intenção

Agrupar uma lista grande de palavras-chave por tema é um trabalho manual clássico: abrir uma planilha, ler termo por termo e decidir em qual grupo cada um entra. Um modelo de linguagem faz essa primeira passada rápido, desde que o prompt entregue a lista bruta — e não um resumo dela. Colar as próprias linhas da planilha, uma por vez, sem reescrever, dá ao modelo o material real para comparar; descrever a lista em prosa ("tenho um monte de termos sobre SEO local") joga fora justamente a informação que permite agrupar bem.

A conferência aqui não é ler o cluster e achar que faz sentido — é comparar uma amostra dos clusters com o que realmente aparece na busca. Se duas palavras-chave caíram no mesmo grupo, as páginas que rankeiam para cada uma deveriam ter uma sobreposição real, não apenas uma palavra em comum. É comum o modelo agrupar por string em vez de por intenção — colocar "seo para pdf" ao lado de "editor de pdf" porque as duas têm "pdf", quando a intenção de busca é completamente diferente. Verificar três ou quatro clusters manualmente antes de aceitar a lista inteira custa poucos minutos e evita construir uma estrutura de conteúdo sobre um agrupamento errado.

• Cole as palavras-chave como lista, uma por linha — não como descrição do tema.
• Peça um rótulo de cluster por grupo e a lista de termos que entram nele.
• Peça que marque como "incerto" qualquer termo que não se encaixe bem, em vez de forçá-lo em algum grupo.
• Peça a saída em tabela ou CSV, não em texto corrido — isso facilita importar e também facilita conferir.

Rascunhos de dados estruturados (schema)

Escrever um bloco JSON-LD à mão para cada página é tedioso, e é uma tarefa em que o modelo tem bastante material de referência, porque o formato do schema.org é público e bem documentado. O prompt funciona melhor quando recebe o conteúdo real da página — o texto do artigo, os campos de um produto, as perguntas de uma FAQ — e pede um tipo específico de schema, em vez de um pedido genérico de "gerar o schema desta página".

O erro mais comum aqui não é sintaxe quebrada — é propriedade inventada ou valor sem fonte. O modelo pode adicionar um campo de avaliação com uma nota que não existe em lugar nenhum da página, porque esse campo "costuma aparecer" em schema de produto. Antes de publicar, valide a marcação numa ferramenta de teste de dados estruturados e confira, campo por campo, se cada valor realmente aparece no conteúdo fornecido. Um schema tecnicamente válido, mas com um valor que a página não sustenta, é o tipo de coisa que aparece como aviso de dado estruturado inválido no Search Console meses depois.

• Cole o conteúdo real da página, não um resumo — o modelo só pode referenciar o que recebeu.
• Diga o tipo de schema esperado (Article, FAQPage, Product) em vez de deixar o modelo escolher.
• Peça explicitamente que omita qualquer propriedade sem valor confirmado no texto, em vez de preencher com algo plausível.

Expressões regulares para tarefas repetitivas

Regex aparece em SEO com mais frequência do que parece: filtrar um log de servidor para isolar as visitas de um crawler específico, extrair um subconjunto de URLs de um sitemap grande, ou escrever a regra de correspondência de um redirecionamento no .htaccess ou nas regras do servidor. É uma tarefa mecânica, e um modelo de linguagem escreve o padrão em segundos — o risco está em aceitar esse padrão sem testá-lo contra dados reais.

O prompt fica muito mais confiável quando inclui exemplos reais das duas categorias: linhas que devem casar com o padrão e linhas que não devem. Pedir "escreva um regex para URLs de categoria" é vago; colar oito ou dez URLs reais do site, marcando quais são categoria e quais não são, dá ao modelo o contraste necessário para não escrever um padrão que também casa com URLs de produto por acidente.

Se o regex vai correr contra um volume grande de linhas em tempo real, vale testar também o comportamento em strings muito longas — um padrão com grupos aninhados mal escritos pode ficar extremamente lento nesse cenário, algo que não aparece num teste com poucas linhas de exemplo, só sob carga real.

• Inclua exemplos positivos e negativos reais, não apenas uma descrição do padrão.
• Peça que o modelo explique cada parte da expressão — isso facilita revisar sem reescrever do zero.
• Teste o padrão contra uma amostra maior antes de aplicar em produção, incluindo barra final, parâmetros de query e maiúsculas e minúsculas.

Mapas de redirecionamento depois de uma migração

Migração de domínio, troca de CMS ou reestruturação de URLs sempre chega ao mesmo ponto: alguém precisa mapear cada URL antiga para o endereço novo correspondente. Com centenas ou milhares de páginas, fazer isso linha por linha é o tipo de trabalho que consome um dia inteiro sem exigir julgamento criativo — só comparação sistemática.

O prompt funciona melhor com as duas listas completas lado a lado — a exportação das URLs antigas e o sitemap novo — mais, quando disponível, o título ou H1 de cada página, porque a URL isolada às vezes não carrega informação suficiente para o pareamento. Peça que o modelo proponha a correspondência com um nível de confiança por linha, e que marque explicitamente qualquer URL antiga sem correspondência clara, em vez de forçar um destino só para preencher a planilha.

Antes de publicar o mapa, confira se o destino final de cada redirecionamento retorna 200 e não outro redirecionamento — encadear redirecionamentos, com uma URL antiga apontando para outra que por sua vez redireciona de novo, é fácil de deixar passar numa planilha grande. Vale também checar se duas URLs antigas diferentes não estão sendo mandadas para o mesmo destino sem que essa consolidação seja intencional, porque isso costuma indicar que o modelo não achou correspondência exata e escolheu a opção mais parecida por aproximação.

• Forneça título ou H1 além da URL — o endereço isolado nem sempre basta para o pareamento.
• Peça um nível de confiança por linha, não apenas o destino sugerido.
• Trate toda URL sem correspondência clara como pendente, nunca como redirecionamento forçado para a home.

Variações de title e meta description em lote

Gerar duas ou três variações de title tag para testar qual funciona melhor, ou escrever meta descriptions para um lote grande de páginas depois de uma migração, é outra tarefa em que o volume favorece automação — mas title e meta description são também o texto mais visível de qualquer trabalho de SEO, então um erro aqui aparece direto na página de resultados, em público.

O prompt rende mais quando recebe o conteúdo real ou um resumo fiel de cada página, não só a palavra-chave alvo — um title bom reflete o que a página realmente entrega, e o modelo só consegue refletir isso se tiver o conteúdo à disposição. Vale fixar restrições explícitas: faixa de caracteres, incluir o termo-alvo apenas quando ficar natural, e proibir afirmações que a página não sustenta.

Depois de gerado, meça o comprimento real de cada variação por contagem de caracteres, não por estimativa, porque o modelo erra a faixa pedida com frequência maior do que se espera. Revise também se, ao gerar em lote para páginas de palavras-chave parecidas, ele não repetiu essencialmente o mesmo title para páginas diferentes, o que cria duplicidade real no site. E leia em busca de afirmação que a página não sustenta: é comum o modelo inserir uma promessa de autoridade, como "o guia definitivo sobre X", que nada no conteúdo garante.

• Passe o conteúdo real da página, não apenas a palavra-chave, para cada title ou meta gerado.
• Fixe a faixa de caracteres no próprio prompt em vez de cortar manualmente depois.
• Proíba explicitamente superlativos sem base — "o melhor", "definitivo", "completo" — que a página não sustenta.

Por que cada saída passa por um checkpoint

As cinco tarefas acima têm uma coisa em comum: o resultado é um artefato técnico — código, marcação, uma tabela — que funciona ou não funciona, diferente de um texto onde "está mais ou menos certo" costuma ser aceitável. Um regex ou casa com a string ou não casa. Um redirecionamento ou chega em 200 ou não chega. Uma propriedade de schema existe no vocabulário ou não existe.

O modo de falha típico não é o modelo ser incapaz da tarefa — é ele produzir algo com a forma certa, formatado como se estivesse correto, escondendo uma suposição errada que só aparece sob teste: a propriedade de schema inventada, o caso de borda que o regex não cobre, o destino de redirecionamento que na prática dá erro. Quanto maior o volume processado de uma vez, maior a tentação de aceitar o lote inteiro sem conferir — e é exatamente aí que o erro se multiplica em vez de aparecer uma única vez.

A regra prática é simples: nenhuma saída dessas categorias vai direto para um arquivo de configuração, para o .htaccess ou para um campo do CMS sem passar pelo mesmo tipo de revisão que se daria ao primeiro rascunho de uma pessoa — validar o formato na ferramenta apropriada, testar contra uma amostra de dados reais, e tratar o volume como motivo para conferir mais amostras, nunca como motivo para pular a conferência.