Generación de páginas por plantilla: la vía técnica del SEO programático

La semana pasada un amigo me habló de SEO programático. Tenía lista la matriz de palabras clave: más de dos mil long tails en Excel, pero se quedó bloqueado en el siguiente paso.

«Entiendo la lógica, pero en cuanto me pongo manos a la obra salen montones de dudas. ¿Next.js o Astro? ¿Qué base de datos? ¿Cómo diseñar las rutas URL? Y si genero cinco mil páginas de golpe, ¿aguanta el servidor?»

Yo me debatía con lo mismo hace dos años. Montaba un directorio de servicios legales y quería tres mil páginas por ciudad con SEO programático. Resultado: dos meses para sacar la primera versión, con trampas de las que aún me acuerdo.

Este artículo cierra esos huecos. Te doy tres vías técnicas completas: generación estática, renderizado dinámico y enfoque híbrido. Cada una con ideas de código, escenarios de uso y casos reales. Al terminar podrás ponerte manos a la obra — al menos sin empezar de cero como yo.

Primero: ¿qué camino te conviene?

La implementación técnica no es elegir un framework a ciegas. Hay que mirar antes las características de tus datos.

¿Te encaja la generación estática (SSG)?

Si tus datos se actualizan poco — una vez por semana o incluso al mes —, la generación estática es lo más estable.

Un ejemplo: ayudé a un amigo con un sitio de guías de viaje. Cada página de ciudad tenía contenido casi fijo: atracciones, transporte, gastronomía. Eso cambiaba cada seis meses. Usamos Content Collections de Astro, dos mil ciudades en JSON y generación estática en lote. El build tardaba unos diez minutos; en producción el TTFB (time to first byte) rondaba los 80 ms y la caché del CDN llegaba al 95 %.

Ventajas claras: carga rápida, SEO natural, poca presión en el servidor. Límites: cada actualización exige rebuild completo; con más de cinco mil páginas el build se alarga mucho.

¿Cuándo usar renderizado dinámico (SSR)?

Cuando los datos cambian en tiempo real, la generación estática no sirve.

Wise (la app de transferencias internacionales) es el caso típico. En sus páginas de conversión de divisas el tipo de cambio varía cada minuto. Con SSG el usuario vería un tipo de hace diez minutos — fatal para decidir una transferencia. Usan SSR de Next.js y consultan la API en cada petición.

El coste es presión en el servidor. Wise recibe más de un millón de consultas diarias; el gasto no es bajo. Además el TTFB sube, normalmente 200-500 ms.

El enfoque híbrido como término medio

Si tienes datos de baja y alta frecuencia, lo híbrido suele encajar mejor.

Las páginas de integraciones de Zapier funcionan así. Tienen más de cinco mil páginas del tipo «App A + App B», por ejemplo «integración de Slack y Gmail». La info base (funciones, pasos de configuración) es estática; el estado real del usuario (conectado o no, última sincronización) es dinámico.

Zapier usa ISR (Incremental Static Regeneration) de Next.js. La primera carga es estática y un mecanismo en segundo plano actualiza periódicamente. El usuario ve contenido rápido y actualizado.

Mi recomendación: responde estas tres preguntas antes de elegir la vía técnica.

1. ¿Con qué frecuencia se actualizan los datos? (¿Diario? ¿Cada hora? ¿Tiempo real?)
2. ¿Qué escala de páginas? (¿Menos de cinco mil? ¿De cinco a veinte mil? ¿Más de veinte mil?)
3. ¿Qué exigencia de rendimiento SEO? (¿TTFB <100 ms obligatorio? ¿300 ms vale?)

Con eso claro, la elección técnica se simplifica.

Generación estática: enfoque práctico con Astro

Si optas por estática, recomiendo Astro. Está pensado para sitios estáticos y Content Collections encaja muy bien con SEO programático.

Diseño de la estructura de datos

Primero define la estructura. Supón un directorio de abogados, una página por ciudad:

// src/content/config.ts
import { defineCollection, z } from 'astro:content';

const lawyersCollection = defineCollection({
  type: 'content',
  schema: z.object({
    city: z.string(),
    citySlug: z.string(),
    province: z.string(),
    lawyerCount: z.number(),
    topFirms: z.array(z.string()),
    avgPrice: z.string(),
    specialties: z.array(z.string()),
  }),
});

export const collections = {
  'lawyers': lawyersCollection,
};

Luego crea archivos en src/content/lawyers/, un JSON por ciudad:

