Um site gerado por IA pode ter boa aparência e ainda chegar à publicação com título genérico, descrição ausente, duas tags H1, imagens sem alternativa, canonical incorreto ou um noindex herdado da fase de teste.

Esses problemas não são resolvidos por um pedido vago como “melhore meu SEO”. A auditoria precisa olhar a versão realmente publicada, devolver achados verificáveis e orientar correções nos arquivos de origem.

Este guia mostra como usar a auditoria SEO do Site no Ar no painel ou pelo MCP, interpretar o relatório e conduzir um ciclo seguro de correção, republicação e nova verificação.

Por que auditar depois de publicar

Checks locais continuam importantes. A auditoria da URL pública responde outra pergunta: o que um visitante, crawler ou compartilhamento social encontra na versão ativa?

Entre o código e a URL, problemas podem surgir por:

  • build antigo;
  • arquivo omitido do pacote;
  • rota diferente da esperada;
  • configuração de produção;
  • canonical apontando para outro host;
  • robots.txt ou sitemap.xml ausente;
  • metadado correto na fonte, mas ausente no HTML entregue;
  • correção feita localmente e nunca republicada.

Por isso, a ordem correta é: publicar, auditar a URL ativa, corrigir a fonte, republicar o mesmo Site e auditar novamente.

O que a auditoria verifica

A auditoria SEO é um recurso do plano Pro. Ela acessa as Pages publicadas do Site e verifica itens técnicos básicos:

  • title, com referência de 50 a 60 caracteres;
  • meta description, com referência de 120 a 158 caracteres;
  • canonical;
  • meta robots, com atenção a noindex acidental;
  • tags Open Graph e Twitter Card;
  • presença de um único H1;
  • atributo alt em imagens;
  • idioma no elemento html;
  • charset e viewport;
  • robots.txt;
  • sitemap.xml.

O resultado traz uma nota de 0 a 100, issues estruturadas por página e regra, severidade, valor encontrado e valor esperado. Também devolve um prompt em Markdown agrupado por página para orientar o agente.

A ferramenta audita até 30 Pages publicadas. Ela exige um Site ativo com pelo menos uma Página .html, consulta a URL pública e tem limite de uso por conta. Em um Site recém-publicado, aguarde a nova versão ser servida antes de concluir que uma correção falhou.

O que a nota não significa

Uma nota alta não garante posição no Google, tráfego orgânico ou conversão. A auditoria cobre fundamentos técnicos observáveis, não toda a estratégia de busca.

Ela não decide:

  • qual palavra-chave merece investimento;
  • se o conteúdo responde bem à intenção de busca;
  • se a marca tem autoridade sobre o assunto;
  • se outras páginas competem pelo mesmo tema;
  • se uma promessa comercial é verdadeira;
  • se a página converte;
  • se mecanismos de busca vão indexar ou posicionar a URL.

Use a nota para acompanhar a integridade do conjunto de checks, não como promessa de resultado.

Prepare o Site para uma auditoria útil

Antes de rodar a ferramenta, confirme:

site_id: [identificador do Site]
url ativa: [URL publicada]
fonte: [repositório e branch]
saída: [pasta ou arquivo publicado]
versão: [commit ou referência]
objetivo: [páginas e tema prioritários]

Use o Site ID retornado por create_site ou list_sites, não o slug. Se houver domínio personalizado ativo, a auditoria usa esse endereço; caso contrário, usa a URL do slug.

Abra a URL manualmente antes. Se a página não carrega, mostra a versão antiga ou está suspensa, resolva o estado de publicação primeiro. A documentação de Publicação descreve o pacote e o deploy esperados.

Rode a primeira auditoria sem autorizar mudanças

Uma boa primeira chamada é de diagnóstico:

Rode audit_seo para o Site [site_id] uma vez.


Não altere arquivos e não republique ainda.
Retorne:
- URL auditada, data e nota;
- issues agrupadas por página e severidade;
- valor encontrado e valor esperado;
- quais correções são bloqueantes, importantes ou opcionais;
- arquivos de origem que provavelmente controlam cada item;
- pontos que exigem decisão editorial em vez de correção automática.

A orientação de rodar uma vez importa: a auditoria acessa Pages ao vivo, pode levar dezenas de segundos e compartilha um limite de uso entre painel e MCP. Corrija o lote de achados antes de consumir outra execução.

Como priorizar os achados

Nem toda issue deve receber a mesma urgência.

Prioridade Exemplos Ação
bloqueante noindex acidental, canonical para host incorreto, página sem título corrigir antes de promover a URL
alta H1 ausente ou duplicado, description ausente, idioma errado corrigir na versão atual
média alt ausente, social metadata incompleta, comprimento inadequado corrigir com contexto editorial
estrutural sitemap ou robots ausente em Site multipágina avaliar arquitetura e publicar arquivo correto

A severidade do relatório é uma entrada. O contexto do negócio completa a decisão. Uma imagem decorativa pede tratamento diferente de uma imagem que comunica instrução essencial.

