SEO programático: cuándo escalar y cuándo es spam

El SEO programático no es generar miles de páginas con una plantilla. Es decidir, antes de escribir una sola línea de esa plantilla, si tu conjunto de datos tiene variación real entre filas — algo que le importe a quien busca, no solo un campo que cambia de valor. La pregunta que decide si el proyecto funciona o se convierte en spam a escala no es "¿cuántas páginas puedo generar?" sino "¿qué distingue realmente a la página A de la página B?".

Este artículo asume que ya conoces la mecánica básica — una plantilla, una fuente de datos, generación en lote — y se centra en lo que las guías en español suelen saltarse: el requisito previo de variación real, cómo validar la demanda antes de generar el lote completo, y por qué el plan de poda debe diseñarse el primer día y no cuando el tráfico ya se ha hundido. Si buscas cómo priorizar esta decisión dentro de una organización más grande, o cómo gestionar plantillas que ya están en producción, esa es otra conversación — aquí la pregunta es previa: si generar esas URLs tiene sentido en absoluto.

El requisito que casi nadie menciona: variación real, no una plantilla

Toda página programática nace de cruzar una plantilla con una fuente de datos. El error habitual no está en la plantilla — está en la fuente de datos. Si la única columna que cambia entre filas es el nombre de una ciudad o de una categoría, y el resto del texto es idéntico o generado con sinónimos automáticos, no tienes cientos de páginas distintas: tienes una página repetida cientos de veces con una etiqueta cambiada. Eso es exactamente lo que un motor de búsqueda —y un usuario que abre dos pestañas para comparar— detecta de inmediato.

La variación real tiene que ser algo que le importe a quien busca: precio, disponibilidad, cobertura, plazo de entrega, características técnicas, condiciones legales, stock. No una variable cosmética. Antes de generar la primera página en lote, haz este ejercicio con tu propia fuente de datos: elige dos filas al azar y pregúntate qué información distinta obtiene un usuario si visita una u otra. Si la respuesta es "el nombre del lugar y poco más", el dataset no está listo, sea cual sea la plantilla que hayas diseñado.

• Variación fuerte: precio por metro cuadrado y número de habitaciones en un portal inmobiliario — cambia con cada inmueble, no se puede fabricar.
• Variación fuerte: cobertura y prima según la aseguradora y la provincia en un comparador de seguros — datos reales de cada póliza.
• Variación débil: "fontanero en Madrid" y "fontanero en Barcelona" con el mismo texto y solo el nombre de la ciudad sustituido.
• Variación débil: una ficha de producto genérica repetida por talla o color cuando la descripción no cambia una sola frase.

La prueba del doorway: qué pasa si borras la variable

Hay una prueba rápida para saber si una página programática es legítima o es, en la práctica, una doorway page: elimina mentalmente la variable que cambia (la ciudad, la categoría, la fecha) y pregúntate si queda algo. Si al quitar esa variable no queda contenido diferenciado — ni un dato, ni una condición, ni una cifra propia de ese caso —, la página nunca tuvo motivo para existir por separado. Existía solo para capturar una variante de la búsqueda, no para responderla de forma distinta.

Google documenta las doorway pages como páginas creadas para posicionar por combinaciones de palabras clave similares sin aportar contenido diferenciado sustancial, cuando existen únicamente para canalizar tráfico hacia otra página. Esa definición no habla de volumen — no dice "más de mil páginas es demasiado" — habla de sustancia. Puedes tener veinte páginas programáticas y que todas sean doorway pages, o puedes tener cincuenta mil y que ninguna lo sea, si cada una resuelve una consulta con datos que solo ella tiene.

Validar la demanda con una muestra de veinte antes de generar veinte mil

El error de secuencia más caro en un proyecto de SEO programático es generar el lote completo antes de saber si el patrón funciona. Si el dataset tiene la variación real del punto anterior, el siguiente paso no es escalar: es publicar una muestra pequeña y observar qué hace el motor de búsqueda con ella antes de comprometer el resto del catálogo.

Una muestra útil no son las veinte mejores filas del dataset — las que tienen más volumen de búsqueda evidente o más datos disponibles. Eso sesga el experimento. Una muestra útil recorre el espectro: algunas combinaciones de alta demanda aparente, algunas intermedias, algunas marginales, para saber si el patrón se sostiene en todo el rango o solo en la parte más obvia. Publica esas veinte, deja pasar el tiempo suficiente para que el rastreo y la indexación hagan su trabajo, y mide tres cosas por separado: cuántas se indexaron, cuántas reciben alguna impresión, y si el contenido generado sigue teniendo sentido cuando lo lee una persona ajena al proyecto.

Solo si esa muestra se comporta razonablemente bien tiene sentido generar el resto. Si la mitad de las veinte páginas no se indexa en varias semanas, generar veinte mil no arregla el problema — lo multiplica. El patrón que falla a pequeña escala falla igual a gran escala; simplemente tarda más en notarse porque hay más páginas para diluir la señal.

Por qué el plan de poda se diseña el primer día

Un supuesto frecuente es que la indexación es automática: publicas, Google rastrea, Google indexa. En la práctica, la indexación es una decisión, no una garantía, y esa decisión tiene en cuenta señales del sitio en conjunto, no solo de la página individual. Cuando un dominio publica un volumen alto de páginas con una proporción baja de contenido genuinamente distinto por plantilla, es razonable esperar que una fracción de esas páginas nunca se indexe, y que esa fracción no indexada no sea aleatoria: tiende a concentrarse en las combinaciones más débiles del dataset — las de menos datos, las más parecidas entre sí.

