Strona internetowa w Astro: przewodnik dla firm (2026)

Kilka razy w roku słyszę od klienta to samo zdanie, tylko innymi słowami: „Chcę stronę, która nie wysypie się po kolejnej aktualizacji wtyczki i nie będzie się ładować pięć sekund na telefonie”. Coraz częściej odpowiadam na to jednym słowem: Astro.

Nie dlatego, że to modne. Na naszym firmowym GitHubie jest dziś dziesięć projektów zbudowanych na Astro: moja strona, strona agencji Kaminski.link, strony usługowe klientów, blogi tematyczne i mały sklep internetowy z koszykiem i kontami klientów. Najstarsze stoją na Astro 5, najnowszy na Astro 7. Panele i aplikacje z logowaniem robimy w czymś innym, i o tym też napiszę, bo uczciwa odpowiedź na pytanie „czy Astro” brzmi czasem „nie”.

Ten tekst jest długi, bo temat jest szeroki. Jeśli prowadzisz firmę i zastanawiasz się, czy zamówić stronę w Astro, przeczytaj rozdziały o tym, kiedy to ma sens, o CMS-ie, kosztach i migracji. Jeśli jesteś osobą techniczną po stronie klienta albo developerem, który chce zobaczyć, jak wygląda to w produkcji, a nie w tutorialu, znajdziesz tu też konfigurację, błędy, które sam popełniłem, i rzeczy, o których dokumentacja mówi szeptem.

Czym jest Astro i co się w nim zmieniło w 2026 roku

Astro (astro.build) to framework do budowania stron, w których najważniejsza jest treść: stron firmowych, usługowych, blogów, baz wiedzy, landing page'y. Jego podstawowe założenie jest proste: przeglądarka dostaje gotowy HTML, a JavaScript trafia tylko tam, gdzie naprawdę coś musi się ruszać. Menu mobilne, kalkulator, formularz z walidacją. Reszta to zwykły dokument, który wyświetla się od razu.

Brzmi jak powrót do stron z 2005 roku i trochę tak jest, tylko z narzędziami z 2026. Piszesz komponenty, masz TypeScript, możesz wstawić komponent Reacta, Vue albo Svelte tam, gdzie go potrzebujesz. Na końcu i tak wychodzi lekki HTML.

W 2026 roku wydarzyło się wokół Astro więcej niż przez dwa wcześniejsze lata:

16 stycznia 2026 roku zespół Astro dołączył do Cloudflare. Framework został na licencji MIT, z otwartym kodem i publiczną roadmapą, a twórcy zapowiedzieli, że dalej będzie wspierał wdrożenia na dowolnej platformie, nie tylko na Cloudflare.
10 marca 2026 wyszło Astro 6: nowy serwer deweloperski oparty na Environment API Vite (lokalnie działa ten sam runtime co na produkcji), wbudowane API do fontów, stabilne Content Security Policy i stabilne Live Content Collections, czyli treści pobierane w momencie wejścia na stronę, bez przebudowy.
22 czerwca 2026 wyszło Astro 7: kompilator przepisany z Go na Rust, przetwarzanie Markdown i MDX też w Rust, Vite 8 z bundlerem Rolldown. Według benchmarków zespołu buildy są szybsze o 15–61%. Do tego stabilne cache'owanie tras i tzw. advanced routing, czyli pełna kontrola nad tym, jak żądanie przechodzi przez aplikację.
We wrześniu wyszło Astro 7.3, a 28 września Cloudflare wypuścił EmDash 1.0, otwarty CMS zbudowany na Astro. Wrócę do niego przy CMS-ach.

Dla właściciela firmy najważniejsza z tych informacji jest jedna: za Astro stoi teraz duża, notowana na giełdzie firma, która ma interes w tym, żeby ten framework żył. Kiedy wybierasz technologię na pięć lat, to ma znaczenie. Astro przestało być ciekawostką dla developerów. W ankiecie State of JavaScript 2025 miało najwyższą satysfakcję użytkowników wśród meta-frameworków, a liczba tygodniowych pobrań z npm urosła w 2025 roku z około 360 tysięcy do ponad 900 tysięcy.

Jak Astro renderuje stronę, wytłumaczone bez żargonu

To jest rozdział, który najczęściej tłumaczę klientom na spotkaniu, bo od niego zależy cała reszta: koszt hostingu, bezpieczeństwo, szybkość i to, co da się na stronie zrobić.

Każda podstrona w Astro może działać w jednym z trzech trybów.

Prerenderowana (statyczna). Strona generuje się raz, przy publikacji. Na serwer trafia gotowy plik HTML. Gdy ktoś wchodzi, CDN po prostu go wysyła, bez bazy danych i bez liczenia czegokolwiek. Tak powinna działać większość stron firmowych: oferta, o nas, realizacje, artykuły.

Renderowana na żądanie (SSR). Strona składa się w momencie wejścia, na serwerze albo na edge'u. Potrzebne tam, gdzie treść zależy od użytkownika albo zmienia się co chwilę: koszyk, konto klienta, wyniki wyszukiwania.

Wyspy serwerowe (server islands). Hybryda, którą bardzo lubię. Cała strona jest statyczna i błyskawiczna, a jeden fragment, np. „dostępne terminy w tym tygodniu” albo cena przeliczona dla zalogowanego klienta, dociąga się osobno. Reszta strony nie czeka na ten fragment.

