SEO Programático que sobrevive à Helpful Content Update — construído pelo operador por trás da HostList.io.

Comecei a HostList no início de 2024 como um projeto paralelo. A ideia era simples o bastante: catalogar todas as empresas de hospedagem web na internet, dar a cada uma uma página real com uma review real, e deixar as pessoas compararem hosts da forma como elas realmente querem comparar. Dois anos e meio depois, há cerca de vinte e oito mil páginas no site, cada uma delas gerada programaticamente a partir de uma fonte de dados estrutturados, e eu pessoalmente assisti o site passar por toda atualização que o Helpful Content disparou contra ele.

A coisa que ninguém te fala quando você começa um site programático é que o trabalho é principalmente editorial, não técnico. O lado Next.js se monta em um par de semanas. O schema Supabase, o pipeline de ingestão, o sitemap streaming, o emissor schema.org — tudo isso é engenharia resolvida. O que consome o resto do ano é descobrir qual das suas vinte e oito mil linhas realmente merece estar no índice, e o que você tem que adicionar ao template antes que qualquer uma dessas linhas se leia como uma página real em vez de um dump de banco de dados com ambições SEO.

Passei a pensar em SEO programático como a disciplina da subtração. O movimento padrão é colocar toda linha ao ar. O movimento certo é colocar ao ar apenas as linhas que ganharam uma vaga, e então envolvê-las em contexto editorial o suficiente para que a página exista por uma razão além de preencher um sitemap. Acerte esses dois pontos e Google deixa você em paz durante core updates. Erre em qualquer um deles e você perde a maioria das suas páginas indexadas em dois trimestres.

O que se segue é o playbook que executo na HostList todos os dias, aplicado ao trabalho com clientes na mesma forma. Não é um pitch de marketing. É o checklist real.

A maioria das ideias que me apresentam como programáticas não deveriam ser programáticas. A forma como eu separo isso na chamada é se o dataset é genuinamente interessante e se as buscas estão genuinamente fragmentadas ao longo da cauda longa. Os dois têm que ser verdadeiros. Se o dataset é apenas bait para SEO e as buscas não estão realmente acontecendo na cauda longa que você imagina, programático é o formato errado e seguir adiante mesmo assim vai custar você as páginas indexadas dentro de seis meses.

Um punhado de padrões funciona em 2026, e eles são bem estreitos. Sites de comparação funcionam porque o buscador já conhece os nomes envolvidos e quer apenas um desempate; Notion versus Linear, Stripe versus Adyen, Cloudways versus Kinsta. Páginas de localização funcionam porque a intenção local é fundamentalmente fragmentada e quase ninguém escreve em escala à mão. Diretórios de indústria funcionam quando a combinação entity-times-filter produz queries com volume real; o próprio HostList é construído exatamente ao redor desse formato, é por isso que conheço os modos de falha ao executá-los. Páginas de glossário funcionam quando o termo é técnico o bastante para que as respostas existentes na web sejam ruins. Páginas de calculadora funcionam quando o cálculo em si mais uma página de metodologia por baixo é o valor real para o buscador.

Tudo o mais que me apresentam é a versão ruim. A versão "queremos um milhão de páginas de conteúdo genérico com nossa marca nelas", geralmente embalada como um experimento de crescimento que deveria multiplicar o tráfego orgânico por dez em um trimestre. Google foi particularmente agressivo nisso desde a Helpful Content Update no final de 2022, e as ondas de desindexação só aceleraram desde então. Vi cinco times diferentes tentarem a jogada programática preguiçosa nos últimos dois anos; todos os cinco perderam a maior parte das páginas indexadas em dois trimestres. Agora recuso o trabalho em vez de entregar, o que é desconfortável na chamada de vendas mas mais gentil com todos a longo prazo.

Três gates rodam no momento da build antes de qualquer página desembarcar no sitemap. Eles são automatizados em vez de uma revisão manual, porque em trinta mil URLs uma revisão manual não é realmente uma revisão e fingir o contrário apenas atrasa a desindexação.

Gate um é dados únicos. Pegue uma página sobre hospedagem WordPress gerenciada Cloudways no HostList. Ela precisa de pelo menos três coisas específicas do Cloudways. Uma faixa de preço. Uma lista de recursos. Uma região. Uma empresa-mãe. Um caso de uso. Qualquer coisa que não seja também verdadeira para Kinsta ou WP Engine. Se a página tem apenas um nome, um logo e uma descrição genérica, ela falha no gate. Retida do sitemap. Noindexed na fonte. A camada de dados se enche eventualmente conforme o time enriquece a linha, então a página ganha sua volta para o índice. No HostList agora, aproximadamente quinze por cento do banco de dados fica fora do sitemap exatamente por essa razão.

Gate dois é valor agregado editorial. O template tem que fazer algo que os dados sozinhos não conseguem. Comparação. Pontuação. Recomendação. Agregação. Prós e contras. Um template que apenas renderiza a linha do banco de dados em tipografia bonita não é suficiente, mesmo que a tipografia seja boa. Este é o gate em que os times mais falham na prática. Eles constroem ingestão inteligente, perdem o wrapper editorial, entregam duas mil páginas que todas parecem idênticas sob a keyword, e depois se perguntam por que Google as desindexou seis meses depois. O wrapper é o que sinaliza para Google que a página existe por uma razão além de preencher um sitemap.

Gate três é intenção de query real. Cada URL tem que mapear para uma query que alguém é plausívelmente buscando, com volume suficiente para ser digno de indexação. Páginas direcionadas para queries sob cinquenta buscas mensais são geralmente noindexed mesmo que passem nos dois primeiros gates, porque poluem o sitemap e diluem o orçamento de crawl para as páginas fortes no mesmo domínio. O limiar se flexiona por indústria; nós calibramos por projeto depois de olhar os dados do Search Console em sites adjacentes no mesmo vertical.