// src/content/lawyers/beijing.json
{
  "city": "Pekín",
  "citySlug": "beijing",
  "province": "Municipio de Pekín",
  "lawyerCount": 12500,
  "topFirms": ["King & Wood Mallesons", "Zhong Lun Law Firm", "Dacheng Law Offices"],
  "avgPrice": "2000-5000 CNY/hora",
  "specialties": ["Penal", "Civil", "Mercantil", "Propiedad intelectual"]
}

Dos mil ciudades, dos mil JSON. Parece pesado, pero puedes generarlos con scripts. Yo suelo exportar de la base con Python o Node.js y escribir los JSON en lote.

Plantilla de ruta dinámica

Con los datos listos, la plantilla. El enrutado dinámico de Astro es muy flexible:

// src/pages/[citySlug].astro
---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const lawyers = await getCollection('lawyers');
  return lawyers.map(lawyer => ({
    params: { citySlug: lawyer.data.citySlug },
    props: { lawyer },
  }));
}

const { lawyer } = Astro.props;
---

<!DOCTYPE html>
<html>
<head>
  <title>Guía de servicios legales en {lawyer.data.city} | Despachos y tarifas</title>
  <meta name="description" content={`Guía completa de servicios legales en ${lawyer.data.city}, con ${lawyer.data.specialties.join(', ')} y más. Despachos recomendados: ${lawyer.data.topFirms.join(', ')}. Tarifas medias: ${lawyer.data.avgPrice}`} />
</head>
<body>
  <h1>Guía de servicios legales en {lawyer.data.city}</h1>

  <section>
    <h2>Datos clave</h2>
    <p>Número de abogados: {lawyer.data.lawyerCount}</p>
    <p>Áreas principales: {lawyer.data.specialties.join(', ')}</p>
    <p>Tarifa media: {lawyer.data.avgPrice}</p>
  </section>

  <section>
    <h2>Despachos recomendados</h2>
    <ul>
      {lawyer.data.topFirms.map(firm => <li>{firm}</li>)}
    </ul>
  </section>

  <!-- Enlaces internos: ciudades cercanas -->
  <section>
    <h2>Servicios legales en ciudades cercanas</h2>
    <!-- Aquí puedes recomendar por provincia o ubicación -->
  </section>
</body>
</html>

getStaticPaths genera automáticamente todas las páginas estáticas. Dos mil ciudades, dos mil HTML.

Build y despliegue

El comando de build de Astro es sencillo:

npm run build

Tras el build, dist/ contiene todos los HTML estáticos. Despliega en Cloudflare Pages o Vercel y la CDN cachea sola.

En el sitio de guías de viaje, dos mil páginas tardaban unos diez minutos. Astro construye rápido, más eficiente que la generación estática de Next.js en muchos casos.

Truco de optimización: con más de cinco mil páginas, conviene build por lotes. Astro permite build incremental: solo las páginas nuevas, sin reconstruir todo el sitio.

Renderizado dinámico: SSR con Next.js

Si los datos cambian en tiempo real, la estática no basta. Ahí entra SSR de Next.js.

Configuración básica

El núcleo de SSR en Next.js es getServerSideProps:

// pages/currency/[pair].tsx
import { GetServerSideProps } from 'next';

export const getServerSideProps: GetServerSideProps = async (context) => {
  const { pair } = context.params;
  const [from, to] = pair.split('-to-');

  // Obtener tipo de cambio en tiempo real
  const exchangeRate = await fetchExchangeRate(from, to);

  return {
    props: {
      from,
      to,
      rate: exchangeRate.rate,
      lastUpdate: exchangeRate.timestamp,
    },
  };
};

export default function CurrencyPage({ from, to, rate, lastUpdate }) {
  return (
    <div>
      <h1>Conversión de {from} a {to}</h1>
      <p>Tipo actual: {rate}</p>
      <p>Última actualización: {new Date(lastUpdate).toLocaleString()}</p>

      {/* Calculadora */}
      <input type="number" placeholder="Importe" />
      <button>Convertir</button>

      {/* Gráfico histórico */}
      <div>Tendencia de los últimos 30 días</div>
    </div>
  );
}

Cada visita a /currency/usd-to-eur dispara una consulta a la API de tipos. El contenido siempre está al día.

Estrategia de caché: no mates el servidor

El problema del dinámico es la carga. Si Wise consultara la API en cada petición entre un millón de visitas, el costo explotaría.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

La solución es caché, pero con criterio.

