Opublikowałem artykuł ” zza kulis” o tym, jak buduję stronę CMS Conf 2026, a to znacznie więcej niż “tylko strona lądowania”.
W artykule opisuję:
- dlaczego wybrałem Astro 5 + Tailwind CSS 4 dla wydajności i łatwości utrzymania,
- jak używam Git-natywnego headless CMS (Pages CMS) zamiast tradycyjnego backendu,
- co zrobiłem wokół SEO, Schema.org i ustrukturyzowanych danych specyficznych dla wydarzeń,
- oraz jak przygotowuję stronę na wyszukiwanie wspierane przez AI, między innymi przez
llms.txt,llms.jsoni automatyczne aktualizacje podczas budowania strony.
To praktyczna historia o projektowaniu, architekturze frontendu, pracy nad treścią i optymalizacji zarówno dla wyszukiwarek, jak i modeli językowych, zbudowana przez mały, skoncentrowany zespół.
Jeśli interesują Cię nowoczesne strony konferencji, architektury statyczne czy SEO gotowe na AI, możesz uznać to za przydatne.
#Astro #TailwindCSS #SEO #LLMO #AISEO #HeadlessCMS #StaticSites #CMSConf
Jak zbudować stronę konferencji w Astro 5 i Tailwind 4
Mariusz Szatkowski Developer {WordPress | WooCommerce | AI | GEO | AEO | LLMO}
18 grudnia 2025
Kiedy zaczęłem planować obecność cyfrową dla CMS Conf 2026, wiedziełem, że standardowa ścieżka “motyw WordPress + wtyczki” nie wystarczy. Chciełem czegoś innego. Potrzebowałem strony, która nie będzie tylko broszurą, ale wysokowydajną platformą treści, szybką, łatwą w utrzymaniu i jawnie zaprojektowaną na erę AI.
Oto historia tego, jak ja stron internetowych, Agnieszka Palmowska, Maciek Palmowski i ja, zbudowałem fundamenty CMS Conf 2026 na nowoczesnym stosie, który dziś trafia w złoty środek web developmentu.
Wydajność strony w Astro 5 i Tailwind CSS 4
Wybrałem Astro 5 z jednego prostego powodu: wydajność to funkcja.
Domyślnie Astro wysyła zero JavaScript do klienta. Oznacza to, że moje strony ładują się natychmiast, co jest krytyczne dla użytkowników mobilnych sprawdzających harmonogram lub prelegentów na słabym wifi konferencji. Połączyłem to z Tailwind CSS 4 (przez nową wtyczkę Vite), co było objawieniem.
Zmierzyłem implementację w wielu narzędziach, jednym z nich był Google PageSpeed Insights i oto wyniki:
Wynik 100 osiągnięte
Ale pozwól, że wyjaśnię, co to oznacza w praktyce. Kiedy mówię o “zero JavaScript”, nie mówię tylko o mniejszych rozmiarach paczek. Mówię o fundamentalnej zmianie w podejściu do rozwoju web. Tradycyjne SPA (Single Page Applications) często wysyłają setki kilobajtów JavaScript tylko do renderowania tego, co mogłoby być prostą statyczną treścią. Astro odwraca ten model.
Oto jak to działa: Astro renderuje całą stronę do statycznego HTML w czasie budowania. Tylko “hydratuje” interaktywne komponenty, gdy jest to potrzebne, a nawet wtedy robi to inteligentnie. Jeśli masz komponent, który musi być interaktywny (jak menu nawigacyjny lub formularz), Astro może wyizolować tylko ten komponent i załadować JavaScript dla niego niezależnie, pozostawiając resztę strony jako lekki HTML.
To podejście daje nam najlepsze z obu światów: wydajność statycznych stron z interaktywnością nowoczesnych aplikacji web, gdy tego potrzebuję.
Wskazówka techniczna: Jeśli przechodzisz na Tailwind 4, użyj wtyczki @tailwindcss/vite. Kompiluje Twój CSS w milisekundach, co sprawia, że doświadczenie dewelopera jest niesamowicie szybkie. Zaimplementowałem również LightningCSS (oparty na Rust) do minifikacji i zbudowałem niestandardową wtyczkę Vite do preloadingu krytycznego CSS, eliminując niepokojący “flash of unstyled content” (FOUC).
Pozwól, że głębiej wejdę w moją konfigurację Tailwind CSS 4. Nowa wersja to silnik napisany od zera. Skanowanie plików pod kątem nazw klas w czasie budowania zostało, ale Tailwind 4 sam wykrywa źródła, więc tablica content z wersji 3 jest zbędna, a konfiguracja przeniosła się z JavaScriptu do CSS przez dyrektywę @theme. Oznacza to:
- Szybsze przebudowania: przyrostowe buildy, które nie kompilują nowego CSS, pomijają najdroższy krok, więc zmiana klasy jest widoczna od razu
- Mniejsze paczki: tylko klasy, które faktycznie występują w plikach źródłowych, trafiają do wyniku
Zaimplementowałem również niestandardowy system tokenów projektowych używając funkcji zmiennych CSS Tailwind. Pozwala to nam utrzymać spójność na całej stronie, jednocześnie zachowując elastyczność do nadpisywania wartości w razie potrzeby. Dla CMS Conf zdefiniowałem moją paletę kolorów, skalę typografii i system odstępów jako zmienne CSS, a następnie odwołałem się do nich w mojej konfiguracji Tailwind.
Moje optymalizacje wydajności na tym się nie skończyły. Zaimplementowałem:
- Wbudowanie krytycznego CSS dla treści powyżej zgięcia
- Lazy loading dla obrazów i iframe’ów
- Wskazówki zasobów (preconnect, prefetch, preload) dla zasobów zewnętrznych
- Service worker dla funkcjonalności offline
- Optymalizację CDN z automatyczną optymalizacją obrazów
Na jakiej wersji Astro działa strona CMS Conf w 2026
Ten artykuł opisuje build ze stanu z grudnia 2025, na Astro 5. Astro 5.0 ukazało się 3 grudnia 2024 (informacja o wydaniu Astro 5.0). Główne nowości to Content Layer, server islands, uproszczony prerendering (dawny tryb hybrid połączono z static), typowane zmienne środowiskowe przez astro:env oraz Vite 6. Dla serwisu z treścią najważniejsza jest Content Layer: zespół Astro podaje, że kolekcje budują się do 5 razy szybciej dla stron Markdown w dużych serwisach i do 2 razy szybciej dla MDX, a zużycie pamięci spada o 25 do 50%.
Od tamtej pory wyszły dwie kolejne wersje główne. Astro 6.0, wydane 10 marca 2026, wymaga Node 22 lub nowszego, przechodzi na Vite 7 i Zod 4 oraz dodaje wbudowane Fonts API, API do Content Security Policy i kolekcje treści na żywo (informacja o wydaniu Astro 6.0). Astro 7.0 pojawiło się 22 czerwca 2026: kompilator plików .astro przepisano w Rust, Markdown i MDX przechodzą przez nowy potok w Rust, a pod spodem pracuje Vite 8. Zespół Astro zmierzył w swoich benchmarkach buildy szybsze o 15 do 61% (informacja o wydaniu Astro 7.0). Daty publikacji w rejestrze npm zgadzają się z tymi wpisami. 15 października 2026 znacznik meta generator na cmsconf.com pokazywał Astro v7.1.1, więc strona produkcyjna jest już za wersją z tytułu tego artykułu. Przy aktualizacji istniejącego projektu obie informacje o wydaniu wskazują to samo polecenie: npx @astrojs/upgrade.
Jak zainstalować Tailwind CSS 4 w projekcie Astro
Tailwind CSS 4.0 ogłoszono 22 stycznia 2025 (ogłoszenie Tailwind CSS v4.0). Według ogłoszenia pełne buildy są do 5 razy szybsze, a przyrostowe ponad 100 razy szybsze i mierzone w mikrosekundach. Wśród głównych zmian wymieniono automatyczne wykrywanie plików z treścią, oficjalną wtyczkę Vite i konfigurację w CSS. Aktualna linia 4.x w npm to 4.3.
Oficjalny przewodnik (Install Tailwind CSS with Astro) ma cztery kroki po utworzeniu projektu Astro:
- Zainstaluj pakiety:
npm install tailwindcss @tailwindcss/vite. - Dodaj
tailwindcss()z@tailwindcss/vitedovite.pluginswastro.config.mjs. - Utwórz
src/styles/global.cssz linią@import "tailwindcss";. - Zaimportuj ten plik w layoucie lub na stronie i zacznij używać klas narzędziowych.
W tej konfiguracji nie ma pliku tailwind.config.js. Wartości motywu trafiają do bloku @theme w tym samym pliku CSS. Zanim wybierzesz wersję 4, sprawdź przeglądarki swoich użytkowników: strona zgodności podaje, że rdzeń frameworka wymaga Chrome 111, Safari 16.4 i Firefox 128, a przewodnik aktualizacji zaleca pozostanie przy v3.4, jeśli musisz obsługiwać starsze przeglądarki.
Pages CMS jako headless CMS oparty na Git
Wspólnym wąskim gardłem w projektach statycznych stron jest zarządzanie treścią. Deweloperzy uwielbiają Markdown; zespoły marketingowe… niekoniecznie.
Maciek rozwiązał to, integrując Pages CMS (https://pagescms.org). To genialny headless CMS, który działa bezpośrednio z Twoim repozytorium GitHub. Daje mojemu zespołowi treści przyjazny interfejs do zarządzania postami na blogu i profilami autorów, ale pod spodem to tylko zatwierdzanie zmian w moim repo.
Dlaczego to działa:
- Zero infrastruktury: Nie ma bazy danych do utrzymania, nie ma serwerów do łatania.
- Natywnie w Git: Każda zmiana treści uruchamia moją pipeline CI/CD, zapewniając, że nic się nie psuje.
- Koszt: Jest darmowy i otwartoźródłowy, na licencji MIT.
Ale pozwól, że wyjaśnię, jak faktycznie zaimplementowałem to w praktyce. Tradycyjny CMS zwykle wymaga osobnej bazy danych, systemu uwierzytelniania i warstwy API. To dodaje złożoność, koszt i potencjalne luki w bezpieczeństwie. Pages CMS przyjmuje całkowicie inne podejście.
Oto moja konfiguracja: Stworzyłem dedykowany katalog content w moim repozytorium z klarownymi strukturami folderów dla różnych typów treści:
content/
├── blog/
│ ├── post-1.md
│ └── post-2.md
├── speakers/
│ ├── speaker-1.md
│ └── speaker-2.md
└── schedule/
├── day-1.md
└── day-2.mdKażdy plik Markdown zawiera sekcję frontmatter z ustrukturyzowanymi metadanymi:
---
title: "Budowanie Nowoczesnych Stron Konferencji"
author: "Mariusz Szatkowski"
date: "2025-12-18"
tags: ["astro", "tailwind", "cms"]
status: "published"
featured: true
---Pages CMS czyta te pliki i prezentuje je w przyjaznym interfejsie. Ja treści może:
- Tworzyć nową treść przez webowy edytor z podglądem na żywo
- Edytować istniejącą treść w edytorze rich text, który zapisuje czysty Markdown
- Zarządzać mediami, przesyłając obrazy, które trafiają do mojego repozytorium
- Recenzować zmiany przez wbudowany proces ze stanami draft/published
Pages CMS zapisuje każdą edycję jako commit w gałęzi otwartej w edytorze, więc historia treści żyje w Git obok kodu. Gdy redaktorzy pracują na gałęzi innej niż main, ich zmiany trafiają na produkcję przez pull request. Oznacza to:
- Wszystkie zmiany przechodzą przez mój normalny proces przeglądu kodu
- Mogę uruchamiać automatyczne testy na zmianach treści
- Mam pełny audyt każdej modyfikacji
- Mogę cofać zmiany w razie potrzeby
- Mogę wdrażać aktualizacje treści niezależnie od zmian w kodzie
Zaimplementowałem również niestandardowe reguły walidacji, aby zapewnić jakość treści. Na przykład, wymagam, aby wszystkie posty na blogu miały:
- Minimalną liczbę słów 500
- Co najmniej jeden wyróżniony obraz
- Właściwe metadane SEO
- Brak złamanych linków wewnętrznych
Te walidacje uruchamiają się automatycznie podczas zapisywania treści, zapewniając natychmiastową informację zwrotną dla mnie treści.
Integracja z moim procesem budowania jest bezproblemowa. Gdy zmiany treści są scalane z main, moja pipeline CI/CD automatycznie:
- Buduje stronę z nową treścią
- Uruchamia testy dostępności i wydajności
- Wdraża do produkcji
- Unieważnia pamięć podręczną CDN
- Wysyła powiadomienia do odpowiednich członków zespołu
To podejście oparte na Git przekształciło sposób, w jaki obsługuję treści. Ja marketingowy może teraz wprowadzać aktualizacje bez interwencji dewelopera, jednocześnie zachowując pełną kontrolę nad implementacją techniczną.
Jak skonfigurować Pages CMS w repozytorium
Cała konfiguracja Pages CMS mieści się w jednym pliku, .pages.yml, w katalogu głównym repozytorium (konfiguracja Pages CMS). Pages CMS czyta go osobno dla każdego repozytorium i każdej gałęzi, więc gałąź robocza może mieć zmieniony model treści bez ruszania produkcji. Klucze najwyższego poziomu to media (gdzie trafiają przesłane pliki i jakie adresy URL zapisują się w treści), content (edytowalne kolekcje i pojedyncze pliki), components (wspólne definicje pól), settings i actions.
Dwa ustawienia warto znać, zanim zespół zacznie edytować. settings.content.merge ma domyślnie wartość false, czyli plik jest przepisywany wyłącznie według skonfigurowanego schematu, a wszystko spoza danych z edytora znika. Przy true Pages CMS scala przesłane pola z istniejącym plikiem i zachowuje klucze, których schemat nie definiuje (ustawienia Pages CMS). Jeśli skrypty builda dopisują do frontmattera własne klucze, ustawienie domyślne usunie je przy najbliższej edycji. settings.commit.templates określa treść commitów, z domyślnymi wzorami w rodzaju “Update {path} (via Pages CMS)”, dzięki czemu commity z treścią łatwo odfiltrować w git log. Klucz actions dodaje przyciski uruchamiające workflowy GitHub Actions z katalogu .github/workflows/, na przykład wdrożenie albo build podglądu. Pages CMS obsługuje tylko GitHub. Jest darmowy i na licencji MIT, niezależnie od tego, czy korzystasz z wersji hostowanej, wdrażasz go na Vercel, czy uruchamiasz na własnym serwerze (pagescms.org).
Schema.org dla wydarzenia i organizacji
Ranking w 2026 wymaga więcej niż tylko słów kluczowych. Potrzebujesz struktury.
Poszłem głęboko w implementację Schema.org. Zbudowałem niestandardowy komponent SchemaOrg.astro, który dynamicznie generuje ustrukturyzowane dane JSON-LD dla każdej strony.
Co zaimplementowałem:
- Schema organizacji: Identyfikacja Openweb S.C. jako podmiotu prawnego.
- Schema wydarzenia: Przekazuje Google dokładne daty, lokalizację (PPNT Gdynia) i informacje o biletach.
- Łączenie @id: Kluczowo używam referencji @id do “połączenia kropek” między organizacją a wydarzeniem w Knowledge Graph Google.
Wskazówka pro: Nie polegaj na domyślnych wtyczkach SEO, aby robić wszystko. Dostosowywanie Twojego Schema do łączenia encji (np. łączenie Twojego wydarzenia z Twoją organizacją przez ID) to potężny sygnał dla wyszukiwarek o tym, kim jesteś i co robisz.
Jakich właściwości Event wymaga Google do wyników rozszerzonych wydarzeń
Dokumentacja Google o wydarzeniach (dane strukturalne Event) wymienia trzy właściwości wymagane: name, startDate w formacie ISO 8601 z godziną oraz location jako Place z polem name i pełnym adresem PostalAddress. Sama nazwa miasta w adresie jest oznaczona jako niezalecana. Zalecane właściwości to description, endDate, eventStatus, image (Google zaleca szerokość 1920 px, minimum 720 px), offers, organizer i performer. W offers pole price to najniższa dostępna cena biletu wraz z opłatami, a 0 oznacza wydarzenie bezpłatne.
W przypadku konferencji przełożenie jest bezpośrednie. W organizer odwołujesz się do @id organizacji z poprzednich akapitów zamiast powtarzać jej dane, offers.url prowadzi do strony z biletami, a performer może wymieniać prelegentów jako obiekty Person. Gdy wydarzenie zmienia termin, Google opisuje pole previousStartDate na starą datę. Trzeba go użyć razem z eventStatus ustawionym na EventRescheduled, a startDate zawiera wtedy wyłącznie nowy termin.
Czym jest plik llms.txt dla modeli AI
To moja ulubiona część. Wyszukiwanie się zmienia. Ludzie pytają ChatGPT i Perplexity o wydarzenia tak często, jak używają Google. Aby zapewnić, że te systemy AI dają dokładne odpowiedzi o CMS Conf, zoptymalizowałem stronę dla nich.
Zaimplementowałem plik llms.txt w głównym katalogu mojej strony.
Pomyśl o tym jak robots.txt, ale dla LLM. Zapewnia ustrukturyzowane, bogate w kontekst podsumowanie całej konferencji, prelegentów, dat, stosu technologicznego, jawnie sformatowane do ingestii przez AI. Napisałem nawet niestandardowy skrypt Node.js (scripts/update-llm-txt.js), który uruchamia się w czasie budowania, aby skanować moje metadane i utrzymywać ten plik idealnie aktualnym.
Wynik? Kiedy AI skanuje moją stronę, nie musi zgadywać. Mówię mu dokładnie, czym jest CMS Conf.
Co powinien zawierać plik llms.txt
Za tym plikiem stoi propozycja llms.txt autorstwa Jeremy’ego Howarda, opublikowana 3 września 2024 i zaktualizowana do wersji v2 w sierpniu 2026 (llmstxt.org). Propozycja nazywa plik llms.txt, z literą “s”, i właśnie pod tą ścieżką odpowiada cmsconf.com: /llms.txt zwraca zwykły tekst, /llms.json zwraca JSON, a /llm.txt zwraca stronę HTML. Format to Markdown w ustalonej kolejności:
- Nagłówek H1 z nazwą projektu lub serwisu, jedyny wymagany element.
- Blok cytatu z krótkim podsumowaniem.
- Opcjonalne akapity lub listy z dodatkowymi szczegółami, bez nagłówków.
- Sekcje pod nagłówkami H2, każda z listą linków w postaci
[nazwa](url)i opcjonalnymi notatkami.
Sekcja zatytułowana “Optional” oznacza linki, które agent może pominąć, gdy potrzebuje krótszego kontekstu. Plik CMS Conf trzyma się tego układu: H1 to “CMS Conf 2026”, cytat opisuje konferencję, a sekcja “Project Information” wymienia agendę, stronę z biletami, call for papers i strony prawne. Propozycja opisuje llms.txt jako plik działający obok robots.txt i map witryny, a nic w niej nie zobowiązuje modelu ani wyszukiwarki do jego czytania.
Jak sprawdzić zepsute linki w Astro przed buildem
Wreszcie, zautomatyzowałem nudne rzeczy. Ustawiłem kontrolę pre-build astro-link-validator, aby zapewnić, że nigdy nie wysyłam złego linku. Zweryfikowałem moje przekierowania w astro.config.mjs, aby łagodnie obsługiwały dziedziczone URL.
Podsumowanie
Budowanie strony CMS Conf nie było tylko o kodzie; było o tworzeniu systemu, który służy moim użytkownikom (szybkość), mojemu zespołowi (zarządzalność) i maszynom, które pomagają ludziom nas znaleźć (SEO & AI).
Jeśli budujesz bogatą w treści stronę w 2026, polecam spojrzeć na tę architekturę Astro + Tailwind + opartą na Git CMS. Jest chuda, jest szybka i pięknie się skaluje.
Zobacz na: https://cmsconf.com/
Dopiero zaczynam. Do zobaczenia w Gdyni w listopadzie!
#WebDevelopment #AstroJS #TailwindCSS #SEO #AI #CMSConf2026 #TechStack
Zobacz moje usługi optymalizacji SEO i widoczności, jeśli chcesz uporządkować ten obszar w swoim projekcie.
Strona konferencji na Astro nadal potrzebuje integracji AI z WordPressem, gdy CMS za harmonogramem zaczyna odpowiadać asystentom.







