SEO w Astro oraz techniczne przygotowanie pod wyszukiwarki AI

Co Astro daje pod SEO już na starcie?

Oto, co Astro dostarcza już w standardzie:

• Statyczny HTML. Google i inne roboty indeksujące dostają gotowy kod, więc nie ma zależności od JavaScriptu.

• Zero JS domyślnie. LCP i TTI na poziomie, który w Next.js trzeba zdobyć optymalizacjami.

• Natywna optymalizacja obrazów przez astro:assets. WebP/AVIF, responsywny srcset, lazy loading.

• Routing oparty na plikach i czyste URL-e. /blog/moj-wpis/ zamiast ?page=123.

• Content Collections z walidacją. Spójne metadane na poziomie systemu (szerzej w osobnym wpisie).

To baza, dzięki której świeżo postawiona strona Astro startuje z Lighthouse Performance powyżej 95 punktów i to bez żadnych dodatkowych optymalizacji.

Core Web Vitals w Astro: co trzeba mierzyć?

Google używa 3 metryk jako czynnika rankingowego:

1. LCP (Largest Contentful Paint), czyli czas do wyrenderowania największego elementu widocznego w początkowym oknie przeglądarki (viewport). Dobry wynik to < 2,5 s.
2. INP (Interaction to Next Paint), czyli czas reakcji strony na interakcję użytkownika; dobra strona to < 200 ms (metryka zastąpiła FID w marcu 2024).
3. CLS (Cumulative Layout Shift), czyli sumaryczna niestabilność układu; dla dobrej strony to < 0,1.

Astro naturalnie dobrze sobie radzi z LCP i INP (zero JS = brak blokowania renderowania, brak opóźnień hydracji), a CLS wymaga uwagi zawsze — niezależnie od frameworka.

Optymalizacja LCP w Astro

Najczęściej elementem LCP jest główny obraz (hero) na stronie głównej lub banner w nagłówku artykułu. Priorytety:

1. Wstępne ładowanie (preload) kluczowego obrazu.

<Image
  src={heroImage}
  alt="Hero"
  width={1200}
  height={630}
  loading="eager"
  fetchpriority="high"
/>

loading="eager" połączony z fetchpriority="high" mówi przeglądarce, że obraz krytyczny i ma go pobrać jako pierwszy.

2. Wstępne połączenie (preconnect) z siecią CDN obrazów.

<link rel="preconnect" href="https://cdn.yoursite.com" />

3. Optymalny format. Astro z astro:assets automatycznie generuje WebP/AVIF, ale dla bardzo krytycznych obrazów rozważ ręczne sprawdzenie wagi, ponieważ zdarza się, że JPEG z wyższą kompresją bije wagą AVIF.

4. Hosting blisko użytkownika. Cloudflare, Vercel, Netlify mają globalne CDN. Samodzielne hostowanie na VPS w Niemczech dla polskiej publiki to mierzalne straty w LCP.

Optymalizacja CLS w Astro

Głównym źródłem CLS są obrazy bez zdefiniowanych wymiarów i późno ładujące się fonty.

Obrazy — zawsze podawaj width i height:

<Image src={img} alt="..." width={800} height={450} />

Przeglądarka rezerwuje przestrzeń jeszcze przed pobraniem obrazu i układ nie skacze.

Fonty — wdrażaj Fonts API ustabilizowane w Astro 6 (top-level klucz fonts):

import { defineConfig, fontProviders } from 'astro/config'
 
export default defineConfig({
  fonts: [
    {
      provider: fontProviders.google(),
      name: 'Inter',
      cssVariable: '--font-inter',
      // Astro generuje optymalne fallbacki z podobnymi metrykami
    },
  ],
})

Astro automatycznie generuje czcionkę zastępczą o metrykach zbliżonych do kroju docelowego, dzięki czemu tekst nie przeskakuje na stronie w momencie, gdy właściwy krój pisma w pełni się załaduje.

Server Islands. Dodawaj slot zastępczy (fallback slot) z tą samą wysokością co finalna zawartość. Szerzej o tym w artykule o Server Islands.

Optymalizacja INP w Astro

INP to metryka sprawdzająca, jak szybko strona reaguje na akcje użytkownika — kliknięcia, dotknięcia ekranu czy pisanie na klawiaturze. W Astro wyniki INP zazwyczaj są świetne z samego założenia (mniej JavaScriptu to po prostu szybsza reakcja), ale i tu zdarzają się wąskie gardła. Na co trzeba uważać?

