Auditoria de conteúdo: como inventariar e classificar páginas

Auditoria de conteúdo, na prática, significa duas coisas antes de qualquer decisão: inventariar cada página que existe (e cada página que devia existir, mas não existe mais) e classificar cada uma por intenção, qualidade e desempenho. Sem esse inventário, decidir o que atualizar, fundir ou remover é chute guiado por memória — alguém lembra que aquela página "sempre trouxe tráfego" ou que aquele texto "ficou datado", mas ninguém tem os números por URL para comparar.

Esta etapa não é sobre o que fazer com cada página — isso vem depois, quando já se sabe quais manter como estão, quais reformar, quais unificar e quais cortar. Também não é o relatório final que justifica o esforço; isso é outro documento, com outro público. Aqui o objetivo é montar, página por página, uma linha só que junta o que o crawler vê, o que o Google mede no Search Console e o que o GA4 registra de comportamento — e então rotular cada linha o suficiente para que a decisão seguinte seja óbvia.

O inventário começa no crawl, não na planilha

O primeiro dado não vem de nenhuma ferramenta de analytics: vem de rastrear o site como um rastreador rastreia, com uma ferramenta como Screaming Frog, Sitebulb ou um rastreador via linha de comando apontado para o domínio inteiro — não só para o sitemap.xml, porque sitemap e site real divergem com frequência. O crawl entrega, para cada URL encontrada: código de status, canonical declarado, diretiva de indexação (index/noindex, via meta robots ou header), profundidade de cliques a partir da home, template ou tipo de página, título, contagem de palavras do corpo e, quando o CMS expõe isso, data de publicação e de última edição.

O ponto que mais gente pula: cruzar o crawl com o sitemap e com as landing pages que aparecem no GA4 — três listas que raramente coincidem por completo. Há URLs no sitemap que redirecionam ou devolvem 404, lixo acumulado de migrações antigas. Há URLs vivas e rastreáveis que nunca entraram no sitemap. E há URLs que só aparecem no GA4, recebendo tráfego direto, de e-mail ou de um backlink antigo, mas que o crawl nem alcança, porque foram despublicadas ou desligadas do menu de navegação. Cada uma dessas divergências já é, por si só, um item de trabalho, antes de qualquer julgamento sobre qualidade.

• Status code, canonical e diretiva de indexação por URL
• Profundidade de cliques a partir da home
• Contagem de palavras e data de última edição, quando disponíveis
• Divergências entre crawl, sitemap.xml e landing pages do GA4

Puxando o Search Console por página

No relatório de Desempenho do Search Console, a granularidade certa para este trabalho é página, não consulta. Agrupar por página entrega, para cada URL, impressões, cliques, CTR e posição média — os quatro números que dizem se uma página é vista, se é clicada quando é vista, e em que posição ela costuma aparecer. A janela de tempo importa: um período curto de 28 dias sofre com sazonalidade e ruído; algo entre 12 e 16 meses, comparado com o período equivalente anterior, mostra tendência de forma muito mais confiável.

A interface do Search Console corta a exportação em mil linhas, o que é insuficiente para qualquer site de porte médio para cima. Para um inventário completo, é a API do Search Console, ou uma exportação em massa para o BigQuery quando o link já está ativado, que entrega todas as linhas sem esse teto. Depois de puxar o desempenho por página, vale um segundo puxão por página mais consulta: isso mostra quais termos de busca realmente alimentam cada URL, e às vezes revela que uma página recebe impressão para consultas que não têm nada a ver com o que ela foi escrita para responder. Isso é um sinal para marcar — possível canibalização ou desalinhamento de intenção — não algo para resolver nesta etapa.

Cruzando o GA4 por página

O GA4 organiza dados por evento, não por página, então o relatório certo usa a dimensão de página e classe de tela, ou o relatório de landing page, com métricas de sessões, sessões engajadas, taxa de engajamento, tempo médio de engajamento e os eventos-chave atribuídos àquela página como ponto de entrada. Para páginas de baixo tráfego, o GA4 aplica limites e às vezes agrega ou suprime linhas — é normal ver menos granularidade nas páginas de cauda longa do que no crawl ou no Search Console, e isso não é motivo para descartar essas linhas do inventário.

O maior risco técnico aqui não está na métrica, está no cruzamento: Search Console e GA4 quase nunca representam a mesma URL da mesma forma. Um site pode ter páginas indexadas com e sem barra final, com parâmetros de rastreamento, em http e em https, com e sem www — e cada uma dessas variações conta como uma linha diferente em cada relatório, se não for normalizada antes de juntar. Decidir a forma canônica de cada URL, geralmente a que está no canonical tag, sem parâmetros e sem barra final, antes de exportar qualquer coisa, evita recontagem e URLs fantasmas na planilha final.

Juntando as três fontes numa única linha por URL

Com o crawl, o Search Console e o GA4 já normalizados pela mesma forma de URL, a junção em si é simples: URL como chave única, uma linha por página, colunas vindas de cada fonte. O resultado costuma ser uma planilha, ou, em sites grandes, uma tabela em banco de dados, com dezenas de colunas — mas a parte que importa não é o volume de dados, é o que aparece vazio.

Toda linha com um campo vazio está contando uma história diferente. URL presente no crawl sem nenhuma linha correspondente no Search Console: página nova, ou bloqueada de indexação, ou penalizada, o que merece checar antes de seguir adiante. URL no Search Console sem correspondente no GA4: normalmente uma tag de analytics ausente ou mal implantada naquele template específico, não um problema do conteúdo em si. URL no GA4 recebendo sessões sem aparecer no crawl atual: página removida do menu e do sitemap, mas ainda linkada de fora ou salva nos favoritos de alguém, candidata natural a um redirecionamento — e o tipo de achado que só aparece porque o inventário juntou as três fontes em vez de olhar cada relatório isoladamente.

