Plik llms.txt w Next.js i Astro: wdrożenie i format

Czym jest llms.txt i do czego służy?

llms.txt to propozycja standardu opisana na llmstxt.org, która zakłada umieszczenie w głównej ścieżce witryny pliku /llms.txt. Jego zadaniem jest dostarczenie modelom językowym pomocnej informacji w momencie wnioskowania (inference time).

Twórcy standardu wyszli z konkretnej obserwacji: modele coraz mocniej polegają na treściach z witryn, ale uderzają w twarde ograniczenie — ich okna kontekstowe są zbyt małe, by zmieścić większość stron w całości. Konwersja zaśmieconego HTML-a z nawigacją, reklamami i JavaScriptem na czysty tekst zrozumiały dla LLM jest trudna i nieprecyzyjna. Witryny obsługują zarówno ludzi, jak i modele, ale to drugie korzystają najbardziej z eksperckiej, zwięzłej informacji zebranej w jednym, łatwo dostępnym miejscu.

Plik celowo używa Markdowna zamiast XML-a. Markdown to dzisiaj najszerzej i najłatwiej rozumiany format, a jednocześnie wystarczająco rygorystyczny, by parsowały go standardowe narzędzia programistyczne.

Warto też rozróżnić dwa pokrewne pliki, ponieważ różnica między nimi jest istotna: llms.txt to indeks — swego rodzaju spis treści z linkami do najważniejszych stron, i to właśnie jego potrzebuje większość witryn. llms-full.txt to już pełny eksport treści całej witryny w jednym dużym dokumencie Markdown, używany zwykle dla dokumentacji deweloperskiej lub ingestii danych strukturalnych. Co ciekawe, ekosystem Astro ma trzeci wariant — llms-small.txt — przefiltrowaną i kompaktową wersję dla modeli z mniejszym oknem kontekstowym.

llms.txt a robots.txt: czym się różnią?

robots.txt i llms.txt nie są wersjami tego samego — obsługują dwa fundamentalnie różne modele dostępu do treści.

Tradycyjne crawlery wyszukiwarek działają w trybie wsadowym: systematycznie skanują i indeksują całą witrynę, regularnie wracają w poszukiwaniu zmian, słuchają reguł robots.txt i sitemap.xml, a treść przechowują długoterminowo do późniejszego serwowania w wynikach.

Modele językowe rządzą się zupełnie inną logiką. Dostęp do treści uzyskują dopiero w chwili, gdy użytkownik zadaje pytanie — nie indeksują ani nie „pamiętają” Twojej strony na stałe. Wchodzą i wychodzą. Pracują w ograniczonym oknie kontekstowym, pomijają treści, które nie są wyraźnie podlinkowane lub łatwe do odczytania, i mają trudność z witrynami mocno opartymi na JavaScripcie i z zaśmieconym HTML-em.

Zestawienie pokazuje to najlepiej:

Jest jednak niuans, który trzeba postawić wprost, zanim potraktujesz llms.txt jako magiczny przełącznik. Stan na czerwiec 2026: główne crawlery LLM nadal nie dają publicznej gwarancji, że masowo respektują ten plik, a badania nad cytowalnością w odpowiedziach AI nie wykazują mierzalnej poprawy pozycji. Zmieniło się natomiast coś innego: Lighthouse sprawdza llms.txt w eksperymentalnej kategorii Przeglądanie Agentowe, czyli jako element gotowości strony dla agentów przeglądających i interpretujących witrynę.

Dźwignią, która realnie kontroluje, jak systemy AI traktują Twoją witrynę, wciąż pozostaje robots.txt z odpowiednio skonfigurowanymi regułami User-agent dla botów AI (jak GPTBot, ClaudeBot, Google-Extended czy CCBot). llms.txt nie decyduje, kto może wejść. Pomaga agentowi szybciej zrozumieć, gdzie są najważniejsze treści.