• Zbyt ciężkie komponenty z dyrektywą client:load — ładowanie wszystkiego od razu niepotrzebnie obciąża przeglądarkę. Tam, gdzie to tylko możliwe, przerzucaj się na client:visible, żeby skrypty wkraczały do akcji dopiero wtedy, gdy element pojawia się na ekranie.
• Skrypty zewnętrzne — analityka, widgety czatu czy osadzone posty z mediów społecznościowych potrafią mocno "zaciąć" interfejs. Wszystko, co nie jest krytyczne, ładuj z atrybutem async lub defer, żeby nie blokowało parsowania strony — defer zachowuje kolejność wykonania, async uruchamia skrypt od razu po pobraniu.
• Długie operacje blokujące interfejs (tzw. long tasks) — o ile React od wersji 18 częściowo ratuje sytuację trybem współbieżnym, o tyle dla wysp bez Reacta zasada jest prosta: nigdy nie podpinaj ciężkich, synchronicznych zadań bezpośrednio pod kliknięcia użytkownika, by nie "zamrażać" strony.

Metadane w Astro i <head> jako element technicznego SEO

Każda strona powinna mieć:

---
// src/layouts/Layout.astro
const { title, description, image, canonical } = Astro.props;
const canonicalURL = new URL(canonical ?? Astro.url.pathname, Astro.site);
---
 
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
 
  <title>{title} | NazwaFirmy</title>
  <meta name="description" content={description} />
  <link rel="canonical" href={canonicalURL} />
 
  <!-- Open Graph -->
  <meta property="og:type" content="website" />
  <meta property="og:url" content={canonicalURL} />
  <meta property="og:title" content={title} />
  <meta property="og:description" content={description} />
  {image && <meta property="og:image" content={new URL(image, Astro.site)} />}
 
  <!-- Twitter Card -->
  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:title" content={title} />
  <meta name="twitter:description" content={description} />
  {image && <meta name="twitter:image" content={new URL(image, Astro.site)} />}
 
  <!-- Favicons i inne -->
  <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
  <meta name="generator" content={Astro.generator} />
</head>

Kluczowy element to <link rel="canonical">, ponieważ bez niego ryzykujesz powielenie treści (duplikację contentu), np. /blog/wpis/ vs /blog/wpis?ref=twitter traktowane jako osobne strony. Dzięki canonical Google wie, która wersja jest oryginalna (kanoniczna).

Dla kolekcji treści (Content Collections) metadane naturalnie wiążą się ze schematem Zod, ponieważ każdy artykuł ma wymagany title i description, które są walidowane podczas budowania projektu.

Dane uporządkowane (structured data) Schema.org w Astro

Dane uporządkowane pomagają Google zrozumieć treść i generować wyniki rozszerzone, takie jak gwiazdki, przepisy, wydarzenia czy elementy produktowe. W 2026 roku są też sensownym fundamentem pod GEO/AEO, ponieważ organizują informacje w formacie łatwym do maszynowej interpretacji.

Article / BlogPosting

---
const { post } = Astro.props;
 
const jsonLd = {
  '@context': 'https://schema.org',
  '@type': 'BlogPosting',
  headline: post.data.title,
  description: post.data.description,
  datePublished: post.data.date.toISOString(),
  dateModified: (post.data.updated ?? post.data.date).toISOString(),
  author: {
    '@type': 'Person',
    name: 'Jan Kowalski',
    url: 'https://example.com/o-mnie/',
  },
  publisher: {
    '@type': 'Organization',
    name: 'StriveLab',
    logo: {
      '@type': 'ImageObject',
      url: 'https://example.com/logo.png',
    },
  },
  image: post.data.image ? `https://example.com${post.data.image}` : undefined,
  mainEntityOfPage: {
    '@type': 'WebPage',
    '@id': new URL(Astro.url.pathname, Astro.site).toString(),
  },
};
---
 
<script type="application/ld+json" set:html={JSON.stringify(jsonLd)} />

FAQ

Jeśli strona zawiera sekcję FAQ, dodaj FAQPage jako strukturę danych. Zastrzeżenie: Google wyświetla wyniki rozszerzone dla FAQ głównie dla autorytatywnych domen rządowych i zdrowotnych — wdrażaj to dla sygnałów semantycznych i GEO/AEO, nie jako gwarantowany snippet w wynikach.

