guides/directories.html

CONSTRUINDO UM SITE DE DIRETÓRIO

Modelo de dados, renderização com templates, gates de indexabilidade e linking interno programático. A partir da entrega do HostList.io e Not Another Sunday em escala de centenas de milhares de páginas.

CONSTRUINDO UM SITE DE DIRETÓRIO

← Blog All posts in this topic

O que é este guia

Sites de diretório e plataformas de listagem são uma categoria específica de projeto de SEO programático que entreguei em escala significativa. HostList.io tem aproximadamente 28.000 empresas de hospedagem web indexadas em categorias, regiões e faixas de preço, todas geradas programaticamente a partir de um modelo de dados estruturado. Not Another Sunday tem 137.000 pubs, bares e restaurantes do Reino Unido. Ambos funcionam no mesmo padrão arquitetural: um modelo de dados limpo, um renderizador de página com templates, um gate rigoroso de indexabilidade e um grafo de linking interno programático.

Este guia é a visão do operador sobre como construir uma plataforma de diretório ou listagem que se sustente sob o escrutínio dos motores de busca em 2026, o que evitar e as partes do conselho convencional que estão erradas na prática. A partir da entrega de múltiplas plataformas de diretório pessoalmente e em engajamentos de clientes da Seahawk Media.

Quando um diretório é o produto certo

Um site de diretório vence quando três coisas são verdadeiras ao mesmo tempo: um mercado fragmentado com muitas entidades concorrentes ou similares, um público que busca com intenção comparativa (melhor, top, vs, mais barato) e a ausência de um único agregador dominante que já possua os SERPs.

Exemplos que funcionaram: empresas de hospedagem web (fragmentado, comparativo, sem um agregador único de propriedade do Google), restaurantes em Londres (fragmentado, a intenção de busca é intensa, os agregadores existentes estão enfraquecendo), ferramentas de software nicho por categoria (fragmentado, os sites de comparação são inconsistentes em qualidade).

Exemplos que não funcionaram: qualquer coisa onde o próprio Google é o agregador dominante (empregos, voos, hipotecas em alguns mercados), qualquer coisa onde as entidades são poucas demais para suportar milhares de páginas (grandes escritórios de advocacia em uma única cidade, por exemplo), qualquer coisa onde os critérios de comparação são muito subjetivos para codificar em um modelo de dados.

A decisão do modelo de dados

Normalizar cedo e com força

Cada entidade (a empresa, a localização, o produto) recebe uma única linha canônica com um ID estável e uma slug que nunca muda. Cada atributo (categoria, faixa de preço, região, funcionalidade) recebe sua própria tabela ou enum, nunca um campo de texto livre. Relacionamentos muitos-para-muitos recebem tabelas de junção. O custo de acertar errado no primeiro dia é anos de instabilidade de slug e redirects quebrados.

Slugs são para sempre

Uma vez que uma página de diretório é indexada pelo Google, a slug não deve mudar. Use padrões slug-of-record: geração determinística a partir do nome da entidade, tratamento de colisão por sufixo numérico, e uma tabela de pesquisa que mapeia qualquer slug histórica para a atual para redirects permanentes 301. Temos uma regra de estabilidade de slug no HostList.io que não mudou em três anos.

O design de schema que escala

No Supabase: uma tabela de entidades com o registro mestre, uma tabela de categorias, uma tabela de atributos, tabelas de junção para muitos-para-muitos, e uma computed_slug gerada que é única. Políticas RLS permitem leitura pública para linhas publicadas, escrita apenas de admin. Índices em cada coluna que você consulta no nível de página. O schema do HostList.io tem aproximadamente doze tabelas e não precisou de alterações estruturais desde o lançamento.

O renderizador de template

Um template, muitos rostos