Do tego dochodzą wyspy po stronie przeglądarki, czyli komponenty interaktywne. Tu Astro daje kontrolę, której brakuje w większości stron: decydujesz, kiedy komponent ma się „obudzić”. Od razu, gdy przeglądarka będzie bezczynna, albo dopiero gdy użytkownik do niego przewinie.

---
import Kalkulator from '../components/Kalkulator.tsx';
import Terminy from '../components/Terminy.astro';
---
<!-- reszta strony to czysty HTML -->
<Kalkulator client:visible />

<Terminy server:defer>
  <p slot="fallback">Sprawdzam wolne terminy…</p>
</Terminy>

W praktyce to wygląda tak: strona usługowa jest prerenderowana, kalkulator wyceny ładuje swój JavaScript dopiero wtedy, gdy ktoś do niego dojedzie, a moduł z terminami dociąga się z serwera. Strona główna nie płaci za nic z tego.

Ważne: tryb ustawiasz per podstrona, nie dla całego serwisu. Możesz mieć projekt, który domyślnie renderuje się na serwerze, a wybrane strony prerenderować jedną linijką (export const prerender = true), albo odwrotnie: statyczny serwis z pojedynczymi trasami dynamicznymi. Strona Kaminski.link działa w trybie serwerowym, większość stron klientów jest statyczna. Dobór tych proporcji to jedna z pierwszych decyzji w projekcie i jedna z tych, które najbardziej wpływają na późniejsze koszty.

Kiedy Astro to dobry wybór, a kiedy go odradzam

Najwięcej szkody w branży robią wykonawcy, którzy wszystko robią w jednej technologii, bo tylko ją znają. Agencja od WordPressa poleci WordPressa, agencja od Next.js poleci Next.js. Ja mam w portfolio wszystkie trzy podejścia i tak dzielę projekty.

Astro biorę, kiedy:

to strona firmowa albo usługowa, gdzie liczy się szybkość, SEO i to, żeby oferta była czytelna,
strona ma dużo treści: blog, poradnik, bazę wiedzy, słowniczek, setki artykułów,
potrzebujesz wielu podobnych podstron opartych o dane: strony lokalne dla miast, katalog usług, karty produktów, realizacje,
strona ma być wielojęzyczna i ma to działać porządnie, z hreflangami i sensownymi adresami,
to landing page pod kampanię, gdzie każda dziesiąta sekundy ładowania przekłada się na koszt pozyskania klienta,
klient ma dość aktualizowania wtyczek, łatania dziur i płacenia za hosting, który „musi być mocny, bo WordPress”.

Astro odradzam, kiedy:

budujesz aplikację: panel klienta, system rezerwacji z rozbudowaną logiką, SaaS, dashboard. Tu robimy Next.js albo dedykowany backend. Astro da radę, ale będziesz walczyć z frameworkiem, zamiast korzystać z jego mocnych stron,
w firmie jest osoba, która lubi sama „klikać” stronę w wizualnym builderze typu Elementor i przestawiać sekcje bez developera. Da się zbliżyć do tego doświadczenia, ale to inna filozofia i trzeba to powiedzieć przed startem, a nie po,
potrzebujesz dużego sklepu z tysiącami produktów, integracjami magazynowymi, marketplace'ami i dziesiątkami metod dostawy. Gotowa platforma e-commerce zrobi to taniej. Mały sklep w Astro zrobiliśmy i działa świetnie, ale to był świadomy wybór pod konkretny przypadek,
strona działa, zarabia, ma dobre wyniki i nikt w firmie nie ma z nią problemu. Wtedy migracja dla samej technologii to wyrzucanie pieniędzy.

Ostatni punkt mówię wprost na spotkaniach i tracę przez to część zleceń. Wolę to niż klienta, który po roku pyta, za co właściwie zapłacił.

Szybkość: co mówią dane, a nie marketing

Każda agencja „od Astro” pisze o wyniku 100 w PageSpeed. Wolę pokazać, co mówią dane z prawdziwych stron.

HTTP Archive publikuje raport Core Web Vitals według technologii, łączący dane z rzeczywistych wizyt użytkowników Chrome (CrUX) z danymi o tym, na czym strony są zbudowane. W zestawieniu opisanym w maju 2026 przez Search Engine Journal Astro miało najlżejszą medianę wagi strony ze wszystkich porównywanych platform: około 1,65 MB, przy około 2,76 MB dla WordPressa. Dobre Core Web Vitals miało około 67% stron na Astro i około 49% stron na WordPressie, który był na ostatnim miejscu.

Zwróć uwagę na jedną rzecz, o której „astrowe” agencje nie piszą: Astro nie było w tym zestawieniu pierwsze. Wyżej były zamknięte platformy typu Duda, Wix i Shopify. Dlaczego? Bo tam dostawca kontroluje cały stos i użytkownik nie ma jak go zepsuć. W Astro możesz zbudować stronę, która ładuje się w pół sekundy, i możesz zbudować taką, która ładuje się trzy. Framework daje dobry punkt startu. Wynik zależy od wykonawcy.