stale-while-revalidate funciona bien: devuelves datos cacheados (quizá de hace unos minutos) y actualizas en segundo plano. En la siguiente visita el usuario ve lo nuevo.

Next.js lo soporta:

export const getServerSideProps: GetServerSideProps = async (context) => {
  const { pair } = context.params;

  // Revisar caché
  const cached = await checkCache(pair);

  if (cached && !isExpired(cached)) {
    return { props: cached.data };
  }

  // Caché caducada: actualizar en background
  fetchExchangeRate(pair).then(data => updateCache(pair, data));

  // Devolver datos antiguos primero
  return { props: cached?.data || await fetchExchangeRate(pair) };
};

Así el usuario ve contenido rápido y el servidor no llama a la API externa en cada petición.

Inyección dinámica de datos estructurados

En páginas dinámicas, el JSON-LD también debe generarse al vuelo:

// Generar JSON-LD en el componente
const jsonLd = {
  "@context": "https://schema.org",
  "@type": "FinancialService",
  "name": `${from} to ${to} Currency Conversion`,
  "offers": {
    "@type": "Offer",
    "price": rate,
    "priceCurrency": to,
  },
};

// Inyectar en HTML
<script type="application/ld+json">
  {JSON.stringify(jsonLd)}
</script>

Cada página lleva datos estructurados precisos y Google puede mostrar el tipo de cambio actualizado.

Enfoque híbrido: ISR con Next.js

Si tu escenario es «parte estático, parte dinámico», ISR (Incremental Static Regeneration) es la mejor opción.

Lógica central del ISR

ISR funciona así: la página se genera estática al inicio, pero puedes fijar un tiempo de caducidad. Tras caducar, la siguiente visita dispara una regeneración en segundo plano.

// pages/integrations/[app1]-and-[app2].tsx
export async function getStaticPaths() {
  const integrations = await fetchAllIntegrations();
  return integrations.map(int => ({
    params: { app1: int.app1, app2: int.app2 },
  }));
}

export async function getStaticProps({ params }) {
  const integration = await fetchIntegration(params.app1, params.app2);

  return {
    props: integration,
    revalidate: 3600, // Caduca a la hora
  };
}

revalidate: 3600 significa: durante la primera hora todas las visitas reciben HTML estático. A la primera visita después de la hora, el usuario sigue viendo la versión antigua mientras se regenera en background. En la segunda visita, ya ve la nueva.

Actualización bajo demanda: on-demand revalidation

A veces no conviene esperar la caducidad natural. Si una integración de Zapier falla y quieres actualizar la página al instante, no esperes una hora.

Next.js permite revalidación bajo demanda:

// Ruta API: disparar actualización
// pages/api/revalidate.ts
export default async function handler(req, res) {
  const { app1, app2 } = req.query;

  try {
    await res.revalidate(`/integrations/${app1}-and-${app2}`);
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).send('Error revalidating');
  }
}

Puedes montar un script de monitorización que revise el estado de las integraciones y llame a esta API cuando detecte un problema.

Límites del ISR

ISR no lo resuelve todo. Si necesitas datos en tiempo real en cada visita (cotizaciones bursátiles, flash sales), sigue haciendo falta SSR.

ISR encaja cuando los datos cambian poco (cada hora, cada día) pero quieres que el cambio se refleje pronto. Las págin de integración de Zapier son el ejemplo perfecto: la info cambia cada pocos meses, pero cuando cambia el usuario quiere verlo ya.

Diseño de URL: la base del SEO

Con la stack elegida, toca la estructura de URL. Muchos la pasan por alto, pero influye directamente en el SEO.

Tres principios para URLs amigables

Primero, incluir la palabra clave objetivo. La URL es factor de ranking; keywords naturales en la ruta ayudan.

Para «abogado divorcio Pekín», la URL puede ser /beijing/divorce-lawyer. «Pekín» y «abogado divorcio» quedan en la ruta.

Segundo, no más de tres niveles de profundidad. Rutas muy profundas perjudican a usuarios y rastreadores.

Una ruta de seis niveles como /service/legal/lawyer/divorce/beijing confunde al usuario. Google puede interpretarla como página de baja calidad.

Tercero, guiones, no parámetros.

/lawyer?type=divorce&city=beijing rinde peor que /beijing/divorce-lawyer. Las URLs con parámetros también se confunden con páginas dinámicas y indexan peor.

Tres patrones habituales de URL

He visto tres modelos principales, cada uno con su escenario.

Patrón 1: término núcleo primero

/lawyer/beijing/divorce

