Techniczna optymalizacja pod GEO i AEO w Next.js

W tym artykule skupiam się na wdrożeniu GEO i AEO w projekcie Next.js, począwszy od metadanych, danych strukturalnych, dostępności dla crawlerów AI, sitemapie i testach na produkcji. Nadmienię też, że artykuł jest techniczną częścią przewodnika po GEO, a sprawy takie jak strategia, treść, decyzje biznesowe i pomiar opisuję w artykule Co to jest GEO i jak optymalizować treści pod AI?. Po prostu tutaj zbieram wszystko, co powinien wdrożyć zespół techniczny.

Dlaczego GEO i AEO to szansa dla polskich stron Next.js

GEO jest szansą, ponieważ wiele serwisów publikuje treści bez jasnych definicji, źródeł, aktualizacji i czytelnej architektury informacji. Dobrze uporządkowany serwis może dzięki temu odróżnić się jakością techniczną i redakcyjną, ale sama obecność FAQ czy definicji nie jest mechanizmem zapewniającym widoczność.

Warto pamiętać, że GEO nie zastępuje SEO, tylko rozszerza je. Jest więc kolejną warstwą skomplikowania w kreacji treści. Strony potrzebują solidnego fundamentu technicznego SEO i głębokości treści, żeby zostać odkryte, zrozumiane i ewentualnie zacytowane przez systemy AI. Czytelna struktura informacji, wyraźne autorstwo i aktualne treści pomagają odbiorcom ocenić materiał. Nie oznacza to jednak, że serwisy z najwyższymi pozycjami w Google zawsze będą wybierane przez różne systemy AI.

Trzeba przy tym zaznaczyć, że GEO nie jest tematem wyłącznie dla marketingu treści. To zbyt wąskie ujęcie, ponieważ deweloper ma realny wpływ na to, czy treść jest dla systemów AI łatwo dostępna do pobrania, czytelna po wyrenderowaniu i poprawnie opisana. Ważne jest też, by była spójna z danymi strukturalnymi oraz łatwa do znalezienia przez linkowanie wewnętrzne i architekturę informacji.

I teraz, jeśli kluczowa treść istnieje dopiero po hydracji na kliencie, jest schowana za interakcją, CDN blokuje ruch botów albo dane strukturalne nie zgadzają się z widoczną treścią, to nawet bardzo dobry artykuł będzie miał problemy. Dla dewelopera GEO nie jest osobną taktyką „pod AI”, ale przecięciem kilku kompetencji:

• technicznego SEO,
• jakościowej treści,
• architektury informacji,
• danych strukturalnych,
• i kontroli nad crawlerami oraz infrastrukturą.

Architektura Next.js pod GEO i AEO: implementacja techniczna

Next.js może ułatwić wdrożenie technicznych podstaw GEO/AEO dzięki obsłudze Server-Side Rendering, Static Site Generation, React Server Components i rozwiniętemu ekosystemowi narzędzi SEO.

Właśnie dlatego, mając już doświadczenie w SEO i ucząc się JS/React, zwróciłem większą uwagę na Next.js. Problemem nie był sam React, tylko typowy setup oparty na client-side renderingu: treść nie trafiała do HTML-a od razu, tylko po wykonaniu JavaScriptu, co osłabia możliwości SEO. Next.js oferuje SSR i SSG, więc użytkownicy oraz roboty wyszukiwarek szybciej dostawali gotową treść, a jest to istotna część optymalizacji.

SSR, SSG i widoczna treść tekstowa dla modeli AI

Kluczowa zawartość strony powinna być dostępna po stronie serwera i widoczna w HTML, a nie doklejana dopiero po czasie przez JavaScript. Dotyczy to przede wszystkim głównych akapitów sekcji FAQ i tabel porównawczych, ale też list zalet i wad oraz danych kontaktowych i informacji o autorze.

Nie chodzi o to, żeby każda aplikacja była pozbawiona całego JS, ale chodzi o to, żeby najważniejsza wiedza była dostępna bez wykonywania złożonej logiki po stronie klienta. Kiedy framework realnie w tym pomaga, opisuję w artykule o przewadze Next.js nad React SPA w SEO.

Metadata API w Next.js jako fundament GEO i AEO