Um site de diretório tem aproximadamente seis arquétipos de página: a página de entidade, a listagem de categoria, a comparação entre categorias, a página regional, a home e a busca. Cada uma recebe um template que renderiza milhares de páginas. A disciplina é: fazer o template bom o suficiente para que nenhuma página individual se beneficiasse de um tratamento especial, e resistir à tentação de criar casos especiais.

Unicidade acima da dobra

Cada página de entidade deve ter conteúdo único acima da dobra: um parágrafo de abertura único, fatos-chave únicos, dados de preço ou recursos únicos. O conteúdo único pode ser gerado programaticamente a partir do modelo de dados (HostList.io faz isso com aberturas com template que interpolam o nome da empresa, ano de fundação, mercado primário e um fato diferenciador), mas deve ler como se tivesse sido escrito para aquela entidade, não como um template de preencha-os-em-branco.

Marcação de schema em escala

Toda página de entidade emite schema Organization ou LocalBusiness com name, url, address (onde aplicável), aggregateRating (onde genuinamente disponível) e links sameAs para perfis sociais verificados. BreadcrumbList em toda página de categoria e entidade. ItemList em toda listagem de categoria. A camada de schema é o que torna o diretório legível por máquina tanto para Google quanto para as superfícies de IA.

O portão de indexabilidade que previne desastres

A Helpful Content Update é a maior ameaça para um site de diretório, e a causa mais comum de colapso de ranking em todo o domínio em sites programáticos. A contramedida é um portão de indexabilidade por página que decide quais páginas valem a pena indexar.

Limiares de qualidade por página

Páginas abaixo de um limiar de qualidade de conteúdo recebem noindex na própria página, independentemente de como o resto do site está configurado. Exemplos de limiares de qualidade que aplicamos: contagem mínima de palavras de conteúdo único (300 palavras no HostList.io), número mínimo de campos de dados estruturados preenchidos (8 de 12 para empresas de hospedagem), número mínimo de links internos apontando para a página (3 links de entrada de outras páginas de entidade ou categoria).

O sitemap segue o acesso restrito

O sitemap exclui qualquer página que seja restrita. O sitemap é o sinal mais confiável que você pode enviar ao Google sobre quais páginas você quer indexadas; páginas excluídas do sitemap mas acessíveis via crawl são rastreadas com menos frequência e ganham ranking fraco. A disciplina do sitemap mantém a superfície indexada limpa.

Robots e noindex são sobrepostos

Não usamos robots.txt para bloquear decisões de indexabilidade; robots.txt bloqueia crawl completamente, o que remove a capacidade do Google de respeitar o header noindex. O padrão correto é: permitir crawl, definir noindex em páginas restritas via meta robots header, excluir do sitemap.

O grafo de links internos

Em escala de diretório, linking interno precisa ser gerado, não curado manualmente. Cada página de entidade se vincula às suas categorias pai, suas entidades irmãs (mesma categoria, atributos semelhantes), a página regional se aplicável, e a página inicial. Cada página de categoria se vincula às suas entidades filhas, categorias pai, e categorias laterais. O grafo é computado no tempo de build e atualizado sempre que entidades são adicionadas ou removidas.

Variedade de anchor text

O anchor text interno deve variar. Vincular 8.000 páginas a uma página de categoria com o mesmo anchor text é um sinal fortemente negativo. Rotacionamos anchor text em um conjunto de templates: "[category] companies", "best [category] services", "[category] at [region]", "[entity] alternatives". A rotação é determinística por página de origem para que o grafo seja estável entre rebuilds.

Links internos em excesso é normal; agrupar links faz as páginas parecerem auto-geradas. Limitamos links internos a três por parágrafo e trinta por página, com o resto distribuído ao longo da página. A disciplina é editorial, aplicada no nível do template.

Hospedagem e infraestrutura para diretórios

Renderização estática com revalidação periódica

