No início de 2023, um cliente do setor de viagens veio me procurar com o que parecia ser uma configuração perfeita. Ele tinha 14.000 páginas de localização — toda cidade, todo bairro, todo distrito de código postal no Reino Unido — todos gerados automaticamente a partir de um banco de dados de informações de hotéis e restaurantes. Template limpo. Links internos decentes. E tinha classificação. Por cerca de quatro meses.
Então a atualização core de março de 2024 chegou. Eles perderam 71% do seu tráfego orgânico em seis semanas. Passei três semanas fazendo a análise forense. O conteúdo não estava exatamente errado. Mas era vazio. Cada página dizia as mesmas três coisas em ordem ligeiramente embaralhada, e o Google havia claramente decidido que não valia a pena servir para ninguém. Reconstruímos o pipeline com comportas de qualidade apropriadas e recuperamos para 60% do pico em cinco meses. Não perfeito. Mas uma lição que ficou comigo.March 2024 core update hit. They lost 71% of their organic traffic in six weeks. I spent three weeks doing the forensics. The content wasn't wrong exactly. But it was hollow. Every page said the same three things in slightly shuffled order, and Google had clearly decided it wasn't worth serving to anyone. We rebuilt the pipeline with proper quality gates and recovered to 60% of peak within five months. Not perfect. But a lesson that's stayed with me.
SEO programático ainda é uma das ferramentas mais poderosas no kit de ferramentas de agência. Mas a margem para slop é basicamente zero.
O Que "Comporta de Qualidade" Realmente Significa em um Pipeline de pSEO
As pessoas usam este termo livremente, então deixa eu ser preciso sobre como eu o uso na Seahawk.
Um quality gate é uma regra ou teste em checkpoint que uma página deve passar antes de ser publicada — ou antes de continuar publicada. Não é um vibe check. É um limiar específico e mensurável que ou deixa a página passar ou a envia de volta para revisão (ou a elimina completamente).checkpointed rule or test that a page must pass before it gets published — or before it stays published. It's not a vibe check. It's a specific, measurable threshold that either lets a page through or sends it back for revision (or kills it entirely).
Pense nisto como integração contínua para conteúdo. Desenvolvedores não fazem push de código que falha testes unitários. Você não deveria publicar páginas que falham testes de conteúdo. A analogia não é perfeita, mas é próxima o suficiente para ser útil.
Um pipeline sem quality gates é só uma máquina de spam de conteúdo. E em 2024, o classificador do Google é bom o suficiente para detectar isto em escala.
As Três Camadas Onde Gates Precisam Existir
Eu estruturo gates em três momentos:
- Pré-geração — antes de qualquer conteúdo ser escrito. Verificações de qualidade de dados. Esta entidade tem atributos únicos suficientes para suportar uma página distinta? — before any content is written. Data quality checks. Does this entity have enough unique attributes to support a distinct page?
- Pós-geração — depois que a IA ou template produziu conteúdo. Scoring automatizado para comprimento, unicidade, cobertura de entidade. — after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- Monitoramento pós-publicação — contínuo. Páginas que caem em impressões ou taxa de clique são sinalizadas para revisão humana. — ongoing. Pages that drop in impressions or click-through rate get flagged for human review.
A maioria das equipes constrói apenas a camada do meio. É por isso que elas se queimam.
O Problema de Suficiência de Dados (A Maioria das Pessoas Pula Isto)
É assim — os piores problemas de conteúdo programático começam antes de uma palavra ser escrita. Começam na planilha.
Se seus dados de origem têm 12 atributos por entidade e 9 deles são idênticos em 80% dos seus registros, você vai produzir páginas quase duplicadas independentemente de quão inteligentes sejam seus prompts. Aprendi isso em um diretório de advogados que construímos na Seahawk em 2021. Tínhamos 6.000 registros de escritórios de advocacia. Cerca de 4.200 deles não tinham nada distintivo além de um nome, um código postal e uma área de atuação. Publicamos todos os 6.000. O Google indexou talvez 1.800.
Filtro pré-geração: pontuação de riqueza de dados. Agora executo cada conjunto de dados por um script Python simples antes de tocarmos em um template. Ele conta o número de campos não nulos e não genéricos por registro e sinaliza qualquer coisa abaixo de um limite — tipicamente uso 7 de 12 como mínimo. Os registros que não passam nesse teste vão para uma categoria "stub" que recebe uma página fina com noindex, ou nenhuma página. I now run every dataset through a simple Python script before we touch a template. It counts the number of non-null, non-generic fields per record and flags anything below a threshold — I typically use 7 out of 12 as a minimum. Records that don't clear it go into a "stub" category that gets a thin page with noindex, or no page at all.
Isso não é glamouroso. Mas é a mudança única que teve o maior impacto na eficiência de rastreamento em nossas construções.
Pontuação de Singularidade Após Geração
Então seus dados passaram no primeiro filtro. O conteúdo foi gerado. E agora?
Não publique até ter pontuado por singularidade — não contra a web, mas contra seu próprio corpus de páginas. Conteúdo interno quase duplicado é o problema mais comum, e é aquele que você tem mais controle direto.
Eu uso uma combinação de duas ferramentas para isso:
- [API em lote do Copyscape](https://www.copyscape.com/api.php) para sinalizar páginas muito similares a URLs já indexadas for flagging pages that are too similar to existing indexed URLs
- Um script customizado de similaridade de cosseno (usando sentence-transformers em Python) que pontua cada página nova contra as 50 páginas mais estruturalmente similares na mesma família de template
Meu threshold é 0.82 de similaridade cosseno. Qualquer coisa acima disso vai para revisão manual. Qualquer coisa acima de 0.91 é descartada ou reformulada pesadamente.
Sim, isso adiciona friction ao pipeline. Bom. Friction é o ponto.
O que "Único" Realmente Precisa Significar
Genuinamente único não significa apenas sentenças embaralhadas. Significa que a página responde uma pergunta que apenas essa entidade pode responder. Para uma landing page de cidade, é dado hyper-local — listagens reais de eventos, estatísticas locais reais, uma citação específica de uma fonte local. Para uma página de comparação de produtos, são pontos de dados que diferenciam esses dois produtos específicos, não uma intro genérica com nomes trocados.this entity can answer. For a city landing page, that's hyper-local data — real event listings, actual local statistics, a specific quote from a local source. For a product comparison page, it's data points that differentiate these two specific products, not a boilerplate intro with swapped nouns.
A própria orientação do Google sobre conteúdo útil sempre disse isso. O classificador apenas ficou agressivo em forçar isso. has always said this. The classifier just got aggressive about enforcing it.
Entity Coverage: O Portão Que Ninguém Fala Sobre
Esse demorou mais para eu descobrir, e estou irritado que demorou.
Toda página em um build programático é nominalmente "sobre" algo — um lugar, um produto, uma pessoa, um serviço. A entidade e seus atributos devem ser representados consistentemente no conteúdo através de menções nomeadas, associações semânticas e structured data. Se não forem, a página lê como thin mesmo que tenha 800 palavras.
Agora executo um lightweight NLP pass em toda página gerada usando spaCy para verificar que:spaCy to check that:
- A entidade primária é nomeada nos primeiros 100 palavras
- Pelo menos 4 entidades ou atributos semanticamente relacionados aparecem no corpo do texto
- A página contém pelo menos um fato que é único da entidade (extraído dos dados da fonte, não alucinado pelo modelo)
Esse último check é manual por enquanto. Quero automatizá-lo, mas ainda não construí uma forma confiável de fazer validação cruzada em escala sem muitos falsos positivos. Se você resolveu isso, genuinamente gostaria de saber.
The Thin-Page Trap: When to Noindex vs. When to Delete
Digamos que uma página passa pela geração mas ainda se sente fina. Talvez os dados fossem escassos, a entidade é obscura, e o output é tecnicamente único mas não particularmente útil.
O que você faz?
Aqui está minha árvore de decisão — simplificada, mas é mais ou menos assim que penso sobre isso:
- Se a página tem zero impressões de busca depois de 90 dias no GSC: delete e redirecione 301 para o pai relevante mais próximo.delete and 301 to the nearest relevant parent.
- Se a página tem impressões mas CTR abaixo de 0.5% e sem backlinks: noindex e consolide em uma página pai ou categoria.noindex and consolidate into a parent or category page.
- Se a página tem impressões, CTR razoável (1%+), mas posição média baixa (40+): mantenha, mas priorize para enriquecimento de conteúdo.keep, but prioritise for content enrichment.
- Se a página está performando: deixe-a em paz e pare de duvidar de si mesmo.leave it alone and stop second-guessing yourself.
Não consigo contar quantas vezes vi donos de agência noindexar páginas que estavam convertendo silenciosamente. Não conserte o que não está quebrado.
Structured Data como Sinal de Qualidade (Não Apenas uma Jogada de Rich Result)
A maioria das pessoas adiciona schema a páginas de pSEO pelos rich results. Justo. Mas comecei a tratar a completude de schema como uma porta de qualidade também.
Se o schema de uma página tem mais de 30% de valores nulos ou placeholder, isso me diz que os dados subjacentes são muito esparsos para produzir uma página útil. Então construímos um validador de schema em nosso pipeline — ele verifica propriedades obrigatórias e recomendadas contra a especificação Schema.org para o tipo que estamos usando. Páginas que falham nesta verificação voltam para a fila de enriquecimento.Schema.org spec for whatever type we're using. Pages that fail this check go back into the enrichment queue.
Google usa completude de schema como um sinal de ranking direto? Quase certamente não de uma forma simples. Mas páginas com schema completo e preciso tendem a ser páginas com dados completos e precisos — e essas páginas tendem a rankear. A correlação é forte o suficiente para que eu trate qualidade de schema como um diagnóstico útil, mesmo que não seja o mecanismo.those pages tend to rank. The correlation is strong enough that I treat schema quality as a useful diagnostic even if it's not the mechanism.
Monitoramento Após Publicação: O Portão Que Continua Funcionando
Uma porta de qualidade não é uma coisa única. Páginas se degradam. Dados ficam obsoletos. Uma página que estava bem em janeiro pode estar fina em outubro porque o mundo mudou e o conteúdo não.
Executo um crawl mensal usando Screaming Frog em todas as grandes propriedades de pSEO que gerenciamos, sinalizando:Screaming Frog on every large pSEO property we manage, flagging:
- Páginas com menos de 350 palavras (após remoção de boilerplate)
- Páginas onde a tag de título corresponde a mais de 3 outras páginas do site
- Páginas sem links internos apontando para elas (risco de órfã)
Faço uma validação cruzada desses dados com informações do GSC exportadas via API — procurando especificamente por páginas que perderam mais de 40% de suas impressões nos últimos 60 dias. Essa intersecção (sinalizadas pelo Screaming Frog e em declínio no GSC) é a fila de revisão de alta prioridade.and declining in GSC) is the high-priority review queue.
Honestamente, esse passo de monitoramento é onde a maioria das agências economiza porque não é faturável de forma óbvia. Mas é isso que diferencia uma construção de pSEO que se sustenta de uma que desmorona após a próxima core update.
FAQ
Usar IA para gerar conteúdo dispara automaticamente uma penalidade do Google?
Não. Google disse explicitamente que conteúdo gerado por IA não viola as diretrizes deles — é conteúdo inútil que é o problema, independentemente de como foi produzido. O sinal é qualidade, não origem. Uma página escrita manualmente que é superficial e duplicada será tratada da mesma forma. O que importa é se a página atende genuinamente à consulta do usuário melhor que as alternativas. Se não atender, o método de produção é irrelevante.unhelpful content that's the problem, regardless of how it was produced. The signal is quality, not origin. A manually written page that's thin and duplicative will get treated the same way. What matters is whether the page genuinely serves the user's query better than the alternatives. If it doesn't, the method of production is irrelevant.
Quantas páginas é "demais" para uma construção programática antes do Google ficar desconfiado?
Não há um número exato, e qualquer figura específica que você tenha visto online é inventada. O que importa é a proporção de páginas indexadas para páginas que fazem ranking. Se você tem 20.000 páginas e 400 estão recebendo impressões, é um problema de crawl budget e qualidade. Google vai começar a ignorar o resto. Eu preferiria publicar 3.000 páginas fortes a 20.000 mediocres. Taxa de cobertura de índice é a métrica a acompanhar, não o número absoluto de páginas.
Consigo me recuperar da penalidade de IA slop depois de ter sido atingido?
Sim, mas leva tempo e não é linear. O cliente de viagens que mencionei no início se recuperou — mas levou trabalho consistente ao longo de cinco meses: deletando as piores páginas, consolidando as de nível médio, enriquecendo as top performers. A ação mais impactante foi reduzir o índice de 14.000 páginas para cerca de 4.200. Counterintuitive, mas é o que os dados mostraram.
Qual é a forma mais rápida de identificar quais páginas em uma grande build são "slop"?
Puxe seus dados completos de performance do GSC dos últimos 16 semanas. Filtre por páginas com mais de 0 impressões mas menos de 0,8% CTR e posição média pior que 35. Essa coorte é seu problema. Faça referência cruzada contra word count e internal link count. A sobreposição de low-CTR, low-word-count e páginas órfãs é quase sempre a parte mais fraca de qualquer build programático.
---
Construir em escala não te dá permissão para construir mal. Os gates que descrevi adicionam talvez dois a três dias de tempo de setup para um novo projeto pSEO. A alternativa — reconstruir depois que um core update te derruba — custa muito mais que isso. Sei disso porque já fiz das duas formas.