Publiqué un artículo “entre bastidores” sobre cómo estamos construyendo la web de CMS Conf 2026, y es mucho más que “solo una landing page”.
En el artículo cuento:
- por qué elegimos Astro 5 + Tailwind CSS 4 por rendimiento y facilidad de mantenimiento,
- cómo usamos un headless CMS nativo de Git (Pages CMS) en lugar de un backend tradicional,
- qué hicimos en torno al SEO, Schema.org y los datos estructurados propios de eventos,
- y cómo preparamos la web para la búsqueda asistida por IA, entre otras cosas con
llm.txt,llm.jsony actualizaciones automáticas durante la compilación del sitio.
Es una historia práctica sobre diseño, arquitectura frontend, trabajo con el contenido y optimización tanto para buscadores como para modelos de lenguaje, construida por un equipo pequeño y centrado.
Si te interesan las webs de conferencias modernas, las arquitecturas estáticas o el SEO preparado para la IA, puede que te resulte útil.
#Astro #TailwindCSS #SEO #LLMO #AISEO #HeadlessCMS #StaticSites #CMSConf
Cómo construir la web de una conferencia con Astro 5 y Tailwind 4
Mariusz Szatkowski Developer {WordPress | WooCommerce | AI | GEO | AEO | LLMO}
18 de diciembre de 2025
Cuando empezamos a planificar la presencia digital de CMS Conf 2026, sabíamos que el camino habitual de “tema de WordPress + plugins” no bastaría. Queríamos algo distinto. Necesitábamos una web que no fuera solo un folleto, sino una plataforma de contenido de alto rendimiento: rápida, fácil de mantener y diseñada de forma explícita para la era de la IA.
Esta es la historia de cómo nuestro equipo web, Agnieszka Palmowska, Maciek Palmowski y yo, construimos las bases de CMS Conf 2026 con un stack moderno que hoy está en el punto óptimo del desarrollo web.
Rendimiento web con Astro 5 y Tailwind CSS 4
Elegimos Astro 5 por una razón sencilla: el rendimiento es una funcionalidad.
Por defecto, Astro envía cero JavaScript al cliente. Eso significa que nuestras páginas cargan al instante, algo crítico para quien consulta el programa o los ponentes desde el móvil con el wifi flojo de la conferencia. Lo combinamos con Tailwind CSS 4 (usando el nuevo plugin de Vite), y fue toda una revelación.
Medimos la implementación con varias herramientas, una de ellas Google PageSpeed Insights, y estos son los resultados:
Resultado 100 alcanzado
Déjame explicar qué significa esto en la práctica. Cuando hablamos de “cero JavaScript”, no hablamos solo de paquetes más pequeños. Hablamos de un cambio de fondo en la forma de abordar el desarrollo web. Las SPA tradicionales (Single Page Applications) suelen enviar cientos de kilobytes de JavaScript solo para renderizar lo que podría ser contenido estático sencillo. Astro le da la vuelta a ese modelo.
Así funciona: Astro renderiza toda la página a HTML estático durante la compilación. Solo “hidrata” los componentes interactivos cuando hace falta, e incluso entonces lo hace de forma selectiva. Si tienes un componente que debe ser interactivo (como un menú de navegación o un formulario), Astro puede aislar solo ese componente y cargar su JavaScript por separado, dejando el resto de la página como HTML ligero.
Este enfoque nos da lo mejor de ambos mundos: el rendimiento de las páginas estáticas con la interactividad de las aplicaciones web modernas cuando la necesitamos.
Consejo técnico: Si te pasas a Tailwind 4, usa el plugin @tailwindcss/vite. Compila tu CSS en milisegundos, lo que hace que la experiencia de desarrollo sea increíblemente rápida. También implementamos LightningCSS (escrito en Rust) para la minificación y creamos un plugin propio de Vite para precargar el CSS crítico, eliminando el molesto “destello de contenido sin estilo” (FOUC, flash of unstyled content).
Entremos más a fondo en nuestra configuración de Tailwind CSS 4. La nueva versión es un motor escrito desde cero. El escaneo de archivos en busca de nombres de clase durante la compilación sigue ahí, pero Tailwind 4 detecta las fuentes por sí mismo, así que el array content de la versión 3 ya no hace falta, y la configuración ha pasado de JavaScript a CSS mediante la directiva @theme. Esto significa:
- Recompilaciones más rápidas: las compilaciones incrementales que no generan CSS nuevo se saltan el paso más costoso, así que un cambio de clase se ve al momento
- Paquetes más pequeños: solo las clases que aparecen de verdad en los archivos fuente llegan al resultado
También implementamos un sistema propio de design tokens usando las variables CSS de Tailwind. Nos permite mantener la coherencia en todo el sitio sin perder flexibilidad para sobrescribir valores cuando hace falta. Para CMS Conf definimos nuestra paleta de colores, la escala tipográfica y el sistema de espaciado como variables CSS, y después las referenciamos en la configuración de Tailwind.
Nuestro trabajo de rendimiento no terminó ahí. Implementamos:
- CSS crítico en línea para el contenido above the fold
- Lazy loading para imágenes e iframes
- Resource hints (preconnect, prefetch, preload) para recursos externos
- Un service worker para funcionar sin conexión
- Optimización de CDN con optimización automática de imágenes
Pages CMS como headless CMS basado en Git
Un cuello de botella habitual en los proyectos de sitios estáticos es la gestión del contenido. A los desarrolladores les encanta Markdown; a los equipos de marketing… no tanto.
Maciek lo resolvió integrando Pages CMS (https://pagescms.org). Es un headless CMS brillante que trabaja directamente con tu repositorio de GitHub. Da a nuestro equipo de contenido una interfaz cómoda para gestionar las entradas del blog y los perfiles de autores, pero por debajo solo está haciendo commits en nuestro repo.
Por qué funciona:
- Cero infraestructura: No hay base de datos que mantener ni servidores que parchear.
- Nativo de Git: Cada cambio de contenido lanza nuestro pipeline de CI/CD, para asegurar que nada se rompe.
- Coste: Es gratuito para repositorios públicos.
Déjame explicar cómo lo llevamos a la práctica. Un CMS tradicional suele implicar una base de datos aparte, un sistema de autenticación y una capa de API. Eso añade complejidad, coste y posibles agujeros de seguridad. Pages CMS sigue un enfoque completamente distinto.
Esta es nuestra configuración: creamos un directorio content dedicado en el repositorio, con estructuras de carpetas claras para cada tipo de contenido:
content/
├── blog/
│ ├── post-1.md
│ └── post-2.md
├── speakers/
│ ├── speaker-1.md
│ └── speaker-2.md
└── schedule/
├── day-1.md
└── day-2.mdCada archivo Markdown contiene una sección de frontmatter con metadatos estructurados:
---
title: "Budowanie Nowoczesnych Stron Konferencji"
author: "Mariusz Szatkowski"
date: "2025-12-18"
tags: ["astro", "tailwind", "cms"]
status: "published"
featured: true
---Pages CMS lee estos archivos y los presenta en una interfaz amigable. Nuestro equipo de contenido puede:
- Crear contenido nuevo con un editor web con vista previa en directo
- Editar contenido existente en un editor de texto enriquecido que guarda Markdown limpio
- Gestionar medios subiendo imágenes que se optimizan automáticamente y se guardan en nuestro repositorio
- Revisar cambios mediante un flujo integrado con estados de borrador y publicado
- Colaborar con comentarios y sugerencias directamente en el CMS
Lo mejor de este enfoque es que, cuando alguien hace un cambio en Pages CMS, se crea un pull request en nuestro repositorio de GitHub. Eso significa que:
- Todos los cambios pasan por nuestro proceso habitual de revisión de código
- Podemos ejecutar pruebas automáticas sobre los cambios de contenido
- Tenemos un registro completo de cada modificación
- Podemos revertir cambios si hace falta
- Podemos desplegar actualizaciones de contenido de forma independiente de los cambios de código
También implementamos reglas de validación propias para asegurar la calidad del contenido. Por ejemplo, exigimos que todas las entradas del blog tengan:
- Un mínimo de 500 palabras
- Al menos una imagen destacada
- Metadatos SEO correctos
- Ningún enlace interno roto
Estas validaciones se ejecutan automáticamente al guardar el contenido, así que nuestro equipo de contenido recibe la respuesta al instante.
La integración con nuestro proceso de compilación es fluida. Cuando los cambios de contenido se fusionan en main, nuestro pipeline de CI/CD automáticamente:
- Compila el sitio con el contenido nuevo
- Ejecuta pruebas de accesibilidad y rendimiento
- Despliega a producción
- Invalida la caché del CDN
- Envía notificaciones a los miembros del equipo que corresponda
Este enfoque basado en Git ha cambiado nuestra forma de gestionar el contenido. Nuestro equipo de marketing ya puede publicar actualizaciones sin intervención de desarrollo, mientras nosotros mantenemos el control total de la implementación técnica.
Schema.org para el evento y la organización
Posicionar en 2026 exige algo más que palabras clave. Necesitas estructura.
Fuimos a fondo con la implementación de Schema.org. Creamos un componente propio, SchemaOrg.astro, que genera de forma dinámica datos estructurados JSON-LD para cada página.
Qué implementamos:
- Schema de organización: Identifica a Openweb S.C. como entidad jurídica.
- Schema de evento: Da a Google las fechas exactas, la ubicación (PPNT Gdynia) y la información de entradas.
- Enlaces con @id: Lo clave es que usamos referencias @id para “unir los puntos” entre la organización y el evento en el Knowledge Graph de Google.
Consejo pro: No confíes en que los plugins SEO por defecto lo hagan todo. Ajustar tu Schema para enlazar entidades (por ejemplo, conectar tu Event con tu Organization mediante su ID) es una señal potente para los buscadores sobre quién eres y qué haces.
¿Qué es el archivo llm.txt para modelos de IA?
Esta es mi parte favorita. La búsqueda está cambiando. La gente pregunta a ChatGPT y Perplexity por eventos tan a menudo como usa Google. Para que estos sistemas de IA den respuestas exactas sobre CMS Conf, optimizamos la web para ellos.
Implementamos un archivo llm.txt en el directorio raíz de nuestra web.
Piensa en él como un robots.txt, pero para LLM. Ofrece un resumen estructurado y rico en contexto de toda la conferencia, los ponentes, las fechas y el stack tecnológico, con un formato pensado expresamente para que lo ingiera la IA. Incluso escribimos un script propio en Node.js (scripts/update-llm-txt.js) que se ejecuta durante la compilación para escanear nuestros metadatos y mantener este archivo siempre al día.
¿El resultado? Cuando una IA analiza nuestra web, no tiene que adivinar. Le decimos exactamente qué es CMS Conf.
¿Cómo comprobar enlaces rotos en Astro antes de compilar?
Por último, automatizamos lo aburrido. Configuramos una comprobación previa a la compilación con astro-link-validator para no publicar nunca un enlace roto. Verificamos nuestras redirecciones en astro.config.mjs para que gestionen con elegancia las URL heredadas.
Resumen
Construir la web de CMS Conf no fue solo cuestión de código; se trataba de crear un sistema que sirva a nuestros usuarios (velocidad), a nuestro equipo (facilidad de gestión) y a las máquinas que ayudan a la gente a encontrarnos (SEO e IA).
Si estás construyendo un sitio con mucho contenido en 2026, te recomiendo mirar esta arquitectura de Astro + Tailwind + CMS basado en Git. Es ligera, es rápida y escala de maravilla.
Échale un vistazo en: https://cmsconf.com/
Esto acaba de empezar. ¡Nos vemos en Gdynia en noviembre!
#WebDevelopment #AstroJS #TailwindCSS #SEO #AI #CMSConf2026 #TechStack
Si quieres poner orden en este ámbito en tu propio proyecto, echa un vistazo a nuestros servicios de optimización SEO y de visibilidad en IA.
Una web de conferencia en Astro sigue necesitando la integración de IA con WordPress cuando el CMS que hay detrás del programa empieza a responder a los asistentes de IA.