Para sitios orientados a marca. «Lawyer» delante refuerza la categoría.

Patrón 2: geografía primero

/beijing/divorce-lawyer

Para servicios locales. Si buscan «abogado divorcio Pekín», la URL coincide con la query.

Patrón 3: plano

/beijing-divorce-lawyer

Para sitios con volumen enorme de páginas. Un solo nivel, fácil de construir y mantener.

Mi consejo: mira cómo buscan tus usuarios. Si predominan «ciudad + servicio», usa el patrón 2. Si las búsquedas son dispersas, el 3 es más flexible.

Automatización de enlaces internos

Con las URL fijadas, los enlaces internos. Una ventaja del SEO programático es tejer la red de enlaces sola.

Imagina un directorio legal con tres mil páginas de ciudad. Cada una debería enlazar ciudades relacionadas. ¿Cómo?

Por jerarquía geográfica: la página de Pekín enlaza «abogados Hebei», «abogados Tianjin» (ciudades cercanas).

Por tipo de servicio: la página de divorcio en Pekín enlaza «abogado penal Pekín», «abogado civil Pekín» (misma ciudad, otro servicio).

En código es directo:

---
// En la plantilla de página
const { lawyer } = Astro.props;
const nearbyCities = await getNearbyCities(lawyer.data.province);
const relatedSpecialties = lawyer.data.specialties;
---

<section>
  <h2>Abogados en ciudades cercanas</h2>
  {nearbyCities.map(city => (
    <a href={`/${city.slug}/${lawyer.data.specialties[0]}-lawyer`}>
      Abogado {lawyer.data.specialties[0]} en {city.name}
    </a>
  ))}
</section>

<section>
  <h2>Otros servicios legales en {lawyer.data.city}</h2>
  {relatedSpecialties.map(spec => (
    <a href={`/${lawyer.data.citySlug}/${spec}-lawyer`}>
      Abogado {spec} en {lawyer.data.city}
    </a>
  ))}
</section>

Cada página acumula decenas de enlaces internos y el sitio forma una malla. El rastreo es eficiente y el usuario encuentra contenido relacionado rápido.

Elección de base de datos: no te atasques aquí

Con la estructura definida, ¿dónde guardar? Mucha gente se enreda semanas; en realidad no es tan complejo.

Cuatro opciones, cada una con su escenario

PostgreSQL: datos estructurados y consultas complejas.

Si los campos son fijos y necesitas consultas del tipo «todos los abogados de divorcio en Pekín por debajo de 3000», PostgreSQL es lo más sólido. ACID, transacciones y búsqueda full-text.

MongoDB: esquema flexible e iteración rápida.

Si la estructura aún evoluciona, MongoDB da más margen. No hace falta definir el esquema de antemano; añades campos cuando quieras. En proyectos tempranos lo usaba mucho por eso.

Airtable/Google Sheets: escala pequeña y colaboración.

Con decenas o cientos de registros y varias personas editando, Airtable o Sheets van bien. Edición visual, tiempo real y perfiles no técnicos pueden mantenerlos. Un amigo tiene doscientos registros en Airtable con costo de mantenimiento bajo.

CSV/JSON: generación puramente estática.

Si los datos son totalmente estáticos y tienes menos de mil páginas, CSV o JSON bastan. Sin base de datos: se leen en el build. Content Collections de Astro sigue ese modelo.

Mi consejo: aclara primero la escala

Menos de mil registros: CSV/JSON o Airtable.
De mil a diez mil: PostgreSQL o MongoDB.
Más de diez mil: PostgreSQL + caché Redis.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

No te quedes bloqueado: elige algo que funcione. Si la estructura cambia, migrar no es el fin del mundo.

Clave del desarrollo de plantillas: diferenciación de contenido

Con la arquitectura montada, el reto real es la plantilla. Muchos proyectos de SEO programático fallan porque todas las páginas se parecen demasiado.

Trampa: plantillas que solo cambian la keyword

Vi un caso fallido: veinte mil páginas «ciudad + hotel» donde solo cambiaba el nombre de la ciudad. «Hoteles recomendados en Pekín», «en Shanghái», «en Cantón»… mismo texto.

Resultado: penalización algorítmica de Google. Tráfico −70 %; recuperarse llevó ocho meses.

Raíz del problema: ninguna página aportaba valor único. Quien busca hoteles en Pekín ve casi lo mismo que en Shanghái — contenido basura generado en masa.

Tres métodos de diferenciación

Método 1: inyección de datos dinámicos