Przypomnę progi, bo często są mylone. Google ocenia Core Web Vitals na podstawie danych od prawdziwych użytkowników, na 75. percentylu wizyt:

LCP (jak szybko pojawia się główna treść): dobrze do 2,5 s,
INP (jak szybko strona reaguje na kliknięcie): dobrze do 200 ms,
CLS (czy elementy nie skaczą podczas ładowania): dobrze do 0,1.

Wynik Lighthouse w zakładce przeglądarki to test laboratoryjny. Ładny, ale to nie on decyduje. Strona agencji Kaminski.link ma w Lighthouse na mobile wynik 86–91, a nie 100. Nie gonię punktów w Lighthouse. Gonię progi Core Web Vitals w danych od prawdziwych użytkowników i pilnuję, żeby każdy skrypt na stronie miał uzasadnienie biznesowe. Analityka, baner zgody na cookies czy font firmowy kosztują kilka punktów i zwykle są tego warte.

Co najczęściej psuje szybkość strony w Astro:

Skrypty zewnętrzne. Menedżer tagów, piksel, czat, mapa, widget opinii. Każdy z nich potrafi dołożyć więcej JavaScriptu niż cała Twoja strona. Astro tu nie pomoże, bo to nie jest jego kod. Pomaga dyscyplina: ładowanie po interakcji, po zgodzie, albo wcale.
Komponenty „budzone” na siłę. Developer przyzwyczajony do Reacta wrzuca cały nagłówek jako komponent z client:load i nagle strona wysyła 150 KB JavaScriptu, żeby otworzyć menu. Menu mobilne da się zrobić w kilkunastu linijkach zwykłego skryptu.
Obrazy wrzucone do folderu public/. Pliki z tego folderu idą na serwer bez żadnej optymalizacji. Obrazy importowane przez komponenty <Image /> i <Picture /> Astro zamienia na AVIF/WebP, generuje rozmiary i atrybuty srcset. Od wersji 5.10 jest stabilna opcja layout, która robi responsywność za Ciebie.
Fonty. Trzy rodziny, każda w pięciu grubościach, ładowane z zewnętrznego serwera. Od Astro 6 jest wbudowane Fonts API, które pobiera fonty, hostuje je lokalnie, generuje fallbacki i preloady. To też kwestia RODO, bo font z serwerów Google ładowany bez zgody to temat, który wraca co jakiś czas.

Architektura treści: niedoceniana przewaga Astro

Gdybym miał wskazać jedną rzecz, dla której wybieram Astro do stron treściowych, nie byłaby to szybkość. Byłyby to Content Collections.

W skrócie: każdy typ treści na stronie (artykuł, usługa, miasto, realizacja, osoba z zespołu) ma zdefiniowany schemat. Jakie pola są wymagane, jakiego typu, jakie wartości są dozwolone. Jeśli ktoś doda artykuł bez opisu meta albo z literówką w kategorii, strona się nie zbuduje. Błąd wychodzi przed publikacją, a nie w Search Console po trzech tygodniach.

Uproszczony fragment podobny do tego, którego używamy na stronie agencji:

// src/content.config.ts
import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';

const uslugi = defineCollection({
  loader: glob({ pattern: '*/index.mdoc', base: 'src/content/uslugi' }),
  schema: z.object({
    title: z.string(),
    metaTitle: z.string().max(60),
    description: z.string().min(70).max(160),
    noindex: z.boolean().default(false),
    locale: z.enum(['pl', 'en']).default('pl'),
    alternateSlug: z.string().optional(), // adres wersji w drugim języku
  }),
});

export const collections = { uslugi };

Z punktu widzenia SEO to jest ogromna różnica. Długość meta description pilnuje kod, nie pamięć copywritera. Każda strona ma pole noindex, więc decyzja „czy ta strona ma być w Google” jest zapisana przy treści, a nie zakopana w ustawieniach wtyczki. A pole alternateSlug rozwiązuje problem, który kosztował mnie kiedyś ponad dwieście błędnych linków. Opiszę go w rozdziale o SEO.

Uwaga na strony generowane z danych. Astro bardzo ułatwia tworzenie wielu podobnych podstron: jeden szablon, lista miast, gotowe. I tu jest pułapka, w którą sam wpadłem na stronie agencji. Audyt pokazał, że nasze strony miast pokrywały się treścią w niemal połowie. Zmieniona nazwa miejscowości i dwa akapity to dla Google nie są osobne, wartościowe strony. Framework zrobi Ci sto podstron w minutę. Nie zrobi za Ciebie stu powodów, dla których każda z nich ma istnieć. Dlatego dziś przy stronach lokalnych zaczynam od pytania, jakie unikalne dane mam dla danego miasta: realizacje, opinie, dojazd, specyfika lokalnego rynku. Jeśli nie mam nic, strona nie powstaje.

Jak klient edytuje treść: wybór CMS-a

To pytanie zadaje każdy klient i ma rację, bo od odpowiedzi zależy, czy strona będzie żyła, czy zamrze po wdrożeniu. Astro nie ma wbudowanego panelu jak WordPress. Panel podpina się osobno, i to jest zaleta, bo można go dobrać do ludzi, którzy będą go używać.

Opcje, z których korzystam albo które realnie rozważam:

Pliki Markdown w repozytorium. Treść leży w plikach obok kodu, zmiany przez Git. Idealne dla stron developerów, dokumentacji i firm, gdzie treść zmienia się raz na kwartał i zmienia ją developer. Dla przeciętnego klienta: nie.

Keystatic. Nasz domyślny wybór dla stron firmowych. Panel działa w przeglądarce, pod adresem strony, a zapis robi commit do repozytorium na GitHubie. Nie ma osobnej bazy danych, nie ma abonamentu, treść zostaje u klienta w plikach. Używamy go w większości projektów, w tym na stronie agencji. Dwie uwagi z praktyki: README projektu od lat nazywa go „eksperymentalnym”, a w lipcu 2026 wyszła linia 0.6, która zmieniła zależności. Wersje trzeba przypinać na sztywno i aktualizować świadomie, a nie odruchowo.

Sanity. Hostowany headless CMS z bardzo dobrym edytorem, podglądem i rolami. Sprawdza się, gdy treści jest dużo, publikuje kilka osób albo ta sama treść idzie na stronę, do newslettera i do aplikacji. Darmowy plan wystarcza wielu firmom. Przy większym zespole trzeba policzyć koszt miejsc.

Storyblok i podobne CMS-y wizualne. Najbliżej doświadczenia „klikam i widzę, co zmieniam”. Dobre dla działów marketingu, które chcą składać landing page z bloków. Droższe, więc liczę je tylko wtedy, gdy klient naprawdę z tego skorzysta.

WordPress jako panel (headless). Czasem klient zna WordPressa i nie chce się przestawiać. Wtedy WordPress zostaje tylko panelem do pisania, a stronę generuje Astro. Live Content Collections z Astro 6 ułatwiają to, bo treść może się aktualizować bez przebudowy. Minus: dalej trzeba utrzymywać WordPressa, choć schowanego i dużo bezpieczniejszego.

EmDash. Nowy, otwarty CMS od Cloudflare zbudowany na Astro, wersja 1.0 z 28 września 2026. Ma rejestr wtyczek z izolacją, serwer MCP dla agentów AI i od lipca działa na nim blog Cloudflare. Wygląda obiecująco i na pewno go przetestuję. Ale na stronę klienta, która ma działać latami, nie wkładam produktu, który ma tydzień. Za pół roku wrócę do tego akapitu.

Moja zasada przy wyborze jest jedna: CMS dobieram do osoby, która będzie go używać, a nie do developera, który go wdraża. Pytam, kto w firmie będzie dodawał treści, jak często, czy potrzebuje podglądu przed publikacją, czy ktoś musi to zatwierdzić i czy strona ma wersje językowe. Dopiero z tych odpowiedzi wychodzi narzędzie.

SEO techniczne w Astro: lista rzeczy, które sprawdzam w każdym projekcie

Astro jest dobre dla SEO z założenia, bo wyszukiwarka dostaje gotowy HTML z treścią, a nie pustą stronę czekającą na JavaScript. To samo dotyczy systemów AI, które czytają strony, żeby odpowiadać na pytania. Pisałem o tym osobno przy pozycjonowaniu pod ChatGPT i AI Overviews. Ale „dobre z założenia” nie znaczy „zrobione”. Oto lista, którą przechodzę przy każdym wdrożeniu.

1. Jeden kanoniczny adres każdej strony. W konfiguracji ustawiam site i decyduję o końcowym ukośniku (trailingSlash). Na stronie agencji mamy always, na stronie jednego z klientów never. Obie decyzje są dobre, pod warunkiem że wersja bez ukośnika (albo z nim) przekierowuje 301 na właściwą, tag canonical wskazuje to samo, a mapa strony też. Najgorszy wariant to oba adresy odpowiadające kodem 200.

2. Mapa strony, która nie zawiera śmieci. Integracja @astrojs/sitemap domyślnie wrzuca wszystko, co się zbudowało. Ja odfiltrowuję wyszukiwarkę i kolejne strony paginacji, a strony oznaczone noindex w ogóle nie powinny tam trafić. Przykład z jednego z naszych projektów:

sitemap({
  filter: (page) => {
    const { pathname } = new URL(page);
    const last = pathname.split('/').filter(Boolean).at(-1);
    const isPagination = pathname.startsWith('/blog/') && Number.isInteger(Number(last));
    return pathname !== '/szukaj' && !isPagination;
  },
}),

Druga rzecz, na którą trafiłem w audycie: w mapie strony były adresy, które już przekierowywały gdzie indziej. Google dostawał sprzeczny sygnał: „zaindeksuj to”, a pod adresem przekierowanie. Dziś generator mapy strony pomija adresy z listy przekierowań, więc ten błąd nie ma jak wrócić.

