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 KI-first Zukunft der Suche vorbereiten mit Dingen wie llm.txt, llm.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
Entwicklung einer Konferenz-Website im Jahr 2026: Warum wir uns für Astro 5, Tailwind 4 und einen KI-first-Ansatz entschieden haben
Mariusz Szatkowski Developer {WordPress | WooCommerce | AI | GEO | AEO | LLMO}
- 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.
1. Geschwindigkeit als Standard: Astro 5 & Tailwind CSS 4
Wir haben 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.
Wir haben die Implementierung in vielen Tools gemessen, eines davon war Google PageSpeed Insights und hier sind die Ergebnisse:
Artikelinhalt 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. Wir haben 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 führt eine völlig neue Architektur ein. Anstatt Ihrer Dateien nach Klassennamen zur Build-Zeit zu scannen, verwendet Tailwind 4 CSS-in-JS mit dem Vite-Plugin, um Stile on-the-fly zu generieren. Das bedeutet:
- Sofortige HMR: Wenn Sie eine Klasse ändern, aktualisiert sich das CSS sofort ohne vollständigen Neubau
- Kleinere Bundles: Nur die Klassen, die Sie tatsächlich verwenden, sind enthalten
- Bessere TypeScript-Unterstützung: Vollständige Autovervollständigung und Typ-Prüfung für Utility-Klassen
Wir haben 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
Das Ergebnis? Unser Largest Contentful Paint (LCP) liegt unter 1,5 Sekunden bei 3G-Verbindungen, und unsere Site erzielt 100 in allen Core Web Vitals.
2. Das Team befähigen: Pages 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-Pipeline aus und stellt sicher, dass nichts kaputt geht.
- Kosten: Es ist kostenlos für öffentliche Repositories.
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: Wir haben 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.mdJede 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:
- Neuen Content erstellen über einen webbasierten Editor mit Live-Vorschau
- Bestehenden Content bearbeiten mit einem Rich-Text-Editor, der sauberes Markdown ausgibt
- Medien verwalten durch Hochladen von Bildern, die automatisch optimiert und in unserem Repository gespeichert werden
- Änderungen überprüfen durch ein eingebautes Workflow-System mit Draft/Published-Status
- Zusammenarbeiten mit Kommentaren und Vorschlägen direkt im CMS
Die Schönheit dieses Ansatzes besteht darin, dass wenn jemand eine Änderung in Pages CMS vornimmt, es einen Pull Request in unserem GitHub-Repository erstellt. Das bedeutet:
- Alle Änderungen durchlaufen unseren normalen Code-Review-Prozess
- Wir können automatisierte Tests auf Content-Änderungen ausführen
- Wir haben 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
Wir haben 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-Pipeline automatisch aus:
- Baut die Site mit dem neuen Content
- Führt Barrierefreiheits- und Leistungstests aus
- Stellt für die Produktion bereit
- Invalidiert den CDN-Cache
- 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.
3. Die “unsichtbare” Arbeit: Erweitertes SEO & Schema
Ranking im Jahr 2026 erfordert mehr als nur Keywords. Sie brauchen Struktur.
Wir sind tief in die Schema.org-Implementierung eingestiegen. Wir haben 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.
4. Optimierung für das KI-Zeitalter (LLM)
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.
Wir haben eine llm.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. Wir haben 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.
5. Automatisierte Qualitätskontrolle
Schließlich haben wir die langweiligen Sachen automatisiert. Wir haben Pre-Build-Checks mit astro-link-validator eingerichtet, um sicherzustellen, dass wir nie einen kaputten Link ausliefern. Wir haben unsere Weiterleitungen in astro.config.mjs validiert, um Legacy-URLs graceful zu handhaben.
Das 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
