AEO — jak zoptymalizować stronę pod AI i Answer Engines

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.

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

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 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 — 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 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.

Przykład wdrożenia

W katalogu części catalog.polo.blue — 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 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 i w dokumentacji 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)
• 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 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 — od statycznego katalogu z tysiącami produktów po headless WordPress z frontendem Astro. Albo po prostu napisz, opowiedz o projekcie, doradzę konkretny stack.