---
const faqs = [
  { question: 'Czy Astro jest lepsze od Next.js?', answer: 'To zależy od projektu...' },
  { question: 'Czy mogę używać Reacta w Astro?', answer: 'Tak, Astro obsługuje różne biblioteki UI...' },
];
 
const faqJsonLd = {
  '@context': 'https://schema.org',
  '@type': 'FAQPage',
  mainEntity: faqs.map((faq) => ({
    '@type': 'Question',
    name: faq.question,
    acceptedAnswer: {
      '@type': 'Answer',
      text: faq.answer,
    },
  })),
};
---
 
<script type="application/ld+json" set:html={JSON.stringify(faqJsonLd)} />

Organization schema na stronie firmowej

{
  '@context': 'https://schema.org',
  '@type': 'Organization',
  name: 'NazwaFirmy',
  url: 'https://example.com',
  logo: 'https://example.com/logo.png',
  sameAs: [
    'https://linkedin.com/in/jan-kowalski',
    'https://github.com/nazwa',
  ],
  contactPoint: {
    '@type': 'ContactPoint',
    email: 'contact@example.com',
    contactType: 'customer service',
  },
}

Sitemap i robots.txt w Astro

Astro udostępnia oficjalną integrację @astrojs/sitemap, która podczas budowania projektu generuje pliki /sitemap-index.xml i /sitemap-0.xml.

npx astro add sitemap

Konfiguracja:

// astro.config.mjs
import sitemap from '@astrojs/sitemap'
 
export default defineConfig({
  site: 'https://example.com',
  integrations: [
    sitemap({
      filter: (page) => !page.includes('/private/'),
      changefreq: 'weekly',
      priority: 0.7,
      lastmod: new Date(),
      i18n: {
        defaultLocale: 'pl',
        locales: {
          pl: 'pl-PL',
          en: 'en-US',
        },
      },
    }),
  ],
})

robots.txt tworzysz ręcznie w public/robots.txt:

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap-index.xml

Dla robotów AI, jeśli chcesz je wykluczyć:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Nie blokuj robotów AI. Perplexity, ChatGPT Search i Gemini generują realne wejścia — blokowanie ich w 2026 roku to odcięcie od rosnącego kanału dystrybucji treści. To decyzja biznesowa, a dane wskazują jeden kierunek.

GEO i AEO w Astro, czyli widoczność w odpowiedziach AI

Generative Engine Optimization (GEO) i Answer Engine Optimization (AEO) to nowe warstwy SEO, kierowane pod Perplexity, ChatGPT, Claude, Gemini czy SearchGPT. Podstawy są podobne do klasycznego SEO, ale kilka akcentów przesuwa się gdzie indziej.

Strukturalność ponad styl. AI lepiej rozumie treść z jasnymi nagłówkami (H2, H3), punktami, definicjami, zestawieniami. Czego nie lubi? Dużych bloków tekstów bez struktury.

Pierwsze zdanie każdej sekcji musi być esencją. AI często cytuje otwarcie paragrafu. Pisz tak, żeby pierwsze zdanie odpowiadało na pytanie zawarte w nagłówku, a z kolei reszta paragrafu to jego rozwinięcie.

Dane uporządkowane (Article, FAQ, HowTo tam, gdzie realnie pasuje do treści) porządkują znaczenie strony. Pomagają robotom i systemom wyszukiwania zrozumieć relacje między pytaniami, odpowiedziami, autorem i datami.

Czysty HTML bez zbędnego runtime'u. Astro zyskuje tu przewagę: mniej skryptów startowych, mniej hydracji i prostszy, semantyczny kod źródłowy. Roboty indeksujące AI otrzymują dokument bliższy klasycznej stronie HTML niż rozbudowanej aplikacji renderowanej po stronie klienta.

Świeża treść z dateModified. Modele AI faworyzują aktualne źródła. Zaktualizowanie artykułu i podbicie dateModified w danych uporządkowanych daje jasny sygnał, że ta strona jest aktualna.

Robotów AI w robots.txt nie blokujesz, chyba że świadomie rezygnujesz z tego kanału. Cytowanie przez systemy AI zwiększa prawidłowa architektura treści: semantyczne nagłówki, czyste odpowiedzi, aktualne dateModified. Gwarancji nie ma, ale prawdopodobieństwo rośnie.

Linkowanie wewnętrzne na stronie Astro

