Conference website with Astro 5 and Tailwind 4: AI-first 2026

I published a “behind the scenes” article on how I am building the CMS Conf 2026 website, and it is much more than “just a landing page”.

In the article I describe:

• why I chose Astro 5 + Tailwind CSS 4 for performance and easy maintenance,
• how I use a Git-native headless CMS (Pages CMS) instead of a traditional backend,
• what I did around SEO, Schema.org and event-specific structured data,
• and how I am preparing the site for AI-assisted search, among other things through llms.txt, llms.json and automatic updates during the site build.

It is a practical story about design, frontend architecture, content work and optimizing for both search engines and language models, built by a small, focused team.

If you are interested in modern conference websites, static architectures or AI-ready SEO, you may find it useful.

#Astro #TailwindCSS #SEO #LLMO #AISEO #HeadlessCMS #StaticSites #CMSConf

#How to build a conference website with Astro 5 and Tailwind 4

Mariusz Szatkowski Developer {WordPress | WooCommerce | AI | GEO | AEO | LLMO}

December 18, 2025

When I started planning the digital presence for CMS Conf 2026, I knew the standard “WordPress theme + plugins” route would not be enough. I wanted something different. I needed a site that would not be just a brochure, but a high-performance content platform: fast, easy to maintain and explicitly designed for the AI era.

This is the story of how my website team, Agnieszka Palmowska, Maciek Palmowski and I, built the foundations for CMS Conf 2026 using a modern stack that sits right in the sweet spot of web development today.

#Website performance with Astro 5 and Tailwind CSS 4

I chose Astro 5 for one simple reason: performance is a feature.

By default, Astro ships zero JavaScript to the client. That means my pages load instantly, which is critical for mobile users checking the schedule or the speakers on weak conference wifi. I paired it with Tailwind CSS 4 (using the new Vite plugin), and that was a revelation.

I measured the implementation with several tools, one of them Google PageSpeed Insights, and here are the results:

Result 100 achieved

Let me explain what this means in practice. When I talk about “zero JavaScript”, I do not just mean smaller bundle sizes. I mean a fundamental shift in how web development is approached. Traditional SPAs (Single Page Applications) often ship hundreds of kilobytes of JavaScript just to render what could be simple static content. Astro flips that model.

Here is how it works: Astro renders the whole page to static HTML at build time. It only “hydrates” interactive components when needed, and even then it does so selectively. If you have a component that has to be interactive (like a navigation menu or a form), Astro can isolate just that component and load its JavaScript independently, leaving the rest of the page as lightweight HTML.

This approach gives us the best of both worlds: the performance of static pages with the interactivity of modern web applications when I need it.

Technical tip: If you are moving to Tailwind 4, use the @tailwindcss/vite plugin. It compiles your CSS in milliseconds, which makes the developer experience incredibly fast. I also implemented LightningCSS (written in Rust) for minification and built a custom Vite plugin for preloading critical CSS, eliminating the annoying “flash of unstyled content” (FOUC).

Let me go deeper into my Tailwind CSS 4 setup. The new version is an engine written from scratch. Scanning files for class names at build time is still there, but Tailwind 4 detects sources on its own, so the content array from version 3 is no longer needed, and configuration has moved from JavaScript to CSS through the @theme directive. This means:

1. Faster rebuilds: incremental builds that do not compile new CSS skip the most expensive step, so a class change shows up immediately
2. Smaller bundles: only the classes that actually appear in source files end up in the output

I also implemented a custom design token system using Tailwind’s CSS variable features. It lets us keep the whole site consistent while still being flexible enough to override values when needed. For CMS Conf I defined my color palette, type scale and spacing system as CSS variables, and then referenced them in my Tailwind configuration.

My performance work did not stop there. I implemented:

• Inlined critical CSS for above-the-fold content
• Lazy loading for images and iframes
• Resource hints (preconnect, prefetch, preload) for external assets
• A service worker for offline functionality
• CDN optimization with automatic image optimization

#Which Astro version the CMS Conf site runs in 2026

This article describes the build as it stood in December 2025, on Astro 5. Astro 5.0 was released on 3 December 2024 (Astro 5.0 release notes). Its headline features were the Content Layer, server islands, simplified prerendering (the old hybrid output mode was merged into static), type-safe environment variables through astro:env, and Vite 6. For a content site the Content Layer matters most: the Astro team reports that collections build up to 5x faster for Markdown pages on content-heavy sites and up to 2x faster for MDX, with memory use cut by 25 to 50%.

