SEO w Astro

TL;DR — Astro to świetny wybór do SEO. Domyślnie buduje strony jako zwykłe pliki HTML z wyprzedzeniem, więc gdy pojawia się Google (lub dowolny bot), treść już tam jest — nie trzeba czekać na uruchomienie JavaScriptu. Jest też bardzo szybki. Trzeba tylko wiedzieć, że Astro daje czysty HTML, ale nie dodaje automatycznie tytułów stron, mapy witryny ani tagów kanonicznych. Konfigurujesz je samodzielnie (to proste).

Co oznacza „Astro SEO”

Astro to framework webowy do budowania witryn. Jego główny pomysł to „mniej JavaScriptu”. Podczas gdy frameworki takie jak React lub Next.js często budują stronę w przeglądarce za pomocą JavaScriptu, Astro tworzy strony jako zwykłe pliki HTML w czasie budowania i wysyła prawie zero JavaScriptu, chyba że dana część strony rzeczywiście go potrzebuje. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

Ta pojedyncza różnica sprawia, że Astro jest tak przyjazne wyszukiwarkom. Gdy wyszukiwarka crawluje stronę, chce odczytać jej treść. W witrynie opartej mocno na JavaScript treści czasem nie ma jeszcze w dokumencie — bot musi najpierw uruchomić JavaScript, co może się opóźnić. W Astro treść jest już w HTML-u w chwili załadowania strony. Nie ma na co czekać.

Własną witrynę patrickstox.com prowadzę na Astro — to nie jest więc dla mnie teoria. To stos technologiczny, na którym faktycznie buduję.

Dlaczego Astro dobrze nadaje się do SEO

• Treść od razu znajduje się w HTML-u. Nie ma opóźnienia renderowania ani brakującej treści.
• Jest szybkie. Witryny Astro są lekkie i zwykle osiągają bardzo dobre wyniki w metrykach jakości strony Google (Core Web Vitals).
• Każda strona ma własny prawdziwy adres URL. Nie ma wymyślnego routingu aplikacji jednostronicowej, który mógłby zmylić crawlery.
• JavaScript ładuje się tylko tam, gdzie jest potrzebny. Galeria zdjęć lub pole wyszukiwania może być interaktywne bez spowalniania reszty strony.

Czego Astro za Ciebie NIE robi

To często wprowadza ludzi w błąd. Stwierdzenie „Astro jest zoptymalizowane pod SEO” jest prawdziwe tylko w połowie. Astro daje czystą podstawę, ale nie dodaje automatycznie:

• Tytułów stron i opisów meta.
• Mapy witryny (dodajesz do tego bezpłatną oficjalną wtyczkę). Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration
• Tagów kanonicznych (które mówią Google, która wersja strony jest „oficjalna”).
• Danych strukturalnych (kodu napędzającego rich result).
• Pliku robots.txt.

Nic z tego nie jest trudne — po prostu musisz to skonfigurować. Pomyśl o Astro jak o świetnej kuchni: urządzenia są doskonałe, ale nadal musisz ugotować posiłek.

Prosta lista startowa

• Dodaj mapę witryny za pomocą oficjalnej wtyczki @astrojs/sitemap.
• Ustaw na każdej stronie title, description i canonical URL (zwykle z jednego wspólnego pliku layoutu).
• Do zdjęć używaj wbudowanego komponentu Astro <Image /> — dzięki niemu ładują się szybko, a strona nie przeskakuje.
• Umieść plik robots.txt w folderze public/.

Chcesz poznać wersję zaawansowaną — Server Islands, View Transitions, renderowanie statyczne i serwerowe oraz dokładne błędy, których należy unikać? Przejdź do karty Advanced. Szerszy obraz tego, jak wyszukiwarki obsługują JavaScript, znajdziesz w JavaScript SEO.

TL;DR — Astro jest architektonicznie dobrze przygotowane do SEO: strony i endpointy są domyślnie prerenderowane do statycznego HTML-u, więc dla tej treści nie trzeba czekać na falę kolejki renderowania — ale to ustawienie domyślne, a nie uniwersalna gwarancja, a sam statyczny lub serwerowy HTML nie dowodzi indeksowalności, indeksowania, rankingów ani Core Web Vitals produkcyjnych adresów URL. Architektura Islands nawadnia tylko komponenty oznaczone dyrektywą client:* — pozostała część wysyła HTML bez własnego JavaScriptu hydratacji, choć skrypty strony, inne wyspy i usprawnienia routera mogą dodać JavaScript w innych miejscach strony. Astro nie generuje automatycznie tagów meta, kanonicznych adresów, map witryny ani danych strukturalnych — skonfiguruj je jawnie, najlepiej poddając walidacji przez Content Collections + Zod. Server Islands (wymagające adaptera) serwują statyczną powłokę z treścią zastępczą w dokumencie początkowym, a później niezależnie pobierają odroczoną treść — sprawdź, co faktycznie pobiera dany crawler, zamiast zakładać. View Transitions używa history.pushState i jest bezpieczne dla SEO; Google crawluje bazowe strony MPA normalnie. Prowadzę patrickstox.com na Astro, a poniższe funkcje to te, których faktycznie używam — sprawdzone na wdrożonej witrynie, a nie tylko w lokalnym środowisku.

Dlaczego Astro całkowicie omija problem renderowania JavaScriptu

Cały problem SEO JavaScriptu bierze się z drugiej fali. Google najpierw pobiera surowy HTML, a potem umieszcza stronę w kolejce do renderowania w bezgłowym Chromium — i właśnie ta kolejka jest ryzykiem. Własne dokumenty Google opisują to tak: “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (tłumaczenie) „Googlebot umieszcza każdą stronę z kodem statusu HTTP 200 w kolejce renderowania, chyba że tag robots meta mówi Google, aby nie indeksował strony. Strona może pozostać w tej kolejce kilka sekund, ale może to potrwać dłużej.” W aplikacji SPA renderowanej po stronie klienta treść nie istnieje, dopóki ta fala renderowania się nie odbędzie.