3. Wielojęzyczność i przełącznik języka. Astro ma wbudowany routing i18n. Najczęściej ustawiam polski jako domyślny bez prefiksu w adresie (prefixDefaultLocale: false), a pozostałe języki z prefiksem, np. /en/. Pułapka, na którą sam wpadłem: przełącznik języka budował adres wersji angielskiej jako /en/ plus polski slug. Strona „/ile-kosztuje-strona/” dostawała link do „/en/ile-kosztuje-strona/”, który nie istnieje. Pomnóż to przez każdą podstronę i każdy wpis na blogu. W audycie wyszło ponad dwieście wewnętrznych linków prowadzących do błędu 404, w dużej części właśnie przez przełącznik. Rozwiązanie: odpowiednik w drugim języku zapisany w treści (pole alternateSlug ze schematu wyżej), a przełącznik bierze adres z danych, nie skleja go sam. Do tego hreflangi w nagłówku i w mapie strony, którą integracja sitemap potrafi wygenerować z alternatywnymi wersjami językowymi.

4. Przekierowania pod kontrolą. Przy migracjach i porządkowaniu struktury przekierowań jest dużo. Na Cloudflare trzymamy je w pliku _redirects, a Astro ma też własną opcję redirects w konfiguracji. Lekcja z życia: reguła przekierowania potrafi przykryć istniejącą stronę. U nas jedna stara reguła odsyłała adres podstrony usługowej do kategorii bloga, choć sama podstrona normalnie istniała w projekcie. Nikt tego nie widział, bo strona „działała”. Dlatego po każdej większej zmianie przekierowań robię crawl całego serwisu i sprawdzam każdy wewnętrzny link.

5. Dane strukturalne. JSON-LD generowany w layoucie z tych samych danych, co treść: Organization albo LocalBusiness na stronie głównej, Article z autorem i datami na wpisach, BreadcrumbList wszędzie, FAQPage tam, gdzie jest sekcja pytań. Skoro treść ma schemat, dane strukturalne przestają być ręczną robotą.

6. Obrazki Open Graph. Generuję je statycznie przy buildzie, dla każdej strony osobno. Link wklejony na Facebooku czy LinkedInie ma wtedy własną grafikę z tytułem, a nie logo w złym kadrze.

7. Prawdziwy kod 404. Strona błędu ma zwracać status 404, a nie 200 z napisem „nie znaleziono”. W Astro wystarczy plik 404.astro, ale przy niestandardowych konfiguracjach hostingu sprawdzam to narzędziem, a nie okiem.

Bezpieczeństwo: „statyczny HTML nie ma luk” to tylko połowa prawdy

Kiedyś sam pisałem, że statyczna strona nie ma luk bezpieczeństwa. W wersji czysto statycznej to prawie prawda: nie ma bazy danych do wstrzyknięcia zapytania, nie ma panelu do zgadywania hasła, nie ma wtyczek z dziurami. Powierzchnia ataku jest naprawdę mała.

Ale współczesna strona w Astro rzadko jest w stu procentach statyczna. Gdy pojawia się tryb serwerowy, pojawia się kod, który wykonuje się na serwerze, a z nim realne podatności. Przykład z tego roku: w kwietniu 2026 opublikowano podatność CVE-2026-41321 w adapterze Astro dla Cloudflare. Punkt końcowy do przetwarzania obrazów podążał za przekierowaniami i dało się go wykorzystać do zapytań do adresów spoza dozwolonej listy (atak typu SSRF). Była to zresztą niepełna poprawka wcześniejszego, bardzo podobnego błędu w sąsiednim fragmencie kodu. Na stronie agencji nie używamy obrazów przetwarzanych w locie, więc ścieżkę /_image po prostu wyłączyliśmy z obsługi przez workera, a grafiki generujemy wcześniej, przy buildzie. Mniej kodu na serwerze to mniej miejsc, w które da się uderzyć.

Lekcja jest taka: przy stronie w Astro też trzeba śledzić komunikaty bezpieczeństwa i aktualizować zależności. Różnica polega na tym, że robi się to kilka razy w roku w kontrolowany sposób, a nie co tydzień w panelu z trzydziestoma wtyczkami.

Content Security Policy, czyli nagłówek, który potrafi wyłączyć Ci analitykę. CSP mówi przeglądarce, skąd strona może ładować skrypty i dokąd może wysyłać dane. To jedno z najlepszych zabezpieczeń przed wstrzyknięciem obcego kodu. Od Astro 6 jest stabilne API, które samo liczy skróty skryptów i stylów i składa nagłówek. My na stronie agencji generujemy politykę w middleware, z jednorazowym kluczem (nonce) dla każdego żądania.

I tu historia, którą opowiadam każdemu, kto wdraża CSP. Przez długie tygodnie Google Analytics 4 na stronie agencji pokazywał praktycznie zero odwiedzin. Strona działała, formularze działały, Search Console pokazywał kliknięcia z Google. Winna była polityka CSP: dopuszczała wysyłanie danych do domen *.google-analytics.com, ale GA4 wysyła dziś pomiary także na analytics.google.com i www.google.com. Przeglądarka grzecznie blokowała każde zdarzenie. Nikt nie widział błędu, bo błędy CSP widać tylko w konsoli deweloperskiej.

Wniosek: po każdej zmianie CSP otwieram stronę w przeglądarce, akceptuję cookies i sprawdzam w zakładce sieci, czy żądania do analityki i pikseli przechodzą. A dzień później zaglądam do GA4, czy dane w ogóle są. Bezpieczna strona bez danych o ruchu to strona, na której podejmujesz decyzje po omacku.

Formularze, integracje i elementy dynamiczne