Next.js App Router oferuje wbudowane Metadata API do deklaratywnego definiowania meta tagów, Open Graph, kanonicznych adresów i alternatyw językowych. JSON-LD renderuje się osobnym, natywnym tagiem <script> w komponencie strony lub layoutu:

// app/blog/[slug]/page.tsx
import type { Metadata } from 'next'
 
type Props = {
  params: Promise<{ slug: string }>
}
 
export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params
  const post = await getPost(slug)
 
  return {
    title: `${post.title} - CompanyName`,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      type: 'article',
      publishedTime: post.datePublished,
      modifiedTime: post.dateModified,
      authors: [post.author],
    },
    alternates: {
      canonical: '/blog/' + slug,
    },
  }
}

Ustaw też metadataBase raz w głównym app/layout.tsx. Wtedy Next.js zamieni względny adres kanoniczny i adresy obrazów Open Graph na pełne URL-e, zamiast wymagać ręcznego sklejania domeny w każdej trasie.

Przy dynamicznym generateMetadata Next.js może wysłać interfejs wcześniej, a znaczniki metadanych dołączyć później w strumieniu, do <body>. Dla rozpoznanych botów niewykonujących JavaScriptu czeka na metadane i umieszcza je w <head>. Dlatego w testach uwzględnij pełną odpowiedź, wyrenderowany DOM oraz sposób obsługi danego robota; brak metadanych w pierwszym fragmencie HTML-a nie musi oznaczać błędu.

Dyrektywy podglądu i funkcje AI w Google

Dopuszczenie lub wykluczenie treści z AI Overviews i AI Mode ustawisz w Search Console (Search generative AI), co opisuję w przewodniku po GEO podlinkowanym na początku wpisu. W kodzie strony nadal obowiązują standardowe mechanizmy indeksowania i podglądu wyników:

• noindex, jeśli strona nie ma być widoczna w Google,

• nosnippet, jeśli nie chcesz, żeby Google pokazywał fragmenty strony,

• max-snippet, jeśli chcesz ograniczyć długość fragmentu,

• data-nosnippet, jeśli chcesz wykluczyć konkretną część widocznej treści,

• poprawna dostępność dla Googlebot, jeśli strona ma być kwalifikowana do wyników i funkcji AI w Search.

W Next.js dyrektywy dla tras ustawisz w polu robots Metadata API, a data-nosnippet dodasz jako atrybut obsługiwanego elementu, np. span, div lub section.

Poniższy przykład świadomie ogranicza podgląd jednej trasy do 160 znaków. Nie jest to zalecana konfiguracja zwiększająca widoczność ani ustawienie długości meta description. max-snippet ogranicza również ilość treści używanej bezpośrednio w AI Overviews i AI Mode, z wyjątkami dotyczącymi odrębnie udzielonych zezwoleń, np. treści udostępnionej w danych strukturalnych. Jeśli nie chcesz narzucać takiego limitu, pomiń tę dyrektywę lub użyj wartości -1. Umieszczenie jej w głównym layoucie rozszerzyłoby zakres na dziedziczące trasy.

// app/material-z-ograniczonym-podgladem/page.tsx — fragment metadanych
import type { Metadata } from 'next'
 
export const metadata: Metadata = {
  robots: {
    index: true,
    follow: true,
    googleBot: {
      index: true,
      follow: true,
      'max-snippet': 160,
    },
  },
}

Google-Extended dotyczy ograniczania użycia treści w części systemów Google poza Search, ale nie jest przełącznikiem odpowiedzialnym za widoczność w AI Overviews. Jeśli chcesz ograniczyć to, co Google może pokazać z Twojej strony w Search, dobierz mechanizm do celu: kontrolkę Search generative AI dla objętych nią funkcji, ustawienia podglądu dla fragmentów lub noindex dla wykluczenia z Search.

JSON-LD i structured data dla wyszukiwarek oraz silników AI

Dane strukturalne opisują treść w formacie maszynowym. Google wskazuje je jako pomoc w rozumieniu strony i kwalifikowaniu do wybranych wyników wzbogaconych (rich results); nie publikuje jednak reguły, według której JSON-LD zwiększa cytowalność w AI Overviews. W praktyce wdrażaj je dla zgodności semantycznej i wyszukiwarki, nie jako obietnicę działania RAG. Oto bezpieczna implementacja JSON-LD w Next.js:

// components/ArticleJsonLd.tsx
interface ArticleJsonLdProps {
  title: string;
  description: string;
  datePublished: string;
  dateModified: string;
  authorName: string;
  url: string;
  imageUrl: string;
}
 
export function ArticleJsonLd({
  title,
  description,
  datePublished,
  dateModified,
  authorName,
  url,
  imageUrl,
}: ArticleJsonLdProps) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: title,
    description,
    datePublished,
    dateModified,
    author: {
      '@type': 'Person',
      name: authorName,
      url: 'https://example.com/o-mnie',
    },
    publisher: {
      '@type': 'Organization',
      name: 'CompanyName',
      url: 'https://example.com',
      logo: {
        '@type': 'ImageObject',
        url: 'https://example.com/logo.png',
      },
    },
    mainEntityOfPage: url,
    image: imageUrl,
  };
 
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{
        __html: JSON.stringify(jsonLd).replace(/</g, '\\u003c'),
      }}
    />
  );
}

Przykłady typów schema zależnie od treści strony:

• Article / BlogPosting dla treści blogowych i artykułów eksperckich,
• FAQPage dla prawdziwej, widocznej sekcji pytań i odpowiedzi,
• HowTo tylko gdy strona faktycznie opisuje instrukcję krok po kroku; Google nie wyświetla już wyników rozszerzonych HowTo,
• Organization / Person do opisu organizacji i osób,
• BreadcrumbList dla jasnej hierarchii nawigacyjnej.

Dobieraj typy do faktycznej treści. Markup nie jest wymaganiem obecności w funkcjach generatywnych ani potwierdzonym sposobem zwiększania cytowań. FAQPage i HowTo mogą opisywać odpowiednie materiały w Schema.org, ale nie należy utożsamiać istnienia typu z obsługą wyniku rozszerzonego. Google wycofał FAQ rich results od 7 maja 2026 r. Informację podaje historia zmian w dokumentacji Google Search. Jak połączyć te typy w jeden graf encji z @id i sameAs, pokazuję w artykule o Schema.org pod AI Search.

Poprawność ogólnego opisu Schema.org sprawdź w Schema Markup Validator. Google Rich Results Test służy do oceny danych pod kątem obsługiwanych przez Google wyników rozszerzonych. Niewykrycie takiego wyniku nie oznacza automatycznie błędnego JSON-LD; oba narzędzia mają inny zakres.

FAQPage Schema w Next.js pod AEO i odpowiedzi AI

FAQ poprawia nawigację i pozwala opisać widoczne pytania oraz odpowiedzi w danych strukturalnych, ale już nie traktuj FAQPage jako taktyki na fragmenty z odpowiedzią (ang. featured snippets) lub AI. Google wycofał wyniki wzbogacone FAQ od 7 maja 2026 r.

// components/FaqJsonLd.tsx
interface FaqItem {
  question: string;
  answer: string;
}
 
export function FaqJsonLd({ items }: { items: FaqItem[] }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'FAQPage',
    mainEntity: items.map((item) => ({
      '@type': 'Question',
      name: item.question,
      acceptedAnswer: {
        '@type': 'Answer',
        text: item.answer,
      },
    })),
  };
 
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{
        __html: JSON.stringify(jsonLd).replace(/</g, '\\u003c'),
      }}
    />
  );
}

Struktura answer-first: odpowiedź na początku, bez sztucznego limitu słów

Nie ma oficjalnej i weryfikowalnej reguły, że ChatGPT, Perplexity czy Google AI Overviews oceniają stronę głównie po pierwszych 200 słowach, ale pomimo tego warto stawiać odpowiedź na główne pytanie wysoko na stronie. Użytkownik w ten sposób, szybciej oceni trafność materiału, a fragment z definicją lub tezą jest łatwiejszy do odnalezienia niż odpowiedź ukryta po długim wstępie.

W praktyce oznacza to, że:

1. Zdanie definicyjne pierwsze 1–2 zdania artykułu powinny zawierać precyzyjną definicję lub odpowiedź na pytanie z tytułu,
2. Kluczowe fakty powinny sie pojawiać natychmiast po definicji, więc podaj 2–3 najważniejsze punkty,
3. Kontekst i rozwinięcie, a dopiero potem rozwijaj temat w szczegółach.

Ta struktura (nazywana „inverted pyramid" lub „TLDR-first") poprawia czytelność i ułatwia wyodrębnienie odpowiedz, ale nie jest udokumentowanym czynnikiem cytowania przez modele generatywne.

Chcesz wiedzieć więcej na ten temat? Strategię treści pod GEO, od danych i źródeł po aktualizacje, opisuję w przewodniku podlinkowanym na początku wpisu, a budowę klastrów tematycznych w artykule o autorytecie tematycznym.

Entity Authority: budowanie tożsamości marki dla AI

„Entity Authority" nie jest oficjalną metryką Google ani dostawców modeli. To praktyczny skrót na wiarygodność encji — spójność danych o marce, osobie lub organizacji w wielu źródłach. Takie informacje ułatwiają ich weryfikację i ograniczają sprzeczności.

Jak budować Entity Authority:

1. Spójna informacja o autorze. Mam tu na myśli biogram z kwalifikacjami, zdjęciem, linkami do profili (LinkedIn, GitHub) na każdej stronie.
2. Schema Person/Organization. Zachowaj spójne identyfikatory i dane tej samej osoby lub organizacji. Artykuły różnych autorów powinny wskazywać właściwe, odrębne encje.
3. Wzmianki w zewnętrznych źródłach. Cytowania w mediach branżowych, artykuły gościnne, wypowiedzi eksperckie etc.
4. Spójna obecność w wielu kanałach. Blog, LinkedIn, X, YouTube z komplementarnymi treściami.

Optymalizacja techniczna Next.js pod crawlery AI

Dostępność strony Next.js dla botów AI

Nie ma jednego „crawlera AI”. Rozdziel dostęp do wyszukiwania, pobierania treści na żądanie użytkownika i treningu modeli, bo te role mają inne identyfikatory oraz konsekwencje. Publiczna strona powinna zwracać indeksowalny HTML, kod 200 i nie być przypadkowo blokowana przez robots.txt, noindex, logowanie ani WAF.

W praktyce zwykle masz trzy kategorie botów:

• boty treningowe: np. GPTBot, ClaudeBot,
• boty wyszukiwawcze / cytujące: np. OAI-SearchBot, PerplexityBot, Claude-SearchBot,
• pobrania uruchamiane przez użytkownika: np. ChatGPT-User, Perplexity-User, Claude-User.

Możesz chcieć dopuścić boty pomagające pojawiać się w wynikach AI, a jednocześnie blokować boty wykorzystywane do trenowania modeli, więc każdą kategorię traktuj osobno. Skutki blokowania poszczególnych botów opisuję w artykule o technicznym SEO dla agentów AI.

# robots.txt
User-agent: *
Allow: /

# ChatGPT Search: odkrywanie i cytowanie publicznych treści
User-agent: OAI-SearchBot
Allow: /

# Wyniki wyszukiwania Perplexity
User-agent: PerplexityBot
Allow: /

# Google Search, w tym funkcje AI w wynikach wyszukiwania Google
User-agent: Googlebot
Allow: /

# Opcjonalna, niezależna zgoda na trening Gemini i grounding Gemini
User-agent: Google-Extended
Allow: /

# Osobna decyzja o możliwym użyciu treści do treningu przez OpenAI
User-agent: GPTBot
Disallow: /

Sitemap: https://twojadomena.pl/sitemap.xml

OAI-SearchBot dotyczy odkrywania i cytowania treści w ChatGPT Search. GPTBot jest odrębną decyzją dotyczącą potencjalnego treningu, a Google-Extended steruje wykorzystaniem treści do treningu i osadzania odpowiedzi Gemini w źródłach (ang. grounding), nie do indeksowania ani rankingu w Google Search. Perplexity-User oraz analogiczne boty pobierające stronę na żądanie użytkownika to inna kategoria niż crawler wyników i nie są dowodem na odkrywalność strony.