Domyślny tryb wyjściowy Astro jest statyczny: strony i endpointy są prerenderowane do kompletnego pliku HTML w czasie budowania. Dla trasy działającej w tym trybie surowy HTML jest wyrenderowaną stroną. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering Nie ma drugiej fali, na którą trzeba czekać, ponieważ nie zostało już nic do wykonania. Googlebot widzi pełną treść przy pierwszym pobraniu. Jak ujmuje to Joost de Valk (założyciel Yoast): “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (tłumaczenie) „Z perspektywy SEO statyczny HTML na CDN-ie jest lepszym punktem wyjścia, niż kiedykolwiek zapewni większość CMS-ów”.

To jednak ustawienie domyślne, a nie uniwersalna właściwość każdej trasy. Ustaw output: 'server', a domyślny tryb zmieni się na renderowanie na żądanie (więcej na ten temat poniżej); nawet w projekcie domyślnie statycznym adapter pozwala pojedynczej trasie wyłączyć prerenderowanie za pomocą export const prerender = false. Sama architektura niczego tu nie gwarantuje: statyczny lub serwerowy HTML, wyspy i adaptery nie zapewniają automatycznie indeksowalności, indeksowania, rankingów ani Core Web Vitals — zależy to od wdrożonej trasy i konkretnego crawlera, więc sprawdzaj to zamiast zakładać, że framework się tym zajmie.

Pomaga to także crawlerom, które w ogóle nie potrafią renderować. Google mówi wprost, że “not all bots can run JavaScript” (tłumaczenie) „nie każdy bot potrafi uruchomić JavaScript” — i to jest rzeczywistość 2026 roku w przypadku większości crawlerów AI oraz wielu narzędzi zewnętrznych. Wyjście Astro w pierwszej kolejności jako HTML jest czytelne dla każdego z nich tam, gdzie faktycznie zostało prerenderowane, a nie tylko dla Googlebota. (To ten sam punkt, który przedstawiam w SEO dla bezgłowego CMS-a: tryb renderowania jest częścią produktu.)

Architektura Islands: JS tylko tam, gdzie go potrzebujesz

Astro renderuje komponenty do HTML-u i, jak samo mówi, wysyła “just HTML & CSS, stripping out all client-side JavaScript automatically.” (tłumaczenie) „tylko HTML i CSS, automatycznie usuwając cały JavaScript po stronie klienta”. Interaktywność jest opcjonalna. Oznaczasz komponent dyrektywą client:* — client:load, client:idle lub client:visible — i tylko ta wyspa jest hydratowana JavaScriptem. Cała reszta pozostaje statycznym HTML-em. Evidence for this claim Astro client directives selectively hydrate interactive islands while other components remain static HTML. Scope: Astro islands and client directives. Confidence: high · Verified: 2026-07-14 Astro: Islands

Z punktu widzenia SEO jest to niemal idealne. Treść, którą Googlebot musi zaindeksować, to zwykły HTML, a interaktywne widgety nie obciążają go. client:visible jest szczególnie użyteczne: komponent poniżej pierwszego ekranu nie zaczyna hydratacji, dopóki nie pojawi się w polu widzenia, więc nigdy nie blokuje LCP. Koncepcja pochodzi od Jasona Millera (twórcy Preacta), który opisał “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions” (tłumaczenie) „renderowanie stron HTML na serwerze i wstrzykiwanie placeholderów lub slotów wokół wysoce dynamicznych obszarów” na potrzeby selektywnej hydratacji.

Dwie kwestie wymagają precyzji, ponieważ materiały konkurencji często je zacierają:

• client:only to coś innego. W przeciwieństwie do client:load/client:idle/client:visible komponent client:only całkowicie pomija renderowanie po stronie serwera — na serwerze nie tworzy żadnego HTML-u. Treść indeksowalna umieszczona wyłącznie w komponencie client:only nie znajduje się w dokumencie pobieranym przez Googlebota; istnieje dopiero po hydratacji w przeglądarce. Nie umieszczaj tam głównej treści.
• To selektywna hydratacja, a nie resumowalność. Astro uruchamia kod klienta każdej wyspy od początku w przeglądarce; nie wznawia stanu wykonania zserializowanego na serwerze tak, jak robi to model resumowalności (na przykład Qwika). W tekstach te pojęcia bywają mieszane — nie oznaczają tego samego.

Nawet komponent bez hydratacji nie wyczerpuje obrazu JavaScriptu na stronie. „Zero JS” opisuje jeden komponent bez dyrektywy client:* — Astro nadal może wysłać tagi <script> na poziomie strony, router View Transitions i inne wyspy w innych miejscach tej samej strony. Opisuj to, co wysyłane jest na komponent lub trasę, a nie jako ogólną właściwość całej strony.

Czego Astro NIE robi automatycznie

Astro generuje czysty, semantyczny HTML — i nic więcej z punktu widzenia SEO. Domyślnie nie ma metadanych, kanonicznego adresu, mapy witryny ani danych strukturalnych. Mit, że „Astro jest automatycznie zoptymalizowane pod SEO”, jest właśnie mitem. To Ty odpowiadasz za:

• Tagi meta (tytuł, opis, Open Graph, Twitter)
• Adresy kanoniczne
• Mapę witryny (przez oficjalną integrację)
• Dane strukturalne / JSON-LD
• robots.txt

Astro jest najlepszą podstawą, z jakiej korzystałem, ale to podstawa, a nie gotowy dom.

Mapa witryny: @astrojs/sitemap

Zainstaluj ją poleceniem npx astro add sitemap. Integracja crawluje trasy generowane statycznie i w czasie budowania emituje sitemap-index.xml oraz podzielone na fragmenty pliki sitemap-0.xml. Dwie rzeczy często sprawiają problemy:

• Musisz ustawić site: w astro.config.mjs. Bez tego integracja po cichu nie wygeneruje niczego. To najczęstsza przyczyna pytania „gdzie jest moja mapa witryny?”.
• Musisz samodzielnie dodać wiersz mapy witryny do robots.txt. Astro tego nie robi.

Dla większej kontroli filter() wyklucza trasy (strony podglądu i wersje robocze — dokładnie do tego używam go w tej witrynie), serialize() pozwala ustawić lastmod/changefreq/priority, a opcja i18n emituje wpisy hreflang w mapie witryny. Tak właśnie opisują to aktualne dokumenty @astrojs/sitemap — jeśli korzystasz ze starszej wersji, sprawdź własną instalację, ponieważ zachowanie integracji zmieniało się między głównymi wersjami.