• URL no crawl, ausente no Search Console: checar bloqueio de indexação ou penalidade
• URL no Search Console, ausente no GA4: checar a tag de analytics no template
• URL no GA4, ausente no crawl atual: candidata a redirecionamento

Classificando por intenção de busca

Com a planilha unificada em mãos, a primeira classificação não é de qualidade, é de intenção: cada página recebe um rótulo — informacional, transacional ou comercial, navegacional ou comparativa — baseado no que ela foi escrita para responder. Essa intenção já existia, em teoria, desde o briefing original da página; a auditoria é o momento de confirmar se a intenção declarada ainda corresponde à intenção que o Google está de fato satisfazendo com aquela URL, hoje.

É aqui que o segundo puxão do Search Console, por página e consulta, vale o esforço extra: as consultas reais que geram impressão numa página informacional às vezes carregam sinal claramente transacional, como "preço" ou "contratar", e o inverso também acontece — uma página escrita para converter aparece para buscas claramente de pesquisa inicial. Esse descompasso entre a intenção pretendida e a intenção capturada é, sozinho, motivo suficiente para marcar uma página como candidata a revisão, independente de qualquer outro critério de qualidade ou de desempenho aplicado a ela depois.

Classificando por qualidade

A classificação de qualidade, nesta fase, não é a auditoria técnica completa que gera um relatório para o orçamento — é um rótulo rápido e consistente, aplicado página por página, para alimentar a decisão seguinte. Um checklist curto e fixo produz rótulos comparáveis entre centenas de páginas; um julgamento livre por página produz rótulos que dependem de quem revisou cada lote, e isso quebra a comparação exatamente no ponto em que ela mais importa.

Um checklist funcional para essa etapa cobre, no mínimo, cinco pontos: se a contagem de palavras vinda do crawl é compatível com a complexidade real do tema, sem existir um número mágico universal, mas um texto de trezentas palavras raramente esgota um assunto que a concorrência trata em mil e quinhentas; se a data de última edição é recente para um tema que muda rápido, como preço ou regulamentação, ou é irrelevante para um tema estável; se a página tem hierarquia de títulos coerente, com um único H1 e H2s que seguem uma lógica de leitura; se existem links internos entrando e saindo dela; e se afirmações específicas trazem alguma fonte ou atribuição, em vez de soarem genéricas e intercambiáveis com qualquer outro texto do setor.

• Palavras versus complexidade real do tema
• Data de última edição versus velocidade de mudança do assunto
• Hierarquia de títulos e presença de links internos
• Afirmações com fonte versus afirmações genéricas

Classificando por desempenho

A classificação de desempenho combina o que o Search Console e o GA4 já trouxeram em quatro eixos: volume de tráfego, medido em cliques e sessões; valor, medido nos eventos-chave atribuídos àquela página como entrada; eficiência, que compara o CTR observado com o CTR esperado para aquela posição média — uma página na posição quatro com CTR muito abaixo do que essa posição normalmente entrega tem um problema de título ou de meta description, não de ranking; e tendência, o mesmo indicador comparado ao período anterior, para separar queda estrutural de flutuação normal de curto prazo.

Cruzar tráfego com valor já produz quatro grupos que dizem muito por si só. Tráfego alto com conversão alta é o grupo que menos precisa de atenção agora. Tráfego alto com conversão baixa é o grupo mais interessante para revisão, porque o volume de visitantes já existe e o problema está em outro lugar da página, não na atração de tráfego. Tráfego baixo com posição boa costuma significar intenção de busca naturalmente pequena, ou um título que não convida ao clique, e não necessariamente conteúdo fraco. E tráfego baixo com posição fraca em todos os eixos é o grupo onde vale perguntar se a página deveria continuar existindo como está — decisão que pertence à etapa seguinte, não a esta.

Erros comuns nesta fase

Alguns erros aparecem com tanta frequência em auditorias de conteúdo que vale nomeá-los antes de fechar qualquer inventário:

• Juntar Search Console e GA4 sem normalizar a URL antes: barra final, protocolo e parâmetros de rastreamento fragmentam a mesma página em várias linhas diferentes
• Usar a janela de data padrão do Search Console, de vinte e oito dias, para tirar conclusão de tendência: sazonalidade normal do negócio parece queda ou alta real
• Tratar uma página sem dados no Search Console como sinal automático de baixa qualidade, quando a causa mais comum é bloqueio de indexação, via noindex ou robots.txt, ou publicação recente demais para já ter sido rastreada
• Classificar qualidade sem um checklist fixo, o que produz rótulos que variam de acordo com quem revisou cada lote de páginas naquela semana
• Fazer a auditoria uma única vez e arquivar o resultado: o inventário descreve um momento específico, e sem repetição periódica ele envelhece tão rápido quanto o próprio conteúdo que descreve
• Misturar classificação com decisão: rotular uma página como de baixo desempenho e já removê-la na mesma passada, sem considerar valor de link building, tráfego de marca ou relevância sazonal que a métrica do período analisado não captura

O resultado desta etapa não é uma pilha de decisões já tomadas, é uma planilha, ou uma tabela, com uma linha por URL, dados de crawl, Search Console e GA4 já cruzados, e três rótulos por página: intenção, qualidade e desempenho. É esse inventário classificado que transforma a etapa seguinte — decidir o que manter, atualizar, fundir ou remover — numa leitura de dados, em vez de numa discussão de opinião entre quem lembra vagamente de cada página.