Dlaczego więc każdy poważny serwis deweloper-tools i tak wdraża llms.txt? Bo koszt to pół dnia pracy, a w dniu, w którym duży dostawca LLM zdecyduje się go respektować, będziesz już gotowy. Do tego dochodzi praktyczny bonus: poprawnie przygotowany plik usuwa jeden z punktów tarcia w audycie Przeglądania Agentowego. Trzymaj robots.txt w aktualności, wdrażaj llms.txt automatycznie i nie spodziewaj się skoku ruchu z dnia na dzień.

Format llms.txt: poprawna struktura pliku

Specyfikacja jest rygorystyczna w kwestii kolejności sekcji. Plik nazwany llm.txt w liczbie pojedynczej nie zostanie rozpoznany — to częsty błąd, który sam neutralizuje całą pracę. Kodowanie musi być UTF-8, a plik musi leżeć w katalogu głównym.

Oto wymagana struktura w odpowiedniej kolejności:

1. H1 z nazwą projektu lub witryny — to jedyna obowiązkowa sekcja.
2. Blockquote (>) z krótkim podsumowaniem, zawierającym kluczowe informacje potrzebne do zrozumienia reszty pliku.
3. Zero lub więcej sekcji Markdown (akapity, listy) dowolnego typu, ale bez nagłówków — z dodatkowym kontekstem.
4. Sekcje z linkami oznaczone nagłówkami H2, gdzie każdy link ma format [Tytuł strony](URL): krótki opis.
5. Opcjonalna sekcja ## Optional dla treści drugorzędnych, które model może pominąć przy ograniczonym kontekście.

Minimalny, poprawny przykład wygląda tak:

# Example Studio
 
> Example Studio to przykładowa firma specjalizująca się
> w aplikacjach React, Next.js i Astro oraz w doradztwie produktowym.
 
Kluczowe informacje o ofercie i realizacjach studia.
 
## Sekcja Services w llms.txt
 
