Konferenz-Website mit Astro 5 und Tailwind 4: KI-zentrierter Ansatz 2026

Ich habe gerade einen hinter den Kulissen Artikel darüber veröffentlicht, wie wir die CMS Conf 2026 Website bauen, und es ist viel mehr als “nur eine Landing Page”.

In dem Artikel gehe ich durch:

• warum wir uns für Astro 5 + Tailwind CSS 4 für Leistung und Wartbarkeit entschieden haben,
• wie wir ein Git-natives Headless CMS (Pages CMS) anstelle eines traditionellen Backends verwenden,
• was wir rund um SEO, Schema.org und ereignisspezifische strukturierte Daten gemacht haben,
• und wie wir die Site für die von KI geprägte Zukunft der Suche vorbereiten mit Dingen wie llms.txt, llms.json und automatisierten Updates während des Build-Prozesses.

Es ist eine praktische Geschichte über Design, Frontend-Architektur, Content-Workflows und Optimierung für sowohl Suchmaschinen als auch LLMs, gebaut von einem kleinen, fokussierten Team.

Wenn Sie sich für moderne Konferenz-Sites, statische Architekturen oder KI-fähiges SEO interessieren, könnten Sie es nützlich finden.

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

#Konferenz-Website mit Astro 5 und Tailwind 4 erstellen

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

18. Dezember 2025

Als wir mit der Planung der digitalen Präsenz für CMS Conf 2026 begannen, wussten wir, dass der Standard-”WordPress-Theme + Plugins”-Weg nicht ausreichen würde. Wir wollten etwas anderes. Wir brauchten eine Site, die nicht nur eine Broschüre ist, sondern eine Hochleistungs-Content-Plattform, schnell, wartbar und explizit für das KI-Zeitalter konzipiert.

Hier ist die Geschichte, wie unser Website-Team, Agnieszka Palmowska, Maciek Palmowski und ich, die Grundlagen für CMS Conf 2026 mit einem modernen Stack gebaut haben, der der Sweet Spot für Webentwicklung jetzt ist.

#Performance mit Astro 5 und Tailwind CSS 4

Ich habe uns für Astro 5 aus einem einfachen Grund entschieden: Leistung ist ein Feature.

Standardmäßig liefert Astro null JavaScript an den Client. Das bedeutet, dass unsere Seiten sofort laden, was für mobile Nutzer kritisch ist, die den Zeitplan oder Redner auf spotty Konferenz-WiFi überprüfen. Wir kombinierten dies mit Tailwind CSS 4 (unter Verwendung des neuen Vite-Plugins), was eine Offenbarung war.

Ich habe die Implementierung in vielen Tools gemessen, eines davon war Google PageSpeed Insights und hier sind die Ergebnisse:

Ergebnis 100 erreicht

Aber lassen Sie mich erklären, was das in der Praxis bedeutet. Wenn wir von “null JavaScript” sprechen, reden wir nicht nur über kleinere Bundle-Größen. Wir sprechen über eine grundlegende Veränderung in der Herangehensweise an die Web-Entwicklung. Traditionelle SPAs (Single Page Applications) liefern oft Hunderte von Kilobytes JavaScript nur, um das zu rendern, was einfacher statischer Inhalt sein könnte. Astro dreht dieses Modell um.

So funktioniert es: Astro rendert Ihre gesamte Site zu statischem HTML zur Build-Zeit. Es “hydriert” nur interaktive Komponenten, wenn nötig, und selbst dann tut es dies intelligent. Wenn Sie eine Komponente haben, die interaktiv sein muss (wie ein Navigationsmenü oder ein Formular), kann Astro nur diese Komponente isolieren und das JavaScript dafür unabhängig laden, während der Rest der Seite als leichtgewichtiges HTML bleibt.

Dieser Ansatz gibt uns das Beste aus beiden Welten: die Leistung von statischen Sites mit der Interaktivität moderner Web-Anwendungen, wenn wir sie brauchen.

Technischer Tipp: Wenn Sie zu Tailwind 4 wechseln, verwenden Sie das @tailwindcss/vite-Plugin. Es kompiliert Ihr CSS in Millisekunden, was das Entwicklererlebnis unglaublich schnell macht. Ich habe auch LightningCSS (Rust-basiert) für die Minifizierung implementiert und ein benutzerdefiniertes Vite-Plugin zum Vorladen von kritischem CSS gebaut, um den störenden “Flash of Unstyled Content” (FOUC) zu eliminieren.