Najczęstszy argument przeciwko Astro brzmi: „na WordPressie formularz kontaktowy to wtyczka i pięć minut”. To prawda. Na Astro to godzina pracy. Tyle że ta godzina daje formularz, nad którym masz pełną kontrolę.

Astro Actions (dostępne od wersji 4.15) to funkcje serwerowe z wbudowaną walidacją. Formularz HTML wysyła dane, akcja sprawdza je według schematu (poprawny e-mail, zaznaczona zgoda, wypełnione pole), a dopiero potem coś z nimi robi:

// src/actions/index.ts
import { defineAction } from 'astro:actions';
import { z } from 'astro/zod';

export const server = {
  zapytanie: defineAction({
    accept: 'form',
    input: z.object({
      imie: z.string().min(2),
      email: z.email(),
      wiadomosc: z.string().min(20),
      zgoda: z.boolean(),
    }),
    handler: async (dane) => {
      // wysyłka maila, zapis do CRM, powiadomienie na Slacku
    },
  }),
};

A co dalej robi się z tym zapytaniem, to już moja ulubiona część, bo na co dzień zajmuję się automatyzacją procesów. Zapytanie z formularza może od razu trafić do CRM-a z przypisanym handlowcem, wysłać klientowi potwierdzenie z terminem oddzwonienia, a zespołowi powiadomienie. Nie przez trzy wtyczki od trzech różnych autorów, tylko przez kilkadziesiąt linijek kodu albo webhook do narzędzia typu n8n. Mail wychodzi przez dostawcę poczty transakcyjnej, a nie przez funkcję mail() serwera, więc dużo rzadziej ląduje w spamie.

Sesje (stabilne od Astro 5.7) pozwalają przechowywać stan użytkownika między żądaniami: koszyk, zalogowanie, wybrany oddział firmy. Oficjalne adaptery, w tym ten dla Cloudflare, same konfigurują domyślny magazyn sesji.

Sklep w Astro? Zrobiliśmy mały sklep internetowy w całości na Astro w trybie serwerowym na Cloudflare: koszyk, rejestracja, logowanie, konto klienta, zamówienia, strony kategorii i produktów. Taki sklep ma sens, gdy katalog nie jest ogromny, zasady dostawy są proste, a klientowi zależy na szybkości i na tym, żeby nie płacić abonamentu za platformę. Przy kilku tysiącach produktów i integracji z hurtowniami wybrałbym inaczej. To dobry przykład tego, że granica „strona czy aplikacja” nie leży w technologii, tylko w skali i w tym, ile logiki biznesowej trzeba utrzymywać.

Hosting i koszty utrzymania strony w Astro

Statyczną stronę w Astro można hostować praktycznie wszędzie. My stawiamy na Cloudflare i nie chodzi tylko o to, że Astro jest teraz częścią tej firmy.

Kilka faktów, które warto znać, zanim ktoś zacznie opowiadać o „darmowym hostingu”:

Na Cloudflare Workers zapytania o pliki statyczne są bezpłatne i bez limitu. Jeśli strona jest w pełni prerenderowana, hosting naprawdę kosztuje zero złotych.
Zapytania obsługiwane przez kod serwerowy (SSR, formularze, wyspy serwerowe) w darmowym planie mają limit 100 tysięcy dziennie. Dla strony firmowej to zwykle dużo, ale przy sklepie albo stronie z dużym ruchem trzeba to policzyć.
Od marca 2026 oficjalny adapter Astro dla Cloudflare wspiera Workers, a nie Cloudflare Pages. Cloudflare zaleca Workers dla nowych projektów. Starsze projekty na Pages dalej działają, ale przy najbliższej większej aktualizacji trzeba zaplanować przeniesienie.
Nie musisz używać Cloudflare. Astro działa na Netlify, Vercelu i na zwykłym serwerze z Node.js. Na stronie jednego z klientów mamy konfigurację, w której ten sam kod buduje się pod Cloudflare albo pod Node, zależnie od środowiska. To dobre zabezpieczenie przed uzależnieniem od jednego dostawcy.

Rzeczy, które realnie kosztują w utrzymaniu: domena, poczta firmowa, ewentualnie płatny plan CMS-a, dostawca wysyłki maili przy większej liczbie formularzy, monitoring dostępności. I czas developera.

Brak aktualizacji wtyczek nie oznacza braku utrzymania. To najważniejszy akapit tego rozdziału. Astro rozwija się szybko. Od wersji 5 do 7 minęło około półtora roku i po drodze było sporo zmian, które trzeba przenieść do projektu: wymagany Node.js 22.12 lub nowszy, przejście na Zod 4, usunięcie starego API kolekcji i Astro.glob(), zmiany w adapterze Cloudflare. Nowy kompilator w Rust z Astro 7 jest bardziej rygorystyczny: niezamknięty tag HTML, który stary kompilator po cichu poprawiał, teraz wywraca build. Pakiet Astro DB został w wersji 7 usunięty, więc kto z niego korzystał, musi przejść na inne rozwiązanie, np. wbudowany w Node SQLite albo Drizzle.