- [Tworzenie stron w Astro](https://example.com/uslugi/astro/): Szybkie, statyczne witryny zorientowane na treść.
- [Aplikacje Next.js](https://example.com/uslugi/next-js/): Aplikacje React renderowane po stronie serwera.
- [Konsultacje product management](https://example.com/uslugi/konsultacje/): Wsparcie w planowaniu i rozwoju produktu cyfrowego.
 
## Sekcja Blog w llms.txt
 
- [Przewodnik po llms.txt](https://example.com/blog/plik-llms-txt/): Jak wdrożyć standard w Next.js i Astro.
 
## Sekcja Optional w llms.txt
 
- [Polityka prywatności](https://example.com/privacy-policy/): Dokument prawny.

• Tylko strony indeksowalne — odfiltruj URL-e oznaczone noindex lub zablokowane w robots.txt, by nie ujawniać ukrytych treści.

• Tylko adresy kanoniczne — każdy link prowadzi do głównej wersji strony, bez duplikatów.

• Świadomy dobór, a nie wszystko — jeśli wylistujesz każdy produkt i każdy wpis, model przekroczy okno kontekstowe i przestanie czytać, pomijając krytyczne sekcje jak FAQ. Lepsza jest mapa sztabowa hubów kategorii niż kompletna inwentaryzacja magazynu.

Jak wdrożyć llms.txt w Astro?

Astro daje tu dwie ścieżki, a jej wybór zależy od tego, czy chcesz plik statyczny, czy generowany dynamicznie z kolekcji treści.

Astro: statyczny llms.txt w katalogu public/

Zawartość katalogu public/ jest kopiowana do outputu builda dosłownie, bez przetwarzania. Dla małego serwisu bez automatyzacji wystarczy ręcznie utworzyć public/llms.txt. To rozwiązanie zerowego nakładu, ale wymaga ręcznej aktualizacji — czyli prędzej czy później rozjedzie się z treścią.

Astro: endpoint llms.txt generowany z Content Collections

Dla bloga czy dokumentacji generuj plik dynamicznie z Content Collections. Tworzysz plik src/pages/llms.txt.ts:

import { getCollection } from 'astro:content'
import type { APIRoute } from 'astro'
 
export const GET: APIRoute = async ({ site }) => {
  const posts = await getCollection('blog', ({ data }) => !data.draft)
 
  const body = `# Example Blog
 
> Artykuły o frontendzie: React, Next.js, Astro, TypeScript oraz SEO/GEO.
 
## Sekcja Articles w llms.txt
 
${posts
  .map(
    (post) =>
      `- [${post.data.title}](${new URL(`blog/${post.id}/`, site)}): ${post.data.description}`,
  )
  .join('\n')}
`
 
  return new Response(body, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  })
}

Endpoint generuje się w czasie builda, więc ma zerowy wpływ na wydajność runtime’u. Używamy obiektu site z konfiguracji do budowy bezwzględnych URL-i i zwracamy standardowy Response z nagłówkiem text/markdown, by crawler dostał dokładnie to, czego oczekuje.

Jeśli korzystasz z integracji @astrojs/sitemap, endpointy są domyślnie wykluczane z mapy strony, więc nie musisz nic robić, by uniknąć duplikacji. Gdybyś chciał, żeby plik był odnajdywalny przez Google, dodaj go ręcznie do customPages.

Astro: gotowa integracja do llms.txt

Tam, gdzie nie zależy Ci na pisaniu od zera, sięgnij po gotowe integracje: astro-llms-generate czy @4hse/astro-llms-txt generują llms.txt, llms-small.txt i llms-full.txt podczas astro build, z opcjami includePatterns / excludePatterns. Dla witryn opartych na Starlight jest dedykowany starlight-llms-txt.

Generowanie llms-full.txt w Astro

Indeks to za mało, jeśli zależy Ci, by model dostał pełną treść bez wchodzenia na poszczególne podstrony. Tu wkracza llms-full.txt, który ma jeden plik z całą treścią w Markdownie. W Astro tworzysz osobny endpoint src/pages/llms-full.txt.ts, który zamiast samych linków wstawia pełne body każdego wpisu:

import { getCollection } from 'astro:content'
import type { APIRoute } from 'astro'
 
export const GET: APIRoute = async ({ site }) => {
  const posts = await getCollection('blog', ({ data }) => !data.draft)
 
  // Sortujemy od najnowszych — model czytający z ograniczonym
  // kontekstem dostanie najpierw najświeższą treść.
  const sorted = posts.sort(
    (a, b) =>
      new Date(b.data.datePublished).valueOf() -
      new Date(a.data.datePublished).valueOf(),
  )
 
  const sections = sorted.map((post) => {
    const url = new URL(`blog/${post.id}/`, site).href
    return `# ${post.data.title}
 
Źródło: ${url}
 
${post.data.description}`
  })
 
  const body = `# StriveLab Blog — pełna treść
 
> Kompletny eksport artykułów dla modeli AI: React, Next.js, Astro, TypeScript, SEO/GEO.
 
${sections.join('\n\n---\n\n')}
`
 
  return new Response(body, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  })
}

W tym przykładzie każda sekcja zawiera tytuł, URL i opis — to minimalny, bezpieczny wariant. Jeśli chcesz dołączyć pełną treść wpisu, potrzebujesz surowego Markdown: w Astro 5/6 z glob loaderem nie ma bezpośredniego post.body, dlatego treść odczytujesz przez readFile z dysku (tak jak w wariancie Next.js poniżej) albo przez render(post) i ekstrakcję tekstu. Sekcje rozdzielamy separatorem ---, żeby model widział granice między dokumentami z chirurgiczną precyzją. Przy dużych blogach pamiętaj, że llms-full.txt urośnie do setek kilobajtów — jeśli przekroczysz rozsądny rozmiar, dorzuć obok llms-small.txt z samymi tytułami i opisami dla modeli z mniejszym oknem.

Astro: filtrowanie noindex i draftów w llms.txt

Specyfikacja jest tu jednoznaczna: do llms.txt nie trafiają strony oznaczone noindex ani zablokowane w robots.txt. W praktyce w Astro masz dwa źródła takich flag — pole draft w schemacie kolekcji oraz dedykowane pole noindex (jeśli je prowadzisz). Filtr w getCollection obsłuży oba naraz:

import { getCollection } from 'astro:content'
import type { APIRoute } from 'astro'
 
export const GET: APIRoute = async ({ site }) => {
  const posts = await getCollection('blog', ({ data }) => {
    // Pomijamy szkice, treści wycofane i wszystko z noindex.
    if (data.draft) return false
    if (data.noindex) return false
    if (data.unlisted) return false
    return true
  })
 
  // Dodatkowo: tylko adresy kanoniczne.
  // Jeśli wpis ma własny canonical wskazujący gdzie indziej,
  // nie linkujemy do duplikatu.
  const indexable = posts.filter(
    (post) =>
      !post.data.canonicalURL || post.data.canonicalURL.includes('example.com'),
  )
 
  const body = `# Example Blog
 
> Artykuły o frontendzie: React, Next.js, Astro, TypeScript oraz SEO/GEO.
 
## Sekcja Articles w llms.txt dla Astro
 
${indexable
  .map(
    (post) =>
      `- [${post.data.title}](${new URL(`blog/${post.id}/`, site)}): ${post.data.description}`,
  )
  .join('\n')}
`
 
  return new Response(body, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  })
}

Zaletą tego podejścia jest to, że filtr żyje obok schematu kolekcji — jedno źródło prawdy steruje równocześnie indeksacją, sitemapą i llms.txt. Nie ma ryzyka, że oznaczysz wpis jako draft, a on i tak wycieknie do modeli AI.

Jak wdrożyć llms.txt w Next.js App Router?

W Next.js (App Router) najczystszym podejściem jest Route Handler. Tworzysz plik app/llms.txt/route.ts:

import { getAllPosts } from '@/lib/posts'
 
export const dynamic = 'force-static'
 
export async function GET() {
  const posts = await getAllPosts()
  const baseUrl = 'https://example.com'
 
  const body = `# Example Studio
 
> Przykładowe studio frontendowe: React, Next.js, Astro i doradztwo produktowe.
 
## Sekcja Blog w llms.txt dla Next.js
 
${posts
  .map((p) => `- [${p.title}](${baseUrl}/blog/${p.slug}): ${p.description}`)
  .join('\n')}
`
 
  return new Response(body, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  })
}

Kluczowy jest export const dynamic = 'force-static' — wymusza wygenerowanie pliku na etapie builda zamiast przy każdym żądaniu. Dla treści, która zmienia się tylko przy deployu, to idealny tryb pracy.

Jeśli wolisz statyczny plik bez logiki, w Next.js wystarczy umieścić llms.txt w katalogu public/ — tak jak w Astro będzie serwowany z roota.

Generowanie llms-full.txt w Next.js

Analogicznie do indeksu tworzysz app/llms-full.txt/route.ts, ale zamiast samego linku wstawiasz pełną treść wpisu. Zakładam tu, że Twoja warstwa danych (@/lib/posts) zwraca surowy Markdown w polu content — jeśli trzymasz treść w plikach MDX, najprościej odczytać ją funkcją pomocniczą czytającą pliki z dysku:

import { getAllPosts } from '@/lib/posts'
 
export const dynamic = 'force-static'
 
export async function GET() {
  const posts = await getAllPosts()
  const baseUrl = 'https://example.com'
 
  // Najnowsze najpierw — to one mają największą szansę
  // zmieścić się w oknie kontekstowym modelu.
  const sorted = posts.sort(
    (a, b) => new Date(b.date).getTime() - new Date(a.date).getTime(),
  )
 
  const sections = sorted.map(
    (p) => `# ${p.title}
 
Źródło: ${baseUrl}/blog/${p.slug}
 
${p.description}
 
${p.content}`,
  )
 
  const body = `# Example Blog — pełna treść
 
> Kompletny eksport artykułów dla modeli AI: React, Next.js, Astro, TypeScript, SEO/GEO.
 
${sections.join('\n\n---\n\n')}
`
 
  return new Response(body, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  })
}

