SEO programático en Next.js: la arquitectura de nuestras 25 páginas de glosario y lo que todavía no ha demostrado

Resumen ejecutivo

• Nuestro glosario son 25 páginas (/glosario/[termino]) generadas desde un solo fichero de datos y una plantilla, con JSON-LD, sitemap, llms-full.txt y un servidor MCP que leen la misma fuente.
• No es SEO programático «de volumen»: el contenido de cada término está escrito a mano. Lo programático es la estructura, no el texto.
• La arquitectura sí está probada: tests, 404 reales para slugs inventados, datos fuera del bundle del navegador.
• El posicionamiento no lo está: en la última semana medida, todo el dominio tuvo 148 impresiones y 2 clics. Los términos de glosario que sí aparecen para «qué es…» están entre las posiciones 60 y 100.

Una corrección antes de empezar

La idea original de este artículo se titulaba «cómo montamos 27 páginas de glosario que posicionan solas». Al preparar el texto comprobamos dos cosas: el glosario tiene 25 términos, no 27, y no posiciona solo, todavía. Escribir el artículo con el título original habría sido contar lo que nos habría gustado medir.

Así que este es el caso real, con las dos mitades: lo que está construido y verificable, y lo que aún es una apuesta. Si buscas la receta de una web que «crece sola», no está aquí. Si buscas una arquitectura que puedas copiar y una referencia honesta de resultados, sí.

Qué es SEO programático (y por qué 25 páginas ya lo son)

El SEO programático consiste en producir muchas páginas a partir de una plantilla y datos estructurados. La definición completa está en el glosario, que además avisa de su riesgo: hecho sin utilidad real por página, deriva en abuso de contenido a escala.

Hay una confusión habitual: pensar que programático significa miles de páginas y texto generado en masa. El patrón es otro. Es separar tres cosas:

1. Datos: lo que cambia de una página a otra.
2. Plantilla: lo que es igual en todas.
3. Reglas: lo que impide publicar una página mal formada.

Con 25 páginas ya se obtiene la ventaja que importa: añadir la página 26 es añadir un objeto a una lista, no diseñar una página nueva. Y la web entera (sitemap, datos estructurados, ficheros para IA) se actualiza sola.

La arquitectura, pieza a pieza

1. Una sola fuente de datos

Todo el glosario vive en lib/glossary.ts. El fichero empieza con import "server-only", así que no puede acabar en el JavaScript que descarga el navegador: si un componente de cliente lo importara por error, el build falla. Esto importa porque son miles de palabras de texto que el visitante no necesita descargar para ver una sola definición.

Cada término es un objeto tipado. Los campos importantes:

Campo	Para qué sirve
slug	La URL (/glosario/e-e-a-t)
shortDefinition	Una frase citable, formato «X es Y que…»
longDefinition, howItWorks, example	El cuerpo de la página
commonMistakes, faqs	Errores reales y preguntas con respuesta
relatedTerms	Enlaces internos a otros términos
sources	Fuentes externas verificables
datePublished, dateModified	Fechas que alimentan sitemap y JSON-LD

La cabecera del fichero fija las reglas editoriales en un comentario: la definición corta es una frase autoextraíble, sin humo ni marketing; los errores comunes son errores reales, «con nombre y apellidos»; los ejemplos, preferiblemente con números. Es una guía para quien escriba el siguiente término, sea una persona o un modelo.

2. Una plantilla y una función que lista las URLs

La ruta es app/(es)/glosario/[termino]/page.tsx. Lo esencial:

export const dynamicParams = false;

export async function generateStaticParams() {
  return getAllTermSlugs().map((termino) => ({ termino }));
}

generateStaticParams le dice a Next.js qué URLs existen y el framework las genera como HTML estático en el build. Las páginas se sirven desde la caché de Vercel, sin trabajo de servidor por visita.

3. dynamicParams = false: el detalle que casi nadie pone

Por defecto, dynamicParams es true: cualquier slug fuera de la lista se renderiza bajo demanda. El problema que encontramos en la auditoría GEO de septiembre de 2026 es que una URL inventada (/glosario/lo-que-sea) devolvía HTTP 200: la página «no encontrada» se materializaba como página ISR, Vercel la cacheaba y la servía con 200.

Google respeta el noindex que Next.js inyecta, pero los rastreadores de IA no lo aplican con esa fiabilidad. Una URL alucinada por un modelo se validaba a sí misma como existente. Con dynamicParams = false, lo que no está en la lista devuelve 404. Es seguro porque la lista es exhaustiva: el contenido vive en el repositorio y publicar exige desplegar.

Si montas SEO programático en Next.js, comprueba esto en tu propio sitio: pide una URL que no exista y mira el código de estado.

4. Metadatos y datos estructurados desde los mismos datos

De cada término salen, sin escribir nada más:

• Metadatos (title, description, canonical, Open Graph) a través de una función común, buildMetadata.
• Cuatro bloques de JSON-LD: DefinedTerm, un Article del glosario, FAQPage y BreadcrumbList. Para el detalle de por qué importa el marcado, lo contamos en Schema JSON-LD para que la IA te cite.
• Una imagen Open Graph propia por término, con opengraph-image.tsx en el mismo segmento.

Como todo sale del mismo objeto, no hay forma de que la definición que ve una persona y la que lee un buscador se desincronicen.

5. Los mismos datos, para máquinas que no son buscadores

La misma lista alimenta:

• El sitemap (app/sitemap.ts), con prioridad 0,75 para los términos y la fecha de modificación de cada uno.
• El fichero llms-full.txt: una sección «Glosario completo» que recorre GLOSSARY_TERMS y publica definición, cómo funciona, ejemplo y errores comunes. Sobre ese fichero hablamos en qué necesita realmente una web: MCP, llms.txt o WebMCP.
• El servidor MCP público, cuyo buscador de glosario (lookupGlossary) consulta esa lista.

Esto es lo que más nos importa del enfoque: una edición, varias superficies.

Los tests que impiden publicar una página rota

SEO programático sin validación es una fábrica de páginas defectuosas con una sola causa. Los tests de tests/constants.test.ts y tests/blog.test.ts hacen cumplir:

• Sin slugs duplicados en el glosario.
• Todo término relacionado existe: un relatedTerms apuntando a un slug inexistente rompería la red de enlaces internos.
• La definición corta no pasa de 450 caracteres: por encima de eso deja de ser una frase extraíble. El corpus actual va de 250 a unos 410.
• Fechas válidas en todos los términos.
• Todo artículo del blog declara al menos un término del glosario, y los que declara existen. Este mismo artículo lo cumple: lleva cinco en su cabecera.

Es el control de calidad más barato que existe. Cuando un test falla, se arregla antes de que el error llegue a producción.

Lo que no es programático: el contenido

Aquí está la parte que separa esto del spam. Cada término se escribió a mano, con definición, mecanismo, ejemplo y errores concretos. La plantilla no «rellena» texto: da forma al que ya existe.

Dos razones de peso:

• Google vigila el contenido generado a escala sin valor. Una plantilla con una palabra cambiada es exactamente lo que penaliza.
• Un glosario cuyo atractivo es que una definición sea citable no sobrevive a un texto genérico.

La regla práctica que seguimos: si el dato que cambia entre páginas es solo el nombre, no merece una página. Si cada página aporta definición, ejemplo y errores propios, sí.

Hay otro uso del mismo patrón en la web: las seis landings sectoriales (/para/abogados, /para/clinicas, /para/saas, /para/inmobiliarias, /para/consultoras, /para/fintech) salen de lib/sectors.ts con la misma lógica de datos, plantilla y dynamicParams = false.

Qué resultados llevamos (los reales)

Esta es la parte incómoda. Con datos de nuestro informe semanal de Search Console, la semana del 18 al 24 de septiembre de 2026, para todo el dominio autoridaddigital.com:

Métrica	Valor
Clics	2
Impresiones	148
CTR	1,35 %
Posición media	50,4

Los clics vinieron de búsquedas de marca («autoridad digital», «federico noya»). En las consultas de tipo definición que corresponden al glosario, aparecemos, pero lejos de la primera página: «qué es AEO» ronda las posiciones 61 a 67, «llms.txt qué es» la 68 y «qué es el GEO» entre la 78 y la 100. Algunas de esas impresiones pueden venir de artículos del blog y no del glosario: el informe por consulta no atribuye URL, así que no podemos separar cuánto aporta el glosario.

Lo que podemos decir con honestidad:

1. El dominio es joven y con poca autoridad externa. Las páginas bien construidas no compensan eso por sí solas.
2. Veinticinco páginas de definición compiten con los glosarios de las herramientas grandes. Cubrir «qué es X» es el terreno más disputado.
3. El valor de las páginas puede estar en otra parte: ser citables por modelos de lenguaje. Eso también es una hipótesis que aún no medimos con un método propio, y no vamos a vender como resultado lo que no hemos medido.

Cómo medir si un glosario programático funciona

Si montas algo parecido, mide estas cuatro cosas, con fecha, y no te quedes en el tráfico:

• Indexación: cuántas de tus URLs están indexadas en Search Console frente a las del sitemap. Si no entran, el problema es anterior al ranking.
• Consultas por patrón: filtra las consultas que contienen «qué es» y mira posición e impresiones, no solo clics.
• Páginas que reciben impresiones: cuántos de tus términos ven alguna consulta. Veinticinco páginas con tres impresiones son un índice, no una mina.
• Respuestas de IA: pregunta cada mes a un asistente por varios de tus términos y guarda si te cita, con la fecha. Sin la fecha, la foto no sirve.

Qué haríamos distinto

• Fuentes externas desde el principio. Nuestra auditoría de septiembre detectó que 12 de los 25 términos no tenían sources. Hoy 23 de 25 las tienen, pero llegaron después de publicar. Un glosario con definiciones sin referencia es menos citable.
• Medir desde el día uno. Montamos la arquitectura antes que el seguimiento; hoy nos falta una línea base por URL.
• No pagar el coste de una base de datos antes de necesitarla. Un fichero tipado y tests bastan hasta que escribirlos deje de ser cómodo.

Resumen para copiar

Si quieres replicar el patrón en tu Next.js:

1. Pon los datos en un fichero tipado con import "server-only".
2. Crea una ruta dinámica con generateStaticParams y dynamicParams = false.
3. Genera metadatos y JSON-LD desde el mismo objeto.
4. Alimenta sitemap, llms-full.txt y lo que haga falta desde la misma lista.
5. Escribe tests que impidan publicar términos rotos o referencias inexistentes.
6. Escribe cada página como si fuera la única. La plantilla ahorra trabajo de ingeniería, no de contenido.
7. Mide antes de contar resultados.

Si quieres ver cómo ve una IA tu propia web, el Escáner GEO hace una primera lectura técnica gratuita.