El año pasado, cruzamos un hito que genuinamente no creía que fuera posible: 253,000 páginas programáticas indexadas en tres sitios de producción, todos ejecutándose en la misma pila tecnológica. No es un proyecto de juguete. No es una demostración. Sitios reales con tráfico real e ingresos reales.

Te mostraré exactamente cómo construimos Deluxe Astrology (91,000 páginas), Not Another Sunday (137,000 listados de lugares) y HostList (25,000 perfiles de empresas de hosting) -- incluyendo las consultas de Supabase, la arquitectura de páginas de Next.js, los pipelines de datos, y lo más importante, qué se rompió en el camino. Porque muchas cosas se rompieron.

La mayoría del contenido de SEO programático en línea parece escrito por alguien que hojeó los documentos y lo dejó así. Esto no es eso. Hemos estado publicando estas páginas durante más de un año, mirando fijamente los gráficos de Google Search Console, maldiciéndola por los límites de presupuesto de rastreo, e identificando lentamente qué funciona realmente a escala.

Tabla de Contenidos

Programmatic SEO: How We Got 253K Pages Indexed with Next.js & Supabase

Qué Significa Realmente SEO Programático en 2025

SEO programático es generar páginas a escala a partir de datos estructurados usando plantillas. Esa es la versión de una oración. La realidad es mucho más complicada.

La postura de Google en 2025 es clara pero matizada: no penalizan el contenido programático porque sea programático. Lo penalizan cuando es delgado, duplicado o poco útil. La diferencia entre las 70,000 páginas indexadas de Zapier que contribuyen a $140M ARR y un caso de estudio de dev.to donde 287,000 páginas obtuvieron casi cero indexación se reduce a una cosa -- si cada página responde genuinamente a una consulta que un humano escribió en una barra de búsqueda.

Los datos de Ahrefs nos dicen que el 96.55% de todas las páginas web obtienen cero tráfico orgánico. SEO programático amplifica este problema si solo estás generando variaciones del mismo contenido. Pero también puede resolverlo espectacularmente si tus datos son genuinamente únicos y tus plantillas producen páginas que son significativamente diferentes entre sí.

Aquí está el modelo mental que funciona para nosotros: cada página programática debería pasar la prueba del "¿Me lo guardaría en marcadores?". Si llegaras a ella desde Google, ¿te quedarías? ¿Encontrarías algo que no puedas encontrar en otro lugar? Si la respuesta es no, no la publiques.

Los Tres Proyectos: Números de Producción

Déjame exponer qué construimos realmente y cómo se ven los números.

Proyecto Páginas Tipos de Contenido Alcance Geográfico Métrica Clave
Deluxe Astrology 91,000 Horóscopos, perfiles de celebridades, números angélicos, monedas cósmicas, piedras preciosas, posturas de yoga, laboratorio de nombres, directorio de astrólogos 30 idiomas 91K páginas indexadas
Not Another Sunday 137,000 Listados de lugares - cafés y tostadores con puntuación NRI, fotos, mapas USA, UK, Japón 137K páginas de lugares únicas
HostList 25,000 Perfiles de empresas de hosting con algoritmo HostScore 53 países 25K perfiles indexados
Total 253,000

Deluxe Astrology: 91K Páginas en 30 Idiomas

Deluxe Astrology comenzó como un sitio de horóscopos en un solo idioma. La escala vino de la intersección de tipos de contenido e idiomas. Piénsalo: si tienes 12 signos zodiacales × 365 horóscopos diarios × 30 idiomas, ya estás en 131,000 páginas potenciales solo con un tipo de contenido. Fuimos selectivos -- no toda combinación obtiene una página -- pero la naturaleza combinatoria del contenido astrológico es perfecta para pSEO.

La sección de perfiles de celebridades tiene 28,840 registros, cada uno enriquecido vía Claude para incluir análisis de carta natal, desglose de personalidad y perspectivas de compatibilidad. Más sobre ese pipeline de datos después.

Not Another Sunday: 137K Listados de Lugares