Corrija as regras sem degradar o conteúdo

Title e meta description

O comprimento esperado é um guardrail, não um convite para preencher caracteres. Title e description devem representar a página real.

Peça ao agente para preservar:

  • palavra-chave e intenção;
  • nome correto do produto;
  • oferta aprovada;
  • diferença entre páginas;
  • tom da marca.

Não aceite o mesmo title em todas as rotas. Em um Site multipágina, cada Page precisa ser identificável.

Canonical

O canonical deve apontar para a URL preferida daquela página. Um erro aqui pode enviar o sinal para outro host, para o ambiente de teste ou para uma rota genérica.

Quando existe domínio personalizado ativo, confira se a estratégia da campanha usa esse domínio. Não troque canonical apenas para fazer a issue desaparecer; confirme o endereço oficial.

Robots meta e robots.txt

Um noindex pode ser intencional em uma revisão privada e bloqueante em uma campanha que precisa ser descoberta. A ferramenta procura o acidente técnico; a equipe decide a política.

Revise também robots.txt. Permitir rastreamento não garante indexação, e bloquear um crawler não protege conteúdo confidencial. Conteúdo privado precisa de controle de acesso adequado.

Open Graph e Twitter Card

Essas tags controlam como a URL tende a aparecer em compartilhamentos compatíveis. Confira título, descrição, imagem e URL.

Não invente uma imagem social com texto ilegível ou uma promessa diferente da landing. Use um asset aprovado e confirme que ele está incluído na Version publicada.

H1 e hierarquia

A auditoria verifica um único H1. Depois disso, ainda cabe revisar se o H1 descreve a página e se H2 e H3 formam uma estrutura compreensível.

Não transforme todo texto grande em heading apenas por estilo. Separe semântica de aparência no componente.

Imagens e texto alternativo

Uma imagem informativa precisa de alt que comunique sua função. Uma imagem decorativa pode usar alternativa vazia para não repetir ruído.

O agente consegue localizar atributos ausentes. Ele precisa de contexto para escrever uma alternativa fiel. Não use uma lista de palavras-chave como descrição.

Idioma, charset e viewport

Esses metadados parecem básicos, mas templates gerados rapidamente podem omiti-los. Para conteúdo brasileiro, confira lang="pt-BR", codificação UTF-8 e viewport adequado ao layout responsivo.

O viewport correto não prova que o mobile funciona. Complete com a revisão visual do checklist de QA.

Sitemap

O sitemap deve listar URLs canônicas que podem ser rastreadas. Em um Site com várias Pages, confira se rotas removidas saíram e se as novas entraram.

Não publique um sitemap copiado de outro domínio. Gere-o a partir das rotas autorizadas da versão atual.

Use o prompt do relatório como rascunho de trabalho

O audit_seo devolve um prompt de correção agrupado por página. Ele reduz transcrição, mas não amplia a autorização do agente.

Acrescente invariantes:

Use o prompt do relatório como lista de achados.


Corrija somente as issues aprovadas nos arquivos de origem.
Preserve oferta, preços, provas, CTA, tracking, identidade e rotas.
Não invente canonical, copy, alt, imagem social ou política de indexação.
Pare e peça decisão quando um valor oficial não estiver documentado.


Depois execute os checks do projeto e mostre o diff.
Não publique até a aprovação.

Esse contrato mantém correção técnica separada de decisão editorial.

Republique no mesmo Site

Depois da aprovação:

  1. gere a build atual;
  2. confirme index.html na raiz do pacote;
  3. valide que Pages, assets, robots.txt e sitemap.xml esperados estão presentes;
  4. use o mesmo Site ID;
  5. edite a Session pelas file tools;
  6. publique a Version;
  7. inicie o deploy;
  8. acompanhe até sucesso ou falha;
  9. abra as URLs afetadas;
  10. confira o HTML realmente servido.

O fluxo de republicação com agente de IA evita criar outro Site e perder a continuidade da URL.

Rode a auditoria novamente

Espere a versão nova estar ativa e execute audit_seo em uma nova rodada. Compare por regra e página, não apenas pela nota total.

Registre:

site_id e URL:
deploy corrigido:
nota anterior e atual:
issues resolvidas:
issues restantes:
decisões editoriais pendentes:
páginas verificadas manualmente:

Se uma issue persistir, confira primeiro a versão servida, o arquivo publicado e a rota auditada. Não repita a mesma alteração no escuro.

Um ciclo de SEO que o agente consegue executar

O processo completo fica assim:

URL publicada
→ auditoria da versão ativa
→ issues com evidência
→ aprovação das correções
→ mudanças na fonte
→ build e QA
→ republicação no mesmo Site
→ verificação da URL
→ nova auditoria
→ registro do resultado

Conecte o agente pela documentação de Configuração, informe o Site ID correto e comece com uma auditoria sem alterações. O ganho não está em perseguir uma nota perfeita. Está em transformar problemas técnicos observáveis em correções pequenas, revisáveis e confirmadas na URL que o público realmente acessa.