Techniczne SEO dla AI: robots.txt, boty i RAG

Klasyczne techniczne SEO, czyli sitemapy, adresy kanoniczne, czysty HTML oczywiście nadal obowiązuje, ale doszła nowa warstwa wymagająca 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 dając nic w zamian.

Boty AI w robots.txt: GPTBot, ClaudeBot i inne crawlery

Nie można traktować AI jako jednej kategorii botów, podczas gdy w rzeczywistości na Twoją stronę trafiają boty o trzech różnych celach. Takie rozróżnienie jest ważne, by podjąć sensowną decyzję. Czy coś z tym robimy czy nie.

1. Pierwsza kategoria to boty trenujące model: pobierają treść, by uczyć na niej modele i nie dają nic w zamian. Należą tu GPTBot (OpenAI), Google-Extended (Gemini) i ClaudeBot (Anthropic).
2. 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.
3. 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, ponieważ rozdzielił swoją aktywność na trzy osobne user-agenty (ClaudeBot, Claude-User, Claude-SearchBot) właśnie po to, byś mógł podejmować decyzje dla określonego celu. Blokowanie „Anthropic" w całości oznaczałoby odcięcie się także od cytowań i odwiedzin na żądanie, czyli od ruchu.

Czy warto blokować boty AI w robots.txt?

Hurtowa blokada zwykle Ci szkodzi, a fundamentem tego wniosku są badania opublikowane pod koniec 2025 roku przez naukowców z Rutgers Business School i The Wharton School. Pokazały one, że wydawcy blokujący crawlery AI przez robots.txt odnotowali spadek ruchu o około 23% miesięcznie, w tym także ruchu prawdziwych użytkowników, 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 powinno być selektywne. Rozważ blokadę botów 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łaśnie one kierują do Ciebie ruch i cytowania. Najczystszy, bezpieczny ruch to zablokowanie Google-Extended, które kontroluje wyłącznie trenowanie Gemini i nie wpływa na ranking w Google Search (ważne!), ponieważ za niego odpowiada osobny Googlebot.

Robots.txt w Next.js: reguły dla GPTBot, ClaudeBot i crawlerów AI

W App Routerze robots.txt generujesz dynamicznie przez plik app/robots.ts, definiując osobne reguły dla różnych user-agentów:

// app/robots.ts
import type { MetadataRoute } from 'next'
 
export default function robots(): MetadataRoute.Robots {
  return {
    rules: [
      // Klasyczne wyszukiwarki i boty AI-search — pełny dostęp
      {
        userAgent: '*',
        allow: '/',
        disallow: '/api/',
      },
      // Boty trenujące — przykład selektywnej blokady
      {
        userAgent: ['GPTBot', 'Google-Extended', 'ClaudeBot'],
        disallow: '/',
      },
    ],
    sitemap: 'https://example.com/sitemap.xml',
  }
}

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, ponieważ 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 dla botów AI to deklaracja, która nie działa jak zapora

Trzeba to powiedzieć wprost, ponieważ łatwo o złudne poczucie kontroli. Plik robots.txt egzekwuje tylko ten, kto chce go respektować. Innymi słowy to taka umowa dżentelmeńska, że "dobrze wychowane" boty (GPTBot, Googlebot) będą ją przestrzegać. O tym, że nie zawsze tak jest, 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 AI i systemów 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 systemów RAG 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, by istotny tekst był już w źródłowym HTML, zanim bot w ogóle dotknie JavaScriptu. Semantyczny HTML robi resztę, czyli czytelną hierarchię nagłówków, sensowne <article> i <main>, właściwe listy (agent parsuje strukturę). Trzecia zasada to by nie chować kluczowej treści za interakcją, czyli wracamy do starej zasady SEO. Jest to istotne dlatego, że to co pojawia się dopiero po kliknięciu albo przy lazy-loadzie, bywa dla bota niewidoczne.

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. Poza robots.txt istnieje jeszcze jeden plik wpływający na to, co modele AI widzą na Twojej stronie, czyli chodzi o llms.txt. To nie zamiennik robots.txt, obydwa działają na różnych poziomach, ale razem tworzą kompletną warstwę sterowania widocznością. Jak wdrożyć go w Next.js i Astro, opisuję w artykule o llms.txt — wdrożenie i formatowanie.

Od 2026 do tej układanki dochodzi jeszcze warstwa diagnostyczna: Lighthouse sprawdza Przeglądanie Agentowe przez sygnały takie jak accessibility tree, CLS, llms.txt i eksperymentalny WebMCP. To nadal nie jest czynnik rankingowy, ale dobry test, czy wpuszczony agent będzie miał po czym chodzić i czy interfejs nie będzie mu uciekał spod kursora.

Jak poukładać techniczne SEO dla agentów AI 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.