Not Another Sunday es una plataforma de descubrimiento de café especializado. Cada café y tostador obtiene una página única con una puntuación NRI (Neighbourhood Relevance Index) propia, fotos seleccionadas, un mapa integrado, horarios de apertura y reseñas. Sacamos datos de múltiples APIs, contenido generado por usuarios, y curaduría manual.

La idea clave: ninguna de dos páginas de lugares se ve igual porque ninguno de dos lugares son iguales. La plantilla es consistente, pero los datos la llenan diferentemente cada vez. Un café en Shibuya con 4.8 NRI y competencias de latte art se ve completamente diferente a un tostador en Brooklyn con 3.2 NRI y operaciones solo mayoristas.

HostList: 25K Perfiles de Hosting en 53 Países

HostList cataloga empresas de hosting en todo el mundo, cada una con un HostScore -- nuestra calificación algorítmica basada en datos de uptime, precios, responsividad del soporte, y reseñas de usuarios. 25,000 perfiles en 53 países, cada uno con datos de rendimiento únicos, tablas de precios y widgets de comparación.

La Pila: Supabase, Next.js ISR, Vercel Edge

Estandarizamos la misma pila en los tres proyectos. Aquí está por qué cada pieza importa.

Supabase (PostgreSQL + pgvector): Toda nuestra capa de datos vive en Supabase. PostgreSQL nos da la estructura relacional que necesitamos para consultas complejas (dame todas las celebridades Sagitario nacidas en diciembre que también sean músicos), y pgvector potencia búsqueda semántica en el contenido. El nivel gratuito de Supabase maneja 500MB; estamos en Pro a $25/mes por proyecto para bases de datos de 8GB con llamadas API ilimitadas.

Next.js con ISR (Incremental Static Regeneration): Cada página se genera estáticamente en tiempo de compilación o en la primera solicitud, luego se revalida en un cronograma. Esto significa que el rastreador de Google siempre accede a una página HTML pre-renderizada y rápida -- no a un spinner de carga esperando JavaScript del lado del cliente. Usamos el App Router con generateStaticParams para generación de rutas.

Vercel Edge: Despliegue, CDN, y middleware de edge todo en uno. El plan Pro de Vercel a $20/usuario/mes nos da 1TB de ancho de banda, que maneja el tráfico de 253K páginas cómodamente. El Middleware de Edge maneja enrutamiento geográfico para la configuración de 30 idiomas de Deluxe Astrology.

El costo total de infraestructura para los tres proyectos ronda $150–200/mes. Eso es hosting de 253,000 páginas que reciben millones de rastreos mensuales. Si estás construyendo sitios programáticos y considerando nuestras capacidades de desarrollo en Next.js o necesitas ayuda con arquitectura de CMS sin cabeza, esta es la pila que recomendaríamos.

Programmatic SEO: How We Got 253K Pages Indexed with Next.js & Supabase - architecture

Arquitectura del Pipeline de Datos

Los datos son lo que hace o deshace SEO programático. Las plantillas son fáciles. ¿Obtener datos genuinamente únicos y de alta calidad para decenas de miles de páginas? Esa es la parte difícil.

Usamos cuatro tipos de fuentes de datos en nuestros proyectos:

1. Raspado de API

Not Another Sunday extrae datos de lugares de Google Places API, Yelp Fusion API, y un puñado de APIs regionales para Japón. Ejecutamos trabajos de sincronización nocturnos vía Supabase Edge Functions que verifican nuevos lugares, horarios actualizados, y ubicaciones cerradas. Cada respuesta de API se normaliza en nuestro esquema antes de la inserción.

2. Importación CSV con Validación

El conjunto de datos inicial de HostList vino de un CSV masivo de empresas de hosting compilado durante dos años. Construimos un pipeline de validación que busca duplicados, normaliza nombres de empresas, y marca registros incompletos. Aproximadamente el 30% de la importación inicial fue marcado y requirió revisión manual.

3. Enriquecimiento con IA Claude

