Como revisar título e meta description de um site criado por IA

Um site criado por IA pode chegar à revisão com uma interface convincente e um <head> genérico. “Home”, “Landing page” ou o nome do template continuam no <title>. A meta description repete palavras-chave, promete algo que a página não entrega ou foi copiada para todas as rotas.

Esses problemas não ficam restritos ao código. O título pode aparecer na aba do navegador, no histórico e como uma das fontes usadas por mecanismos de busca. A description pode ajudar a formar o snippet exibido para uma consulta. Quando ambos contradizem o H1 e o conteúdo, o visitante recebe uma promessa antes de abrir a página e outra depois do clique.

Este guia mostra como transformar essa revisão em um processo reproduzível: inventariar, comparar, corrigir na fonte, validar a build e confirmar a versão publicada. O objetivo não é preencher uma contagem de caracteres. É fazer metadados e página contarem a mesma história.

Separe os elementos antes de revisar

Três textos próximos cumprem papéis diferentes:

Eles podem ser parecidos sem precisar ser idênticos. Uma landing pode ter um H1 mais persuasivo, enquanto o <title> acrescenta contexto suficiente para distinguir aquela rota. A description completa a promessa com público, resultado ou recorte.

Não use essa diferença para mudar a oferta escondida no <head>. Se a página não oferece diagnóstico gratuito, o title e a description também não podem oferecê-lo.

Entenda o que você controla — e o que apenas influencia

A documentação do Google sobre title links explica que o resultado pode ser formado a partir do <title>, do título visual, de headings, de og:title, de links e de outros textos da página. O mecanismo tenta representar o resultado para cada contexto; publicar um <title> não garante que ele será reproduzido literalmente.

O mesmo cuidado vale para a description. Segundo a documentação sobre snippets, o Google usa principalmente o conteúdo da página e pode escolher a meta description quando ela representar melhor a URL. O snippet também pode mudar conforme a consulta.

Portanto, evite duas promessas comuns:

• “este é exatamente o título que aparecerá na busca”;
• “esta descrição sempre será mostrada inteira”.

Você controla a qualidade e a coerência das fontes. O sistema de busca controla a apresentação final.

Comece pela versão que será publicada

Antes de editar, registre:

fonte, branch e versão:
comando de build:
pasta ou arquivo publicável:
rotas incluídas:
domínio e URLs esperadas:
página prioritária e intenção:
oferta e CTA aprovados:

Em um site estático simples, o <head> pode estar no próprio index.html. Em um projeto com componentes, ele pode vir de layout, template, arquivo de rota, CMS ou função compartilhada. Alterar apenas o HTML gerado pode resolver um pacote e perder a mudança na próxima build.

Leia fonte e resultado:

1. encontre onde cada rota define seus metadados;
2. gere a build atual;
3. abra o HTML produzido;
4. compare os valores finais com a fonte;
5. confirme se o pacote contém a versão esperada.

A documentação de Publicação ajuda a fechar o escopo: a home fica em public/index.html, enquanto outras páginas e assets preservam os caminhos referenciados.

Faça um inventário por URL

Não revise páginas de memória. Extraia uma tabela pequena:

Marque também valores ausentes, vazios, repetidos ou produzidos por fallback. Em sites gerados por IA, procure especialmente:

• “Untitled”, “Document”, “Home” ou nome de template;
• títulos iguais em rotas com intenções diferentes;
• sufixo de marca repetido duas vezes;
• ano, preço ou disponibilidade que já mudou;
• description formada por lista de palavras-chave;
• description que descreve outra página;
• H1 e title disputando assuntos diferentes;
• conteúdo visível sem evidência para a promessa do metadata.

Esse inventário complementa a auditoria SEO de um site gerado por IA. A auditoria ampla encontra várias classes de problema; aqui a decisão editorial recebe atenção por URL.

Revise o title pela intenção da página

Um title útil permite que alguém diferencie a página sem depender da posição no menu.

Confirme que ele:

• descreve o assunto real;
• é específico para aquela rota;
• usa a linguagem principal da página;
• evita repetição artificial da palavra-chave;
• inclui marca de modo conciso, quando necessário;
• remove datas e qualificadores obsoletos;
• não esconde a parte importante depois de boilerplate longo.

O Google recomenda títulos descritivos e concisos, sem keyword stuffing e sem boilerplate repetido. Não há um limite universal de caracteres: a exibição pode ser truncada conforme largura do dispositivo e contexto. Use uma visualização como alerta, não como régua editorial absoluta.

Compare sempre com o H1. Uma diferença pode ser saudável:

title: Consultoria de dados para varejo | Empresa Exemplo
H1: Decisões de estoque com dados confiáveis

Os dois textos apontam para a mesma oferta. Já este par abre uma divergência:

title: Plataforma gratuita de previsão de demanda
H1: Consultoria personalizada para operações

Antes de “otimizar”, peça a definição comercial correta.

Escreva a meta description como resumo, não como depósito

Uma description útil responde rapidamente:

1. o que existe nesta página?
2. para quem ou para qual situação?
3. qual resultado concreto a pessoa encontra?

Ela deve ser específica, legível e compatível com o conteúdo. Não precisa repetir o title palavra por palavra. Também não precisa enumerar toda a página.

Evite:

IA, site IA, landing page IA, publicar site, melhor site, site rápido.

Prefira um resumo completo:

Revise title, H1 e meta description de cada página criada por IA para alinhar busca, conteúdo e intenção antes e depois de publicar.

A documentação do Google não estabelece um tamanho máximo para a tag; informa que o snippet pode ser truncado conforme a apresentação. Uma contagem pode ajudar a perceber excesso, mas cortar uma frase boa apenas para atingir um número não garante exibição nem melhora o resultado.

Valide unicidade sem gerar texto artificial

Descrições idênticas não ajudam a distinguir páginas. Entretanto, trocar somente uma palavra em um template também pode produzir variações vazias.

Para cada rota, use dados que realmente pertencem a ela:

• categoria ou serviço específico;
• público atendido;
• localização, quando relevante e verdadeira;
• etapa do processo;
• formato do conteúdo;
• condição comercial vigente;
• resultado que o corpo demonstra.

Em catálogos grandes, geração programática pode ser apropriada. Defina campos obrigatórios, fallback seguro e teste amostras de diferentes tipos. Se faltarem dados, prefira uma descrição simples e verdadeira a uma frase inventada pelo agente.

Trate conteúdo dinâmico e rotas compartilhadas

Single-page applications e templates podem atualizar o conteúdo visível sem atualizar corretamente o <head>. Em outros casos, todas as rotas herdam o metadata da home.

Teste navegação direta e recarregamento em cada URL. Confirme:

• o servidor devolve o documento esperado;
• o title corresponde à rota atual;
• não há flash prolongado de um título genérico;
• a description está no HTML consumível pelo cliente relevante;
• a URL canônica não aponta todas as páginas para a home;
• a build estática produziu todas as rotas autorizadas.

Não corrija canonical, robots ou dados estruturados por associação sem conferir a estratégia da página. Eles se relacionam com SEO, mas têm contratos próprios.

Dê ao agente um contrato de revisão

Um pedido seguro separa inventário, decisão e edição:

Revise title, H1 e meta description deste site criado por IA.

Escopo:
- fonte e versão: [repositório, branch e commit]
- build ou pacote: [caminho]
- rotas: [lista]
- intenção e oferta aprovadas: [resumo]

1. Localize a fonte dos metadados e gere a versão atual.
2. Monte uma tabela por rota com title, H1 e meta description finais.
3. Marque ausência, duplicação, boilerplate, desatualização e divergência.
4. Proponha a menor correção para cada achado, sem editar ainda.
5. Não invente oferta, preço, prova, localização, prazo ou palavra-chave.
6. Não prometa uma apresentação exata nos resultados de busca.
7. Pare quando houver decisão editorial ou comercial pendente.

Depois da aprovação, peça mudanças apenas na fonte responsável, execute os checks do projeto e revise o diff antes de montar o pacote.

Valide antes e depois da publicação

Na build local:

1. percorra todas as rotas do inventário;
2. conte títulos e descriptions ausentes ou duplicados;
3. compare title, H1 e conteúdo;
4. confirme idioma e caracteres do português;
5. revise o HTML gerado, não apenas o componente;
6. teste a tarefa principal para evitar regressão.

Depois do deploy:

1. abra cada URL final;
2. veja o title na aba e no HTML servido;
3. inspecione a meta description recebida;
4. confirme que a versão e o domínio são os esperados;
5. registre evidência e exceções;
6. solicite novo rastreamento apenas quando isso fizer parte do processo de busca do projeto.

Se a versão publicada estiver errada, não continue editando a fonte às cegas. Confira Site ID, slug, pacote e estado do deploy. O fluxo de republicação no mesmo Site ajuda a preservar o endereço durante a correção.

Feche com coerência, não com uma pontuação

Uma revisão está pronta quando cada página tem identidade própria e nenhuma promessa depende de metadado invisível para existir. Title, H1, description e conteúdo não precisam repetir a mesma frase; precisam sustentar a mesma intenção.

O agente acelera extração, comparação e correções mecânicas. A aprovação continua humana quando envolve posicionamento, oferta ou linguagem de marca. Publique a versão aprovada, valide a URL real e então observe como os sistemas externos a interpretam — sem confundir influência técnica com controle da apresentação.