Cada página necesita datos propios. En un directorio legal, el número de abogados, la lista de despachos y la tarifa media cambian por ciudad. Vienen de la base y diferencian solos.

Método 2: integración UGC

El contenido generado por usuarios es el mejor material de diferenciación. En TripAdvisor cada hotel tiene reseñas únicas, escritas por personas reales, no por plantilla.

Si tienes UGC, intégralo. En un directorio legal, un bloque de reseñas:

<section>
  <h2>Opiniones de usuarios</h2>
  {lawyer.data.reviews.map(review => (
    <div>
      <p>{review.content}</p>
      <span>Valoración: {review.rating}/5</span>
    </div>
  ))}
</section>

Método 3: ampliación asistida por IA

Sin datos dinámicos ni UGC, la IA puede ayudar a párrafos descriptivos. Pero: revisión humana obligatoria y solo para texto secundario, no para el núcleo.

Hice una prueba en un directorio legal: datos núcleo (conteo, despachos) de la base; el párrafo «particularidades del servicio legal en esta ciudad» lo ampliaba la IA. Por ejemplo: «En Pekín predominan disputas mercantiles y alta demanda de propiedad intelectual…»

Clave: la IA complementa, no sustituye. Cada página debe tener datos únicos reales; la IA es un extra, no la base.

Automatización de datos estructurados

Cada página necesita JSON-LD. Se puede automatizar por completo:

const jsonLd = {
  "@context": "https://schema.org",
  "@type": "LegalService",
  "name": `Servicios legales en ${lawyer.data.city}`,
  "areaServed": {
    "@type": "City",
    "name": lawyer.data.city,
  },
  "provider": lawyer.data.topFirms.map(firm => ({
    "@type": "Organization",
    "name": firm,
  })),
};

El schema sale de datos reales; en SERP pueden aparecer despachos y ciudad, con mejor CTR.

Optimización de rendimiento: no hagas esperar al usuario

Con miles de páginas, el rendimiento no es opcional.

Tres métricas clave

TTFB (time to first byte): velocidad de respuesta del servidor.

Generación estática suele ser <100 ms; dinámico 200-500 ms. Si superas 500 ms, el usuario puede cerrar antes de ver nada.

LCP (Largest Contentful Paint): cuándo aparece el contenido principal.

Objetivo <2,5 s. Muchas imágenes o componentes pesados alargan el LCP.

FID (First Input Delay): respuesta a la interacción.

Objetivo <100 ms. Demasiado JavaScript y los clics no responden.

CDN: acelerador de páginas estáticas

En estático, la caché CDN es clave. Cloudflare Pages y Vercel traen CDN; la configuración es sencilla.

// astro.config.mjs
export default defineConfig({
  output: 'static',
  build: {
    assets: 'assets/',
  },
  vite: {
    build: {
      rollupOptions: {
        output: {
          assetFileNames: 'assets/[hash][extname]',
        },
      },
    },
  },
});

Los estáticos quedan con hash único y la CDN cachea mejor.

Imágenes: que no frenen la página

Un hero JPG sin optimizar puede pesar varios MB y ralentizar todo.

Astro optimiza imágenes:

---
import { Image } from 'astro:assets';
import heroImage from '../images/lawyer-hero.jpg';
---

<Image src={heroImage} alt="Servicios legales" width={1200} height={675} />

Convierte a WebP y comprime. De 2 MB puedes bajar a 200 KB.

Presupuesto de rastreo: obligatorio con muchas páginas

Con más de cinco mil URLs, Google puede no rastrearlas todas. Eso es «desperdicio de presupuesto de rastreo».

Soluciones:

Primero, fragmentar sitemap.xml. No metas cinco mil URLs en un solo archivo:

// sitemap-index.xml
<sitemapindex>
  <sitemap><loc>https://example.com/sitemap-1.xml</loc></sitemap>
  <sitemap><loc>https://example.com/sitemap-2.xml</loc></sitemap>
  <sitemap><loc>https://example.com/sitemap-3.xml</loc></sitemap>
</sitemapindex>

Máximo unos 500 URLs por sitemap; el rastreo es más eficiente.

Segundo, prioridad de enlaces internos. Las páginas importantes (ciudades con más búsquedas) reciben más entradas: home, navegación. Las secundarias, menos enlaces; el crawler prioriza lo relevante.

Casos reales: cómo lo hacen otros

La teoría está; veamos casos. Sus arquitecturas dan muchas ideas.

TripAdvisor: arquitectura híbrida de referencia

