# AEO — jak zoptymalizować stronę pod AI i Answer Engines Answer Engine Optimization, llms.txt, architektura wysp i szybkość jako waluta konwersji. Praktyczny przewodnik po optymalizacji stron pod modele językowe i wyszukiwarki generatywne. **Canonical:** https://spoko.space/pl/blog/aeo-optymalizacja-pod-ai/ **Language:** pl **Published:** 2026-04-20 **Tags:** AEO, llms.txt, SEO, AI, Astro, web development **Category:** Poradnik --- **Tradycyjne SEO skupione na liście niebieskich linków przestaje wystarczać.** Coraz więcej użytkowników zaczyna szukanie od ChatGPT, Perplexity, Gemini albo AI Overviews w Google — i dostaje jedną, syntetyczną odpowiedź. Aby Twoja marka była w tej odpowiedzi, strona musi być zrozumiała dla modeli językowych. To jest właśnie **Answer Engine Optimization (AEO)** — szerszy przewodnik po strategii opisuję w [artykule o architekturze AI, OpenClaw i AEO](https://uper.pl/blog/architektura-ai-openclaw-seo-aeo/). Ten tekst to praktyczny przewodnik, jak zoptymalizować stronę pod AEO — z konkretnymi technikami, liczbami i przykładami z wdrożeń, które prowadzę w spoko.space. --- ## Czym AEO różni się od klasycznego SEO | Aspekt | Tradycyjne SEO | AEO | |---|---|---| | Cel | Miejsce w TOP 10 linków | Być cytowanym w odpowiedzi AI | | Odbiorca treści | Ludzie klikający w wyniki | Modele LLM + ludzie | | Sygnał jakości | Linki, CTR, dwell time | Struktura danych, semantyka, cytowalność | | Format treści | Tekst długi, zoptymalizowany pod keyword | Precyzyjne odpowiedzi na konkretne pytania | | Narzędzia | Ahrefs, Semrush | `llms.txt`, JSON-LD, czysty semantyczny HTML | Tradycyjne SEO nie znika. Zmienia się warstwa dostarczania odpowiedzi — zamiast listy linków, użytkownik widzi gotową odpowiedź wygenerowaną przez AI, z podaniem źródeł. Twoja strona musi być wśród tych źródeł. --- ## Szybkość jako fundament Zanim LLM zaindeksuje Twoją stronę, musi ją pobrać. Serwisy wolne albo ukryte za ciężkim JavaScriptem często w ogóle nie trafiają do zbiorów treningowych ani do kontekstu generatywnego. Dlatego pierwszym krokiem AEO jest **radykalna redukcja wagi kodu**. Typowa strona WordPress z kilkoma pluginami ma 1–2 MB JS przed pierwszym renderem. Statyczna strona w [Astro](https://astro.build) z architekturą wysp — zwykle poniżej 80 KB. Różnica 15–25×. W praktyce oznacza to: - **LCP < 1 s** zamiast 4–8 s typowych dla CMS - **JavaScript włącza się tylko tam, gdzie jest interakcja** (np. formularz kontaktowy, wyszukiwarka) - Googlebot i crawlery LLM widzą kompletny HTML od razu, bez czekania na hydrację O skali trendu świadczy fakt, że w 2026 roku Cloudflare przejął zespół Astro i wydał [EmDash](https://uper.pl/blog/cloudflare-emdash-astro-seo/) — open-source CMS oparty na Astro 6 + Cloudflare Workers + D1. Infrastruktura obsługująca znaczną część światowego internetu stawia na architekturę, którą w spoko.space wdrażam od 2023 roku. --- ## llms.txt — standard dla AI-ready stron Analogicznie do `robots.txt` dla crawlerów Google, [llms.txt](https://llmstxt.org) to plik w korzeniu domeny, który mówi modelom językowym: *"tak powinna być rozumiana moja strona"*. Standard zaproponowany we wrześniu 2024, w 2026 staje się praktyką wdrażaną przez dojrzałe projekty. Typowa implementacja zawiera dwa pliki: - **`/llms.txt`** — skondensowany opis witryny z linkami do najważniejszych podstron (markdownowa mapa) - **`/llms-full.txt`** — pełna treść serwisu w jednym pliku, gotowa do wczytania przez model Dlaczego to działa? Modele językowe lepiej rozumieją Markdown niż HTML zaśmiecony reklamami, trackerami i szablonowymi elementami nawigacji. Podanie „czystego" streszczenia podnosi szansę na trafne cytowanie. Szczegóły implementacyjne i liczby redukcji tokenów analizuję osobno w tekście [llms-full.txt: 90% mniej tokenów i zero halucynacji AI](https://uper.pl/blog/llms-full-txt/). ### Przykład wdrożenia W katalogu części [catalog.polo.blue](https://spoko.space/pl/vw-polo-6r-parts-catalog/) — statycznym serwisie na Astro + Vue 3, który prowadzę — wdrożyłem oba pliki: - `/llms.txt` — ~8 KB, lista wszystkich kategorii części, linki do specyfikacji - `/llms-full.txt` — ~2 MB, pełne opisy produktów OEM, kompatybilność, kody PR, wszystkie trzy języki Efekt: odpowiedzi generatywne AI (testowane na ChatGPT i Perplexity) podają konkretne numery katalogowe części i cytują catalog.polo.blue jako źródło — zamiast ogólnikowych odpowiedzi „sprawdź u dealera VW". --- ## Architektura wysp — interaktywność bez kosztu wydajności W klasycznym SPA (React, Vue SPA) cała strona jest jedną aplikacją JavaScript. Ładowanie wymaga pobrania całego frameworka, hydracji, nawiązania połączeń API. Czas do pierwszej interakcji: 2–5 s. **Architektura wysp** odwraca tę logikę: szkielet strony to statyczny HTML, a interaktywność jest „wyspą" aktywowaną tylko wtedy, gdy użytkownik zaczyna z niej korzystać. W [moim porównaniu frameworków z 2026 roku](https://spoko.space/pl/blog/frameworki-aplikacje-webowe-2026/) opisuję to szerzej, ale kluczowy wniosek: **nie musisz wybierać między szybkością a funkcjonalnością**. Konkretne liczby z catalog.polo.blue (tysiące podstron, 3 języki): - **Weight przed interakcją:** 48 KB HTML + 12 KB CSS + 0 KB JS - **Pagefind** (wyszukiwarka client-side): ładowana dopiero po kliknięciu w pole wyszukiwania - **Kalkulator opon** (Vue 3): hydruje się dopiero gdy użytkownik przewinie do sekcji - **Lighthouse mobile:** 98–100 pkt Performance --- ## Schema.org i dane strukturalne LLM-y czytają JSON-LD podobnie jak klasyczne crawlery, ale **skuteczniej ekstrahują z nich relacje między encjami**. Minimalny zestaw schem dla strony firmowej: 1. **Organization** (dane firmy, logo, kontakt, social) 2. **WebSite** + **SearchAction** (jeśli masz wyszukiwarkę) 3. **BreadcrumbList** (hierarchia nawigacji) 4. **Article** + **FAQPage** dla wpisów blogowych 5. **Product** / **Service** dla oferty Dla realizacji typu katalog dodajemy dodatkowo `IndividualProduct` (zamiast `Product` — żeby zasygnalizować brak transakcji), `ItemList` dla stron kategorii i `@graph` wiążący wszystko w jedną spójną strukturę. Więcej praktycznych wzorców znajdziesz w [dokumentacji Google Search Central](https://developers.google.com/search/docs/appearance/structured-data) i w [dokumentacji schema.org](https://schema.org). --- ## Treść pod AEO — format odpowiedzi Klasyczny SEO-copy to długie artykuły „10 powodów dlaczego…". AEO preferuje inny format: - **Pytania jako H2/H3** (LLM łapie je jako intent użytkownika) - **Krótkie, konkretne odpowiedzi** zaraz po nagłówku (1–3 zdania) - **Listy i tabele** dla porównań (łatwiej parsować) - **Liczby i dane** (LLM cytuje konkret chętniej niż opinie) - **Sekcja FAQ** na końcu ze schema FAQPage Dobry test: jeśli bierzesz 1 akapit ze swojego tekstu i wrzucasz do ChatGPT jako cytat — czy brzmi jak kompletna odpowiedź? Jeśli tak, jest AEO-friendly. --- ## Lista kontrolna wdrożenia AEO **Warstwa techniczna:** - [ ] LCP < 2.5 s na mobile (sprawdź w [PageSpeed Insights](https://pagespeed.web.dev)) - [ ] Statyczny HTML generowany w czasie buildu (SSG) lub SSR z cache - [ ] JavaScript poniżej 100 KB dla stron informacyjnych - [ ] `llms.txt` i `llms-full.txt` w korzeniu domeny - [ ] Pełny JSON-LD (`Organization`, `BreadcrumbList`, `Article`/`FAQPage`) - [ ] `sitemap.xml` + `robots.txt` bez błędów - [ ] `hreflang` dla wersji językowych - [ ] Obrazy w AVIF/WebP z `fetchpriority` dla LCP **Warstwa treści:** - [ ] Pytania użytkownika w nagłówkach H2/H3 - [ ] Krótkie odpowiedzi bezpośrednio pod nagłówkami - [ ] Tabele porównawcze zamiast długich akapitów - [ ] Twarde liczby, nie ogólniki - [ ] Sekcja FAQ z FAQPage schema - [ ] Linkowanie wewnętrzne do kluczowych podstron - [ ] Outbound links do wiarygodnych źródeł (buduje topikalność) **Warstwa autorstwa (E-E-A-T):** - [ ] Imię autora + strona `/about` - [ ] Schema `Person` lub `Organization` - [ ] Profile na LinkedIn, GitHub (dla dev), Crunchbase (dla firm) - [ ] Data publikacji i data aktualizacji widoczne + w schema --- ## Ekologia cyfrowa — bonus poza AEO Lekka strona = mniej cykli CPU na serwerze + mniej danych przez sieć + mniej energii na urządzeniu użytkownika. To nie jest puste marketing — [Website Carbon Calculator](https://www.websitecarbon.com/) pokazuje, że typowa strona produkuje 0.5–2.5 g CO₂ na odsłonę. Redukcja wagi o 80% (z WP do Astro) to realna oszczędność w skali setek tysięcy wizyt miesięcznie. Dla klientów B2B to często argument w ESG reportach. Dla klientów indywidualnych — subtelny sygnał, że Twoja marka nie obciąża baterii w ich telefonie. --- ## Podsumowanie **AEO to nie trend, tylko przesunięcie architektury dostępu do informacji.** Użytkownik coraz rzadziej przegląda listę linków — częściej dostaje syntetyczną odpowiedź od AI. Żeby Twoja marka w tej odpowiedzi była, strona musi być: 1. **Szybka** (LCP < 2.5 s, waga < 100 KB JS) 2. **Semantyczna** (czysty HTML, JSON-LD, `llms.txt`) 3. **Skonstruowana wokół pytań**, nie wokół keyword density 4. **Poparta autorytetem** (realne autorstwo, wiarygodne linki, aktualizacje) Te same techniki, które wygrywają w AEO, wygrywają też w klasycznym SEO. Inwestycja nie ma ryzyka przestarzenia. Pracujesz nad stroną, która powinna być widoczna w erze AI? Zobacz, jak projektujemy takie wdrożenia w [spoko.space](https://spoko.space/pl/tworzenie-stron-internetowych/) — od [statycznego katalogu z tysiącami produktów](https://spoko.space/pl/vw-polo-6r-parts-catalog/) po [headless WordPress z frontendem Astro](https://spoko.space/pl/modern-car-blog/). Albo po prostu [napisz](https://spoko.space/pl/contact/), opowiedz o projekcie, doradzę konkretny stack.