Lassen Sie mich tiefer in unser Tailwind CSS 4-Setup eintauchen. Die neue Version ist eine von Grund auf neu geschriebene Engine. Der Scan der Dateien nach Klassennamen zur Build-Zeit bleibt, aber Tailwind 4 erkennt die Quellen selbst, das content-Array aus Version 3 entfällt, und die Konfiguration wandert aus JavaScript ins CSS, in die @theme-Direktive. Das bedeutet:

1. Schnellere Rebuilds: inkrementelle Builds, die kein neues CSS kompilieren müssen, überspringen den teuersten Schritt, eine geänderte Klasse ist also sofort sichtbar
2. Kleinere Bundles: nur Klassen, die tatsächlich in den Quelldateien stehen, landen im Ergebnis

Ich habe auch ein benutzerdefiniertes Design-Token-System mit Tailwinds CSS-Variablen-Funktion implementiert. Dies ermöglicht es uns, Konsistenz über die gesamte Site zu wahren, während wir dennoch die Flexibilität behalten, Werte bei Bedarf zu überschreiben. Für CMS Conf haben wir unsere Farbpalette, Typografie-Skala und Abstandssystem als CSS-Variablen definiert und dann in unserer Tailwind-Konfiguration referenziert.

Unsere Leistungsoptimierungen hörten dort nicht auf. Wir implementierten:

• Kritisches CSS-Inlining für Above-the-Fold-Inhalte
• Lazy Loading für Bilder und Iframes
• Resource-Hinweise (Preconnect, Prefetch, Preload) für externe Ressourcen
• Service Worker für Offline-Funktionalität
• CDN-Optimierung mit automatischer Bildoptimierung

#Welche Astro-Version die CMS-Conf-Website 2026 nutzt

Dieser Artikel beschreibt den Build im Stand von Dezember 2025, also auf Astro 5. Astro 5.0 erschien am 3. Dezember 2024 (Release Notes zu Astro 5.0). Die wichtigsten Neuerungen waren der Content Layer, Server Islands, vereinfachtes Prerendering (der alte Ausgabemodus hybrid wurde mit static zusammengelegt), typsichere Umgebungsvariablen über astro:env und Vite 6. Für eine Content-Website zählt vor allem der Content Layer: Laut Astro-Team bauen Collections bei Markdown-Seiten auf inhaltsreichen Websites bis zu 5-mal schneller und bei MDX bis zu 2-mal schneller, bei 25 bis 50% weniger Speicherverbrauch.

Seitdem sind zwei Hauptversionen erschienen. Astro 6.0 vom 10. März 2026 setzt Node 22 oder neuer voraus, wechselt auf Vite 7 und Zod 4 und bringt eine eingebaute Fonts API, eine Content Security Policy API und Live Content Collections (Release Notes zu Astro 6.0). Astro 7.0 folgte am 22. Juni 2026 mit einem in Rust neu geschriebenen .astro-Compiler, einer Rust-Pipeline für Markdown und MDX sowie Vite 8; das Astro-Team hat in eigenen Benchmarks 15 bis 61% schnellere Builds gemessen (Release Notes zu Astro 7.0). Die Veröffentlichungsdaten in der npm-Registry stimmen mit diesen Beiträgen überein. Am 15. Oktober 2026 meldete das generator-Meta-Tag auf cmsconf.com Astro v7.1.1, die Live-Website ist also schon über die Version im Titel dieses Artikels hinaus. Für ein bestehendes Projekt nennen beide Release Notes denselben Befehl: npx @astrojs/upgrade.

#Tailwind CSS 4 in einem Astro-Projekt installieren

Tailwind CSS 4.0 wurde am 22. Januar 2025 angekündigt (Ankündigung von Tailwind CSS v4.0). Laut Ankündigung sind vollständige Builds bis zu 5-mal und inkrementelle Builds mehr als 100-mal schneller, gemessen in Mikrosekunden. Zu den wichtigsten Änderungen zählen die automatische Erkennung von Quelldateien, ein offizielles Vite-Plugin und die CSS-first-Konfiguration. Die aktuelle 4.x-Linie auf npm ist 4.3.

Die offizielle Anleitung (Install Tailwind CSS with Astro) besteht nach dem Anlegen des Astro-Projekts aus vier Schritten:

1. Pakete installieren mit npm install tailwindcss @tailwindcss/vite.
2. tailwindcss() aus @tailwindcss/vite in astro.config.mjs unter vite.plugins eintragen.
3. src/styles/global.css mit @import "tailwindcss"; anlegen.
4. Diese Datei in einem Layout oder einer Seite importieren und die Utility-Klassen verwenden.

In diesem Setup gibt es keine tailwind.config.js. Theme-Werte stehen in einem @theme-Block in derselben CSS-Datei. Prüfen Sie vor der Entscheidung für Version 4 die Browser Ihrer Zielgruppe: Laut Kompatibilitätsseite hängt der Kern des Frameworks von Chrome 111, Safari 16.4 und Firefox 128 ab, und der Upgrade-Leitfaden rät, bei v3.4 zu bleiben, wenn ältere Browser unterstützt werden müssen.

#Pages CMS als Git-basiertes Headless CMS

Ein häufiger Engpass bei statischen Site-Projekten ist die Content-Verwaltung. Entwickler lieben Markdown; Marketing-Teams… nicht so sehr.

Maciek löste dies durch die Integration von Pages CMS (https://pagescms.org). Es ist ein brillantes Headless CMS, das direkt mit Ihrem GitHub-Repository arbeitet. Es gibt unserem Content-Team eine freundliche UI zur Verwaltung von Blog-Posts und Autorenprofilen, aber unter der Haube ist es nur das Committen von Änderungen an unser Repo.

Warum das funktioniert:

• Zero Infrastructure: Keine Datenbank zu warten, keine Server zu patchen.
• Git-Nativ: Jede Content-Änderung löst unsere CI/CD-Prozess aus und stellt sicher, dass nichts kaputt geht.
• Kosten: Es ist kostenlos und Open Source unter MIT-Lizenz.

Aber lassen Sie mich erklären, wie wir das tatsächlich in der Praxis implementiert haben. Der traditionelle CMS-Ansatz beinhaltet oft eine separate Datenbank, ein Authentifizierungssystem und eine API-Schicht. Dies fügt Komplexität, Kosten und potenzielle Sicherheitslücken hinzu. Pages CMS nimmt einen völlig anderen Ansatz.

Hier ist unser Setup: Ich habe ein dediziertes content-Verzeichnis in unserem Repository mit klaren Ordnerstrukturen für verschiedene Content-Typen erstellt:

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

Jede Markdown-Datei enthält eine Frontmatter-Sektion mit strukturierten Metadaten:

---
title: "Moderne Konferenz-Websites bauen"
author: "Mariusz Szatkowski"
date: "2025-12-18"
tags: ["astro", "tailwind", "cms"]
status: "published"
featured: true
---

Pages CMS liest diese Dateien und präsentiert sie in einer benutzerfreundlichen Oberfläche. Unser Content-Team kann:

1. Neuen Content erstellen über einen webbasierten Editor mit Live-Vorschau
2. Bestehenden Content bearbeiten mit einem Rich-Text-Editor, der sauberes Markdown ausgibt
3. Medien verwalten durch Hochladen von Bildern, die in unserem Repository gespeichert werden
4. Änderungen überprüfen durch ein eingebautes Workflow-System mit Draft/Published-Status

Pages CMS speichert jede Bearbeitung als Commit im Branch, der gerade im Editor geöffnet ist, die Inhaltshistorie liegt also neben dem Code in Git. Arbeiten die Redakteure auf einem anderen Branch als main, gelangen ihre Änderungen per Pull Request in die Produktion. Das bedeutet:

• Alle Änderungen durchlaufen unseren normalen Code-Review-Prozess
• Wir können automatisierte Tests auf Content-Änderungen ausführen
• Ich habe ein vollständiges Audit jeder Änderung
• Wir können Änderungen bei Bedarf zurückrollen
• Wir können Content-Updates unabhängig von Code-Änderungen bereitstellen

Ich habe auch benutzerdefinierte Validierungsregeln implementiert, um die Content-Qualität zu gewährleisten. Zum Beispiel erfordern wir, dass alle Blog-Posts haben:

• Eine Mindestwortzahl von 500 Wörtern
• Mindestens ein Featured Image
• Richtige SEO-Metadaten
• Keine kaputten internen Links

Diese Validierungen laufen automatisch, wenn Content gespeichert wird, und bieten sofortiges Feedback für unser Content-Team.

Die Integration mit unserem Build-Prozess ist nahtlos. Wenn Content-Änderungen nach main gemergt werden, führt unsere CI/CD-Prozess automatisch aus:

1. Baut die Site mit dem neuen Content
2. Führt Barrierefreiheits- und Leistungstests aus
3. Stellt für die Produktion bereit
4. Invalidiert den CDN-Cache
5. Sendet Benachrichtigungen an relevante Teammitglieder

Dieser Git-basierte Ansatz hat transformiert, wie wir Content handhaben. Unser Marketing-Team kann jetzt Updates ohne Entwickler-Intervention vornehmen, während wir die volle Kontrolle über die technische Implementierung behalten.

#Pages CMS in einem Repository konfigurieren

Die gesamte Konfiguration von Pages CMS steht in einer Datei, .pages.yml, im Wurzelverzeichnis des Repositorys (Pages-CMS-Konfiguration). Pages CMS liest sie pro Repository und pro Branch, ein Feature-Branch kann also ein geändertes Inhaltsmodell mitbringen, ohne die Produktion zu berühren. Die Schlüssel der obersten Ebene sind media (wo Uploads gespeichert werden und welche URLs in den Inhalt geschrieben werden), content (die bearbeitbaren Collections und Einzeldateien), components (gemeinsame Felddefinitionen), settings und actions.

Zwei Einstellungen sollten Sie kennen, bevor das Team mit dem Bearbeiten beginnt. settings.content.merge steht standardmäßig auf false: Die Datei wird nur aus dem konfigurierten Schema neu geschrieben, alles außerhalb der Editor-Ausgabe fällt weg. Mit true führt Pages CMS die übermittelten Felder mit der bestehenden Datei zusammen und behält Schlüssel, die das Schema nicht kennt (Pages-CMS-Einstellungen). Fügen Build-Skripte eigene Frontmatter-Schlüssel hinzu, würde die Standardeinstellung sie bei der nächsten Bearbeitung löschen. settings.commit.templates legt die Commit-Nachrichten fest, mit Vorgaben wie “Update {path} (via Pages CMS)”, sodass sich Inhalts-Commits in git log leicht filtern lassen. Der Schlüssel actions fügt Buttons hinzu, die GitHub-Actions-Workflows aus .github/workflows/ starten, etwa ein Deployment oder einen Vorschau-Build. Pages CMS unterstützt nur GitHub und ist kostenlos und MIT-lizenziert, ob als gehostete Version, auf Vercel oder selbst betrieben (pagescms.org).

#Schema.org für Events und Organisationen

Ranking im Jahr 2026 erfordert mehr als nur Keywords. Sie brauchen Struktur.

Ich bin tief in die Schema.org-Implementierung eingestiegen. Ich habe eine benutzerdefinierte SchemaOrg.astro-Komponente gebaut, die dynamisch JSON-LD-strukturierte Daten für jede Seite generiert.

Was wir implementiert haben:

• Organisationsschema: Identifizierung von Openweb S.C. als Rechtseinheit.
• Event-Schema: Bereitstellung von Google mit präzisen Daten, Standort (PPNT Gdynia) und Ticket-Informationen.
• @id-Verknüpfung: Entscheidend verwenden wir @id-Referenzen, um “die Punkte zu verbinden” zwischen der Organisation und dem Event im Google Knowledge Graph.

Pro-Tipp: Verlassen Sie sich nicht auf Standard-SEO-Plugins, um alles zu erledigen. Die Anpassung Ihres Schemas zur Verknüpfung Ihrer Entitäten (z.B. Verknüpfung Ihres Events mit Ihrer Organisation über IDs) ist ein starkes Signal an Suchmaschinen darüber, wer Sie sind und was Sie tun.

#Welche Event-Eigenschaften Google für Rich Results zu Veranstaltungen verlangt

Die Google-Dokumentation zu Veranstaltungen (strukturierte Daten für Event) nennt drei Pflichteigenschaften: name, startDate im ISO-8601-Format mit Uhrzeit und location als Place mit name und vollständiger PostalAddress. Nur der Städtename als Adresse ist als nicht empfohlen markiert. Empfohlen sind description, endDate, eventStatus, image (Google empfiehlt 1920 px Breite, mindestens 720 px), offers, organizer und performer. In offers ist price der niedrigste verfügbare Ticketpreis inklusive Gebühren, 0 kennzeichnet eine kostenlose Veranstaltung.

Für eine Konferenz ist die Zuordnung direkt. In organizer wird die @id der Organisation aus den vorherigen Absätzen referenziert statt wiederholt, offers.url zeigt auf die Ticketseite, und performer kann die Speaker als Person-Einträge auflisten. Wird die Veranstaltung verschoben, dokumentiert Google previousStartDate für das alte Datum; es muss zusammen mit eventStatus auf EventRescheduled verwendet werden, und startDate enthält dann nur noch das neue Datum.

#Was ist eine llms.txt-Datei für KI-Modelle

Das ist mein Lieblingsteil. Die Suche ändert sich. Leute fragen ChatGPT und Perplexity so oft nach Events wie sie Google verwenden. Um sicherzustellen, dass diese KI-Systeme genaue Antworten über CMS Conf geben, haben wir die Site für sie optimiert.

Ich habe eine llms.txt-Datei im Stammverzeichnis unserer Site implementiert.

Denken Sie daran wie robots.txt, aber für LLMs. Es bietet eine strukturierte, kontextreiche Zusammenfassung der gesamten Konferenz, Redner, Daten, Tech-Stack, explizit formatiert für KI-Ingestion. Ich habe sogar ein benutzerdefiniertes Node.js-Skript (scripts/update-llm-txt.js) geschrieben, das zur Build-Zeit läuft, um unsere Metadaten zu scannen und diese Datei perfekt aktuell zu halten.

Das Ergebnis? Wenn eine KI unsere Site crawlt, muss sie nicht raten. Wir sagen ihr genau, was CMS Conf ist.

#Was in eine llms.txt-Datei gehört

Hinter dieser Datei steht der llms.txt-Vorschlag von Jeremy Howard, veröffentlicht am 3. September 2024 und im August 2026 als v2 überarbeitet (llmstxt.org). Der Vorschlag nennt die Datei llms.txt, mit “s”, und unter diesem Pfad antwortet cmsconf.com: /llms.txt liefert reinen Text und /llms.json liefert JSON, während /llm.txt eine HTML-Seite zurückgibt. Das Format ist Markdown in fester Reihenfolge:

1. Eine H1 mit dem Namen des Projekts oder der Website, das einzige Pflichtelement.
2. Ein Blockzitat mit einer kurzen Zusammenfassung.
3. Optionale Absätze oder Listen mit Details, ohne Überschriften.
4. Abschnitte unter H2-Überschriften, jeweils eine Linkliste in der Form [Name](url) mit optionalen Notizen.

Ein Abschnitt mit dem Titel “Optional” markiert Links, die ein Agent bei kürzerem Kontext überspringen kann. Die Datei von CMS Conf folgt diesem Aufbau: Die H1 lautet “CMS Conf 2026”, das Blockzitat beschreibt die Konferenz, und der Abschnitt “Project Information” listet Agenda, Ticketseite, Call for Papers und die rechtlichen Seiten. Der Vorschlag beschreibt llms.txt als Datei, die neben robots.txt und Sitemaps besteht, und nichts darin verpflichtet ein Modell oder eine Suchmaschine, sie zu lesen.

#Defekte Links in Astro vor dem Build prüfen

Schließlich haben wir die langweiligen Sachen automatisiert. Ich habe Pre-Build-Checks mit astro-link-validator eingerichtet, um sicherzustellen, dass wir nie einen kaputten Link ausliefern. Ich habe unsere Weiterleitungen in astro.config.mjs validiert, um Legacy-URLs graceful zu handhaben.

#Fazit

Der Bau der CMS Conf-Website ging nicht nur um Code; es ging um die Schaffung eines Systems, das unseren Nutzern (Geschwindigkeit), unserem Team (Wartbarkeit) und den Maschinen, die Leute uns finden helfen (SEO & KI), dient.

Wenn Sie eine content-reiche Site im Jahr 2026 bauen, empfehle ich dringend, sich diese Astro + Tailwind + Git-basierte CMS-Architektur anzusehen. Sie ist schlank, sie ist schnell und sie skaliert wunderschön.

Sehen Sie sich an: https://cmsconf.com/

Wir fangen gerade erst an. Bis dahin in Gdynia im November!

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

Mehr zur SEO- und GEO-Optimierung.

Eine Astro-Konferenzseite braucht weiterhin WordPress-KI-Integration, sobald das CMS hinter dem Schedule Assistenten beantwortet.