Astro nie narzuca domyślnej strategii linkowania wewnętrznego, ale budowa klastrów tematycznych, czyli grup powiązanych artykułów linkujących do siebie nawzajem, to jedna z najskuteczniejszych technik SEO w 2026 roku.

Praktycznym przykładem są wszystkie moje artykuły o Astro, które odsyłają do siebie nawzajem — architektura wysp, dyrektywy klienckie, Content Collections, Server Islands i Astro vs Next.js. Google rozpoznaje klaster „Astro” i traktuje całość jako silniejsze źródło tematyczne.

W Content Collections możesz to zautomatyzować: wystarczy zdefiniować w schemacie Zod pole relatedPosts jako referencję do kolekcji blog, a następnie w szablonie artykułu wyrenderować na tej podstawie automatyczną sekcję „Zobacz też”.

Audyt SEO w Astro: praktyczne narzędzia

Wdrożenie strony to dopiero początek, ponieważ widoczność utrzymujesz regularnym audytem. Zerknij na pięć narzędzi, które mierzą to, co rankuje:

1. Google Search Console. Absolutna podstawa zdrowia dla stron internetowych i to od wielu lat. To tutaj wyłapiesz błędy indeksacji, sprawdzisz realne wyniki Core Web Vitals i zobaczysz, po jakich hasłach użytkownicy rzeczywiście wchodzą na stronę. Odwiedzaj przynajmniej raz na tydzień, szczególnie na początku projektu lub po wielu zmianach na stronie.
2. PageSpeed Insights. Świetne do szybkiego diagnozowania wydajności i szukania technicznych wąskich gardeł na konkretnych podstronach.
3. Lighthouse (wbudowany w Chrome DevTools). Idealny do lokalnego testowania zmian, sprawdzania dostępności (Accessibility) i dobrych praktyk jeszcze przed wypuszczeniem kodu na produkcję.
4. Screaming Frog. Niezastąpiony przy większych serwisach, ponieważ pozwala „przeskanować” całą witrynę, znaleźć uszkodzone linki, brakujące metadane oraz wyłapać zduplikowane treści.
5. Ahrefs / Semrush, jeśli traktujesz SEO znacznie bardziej poważnie, to tutaj prześledzisz widoczność swojej domeny, profil linków oraz wszelkie ruchy konkurencji.

A jeśli wolisz oddać te kwestie w ręce kogoś, kto zajmuje się tym na co dzień — zerknij na mój audyt techniczny SEO. Przeprowadzę kompleksową analizę Twojej aplikacji i przygotuję gotowy plan optymalizacji (albo po prostu wdrożę go za Ciebie).

Diagnostyka SEO specyficzna dla Astro

Klasyczne narzędzia audytowe (GSC, Screaming Frog, Lighthouse) dobrze mierzą objawy. W Astro są jednak cztery obszary, gdzie przyczyna leży głębiej — w konfiguracji frameworka i architekturze tras — i gdzie ogólny raport narzędzia nie powie Ci, co poprawić.

Dyrektywy client:* a widoczność dla crawlerów AI

Astro domyślnie nie wysyła żadnego JavaScriptu. Każda dyrektywa client:* to świadoma decyzja o oddaniu renderowania przeglądarce i bezpośrednia konsekwencja dla crawlerów, które nie wykonują JS.

Zasada diagnostyczna: jeśli krytyczna treść (nagłówek, opis usługi, sekcja FAQ) znajduje się wewnątrz komponentu z dowolną dyrektywą client:*, dla GPTBota, ClaudeBota i Perplexity ta treść nie istnieje.

Jak to sprawdzić:

# Co crawler dostaje bez wykonywania JS?
curl -s https://twojadomena.pl/ | grep -i "twoja-kluczowa-fraza"

Jeśli curl nie zwraca oczekiwanej treści, masz komponent z client:* zamiast statycznego HTML-a. Rozwiązanie: przenieś statyczną treść na poziom layoutu lub komponentu .astro bez dyrektywy, a interaktywność zachowaj jako cienką warstwę na wierzchu.

Tryb renderowania per trasa w Astro

Astro pozwala mieszać trasy statyczne i serwerowe w jednym projekcie. To elastyczne, ale łatwo stracić kontrolę nad tym, co się faktycznie buduje statycznie.

# Sprawdź, czy adapter SSR jest aktywny
astro check