To zakres powoduje najwięcej problemów: mechanizm odkrywania integracji obejmuje trasy wygenerowane statycznie. Jeśli którykolwiek z adresów URL istnieje tylko w czasie działania — trasy serwerowe (output: 'server') albo trasy generowane na żądanie, a nie podczas budowania — nie zakładaj, że znajdzie się w mapie witryny. Dodaj go jawnie przez customPages, a po budowaniu rzeczywiście otwórz sitemap-index.xml, aby potwierdzić obecność. W przypadku trasy, która nie jest statyczna w czasie budowania, nie przyjmuj na wiarę, że „integracja się tym zajmuje”.

Tagi meta i kanoniczne: wzorzec BaseLayout

Astro nie ma specjalnego komponentu <Head> — bezpośrednio kontrolujesz <head> w plikach .astro. Standardowy wzorzec (i ten, którego używam) to pojedynczy BaseLayout.astro, który przyjmuje właściwości title, description i canonicalURL, a następnie zapisuje nagłówek. Ustaw jawnie kanoniczny adres na każdej stronie i zachowaj jego zgodność z og:url. Biblioteka nie jest konieczna, ale społecznościowy pakiet astro-seo (npm) to wygodna otoczka jednego komponentu dla tytułu/opisu/OG/Twittera/kanonicznego adresu, jeśli jej potrzebujesz.

Content Collections jako zabezpieczenie SEO

To niedoceniana funkcja SEO Astro. Content Collections to bezpieczna typowo warstwa treści dla Markdown/MDX/JSON z walidacją schematu Zod. Możesz dzięki temu uczynić title i description polami wymaganymi — a jeśli którejś brakuje, kompilacja kończy się błędem. Nie da się przypadkiem wysłać strony bez tytułu. Funkcje zapytań (getCollection(), getEntry()) generują statyczne strony w czasie budowania, więc po wdrożeniu wyjściem jest zwykły HTML. Ponieważ MDX zachowuje surowy Markdown jako źródło prawdy, pliki te są także czystą treścią źródłową dla crawlerów AI i wzorców w rodzaju llms.txt. Ta witryna jest zbudowana na Content Collections z frontmatterem walidowanym przez Zod.

astro:assets: obrazy zrobione poprawnie (z jedną pułapką)

Komponent <Image /> automatycznie konwertuje obrazy do WebP, ustala wymiary, aby “avoid Cumulative Layout Shift (CLS),” (tłumaczenie) „uniknąć Cumulative Layout Shift (CLS)”, domyślnie ustawia loading="lazy" i wymaga alt — brak alt jest błędem kompilacji. <Picture /> rozszerza to o elementy <source> AVIF/WebP i fallback.

Pułapka: automatyczne loading="lazy" jest nieprawidłowe dla obrazu LCP (zwykle hero). Lazy loading najważniejszego obrazu opóźnia go. W przypadku obrazów powyżej pierwszego ekranu nadpisz ustawienie przez loading="eager" i fetchpriority="high". Obrazy zdalne potrzebują jawnych wartości width i height.

Server Islands: co faktycznie widzą crawlery

Server Islands (Astro 4.12+) to funkcja, którą większość poradników konkurencji opisuje błędnie. Przy server:defer komponent renderuje się na serwerze niezależnie od głównej strony. Statyczna powłoka jest wysyłana od razu; zgodnie z dokumentami Astro: “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (tłumaczenie) „Twoja strona od razu zostanie wyrenderowana z określoną treścią zastępczą jako placeholderem. Następnie własna treść komponentu zostanie pobrana po stronie klienta i wyświetlona, gdy będzie dostępna”.

Dwie kwestie wymagają precyzji. Po pierwsze, Server Islands wymagają adaptera — jest to funkcja na żądanie, a nie coś, co czysto statyczne budowanie tworzy samo z siebie. Po drugie, sekwencja wygląda tak: dokument początkowy zawiera skonfigurowaną treść zastępczą, a rzeczywista treść wyspy jest osobnym, niezależnym żądaniem pobieranym po załadowaniu strony z własnego endpointu. To twarda granica tego, co zawiera pierwszy dokument — bez bezpośredniego testowania własnych wdrożonych adresów URL nie uogólniałbym na tej podstawie tego, co później robi każdy konkretny crawler.

Konsekwencja SEO jest konkretna: statyczny HTML odczytywany przez crawler przy pierwszym pobraniu zawiera treść zastępczą, a nie odroczoną treść wyspy. To idealne rozwiązanie dla tego, do czego służą Server Islands — spersonalizowanych, zależnych od sesji elementów (stan logowania, licznik koszyka, rekomendacje), których i tak nie należy buforować ani indeksować. Nie sprawdza się w przypadku głównej treści indeksowalnej. Wszystko, co ma zajmować pozycje, umieść w głównym szablonie Astro, a Server Islands zostaw na otaczające je elementy dynamiczne.

Tryby wyjścia: statyczny i serwerowy oraz nadpisanie dla pojedynczej trasy

Domyślny tryb wyjściowy Astro to static — strony i endpointy są prerenderowane do HTML-u w czasie budowania. Ustaw output: 'server' w astro.config.mjs, a domyślny tryb zmieni się na renderowanie na żądanie: strony będą renderować się przy każdym żądaniu (z adapterem), co przydaje się w przypadku uwierzytelniania, danych w czasie rzeczywistym lub personalizacji wykraczającej poza możliwości Server Islands. W obu trybach możesz nadpisać domyślne ustawienie dla trasy: w projekcie domyślnie statycznym export const prerender = false włącza renderowanie na żądanie, a w projekcie domyślnie serwerowym export const prerender = true przywraca prerenderowanie podczas budowania. Stwierdzenie „moja witryna jest statyczna” lub „moja witryna używa SSR” rzadko jest prawdziwe dla każdej trasy — sprawdź ustawienie trasy, a nie tylko konfigurację najwyższego poziomu.