Grupa dla konkretnego robota nie dziedziczy automatycznie reguł z User-agent: *. Jeśli ograniczasz tam skanowanie filtrów lub innych ścieżek, zachowaj odpowiednie ograniczenia także w grupach dla Googlebota i pozostałych botów, bo samo Allow: / może je niezamierzenie pominąć. Opisują to zasady robots.txt w dokumentacji Google. Dla Google AI Overviews i AI Mode kluczowy jest Googlebot i ogólna kwalifikacja strony do Search.

Google-Extended nie ma własnego User-Agenta HTTP. Jest tokenem kontroli wykorzystania treści pobieranej przez istniejące roboty Google; nie szukaj wizyt pod tą nazwą w logach. Opisuje to dokumentacja Google-Extended.

CDN, WAF i reguły bezpieczeństwa pod crawlery AI

robots.txt jest tylko jedną warstwą. Przy Cloudflare, CDN lub własnym WAF sprawdź osobno, czy zweryfikowane boty nie dostają 403, challenge, przekierowania do logowania albo pustego dokumentu. Nie ufaj samemu nagłówkowi User-Agent: do list dozwolonych używaj procedury weryfikacji i zakresów IP opublikowanych przez konkretnego dostawcę. Na przykład Perplexity zaleca połączenie User-Agenta z oficjalnymi zakresami IP.

Platformy infrastrukturalne dodają też osobne mechanizmy do zarządzania ruchem AI. Cloudflare ma już AI Crawl Control i osobną funkcję blokowania botów AI, więc sam fakt, że robots.txt wygląda poprawnie, nie oznacza jeszcze, że ruch botów dociera do treści. Sprawdź logi serwera albo CDN, statusy odpowiedzi i faktycznie zwracaną treść: odpowiedź 200 powinna zawierać właściwą stronę, a nie ekran weryfikacji lub pusty szablon. Jak czytać takie logi w Cloudflare, pokazuję w artykule o analizie logów Cloudflare.

Test odpowiedzi HTTP i widocznej treści

Po wdrożeniu sprawdź stronę w produkcji, nie tylko lokalnie. Poniższe polecenia to wstępna diagnostyka, która pokazuje nagłówki pierwszej odpowiedzi i wyszukuje wybrane znaczniki w treści po przekierowaniach:

curl -sS -o /dev/null -D - https://example.com/blog/next-js-geo-aeo
curl -sSL https://example.com/blog/next-js-geo-aeo | rg -n \
  'rel="canonical"|name="robots"|application/ld\+json|Jak technicznie'

Dopasowanie przez rg nie sprawdza poprawności linku kanonicznego ani wartości dyrektyw. Fraza może znajdować się wyłącznie w JSON-LD lub danych RSC, bez obecności w widocznej treści. Skontroluj również ewentualne przekierowania, końcowy status oraz nagłówek X-Robots-Tag.

W przeglądarce porównaj odpowiedź dokumentu w Network z DOM-em po renderowaniu: sprawdź tekst w głównej części strony, linki i wartości metadanych. Uwzględnij streaming i różnice odpowiedzi zależne od User-Agenta. Samo podszycie się pod nazwę bota w curl nie potwierdza, że WAF dopuści prawdziwy, zweryfikowany ruch tego robota.

W Google Search Console korzystaj dodatkowo z narzędzia „Inspekcja adresu URL”, aby zweryfikować stan indeksowania oraz sposób renderowania strony. Pamiętaj, że brak tagu noindex to za mało, ponieważ Google wymaga, aby strona była dostępna dla Googlebota, zwracała kod odpowiedzi 200 i zawierała treść możliwą do poprawnego zindeksowania, również na potrzeby formatów obsługiwanych przez AI.

Sitemap XML z lastmod dla Google i crawlerów AI

Mapa strony pomaga wyszukiwarkom odkrywać kanoniczne adresy i oceniać, które dokumenty zmieniły się od ostatniego pobrania. lastmod nie jest sygnałem GEO ani gwarancją ponownego crawlu, dlatego podawaj rzeczywistą datę istotnej modyfikacji:

// app/sitemap.ts
import { MetadataRoute } from 'next'
 
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllPosts()
 
  return posts.map((post) => ({
    url: 'https://twojadomena.pl/blog/' + post.slug,
    lastModified: new Date(post.updatedAt),
  }))
}

