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
llms.txt,llms.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 yo web, Agnieszka Palmowska, Maciek Palmowski y yo, construyo 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 implemento LightningCSS (escrito en Rust) para la minificación y creo 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 implemento 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í. Implemento:
- 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
Qué versión de Astro usa la web de CMS Conf en 2026
Este artículo describe la compilación tal como estaba en diciembre de 2025, con Astro 5. Astro 5.0 se publicó el 3 de diciembre de 2024 (notas de la versión Astro 5.0). Sus novedades principales fueron la Content Layer, las server islands, el prerenderizado simplificado (el antiguo modo de salida hybrid se fusionó con static), las variables de entorno con tipos a través de astro:env y Vite 6. Para una web de contenido lo que más pesa es la Content Layer: el equipo de Astro indica que las colecciones compilan hasta 5 veces más rápido en páginas Markdown de sitios con mucho contenido y hasta 2 veces más rápido en MDX, con un consumo de memoria entre un 25 y un 50% menor.
Desde entonces han salido dos versiones mayores. Astro 6.0, publicada el 10 de marzo de 2026, exige Node 22 o posterior, pasa a Vite 7 y Zod 4, y añade una Fonts API integrada, una API de Content Security Policy y las colecciones de contenido en vivo (notas de la versión Astro 6.0). Astro 7.0 llegó el 22 de junio de 2026 con el compilador de .astro reescrito en Rust, un pipeline en Rust para Markdown y MDX, y Vite 8; el equipo de Astro midió compilaciones entre un 15 y un 61% más rápidas en sus propias pruebas (notas de la versión Astro 7.0). Las fechas de publicación en el registro de npm coinciden con estas entradas. El 15 de octubre de 2026 la etiqueta meta generator de cmsconf.com indicaba Astro v7.1.1, así que la web en producción ya ha dejado atrás la versión del título de este artículo. Para un proyecto existente, las notas de ambas versiones remiten al mismo comando: npx @astrojs/upgrade.
Cómo instalar Tailwind CSS 4 en un proyecto Astro
Tailwind CSS 4.0 se anunció el 22 de enero de 2025 (anuncio de Tailwind CSS v4.0). El anuncio habla de compilaciones completas hasta 5 veces más rápidas y de compilaciones incrementales más de 100 veces más rápidas, medidas en microsegundos, y cita entre los cambios principales la detección automática de contenido, un plugin oficial para Vite y la configuración CSS-first. La línea 4.x actual en npm es la 4.3.
La guía oficial (Install Tailwind CSS with Astro) tiene cuatro pasos una vez creado el proyecto Astro:
- Instalar los paquetes con
npm install tailwindcss @tailwindcss/vite. - Añadir
tailwindcss()de@tailwindcss/viteavite.pluginsenastro.config.mjs. - Crear
src/styles/global.csscon@import "tailwindcss";. - Importar ese archivo en un layout o una página y empezar a usar las clases de utilidad.
En esta configuración no hay tailwind.config.js. Los valores del tema van en un bloque @theme dentro del mismo archivo CSS. Antes de elegir la versión 4, revisa los navegadores de tu público: la página de compatibilidad indica que el núcleo del framework depende de Chrome 111, Safari 16.4 y Firefox 128, y la guía de actualización recomienda quedarse en la v3.4 si necesitas dar soporte a navegadores más antiguos.
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 yo 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 y de código abierto, con licencia MIT.
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: creo 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. Yo 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 guardan en nuestro repositorio
- Revisar cambios mediante un flujo integrado con estados de borrador y publicado
Pages CMS guarda cada edición como un commit en la rama que está abierta en el editor, así que el historial del contenido vive en Git junto al código. Cuando el equipo edita en una rama distinta de main, los cambios llegan a producción mediante un pull request. 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 implemento 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 yo 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. Yo de marketing ya puede publicar actualizaciones sin intervención de desarrollo, mientras nosotros mantenemos el control total de la implementación técnica.
Cómo se configura Pages CMS en un repositorio
Toda la configuración de Pages CMS está en un solo archivo, .pages.yml, en la raíz del repositorio (configuración de Pages CMS). Pages CMS lo lee por repositorio y por rama, así que una rama de desarrollo puede llevar un modelo de contenido modificado sin tocar producción. Las claves de primer nivel son media (dónde se guardan las subidas y qué URL se escriben en el contenido), content (las colecciones y archivos editables), components (definiciones de campos compartidas), settings y actions.
Conviene conocer dos ajustes antes de que el equipo empiece a editar. settings.content.merge vale false por defecto, lo que reescribe el archivo solo a partir del esquema configurado y elimina todo lo que quede fuera de lo que devuelve el editor; con true, Pages CMS fusiona los campos enviados con el archivo existente y conserva las claves que el esquema no define (ajustes de Pages CMS). En una web donde los scripts de compilación añaden sus propias claves al frontmatter, el valor por defecto las borraría en la siguiente edición. settings.commit.templates define los mensajes de commit, con valores por defecto como “Update {path} (via Pages CMS)”, lo que permite filtrar los commits de contenido en git log. La clave actions añade botones que lanzan flujos de GitHub Actions desde .github/workflows/, por ejemplo un despliegue o una compilación de vista previa. Pages CMS solo funciona con GitHub y es gratuito y con licencia MIT, tanto en la versión alojada como desplegado en Vercel o en tu propio servidor (pagescms.org).
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. Creo un componente propio, SchemaOrg.astro, que genera de forma dinámica datos estructurados JSON-LD para cada página.
Qué implemento:
- 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é propiedades de Event pide Google para los resultados enriquecidos de eventos
La documentación de Google sobre eventos (datos estructurados de Event) enumera tres propiedades obligatorias: name, startDate en formato ISO 8601 con hora, y location como Place con name y una PostalAddress completa. Indicar solo el nombre de la ciudad como dirección figura como no recomendado. Las recomendadas son description, endDate, eventStatus, image (Google recomienda 1920 px de ancho, con un mínimo de 720 px), offers, organizer y performer. Dentro de offers, price es el precio más bajo disponible de la entrada con comisiones incluidas, y 0 marca un evento gratuito.
En una conferencia la correspondencia es directa. En organizer se referencia el @id de la Organization de los párrafos anteriores en lugar de repetirla, offers.url apunta a la página de entradas y performer puede listar a los ponentes como entradas Person. Si el evento cambia de fecha, Google documenta previousStartDate para la fecha antigua; debe usarse junto con eventStatus con el valor EventRescheduled, y startDate pasa a llevar solo la fecha nueva.
Qué es el archivo llms.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.
Implemento un archivo llms.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.
Qué contiene un archivo llms.txt
La convención detrás de este archivo es la propuesta llms.txt de Jeremy Howard, publicada el 3 de septiembre de 2024 y revisada como v2 en agosto de 2026 (llmstxt.org). La propuesta llama al archivo llms.txt, con “s”, y esa es la ruta que sirve cmsconf.com: /llms.txt devuelve texto plano y /llms.json devuelve JSON, mientras que /llm.txt devuelve una página HTML. El formato es Markdown en un orden fijo:
- Un H1 con el nombre del proyecto o del sitio, el único elemento obligatorio.
- Una cita (blockquote) con un resumen breve.
- Párrafos o listas opcionales con más detalle, sin encabezados.
- Secciones bajo encabezados H2, cada una con una lista de enlaces en la forma
[nombre](url)y notas opcionales.
Una sección titulada “Optional” marca los enlaces que un agente puede saltarse cuando necesita un contexto más corto. El archivo de CMS Conf sigue esta forma: el H1 es “CMS Conf 2026”, la cita describe la conferencia y una sección “Project Information” enumera la agenda, la página de entradas, la convocatoria de ponencias y las páginas legales. La propuesta describe llms.txt como un archivo que convive con robots.txt y los sitemaps, y nada en ella obliga a un modelo ni a un buscador a leerlo.
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 yo (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 mis 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.
