SEO Programático: 4.700+ Páginas desde un ERP

En el sector de reparación de dispositivos en España, nadie estaba haciendo SEO programático. Cada combinación de dispositivo, marca, modelo, tipo de reparación y ciudad era una oportunidad long-tail sin explotar.

La idea era simple: si alguien busca "reparar iPhone batería Sevilla", debería existir una página específica para esa búsqueda, con el precio real, el tiempo estimado y fotos de reparaciones reales. Pero crear esas páginas a mano para miles de combinaciones no era viable. Necesitaba un sistema que generase las páginas automáticamente desde el ERP, y que fuera lo suficientemente inteligente para decidir cuáles indexar y cuáles no.

Santifer iRepair fue mi negocio de reparación de dispositivos en Sevilla desde 2009. 16 años, más de 30.000 reparaciones. En 2024 decidí que la web del negocio necesitaba dejar de ser un folleto en Squarespace y empezar a capturar la demanda que ya existía en Google. Construí este sistema de SEO programático como ventaja competitiva y vendí el negocio en septiembre 2025, en su punto más alto.

La Oportunidad#

El mercado de reparación de dispositivos en España es altamente local. Los usuarios buscan servicios por ciudad, marca y tipo de reparación. Pero la mayoría de negocios del sector tenían webs genéricas: una landing para toda España, si es que tenían web.

Queries reales de GSC

Los Números#

Dos Estrategias, Un Sistema#

El proyecto empezó con ambición nacional, pero Google tiene criterio propio. Las búsquedas de reparación tienen intención local muy fuerte. Google prioriza resultados con proximidad geográfica, así que las páginas nacionales sin ciudad competían peor. La solución: una estrategia dual. Páginas locales para Sevilla (donde está la tienda física) y páginas nacionales de nicho para reparaciones específicas donde la localización importa menos.

La Arquitectura#

El sistema tiene cuatro capas. Airtable funciona como CMS headless con 14 tablas y ~60 campos por tabla. El ERP alimenta los datos reales de producción. DataForSEO decide qué se indexa. Astro genera HTML estático con mínimo JavaScript en el cliente — solo lo imprescindible para UX (buscador, carrusel), cargado de forma lazy.

Taxonomía de URLs#

La web usa 6 patrones de URL, cada uno correspondiente a un nivel de la taxonomía del negocio. Los patrones locales (con /sevilla) capturan intención local. Los patrones nacionales (sin ciudad) capturan búsquedas de nicho.

Rutas Premium para Apple

El negocio empezó en 2009 reparando exclusivamente dispositivos Apple — la gente nos conocía por ello. Apple tiene el mayor volumen de búsqueda y las rutas más cortas reflejan esa prioridad: /iphone/14-pro en vez de /reparar-movil/apple/iphone-14-pro. Más corto, más limpio, mejor CTR. Un solo booleano cambia todo:

// Apple: /iphone/14-pro (corto, limpio, mejor CTR)
const records = await getRecordsModelos(true);  // modoApple = true → vista CMSAstro(Apple)
return records.map(r => ({
  params: { paramMarcaApple: r.paramMarca, paramModeloApple: r.paramModelo },
}));

// Genérico: /reparar-movil/samsung/galaxy-s21
const records = await getRecordsModelos();  // modoApple = false → vista CMSAstro
return records.map(r => ({
  params: { paramTipo: r.paramTipo, paramMarca: r.paramMarca, paramModelo: r.paramModelo },
}));

El CMS por Dentro#

Airtable no es solo una hoja de cálculo con esteroides. En este proyecto funciona como un CMS relacional completo. La clave es la jerarquía de 6 niveles que refleja exactamente cómo funciona el negocio.

Patrones clave del CMS

Anatomía de una Página#

Cada una de las 4.700+ páginas se genera desde un template, pero el contenido es único porque viene del ERP. No es texto generado por IA ni contenido de relleno: son datos de producción.

Flujo de Conversión por Página

Cada página sigue una estructura de conversión diseñada para llevar al usuario del descubrimiento a la acción:

Un usuario busca "reparar pantalla iPhone 14 Pro Sevilla". Llega a una página con precio (189€ original / 89€ compatible), tiempo estimado (45 min), 3 fotos de reparaciones reales de iPhone 14 Pro, y 12 reseñas verificadas. No necesita navegar a otra página — toda la información para decidir está ahí.

Copy Dinámico por Modelo