A primeira coisa que cortei do índice foi a cauda fina. Cerca de quinze por cento do banco de dados fica de fora do sitemap porque o limiar de dados únicos não foi atendido. Uma linha com apenas um nome, um logo e uma descrição genérica de uma linha não é uma página que o Google deveria conhecer; o custo de rastreá-la é maior do que o valor de tê-la indexada. Páginas de categoria com menos de cinco listagens fortes também ficam de fora, porque uma categoria fina parece um esforço baixo mesmo quando o schema está tecnicamente correto. Combinações de filtros com menos de três resultados recebem noindex automaticamente através de uma verificação em tempo de compilação.

O que mantive e desenvolvi foi a comparação. Páginas frente a frente entre hosts nomeados acabaram sendo o tipo de página com maior taxa de conversão no site, gerando cerca de trinta por cento de todas as conversões apesar de representarem menos de cinco por cento da contagem de URLs. Adicionei comparação como um template separado e escalei deliberadamente. Páginas de categoria com dados únicos fortes também superaram as versões genéricas por uma margem considerável. Não apenas "melhor hospedagem WordPress" mas "melhor hospedagem WordPress para lojas WooCommerce com menos de dez mil produtos". Específico. Consultável. Útil. Quanto mais estreito o qualificador, melhor a página tende a funcionar, o que vai contra a maioria dos conselhos de SEO que você lê online.

As páginas que mantive escritas à mão foram o centro de gravidade. Cerca de duzentas das vinte e oito mil são completamente editoriais escritas por humanos. A página de metodologia. A rubrica de pontuação. O guia "como escolher um provedor de hospedagem". Um punhado de fortes páginas de categoria. Elas não escalem programaticamente e nunca foram feitas para isso, mas carregam um peso desproporcional no gráfico de autoridade temática e toda página folha se liga de volta para elas. As vinte e sete mil oitocentas páginas programáticas orbitam em torno das duzentas. Essa é a estrutura que sobrevive a uma atualização de núcleo.

A camada de dados fica no Postgres, através de Supabase ou hospedado automaticamente dependendo do que o time já está rodando. Cada coluna de faceta é devidamente indexada, porque em escala varreduras de tabela completa em uma consulta de filtro se tornam o gargalo antes da própria página ficar lenta. Cada tipo de conteúdo recebe uma tabela de entidades dedicada com colunas de gate de qualidade junto com o conteúdo real — pontuação de unicidade, percentual de completude, timestamp da última verificação. Uma visualização de elegibilidade de sitemap filtra linhas abaixo do limiar automaticamente, então o sitemap e os dados subjacentes permanecem sincronizados sem envolvimento de curação manual.

Templates vêm em quatro formas. Um template de detalhe por tipo de entidade, com slots explícitos para dados únicos mais o envolvimento editorial. Um template de comparação para frente a frente entre entidades nomeadas, schema FAQPage anexado, nunca AggregateRating a menos que avaliações de primeira parte realmente existam. Um template de categoria e filtro usando CollectionPage com ItemList de entidades qualificadas, paginado com manipulação canônica apropriada para que combinações de filtros não criem URLs duplicadas infinitas. E templates editoriais usando schema Article, escritos à mão, volume menor, peso temático maior, tratados como a espinha dorsal do gráfico de links em vez das folhas.

Andaimes de SEO é a parte que a maioria dos times subestima em escala. O sitemap flui em pedaços por template, porque um único sitemap.xml atinge o máximo em cinquenta mil URLs e a maioria dos projetos programáticos passa disso dentro do primeiro ano. Ligação interna é gerada a partir dos dados em si — toda folha se liga para sua categoria, sua localização, seus concorrentes nomeados e entidades similares por sobreposição de recursos. Um linter de SEO em tempo de compilação tira uma amostra de páginas em cada deploy e falha a compilação em qualquer anomalia de contagem de H1, meta description fora do intervalo, erro de validade JSON-LD ou problema de integridade de cluster hreflang. Após o lançamento, rastreamento de citações de AI Overview via Otterly ou Profound é executado semanalmente para detectar quando um mecanismo de busca generativo começa a citar ou para de citar uma página no domínio.

Intervalos honestos, tirados de engajamentos recentes reais em vez de preços aspiracionais em um deck de vendas. Uma compilação programática pequena com menos de mil entidades custa dezoito a trinta mil dólares americanos durante seis a nove semanas. Trabalho de tamanho médio entre mil e dez mil entidades, com importação de dados estruturados, custa trinta a sessenta mil durante oito a quatorze semanas. Projetos maiores entre dez mil e cem mil entidades, com um pipeline de ingestão customizado contra uma API externa ou fonte de scraping, custam cinquenta a noventa mil durante doze a dezoito semanas. Planos de manutenção para operação contínua, atualização de conteúdo e manutenção de gate de qualidade custam quinhentos a três mil por mês após o lançamento.

Cada intervalo inclui o scaffolding de dados, os templates, o linter de SEO e um dashboard admin básico para overrides editoriais. Eles não incluem a aquisição de dados em si. Editorial manual, infraestrutura de scraping, custos de API de terceiros e trabalho original de marca e design são todos itens de linha separados. Aquisição de tráfego pago também está fora do escopo; SEO programático é um jogo orgânico e não agrupamos mídia paga no engajamento. A maioria dos projetos se situa confortavelmente na metade inferior de cada banda; a metade superior existe para compilações genuinamente complexas onde a ingestão de dados ou a camada editorial é incomumente pesada.