Millones de páginas de hotel. ¿Cómo?

Arquitectura: híbrido estático + actualización dinámica.

Info base del hotel (nombre, dirección, servicios) estática. Reseñas y puntuación dinámicas. Dos fuentes: export de base + API de reseñas.

URL: /hotel/[city]/[hotel-name]

Por ejemplo /hotel/beijing/grand-hyatt. Tres niveles, SEO friendly.

Tecnologías clave:

• Reseñas UGC en tiempo casi real
• Comparación de precios vía API
• Schema Review automatizado

El éxito de TripAdvisor es el UGC: cientos de reseñas reales por hotel, diferenciación natural. Sin UGC, plantillas puras no rankean así.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Zapier: ISR clásico

Más de cinco mil páginas «App A + App B»: «Slack y Gmail», «Notion y Google Calendar»…

Arquitectura: ISR de Next.js.

Info base de la integración estática; estado del usuario (conectado, última sync) dinámico. ISR equilibra velocidad y exactitud.

URL: /integrations/[app1]/[app2]

Por ejemplo /integrations/slack/gmail. Dos niveles, limpio.

Tecnologías clave:

• on-demand revalidation ante fallos
• Tests automatizados (Playwright) por página
• Red de enlaces: hub de apps + integraciones relacionadas

El equipo de ingeniería de Zapier publicó cómo gestionan cinco mil páginas con ISR; merece la pena leerlo.

Wise: dinámico + caché

Tipos de cambio que varían cada minuto: SSG no sirve.

Arquitectura: SSR de Next.js + caché stale-while-revalidate.

En /currency/usd-to-eur se consulta la caché. Si no caducó (p. ej. 5 minutos), se devuelve; en paralelo se actualiza el tipo. La siguiente visita ve datos nuevos.

URL: /currency/[from]-to-[to]

Por ejemplo /currency/usd-to-eur. Keywords en la ruta.

Tecnologías clave:

• stale-while-revalidate
• CDN edge caching global
• JSON-LD con tipo en tiempo real

La estrategia de Wise equilibra actualidad y costo. Para datos en tiempo real, su enfoque es buena referencia.

Guía de trampas: errores que yo cometí

Tras los éxitos, las lecciones duras. Las pisé yo; ojalá las evites.

Trampa 1: URL caóticas

Mi primer directorio legal usaba /service?id=lawyer&city=beijing&type=divorce.

Flexible en apariencia, pero Google indexa mal las URLs con parámetros y el usuario no sabe qué hay dentro.

Lección: fija la estructura de URL antes de codear. Cambiarla en producción cuesta caro: enlaces internos, externos y sitemap.

Trampa 2: contenido duplicado en plantillas

Vi un sitio con veinte mil páginas que solo cambiaba la ciudad. Mismo cuerpo, «Pekín» por «Shanghái».

Penalización de Google. Tráfico −70 %.

Lección: cada página necesita datos únicos. Sin ellos, no generes la página. Mil páginas buenas valen más que diez mil basura.

Trampa 3: cuello de botella de rendimiento

Cinco mil páginas en SSR puro saturan el servidor. Yo generaba con PHP dinámico y el servidor caía a menudo.

Lección: más de cinco mil páginas, estática o ISR. SSR puro no aguanta.

Trampa 4: sin monitorización

Sin seguimiento, los problemas llegan tarde. Un proyecto mío: a los tres meses descubrí que la mitad no estaba indexada por un sitemap mal configurado.

Lección: la primera semana en producción, monitoriza. Google Search Console para indexación, Screaming Frog para técnica, Ahrefs para rankings.

Próximos pasos: no lo pienses demasiado, empieza

Puede que aún te sientas abrumado. Mi consejo: empieza con un experimento pequeño.

Paso 1: elige un escenario acotado

No arranques con cinco mil páginas. Cincuenta ciudades, por ejemplo.

Paso 2: define la stack

Datos de baja frecuencia: Astro. Tiempo real: SSR de Next.js.

Paso 3: diseña datos y URL

Medio día para campos y rutas. No lo saltes.

Paso 4: plantilla + prueba

Tres páginas de prueba; revisa la diferenciación a mano. Luego genera en lote.

Paso 5: lanzamiento en pequeño

Publica cincuenta páginas y observa una semana: indexación, rebote, tiempo en página. Si va bien, escala a quinientas.

Paso 6: iteración

Ajusta plantilla, enlaces y URL según datos. El SEO programático no es un proyecto único; es mejora continua.