Decidir em comitê entre escalar, podar ou parar

Continuar publicando um acervo que parou de render consome verba e reputação todo mês, e ninguém costuma marcar a data em que isso começou. O gerador está funcionando. Você publica um lote, ele indexa, aparece impressão, você publica outro. A pergunta que sobra é a única que nenhum material responde: quando parar. Nenhum tutorial termina com "pare aqui", porque o formato de conteúdo do setor premia a curva ascendente e não tem nada a ganhar mostrando o que vem depois dela.

Então comece pelo que vem depois.

Causal. O caso mais documentado do período. Cerca de 1.800 artigos gerados a partir do sitemap de um concorrente, publicados no domínio de uma empresa de planejamento financeiro. Medido com Ahrefs: linha de base de cerca de 200 mil visitas no começo de 2023, pico de 610 mil no começo de outubro de 2023, 190 mil em meados de dezembro de 2023. O ciclo inteiro durou cerca de quatro meses e terminou abaixo da linha de base. O custo não foi a campanha não ter funcionado, foi o ativo anterior ter piorado.

HouseFresh. O lado oposto da assimetria. Site independente de review de purificadores de ar, com teste próprio de produto, reportou perda de 91 por cento do tráfego de busca a partir de 09/03/2024. A recuperação foi reportada pelo próprio site em 11/10/2025. São cerca de dezenove meses entre a queda e a recuperação, para um projeto que não violou nenhum critério declarado do Google.

Junte as duas curvas e a lição aparece na tesouraria, mais que no algoritmo.

Antes do runbook, uma correção de vocabulário que muda o diagnóstico inteiro.

A prática difundida é olhar a data da queda, procurar o core update mais próximo e declarar a causa. Em 09/12/2025 o Google expandiu a documentação de core updates para explicar que existem atualizações algorítmicas contínuas além dos lançamentos nomeados. Isso não invalida a tabela de datas oficiais do painel de status do Google, que continua útil como referência de contexto de volatilidade e está logo abaixo.