Cada modelo de dispositivo tiene un microcopy único generado a partir de sus specs de hardware reales. Un campo en Airtable almacena las características técnicas (cámara, batería, procesador, resistencia al agua) y un prompt genera una descripción que varía según el modelo. Un iPhone 14 Pro habla de su cámara de 48MP y su pantalla ProMotion. Un Pixel 7a destaca su chip Tensor y fotografía computacional. No es contenido genérico: es contenido que solo aplica a ESE modelo, basado en datos reales de hardware. Misma plantilla, contenido único en cada página.

Precios Sincronizados desde el ERP

El mismo CMS que genera el copy también sincroniza los precios de cada reparación en tiempo real. Airtable funciona como puente entre el ERP (donde se actualizan los costes de piezas y márgenes) y la web. Cada modelo muestra un rango de precios calculado desde el mínimo y máximo de sus reparaciones disponibles. Cuando un precio cambia en el ERP, la web se regenera con el precio actualizado — sin intervención manual.

let cadenaPrecio = '';
if (mostrarPrecio.startsWith('desde') && detail.precioMinCard) {
  cadenaPrecio = `Desde ${detail.precioMinCard}`;
}
if (mostrarPrecio === 'desdeHasta' && detail.precioMaxCard) {
  cadenaPrecio = `${cadenaPrecio} hasta ${detail.precioMaxCard}`;
}
if (mostrarPrecio === 'exacto' && detail.precioMinCard) {
  cadenaPrecio = detail.precioMaxCard
    ? `Desde ${detail.precioMinCard} hasta ${detail.precioMaxCard}`
    : `${detail.precioMinCard}`;
}

Buscador Contextual

El buscador no es un simple filtro de texto. Es un componente con un algoritmo de scoring propio — sin librerías externas como Fuse.js. El usuario escribe "iphone 12 pro" y el sistema puntúa los 867 modelos: +20 si contiene todas las palabras, +30 si es coincidencia exacta, +10 si el nombre empieza por la búsqueda, y penaliza palabras extra en el nombre del modelo. El resultado: los 6 modelos más relevantes, ordenados por puntuación.

Lo interesante es que el buscador es sensible al contexto. En la homepage busca en los 867 modelos de todas las marcas y tipos de dispositivo. Pero en la página de una marca específica (ej: Samsung), solo busca entre modelos de esa marca. Y en la página de un tipo de dispositivo (ej: tablets), solo tablets. El mismo componente, con props de filtro (`filtroTipo`, `filtroMarca`), se comporta de forma diferente según dónde se embeba. Los modelos se cargan bajo demanda en el primer foco del input y se cachean en localStorage para que las búsquedas siguientes sean instantáneas.

El artículo describe el algoritmo. Este es el código real — 30 líneas sin dependencias externas:

function calcularPuntuacion(modelo, terminosBusqueda) {
  let puntuacion = 0;
  const nombreModelo = modelo.n.toLowerCase();

  const todasPresentes = terminosBusqueda.every(t => nombreModelo.includes(t));

  if (todasPresentes) {
    puntuacion += 20;
    const palabrasModelo = nombreModelo.split(/\s+/);
    const extras = palabrasModelo.filter(p => !terminosBusqueda.includes(p)).length;
    puntuacion -= extras * 2;

    if (nombreModelo === terminosBusqueda.join(' ')) puntuacion += 30;
    if (nombreModelo.startsWith(terminosBusqueda.join(' '))) puntuacion += 10;
  }
  return puntuacion;
}

El Motor de Decisiones#

El sistema genera miles de páginas (muchas más de las 4.730 que recibieron tráfico), pero no todas merecen ser indexadas. Si nadie busca "reparar cámara delantera iPhone 11", esa página no debería competir en Google — pero sí debe existir para el usuario que navega desde la página del iPhone 11 y necesita esa reparación concreta. La clave es separar SEO de UX. El motor de decisiones consulta DataForSEO para obtener volumen de búsqueda real de cada combinación, y el resultado se almacena en el campo "indexable" de airtable.ts.

Optimización del Crawl Budget#

Con 4.700+ páginas, gestionar el crawl budget es crítico. Google no debería perder tiempo rastreando páginas que no van a posicionar. Las 700+ reglas de robots.txt se suman a las 1.009 redirecciones heredadas de la migración.

Patrón "Noindex Seguro"

El noindex accidental es uno de los errores más caros en SEO: una sola línea puede desindexar miles de páginas. Este es el patrón de seguridad que lo previene:

{NOINDEXCUIDADO &&
  NOINDEXCUIDADO === 'Estoy absolutamente seguro que no quiero hacer no index por eso pongo esta cadena' && (
    <meta name="robots" content="noindex" />
  )}

Pipeline de Build#