Google ignoruje pola priority i changefreq, dlatego przykład ich nie zawiera. Nie służą do sterowania rankingiem ani harmonogramem skanowania Googlebota.

Pole updatedAt jest elementem Twojej aplikacji — dopiero jego użycie w widocznej dacie lub metadanych udostępnia informację odbiorcom.

llms.txt możesz utrzymywać jako wygodny, tekstowy indeks najważniejszych materiałów, zwłaszcza gdy generujesz go z tych samych danych co sitemapę. Nie jest jednak standardem sieciowym ani udokumentowanym wymogiem Google, OpenAI czy Perplexity. W 2026 roku Lighthouse zaczął sprawdzać llms.txt w eksperymentalnej kategorii Przeglądanie Agentowe. Według dokumentacji audytu w Lighthouse błąd serwera przy pobieraniu pliku jest zgłaszany, natomiast brak pliku (404) daje wynik „nie dotyczy” (N/A). Samo zaliczenie audytu nie dowodzi używania go przez dany system AI ani wpływu na cytowania.

Core Web Vitals i jakość strony

Core Web Vitals są elementem jakości doświadczenia strony i sygnałem używanym w klasycznym Google Search. Google zaleca dobrą jakość strony także dla wejść z AI Overviews i AI Mode, ale nie publikuje osobnego progu CWV, który decyduje o cytowaniu w odpowiedzi AI. W Next.js pomagają osiągnąć dobre wyniki:

• Image Optimization z next/image: domyślnie WebP; AVIF wymaga konfiguracji images.formats, a wybór formatu zależy od nagłówka Accept. Podaj właściwe sizes i dobierz sposób ładowania: lazy loading jest odpowiedni dla obrazów poza pierwszym ekranem, ale nie dla głównego obrazu LCP,
• Font Optimization z next/font: samodzielne hostowanie fontów oraz dopasowanie metryk fallbacku mogą ograniczyć przesunięcia związane z ładowaniem kroju. Nie gwarantują zerowego CLS w każdej konfiguracji ani na całej stronie,
• Streaming z Suspense pozwala dostarczać gotowe fragmenty bez czekania na całą stronę; to, kiedy dotrze główna treść, zależy od pobierania danych i rozmieszczenia granic Suspense,
• React Server Components mogą ograniczyć JavaScript po stronie klienta i pracę przeglądarki; efekt dla LCP trzeba potwierdzić danymi z realnych użytkowników.

Oceniaj CWV na podstawie 75. percentyla rzeczywistych wizyt, osobno dla urządzeń mobilnych i desktopowych. Dobre wyniki to LCP ≤ 2,5 s, INP ≤ 200 ms oraz CLS ≤ 0,1. Pojedynczy pomiar Lighthouse pomaga w diagnozie, ale nie potwierdza spełnienia tych warunków dla użytkowników.

Semantyczny HTML i architektura informacji

Silniki generatywne lepiej radzą sobie z treścią, która ma czytelną strukturę, czyli w praktyce oznacza to:

• jedną, logiczną hierarchię nagłówków,

• sensowne użycie <main>, <article>, <section>, <nav>,

• tekst alternatywny przy ilustracjach,
• tabele tam, gdzie naprawdę porównujesz dane,
• linkowanie wewnętrzne między powiązanymi wpisami,

• brak ukrywania najważniejszych informacji w karuzelach, accordionach i interaktywnych widgetach bez sensownego fallbacku.

Dla GEO ważniejsze od „sprytnego frontendu” jest to, czy treść ma klarowny kształt po wyrenderowaniu. Warto też zadbać o semantyczny HTML i poprawne nazwy oraz stany kontrolek. Pomagają one osobom korzystającym z technologii asystujących, a także narzędziom, które odczytują strukturę i interakcje strony. Nie zastępuje to klasycznego SEO, Core Web Vitals ani testu dostępności dla crawlerów.

Jak sprawdzić efekty wdrożenia