O que a nota de 09/12/2025 invalida é o uso da tabela como diagnóstico. Amarrar a queda a um nome produz uma explicação que não gera ação: não existe nada a fazer com a informação "foi o update de maio". Encontrar o nome parece progresso e é parada. Quando a queda coincide com uma atualização de spam em andamento, siga o protocolo de [Proteger o acervo nas atualizações de spam de 2026](#proteger-acervo-nas-atualizacoes-de-spam) antes de mexer no catálogo.

Exemplo resolvido. O Radar tem 4.180 páginas municipais publicadas. Na segunda-feira, o painel mostra impressões caindo 38 por cento em quatro semanas. Veja o runbook rodando inteiro, com o que cada passo respondeu.

Passo 1, ação manual. No Search Console, relatório de ações manuais. O rótulo a procurar é "Thin content with little or no added value", descrito como "Google has detected low-quality pages or shallow pages on your site". Não existe ação manual chamada "scaled content abuse": quem busca o nome da política conclui erradamente que está limpo. Resultado no Radar: nenhuma ação manual. Segue.

Passo 2, impressão contra clique. Impressões caíram 38 por cento, cliques caíram 6 por cento, posição média melhorou de 22,4 para 14,1. Esse conjunto é assinatura de sumiço de impressão em posição alta, e não de perda de ranking. Se a série atravessasse setembro de 2025, a comparação seria inválida de saída: o fim do parâmetro num=100 apagou impressões geradas por rastreadores em posições 50 a 100, e séries dos dois lados dessa data não se comparam. No Radar a janela é recente, então a leitura vale: o que caiu foi cauda de impressão, e o negócio continua igual.

Passo 3, estados de indexação. "Discovered, currently not indexed" estável em 210 URLs. "Crawled, currently not indexed" saiu de 640 para 1.190 em quatro semanas, concentrado em municípios pequenos. Aqui o diagnóstico muda de assunto: Discovered é capacidade e tem tratamento técnico; Crawled not indexed é veredito de valor, e a orientação oficial é literalmente não reenviar a URL.

Passo 4, régua externa. Pegue três páginas do bloco afetado e compare com as três melhores páginas da web sobre o mesmo assunto. A régua da seção 4.6.6 das rater guidelines é comparação contra outras páginas da web sobre o mesmo tópico, nunca contra a média interna do próprio site. Um template pode ser internamente consistente e raso na régua real. No Radar, os municípios afetados tinham série histórica de três semanas, o que produzia uma página sem variação, sem comparação com a média da UF e sem número de postos pesquisados.

Passo 5, mudança. A hipótese escrita foi: páginas com menos de doze semanas de série não sustentam densidade. A ação foi poda, não reescrita.

Agora os gatilhos. A regra que faz esta parte funcionar é simples de enunciar e difícil de cumprir: copiar limiar genérico de blog é o mesmo que não ter gatilho. Um número só vale se vier de uma janela declarada e da série do seu próprio catálogo.

Gatilho de escala. Publicar o próximo lote exige duas condições simultâneas, medidas sobre o último lote. A primeira é a proporção de páginas do lote que entraram no índice e acumularam pelo menos uma impressão dentro da janela declarada. A segunda é a proporção de páginas com dado exclusivo, que é o critério de sucesso adotado desde [Medir o template contra as melhores páginas do assunto](#template-com-densidade). No Radar, a declaração escrita foi: janela de 28 dias, 70 por cento do lote indexado com impressão, e 80 por cento do catálogo com pelo menos três recortes que só existem naquela página.

Gatilho de poda. Dispara quando "Crawled, currently not indexed" passa de um percentual do catálogo, ou quando páginas ficam sem nenhuma impressão numa janela declarada. A resposta correta é reduzir quantidade ou aumentar densidade, e poda é ação de primeira linha. O mecanismo está na documentação de crawl budget: duplicatas e URLs indesejadas reduzem a demanda de rastreio pelo fator *perceived inventory*. Remover mil páginas sem inventário melhora a situação das que ficam, porque muda a percepção de inventário do site inteiro.

Gatilho de parada. Dispara em duas situações. Quando o custo de manter a cobertura excede o retorno, o que exige o cálculo de custo total de posse abaixo. E quando a fonte de dado deixa de ser exclusiva, porque nesse momento o projeto perde a resposta do gate de [Separar acervo de fachada antes de aprovar a verba](#gate-do-dado-proprio) e vira outra coisa.

Custo total de posse do catálogo. Duas contas que apareceram separadas no curso precisam ser somadas aqui, porque é o par delas que alimenta o gatilho de parada.

O primeiro número vem de [Priorizar páginas sem depender do volume de busca](#keywords-sem-volume-confiavel): o custo de monitoramento. Verificação semanal de posição para N páginas custa N vezes 4 SERPs por mês. Com DataForSEO na fila Standard a US$ 0,60 por mil SERPs, 5.000 páginas verificadas semanalmente dão 20.000 SERPs por mês, algo em torno de US$ 12 mensais. Esse número muda de ordem de grandeza se a verificação virar diária, e é aí que a decisão de cadência vira decisão de arquitetura.

O segundo vem do apêndice técnico [Testar o template no pior caso e achar o teto](#performance-e-teto-de-plataforma), que detalha o custo de revalidação da plataforma. Em Cloudflare, o teto de arquivos por versão do Worker é de 100.000 no plano pago e 20.000 no free, e cada página pré-renderizada gera mais de um arquivo. Acima disso a saída deixa de ser asset estático e passa a exigir cache incremental com backend, o que traz o gargalo da fila do OpenNext: no máximo 10 instâncias de Durable Object processando até 5 requests em paralelo, ou seja 50 revalidações concorrentes. Faça a conta do seu catálogo: quanto tempo leva para revalidar tudo a 50 por vez, e quantas vezes por semana isso precisa acontecer para o lastmod continuar honesto.

A soma das duas contas, dividida pelo retorno que o catálogo gera, é o número do gatilho de parada. Sem ela, "parar" vira decisão emocional tomada num mês ruim.

Capstone: o Radar entregue. O critério não é você achar que ficou bom, é um terceiro conseguir verificar sem acesso ao seu código, com os mesmos quatro comandos de [Auditar o concorrente em escala pelo que ele publica](#auditoria-de-sitemap-ao-vivo). Cinco itens compõem a entrega.

1. 01robots.txt declarando o sitemap index.
2. 02O índice apontando para partições nomeadas, cujos nomes revelam a taxonomia (o eixo município, o eixo combustível, a camada curada separada da gerada).
3. 03Uma amostra de URLs com inventário retornando indexável, e uma amostra sem inventário retornando noindex, decidido em tempo de render contra o dado real.
4. 04lastmod variando entre páginas conforme a semana de referência da série da ANP, e não igual ao timestamp do build.
5. 05O relatório de densidade, dizendo qual proporção do catálogo tem dado que não existe em outro lugar.

Os quatro primeiros um estranho confere em cinco minutos. O quinto é o que separa um acervo de um gerador de texto, e é o único que você precisa produzir.

Fechamento, e o gate de volta. Você chegou aqui com o catálogo pronto na mão. Volte a [Separar acervo de fachada antes de aprovar a verba](#gate-do-dado-proprio) e releia o gate: cada página tem um dado que só existe nela e que alguém buscaria por si só?

Responda de novo, agora com o relatório de densidade aberto ao lado. Se a resposta continua sendo sim para 80 por cento do catálogo, o gatilho de escala está satisfeito e o próximo lote pode sair. Se caiu para 40 por cento no caminho, o gate não foi violado em [Separar acervo de fachada antes de aprovar a verba](#gate-do-dado-proprio), foi violado em algum lote intermediário em que a cobertura cresceu mais rápido que o inventário. Encontrar em qual lote isso aconteceu é a última investigação que o comitê precisa encomendar.

O guia a seguir é para quem preside o comitê do acervo, normalmente o CMO ou o diretor de produto digital. Ele destrava a decisão trimestral entre escalar, podar ou parar com números combinados antes, e não descobertos na reunião.

Convoque o primeiro comitê do acervo para os próximos 30 dias e leve o documento dos três gatilhos para aprovação. Confira que ele funcionou por dois sinais: a reunião termina com uma das três decisões registradas em ata e a próxima data já está no calendário de todos os participantes.