El pipeline transforma los datos del CMS en una web estática lista para desplegar. Todo está automatizado. schema.ts tiene 1.677 líneas que mapean la jerarquía de Airtable a tipos de Astro.

Retry con Backoff Exponencial

El pipeline comienza con la extracción de datos de Airtable. Con 14 tablas y miles de registros, las llamadas a la API necesitan ser resilientes. Esta función genérica de retry sostiene todo el build:

function delay(ms: number): Promise<void> {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function retryWithBackoff<T>(
  operation: () => Promise<T>,
  retries: number = 5,
  delayTime: number = 500
): Promise<T> {
  try {
    return await operation();
  } catch (error: any) {
    if (retries > 0 && (error.statusCode === 502 || error.statusCode === 503)) {
      await delay(delayTime);
      return retryWithBackoff(operation, retries - 1, delayTime * 2);
    }
    throw error;
  }
}

Sistema de Cache de Reseñas

Las reseñas son las llamadas más caras del build: 4.700+ páginas podrían necesitarlas, pero solo hay 607 en total. La solución: cargar todas una vez al inicio del build y que cada página consulte desde memoria.

let caches: { [key: string]: Reseña[] | undefined } = {};

async function loadReseñas(baseName: string, cacheKey: string): Promise<void> {
  if (caches[cacheKey]) return;

  const fetchOperation = () => new Promise<Reseña[]>((resolve, reject) => {
    const allRecords: Reseña[] = [];
    base(baseName)
      .select({ view: 'CMSAstro', fields: ReseñaFields })
      .eachPage(
        (records, fetchNextPage) => {
          records.forEach(record => allRecords.push(mapReseñaFields(record.fields)));
          fetchNextPage();
        },
        (err) => err ? reject(err) : resolve(allRecords)
      );
  });

  caches[cacheKey] = await retryWithBackoff(fetchOperation);
}

export async function ensureCachesLoaded(): Promise<void> {
  await Promise.all([
    loadReseñas('Reseñas sincronizar Astro', 'cachedReseñas'),
    loadReseñas('Reseñas Internas', 'cachedReseñasInternas')
  ]);
}

// Se ejecuta al importar el módulo
ensureCachesLoaded().catch(console.error);

Pipeline de Contenido Automatizado#

Generar miles de páginas es solo la mitad. Cada página necesita imágenes, metadata y copy únicos. Un conjunto de 8 scripts Node.js (1.411 líneas) automatiza toda la producción de contenido visual y textual sin intervención manual. Todo conectado a las 12 bases del Business OS en Airtable. Resultado: más de 26.000 imágenes generadas automáticamente.

Cada imagen recibe las coordenadas GPS de la tienda inyectadas en los metadatos EXIF. Google Images usa estos datos para posicionar imágenes en búsquedas locales:

// Coordenadas de la tienda en Sevilla
gps[piexif.GPSIFD.GPSLatitude] = convertToDMS(37.38606);
gps[piexif.GPSIFD.GPSLatitudeRef] = 'N';
gps[piexif.GPSIFD.GPSLongitude] = convertToDMS(-5.98585);
gps[piexif.GPSIFD.GPSLongitudeRef] = 'W';

// Descripción SEO en ambos campos EXIF
exifObj['0th'][piexif.ImageIFD.ImageDescription] = description;

// UCS-2 para soporte Unicode (tildes, ñ)
const userComment = Buffer.concat([
  Buffer.from('UNICODE\0\0\0', 'ascii'),
  encodeUCS2(description),
]);
exifObj['Exif'][piexif.ExifIFD.UserComment] = userComment.toString('binary');

Cascada de Contenido: Una Reseña, Seis Páginas

El sistema hereda contenido automáticamente a través de la taxonomía. Una reseña de "reparación de pantalla de iPhone 12" no solo aparece en esa página — aparece en todas las páginas donde es relevante:

La misma lógica aplica a las fotos antes/después: una foto de reparación de pantalla de iPhone 12 aparece en todas las páginas de esa rama de la taxonomía. Esto multiplica el contenido único sin duplicar ni generar nada artificialmente. Cada página acumula más social proof y contenido visual a medida que el negocio crece.

Explora los scripts del pipeline en GitHub →

Dentro del Pipeline de Imágenes#

La sección anterior describe el pipeline a alto nivel. Aquí se ve exactamente cómo funciona: las plantillas reales, el código de composición, y el resultado de aplicarlo a 867 modelos distintos.

Las Plantillas de Overlay

Cada tipo de reparación tiene un overlay PNG de 384×256 píxeles. El overlay muestra visualmente qué pieza se repara: una pantalla rota, una batería, una cámara... Son 17 plantillas en total, cada una diseñada para superponerse sobre la foto de cualquier dispositivo.

El Proceso de Composición

Cada imagen de reparación se genera en 6 pasos, completamente automatizado con un script Node.js y Sharp.js:

El Código Real

Este es el fragmento real del script generarImagenesReparacionesModelos.mjs que genera cada imagen de reparación:

await sharp({
  create: {
    width: 384, height: 256,
    channels: 4,
    background: { r: 255, g: 255, b: 255, alpha: 1 }
  }
})
  .png()
  .composite([
    { input: overlayPath },
    { input: devicePhoto,
      top: Math.round(top),
      left: Math.round(left) }
  ])
  .webp()
  .toFile(outputPath)

1 Foto → 18 Variantes

A partir de una sola foto del iPhone 14 Pro, el pipeline genera automáticamente 18 imágenes únicas: una imagen hero genérica y 17 variantes de reparación. Cada variante combina la foto del dispositivo con un overlay específico.

9 de las 17 variantes generadas automáticamente para el iPhone 14 Pro. Cada imagen combina la foto real del dispositivo con un overlay de reparación específico.

Mismo Pipeline, Diferente Dispositivo

El mismo proceso se aplica a cualquier dispositivo. La foto cambia, los overlays son los mismos. Esto es lo que permite escalar a 867 modelos sin trabajo manual.

La Escala

Pipeline de Reseñas#

Las reseñas son el social proof más potente de cada página. Pero gestionar cientos de perfiles de clientes, sincronizar dos fuentes y cascadear la prueba social por toda la taxonomía requiere su propio pipeline.

Fuente y Sincronización

Las reseñas llegan de dos fuentes: Google My Business (verificadas públicamente) y encuestas internas post-reparación. Ambas se sincronizan a Airtable y se normalizan en un formato único.

Procesamiento de Fotos de Perfil

Cada reseña con foto de perfil pasa por un pipeline de procesamiento automatizado:

El Código Real

Este es el fragmento real de `generarImagenesReseñas.mjs` que procesa cada foto de perfil:

const imageBuffer = await fetch(attachmentUrl)
  .then(r => r.arrayBuffer())

await sharp(Buffer.from(imageBuffer))
  .webp({ quality: 95 })
  .toFile(outputPath)

// Write processed URL back to Airtable
await base('Reseñas sincronizar Astro')
  .update(record.id, {
    'imagen_procesada': outputUrl
  })

Cascada de Social Proof

Las reseñas no solo aparecen en una página — se heredan por toda la taxonomía. Una reseña vinculada a un modelo se propaga a todas las páginas donde ese modelo es relevante.

Cientos de Perfiles Procesados

Perfiles reales de clientes procesados por el pipeline. Cada foto fue descargada, convertida a WebP y vinculada de vuelta a Airtable.

Perfiles reales de clientes. Cada foto se descarga, convierte a WebP y vincula de vuelta a Airtable.

Renderizado: Carrusel CRO

En producción, las reseñas se renderizan en un carrusel con auto-rotación de 9 segundos, barra de progreso visual y navegación por puntos. Las top 20 reseñas son visibles directamente; el resto se expanden bajo un botón "Ver más". Todo renderizado en servidor — cero JavaScript para el carrusel base.

1 / 5

La Escala

Pipeline Antes/Después#

Cada reparación completada genera evidencia fotográfica: 4 fotos que documentan el estado del dispositivo antes y después. Este pipeline procesa esas fotos automáticamente y las distribuye por la web.

Protocolo de Captura

Cada reparación completada en el taller sigue un protocolo de 4 fotos:

Procesamiento Automatizado

Cada foto pasa por 6 pasos de procesamiento con Sharp.js:

El Código Real

Este es el fragmento real de CasosExito.mjs que procesa cada foto de reparación:

let pipeline = sharp(inputBuffer)
  .resize({
    width: Math.round(metadata.width / 4),
    height: Math.round(metadata.height / 4)
  })

if (record.fields.difuminar) {
  pipeline = pipeline.blur(8)
}

await pipeline
  .composite([{
    input: whiteOverlay,
    blend: 'over'
  }])
  .webp({ quality: 85 })
  .toFile(outputPath)

Resultado Real: iPhone 14 Pro

Estas son fotos reales procesadas por el pipeline. Frontal y trasera, antes y después de la reparación.

Mismo Pipeline, Diferentes Marcas

El pipeline funciona igual para cualquier marca y modelo. Aquí se ve aplicado a un Samsung Galaxy A51 y un Xiaomi Redmi Note 9S.

Mismo pipeline de procesamiento para cualquier marca. Las fotos se descargan, redimensionan, difuminan si es necesario y exportan a WebP automáticamente.

La Escala

Curva de Crecimiento#

El proyecto se lanzó en octubre 2024. Los primeros meses fueron de indexación progresiva. Tras un pico inicial en enero, el tráfico se estancó entre febrero y junio — y no fue estacionalidad. Fue una reestructuración: la versión inicial generaba páginas nacionales y locales para cada combinación, pero eran demasiadas y Google priorizaba claramente la intención local. Redirigí las páginas nacionales a sus equivalentes locales con /sevilla, manteniendo solo las reparaciones de nicho en formato nacional (como /cambiar-bateria-iphone-11) donde la especificidad compensa la falta de localización. Mientras Google reindexaba la nueva estructura, el tráfico se mantuvo plano. Una vez consolidado, el crecimiento se disparó hasta el pico de septiembre 2025.

Hitos de Google Search Console

Google celebra los hitos de tráfico con badges. En 3 meses pasamos de 1.2K a 2K clicks mensuales — el último badge llegó junto a la venta del negocio.

Resultados#

Métricas acumuladas desde el lanzamiento (octubre 2024 a febrero 2026), directamente de Google Search Console:

Pero estos resultados no surgieron de la nada. El punto de partida fue una web en Squarespace con problemas técnicos que había que resolver antes de construir el sistema programático.

El Punto de Partida#

La web del negocio llevaba años en Squarespace. Sin control de URLs, sin canonical tags, sin redirects custom. Lo que venía no era solo un cambio de plataforma — era una triple migración: plataforma (Squarespace → Astro), dominio (santifer.me → santiferirepair.es) y hosting (Squarespace → Vercel/Cloudflare). El primer paso fue documentar exactamente qué había que arreglar: una auditoría técnica completa de 144 páginas, realizada como Trabajo Fin de Máster del programa Big SEO.

La Auditoría Técnica

El primer paso fue una auditoría técnica completa, realizada como Trabajo Fin de Máster del programa Big SEO. 144 páginas documentando cada aspecto técnico de la web: desde la situación del tráfico hasta la última meta description.

Los Problemas Técnicos

La Migración

El Servidor de Redirecciones

La triple migración (plataforma, dominio, hosting) requería un plan para no perder la autoridad acumulada en el dominio antiguo. La solución fue un proyecto dedicado en Vercel cuya única función era servir redirecciones 301. Un gotcha del cambio de dominio: Squarespace no permitía redirigir la homepage, lo que bloqueaba el GSC change of address. El doble salto HTTP→308→301 impedía la validación. Se resolvió en una tarde con Vercel Redirect Domain + Cloudflare Redirect Rules para un único 301 directo.

El Coste de Migrar

Toda migración tiene un coste de transición. 800+ páginas tardaron en reindexarse y keywords clave cayeron temporalmente — "reparar iphone sevilla" pasó del top 2 al puesto 6. Era esperable: Google necesita tiempo para reevaluar un dominio tras un cambio de dirección. La recuperación llegó.

De un Lighthouse de 21 en Squarespace a 100 en Astro. De DA 8 a competir en un mercado donde los líderes tienen 100x más tráfico. La auditoría técnica documentó 33 problemas; la migración los resolvió todos de una vez.

Stack y Herramientas#

El stack se eligió para una necesidad concreta: generar miles de páginas estáticas con datos de un CMS relacional, con el mínimo JavaScript posible en el cliente. Astro era la opción obvia para SSG puro. Airtable funcionaba como CMS porque ya era el Business OS del negocio — no tenía sentido migrar a Supabase para una web estática. DataForSEO se eligió por precio y cobertura de keywords en español.

Astro

SSG, 21 templates, JS mínimo lazy

Airtable

CMS headless, 14 tablas, ~60 campos/tabla

DataForSEO

Volúmenes de búsqueda, campo "indexable"

ERP propio

867 modelos, precios, stock, fotos, reseñas

Cloudflare

CDN, edge caching, deploy

TypeScript

schema.ts de 1.677 líneas para el mapping

JSON-LD

6 tipos de structured data por página

Lecciones Aprendidas#

Lo Que Esto Demuestra

Preguntas Frecuentes#

Recursos#

• Código fuente en GitHub (scripts, layouts, rutas)
• Santifer iRepair (la web programática)
• Case Study: Business OS / ERP que alimenta estas páginas
• Astro, el framework de sitio estático
• DataForSEO, API de datos SEO
• Airtable, plataforma de datos y CMS