Po wdrożeniu zacznij od warstwy technicznej: logi serwera lub CDN pokażą żądania botów, statusy i ewentualnie rozmiar odpowiedzi, a Search Console pozwoli sprawdzić indeksację kluczowych adresów. Standardowe logi zwykle nie zapisują treści odpowiedzi, więc kompletność HTML-a zweryfikuj osobnym pobraniem i testem renderowania. Jak czytać takie logi, pokazuję w artykule o analizie logów Cloudflare. Pomiar samej widoczności w odpowiedziach AI, czyli raport Generative AI w Search Console, ruch z ChatGPT w analityce i powtarzalny audyt promptów, opisuję w części o pomiarze przewodnika po GEO.

Logi serwera i CDN pomagają wykryć błędy pobierania, blokady oraz powroty zweryfikowanych crawlerów po aktualizacji. Nie potwierdzają jednak cytowania. Brak świeżej wizyty również nie przesądza o niewidoczności: system może korzystać z wcześniej pobranych materiałów lub zewnętrznego indeksu.

Lista kontrolna wdrożenia GEO i AEO dla Next.js

Poniżej zestawienie działań, które możesz wdrożyć systematycznie:

Warstwa techniczna:

• Implementacja JSON-LD zgodnego z widoczną treścią (zwykle Article lub BlogPosting, Organization/Person i BreadcrumbList; FAQPage/HowTo tylko gdy typ faktycznie pasuje)

• Walidacja Schema.org w Schema Markup Validator oraz obsługiwanych wyników rozszerzonych w Google Rich Results Test

• Rozdzielona polityka robots.txt dla Googlebota, OAI-SearchBot, PerplexityBot oraz opcjonalnie Google-Extended i GPTBot

• Sitemap XML z właściwymi datami lastmod

• Opcjonalny llms.txt generowany z tego samego źródła prawdy co sitemap i treści, bez traktowania go jako sygnału rankingowego

• Indeksowalna treść w odpowiedzi HTML oraz test 200, linku kanonicznego, noindex i blokad CDN, WAF lub firewalla na produkcji

• Najważniejsze informacje dostępne bez logowania, interakcji i ciężkiego client-side renderingu

• Ta sama kluczowa treść w wersji mobilnej i desktopowej
• Logiczna struktura nagłówków i linkowanie wewnętrzne

• Sprawdzone ustawienie Search generative AI w Search Console oraz dyrektywy indeksowania i podglądu wyników

• Core Web Vitals w zielonych strefach (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) dla 75. percentyla rzeczywistych wizyt, osobno na urządzeniach mobilnych i desktopowych

• Kanoniczne URL-e na każdej stronie

Warstwa treści:

• Struktura answer-first — konkretna odpowiedź wysoko na stronie, bez sztucznego limitu liczby słów

• Sekcje FAQ z pytaniami w języku naturalnym (czyli, jak ludzie pytają AI)

• Dane, statystyki i konkretne liczby z podaniem źródeł

• Opis istotnych aktualizacji, jeśli rzeczywiście zmieniły się informacje ważne dla czytelnika

• Klastry tematyczne (ang. topic clusters) ze stronami filarowymi (ang. pillar pages) i linkowaniem wewnętrznym

• Widoczna data publikacji i ostatniej aktualizacji

• Kompletny biogram autora z kwalifikacjami (wprowadzenie Author Boxa z linkami)

Warstwa autorytetu:

• Spójne dane tej samej encji Person/Organization i właściwe autorstwo każdego wpisu

• Obecność marki/autora w wielu zewnętrznych źródłach
• Cytowania w mediach branżowych i guest posty
• Profile społecznościowe z komplementarną treścią

Jeśli rozwijasz ten temat dalej, zobacz też GEO — Generative Engine Optimization, czyli jak optymalizować treści pod AI, Next.js a SEO — kiedy naprawdę daje przewagę nad zwykłym Reactem i App Router czy Pages Router — co wybrać?. Techniczna warstwa dostępności dla botów AI — co powinna zawierać robots.txt, jakie boty odróżnić i dlaczego masowa blokada nie jest dobrym pomysłem — to osobny temat w artykule o technicznym SEO dla agentów AI. Uzupełnieniem jest też llms.txt — jak wdrożyć i formatować go w Next.js lub Astro. Widoczność w odpowiedziach AI to jedna z warstw audytu; pozostałe rozpisuję w przewodniku po audycie technicznym SEO.