JavaScript SEO w 2026: Google, Bing i boty AI. Przewodnik na danych
W ciągu 15 dni (18 maja – 2 czerwca 2026) mój test bed na next.jsseo.dev odnotował 6125 wejść z 25 klas botów, które pokryły wszystkie 55 komórek testowych. Sześć najaktywniejszych klas – w tym GPTBot, Meta-ExternalAgent i Amazonbot – wykonało łącznie 862 żądania i ani razu nie poprosiło o robots.txt. Meta crawlowała z 50 różnych adresów IP i każdy z nich poszedł prosto do treści, z pominięciem reguł.
Tak wygląda rzeczywistość, w której odbywa się dziś JavaScript SEO. Pytanie: „czy mój serwis JS jest widoczny w wyszukiwarkach” nie ma jednej odpowiedzi, bo systemów jest co najmniej trzy i każdy zachowuje się inaczej. Google renderuje JavaScript niemal zawsze. Bing deklaruje, że potrafi – i robi to jednym z dwóch podsystemów, tym mniejszym. Boty AI, z nielicznymi wyjątkami, nie renderują wcale. Serwis może być numerem jeden w Google i jednocześnie nie istnieć dla ChatGPT, Perplexity czy Claude’a.
Ten przewodnik rozbiera trzy systemy osobno – na źródłach z lat 2024–2026 i na pomiarach z mojego laboratorium jsseo.dev, gdzie od maja 2026 mierzę zachowanie botów na ośmiu wzorcach osadzania treści JS (8 wzorców × 5 typów stron × 3 tryby renderowania). Metodologia, kod i surowe dane trackera są otwarte (CC0/CC-BY, MIT).
System pierwszy: Google
Co wiadomo na pewno
Web Rendering Service (WRS) to headless Chromium w wersji evergreen – od maja 2019 aktualizowany do bieżącego stabilnego Chrome’a. Renderuje JS, CSS i żądania XHR; nie pobiera obrazów ani wideo w trakcie renderowania. Działa bezstanowo: między żądaniami czyści local storage i dane sesji, więc treść zależna od stanu przeglądarki dla Googlebota nie istnieje.
Największe niezależne badanie zrobili Vercel i MERJ (kwiecień 2024, publikacja lipiec 2024): na próbie ponad 100 tysięcy pobrań Googlebota renderowanie objęło praktycznie wszystkie strony HTML – łącznie ze złożonymi interakcjami JS, React Server Components i treścią streamowaną. Kolejka renderowania miała minimalny wpływ na SEO. Jedno zastrzeżenie: to próba na konkretnych frameworkach i serwisach, więc uczciwa interpretacja brzmi „Googlebot renderuje zdecydowaną większość niezawodnie”, a nie „renderuje wszystko zawsze”. W moim labie Googlebot okazał się zresztą najbardziej selektywnym z crawlerów: odwiedził 9 z 55 komórek, podczas gdy ClaudeBot i Meta zrobiły pełny przegląd matrycy. Render u Google działa – pod warunkiem że Googlebot w ogóle uzna URL za wart odwiedzenia.
Świeży i mało znany konkret: w marcu 2026 Gary Illyes opublikował na blogu Search Central szczegóły limitów pobierania. Googlebot pobiera maksymalnie 2 MB na pojedynczy URL, licząc z nagłówkami HTTP. Bajty powyżej limitu są ignorowane w całości: nie są pobierane, renderowane ani indeksowane. Zasoby zewnętrzne (JS, CSS) mają własne, osobne liczniki. Kontekst, który robi z tego realny problem: według HTTP Archive mediana strony mobilnej to 2,56 MB – statystycznie połowa stron internetu ociera się o limit albo go przekracza. Wnioski: chudy HTML, ciężki CSS/JS na zewnątrz, a title, canonical i kluczowe dane strukturalne wysoko w dokumencie, nie na jego końcu.
Trzy mity, które branża wciąż powtarza
„Two-wave indexing”. Model dwóch fal pochodzi z Google I/O 2018 i sam Google go wycofał. Martin Splitt nazwał go nadmiernym uproszczeniem i już w 2019 mówił, że dwie fale odgrywają coraz mniejszą rolę, a indeksowanie przed renderowaniem w zasadzie nie zachodzi. Jeśli w 2026 ktoś diagnozuje ci „problem z two-wave indexing”, wiesz, z którego roku pochodzi jego wiedza.
„Renderowanie trwa dni albo tygodnie”. Liczba z 2018 („minuty, godzina, dzień, do tygodnia”) jest nieaktualna od listopada 2019, kiedy Google podał medianę czasu do renderowania na poziomie około 5 sekund, z 90. percentylem w minutach. Niuans z badań Onely (TGIF): mediana renderowania to nie to samo co pełne zaindeksowanie treści – w ich pomiarach od 5 do 50% nowych stron zależnych od JS miało niezaindeksowaną treść JS jeszcze dwa tygodnie po dodaniu do sitemapy. Render jest szybki; indeksacja treści z renderu bywa wolna.
„WRS to Chrome 41”. Nieaktualne od siedmiu lat, a wciąż spotykane w polskich audytach.
Co z tego wynika
Dla samego Google dobrze zbudowany serwis JS działa. Problemy zaczynają się w szczegółach implementacji: błędach JS wywalających render, metadanych wstrzykiwanych po asynchronicznym fetchu, zasobach zablokowanych w robots.txt. Ale kluczowa zmiana perspektywy jest inna: Google to najłagodniejszy z trzech systemów. Optymalizacja „pod Google” przestała być optymalizacją „pod wyszukiwanie”.
System drugi: Bing i Copilot
Deklaracja kontra pomiar
Bingbot od października 2019 renderuje strony silnikiem Chromium (Microsoft Edge) – ogłaszał to Fabrice Canel z obietnicą, że Bingbot będzie widział strony tak samo jak Googlebot. Tyle deklaracja. Oficjalne wytyczne Bing Webmaster mówią coś ciekawszego: Bing „generalnie potrafi przetwarzać JavaScript”, ale ma ograniczenia w przetwarzaniu JS w skali – i dlatego dla dużych serwisów sam rekomenduje dynamic rendering, czyli serwowanie botom prerenderowanej wersji.
Niezależne testy (m.in. Carlos Sánchez na Sitebulb, 2025) pokazywały, że na dużych serwisach client-side rendered zmiany w DOM nie pojawiały się w wyrenderowanym widoku Binga. Moje pomiary dokładają do tego strukturę: w pierwszych ośmiu dniach pracy labu Bingbot pobrał test bed 126 razy. 110 wejść nigdy nie wykonało JavaScriptu. Pozostałe 16 – z innym stringiem user-agenta – odpaliło pełnego Reacta. Bingbot dzieli ruch na dwa podsystemy (desktopowy i smartfonowy) i tylko jeden z nich renderuje. W szerszym 15-dniowym oknie Bingbot był najaktywniejszym zweryfikowanym crawlerem na test bedzie: 303 wejścia ze 106 adresów IP.
To spina deklarację z pomiarami: „potrafimy renderować” i „nie w skali” są jednocześnie prawdziwe. Praktyczna konsekwencja: jeśli treść krytyczna istnieje tylko po wykonaniu JS, w Bingu jest loterią – i to loterią, w której renderujący podsystem to mniejszość ruchu.
Dlaczego Bing znaczy więcej, niż sugeruje jego udział w rynku
Indeks Binga zasila Copilota (Microsoft dokumentuje pipeline groundingu odpowiedzi na indeksie Bing), Yahoo i częściowo DuckDuckGo. Branżowe szacunki mówią też o dużym udziale indeksu Binga w odpowiedziach wyszukiwania ChatGPT – szacunek nieoficjalny, ale kierunkowo spójny z relacją Microsoft–OpenAI. Zgubienie Bingbota to utrata widoczności w całym tym ekosystemie naraz.
Bing wspiera też IndexNow – protokół aktywnego powiadamiania o nowych i zmienionych URL-ach, przyjęty również przez Yandex, Naver, Seznam i Yep (Google testował w 2021 i nie wdrożył). Microsoft raportował, że w 2024 około 17% świeżo klikanych URL-i w Bingu przyszło przez IndexNow. Dla serwisu JS to istotne: skoro nie możesz liczyć na niezawodny render przy crawlu, przynajmniej skróć drogę do odkrycia treści.
System trzeci: boty AI
Taksonomia, bez której nic nie zrozumiesz
„Boty AI” to trzy funkcjonalnie różne kategorie i u głównych vendorów każda ma osobny token w robots.txt:
| Vendor | Trening | Search/retrieval | Na żądanie użytkownika |
|---|---|---|---|
| OpenAI | GPTBot | OAI-SearchBot | ChatGPT-User |
| Anthropic | ClaudeBot | Claude-SearchBot | Claude-User |
| Perplexity | – (deklaruje brak treningu) | PerplexityBot | Perplexity-User |
| Meta | Meta-ExternalAgent | – | Meta-ExternalFetcher |
| Amazon | Amazonbot | Amzn-SearchBot | Amzn-User |
| Apple | Applebot-Extended (token opt-out, nie osobny crawler) | Applebot | – |
| Google-Extended (token opt-out) | Googlebot | – |
Tokeny są niezależne: zablokowanie GPTBota nie blokuje OAI-SearchBota. Blokada treningu i blokada widoczności w odpowiedziach to dwie różne decyzje – OpenAI wprost dokumentuje, że serwis blokujący OAI-SearchBota nie pojawi się w odpowiedziach wyszukiwania ChatGPT. Pułapka, którą SEO-we listicle notorycznie mylą: Google-Extended i Applebot-Extended to dyrektywy dla istniejących crawlerów, nie nowe boty – nie wykonują żądań HTTP i nigdy nie zobaczysz ich w logach. Amazon ma mechanizm unikalny w stawce: opt-out z treningu na poziomie pojedynczej strony, przez meta tag robots noarchive, nie przez token w robots.txt.
Renderowanie: werdykt z pomiarów
Badanie Vercel i MERJ z grudnia 2024 postawiło sprawę jasno: żaden z głównych batch crawlerów AI nie renderuje JavaScriptu. GPTBot pobierał pliki JS w 11,5% żądań, ClaudeBot w prawie 24% – ale żaden ich nie wykonywał. Późniejsza analiza ponad 500 milionów pobrań GPTBota nie znalazła ani jednego dowodu wykonania JS.
Wyjątki są trzy i każdy istotny. Gemini korzysta z infrastruktury Googlebota, więc dziedziczy pełny render WRS. Applebot renderuje JavaScript przeglądarkowo – i zasila Siri, Spotlight oraz Apple Intelligence. Trzeci wyjątek zmierzyłem w labie i zaskoczył mnie samego: NotebookLM, który branża traktowała jako scraper statycznego HTML-a, wykonał Reacta – sonda oparta na entropii runtime’owej wykazała wygenerowanie UUID w czasie wykonania i pobranie treści dociąganej client-side. Do tego luka dowodowa, którą uczciwie trzeba nazwać: Amazonbot nie był w próbie Vercel/MERJ, a dokumentacja Amazona milczy o renderowaniu – nie zakładaj, że nie renderuje, bo tego dotąd nikt nie zmierzył.
Robots.txt: trzy zachowania, jeden regulamin
Tu zaczyna się część, której nie znajdziesz w żadnym anglojęzycznym przewodniku, bo pochodzi z mojego trackera. W 15-dniowym oknie boty ułożyły się w trzy pasma względem robots.txt:
Ciężcy czytelnicy. OAI-SearchBot: 38 z 42 żądań na robots.txt (90,5%), tylko 2 wejścia na treść. Cokolwiek robi, jest tam głównie po to, żeby czytać regulamin. Googlebot: 42,7% żądań na robots.txt – zaskakująco dużo jak na statyczny, niezmieniany plik; prawdopodobnie efekt onboardingu nowej domeny albo zachowania cache po stronie Google.
Lekcy czytelnicy. Bingbot (4,6%) i ClaudeBot (4,1%) – sięgają po reguły okazjonalnie, większość ruchu to treść.
Zero. Sześć klas botów – GPTBot, Meta-ExternalAgent, Amazonbot, Google-ReadAloud, Google-Other, Google-Inspection – wykonało łącznie 862 żądania, pobrało 713 komórek treści i ani razu nie poprosiło o robots.txt. GPTBot przeszedł 39 z 55 komórek z 6 adresów IP, pobierając po drodze sitemapę 14 razy – i ani razu reguł. Wszystkie 50 adresów IP Mety poszło prosto do treści.
Ważne zastrzeżenie, które robi różnicę między rzetelnością a clickbaitem: to nie dowodzi, że te crawlery ignorują robots.txt. Istnieje wiarygodna architektura, w której dyspozytor crawlera sprawdza reguły centralnie – z innej puli IP, raz na wiele domen, względem wersji z cache – i wypuszcza fetchery tylko tam, gdzie wolno. Log serwera docelowego nigdy nie zobaczy wtedy żądania robots.txt, a reguły i tak zostały sprawdzone. Z poziomu logów nie da się odróżnić tej architektury od zwykłego olewania pliku.
Wniosek operacyjny jest za to twardy: nieobecność żądania robots.txt w twoich logach nie mówi nic o compliance. Jedyny test, który cokolwiek rozstrzyga, to realny Disallow: dla konkretnego bota na konkretnej ścieżce i obserwacja, czy pobrania ustają. Dokładnie taki eksperyment mam zaplanowany w labie jako kolejne okno pomiarowe.
Skala i zachowanie: liczby, które zmieniają rozmowę
Cloudflare Radar za 2025: trening to około 80% ruchu botów AI, search około 18%, boty działające na żądanie użytkownika około 3% – przy czym ta ostatnia kategoria urosła w rok około 15-krotnie. W czerwcu 2026 Cloudflare ogłosił moment przełomowy: boty po raz pierwszy w historii wygenerowały więcej żądań HTML niż ludzie (57,5% wobec 42,5%).
Druga strona medalu to stosunek crawlowania do odsyłania ruchu. Według Cloudflare GPTBot crawluje w proporcji około 1091 żądań na jedno odesłane wejście człowieka, Perplexity 195:1 (z trendem rosnącym: więcej crawlu, mniej referrali), a Anthropic mimo dużego spadku pozostaje najbardziej crawl-intensywną platformą. Bingbot dla porównania: około 40:1. Boty AI konsumują nieporównanie więcej, niż oddają – to kontekst każdej decyzji o wpuszczaniu.
Do tego wzorzec czasowy z mojego labu, który psuje popularny mental model „botów chodzących codziennie”: batch crawlery AI robią przegląd zimnej domeny w pierwszych dniach, po czym cichną. GPTBot był najaktywniejszy pierwszego i czternastego dnia, z niewielką aktywnością pomiędzy; ClaudeBot zrobił główny przegląd drugiego dnia i mniejszy tydzień później, po czym zniknął.
I liczba najmniej wygodna: TollBit zmierzył wzrost omijania robots.txt przez boty o około 400% między Q2 a Q4 2025; w Q4 ponad 13% żądań botów AI ignorowało plik. Najgłośniejszy przypadek to Perplexity: Cloudflare w sierpniu 2025 udokumentował, że po zablokowaniu oficjalnego crawlera Perplexity sięgało po niezadeklarowane boty udające Chrome’a na macOS, z rotacją user-agentów, adresów IP i ASN – i zdjął Perplexity z listy zweryfikowanych botów. Perplexity odpowiedziało, że agent działający na wyraźne żądanie użytkownika to nie crawler, tylko odpowiednik przeglądarki. Spór o to, czy boty user-triggered obowiązuje robots.txt, pozostaje nierozstrzygnięty – a definiuje granice kontroli, jaką realnie masz nad dostępem do treści.
Osiem wzorców treści JS: co mierzy lab
Vercel i MERJ rozstrzygnęli pytanie o tryby renderowania. Ale audyty klienckie nie pytają „czy serwis jest SSR czy CSR” – pytają, czy konkretny wzorzec (cena dociągana w useEffect, treść za kliknięciem, nawigacja na hash-routingu) kosztuje widoczność w konkretnym indeksie. Dlatego lab mierzy przeżywalność ośmiu wzorców osadzania treści – clean, js-images, js-links, click-reveal, js-fetched, hash-routing, late-loaded, mixed – na pięciu typach stron i w trzech trybach renderowania. Razem 55 komórek testowych, każda z sygnałami zbieranymi per bot.
Faza 1 badania trwa; werdykty przeżywalności per komórka będą publikowane na jsseo.dev wraz z krzepnięciem danych. Co już widać w pokryciu: ClaudeBot i Meta-ExternalAgent zrobiły pełny przegląd wszystkich 55 komórek, GPTBot 39, a Googlebot był najbardziej selektywny (9 komórek) – przy czym jego wybór objął zarówno wzorce czyste, jak i zależne od JS. Wniosek już teraz użyteczny: treść obecna w initial HTML jako tekst – nawet w formie JSON-a czy payloadu RSC – bywa konsumowana przez boty nierenderujące, bo one czytają odpowiedź serwera, nie DOM. Granica nie przebiega między „ładny HTML” a „JavaScript”, tylko między „jest w odpowiedzi serwera” a „powstaje w przeglądarce”.
Praktyka: jedna zasada i jej konsekwencje
Wspólny mianownik trzech systemów jest jeden: treść krytyczna musi istnieć w initial HTML. Wszystko poniżej to konsekwencje tej zasady.
Strategia renderowania per typ podstrony. SSG dla treści rzadko zmiennych (dokumentacja, blog, strony ofertowe), ISR dla odświeżanych okresowo, SSR dla danych na żywo. Client-side rendering zostaje dla elementów bez wartości SEO: liczników, czatów, widgetów społecznościowych. Wybór jednej religii renderowania dla całego serwisu to najdroższy błąd, jaki widuję w audytach – decyzję podejmuje się per szablon, na podstawie tego, kto ma daną treść skonsumować.
Dynamic rendering: rozjazd vendorów, o którym trzeba wiedzieć. Google od 2022 klasyfikuje dynamic rendering jako obejście, nie rozwiązanie, a w 2024 wyciął z dokumentacji sekcje wdrożeniowe. Bing w tym samym czasie dalej oficjalnie rekomenduje go dla dużych serwisów JS. Moja praktyka: prerender jako most na czas migracji, nie architektura docelowa – a przy treści w initial HTML cały dylemat znika. Granica cloakingu według Google: wersja serwerowa dla botów jest w porządku, dopóki treść jest zasadniczo ta sama co dla ludzi.
Metadane i canonicale w initial HTML. Title i canonical wstrzykiwane client-side potrafią być nadpisane albo zignorowane; Google i tak przepisuje title w około jednej trzeciej przypadków (badanie Ahrefs na ~950 tys. stron), więc nie dokładaj mu powodów. Dane strukturalne: Google czyta JSON-LD wstrzyknięty JS-em (nawet przez Google Tag Managera), o ile render się powiedzie – ale dla botów nierenderujących taki JSON-LD nie istnieje. Wniosek ten sam: JSON-LD w HTML-u z serwera, generowany z tego samego źródła danych co widoczna treść, walidowany w Rich Results Test na żywym URL-u. W SPA nie wstrzykuj schematów w useEffect po asynchronicznym fetchu – render może się skończyć przed przybyciem danych.
Linki. Google deklaruje wprost: crawluje linki będące elementami <a> z atrybutem href. Nawigacja na onClick, przyciski, pseudo-URL-e i hash-e to treść nieosiągalna dla crawlera. Reguła Splitta jest praktyczna: akcja na bieżącej stronie – button; przejście do nowej treści – <a href>. W SPA routing na History API, nie na fragmentach.
Diagnostyka rozjazdu raw vs rendered. Trzy testy w kolejności rosnącej rzetelności: view-source i szukanie treści; wyłączenie JS i przeładowanie; crawl porównawczy raw vs rendered na wszystkich szablonach (Screaming Frog / Sitebulb). Do tego URL Inspection w GSC dla widoku Googlebota i logi serwera dla odpowiedzi na pytanie, jak boty faktycznie chodzą po serwisie – w tym które klasy w ogóle proszą o pliki JS. Prosty trik wynikający wprost z pomiarów: skoro batch crawlery AI nie renderują, curl z ich user-agentem pokazuje dokładnie to, co widzą.
llms.txt: uczciwy werdykt
Propozycja Jeremy’ego Howarda z września 2024 zrobiła karierę w narzędziach SEO, ale nie u vendorów AI. John Mueller porównał llms.txt do meta tagu keywords i stwierdził, że żaden system AI z niego nie korzysta; Gary Illyes potwierdził brak wsparcia i planów. Pomiary są bezlitosne: Ahrefs na 137 tys. domen znalazł, że 97% plików llms.txt nie dostało w maju 2026 ani jednego żądania, a boty AI to 1,1% ruchu na tych plikach – większość odwiedzin generują narzędzia audytowe SEO. SE Ranking na około 300 tys. domen nie znalazł korelacji z cytowaniami w AI.
Realny przypadek użycia istnieje, ale gdzie indziej: narzędzia developerskie (Cursor, Claude Code, Copilot) pobierają llms.txt dokumentacji technicznych. Prowadzisz docs produktu – rozważ. Liczysz na widoczność w odpowiedziach AI – to nie jest ta dźwignia. Kontrola dostępu botów odbywa się dziś w robots.txt, per token – z zastrzeżeniami z sekcji o trzech zachowaniach wobec robots.txt powyżej.
Blokować czy wpuszczać: decyzja biznesowa, nie techniczna
Argumenty za wpuszczaniem: widoczność w odpowiedziach (OAI-SearchBot, Claude-SearchBot, PerplexityBot), obecność w ekosystemach (Applebot → Siri i Apple Intelligence). Argumenty za blokowaniem: stosunek crawl-to-refer liczony w setkach lub tysiącach żądań na jedno odesłane wejście, koszty infrastruktury, ochrona treści przed treningiem. Rozsądny punkt wyjścia dla większości serwisów komercyjnych: wpuszczać boty search/retrieval, decyzję o botach treningowych podejmować świadomie per vendor, a boty user-triggered traktować jako nieblokowane w praktyce – spór Perplexity–Cloudflare pokazuje, że deklaratywna kontrola nad nimi jest iluzoryczna.
Kontekst infrastrukturalny się zmienia: Cloudflare od lipca 2025 domyślnie blokuje crawlery AI dla nowych domen i rozwija model płatności za crawl. Jeśli twój serwis stoi za Cloudflare, sprawdź te ustawienia, zanim zaczniesz debugować „zniknięcie” z odpowiedzi AI – najczęstszą przyczyną braku cytowań w ChatGPT w latach 2024–2025 było wpuszczenie GPTBota w robots.txt przy równoczesnym blokowaniu go na WAF/CDN.
Co dalej: otwarte eksperymenty labu
Najbliższe okno pomiarowe to test falsyfikujący dla findingu o robots.txt: Disallow: dla GPTBota, Mety i Amazonbota na zdefiniowanym podzbiorze komórek i obserwacja, czy pobrania ustaną. Jeśli ustaną bez widocznego żądania robots.txt – reguły są sprawdzane out-of-band i dostaniemy na to pierwszy bezpośredni dowód. Jeśli nie ustaną – interpretacja „ignorują plik” przestaje być spekulacją. Obie odpowiedzi są cenne. Równolegle: dłuższe okno dla proporcji dwóch podsystemów Bingbota i zamknięcie luki dowodowej wokół renderowania Amazonbota.
Ten przewodnik będę aktualizował wraz z danymi – w JavaScript SEO fakty starzeją się szybciej niż w jakiejkolwiek innej działce technicznego SEO, a połowa branży wciąż cytuje stan z 2019 roku.
Jeśli chcesz sprawdzić, co z twojego serwisu widzą poszczególne klasy botów – to jest dokładnie zakres audytu JavaScript SEO. Diagnozę, czy problem w ogóle leży w JavaScript, załatwia często godzina konsultacji.