Two major versions have shipped since then. Astro 6.0, released on 10 March 2026, requires Node 22 or later, moves to Vite 7 and Zod 4, and adds a built-in Fonts API, a Content Security Policy API and live content collections (Astro 6.0 release notes). Astro 7.0 followed on 22 June 2026 with the .astro compiler rewritten in Rust, a Rust pipeline for Markdown and MDX, and Vite 8; the Astro team measured builds 15 to 61% faster in its own benchmarks (Astro 7.0 release notes). The publish dates in the npm registry match these posts. On 15 October 2026 the generator meta tag on cmsconf.com reported Astro v7.1.1, so the live site has already moved past the version in this article’s title. For an existing project, both sets of release notes point to the same command: npx @astrojs/upgrade.

#How to install Tailwind CSS 4 in an Astro project

Tailwind CSS 4.0 was announced on 22 January 2025 (Tailwind CSS v4.0 announcement). The announcement describes full builds as up to 5x faster and incremental builds as over 100x faster, measured in microseconds, and lists automatic content detection, a first-party Vite plugin and CSS-first configuration among the main changes. The current 4.x line on npm is 4.3.

The official guide (Install Tailwind CSS with Astro) needs four steps once the Astro project exists:

1. Install the packages with npm install tailwindcss @tailwindcss/vite.
2. Add tailwindcss() from @tailwindcss/vite to vite.plugins in astro.config.mjs.
3. Create src/styles/global.css containing @import "tailwindcss";.
4. Import that file in a layout or page and start using utility classes.

This setup has no tailwind.config.js. Theme values go into an @theme block in the same CSS file. Check your audience’s browsers before choosing version 4: the compatibility page says the framework’s core depends on Chrome 111, Safari 16.4 and Firefox 128, and the upgrade guide advises staying on v3.4 if you need to support older browsers.

#Pages CMS as a Git-based headless CMS

A common bottleneck in static site projects is content management. Developers love Markdown; marketing teams… not so much.