Aquí es donde se pone interesante. Para Deluxe Astrology, teníamos 28,840 registros de celebridades con datos biográficos básicos -- nombre, fecha de nacimiento, lugar de nacimiento. Eso no es suficiente para una página útil. Usamos Claude (API de Anthropic) para enriquecer cada registro con interpretación de carta natal, análisis de personalidad, perspectivas de compatibilidad de carrera, e información divertida.

La clave: no usamos Claude para generar contenido de la nada. Lo usamos para analizar e interpretar datos astronómicos reales. La carta natal de cada celebridad se calcula matemáticamente a partir de sus datos de nacimiento, luego Claude proporciona la interpretación astrológica. Los datos subyacentes son únicos y verificables. La capa de IA agrega profundidad, no fabricación.

Aquí está una versión simplificada de nuestro pipeline de enriquecimiento:

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"""Dados estos datos de carta natal para {record['name']}:
    Sol: {natal_chart['sun_sign']} en {natal_chart['sun_house']}
    Luna: {natal_chart['moon_sign']} en {natal_chart['moon_house']}
    Ascendente: {natal_chart['ascendant']}
    
    Escribe un perfil de personalidad astrológica de 300 palabras enfocándose en
    cómo estas colocaciones se manifiestan en su carrera como {record['profession']}.
    Incluye interpretaciones 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()

Procesamos los 28,840 registros durante aproximadamente una semana, usando lotes de solicitudes para mantenernos dentro de los límites de velocidad. El costo fue aproximadamente $180 en créditos de API. No está mal para enriquecer casi 29K páginas con contenido único.

4. Contenido Generado por Usuarios

Not Another Sunday acepta reseñas y envíos de fotos de usuarios. Este UGC hace que las páginas sean cada vez más únicas con el tiempo y señala a Google que el contenido es fresco y impulsado por la comunidad.

Arquitectura de Plantillas de Páginas Que Google No Odia

Aquí es donde fallan la mayoría de proyectos de SEO programático. Crean una plantilla como:

<h1>{Ciudad} {Servicio} Directorio</h1>
<p>¿Buscas {servicio} en {ciudad}? Explora nuestro directorio de {contador} proveedores.</p>

Eso es contenido delgado. Google lo sabe. Los usuarios lo saben. No hagas esto.

Nuestra arquitectura de plantillas asegura que cada página tenga cinco elementos únicos:

  1. H1 único: No solo {nombre} insertado en un patrón. La estructura H1 varía por tipo de contenido e incluye modificadores contextuales.

  2. Descripción meta única: Generada a partir de los datos reales de la página, no una plantilla con espacios en blanco rellenados.

  3. Contenido del cuerpo único: Este es el grande. Cada página tiene 400-2,000 palabras de contenido específico para esa entidad. Para celebridades, es su análisis de carta natal. Para lugares, es su desglose de NRI, contexto del vecindario, y aspectos destacados del menú. Para empresas de hosting, es su desglose de HostScore con porcentajes de uptime específicos y precios.

  4. Datos estructurados (schema.org): Cada página obtiene marcado JSON-LD apropiado para su tipo -- Person para celebridades, LocalBusiness para lugares, Organization para empresas de hosting.

  5. Enlaces internos: Cada página se vincula a 5-15 páginas relacionadas basadas en relaciones de datos reales. Una página de celebridad se vincula a otras celebridades con el mismo signo solar, misma profesión, o mismo año de nacimiento. Una página de lugar se vincula a lugares cercanos y lugares con puntuaciones NRI similares.

La pieza de enlaces internos resultó ser el factor individual más importante para la indexación. Más sobre esto en la sección de fixes.

Código Real: Desde Consulta Supabase hasta Página Renderizada

Déjame mostrarte el flujo real para una página de lugar de Not Another Sunday. Este es código de producción, simplificado ligeramente para legibilidad.

Primero, la capa de consultas de 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 ?? []
}

La función get_related_venues es una función PostgreSQL en Supabase que devuelve lugares cercanos ordenados por proximidad de puntuación 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;

Ahora el componente de página de 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} -- Specialty Coffee in ${venue.city} | NRI ${venue.nri_score}`,
    description: avgRating
      ? `${venue.name} in ${venue.city} scores ${venue.nri_score}/10 NRI. Rated ${avgRating}/5 from ${reviewCount} reviews. ${venue.description?.slice(0, 80)}...`
      : `${venue.name} in ${venue.city} scores ${venue.nri_score}/10 on our Neighbourhood Relevance Index. ${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>About {venue.name}</h2>
          <p>{venue.description}</p>
          {venue.menu_highlights && (
            <>
              <h3>Menu Highlights</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>
    </>
  )
}

Observa revalidate = 3600. Esto es ISR -- la página se genera estáticamente en la primera solicitud y se almacena en caché durante una hora. El rastreador de Google siempre obtiene HTML rápido. Los datos frescos fluyen en el siguiente ciclo de revalidación. Esto importa enormemente para el presupuesto de rastreo.

Qué Se Rompió y Cómo Lo Arreglamos

Aquí es donde la mayoría de casos de estudio se vuelven deshonestos. Muestran los resultados sin los meses de debugging. Tuvimos tres problemas mayores.

Problema 1: Deluxe Astrology -- Inanición del Presupuesto de Rastreo

Lanzamos con 91,000 páginas y una estructura de sitemap plana. Google indexó aproximadamente 12,000 páginas en el primer mes y luego... se detuvo. El informe de cobertura de GSC mostró "Descubierto -- actualmente no indexado" para decenas de miles de URLs.

El problema era doble. Primero, nuestro sitemap era un archivo único con 91,000 URLs. Google recomienda máximo 50,000 por sitemap, pero incluso dentro de ese límite, un sitemap masivo único no señala prioridad. Segundo, nuestros enlaces internos eran débiles -- muchas páginas solo eran accesibles a través del sitemap, no a través de enlaces en la página.

La solución:

  1. Reestructuración de sitemap: Dividimos el sitemap monolítico en sitemaps basados en categorías. sitemap-celebrities.xml, sitemap-horoscopes-en.xml, sitemap-horoscopes-es.xml, etc. Cada uno bajo 10,000 URLs.

  2. Revisión de enlaces internos: Agregamos enlaces cruzados contextuales en cada página. Las páginas de celebridades ahora se vinculan a celebridades relacionadas (mismo zodíaco, misma profesión, mismo año de nacimiento). Las páginas de horóscopos se vinculan a los perfiles de celebridades de ese signo. Cada página se conecta a al menos 8 otras páginas.

  3. Eliminación de páginas delgadas: Matamos aproximadamente 4,000 páginas que tenían menos de 200 palabras de contenido único. Estas fueron principalmente páginas de combinación generadas automáticamente que no agregaban valor. Menos páginas, pero de mayor calidad.

Después de estos cambios, la indexación creció de 12K a 91K en aproximadamente 10 semanas. Los enlaces internos fueron el mayor factor.

Problema 2: HostList -- Misconfigración de ISR

HostList se lanzó con export const dynamic = 'force-dynamic' en cada página. Esto significaba que cada solicitud individual -- incluyendo cada rastreo de Googlebot -- golpeaba Supabase en tiempo real. Con Google rastreando miles de páginas por día, nuestra instancia de Supabase estaba siendo golpeada, los tiempos de respuesta aumentaban, y algunas páginas se agotaban durante los rastreos.

La solución: Cambiamos a export const revalidate = 3600. Las páginas se almacenan en caché estáticamente y se sirven en menos de 100ms. Supabase solo se accede una vez por hora por página en lugar de una vez por solicitud. Nuestro tiempo de respuesta p95 bajó de 2.8 segundos a 47 milisegundos. Googlebot comenzó a rastrear 3x más páginas por día porque no estaba esperando.

Problema 3: Not Another Sunday -- Contenido Duplicado en Países

Algunas cadenas de cafés operan en múltiples países. Starbucks Reserve en Tokio y Starbucks Reserve en Londres inicialmente tenían contenido de página muy similar porque la plantilla enfatizaba información de marca sobre datos específicos de ubicación.

La solución: Ponderamos el contenido específico de la ubicación mucho más alto. Las descripciones del vecindario, comparaciones con lugares cercanos, sentimiento de reseñas locales, y precios específicos del país ahora componen el 70%+ de cada página. La información de marca es una pequeña sección. Google dejó de señalar estos como casi-duplicados.

Resultados: El Efecto Hockey y los Fracasos Honestos

Los datos combinados de GSC en los tres proyectos muestran la curva de efecto hockey clásico -- plana durante semanas, luego crecimiento exponencial mientras el rastreador de Google ganaba confianza en nuestros dominios.

Métrica Mes 1 Mes 3 Mes 6 Mes 12
Total de páginas indexadas 18,200 67,000 189,000 253,000
Clics orgánicos diarios 340 2,100 8,400 19,600
Promedio de posición (todas las consultas) 42 28 16 11
Solicitudes de rastreo/día (todos los sitios) 4,200 12,800 31,000 48,000
Costo mensual de Supabase $75 $75 $125 $150
Costo mensual de Vercel $40 $60 $60 $60

Pero déjame ser honesto sobre los fracasos también. Aproximadamente el 8% de nuestras páginas aún se encuentran en "Descubierto -- actualmente no indexado" después de 12 meses. Estas tienden a ser las páginas de menor potencial de tráfico en la cola larga -- páginas de números angélicos específicas en idiomas de bajo volumen de búsqueda, o empresas de hosting en mercados pequeños. Probablemente podríamos forzar su indexación con más enlaces internos, pero el ROI no está allí.

También tuvimos un período alrededor del mes 4 donde el tráfico de Deluxe Astrology cayó un 30% después de una actualización central de Google. Se recuperó en 6 semanas sin cambios de nuestra parte, pero fueron semanas estresantes. Los sitios programáticos parecen ser más volátiles durante las actualizaciones principales porque Google reevalúa las señales de calidad en todo el corpus de páginas simultáneamente.

Si estás considerando construir algo a esta escala, hemos detallado nuestro enfoque y precios en nuestra página de precios. Para la generación de sitios estáticos basada en Astro -- que también hemos experimentado para pSEO puramente estático -- consulta nuestras capacidades de desarrollo de Astro.

SEO Programático vs. Contenido Tradicional: Cuándo Usar Cada Uno

SEO programático no es un reemplazo para contenido editorial. Es una herramienta diferente para un trabajo diferente.

Factor SEO Programático Contenido Tradicional
Mejor para Consultas impulsadas por datos ("mejores cafés en Shibuya", "horóscopo Leo hoy") Consultas impulsadas por intención ("cómo preparar café pour-over")
Unicidad del contenido Viene de datos únicos por página Viene de perspectiva/investigación única
Velocidad de escala 1,000+ páginas por semana 2-5 artículos por semana
Carga de mantenimiento Actualizaciones de base de datos, correcciones de plantillas Actualización periódica de contenido
Construcción de confianza en Google Más lento (necesita probar calidad a escala) Más rápido (cada pieza juzgada individualmente)
Perfil de riesgo Mayor (sanciones de contenido delgado afectan todo el sitio) Menor (un artículo malo no derrumba el dominio)

El punto dulce es combinar ambos. Not Another Sunday tiene 137K páginas de lugares programáticas y 200+ guías editoriales sobre cultura del café, métodos de preparación, y rutas de rastreo de cafés específicas de la ciudad. El contenido editorial construye señales de E-E-A-T que elevan todo el dominio, lo cual ayuda a que las páginas programáticas se indexen más rápido.

Preguntas Frecuentes

¿Cuántas páginas puedes indexar realísticamente con SEO programático? Depende enteramente de la autoridad del dominio y calidad del contenido. En dominios establecidos con fuertes perfiles de backlinks, hemos visto tasas de indexación del 90%+ para 100K+ páginas. Los dominios nuevos luchan -- el caso de estudio de dev.to de 287K páginas en un dominio fresco obtuviendo casi cero indexación es la norma, no la excepción. Comienza con 1,000-5,000 páginas de alta calidad, construye autoridad, luego escala.

¿Cuál es el contenido mínimo por página para evitar sanciones de contenido delgado? Apuntamos a al menos 400 palabras de contenido único por página, más datos estructurados, imágenes y enlaces internos. Pero el conteo de palabras solo no es la métrica -- se trata de si la página responde la consulta del usuario mejor que lo que ya existe. Una página de 200 palabras con tablas de datos únicas y un mapa puede superar una página de 2,000 palabras de texto genérico.

¿Es el SEO programático aún seguro después de las actualizaciones de contenido útil de Google en 2025? Sí, pero solo si genuinamente estás creando páginas útiles. Las actualizaciones de 2025 de Google se dirigen específicamente al contenido programático de baja calidad que existe solo para capturar tráfico de búsqueda sin proporcionar valor. Sitios como Zapier (70K páginas, $140M ARR) continúan prosperando porque sus páginas resuelven problemas reales. Los sitios siendo penalizados son los que generan variaciones de "Mejor {servicio} en {ciudad}" sin datos reales detrás.

¿Cuánto cuesta una pila de SEO programático con Supabase y Vercel? Nuestra pila de tres proyectos funciona alrededor de $150-200/mes total. Supabase Pro es $25/mes por proyecto (usamos tres instancias). Vercel Pro es $20/usuario/mes. El enriquecimiento de IA vía la API de Claude fue un costo único de aproximadamente $180 para 28,840 registros. Para la mayoría de proyectos bajo 50K páginas, espera $50-100/mes en costos de infraestructura.

¿Cuánto tiempo le toma a Google indexar páginas programáticas? Espera 2-4 semanas para rastreo inicial de tus sitemaps, pero la indexación completa de grandes conjuntos de páginas toma 3-6 meses. Nuestra experiencia muestra un patrón de efecto hockey: rastreo lento durante las primeras 6-8 semanas mientras Google evalúa calidad, luego aceleración rápida una vez que decide que tu contenido vale la pena indexar. Los enlaces internos y la estructura del sitemap afectan dramáticamente esta línea de tiempo.

¿Debería usar SSR o ISR de Next.js para páginas de SEO programático? ISR, casi siempre. SSR (force-dynamic) significa que cada solicitud de rastreador -- incluyendo cada rastreo de Googlebot -- golpea tu base de datos, lo cual crea problemas de rendimiento a escala y desperdicia presupuesto de rastreo en respuestas lentas. ISR con revalidate = 3600 (o incluso 86400 para actualizaciones diarias) te da rendimiento de sitio estático con actualización de datos dinámica. Aprendimos esto de la manera difícil con HostList -- cambiar de force-dynamic a ISR bajó nuestro tiempo de respuesta de 2.8s a 47ms.

¿Cómo manejas enlaces internos en 100K+ páginas? Consultas de contenido relacionado impulsadas por base de datos. Cada página ejecuta una consulta que encuentra 8-15 páginas relacionadas basadas en relaciones de datos reales -- misma categoría, puntuaciones similares, proximidad geográfica, atributos compartidos. No simplemente vincula aleatoriamente a páginas. Los enlaces necesitan tener sentido contextual para usuarios y Google. Usamos funciones PostgreSQL en Supabase para calcular estas relaciones eficientemente.

¿Cuál es el mayor error que comete la gente con SEO programático? Enfocarse en recuento de páginas en lugar de calidad de página. Es tentador generar cada combinación posible de tus datos, pero 10,000 páginas excelentes superarán 100,000 mediocres cada vez. Matamos 4,000 páginas delgadas en Deluxe Astrology y vimos la indexación aumentar en las páginas restantes. Google interpreta páginas delgadas como una señal de que tu sitio completo podría ser de baja calidad. Si estás listo para construir páginas programáticas de la manera correcta, comunícate con nuestro equipo -- hemos aprendido estas lecciones para que no tengas que hacerlo.