Un indicador operativo, aunque no sea un número universal, ayuda a decidir cuándo un lote se ha excedido: si al revisar los registros de rastreo, o la cobertura de indexación disponible en las herramientas para webmasters, una fracción visible de las páginas generadas nunca ha sido visitada por el rastreador semanas después de publicarse, esa fracción no es ruido — es información sobre qué segmento del dataset no merecía una URL propia. Ignorar esa señal y seguir generando el resto del catálogo con el mismo patrón no cambia el resultado, solo lo repite a mayor escala.

La consecuencia práctica es que el plan de poda —qué páginas se retiran, se fusionan con canonical, o se marcan noindex— no puede ser un plan de emergencia que se diseña cuando el tráfico ya bajó. Tiene que existir antes de generar la primera página, con reglas objetivas y automatizables:

• No publicar filas del dataset sin datos suficientes para diferenciarse (por ejemplo, cero resultados, cero disponibilidad, campos vacíos).
• Definir un plazo de observación, semanas y no meses, tras el cual una página sin indexar ni señal de rastreo se retira o se fusiona con una página padre mediante canonical.
• Revisar periódicamente qué segmentos del dataset generan páginas que nunca reciben una visita y detener la generación de ese segmento, no solo la de las páginas ya publicadas.
• Tratar la poda como mantenimiento continuo del catálogo, igual que se mantiene un inventario, no como una limpieza puntual.

Control de calidad por plantilla, no por página

Nadie revisa veinte mil páginas una por una, así que el control de calidad tiene que vivir en la plantilla y en las reglas de generación, no en la revisión manual de cada URL. Esto significa construir comprobaciones automáticas que se ejecutan antes de publicar cada página, no después.

Esta disciplina es la diferencia entre un catálogo programático que se puede mantener durante años y uno que hay que reescribir por completo en cuanto alguien —dentro o fuera de la empresa— se para a leer diez páginas seguidas. Estas son las comprobaciones mínimas:

• Un umbral mínimo de contenido único generado por fila, no solo longitud total, sino cuánto texto no es boilerplate compartido con el resto del lote.
• Una comprobación de similitud entre páginas del mismo lote: si dos páginas generadas superan un porcentaje de coincidencia de texto muy alto, algo en el dataset o en la plantilla está fallando, y hay que corregirlo antes de publicar más, no después.
• Validación de que los campos obligatorios de la plantilla —precio, disponibilidad, cobertura, la variable que justifica la página— están realmente presentes y no vacíos o con un valor por defecto genérico.
• Un muestreo humano periódico —no de todas las páginas, pero sí de una selección aleatoria recurrente— para confirmar que lo que lee una persona real sigue teniendo sentido, porque las comprobaciones automáticas detectan duplicación pero no detectan si el texto suena natural.

Cómo se ve esto en mercados reales de habla hispana

Tres tipos de página son habituales en el mercado hispanohablante y ilustran bien la diferencia entre variación real y variación cosmética.

Un portal inmobiliario que genera una página por inmueble tiene, casi por definición, variación real: precio, superficie, número de habitaciones, planta, año de construcción y ubicación exacta cambian en cada fila porque son datos objetivos del inmueble. El riesgo ahí no es el doorway, es la calidad del texto descriptivo que rodea esos datos —si la descripción es puro relleno genérico repetido, el dato estructurado salva la página pero no la hace mejor.

Un comparador de seguros que genera una página por combinación de provincia y tipo de póliza es legítimo si cada página refleja condiciones, coberturas y precios reales de esa combinación —datos que efectivamente difieren de una aseguradora a otra y de una provincia a otra por regulación o riesgo—. Deja de serlo si el texto es el mismo párrafo genérico sobre por qué contratar un seguro repetido cincuenta veces con el nombre de la provincia cambiado y una tabla de precios que en realidad es una estimación genérica sin relación con datos reales de pólizas.

El caso más claro de trampa es el marketplace de servicios por ciudad: "fontanero en Madrid", "fontanero en Sevilla", "fontanero en Bilbao". Salvo que cada página incluya datos genuinamente distintos por ciudad —tarifas locales verificadas, cobertura real de profesionales disponibles en esa zona, tiempos de respuesta medidos—, el patrón completo es el ejemplo de manual de variación cosmética: el mismo servicio, el mismo texto, una etiqueta geográfica cambiada. Es exactamente el escenario que la prueba del doorway del punto anterior detecta de inmediato.

La pregunta que hay que responder antes de escribir la plantilla

Antes de generar la primera página en lote, conviene poder responder tres preguntas por escrito, no de memoria: qué dato concreto varía fila a fila y le importa a quien busca; cómo se va a validar la demanda con una muestra reducida antes de comprometer el resto del catálogo; y cuál es el umbral y el plazo que activan la poda de las páginas que no funcionan. Si alguna de las tres no tiene respuesta clara, generar la plantilla no es el siguiente paso — definir el dataset sí lo es. El volumen de páginas nunca fue el objetivo; era una consecuencia de tener datos reales que merecían una URL propia.