Jeśli treść trzymasz w MDX i nie masz jej jeszcze jako surowego stringa, pomocnik do odczytu wygląda tak:

import { readFile } from 'node:fs/promises'
import path from 'node:path'
import matter from 'gray-matter'
 
export async function getPostRawContent(slug: string): Promise<string> {
  const filePath = path.join(process.cwd(), 'content', 'blog', `${slug}.mdx`)
  const raw = await readFile(filePath, 'utf-8')
  // Odcinamy frontmatter, zostawiamy samą treść Markdown.
  const { content } = matter(raw)
  return content
}

Next.js: filtrowanie noindex i draftów w llms.txt

W Next.js flagi sterujące indeksacją żyją zwykle we frontmatterze MDX (draft, noindex) i są mapowane na metadata.robots w funkcji generateMetadata poszczególnych stron. Żeby llms.txt nie rozjechał się z tym, co faktycznie pozwalasz indeksować, zastosuj ten sam filtr na liście wpisów:

import { getAllPosts } from '@/lib/posts'
 
export const dynamic = 'force-static'
 
export async function GET() {
  const posts = await getAllPosts()
  const baseUrl = 'https://example.com'
 
  const indexable = posts.filter((p) => {
    // Te same reguły, których używasz w generateMetadata.
    if (p.draft) return false
    if (p.noindex) return false
    // Tylko adresy kanoniczne wskazujące na naszą domenę.
    if (p.canonicalUrl && !p.canonicalUrl.includes('example.com')) return false
    return true
  })
 
  const body = `# Example Studio
 
> Przykładowe studio frontendowe: React, Next.js, Astro i doradztwo produktowe.
 
## Sekcja Blog w llms.txt i robots.txt w Next.js
 
${indexable
  .map((p) => `- [${p.title}](${baseUrl}/blog/${p.slug}): ${p.description}`)
  .join('\n')}
`
 
  return new Response(body, {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  })
}

