Cómo organizar una web de muchas páginas para que siga siendo mantenible

Una web de muchas páginas sigue siendo mantenible cuando cada cambio tiene un lugar previsible. El contenido variable vive separado de la estructura compartida, los componentes resuelven repeticiones reales y los metadatos se generan desde una fuente común. Si añadir una página obliga a copiar otra y recordar cinco archivos más, el problema no es el número de URLs: es la arquitectura.

He aplicado esta idea en dos contextos distintos. La web de Patricia Pólvora reúne 17 páginas públicas con servicios, informes, publicaciones y contacto. Este portfolio combina proyectos, artículos, páginas de servicio y versiones en español e inglés. En ambos casos, crecer sin orden habría multiplicado también las incoherencias.

Esta es la estructura que utilizo para que una web multipágina pueda ampliarse sin convertir cada nueva ruta en una excepción.

El problema no empieza cuando hay muchas páginas

Una web puede resultar difícil de mantener con cinco páginas y seguir ordenada con cincuenta. La diferencia está en cuántas decisiones hay que repetir manualmente.

Estas son señales de que la arquitectura empieza a fallar:

• El encabezado o el pie se copian en cada página.
• Los datos de contacto aparecen escritos en varios componentes.
• Cada ruta construye su propio <head> y su propio schema.
• Un mismo bloque tiene versiones casi iguales con pequeñas diferencias.
• Los estilos dependen de selectores globales o de saber en qué orden se importan.
• Añadir una página exige recordar a mano el sitemap, la navegación y los enlaces relacionados.

El coste aparece después. Un teléfono cambia en cuatro lugares, una versión inglesa conserva una frase antigua o una página nueva sale sin imagen social. Ninguno de esos fallos es complejo por separado. Lo difícil es que el proyecto dependa de recordarlos todos.

Por eso no intento eliminar cada repetición desde el primer día. Primero identifico qué pertenece al sitio completo, qué se repite en una familia de páginas y qué debe seguir siendo específico de una URL.

Antes de los componentes, preparo el mapa de contenido

La primera decisión no es técnica. Es decidir qué información merece una página y qué función cumple cada URL.

En la web de Patricia no partí de una lista de plantillas. Había tres servicios de consultoría, informes, formaciones, publicaciones, prensa, trayectoria y distintas formas de contacto. La arquitectura debía permitir tres recorridos: entender un servicio, comprobar experiencia y contactar.

MDN denomina arquitectura de la información al trabajo de organizar las páginas y sus relaciones. Un mapa inicial ayuda a distinguir entre una página con intención propia y un bloque que solo necesita formar parte de otra.

Para cada ruta anoto cuatro cosas:

Este mapa evita crear páginas porque existe una plantilla disponible. También permite detectar familias: servicios con una estructura parecida, proyectos con los mismos campos o artículos que comparten autor, fecha y navegación.

Separo cuatro capas con responsabilidades distintas

Una web multipágina se vuelve más previsible cuando la organización del repositorio refleja las preguntas anteriores.

Astro define los layouts como componentes que proporcionan una estructura reutilizable para las páginas. En este proyecto, BaseLayout.astro no sabe qué artículo se está leyendo ni qué proyecto se muestra. Se ocupa del documento, el SEO compartido, la cabecera, el contenido principal y el pie.

Las rutas de artículos añaden después lo que pertenece a esa familia: cabecera editorial, fecha, tiempo de lectura, índice, autor, schema BlogPosting y navegación entre publicaciones. El MDX conserva el contenido de una pieza concreta. Cada nivel sabe lo suficiente para hacer su trabajo, pero no intenta controlar todo el sitio.

La estructura actual se puede resumir así:

src/
├── layouts/       # estructura global
├── pages/         # rutas y plantillas de página
├── components/    # bloques reutilizables
├── content/       # artículos y proyectos
├── config/        # datos compartidos y relaciones
└── sass/          # estilos por responsabilidad

No es una estructura universal. Es útil porque los nombres expresan dónde buscar cada cambio.

Centralizo datos antes de abstraer interfaces

Cuando algo se repite, no siempre necesita un componente. A veces necesita una fuente de datos.