Maciek solved this by integrating Pages CMS (https://pagescms.org). It is a brilliant headless CMS that works directly with your GitHub repository. It gives my content team a friendly interface for managing blog posts and author profiles, but under the hood it is just committing changes to my repo.

Why it works:

• Zero infrastructure: There is no database to maintain and no servers to patch.
• Git-native: Every content change triggers my CI/CD pipeline, making sure nothing breaks.
• Cost: It is free and open source under the MIT licence.

Let me explain how I actually put this into practice. A traditional CMS approach often involves a separate database, an authentication system and an API layer. That adds complexity, cost and potential security holes. Pages CMS takes a completely different approach.

Here is my setup: I created a dedicated content directory in my repository with clear folder structures for different content types:

content/
├── blog/
│   ├── post-1.md
│   └── post-2.md
├── speakers/
│   ├── speaker-1.md
│   └── speaker-2.md
└── schedule/
    ├── day-1.md
    └── day-2.md

Each Markdown file contains a frontmatter section with structured metadata:

---
title: "Budowanie Nowoczesnych Stron Konferencji"
author: "Mariusz Szatkowski"
date: "2025-12-18"
tags: ["astro", "tailwind", "cms"]
status: "published"
featured: true
---

Pages CMS reads these files and presents them in a friendly interface. My content team can:

1. Create new content in a web editor with live preview
2. Edit existing content in a rich text editor that saves clean Markdown
3. Manage media by uploading images that are stored in my repository
4. Review changes through a built-in process with draft/published states

Pages CMS saves every edit as a commit on the branch currently open in the editor, so the content history lives in Git next to the code. When editors work on a branch other than main, their changes reach production through a pull request. That means:

• All changes go through my normal code review process
• I can run automated tests on content changes
• I have a full audit trail of every modification
• I can roll back changes when needed
• I can deploy content updates independently of code changes

I also implemented custom validation rules to ensure content quality. For example, I require every blog post to have:

• A minimum word count of 500
• At least one featured image
• Proper SEO metadata
• No broken internal links

These validations run automatically when content is saved, giving my content team immediate feedback.

The build process picks up content changes on its own. When they are merged into main, my CI/CD pipeline automatically:

1. Builds the site with the new content
2. Runs accessibility and performance tests
3. Deploys to production
4. Invalidates the CDN cache
5. Sends notifications to the relevant team members

This Git-based approach has transformed how I handle content. My marketing team can now ship updates without developer intervention, while I keep full control over the technical implementation.

#How Pages CMS is configured in a repository

All Pages CMS configuration lives in one file, .pages.yml, at the repository root (Pages CMS configuration). Pages CMS reads it per repository and per branch, so a feature branch can carry a changed content model without touching production. The top-level keys are media (where uploads are stored and which URLs are written into content), content (the editable collections and single files), components (shared field definitions), settings and actions.

Two settings are worth knowing before a team starts editing. settings.content.merge defaults to false, which rewrites a file from the configured schema only and removes anything outside the editor’s output; with true, Pages CMS merges the submitted fields into the existing file and keeps keys the schema does not define (Pages CMS settings). On a site where build scripts add their own frontmatter keys, the default would drop them on the next edit. settings.commit.templates sets the commit messages, with defaults such as “Update {path} (via Pages CMS)”, which makes content commits easy to filter in git log. The actions key adds buttons that dispatch GitHub Actions workflows from .github/workflows/, for example a deploy or a preview build. Pages CMS supports GitHub only, and it is free and MIT-licensed whether you use the hosted version, deploy it on Vercel or host it yourself (pagescms.org).

#Schema.org for the event and the organization

Ranking in 2026 takes more than keywords. You need structure.

I went deep on Schema.org implementation. I built a custom SchemaOrg.astro component that dynamically generates JSON-LD structured data for every page.

What I implemented:

• Organization schema: Identifying Openweb S.C. as the legal entity.
• Event schema: Giving Google precise dates, the location (PPNT Gdynia) and ticket information.
• @id linking: Crucially, I use @id references to “connect the dots” between the organization and the event in Google’s Knowledge Graph.

Pro tip: Do not rely on default SEO plugins to do everything. Customizing your Schema to link entities (for example, connecting your Event to your Organization by ID) is a powerful signal to search engines about who you are and what you do.

#Which Event properties Google needs for event rich results

Google’s event documentation (Event structured data) lists three required properties: name, startDate in ISO 8601 format with a time, and location as a Place with a name and a full PostalAddress. A city name on its own is marked as not recommended for the address. The recommended set covers description, endDate, eventStatus, image (Google recommends 1920 px wide, minimum 720 px), offers, organizer and performer. In offers, price is the lowest available ticket price including fees, and 0 marks a free event.

For a conference the mapping is direct. organizer is where the Organization @id from the previous paragraphs is referenced instead of repeated, offers.url points to the ticket page, and performer can list speakers as Person entries. If the event moves, Google documents previousStartDate for the old date; it must be used together with eventStatus set to EventRescheduled, and startDate then carries only the new date.

#What is an llms.txt file for AI models

This is my favorite part. Search is changing. People ask ChatGPT and Perplexity about events as often as they use Google. To make sure these AI systems give accurate answers about CMS Conf, I optimized the site for them.

I implemented an llms.txt file in the root directory of my site.

Think of it like robots.txt, but for LLMs. It provides a structured, context-rich summary of the whole conference, the speakers, the dates and the tech stack, explicitly formatted for AI ingestion. I even wrote a custom Node.js script (scripts/update-llm-txt.js) that runs at build time to scan my metadata and keep this file perfectly up to date.

The result? When an AI scans my site, it does not have to guess. I tell it exactly what CMS Conf is.

#What goes into an llms.txt file

The convention behind this file is the llms.txt proposal by Jeremy Howard, published on 3 September 2024 and revised as v2 in August 2026 (llmstxt.org). The proposal names the file llms.txt, with an “s”, and that is the path cmsconf.com serves: /llms.txt returns plain text and /llms.json returns JSON, while /llm.txt returns an HTML page. The format is Markdown in a fixed order:

1. An H1 with the name of the project or site, the only required element.
2. A blockquote with a short summary.
3. Optional paragraphs or lists with more detail, without headings.
4. Sections under H2 headings, each a list of links in the form [name](url) with optional notes.

A section titled “Optional” marks links an agent can skip when it needs a shorter context. The CMS Conf file follows this shape: the H1 is “CMS Conf 2026”, the blockquote describes the conference, and a “Project Information” section lists the agenda, the ticket page, the call for papers and the legal pages. The proposal describes llms.txt as a file that coexists with robots.txt and sitemaps, and nothing in it obliges a model or a search engine to read the file.

#How to check for broken links in Astro before the build

Finally, I automated the boring stuff. I set up an astro-link-validator pre-build check to make sure I never ship a bad link. I verified my redirects in astro.config.mjs so they handle legacy URLs gracefully.

#Summary

Building the CMS Conf website was not just about code; it was about creating a system that serves my users (speed), my practice (manageability) and the machines that help people find us (SEO & AI).

If you are building a content-rich site in 2026, I recommend looking at this Astro + Tailwind + Git-based CMS architecture. It is lean, it is fast and it scales beautifully.

See it at: https://cmsconf.com/

I am just getting started. See you in Gdynia in November!

#WebDevelopment #AstroJS #TailwindCSS #SEO #AI #CMSConf2026 #TechStack

See my SEO and AI visibility optimization services if you want to put this area in order in your own project.

A conference website on Astro still needs AI integration with WordPress once the CMS behind the schedule starts answering assistants.