llms.txt i robots.txt w Next.js

Filtrowanie treści to jedna strona medalu — druga to robots.txt. W Next.js generujesz go przez app/robots.ts:

import type { MetadataRoute } from 'next'
 
export default function robots(): MetadataRoute.Robots {
  return {
    rules: [{ userAgent: '*', allow: '/' }],
    sitemap: 'https://example.com/sitemap.xml',
  }
}

To właśnie reguły User-agent w robots.txt (dla GPTBot, ClaudeBot, Google-Extended, CCBot) dziś faktycznie sterują dostępem botów AI — llms.txt mówi modelowi, co warto przeczytać, ale robots.txt decyduje, czy w ogóle wolno mu wejść.

Warto odróżnić dwie rozmowy, które często są wrzucane do jednego worka. Dla Google Search llms.txt nie jest wymaganiem dla AI Overviews ani AI Mode. Dla Lighthouse kategoria Przeglądanie Agentowe jest natomiast opcjonalnym, ale sprawdzanym elementem warstwy „discoverability”. Jeśli chcesz zrozumieć tę różnicę bez marketingowego szumu, rozbieram ją osobno w tekście o Przeglądaniu Agentowym w PageSpeed Insights.

Dlaczego Next.js i Astro dobrze nadają się do llms.txt?

Dlaczego akurat te dwa frameworki tak dobrze grają z llms.txt? Bo oba mają wbudowaną warstwę treści strukturalnej — Content Collections w Astro i konwencje MDX/route handlers w Next.js — z której plik generuje się niemal za darmo jako produkt uboczny istniejącego pipeline’u. Nie tworzysz przy tym osobnego źródła prawdy.

• Spójność — plik aktualizuje się automatycznie przy każdym buildzie, więc nigdy nie rozjedzie się z faktyczną treścią.

• Higiena architektury — sam proces tworzenia llms.txt zmusza do przemyślenia, które treści naprawdę się liczą. Ta wartość istnieje nawet gdyby żaden model nigdy pliku nie przeczytał.

• Gotowość operacyjna — plik możesz od razu wykorzystać wewnętrznie: wgrać do projektu w Claude albo umieścić w katalogu Cursora jako kontekst, gdy pracujesz z asystentem AI nad audytem czy strategią treści.