No Next.js: geração estática no momento da build, ISR com janela de revalidação de 24 horas para páginas de entidades, revalidação sob demanda quando uma entidade é atualizada pelo admin. Vercel lida com 28.000 páginas sem problema; o custo gira em torno dos eventos de escrita do ISR, que mantemos controláveis restringindo revalidação estritamente a mudanças de entidades em vez de qualquer ajuste de conteúdo.

Database connection pooling

Queries diretas ao Supabase a partir do template da página não escalam; você atinge limites de conexão durante uma rebuild completa. Usamos o padrão de geração estática: no momento da build, buscar todas as páginas em poucas queries grandes, gerar as páginas a partir de dados em memória. Renders de página nunca acessam o banco de dados diretamente. Os tempos de rebuild ficam abaixo de dez minutos para HostList.io com 28.000 páginas.

CDN e edge caching

Cloudflare na frente da origin sempre. O tier gratuito lida com o tráfego de diretório sem problemas; tiers pagos adicionam Argo para roteamento global se o tráfego justificar. Caching do CDN reduz a carga da origin para aproximadamente 5% do tráfego público em um perfil típico de tráfego de diretório.

As métricas que diagnosticam a saúde do diretório

Três métricas que verifico semanalmente em todos os sites de diretório que executo:

Páginas indexadas versus páginas publicadas

Search Console > Pages > Indexed comparado com a contagem do seu sitemap. Saudável: 90%+. Abaixo de 80%: Google tem preocupações com qualidade de sinal; revise os limites de gate. Abaixo de 70%: problema estrutural, provavelmente conteúdo fino ou intenção duplicada.

Posição média por arquétipo de template

Search Console filtrado por padrão de URL, segmentado por entidade / categoria / regional. Mostra qual template está funcionando e qual está arrastando o domínio. Capturamos regressões de template no HostList.io em 7 dias usando essa métrica.

Cliques por página indexada

Total de cliques dividido por páginas indexadas, semanalmente. Diretórios saudáveis: 0,3 a 1,5. Abaixo de 0,2: o índice é muito amplo e páginas sem tráfego estão diluindo o domínio. Aperte o gate.

Os erros que derrubam sites de diretório

Cinco erros que mataram sites de diretório que auditei:

1. Link interno curado manualmente que não sobreviveu a uma adição de conteúdo. O grafo precisa ser programático desde o primeiro dia.

2. Slugs que mudaram quando nomes de entidades foram corrigidos. Até uma mudança de slug sem um 301 custa sinal de ranking significativo; dez mudanças de slug podem ser terminais.

3. Páginas indexáveis sem conteúdo único. O Helpful Content Update não perdoa diretórios onde páginas de categoria parecem todas com o mesmo texto padrão.

4. Schema AggregateRating com avaliações falsas ou não verificáveis. O Google detecta isso e desvaloriza o schema globalmente. Use AggregateRating apenas quando as avaliações forem reais e verificáveis.

5. Tratar o diretório como um projeto de lançamento em vez de uma preocupação operacional contínua. Diretórios precisam de manutenção ativa: entidades obsoletas removidas, novas entidades adicionadas, links externos quebrados podados, schema mantido sincronizado. Sem isso, diretórios se degradam em 12 a 24 meses.

A questão fundamental

Um site de diretório que funciona em 2026 é um modelo de dados limpo, um renderizador de template disciplinado, uma porta de indexabilidade rigorosa, um grafo de links internos programático e cuidado operacional contínuo. A arquitetura é repetível; o que varia é a qualidade dos dados e o julgamento editorial sobre quais entidades e categorias merecem superfície indexável.

Você não precisa fazer tudo isso no primeiro dia. Você precisa saber quais destes você ainda não construiu e consertar o próximo antes que o Google perceba.

Construímos plataformas de diretório e listagem na Seahawk Media a partir de 18.000 USD. O case study HostList.io ilustra o padrão em escala; a conversa sobre como seu diretório específico deve parecer é gratuita.

WHEN YOU ARE READY TO TALK