Część naszych projektów, łącznie z tą stroną, wciąż działa na Astro 5 i działa dobrze, bo stara wersja nie przestaje nagle działać. Ale wiem, że przejście na 7 to kilka godzin pracy na projekt, a nie jedno kliknięcie. Dlatego w ofercie zawsze rozpisuję, co obejmuje opieka po wdrożeniu, i proponuję aktualizację do nowej wersji raz w roku, w zaplanowanym terminie, z testami. Dla klienta to przewidywalny, niewielki koszt zamiast awaryjnej naprawy, gdy coś przestanie działać.

Migracja z WordPressa do Astro bez utraty pozycji w Google

Pisałem już o tym, jak przeniosłem swoją stronę z WordPressa i co mnie po drodze zaskoczyło, w tekście o migracji z WordPressa na Jamstack. Tutaj skupię się na tym, co robię przy migracji strony klienta, gdzie stawką jest ruch z Google, na który ktoś pracował latami.

1. Inwentaryzacja adresów. Zanim powstanie pierwsza linijka kodu, zbieram wszystkie adresy starej strony: z mapy strony, z crawla, z Google Search Console (strony z wyświetleniami z ostatnich 16 miesięcy), z linków zewnętrznych. Często wychodzą adresy, o których klient nie wiedział: stare kampanie, załączniki PDF, tagi, archiwa autorów.

2. Decyzja dla każdego adresu. Zostaje bez zmian, zmienia adres z przekierowaniem 301 albo znika (i wtedy przekierowanie na najbliższy tematycznie odpowiednik, a nie hurtem na stronę główną). Jeśli tylko się da, zachowuję dotychczasowe adresy. Najlepsze przekierowanie to takie, które nie jest potrzebne.

3. Przeniesienie treści i danych. Treść z WordPressa wyciągam przez REST API i zamieniam na pliki albo wpisy w nowym CMS-ie. Razem z treścią przenoszę tytuły i opisy meta (z Yoasta czy Rank Matha), teksty alternatywne obrazków, daty publikacji i autorów. Treść, którą Google zna i lubi, nie powinna się zmienić przy okazji zmiany technologii. Na poprawianie tekstów jest czas po migracji, gdy widać, że pozycje się utrzymały.

4. Odtworzenie funkcji. Formularze, newsletter, kalkulatory, mapy, integracje. Każdą funkcję starej strony wypisuję na liście i każdą przy odbiorze sprawdzam. Najczęściej zapominana: przekierowania i skrypty dodane kiedyś przez wtyczkę, o której wszyscy zapomnieli.

5. Wersja testowa poza Google. Nowa strona działa pod adresem testowym, zabezpieczona przed indeksowaniem. Tam robię crawl, sprawdzam przekierowania z listy, dane strukturalne, Core Web Vitals, analitykę ze zgodą na cookies i CSP.

6. Przełączenie i obserwacja. Po publikacji: zgłoszenie nowej mapy strony w Search Console, sprawdzenie najważniejszych adresów narzędziem do inspekcji, a potem przez 4–8 tygodni obserwacja raportu indeksowania, błędów 404 i pozycji na kluczowe frazy. Lekkie wahania w pierwszych tygodniach są normalne. Trwały spadek oznacza, że coś poszło nie tak i trzeba to znaleźć, a nie czekać.

Migracja dobrze zrobiona jest nudna. Migracja źle zrobiona potrafi zabrać połowę ruchu na pół roku. Różnica w koszcie między nimi to zwykle kilka dni pracy przy inwentaryzacji i testach.

Ile kosztuje strona internetowa w Astro

Krótko: zwykle trochę więcej niż strona na gotowym motywie WordPressa i zwykle mniej w utrzymaniu przez kolejne lata. Różnica w cenie wynika z tego, że w Astro nie składa się strony z gotowych klocków, tylko się ją projektuje i koduje.

Ceny są takie same jak w konfiguratorze wyceny na Kaminski.link. Wszystkie kwoty są netto:

Landing page pod kampanię lub jedną usługę: od 1 990 zł, z CMS-em o 600 zł więcej.
Strona firmowa z CMS-em: od 3 900 zł za pięć podstron, każda kolejna podstrona to 250 zł.
Blog: 500 zł. Każda dodatkowa wersja językowa: 1 200 zł.
Sklep internetowy: od 6 900 zł.
Projekty z logiką po stronie serwera (strefa klienta, integracje z CRM-em czy systemem rezerwacji): od 9 900 zł, ostateczna wycena po specyfikacji.
Migracja z WordPressa z zachowaniem SEO: cena nowej strony plus praca przy spisie adresów, przekierowaniach i przenoszeniu treści. Tę część wyceniam po przejrzeniu obecnej strony, bo zależy głównie od liczby adresów i funkcji do odtworzenia.

Przykład: strona firmowa z dziesięcioma podstronami, blogiem i wersją angielską to 3 900 + 5 × 250 + 500 + 1 200 = 6 850 zł netto. Konfigurator pokaże widełki wokół tej kwoty, a dokładną cenę podaję po rozmowie.

Ponad te kwoty koszt najbardziej podnoszą: integracje z zewnętrznymi systemami, migracja dużej ilości treści, rozbudowany CMS z podglądem i rolami oraz dużo różnych układów stron zamiast kilku powtarzalnych.

Więcej o tym, z czego składa się cena strony niezależnie od technologii, pisałem w artykule o kosztach strony internetowej w 2026 roku.