El nombre del autor, la URL base, los enlaces sociales o la descripción del servicio no deberían escribirse de nuevo en cada página. En este portfolio viven en configuración compartida. Así, una plantilla puede consumirlos sin crear otra copia que se quede desactualizada.

Para grupos de contenido utilizo colecciones tipadas. Los proyectos comparten campos como título, resumen, rol, stack, imágenes y fechas. Los artículos comparten títulos localizados, resúmenes, etiquetas, fechas e imágenes Open Graph. El esquema convierte esas expectativas en una comprobación del build:

const posts = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    title_en: z.string().optional(),
    summary: z.string(),
    summary_en: z.string().optional(),
    publishedAt: z.coerce.date(),
    updatedAt: z.coerce.date().optional(),
  }),
});

Las Content Collections de Astro permiten definir una forma común, validar cada entrada y obtener tipos de TypeScript al consultar el contenido. Si falta una fecha o un campo tiene otro formato, prefiero que el proyecto falle durante la comprobación y no que la incoherencia llegue a producción.

Centralizar tampoco significa guardar todo en un único archivo. Los datos globales, una entrada editorial y la configuración de un clúster cambian por motivos distintos. Juntarlos solo reemplazaría muchas copias pequeñas por un archivo enorme que nadie quiere tocar.

Un componente debe eliminar una repetición real

Extraigo un componente cuando varias páginas comparten estructura y comportamiento, no solo porque dos fragmentos se parecen visualmente.

Una tarjeta de proyecto es un buen componente: recibe datos, conserva la misma semántica y resuelve el mismo tipo de enlace. La cabecera de una página de servicio y la de un artículo pueden parecer similares, pero comunican información distinta. Forzarlas dentro de un componente lleno de propiedades opcionales haría más difícil entender ambas.

Utilizo tres criterios antes de extraer:

1. La estructura se repite en más de un lugar.
2. El bloque tiene una responsabilidad que se puede nombrar.
3. Un cambio coherente debería propagarse a todas sus apariciones.

Si para reutilizar un componente necesito propiedades como isArticle, isProject, compact, showDate, hideSummary y varias combinaciones más, probablemente he unido familias que solo compartían apariencia.

La abstracción útil reduce decisiones futuras. La abstracción prematura oculta dónde se toma cada decisión.

Los estilos también necesitan límites

Una arquitectura de componentes no arregla una hoja de estilos donde cualquier selector puede afectar a cualquier página.

En el portfolio separo fundamentos, layout, componentes y estilos propios de cada página. Un token de color puede utilizarse en todo el sitio. La cuadrícula principal pertenece al layout. Una tarjeta conserva sus reglas junto al componente y un ajuste exclusivo del artículo no necesita convertirse en una utilidad global.

En la web de Patricia organicé Sass con la misma intención: evitar que una página nueva obligara a copiar bloques completos o a sobrescribir reglas antiguas. Esa estructura no impide todos los conflictos, pero acota dónde buscar cuando aparecen.

Hay dos extremos que evito:

• Un único archivo global donde el orden de cientos de reglas forma parte de la lógica.
• Un sistema de utilidades y variantes creado antes de saber qué patrones existen de verdad.

Los estilos mantenibles no son los que tienen más capas. Son los que permiten cambiar un bloque sin revisar visualmente todo el sitio por miedo a un efecto lateral.

Rutas y metadatos forman parte de la arquitectura

Una página no está completa solo porque renderice su contenido. También necesita una URL estable, un título, una descripción, canonical, relaciones lingüísticas y, cuando corresponde, datos estructurados.

Copiar ese bloque en cada archivo funciona hasta que cambia una regla. En este portfolio, las rutas dinámicas de artículos y proyectos construyen esas señales desde los datos de cada entrada. Astro permite generar rutas dinámicas a partir de una colección durante el build, de modo que una plantilla controla la familia y cada entrada aporta su contenido.

El principio no consiste en generar todo automáticamente. Consiste en centralizar la regla y mantener específico el valor:

• La plantilla decide cómo se construye una canonical.
• La entrada decide su título y resumen.
• La configuración conoce la URL base y el autor.
• El schema de la página une esas fuentes sin volver a escribirlas.

Así, añadir un artículo no requiere copiar un <head> existente. Requiere completar los campos que la colección valida.

El build debe encontrar olvidos, no solo errores de sintaxis

Una web mantenible necesita comprobaciones proporcionales a lo que puede romperse.

En este portfolio ejecuto la comprobación de Astro, genero el sitio completo y reviso su salida. Además, una prueba recorre el HTML publicado para comprobar sitemap, idiomas, schema, imágenes y relaciones internas. No sustituye la revisión visual, pero detecta errores repetibles que no deberían depender de abrir decenas de páginas a mano.

El objetivo no es probar cada línea. Es cubrir las reglas compartidas cuyo fallo afectaría a muchas URLs:

• Todas las entradas públicas aparecen donde deben.
• Los metadatos localizados corresponden al idioma de la ruta.
• Las imágenes sociales existen.
• Los hubs no enlazan artículos inexistentes.
• Las páginas importantes conservan canonical y schema coherentes.

Cuanto mayor es el efecto de una regla compartida, más valor tiene una comprobación automática sobre ella.

Lo que funcionó en una web de 17 páginas

En el proyecto de Patricia Pólvora, la mantenibilidad no vino de reducir todas las páginas a una sola plantilla. Vino de distinguir qué compartían y qué necesitaba seguir siendo propio.

Centralicé datos repetidos, preparé componentes reutilizables y organicé los estilos para que los servicios, informes, publicaciones y páginas de trayectoria pudieran crecer sobre una base común. Cada una conservó su contenido y sus metadatos porque respondía a una intención diferente.

El resultado verificable es una web publicada con 17 URLs en su sitemap, tres servicios principales y rutas diferenciadas para informes, formación, prensa, publicaciones y contacto. No atribuyo a esa arquitectura métricas de negocio que no tengo. Sí puedo comprobar que el sitio se construyó, se publicó y puede ampliarse sin rehacer su estructura principal.

Este portfolio aplica el mismo principio con otras necesidades. Aquí una sola entrada produce versiones española e inglesa, los artículos se agrupan en rutas temáticas y los metadatos se generan desde datos tipados. La solución concreta cambia; la pregunta se mantiene: ¿cuántos lugares hay que recordar para publicar una página coherente?

La arquitectura depende de quién mantendrá la web

Una base de código ordenada puede seguir siendo la solución equivocada si quien actualiza la web necesita un panel y no va a trabajar con el repositorio.

Antes de elegir la arquitectura conviene definir:

• Quién cambiará textos e imágenes.
• Con qué frecuencia se publicará.
• Si hacen falta borradores, permisos o revisiones.
• Quién actualizará dependencias y comprobará despliegues.
• Qué parte del mantenimiento está incluida después de la entrega.

Cuando varias personas publican con frecuencia, un CMS puede reducir fricción editorial aunque añada integración, permisos y mantenimiento técnico. En Astro con Sanity y en la comparación entre Keystatic y Sanity explico esas responsabilidades.

Una web no es mantenible solo porque su código esté limpio. También debe existir un proceso realista para actualizarla.

Una comprobación rápida antes de añadir otra página

Antes de crear una ruta nueva, reviso estas preguntas:

1. ¿La página tiene un propósito y una intención distintos?
2. ¿Pertenece a una familia existente o necesita otra estructura?
3. ¿Qué contenido es propio y qué datos ya existen en configuración?
4. ¿Qué componente elimina una repetición real sin añadir variantes innecesarias?
5. ¿De dónde salen su title, canonical, imagen social y schema?
6. ¿Qué comprobación detectará si la nueva ruta queda incompleta?
7. ¿Quién podrá actualizarla dentro de seis meses?

Si las respuestas están claras, sumar páginas no tiene por qué sumar desorden. El trabajo importante ocurre antes: diseñar una estructura que haga visible dónde vive cada decisión.

El caso de Patricia Pólvora recoge el alcance, las 17 páginas y el resultado publicado de una arquitectura aplicada a un encargo real.