Klasyczne techniczne SEO — sitemapy, kanonikale, czysty HTML renderowany po stronie serwera (SSR/SSG) zawiera treść w źródle dokumentu od razu. W przeciwieństwie do czystego SPA, gdzie HTML jest pustą powłoką, a treść dorysowuje JavaScript w przeglądarce. — nadal obowiązuje, ale doszła nowa warstwa decyzji: który z botów AI ma prawo czytać Twoją treść i w jakim celu. To nie jest pytanie czysto techniczne, lecz biznesowe, ponieważ część tych botów kieruje do Ciebie ruch i cytowania, a część jedynie pobiera treść do treningu — nie mamy wtedy z tego nic. Nie wrzucajmy więc wszystkich do tego samego worka.
Menażeria botów AI — kto puka do Twojej strony
Najczęstszy błąd to traktowanie „AI" jako jednej kategorii botów, podczas gdy w rzeczywistości na Twoją stronę trafiają boty o trzech różnych celach — i to rozróżnienie jest najważniejsze, by podjąć sensowną decyzję.
Pierwsza kategoria to boty trenujące model: pobierają treść, by uczyć na niej modele, i nic za to nie dają w zamian. Należą tu GPTBot (OpenAI), Google-Extended (Gemini) i ClaudeBot (Anthropic). Kategoria druga to boty indeksujące pod AI search — budują indeks pod funkcję wyszukiwania, która może Cię cytować z linkiem i kierować do Ciebie realny ruch: OAI-SearchBot, Claude-SearchBot, PerplexityBot. Trzecia to boty pobierające na żądanie: odwiedzają stronę, bo użytkownik poprosił asystenta o jej sprawdzenie — praktycznie odwiedziny w Twoim imieniu: ChatGPT-User, Claude-User.
Anthropic jest tu wzorcowym przykładem — rozdzielił swoją aktywność na trzy osobne user-agenty (ClaudeBot, Claude-User, Claude-SearchBot) właśnie po to, byś mógł podejmować decyzje per cel. Blokowanie „Anthropic" w całości oznaczałoby odcięcie się także od cytowań i odwiedzin na żądanie — czyli od ruchu.
Czy w ogóle warto blokować?
Odpowiem od razu, że hurtowa blokada zwykle Ci szkodzi. Fundamentem tego wniosku są badania opublikowane pod koniec 2025 roku przez naukowców z Rutgers Business School i The Wharton School pokazały, że wydawcy blokujący crawlery AI przez robots.txt odnotowali spadek ruchu o około 23% miesięcznie — w tym także ruchu czysto ludzkiego — przy czym blokada nie obniżała niezawodnie cytowań przez systemy AI. O ile możemy do badań naukowych i ich jakości podchodzić w różny sposób — są lepsze i gorsze — to te powinny nam dać jakiś punkt zaczepienia w dyskusji.
Sensowne podejście jest selektywne: rozważ blokadę botów czysto trenujących (jeśli masz powód, by nie zasilać treningu — np. treść premium), a zostaw otwarte boty wyszukujące i odwiedzające na żądanie, ponieważ to własnie one kierują do Ciebie ruch i cytowania. Najczystszy bezpieczny ruch to zablokowanie Google-Extended, które kontroluje wyłącznie trenowanie Gemini i — co kluczowe — nie wpływa na ranking w Google Search, ponieważ za niego odpowiada osobny Googlebot.
robots.txt w Next.js — reguły per bot
W App Routerze robots.txt generujesz dynamicznie przez plik app/robots.ts — konwencja Next.js App Router. Eksportujesz funkcję zwracającą obiekt konfiguracji, a Next.js generuje z niego /robots.txt podczas buildu, bez ręcznego utrzymywania pliku statycznego., definiując osobne reguły dla różnych user-agentów:
W tym przykładzie wyszukiwarki i boty AI-search (OAI-SearchBot, PerplexityBot, Claude-SearchBot — łapane przez *) mają pełny dostęp, a boty czysto trenujące są zablokowane. To jeden z wielu możliwych kompromisów — równie dobrze możesz zostawić wszystko otwarte, jeśli zależy Ci wyłącznie na maksymalnej widoczności. Ważne, że decyzja jest świadoma i odnosi się do danej kategorii bota.
robots.txt to deklaracja, nie zapora
Trzeba to powiedzieć wprost, ponieważ łatwo o złudne poczucie kontroli: robots.txt egzekwuje tylko ten, kto chce go respektować. Innymi słowy to taka umowa dżentelmeńska, "dobrze wychowane" boty (GPTBot, Googlebot) jej przestrzegają... albo i nie o czym piszę poniżej.
W sierpniu 2025 roku Cloudflare opublikowało raport pokazujący, że Perplexity korzystał z niedeklarowanych crawlerów rotujących user-agenty i adresy IP, by omijać dyrektywy no-crawl. To pokazuje granicę robots.txt: jeśli ktoś naprawdę chce pobrać Twoją treść, po prostu zignoruje zasady i plik tekstowy go nie powstrzyma.
Dostępność danych dla agentów i RAG
Druga stawka technicznego SEO dla AI to nie blokowanie, ale upewnienie się, że boty, które chcesz wpuścić, w ogóle widzą Twoją treść. Tutaj wraca jak bumerang fundamentalny problem renderowania.
Wiele RAG (Retrieval-Augmented Generation) — technika, w której system AI najpierw pobiera fragmenty treści ze źródeł (Twojej strony), a potem generuje odpowiedź opartą na tym kontekście. Jakość pobrania zależy od tego, czy treść jest dostępna w źródłowym HTML. i botów pobierających stronę na żądanie nie wykonuje pełnego renderowania JavaScriptu albo robi to nie tak jak trzeba. Jeśli kluczowa treść pojawia się dopiero po wykonaniu JS — jak w czystym SPA — agent może zobaczyć pustą powłokę zamiast odpowiedzi. To ta sama bolączka, która latami szkodziła SEO aplikacji klienckich, a teraz dotyczy też silników AI.
Rozwiązanie leży po stronie architektury: treść powinna renderować się na serwerze — w Next.js przez Server Components, SSR albo SSG — tak by istotny tekst był już w źródłowym HTML, zanim bot w ogóle dotknie JavaScriptu. Semantyczny HTML robi resztę: czytelna hierarchia nagłówków, sensowne <article> i <main>, właściwe listy — agent parsuje strukturę, nie wygląd. Trzecia zasada jest prosta i trudna do przeoczenia: nigdy nie chowaj kluczowej treści za interakcją - jest to stara zasada jeszcze z początków SEO. To, co pojawia się dopiero po kliknięciu albo przy lazy-loadzie, bywa dla bota niewidoczne.
To domyka obraz: techniczne SEO dla AI to z jednej strony kontrola dostępu (kogo wpuszczam i po co), a z drugiej dostępność treści (czy wpuszczony bot w ogóle ją zobaczy). Pierwsze robisz w robots.txt i na poziomie sieci, a drugie — w architekturze renderowania.
Jak to poukładać w praktyce
Sensowna kolejność wdrożenia dla typowej strony w Next.js zaczyna się od otwartego dostępu — domyślnie wpuszczasz wszystko i blokujesz tylko jeśli jest na to konkretny powód. Jeśli już blokujesz to boty trenujące (GPTBot, Google-Extended), a nie wyszukujące i odwiedzające na żądanie, ponieważ właśnie te drugie kierują do Ciebie użytkowników. robots.txt generujesz przez app/robots.ts, gdzie reguły per userAgent są wersjonowane w repo, a nie ręcznie edytowane. Jednocześnie upewniasz się, że treść żyje w źródłowym HTML — SSR/SSG dla wszystkiego, co ma być widoczne dla agentów i systemów RAG. Twardą blokadę, jeśli naprawdę musisz ją wprowadzić, przenosisz do sieci: WAF lub Cloudflare.
