SEO Programático: Como Indexamos 253K Páginas com Next.js & Supabase
SEO Programático: Como Conseguimos Indexar 253K Páginas com Next.js & Supabase
No ano passado, ultrapassamos um marco que genuinamente não achei que fosse possível: 253.000 páginas programáticas indexadas em três sites de produção, todos rodando na mesma stack. Não é um projeto de brinquedo. Não é uma demo. São sites reais com tráfego real e receita real.
Vou guiá-lo exatamente como construímos Deluxe Astrology (91.000 páginas), Not Another Sunday (137.000 listagens de locais) e HostList (25.000 perfis de empresas de hospedagem) -- incluindo as queries do Supabase, a arquitetura de páginas do Next.js, os pipelines de dados, e mais importante, o que quebrou no caminho. Porque muita coisa quebrou.
A maioria do conteúdo sobre SEO programático na internet parece escrita por alguém que folheou a documentação e pronto. Não é assim. Estamos entregando essas páginas há mais de um ano, observando gráficos do Google Search Console, xingando limites de crawl budget e lentamente descobrindo o que realmente funciona em escala.
Índice
- O que SEO Programático Realmente Significa em 2025
- Os Três Projetos: Números de Produção
- A Stack: Supabase, Next.js ISR, Vercel Edge
- Arquitetura do Pipeline de Dados
- Arquitetura de Template de Página que o Google Não Odeia
- Código Real: Da Query Supabase à Página Renderizada
- O que Quebrou e Como Consertamos
- Resultados: O Hóquei no Gelo e os Fracassos Honestos
- SEO Programático vs. Conteúdo Tradicional: Quando Usar Qual
- FAQ
O que SEO Programático Realmente Significa em 2025
SEO programático é gerar páginas em escala a partir de dados estruturados usando templates. Essa é a versão de uma frase. A realidade é muito mais bagunçada.
A posição do Google em 2025 é clara, mas matizada: eles não penalizam conteúdo programático porque ele é programático. Eles penalizam quando é fino, duplicado ou inútil. A diferença entre as 70.000 páginas indexadas do Zapier contribuindo para $140M ARR e um case study do dev.to onde 287.000 páginas receberam quase zero indexação resume-se a uma coisa -- se cada página realmente responde a uma query que um humano digitou em uma barra de pesquisa.
Os dados do Ahrefs nos dizem que 96,55% de todas as páginas web recebem zero tráfego orgânico. SEO programático amplifica esse problema se você está apenas criando variações do mesmo conteúdo. Mas também pode resolver de forma espetacular se seus dados são genuinamente únicos e seus templates produzem páginas que são significativamente diferentes umas das outras.
O modelo mental que funciona para nós: cada página programática deve passar no teste "eu marcaria isso como favorito?". Se você caísse nela através do Google, você ficaria? Você encontraria algo que não consegue encontrar em outro lugar? Se a resposta é não, não publique.
Os Três Projetos: Números de Produção
Deixe-me detalhar o que realmente construímos e como os números se veem.
| Projeto | Páginas | Tipos de Conteúdo | Alcance Geográfico | Métrica-Chave |
|---|---|---|---|---|
| Deluxe Astrology | 91.000 | Horoscópios, perfis de celebridades, números anjos, moedas cósmicas, pedras preciosas, poses de yoga, laboratório de nomes, diretório de astrólogos | 30 idiomas | 91K páginas indexadas |
| Not Another Sunday | 137.000 | Listagens de locais (cafés e torrefadores) com score NRI, fotos, mapas | USA, UK, Japão | 137K páginas únicas de locais |
| HostList | 25.000 | Perfis de empresas de hospedagem com algoritmo HostScore | 53 países | 25K perfis indexados |
| Total | 253.000 |
Deluxe Astrology: 91K Páginas em 30 Idiomas
Deluxe Astrology começou como um site de horoscópio em um único idioma. A escala veio da intersecção de tipos de conteúdo e idiomas. Pense assim: se você tem 12 signos do zodíaco × 365 horoscópios diários × 30 idiomas, você já tem 131.000 páginas potenciais apenas de um tipo de conteúdo. Fomos seletivos -- nem toda combinação recebe uma página -- mas a natureza combinatória do conteúdo astrológico é perfeita para pSEO.
A seção de perfis de celebridades sozinha tem 28.840 registros, cada um enriquecido via Claude para incluir análise de carta natal, desdobramentos de personalidade e insights de compatibilidade. Mais sobre esse pipeline de dados depois.
Not Another Sunday: 137K Listagens de Locais
Not Another Sunday é uma plataforma de descoberta de café especializado. Todo café e torrefador recebe uma página única com um score proprietário NRI (Índice de Relevância de Bairro), fotos curadas, um mapa incorporado, horários de funcionamento e avaliações. Puxamos dados de múltiplas APIs, conteúdo gerado por usuários e curação manual.
O insight-chave: nenhuma duas páginas de locais se parecem porque nenhuns dois locais são iguais. O template é consistente, mas os dados o preenchem de forma diferente cada vez. Um café em Shibuya com NRI 4.8 e competições de latte art se parece bem diferente de um torrefador em Brooklyn com NRI 3.2 e operações apenas no atacado.
HostList: 25K Perfis de Hospedagem em 53 Países
HostList cataloga empresas de hospedagem em todo o mundo, cada uma com um HostScore -- nossa classificação algorítmica baseada em dados de uptime, preços, responsividade de suporte e avaliações de usuários. 25.000 perfis em 53 países, cada um com dados de desempenho únicos, tabelas de preços e widgets de comparação.
A Stack: Supabase, Next.js ISR, Vercel Edge
Padronizamos a mesma stack em todos os três projetos. Aqui está o porquê de cada peça ser importante.
Supabase (PostgreSQL + pgvector): Toda nossa camada de dados vive no Supabase. PostgreSQL nos dá a estrutura relacional que precisamos para queries complexas (me dê todas as celebridades Sagitário nascidas em dezembro que também são músicos), e pgvector potencializa a busca semântica em todo o conteúdo. A camada gratuita do Supabase lidar com 500MB; estamos no Pro a $25/mês por projeto para bancos de dados de 8GB com chamadas de API ilimitadas.
Next.js com ISR (Incremental Static Regeneration): Cada página é gerada estaticamente no tempo de build ou na primeira solicitação, então revalidada em um cronograma. Isso significa que o crawler do Google sempre atinge uma página HTML rápida e pré-renderizada -- não um spinner de carregamento esperando JavaScript no lado do cliente. Usamos o App Router com generateStaticParams para geração de caminhos.
Vercel Edge: Deploy, CDN e edge middleware tudo em um. O plano Pro do Vercel a $20/usuário/mês nos dá 1TB de bandwidth, que lida confortavelmente com o tráfego de 253K páginas. Edge Middleware lida com roteamento geográfico para configuração de 30 idiomas do Deluxe Astrology.
O custo total de infraestrutura para todos os três projetos fica em torno de $150–200/mês. Isso está hospedando 253.000 páginas que recebem milhões de crawls mensais. Se você está construindo sites programáticos e considerando nossas capacidades de desenvolvimento Next.js ou precisa de ajuda com arquitetura headless CMS, essa é a stack que recomendaríamos.
Arquitetura do Pipeline de Dados
Os dados são o que fazem ou quebram o SEO programático. Templates são fáceis. Conseguir dados genuinamente únicos e de alta qualidade para dezenas de milhares de páginas? Essa é a parte difícil.
Usamos quatro tipos de fonte de dados em nossos projetos:
1. API Scraping
Not Another Sunday puxa dados de locais da Google Places API, Yelp Fusion API e um punhado de APIs regionais para o Japão. Executamos jobs de sincronização noturnos via Supabase Edge Functions que verificam novos locais, horários atualizados e locais fechados. Cada resposta de API é normalizada para nosso schema antes da inserção.
2. Importação CSV com Validação
O dataset inicial do HostList veio de um enorme CSV de empresas de hospedagem compilado ao longo de dois anos. Construímos um pipeline de validação que verifica duplicatas, normaliza nomes de empresas e marca registros incompletos. Cerca de 30% da importação inicial foi marcado e requeriu revisão manual.
3. Enriquecimento com Claude AI
É aqui que fica interessante. Para Deluxe Astrology, tínhamos 28.840 registros de celebridades com dados biográficos básicos -- nome, data de nascimento, local de nascimento. Isso não é suficiente para uma página útil. Usamos Claude (API do Anthropic) para enriquecer cada registro com interpretação de carta natal, análise de personalidade, insights de compatibilidade de carreira e curiosidades.
A chave: não usamos Claude para gerar conteúdo do nada. Usamos para analisar e interpretar dados astronômicos reais. A carta natal de cada celebridade é calculada matematicamente a partir de seus dados de nascimento, depois Claude fornece a interpretação astrológica. Os dados subjacentes são únicos e verificáveis. A camada de IA adiciona profundidade, não fabricação.
Aqui está uma versão simplificada do nosso pipeline de enriquecimento:
import anthropic
from supabase import create_client
client = anthropic.Anthropic()
supabase = create_client(SUPABASE_URL, SUPABASE_KEY)
def enrich_celebrity(record):
natal_chart = calculate_natal_chart(
birth_date=record['birth_date'],
birth_place=record['birth_place']
)
prompt = f"""Dada essa dados de carta natal para {record['name']}:
Sol: {natal_chart['sun_sign']} em {natal_chart['sun_house']}
Lua: {natal_chart['moon_sign']} em {natal_chart['moon_house']}
Ascendente: {natal_chart['ascendant']}
Escreva um perfil de personalidade astrológica de 300 palavras focando em
como essas posições se manifestam em sua carreira como {record['profession']}.
Inclua interpretações de aspectos específicos."""
response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}]
)
supabase.table('celebrities').update({
'natal_chart': natal_chart,
'ai_profile': response.content[0].text,
'enriched_at': 'now()'
}).eq('id', record['id']).execute()
Processamos todos os 28.840 registros ao longo de cerca de uma semana, batchando requisições para ficar dentro dos limites de taxa. O custo foi aproximadamente $180 em créditos de API. Não é ruim para enriquecer quase 29K páginas com conteúdo único.
4. Conteúdo Gerado por Usuários
Not Another Sunday aceita avaliações e submissões de fotos de usuários. Esse UGC torna páginas progressivamente mais únicas ao longo do tempo e sinaliza ao Google que o conteúdo é fresco e impulsionado pela comunidade.
Arquitetura de Template de Página que o Google Não Odeia
É aqui que a maioria dos projetos de SEO programático falha. Eles criam um template como:
<h1>{City} {Service} Directory</h1>
<p>Looking for {service} in {city}? Browse our directory of {count} providers.</p>
Esse é conteúdo fino. Google sabe disso. Usuários sabem disso. Não faça isso.
Nossa arquitetura de template garante que cada página tenha cinco elementos únicos:
H1 Único: Não apenas
{name}inserido em um padrão. A estrutura do H1 varia por tipo de conteúdo e inclui modificadores contextuais.Meta descrição única: Gerada a partir dos dados reais da página, não um template com espaços em branco preenchidos.
Conteúdo de corpo único: Esse é o grande. Cada página tem 400-2.000 palavras de conteúdo específico para essa entidade. Para celebridades, é sua análise de carta natal. Para locais, é seu desdobramento do NRI, contexto de bairro e destaques do menu. Para empresas de hospedagem, é seu desdobramento do HostScore com percentuais de uptime específicos e preços.
Dados estruturados (schema.org): Cada página obtém marcação JSON-LD apropriada para seu tipo --
Personpara celebridades,LocalBusinesspara locais,Organizationpara empresas de hospedagem.Linking interno: Cada página lida com 5-15 páginas relacionadas baseado em relacionamentos de dados reais. Uma página de celebridade liga para outras celebridades com o mesmo signo do sol, mesma profissão ou mesmo ano de nascimento. Uma página de local liga para locais próximos e locais com scores NRI similares.
O piece de internal linking se mostrou ser o fator único mais importante para indexação. Mais sobre isso na seção de correções.
Código Real: Da Query Supabase à Página Renderizada
Deixe-me mostrar o fluxo real para uma página de local Not Another Sunday. Esse é código de produção, simplificado um pouco para legibilidade.
Primeiro, a camada de query do Supabase:
// lib/queries/venues.ts
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.SUPABASE_SERVICE_ROLE_KEY!
)
export async function getVenueBySlug(slug: string) {
const { data, error } = await supabase
.from('venues')
.select(`
id, name, slug, description, nri_score,
address, city, country, lat, lng,
opening_hours, photos, menu_highlights,
created_at, updated_at,
venue_reviews (
id, rating, body, author_name, created_at
),
venue_tags (
tag:tags ( name, slug )
)
`)
.eq('slug', slug)
.eq('status', 'published')
.single()
if (error) throw error
return data
}
export async function getRelatedVenues(venueId: string, city: string, nriScore: number) {
const { data } = await supabase
.rpc('get_related_venues', {
p_venue_id: venueId,
p_city: city,
p_nri_score: nriScore,
p_limit: 12
})
return data ?? []
}
A função get_related_venues é uma função PostgreSQL no Supabase que retorna locais próximos classificados pela proximidade do score NRI:
CREATE OR REPLACE FUNCTION get_related_venues(
p_venue_id UUID,
p_city TEXT,
p_nri_score NUMERIC,
p_limit INT DEFAULT 12
)
RETURNS TABLE (
id UUID, name TEXT, slug TEXT,
nri_score NUMERIC, city TEXT, country TEXT
) AS $$
BEGIN
RETURN QUERY
SELECT v.id, v.name, v.slug, v.nri_score, v.city, v.country
FROM venues v
WHERE v.id != p_venue_id
AND v.status = 'published'
AND v.city = p_city
ORDER BY ABS(v.nri_score - p_nri_score) ASC
LIMIT p_limit;
END;
$$ LANGUAGE plpgsql;
Agora o componente de página Next.js usando App Router:
// app/venues/[country]/[city]/[slug]/page.tsx
import { getVenueBySlug, getRelatedVenues } from '@/lib/queries/venues'
import { VenueHeader } from '@/components/venue/VenueHeader'
import { NRIScoreCard } from '@/components/venue/NRIScoreCard'
import { VenueMap } from '@/components/venue/VenueMap'
import { ReviewSection } from '@/components/venue/ReviewSection'
import { RelatedVenues } from '@/components/venue/RelatedVenues'
import { venueJsonLd } from '@/lib/schema/venue'
import { notFound } from 'next/navigation'
export const revalidate = 3600 // ISR: revalidate every hour
export async function generateMetadata({ params }: Props) {
const venue = await getVenueBySlug(params.slug)
if (!venue) return {}
const reviewCount = venue.venue_reviews?.length ?? 0
const avgRating = reviewCount > 0
? (venue.venue_reviews.reduce((sum, r) => sum + r.rating, 0) / reviewCount).toFixed(1)
: null
return {
title: `${venue.name} -- Café Especializado em ${venue.city} | NRI ${venue.nri_score}`,
description: avgRating
? `${venue.name} em ${venue.city} marca ${venue.nri_score}/10 NRI. Avaliado ${avgRating}/5 em ${reviewCount} avaliações. ${venue.description?.slice(0, 80)}...`
: `${venue.name} em ${venue.city} marca ${venue.nri_score}/10 em nosso Índice de Relevância de Bairro. ${venue.description?.slice(0, 100)}...`,
alternates: {
canonical: `/venues/${params.country}/${params.city}/${params.slug}`
}
}
}
export default async function VenuePage({ params }: Props) {
const venue = await getVenueBySlug(params.slug)
if (!venue) notFound()
const related = await getRelatedVenues(venue.id, venue.city, venue.nri_score)
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(venueJsonLd(venue)) }}
/>
<article>
<VenueHeader venue={venue} />
<NRIScoreCard score={venue.nri_score} breakdown={venue.nri_breakdown} />
<VenueMap lat={venue.lat} lng={venue.lng} />
<section className="venue-body">
<h2>Sobre {venue.name}</h2>
<p>{venue.description}</p>
{venue.menu_highlights && (
<>
<h3>Destaques do Menu</h3>
<ul>
{venue.menu_highlights.map(item => (
<li key={item}>{item}</li>
))}
</ul>
</>
)}
</section>
<ReviewSection reviews={venue.venue_reviews} />
<RelatedVenues venues={related} currentCity={venue.city} />
</article>
</>
)
}
Note revalidate = 3600. Isso é ISR -- a página é gerada estaticamente na primeira solicitação e cacheada por uma hora. O crawler do Google sempre recebe HTML rápido. Dados frescos fluem na próxima ciclo de revalidação. Isso importa enormemente para o crawl budget.
O que Quebrou e Como Consertamos
É aqui que a maioria dos case studies fica desonesta. Eles mostram os resultados sem os meses de debugging. Temos três problemas maiores.
Problema 1: Deluxe Astrology -- Inanição de Crawl Budget
Lançamos com 91.000 páginas e uma estrutura de sitemap plana. Google indexou cerca de 12.000 páginas no primeiro mês e então... parou. O relatório de cobertura do GSC mostrou "Descoberto -- atualmente não indexado" para dezenas de milhares de URLs.
O problema era duplo. Primeiro, nosso sitemap era um arquivo único com 91.000 URLs. Google recomenda máximo 50.000 por sitemap, mas mesmo dentro desse limite, um sitemap massivo único não sinaliza prioridade. Segundo, nosso linking interno era fraco -- muitas páginas eram apenas alcançáveis através do sitemap, não através de links na página.
A correção:
Reestruturação de sitemap: Dividimos o sitemap monolítico em sitemaps baseados em categorias.
sitemap-celebrities.xml,sitemap-horoscopes-en.xml,sitemap-horoscopes-es.xml, etc. Cada um sob 10.000 URLs.Overhaul de linking interno: Adicionamos cross-links contextuais em cada página. Páginas de celebridades agora ligam para celebridades relacionadas (mesmo zodíaco, mesma profissão, mesmo ano de nascimento). Páginas de horoscópio ligam para os perfis de celebridades para esse signo. Cada página se conecta a pelo menos 8 outras páginas.
Remoção de página fina: Matamos cerca de 4.000 páginas que tinham menos de 200 palavras de conteúdo único. Essas eram principalmente páginas de combinação auto-geradas que não adicionavam valor. Menos páginas, mas qualidade mais alta.
Após essas mudanças, a indexação subiu de 12K para 91K ao longo de cerca de 10 semanas. O linking interno foi a maior alavanca.
Problema 2: HostList -- Configuração ISR Incorreta
HostList lançou com export const dynamic = 'force-dynamic' em cada página. Isso significava que toda solicitação única -- incluindo todo crawl do Googlebot -- atingia Supabase em tempo real. Com Google rastreando milhares de páginas por dia, nossa instância Supabase estava sendo martelada, tempos de resposta aumentaram e algumas páginas tiveram timeout durante crawls.
A correção: Mudamos para export const revalidate = 3600. Páginas recebem cache estático e servem em menos de 100ms. Supabase é atingido apenas uma vez por hora por página em vez de uma vez por solicitação. Nosso tempo de resposta p95 caiu de 2.8 segundos para 47 milissegundos. Googlebot começou a rastrear 3x mais páginas por dia porque não estava esperando ao redor.
Problema 3: Not Another Sunday -- Conteúdo Duplicado Entre Países
Algumas redes de cafés operam em múltiplos países. Starbucks Reserve em Tóquio e Starbucks Reserve em Londres inicialmente tinham conteúdo de página muito similar porque o template enfatizava informações de marca sobre dados específicos de localização.
A correção: Ponderamos conteúdo específico de localização muito mais. Descrições de bairro, comparações de locais próximos, sentimento de revisão local e preços específicos do país agora fazem up 70%+ de cada página. A informação de marca é uma seção pequena. Google parou de marcar essas como quase-duplicatas.
Resultados: O Hóquei no Gelo e os Fracassos Honestos
Os dados combinados de GSC em todos os três projetos mostram a curva clássica de hóquei no gelo -- plana por semanas, depois crescimento exponencial conforme o crawler do Google ganhou confiança em nossos domínios.
| Métrica | Mês 1 | Mês 3 | Mês 6 | Mês 12 |
|---|---|---|---|---|
| Total de páginas indexadas | 18.200 | 67.000 | 189.000 | 253.000 |
| Cliques orgânicos diários | 340 | 2.100 | 8.400 | 19.600 |
| Posição média (todas as queries) | 42 | 28 | 16 | 11 |
| Requisições de crawl/dia (todos os sites) | 4.200 | 12.800 | 31.000 | 48.000 |
| Custo mensal de Supabase | $75 | $75 | $125 | $150 |
| Custo mensal de Vercel | $40 | $60 | $60 | $60 |
Mas deixe-me ser honesto sobre os fracassos também. Cerca de 8% de nossas páginas ainda estão em "Descoberto -- atualmente não indexado" após 12 meses. Essas tendem a ser as páginas de menor potencial de tráfego na cauda longa -- páginas específicas de número de anjo em idiomas de baixo volume de busca, ou empresas de hospedagem em mercados pequenos. Poderíamos provavelmente forçar-indexá-las com mais links internos, mas o ROI não está lá.
Também tivemos um período por volta do mês 4 onde o tráfego do Deluxe Astrology caiu 30% após uma atualização central do Google. Ele se recuperou ao longo de 6 semanas sem nenhuma mudança de nossa parte, mas essas foram semanas estressantes. Sites programáticos parecem mais voláteis durante atualizações principais porque Google reavalia sinais de qualidade em todo o corpus de página ao mesmo tempo.
Se você está considerando construir algo nessa escala, detalhamos nossa abordagem e preços em nossa página de preços. Para geração de site estático baseado em Astro -- que também experimentamos para pSEO puro-estático -- confira nossas capacidades de desenvolvimento Astro.
SEO Programático vs. Conteúdo Tradicional: Quando Usar Qual
SEO programático não é um substituto para conteúdo editorial. É uma ferramenta diferente para um trabalho diferente.
| Fator | SEO Programático | Conteúdo Tradicional |
|---|---|---|
| Melhor para | Queries orientadas a dados ("melhores cafés em Shibuya", "horoscópio de Leão hoje") | Queries orientadas a intenção ("como fazer café pour-over") |
| Unicidade de conteúdo | Vem de dados únicos por página | Vem de perspectiva/pesquisa única |
| Velocidade de scaling | 1.000+ páginas por semana | 2-5 artigos por semana |
| Carga de manutenção | Atualizações de banco de dados, correções de template | Atualização periódica de conteúdo |
| Construção de confiança do Google | Mais lenta (precisa provar qualidade em escala) | Mais rápida (cada piece julgada individualmente) |
| Perfil de risco | Mais alto (penalidades de conteúdo fino afetam site inteiro) | Mais baixo (um artigo ruim não derruba o domínio) |
O ponto doce é combinar ambos. Not Another Sunday tem 137K páginas de locais programáticos e 200+ guias editoriais sobre cultura do café, métodos de preparo e rotas de café específicas da cidade. O conteúdo editorial constrói sinais de E-E-A-T que elevam o domínio inteiro, o que ajuda as páginas programáticas a indexar mais rápido.
FAQ
Quantas páginas você pode realistically conseguir indexadas com SEO programático?
Depende inteiramente da autoridade de domínio e qualidade de conteúdo. Em domínios estabelecidos com perfis de backlink fortes, vimos taxas de indexação de 90%+ para 100K+ páginas. Domínios novos lutam -- o case study do dev.to de 287K páginas em um domínio fresco recebendo quase zero indexação é a norma, não a exceção. Comece com 1.000-5.000 páginas de alta qualidade, construa autoridade, então scale.
Qual é o mínimo de conteúdo por página para evitar penalidades de conteúdo fino?
Miramos por pelo menos 400 palavras de conteúdo único por página, mais dados estruturados, imagens e links internos. Mas contagem de palavra sozinha não é a métrica -- é sobre se a página responde melhor a query do usuário do que o que já existe. Uma página de 200 palavras com tabelas de dados únicas e um mapa pode superar uma página de 2.000 palavras de texto genérico.
SEO programático ainda é seguro após as atualizações de conteúdo útil do Google em 2025?
Sim, mas apenas se você está genuinamente criando páginas úteis. As atualizações de 2025 do Google especificamente miraram conteúdo programático de baixa qualidade que existe apenas para capturar tráfego de busca sem fornecer valor. Sites como Zapier (70K páginas, $140M ARR) continuam prosperar porque suas páginas resolvem problemas reais. Os sites sendo penalizados são aqueles gerando variações de "Melhor {serviço} em {cidade}" sem dados reais atrás.
Quanto custa uma stack de SEO programático com Supabase e Vercel?
Nossa stack de três projetos roda cerca de $150-200/mês total. Supabase Pro é $25/mês por projeto (usamos três instâncias). Vercel Pro é $20/usuário/mês. O enriquecimento de IA via API do Claude foi um custo único de cerca de $180 para 28.840 registros. Para a maioria dos projetos under 50K páginas, espere $50-100/mês em custos de infraestrutura.
Quanto tempo leva para Google indexar páginas programáticas?
Espere 2-4 semanas para rastreamento inicial de seus sitemaps, mas indexação completa de grandes conjuntos de páginas leva 3-6 meses. Nossa experiência mostra um padrão de hóquei no gelo: rastreamento lento nos primeiros 6-8 semanas conforme Google avalia qualidade, então aceleração rápida uma vez que decide que seu conteúdo vale a pena indexar. Linking interno e estrutura de sitemap dramaticamente afetam essa linha do tempo.
Devo usar Next.js SSR ou ISR para páginas programáticas de SEO?
ISR, quase sempre. SSR (force-dynamic) significa que toda solicitação de crawler -- incluindo todo Googlebot -- atinge seu banco de dados em tempo real, que cria problemas de desempenho em escala e desperdiça crawl budget em respostas lentas. ISR com revalidate = 3600 (ou até 86400 para atualizações diárias) lhe dá desempenho de site estático com atualização de dados dinâmica. Aprendemos isso da forma difícil com HostList -- mudar de force-dynamic para ISR cortou nosso tempo de resposta de 2.8s para 47ms.
Como você lida com linking interno entre 100K+ páginas?
Queries de conteúdo relacionado orientadas por banco de dados. Cada página executa uma query que encontra 8-15 páginas relacionadas baseado em relacionamentos de dados reais -- mesma categoria, scores similares, proximidade geográfica, atributos compartilhados. Não apenas link aleatoriamente para páginas. Os links precisam fazer sentido contextual tanto para usuários quanto para Google. Usamos funções PostgreSQL no Supabase para computar essas relações eficientemente.
Qual é o maior erro que as pessoas cometem com SEO programático?
Focar em contagem de página em vez de qualidade de página. É tentador gerar toda combinação possível de seus dados, mas 10.000 páginas excelentes superam 100.000 medíocres toda vez. Matamos 4.000 páginas finas no Deluxe Astrology e vimos indexação aumentar em páginas restantes. Google interpreta páginas finas como um sinal que seu site inteiro pode ser de baixa qualidade. Se você está pronto para construir páginas programáticas da forma correta, entre em contato com nosso time -- aprendemos essas lições para que você não tenha que aprender.