Jak wygląda projekt strony w Astro u mnie

Opiszę proces, bo dla wielu klientów to ważniejsze niż technologia.

Rozmowa. Pytam o cel strony, o to, skąd przychodzą klienci, kto w firmie będzie zmieniał treści i co nie działa na obecnej stronie. Często już tu okazuje się, że Astro nie jest potrzebne i to mówię.
Audyt obecnej strony, jeśli istnieje. Ruch, frazy, indeksowanie, szybkość, analityka. To podstawa do decyzji, co przenieść, a co zostawić.
Specyfikacja i model treści. Jakie typy treści, jakie pola, jakie adresy, jakie integracje. To etap, którego większość wykonawców nie robi, a który decyduje o tym, czy za rok da się stronę rozbudować bez przepisywania.
Projekt graficzny na prawdziwej treści, nie na lorem ipsum.
Wdrożenie z wersją testową dostępną dla klienta od pierwszych dni, a nie na końcu.
Testy przed publikacją: Core Web Vitals, crawl i linki, przekierowania, dane strukturalne, analityka ze zgodą, nagłówki bezpieczeństwa, formularze na prawdziwych skrzynkach.
Publikacja i 30 dni obserwacji w Search Console i analityce.
Opieka: aktualizacje bezpieczeństwa, coroczne przejście na nową wersję Astro, rozwój strony.

Strona firmowa to zwykle 3–6 tygodni od akceptacji specyfikacji, landing page 1–2 tygodnie, migracja rozbudowanego serwisu 4–10 tygodni. Najczęściej na harmonogram wpływa nie kod, tylko to, kiedy gotowa jest treść.

Najczęstsze pytania

Czy strona w Astro jest lepsza dla SEO niż strona na WordPressie?

Sama technologia nie wypozycjonuje strony. Astro daje lepszy punkt startu: lekki HTML, szybkie ładowanie, pełną kontrolę nad kodem i metadanymi. Ale słaba treść na szybkiej stronie dalej jest słabą treścią. Największy zysk widzę u firm, których dotychczasowa strona była wolna albo technicznie zaniedbana.

Czy będę mógł sam edytować treści?

Tak, jeśli w projekcie jest CMS. Dobieram go do osoby, która będzie go używać. Zmiana tekstu, dodanie artykułu czy realizacji to kwestia kilku minut w panelu, bez znajomości kodu.

Co jeśli Cloudflare zmieni zasady albo Astro przestanie być rozwijane?

Astro jest na licencji MIT, więc kod zostaje otwarty niezależnie od właściciela. Stronę w Astro można przenieść na innego dostawcę hostingu, a treść, szczególnie w CMS-ach opartych o pliki, zostaje u Ciebie. To mniejsze ryzyko niż zamknięte platformy, gdzie strona istnieje tylko u jednego dostawcy.

Astro czy Next.js?

Strona treściowa: Astro. Aplikacja z logowaniem, panelem i dużą ilością interakcji: Next.js. Gdy projekt ma oba elementy, często robimy część marketingową w Astro, a aplikację osobno. Każda część korzysta wtedy z tego, w czym jej technologia jest najlepsza.

Czy hosting strony w Astro naprawdę jest darmowy?

Dla strony w pełni statycznej na Cloudflare: tak, płacisz tylko za domenę. Przy elementach serwerowych darmowy plan ma limity, które przy typowej stronie firmowej rzadko są problemem. I tak liczę je przed wdrożeniem.

Ile trwa zrobienie strony w Astro?

Landing page 1–2 tygodnie, strona firmowa 3–6 tygodni, migracja większego serwisu 4–10 tygodni. Najwięcej czasu zwykle zajmuje przygotowanie treści.

Czy mogę przejąć stronę w Astro zrobioną przez kogoś innego?

Tak, jeśli masz dostęp do repozytorium z kodem i do konta hostingowego. Zawsze zaczynam od przeglądu kodu, wersji Astro i zależności. Jeśli poprzedni wykonawca nie przekazał repozytorium, to pierwsza rzecz do załatwienia, zanim zapłacisz za cokolwiek innego.

Czy Astro nadaje się na stronę z AI, chatbotem albo wyszukiwarką?

Tak. Czat czy wyszukiwarkę wstawia się jako wyspę, która ładuje się dopiero, gdy jest potrzebna, więc nie spowalnia reszty strony. Logikę po stronie serwera obsługują akcje i endpointy.

Astro nie jest magiczne. To dobrze zaprojektowane narzędzie, które w rękach kogoś, kto rozumie, jak działa wyszukiwarka, przeglądarka i biznes klienta, daje stronę szybką, bezpieczną i tanią w utrzymaniu. W rękach kogoś, kto skopiował szablon z internetu, daje stronę jak każda inna, tylko trudniejszą do edycji.

Jeśli zastanawiasz się, czy Astro ma sens dla Twojej firmy, albo chcesz przenieść stronę z WordPressa i boisz się o pozycje w Google, napisz do mnie. Najpierw sprawdzę, co masz teraz. Czasem powiem, żeby niczego nie ruszać, i to też jest dobra odpowiedź.

Strona internetowa w Astro: przewodnik praktyka dla firm (Astro 7, 2026)