Z czysto SEO-wego punktu widzenia prerenderowany i generowany na żądanie HTML są równoważne — oba dostarczają crawlerowi kompletny HTML przy pierwszym żądaniu, gdy faktycznie potwierdzisz, że trasa zwraca 200 z pełnym oznaczeniem. Trasy generowane na żądanie mogą strumieniować HTML, a wolne dane lub warunki sieciowe mogą opóźniać późniejsze fragmenty, więc strumieniowana odpowiedź nie jest automatycznym dowodem, że dotarła cała treść — sprawdź to, nie zakładaj. Prawdziwa różnica między trybami jest operacyjna: prerenderowana treść pozostaje stała do następnego budowania (lub osobno skonfigurowanego odświeżenia w czasie działania) i jest serwowana prosto z brzegu CDN; treść na żądanie jest zawsze aktualna, ale zależy od zdrowego działania adaptera i środowiska uruchomieniowego na produkcji. Nie traktuj tego jako decyzji SEO — wybierz tryb według świeżości danych i operacji, a następnie zweryfikuj wdrożone trasy, statusy, przekierowania i nagłówki odpowiedzi, zamiast ekstrapolować z lokalnego środowiska.

View Transitions: bezpieczne dla SEO mimo wrażenia SPA

Astro <ClientRouter /> (wcześniej <ViewTransitions />) zapewnia miękką nawigację w stylu SPA za pomocą przeglądarkowego API View Transitions i History API. Kluczowy fakt: nawiguje przez history.pushState, dokładnie tak, jak Google zaleca w nawigacji po stronie klienta — Google ostrzega, że adresy oparte na fragmentach (#hash) to coś, czego “can’t reliably resolve.” (tłumaczenie) „nie potrafi niezawodnie rozwiązać”. Co najważniejsze, View Transitions to usprawnienie po stronie przeglądarki. Gdy Googlebot crawluje, wysyła żądanie do każdego adresu URL i otrzymuje zwykłą, kompletną stronę HTML — bazowa MPA pozostaje nietknięta. Przejścia wpływają tylko na to, co człowiek widzi w przeglądarce.

Nie, View Transitions nie zmieniają witryny Astro w SPA i nie psują SEO. Warto zauważyć, że dokumenty Astro dotyczące View Transitions nie mają sekcji SEO, co prawdopodobnie tłumaczy utrzymywanie się mitu „to psuje SEO”. Aby sprawdzić własną witrynę, pobierz bezpośrednio kilka adresów URL i potwierdź, że każdy zwraca pełny HTML — nie przyjmuj tego na wiarę, sprawdź własne wdrożenie.

Typowe błędy SEO w Astro

1. Zakładanie, że Astro zajmie się SEO za Ciebie. Zajmuje się HTML-em. Meta, kanoniczne adresy, mapa witryny i schema są po Twojej stronie.
2. Zapomnienie o site: w konfiguracji — mapa witryny po cichu się nie wygeneruje.
3. Brak mapy witryny w robots.txt — Astro tego nie zrobi.
4. Lazy loading obrazu LCP — nadpisz to dla hero przez eager + fetchpriority.
5. Umieszczanie indeksowalnej treści w Server Island — crawlery widzą treść zastępczą, a Server Islands i tak wymagają adaptera.
6. Pogoń za idealnym wynikiem Lighthouse i zatrzymanie się na tym. Szybkość jest sygnałem rankingowym, ale nie jedynym sygnałem rankingowym. Szybka pusta strona nie zajmuje pozycji — najwięcej pracy wykonują nadal treść, linki i E-E-A-T.
7. Umieszczenie indeksowalnej treści wyłącznie w komponencie client:only. W przeciwieństwie do pozostałych dyrektyw client:*, client:only całkowicie pomija renderowanie serwerowe — dla tego komponentu nie ma HTML-u, dopóki przeglądarka go nie zahydratuje.
8. Traktowanie „Astro jest statyczne/szybkie” jako gwarancji rezultatu. Statyczny lub generowany na żądanie HTML, wyspy i adaptery to mechanizmy — same z siebie nie gwarantują indeksowalności, indeksowania, rankingów ani Core Web Vitals. Zweryfikuj wdrożoną trasę, a nie diagram architektury.

Gdzie to pasuje w klastrze

Astro jest jednym, wyjątkowo przyjaznym SEO rozwiązaniem dla problemów z renderowaniem, które stawia JavaScript SEO, oraz popularnym frontendem dla wdrożeń bezgłowego CMS-a. Warstwa wydajności łączy się bezpośrednio z Core Web Vitals w klastrze wydajności stron, a dyscyplina sprawdzania „czy moja treść rzeczywiście znajduje się w HTML-u?” jest taka sama jak w klastrach crawlowania i indeksowania.

Antywzorce SEO w Astro

Konkretne błędy, które faktycznie widuję w witrynach Astro — nie hipotetyczne. Każdy z nich dotyczy zapobiegania, a nie diagnozy: wykryj go, zanim trafi na produkcję.

Traktowanie Astro jako „zoptymalizowanego pod SEO” od razu po instalacji

Astro daje szybki, czysty statyczny HTML i jest to rzeczywiście duży punkt wyjścia — ale nie jest tym samym co tagi meta, kanoniczne adresy, mapa witryny ani dane strukturalne. Dlaczego to błąd: zespoły wdrażają strony bez zmiennego <title>, bez adresu kanonicznego i bez mapy witryny, ponieważ „Astro obsługuje SEO”, a potem zastanawiają się, dlaczego nic nie jest indeksowane zgodnie z oczekiwaniami. Co zrobić zamiast tego: od pierwszego dnia podłącz właściwości BaseLayout.astro dla tytułu/opisu/kanonicznego adresu, dodaj @astrojs/sitemap i traktuj te elementy jako wymagane kroki budowania, a nie ustawienia domyślne.

Zapominanie o site: w astro.config.mjs

To najczęstszy raport w rodzaju „dlaczego moja mapa witryny jest pusta?”. Dlaczego to błąd: @astrojs/sitemap potrzebuje bezwzględnego adresu witryny, aby zbudować bezwzględne wpisy <loc> — bez ustawionego site: integracja po cichu nie tworzy niczego (bez błędu i bez ostrzeżenia). Co zrobić zamiast tego: ustaw site: w astro.config.mjs przed zainstalowaniem integracji mapy witryny i po następnym budowaniu sprawdź, czy sitemap-index.xml rzeczywiście zawiera adresy URL.

Pomijanie mapy witryny w robots.txt

Instalacja @astrojs/sitemap nie dodaje wiersza Sitemap: do robots.txt — to osobny, ręczny krok, który ludzie często uznają za automatyczny. Dlaczego to błąd: wyszukiwarki nadal mogą znaleźć mapę witryny po przesłaniu jej w Search Console, ale tracisz pasywną ścieżkę odkrywania, na której polegają inne boty (oraz crawlery powiązane z Bing/IndexNow). Co zrobić zamiast tego: dodaj Sitemap: https://yoursite.com/sitemap-index.xml do robots.txt w folderze public/ i po wdrożeniu potwierdź, że adres działa.

Pozostawianie domyślnego loading="lazy" na obrazie hero

Komponent <Image /> Astro domyślnie używa lazy loadingu, co jest właściwe dla obrazów poniżej pierwszego ekranu, ale niewłaściwe dla obrazu, który zwykle jest elementem LCP. Dlaczego to błąd: lazy loading hero opóźnia nawet rozpoczęcie żądania tego obrazu przez przeglądarkę, co bezpośrednio pogarsza wynik Largest Contentful Paint. Co zrobić zamiast tego: jawnie nadpisz ustawienia obrazu hero/powyżej pierwszego ekranu przez loading="eager" i fetchpriority="high", a wszystkie pozostałe obrazy pozostaw z domyślnym lazy loadingiem.

Umieszczanie indeksowalnej treści w Server Island

server:defer służy do spersonalizowanej treści zależnej od sesji — liczników koszyka, stanu logowania i rekomendacji — a nie do rzeczy, które mają zajmować pozycje. Dlaczego to błąd: statyczny HTML odczytywany przez crawler zawiera treść zastępczą skonfigurowaną dla wyspy, a nie treść pobieraną po stronie klienta po załadowaniu strony, więc główna treść umieszczona w tym miejscu jest niewidoczna dla wyszukiwarek przy pierwszym crawlowaniu. Co zrobić zamiast tego: zachowaj treść rankingową w głównym szablonie Astro, a Server Islands zostaw wyłącznie na elementy dynamiczne i spersonalizowane, których i tak nie należy indeksować.

Zakładanie, że szybki wynik Lighthouse oznacza koniec pracy

Witryny Astro niemal domyślnie osiągają dobre Core Web Vitals i łatwo na tym poprzestać. Dlaczego to błąd: szybkość jest jednym z wielu sygnałów rankingowych — szybka, pusta lub cienka strona nadal nie pokona wolniejszej strony z lepszą treścią, linkami i głębią tematyczną. Co zrobić zamiast tego: traktuj wydajność jako podstawę, którą Astro daje za darmo, a właściwy wysiłek optymalizacyjny przeznacz na jakość treści, linkowanie wewnętrzne oraz dane strukturalne i meta, których Astro nie tworzy.

Zakładanie, że „statyczne domyślnie” dotyczy każdej trasy

Tryb statycznego wyjścia Astro jest domyślny, ale to ustawienie, a nie uniwersalna właściwość — output: 'server' je zmienia, a prerender można ustawić dla każdej trasy w obu kierunkach. Dlaczego to błąd: zespoły opisują całą witrynę jako „statyczną” lub „SSR” na podstawie konfiguracji najwyższego poziomu i nie sprawdzają poszczególnych tras, a potem są zaskoczone, gdy jedna z nich zachowuje się inaczej na produkcji. Co zrobić zamiast tego: sprawdź ustawienie prerender dla każdej analizowanej trasy i zweryfikuj rzeczywistą odpowiedź (kod statusu, pełne oznaczenie, zachowanie przekierowania) pod wdrożonym adresem URL, zamiast ufać plikowi konfiguracyjnemu.

Umieszczanie treści wyłącznie w komponencie client:only

client:only nie jest tym samym co client:load/client:idle/client:visible — całkowicie pomija renderowanie serwerowe. Dlaczego to błąd: komponent używający client:only nie generuje HTML-u na serwerze, więc treść indeksowalna umieszczona wyłącznie w tym miejscu jest niewidoczna dla crawlera czytającego surową odpowiedź, a po client:only łatwo sięgnąć dla „prostoty” bez uświadomienia sobie kosztu SEO. Co zrobić zamiast tego: renderuj główną treść w komponencie renderowanym na serwerze lub w szablonie strony; client:only zostaw na widgety służące wyłącznie interakcji, bez treści indeksowalnej.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• Domyślny tryb wyjścia Astro prerenderuje HTML statycznie w czasie budowania — dla trasy działającej w tym trybie surowy HTML jest gotową stroną, więc problem kolejki renderowania Google (związany z „drugą falą”) jej nie dotyczy. To ustawienie domyślne, a nie uniwersalna właściwość: output: 'server' je zmienia, a prerender może nadpisać je dla każdej trasy w obu kierunkach.
• Architektura Islands hydratyzuje tylko komponenty oznaczone client:*; komponent bez tej dyrektywy wysyła HTML bez własnego JS hydratacji (choć Astro nadal może dodać skrypty strony, inne wyspy i JS routera w innych miejscach). Wyjątkiem jest client:only — pomija renderowanie serwerowe, więc treść indeksowalna nie powinna znajdować się wyłącznie tam. To selektywna hydratacja, a nie resumowalność. client:visible chroni LCP, nie dopuszczając do blokowania go przez JS poniżej pierwszego ekranu.
• Astro nie generuje automatycznie niczego z punktu widzenia SEO — tagi meta, adresy kanoniczne, mapa witryny, dane strukturalne i robots.txt są celowymi krokami budowania. „Astro jest automatycznie zoptymalizowane pod SEO” to mit.
• @astrojs/sitemap odkrywa trasy wygenerowane statycznie — ale musisz ustawić site: w konfiguracji (w przeciwnym razie po cichu nic nie robić), samodzielnie dodać wiersz mapy witryny do robots.txt i jawnie dodać adresy istniejące tylko w czasie działania przez customPages.
• Content Collections + Zod mogą wymusić title/description, powodując błąd budowania, gdy strona ich nie zawiera — to zabezpieczenie SEO.
• astro:assets <Image> konwertuje obrazy do WebP, ustawia wymiary (zapobiega CLS), domyślnie używa lazy loadingu i wymaga alt. Nadpisz ustawienie obrazu LCP przez loading="eager" + fetchpriority="high".
• Server Islands (server:defer) wymagają adaptera, natychmiast serwują statyczną powłokę + treść zastępczą w dokumencie początkowym, a później niezależnie pobierają wyspę. Crawlery czytające pierwszy dokument widzą treść zastępczą, a nie wyspę — nigdy nie umieszczaj tam treści indeksowalnej.
• Wyjście statyczne i na żądanie (serwerowe) jest równoważne z punktu widzenia SEO po weryfikacji — oba dostarczają crawlerom pełny HTML przy pierwszym żądaniu, ale trasy na żądanie mogą strumieniować odpowiedź, więc potwierdź, że faktycznie dociera kompletna; wybieraj tryb według świeżości danych i operacji, a nie SEO.
• View Transitions (<ClientRouter />) używa history.pushState i jest bezpieczne dla SEO; Google crawluje bazowe strony MPA normalnie. To usprawnienie przeglądarki, a nie konwersja do SPA.
• Żaden z tych elementów nie jest gwarancją rezultatu — statyczny/serwerowy HTML, wyspy i adaptery są mechanizmami, a nie dowodem indeksowalności, indeksowania, rankingów ani Core Web Vitals. Zweryfikuj wdrożoną trasę.
• Astro osiąga dobre wyniki Core Web Vitals w swoim benchmarku z 2023 roku — ponad 50% witryn Astro przeszło ocenę Google CWV, znacznie powyżej ówczesnej średniej branżowej; traktuj to jako datowany punkt odniesienia, a nie bieżącą gwarancję.

Dokumentacja oficjalna

Dokumentacja źródłowa Astro i wyszukiwarek.

Astro

• Islands Architecture — sposób, w jaki Astro usuwa JS po stronie klienta i hydratyzuje tylko interaktywne komponenty.
• Template Directives Reference — client:load/idle/visible/only oraz server:defer, w tym to, co pomija client:only.
• Image Optimization (astro:assets) — komponenty <Image>/<Picture>, WebP, wymiary i CLS.
• @astrojs/sitemap — automatyczne tworzenie mapy witryny, filter, serialize i i18n.
• Server Islands — server:defer, wymóg adaptera, treść zastępcza i odroczone pobieranie po stronie klienta.
• On-Demand Rendering — tryby wyjścia static/server, prerender dla trasy i strumieniowanie HTML-u.
• Routing Reference — sposób, w jaki strony i endpointy są domyślnie prerenderowane.
• Astro Runtime API Reference — obsługa Response/przekierowań i domyślne kody statusu.
• Content Collections — bezpieczna typowo treść z walidacją schematu Zod.
• View Transitions — <ClientRouter /> i nawigacja przez History API.

Google

• Understand JavaScript SEO Basics — kolejka renderowania, linki możliwe do crawlowania, History API i zastrzeżenie, że “not all bots run JavaScript” (tłumaczenie) „nie każdy bot potrafi uruchomić JavaScript”.
• In-Depth Guide to How Google Search Works — crawlowanie → renderowanie → indeksowanie oraz miejsce, w którym SSG usuwa etap renderowania.

Bing / Microsoft

• IndexNow / indexnow.org — protokół push, który dobrze łączy się ze statycznym wdrożeniem Astro (podłącz go do kroku publikacji, aby Bing i Yandex od razu dowiadywały się o nowych stronach).

Cytaty ze źródła

Dosłowne wypowiedzi z dokumentów Astro, Google i nazwanych praktyków. Każdy odnośnik do wyszukiwarki i dokumentacji prowadzi bezpośrednio do cytowanego fragmentu na stronie źródłowej.

Google — kolejka renderowania, którą omija Astro

• “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (tłumaczenie) „Googlebot umieszcza wszystkie strony z kodem statusu HTTP 200 w kolejce renderowania, chyba że tag robots meta mówi Google, aby nie indeksował strony. Strona może pozostać w tej kolejce kilka sekund, ale może to potrwać dłużej.” Jump to quote
• “not all bots can run JavaScript” (tłumaczenie) „nie wszystkie boty potrafią uruchomić JavaScript” — dlaczego wyjście HTML-first pomaga nie tylko Googlebotowi. Jump to quote

Dokumenty Astro — wyspy, obrazy, mapy witryny i Server Islands

• “just HTML & CSS, stripping out all client-side JavaScript automatically.” (tłumaczenie) „tylko HTML i CSS, automatycznie usuwając cały JavaScript po stronie klienta” — o architekturze Islands. Jump to quote
• “infers image dimensions to avoid Cumulative Layout Shift (CLS).” (tłumaczenie) „określa wymiary obrazów, aby uniknąć Cumulative Layout Shift (CLS)” — o komponencie Image. Jump to quote
• “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (tłumaczenie) „Twoja strona zostanie natychmiast wyrenderowana z określoną treścią zastępczą jako placeholderem. Następnie własna treść komponentu zostanie pobrana po stronie klienta i wyświetlona, gdy będzie dostępna” — o Server Islands. Jump to quote

Jason Miller (twórca Preacta, który ukuł określenie „islands architecture”)

• Selektywna hydratacja działa przez “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions.” (tłumaczenie) „renderowanie stron HTML na serwerze i wstrzykiwanie placeholderów lub slotów wokół wysoce dynamicznych obszarów” — cytat przytoczony w dokumentacji Astro: Islands Architecture.

Joost de Valk (założyciel Yoast SEO)

• “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (tłumaczenie) „Z perspektywy SEO statyczny HTML na CDN-ie jest lepszym punktem wyjścia, niż kiedykolwiek zapewni większość CMS-ów” — Joost.blog: Astro SEO Complete Guide.

Lista kontrolna Astro SEO

Kontrola, która ma potwierdzić, że witryna Astro jest rzeczywiście przygotowana do wyszukiwania — a nie tylko oparta na dobrej podstawie:

• site: jest ustawione w astro.config.mjs (bez tego mapa witryny po cichu się nie wygeneruje).
• @astrojs/sitemap jest zainstalowane, a odwołanie do mapy witryny dodane ręcznie do robots.txt.
• W public/ istnieje robots.txt i nie blokuje niczego, co chcesz indeksować.
• Każda strona ustawia unikatowy title i description (najlepiej przez wspólny BaseLayout.astro).
• Na każdej stronie znajduje się kanoniczny adres wskazujący na nią samą i zgodny z og:url.
• Content Collections używa schematu Zod, który wymusza title/description (budowanie kończy się błędem przy braku).
• Obrazy używają <Image />/<Picture />; wszystkie mają alt (jego brak i tak jest błędem kompilacji).
• Obraz LCP/hero nadpisuje domyślny lazy loading przez loading="eager" i fetchpriority="high".
• Żadna indeksowalna treść nie znajduje się w Server Island (server:defer) — crawlery widzą treść zastępczą, a Server Islands potrzebują adaptera.
• Żadna indeksowalna treść nie znajduje się wyłącznie w komponencie client:only — pomija on renderowanie serwerowe, więc HTML pojawia się dopiero po hydratacji przeglądarki.
• Dla każdej trasy używającej output: 'server' lub prerender = false dla trasy potwierdź, że adresy istniejące tylko w czasie działania zostały jawnie dodane do mapy witryny (customPages) — automatyczne odkrywanie obejmuje statycznie wygenerowane trasy.
• Dane strukturalne (JSON-LD) znajdują się w renderowanym serwerowo <head>.
• Jeśli włączono <ClientRouter />, sprawdź próbkę, aby potwierdzić, że każdy adres URL nadal zwraca pełny HTML przy bezpośrednim pobraniu.
• Trasy na żądanie/serwerowe: pobierz bezpośrednio produkcyjny adres URL i potwierdź kod statusu, zachowanie przekierowania oraz pełny HTML odpowiedzi — nie ekstrapoluj z lokalnego środowiska, ponieważ zachowanie adaptera i środowiska uruchomieniowego może się różnić.

Modele mentalne

1. Surowy HTML jest gotową stroną — dla domyślnego trybu tej trasy. Statyczny tryb wyjściowy Astro oznacza, że dla prerenderowanej trasy nie ma fali renderowania, na którą trzeba czekać — to, co pobiera Googlebot, jest tym, co zostaje zaindeksowane. To domyślne ustawienie dla trasy, a nie gwarancja dla całej witryny (output: 'server' i prerender mogą je zmienić), więc sprawdź trasę, a nie tylko konfigurację najwyższego poziomu. Gdy zasada ma zastosowanie, View Source jest prawdą (odwrotnie niż w SPA z CSR) — ale upewnij się, że ma zastosowanie, zanim uznasz ją za fakt.

2. Podstawa, nie wykończenie i nie gwarancja rezultatu. Astro daje czysty HTML i dobre mechanizmy wydajności bez dodatkowej pracy. Wszystko, co przekazuje wyszukiwarkom znaczenie — meta, adres kanoniczny, mapa witryny, schema — jest celowym krokiem, który dodajesz samodzielnie. „Dobra architektura” ≠ „gotowe” i żadne z tych stwierdzeń nie dowodzi indeksowalności, indeksowania ani rankingów — trzeba je nadal zweryfikować na wdrożonej witrynie.

3. Wyspy są addytywne — z wyjątkiem client:only. Interaktywność nakłada się na HTML, nigdy pod nim, w przypadku client:load/client:idle/client:visible: te dyrektywy dodają JS do jednego komponentu bez usuwania treści z podstawy możliwej do crawlowania. client:only łamie ten wzorzec — całkowicie pomija renderowanie serwerowe, więc bez odpowiedniego planu jest prawdziwą luką w statycznym HTML-u, a nie dodatkiem. Hydratacja wysp jest selektywna, a nie resumowalna — nie mieszaj tych pojęć.

4. Statyczną powłokę widzą crawlery. W przypadku Server Islands crawler odczytuje treść zastępczą ze statycznej powłoki, a nie treść odroczoną. Zasada decyzyjna: treść indeksowalna trafia do głównego szablonu, a treść spersonalizowana/dynamiczna do wyspy.

5. Usprawnienie przeglądarki ≠ zmiana struktury. View Transitions zmienia doświadczenie w przeglądarce (miękka nawigacja przez history.pushState), ale nie doświadczenie crawlowania (każdy adres URL nadal jest pełną stroną HTML). Usprawnienia, które pozostawiają bazową MPA bez zmian, są bezpieczne dla SEO.

6. Waliduj w czasie budowania. Content Collections + Zod zmieniają „pamiętaj, aby dodać tytuł” w „budowanie nie wyśle strony bez tytułu”. Wprowadź wymagania SEO do systemu typów, a przestaną być rzeczami, o których można zapomnieć.

Astro SEO — ściąga

Co jest automatyczne, a co zależy od Ciebie

Tryby wyjścia

Dyrektywy Islands

• client:load — hydratyzuj natychmiast.
• client:idle — hydratyzuj, gdy przeglądarka jest bezczynna.
• client:visible — hydratyzuj po przewinięciu do pola widzenia (najlepsze dla treści poniżej pierwszego ekranu; chroni LCP).
• client:only — całkowicie pomija renderowanie serwerowe. Dla tego komponentu nie ma HTML-u, dopóki przeglądarka go nie zahydratuje; w przeciwieństwie do pozostałych dyrektyw nie jest addytywne.

Szybkie zasady

• Brak site: → brak mapy witryny (po cichu).
• Indeksowalna treść w Server Island → crawler widzi treść zastępczą; Server Islands potrzebują adaptera.
• Indeksowalna treść wyłącznie w client:only → brak HTML-u tej treści, kropka.
• Mapa witryny obejmuje trasy statyczne → dodaj adresy tylko runtime przez customPages.
• View Transitions używa history.pushState → bezpieczne dla SEO, bazą pozostaje MPA.
• Wyjście statyczne/serwerowe i wyspy są mechanizmami, a nie gwarancjami — zweryfikuj wdrożoną trasę, kod statusu i pełny HTML, zanim przypiszesz jej rezultat.
• Szybka pusta strona nadal nie zajmuje pozycji — szybkość jest jednym z sygnałów, a nie jedynym sygnałem.

Audyt zbudowanego HTML-u Astro

Uruchom to po astro build. Sprawdza artefakt otrzymywany przez crawlery, a nie drzewo komponentów źródłowych:

find dist -name '*.html' -type f | while IFS= read -r file; do
  canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$file" | wc -l | tr -d ' ')
  titles=$(grep -Eio '<title>[^<]*</title>' "$file" | wc -l | tr -d ' ')
  if [ "$canonicals" -ne 1 ] || [ "$titles" -ne 1 ]; then
    printf '%s\ttitles=%s\tcanonicals=%s\n' "$file" "$titles" "$canonicals"
  fi
done

Pusty wynik oznacza, że każdy wygenerowany plik HTML ma dokładnie jeden tytuł i jeden adres kanoniczny; nie sprawdza, czy ich wartości są poprawne, więc te wartości trzeba próbkować osobno. Kontrola dotyczy wyłącznie artefaktu budowania — nie mówi nic o trasach na żądanie (output: 'server') ani Server Islands, które nie istnieją jako pliki statyczne.

Sprawdzanie tras na żywo w produkcji

W przypadku wszystkiego, co renderuje się na żądanie — tras output: 'server', tras z prerender = false albo Server Islands — powyższa kontrola artefaktu budowania nie ma zastosowania. Sprawdź zamiast tego rzeczywistą odpowiedź wdrożenia:

# Replace with your real URLs
for url in "https://example.com/" "https://example.com/some-server-route/"; do
  echo "== $url =="
  curl -sS -D - -o /dev/null "$url" | grep -Ei '^(HTTP|location|cache-control):'
done

Sprawdź oczekiwany kod statusu (200 dla działającej strony, rzeczywisty kod przekierowania, jeśli następuje — nie zakładaj 302 zamiast 301 bez sprawdzenia) i potwierdź, że curl -sS "$url" zwraca pełne oznaczenie, a nie powłokę zastępczą, jeśli sprawdzasz stronę zawierającą Server Island. Rób to na produkcji, a nie przez astro dev — zachowanie adaptera i środowiska uruchomieniowego może się różnić.

Narzędzia dla witryny Astro

• @astrojs/sitemap — oficjalna integracja mapy witryny (astro add sitemap). Nie zapomnij o site: w konfiguracji.
• astro-seo (npm) — opcjonalny komponent społecznościowy łączący tytuł, opis, karty Open Graph, Twittera i adres kanoniczny w jednym tagu.
• astro-seo-schema (npm) — typowany pomocnik danych strukturalnych JSON-LD dla Astro.
• astro:assets <Image> / <Picture> — wbudowana optymalizacja obrazów (WebP/AVIF, wymiary, lazy loading, wymuszanie alt).
• Kontrola adresu URL (Google Search Console) — potwierdź, że treść znajduje się w HTML-u crawlowanym (w Astro powinna być już widoczna w View Source — to szybka kontrola rozsądku).
• Crawler renderujący JavaScript — Ahrefs Site Audit lub Screaming Frog do sprawdzenia zgodności surowego i wyrenderowanego HTML-u w całej witrynie (na trasach prerenderowanych powinny się zgadzać — potwierdź to, nie zakładaj; osobno sprawdź trasy na żądanie i Server Islands).
• IndexNow — połącz z krokiem wdrożenia/publikacji, aby Bing i Yandex od razu dowiadywały się o nowych stronach statycznych.

Sprawdź się: Astro SEO

Pięć krótkich pytań o wpływ architektury Astro na SEO. Wybierz odpowiedź na każde pytanie, a następnie sprawdź.

Zasoby warte uwagi

Moje powiązane teksty

• JavaScript SEO: A Definitive Guide — podstawy renderowania wyjaśniające, dlaczego wyjście Astro oparte na HTML-u jest tak dużą zaletą.
• The Beginner’s Guide to Technical SEO — miejsce wyboru frameworka w szerszym obrazie.

Moje wystąpienia

• How Search Works (SlideShare) — moje omówienie crawlowania, renderowania, indeksowania i rankingów — procesu, który domyślny SSG Astro skraca. (Stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne”.)

Z branży

• Astro Docs: Islands Architecture — autorytatywne wyjaśnienie usuwania JS po stronie klienta przez Astro.
• Astro Docs: @astrojs/sitemap — oficjalna konfiguracja, wymóg site: oraz opcje filter/serialize/i18n.
• Astro Docs: Server Islands — server:defer, treść zastępcza i zachowanie pobierania po stronie klienta, którego crawlery nie widzą.
• Joost de Valk: Astro SEO Complete Guide — najbardziej autorytatywny przewodnik praktyka, autorstwa założyciela Yoast; mocny w obszarze nowoczesnych wzorców gotowych na AI i IndexNow.
• Google Search Central: Understand JavaScript SEO Basics — kolejka renderowania, linki możliwe do crawlowania i wytyczne History API, za którymi podąża View Transitions Astro.
• Astro: 2023 Web Framework Performance Report — dane Core Web Vitals porównujące Astro z innymi frameworkami.
• Search Engine Journal: Core Web Vitals, WordPress i Astro — niezależne omówienie porównania wydajności Astro i WordPressa.

Statystyki warte cytowania

Wszystkie poniższe liczby pochodzą z raportu Astro 2023 Web Framework Performance Report (oraz z omówienia SEJ); traktuj je jako benchmarki z epoki 2023, a nie aktualne wartości.

• Ponad 50% witryn Astro przechodzi ocenę Google Core Web Vitals — powyżej średniej branżowej wynoszącej około 40,5%; Astro i SvelteKit były jedynymi dużymi frameworkami przekraczającymi tę bazę (Next.js około 25%, Nuxt około 20%). Source
• Wskaźnik zaliczeń INP dla Astro: 68,8% — przypisany architekturze MPA (brak nawigacji sterowanej JS), która zostawia główny wątek wolny. Source
• Mediana wagi strony: 1,65 MB — najniższa w zbiorze danych. Source
• LCP: Astro około 0,44 s wobec WordPressa około 0,81 s — według porównania w raporcie około 46% szybciej. Coverage

Dziennik zmian