Ważniejsze jest ręczne sprawdzenie kluczowych tras. W pliku .astro lub w getStaticPaths:

---
// Trasa statyczna (domyślna przy braku adaptera SSR)
// export const prerender = true  ← domyślne, można nie pisać
 
// Trasa serwerowa — render on-demand
export const prerender = false
---

Zagrożenie polega na tym, że korzystając z adaptera SSR, takiego jak Cloudflare lub Node, brak jawnego ustawienia dyrektywy prerender = true na kluczowych stronach sprawia, że cała aplikacja automatycznie staje się dynamiczna. Witryny takie jak strony marketingowe, blog czy podstrony usługowe powinny pozostać w pełni statyczne, dlatego po zakończonym procesie budowania warto zawsze zweryfikować katalog dist, który dla każdej z tych tras powinien zawierać gotowe pliki w formacie HTML.

# Po astro build — sprawdź, co jest statycznym HTML-em
find dist -name "*.html" | head -20
ls dist/blog/

Brak pliku dist/blog/moj-wpis/index.html przy trasie, która powinna być statyczna, to sygnał że trasa renderuje się dynamicznie — i ma gorszy TTFB oraz jest potencjalnie niewidoczna dla crawlerów bez JS.

Sitemap a trasy serwerowe i endpointy API

@astrojs/sitemap domyślnie zbiera wszystkie trasy projektu, w tym pliki z src/pages/api/. Endpointy API (np. src/pages/api/search.ts, src/pages/api/contact.ts) nie powinny trafiać do sitemapy.

Weryfikacja po buildzie:

# Sprawdź, co weszło do sitemapy
cat dist/sitemap-0.xml | grep "<loc>"

Jeśli widzisz /api/ w wynikach — odfiltruj:

// astro.config.mjs
sitemap({
  filter: (page) =>
    !page.includes('/api/') &&
    !page.includes('/private/') &&
    !page.includes('/draft/'),
})

Druga pułapka: strony z prerender = false (SSR) nie trafiają automatycznie do sitemapy generowanej podczas builda, bo Astro nie zna ich adresów statycznie. Jeśli masz wartościowe, serwerowe trasy (np. wyniki wyszukiwania z czystym URL), musisz dodać je ręcznie przez opcję customPages:

sitemap({
  customPages: ['https://twojadomena.pl/szukaj/popularne'],
})

Content Collections i brakujące strony w indeksie

W przypadku renderowania po stronie serwera z wykorzystaniem kolekcji treści może pojawić się trudny do wykrycia problem, w którym proces budowania kończy się pełnym sukcesem, jednak dla konkretnych wpisów generowany jest pusty kod HTML. Najczęstszą przyczyną takiej sytuacji jest niezgodność schematu walidacji Zod z danymi zdefiniowanymi w sekcji frontmatter.

# Podczas astro build — szukaj ostrzeżeń o kolekcjach
astro build 2>&1 | grep -i "warn\|error\|collection"

Dla artykułów, które mają być statyczne, zawsze waliduj lokalnie przed deploymentem:

astro check && astro build

astro check łapie błędy TypeScript i schematu Zod zanim cokolwiek trafi na serwer i jest szybszy niż debugowanie pustych stron w GSC.

Lista kontrolna SEO w Astro przed publikacją

Przed publikacją każda strona przechodzi przez krótki zestaw techniczny, który oczywiście nie zastępuje pracy redakcyjnej, ale eliminuje błędy wpływające na widoczność.

• title, description, link kanoniczny i Open Graph są ustawione na finalne wartości, bez tekstów zastępczych.

• Jeśli strona jest wielojęzyczna, hreflang wskazuje poprawne odpowiedniki językowe.

• Obraz LCP ma stałe wymiary, sensowny alt, właściwy format i priorytet ładowania.

• Treść, która ma rankować, jest w HTML-u, a nie dopiero w klienckim komponencie.

• Schema.org pasuje do realnej treści strony; FAQ wynika z sekcji faqs: i nie dubluje ręcznie dopisanych bloków.

• Sitemap zawiera tylko kanoniczne, opublikowane URL-e, a robots.txt ich nie blokuje.

• W artykule znajdują się linki wewnętrzne do powiązanych wpisów i usług, ale bez nienaturalnego upychania słów kluczowych w anchorach.

• Po publikacji weryfikujesz losowy adres URL w Search Console URL Inspection albo przez curl, aby upewnić się, że renderowanie HTML działa poprawnie.