Crawlery AI nie wykonują kodu JavaScript

Krótka odpowiedź

Crawlery AI nie wykonują kodu JavaScript. Kiedy GPTBot, ClaudeBot czy PerplexityBot pobiera stronę, wysyła zwykłe żądanie HTTP GET, przyjmuje bajty zwrócone przez serwer i parsuje je jako tekst. Nie ma tu przeglądarki, budowania DOM, hydracji ani czekania na rozwiązanie wywołań XHR. Wspólna analiza Vercel i MERJ, przeprowadzona w sieci obsługującej w ciągu jednego miesiąca 569 milionów żądań GPTBot i 370 milionów żądań ClaudeBot, nie wykazała żadnych dowodów na wykonywanie kodu JavaScript przez którykolwiek z liczących się crawlerów AI. Crawlery czasem faktycznie pobierają pliki skryptów — GPTBot sięgał po JavaScript w 11,50% żądań, ClaudeBot w 23,84% — a potem nigdy ich nie uruchamiają.

Wyjątkiem jest Google — i to właśnie dlatego tak wiele zespołów nie zauważyło jeszcze problemu. Googlebot prowadzi usługę renderującą opartą na headless Chromium, a Gemini opiera się na tej infrastrukturze. Katalog parametryczny renderowany po stronie klienta może więc znakomicie rankować w wyszukiwarce Google, a jednocześnie być całkowicie nieobecny w ChatGPT, Claude i Perplexity. To już nie jest ta sama publiczność: z badania nabywców przeprowadzonego przez Forrester w 2026 roku wynika, że 94% nabywców biznesowych korzysta dziś z AI w procesie zakupowym, a Adobe zmierzył, że ruch kierowany przez AI na strony handlowe rósł w tempie 393% rok do roku w pierwszym kwartale 2026 roku.

Co GPTBot faktycznie dostaje

Warto precyzyjnie rozróżnić dwa dokumenty, o które tu chodzi, bo większość zespołów katalogowych ogląda wyłącznie ten drugi.

Surowy HTML to strumień bajtów, który serwer origin zapisuje w odpowiedzi. To właśnie wypisuje curl, to pokazuje view-source: i to parsuje czysto tekstowy klient HTTP.

Wyrenderowany DOM to zawartość pamięci po tym, jak przeglądarka sparsowała ten HTML, pobrała i wykonała każdy skrypt, rozwiązała każde wywołanie fetch() i zastosowała każdą mutację. To właśnie pokazuje panel Elements w narzędziach deweloperskich przeglądarki.

W nowoczesnym katalogu typu SPA te dwa dokumenty nie mają ze sobą prawie nic wspólnego. Surowy HTML jest pustą skorupą: <div id="root">, manifest preload i sto kilobajtów odwołań do bundle'i. Każdy znaczący ciąg znaków — numer katalogowy, obudowa, tolerancja, zakres temperatur pracy, status RoHS, status cyklu życia, stan magazynowy, próg cenowy — pojawia się później, z wywołania API, którego crawler nigdy nie wykona.

Crawler AI widzi Twój surowy HTML i nic poza tym. Jeśli danej specyfikacji nie ma w bajtach zwracanych przez serwer, to z punktu widzenia modelu ta specyfikacja nie istnieje.

Które klienty renderują, a które nie

Każde „Nie" w tej tabeli to zmierzone zachowanie ze zbioru danych Vercel i MERJ, a nie wniosek wysnuty z przesłanek. Każde „Tak" jest udokumentowane przez operatora: Google publikuje opis swojego potoku renderowania, a dokumentacja crawlera Apple stwierdza, że Applebot „może renderować zawartość Twojej witryny w przeglądarce". Nowsze agenty Anthropic — Claude-SearchBot i Claude-User — powstały już po tym badaniu i nie były mierzone osobno; od tego czasu żaden operator nie ogłosił dla nich potoku renderowania.

Praktyczna konsekwencja jest asymetryczna w wyjątkowo niewygodny sposób. Renderowanie to kosztowna część crawlowania, a operatorzy, którzy je pominęli, to dokładnie ci, którzy stoją dziś między Twoim produktem a Twoim klientem.

Dlaczego katalogi parametryczne wypadają gorzej niż cokolwiek innego

W analizie Adobe z kwietnia 2026 roku oceniono strony handlowe pod kątem czytelności maszynowej: karty produktów uzyskały 66% — najniższy wynik ze wszystkich typów stron, poniżej stron głównych (75%), stron kategorii (74%), a nawet stron FAQ (80%). Ta kolejność nie jest przypadkiem. Strony niosące dane najbardziej ustrukturyzowane, najcenniejsze i najistotniejsze dla decyzji zakupowej to jednocześnie te zbudowane z największą ilością kodu JavaScript.

Za większość szkód odpowiada pięć wzorców:

1. 01Stan filtrów żyje po stronie klienta. Twój selektor parametryczny to komponent React czytający z lokalnego magazynu stanu. Nie istnieje renderowany serwerowo URL dla „0603, 100nF, X7R, 50V", więc crawler nie ma czego pobrać ani czego zacytować.
2. 02Tabela specyfikacji to odpowiedź z API. Najpierw renderuje się szkielet strony, potem żądanie do /api/product/attributes wypełnia tabelę. Crawler zatrzymuje się na szkielecie.
3. 03Cena i dostępność są celowo po stronie klienta. Rozsądne ze względu na cache. Zabójcze dla widoczności maszynowej, bo model, który nie widzi stanu magazynowego, nie poleci danej części.
4. 04Zakładki i akordeony odraczają swoją treść. Karty katalogowe, noty aplikacyjne, certyfikaty zgodności i linki do plików CAD są zwykle ładowane po kliknięciu. Crawler nigdy nie klika.
5. 05Nieskończone przewijanie zastępuje paginację. Od pięćdziesiątego pierwszego produktu w górę nie ma już żadnego URL, który crawler mógłby odwiedzić.

W sierpniu 2026 roku Partsgraph zbadał 984 domeny dystrybutorów i producentów na całym świecie — w Ameryce Północnej, Europie i Azji. Mediana wyniku widoczności dla AI wyniosła 50 na 100, a 70% badanej grupy otrzymało ocenę D lub F. Mniej więcej połowa nie potrafiła podać standardowemu klientowi niebędącemu przeglądarką ani jednej czytelnej strony katalogowej. Najsłabszym segmentem okazała się dystrybucja elektroniki z medianą 34.

Jak sprawdzić, czy crawlery AI mogą odczytać mój katalog?

Rób to na własnym serwerze origin. Testowanie witryny konkurencji przez podszywanie się pod user-agenta crawlera daje wyniki fałszywie negatywne, bo korporacyjne systemy zarządzania botami weryfikują crawlery po źródłowym adresie IP, a nie po ciągu user-agent — podrobiony nagłówek z nierozpoznanego adresu zostanie zakwestionowany niezależnie od tego, co mówi robots.txt.

1. 01Pobierz surowy HTML. Wybierz swoją najcenniejszą pojedynczą stronę produktu.

curl -sS --compressed -o page.html -w "status=%{http_code} bytes=%{size_download}" "https://example.com/products/part-number"

1. 01Poszukaj numeru katalogowego w bajtach. Nie w przeglądarce — w pliku.

grep -c "MPN-12345" page.html

Jeśli zwróci to 0, żaden crawler AI nie rozpozna, że ta strona dotyczy tej części.

1. 01Poszukaj trzech wartości parametrycznych, po których inżynier zwykle filtruje.

grep -oiE "operating temperature|tolerance|package|rohs|lifecycle" page.html | sort | uniq -c

1. 01Policz bloki danych strukturalnych.

grep -c "application/ld+json" page.html

Zero oznacza brak rekordu produktu czytelnego maszynowo. Jeden lub więcej oznacza, że warto go wyodrębnić i sprawdzić, czy faktycznie zawiera sku, mpn, gtin, brand, offers oraz kluczowe wpisy additionalProperty, a nie wyłącznie ścieżkę nawigacyjną.

1. 01Porównaj z wyrenderowaną stroną. Otwórz ten sam URL w przeglądarce z wyłączonym JavaScript. To, co zostanie, mniej więcej odpowiada temu, co dostaje crawler. Różnica między tym a normalną stroną to Twoja niewidoczność.

1. 01Sprawdź całą ścieżkę, nie jedną stronę. Powtórz test dla strony kategorii, strony wyników wyszukiwania, linku do karty katalogowej i pobrania pliku CAD. Crawler, który potrafi odczytać stronę produktu, ale nie może do niej dotrzeć z listingu kategorii dostępnego dla crawlerów, i tak utknie.

Strona, która przejdzie test, pokaże numer katalogowy dziesiątki razy, etykiety parametryczne obecne jako tekst i co najmniej jeden blok JSON-LD. Dla porównania: dobrze zbudowana strona produktu zwraca zwykle 60–200 KB HTML zawierającego pełną tabelę specyfikacji, a zepsuty szkielet SPA — 4–15 KB, w których nie ma nic poza odwołaniami do bundle'i.

Jak to naprawić bez przepisywania całej witryny?

Nie musisz zmieniać platformy. Potrzebujesz tego, żeby bajty na serwerze origin zawierały fakty. Są cztery drogi i wcale się nie wykluczają.

Renderowanie po stronie serwera dla ścieżek produktowych i kategorii to odpowiedź trwała. Jeśli działasz już na frameworku, który to wspiera, przeniesienie ścieżek katalogowych na komponenty serwerowe albo na generowanie statyczne z inkrementalną rewalidacją to zwykle kwestia tygodni, nie kwartałów, bo warstwa danych już istnieje — jest tylko wywoływana z niewłaściwej strony.

Prerendering to uczciwe rozwiązanie przejściowe. Wyrenderuj każdą stronę produktu raz — podczas builda albo według harmonogramu — buforuj HTML na brzegu sieci i podawaj go wszystkim. Serwuj ludziom i maszynom ten sam dokument; podstawianie crawlerom innej strony jest zarówno ryzykowne w świetle wytycznych, jak i w praktyce nieskuteczne, bo model zacytuje tę wersję, którą otrzymał.

JSON-LD renderowany serwerowo to zmiana o najwyższej dźwigni przy najmniejszym nakładzie pracy. Umieść go w HTML, który emituje serwer, a nie w tag managerze.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "sku": "MPN-12345",
  "mpn": "MPN-12345",
  "name": "100 nF 50 V X7R 0603 ceramic capacitor",
  "brand": { "@type": "Brand", "name": "Example Components" },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Capacitance", "value": "100 nF" },
    { "@type": "PropertyValue", "name": "Voltage rating", "value": "50 V" },
    { "@type": "PropertyValue", "name": "Dielectric", "value": "X7R" },
    { "@type": "PropertyValue", "name": "Operating temperature", "value": "-55 to +125 C" }
  ],
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "0.042",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Kopia w Markdown to najtańszy sposób, by strona stała się jednoznaczna. Udostępnij czysto tekstowy odpowiednik każdej strony produktu pod stabilnym, podlinkowanym URL, z tabelą specyfikacji zapisaną jako tabela Markdown. Klienty czysto tekstowe parsują to bez zarzutu, wygenerowanie tego z tego samego źródła danych kosztuje niemal nic, a Ty zyskujesz kanoniczną powierzchnię maszynową, która nie rozjeżdża się przy przebudowie front-endu. Uwaga: llms.txt to co innego — na rok 2026 żaden liczący się operator AI nie zobowiązał się do jego czytania, a zespół Search Relations w Google wprost odmówił jego poparcia. Kopie działają dlatego, że są zwykłymi, podlinkowanymi stronami.

Nakładka umieszcza wszystko powyższe przed istniejącą witryną, a nie wewnątrz niej. Usługa typu sidecar albo edge worker serwuje renderowane serwerowo strony czytelne dla agentów, JSON-LD, kopie w Markdown oraz hostowany endpoint MCP w Twojej własnej domenie, czytając z istniejącego systemu PIM. W samej witrynie dla klientów nie zmienia się nic. Takie podejście stosuje Partsgraph i tak samo buduje u siebie coraz więcej producentów: Microchip udostępnił w listopadzie 2025 roku bezpłatny publiczny serwer MCP dla swoich danych produktowych, a należący do ECIA serwis TrustedParts uruchomił w czerwcu 2026 roku usługę agenta AI do stanów magazynowych.

Od czego zacząć, po kolei

1. 01Przeprowadź powyższy sześciostopniowy test na dziesięciu najważniejszych produktach i zapisz liczby bajtów.
2. 02Renderuj JSON-LD po stronie serwera na stronach produktów. To najmniejsza zmiana o największym mierzalnym efekcie.
3. 03Zadbaj, by każda specyfikacja, każdy link do karty katalogowej i każdy link do pliku CAD były obecne w pierwotnym HTML, nawet jeśli wersja interaktywna pozostanie po stronie klienta.
4. 04Nadaj każdej istotnej kombinacji filtrów parametrycznych prawdziwy, dostępny dla crawlerów, renderowany serwerowo URL.
5. 05Opublikuj kopię w Markdown dla każdego produktu i podlinkuj ją ze strony.
6. 06Dopiero potem martw się o pozycje, prompty i udział w odpowiedziach. Pobranie treści poprzedza cytowanie — nie ma czego optymalizować, dopóki treść nie znajdzie się w ciele odpowiedzi.

Mechanizm nie jest tu subtelny ani sporny. Model może zacytować wyłącznie to, co otrzymał, a otrzymał Twój surowy HTML. Cała reszta to krok renderowania, który nigdy się nie wydarzył.

Chcesz wiedzieć, jak wypada Twój katalog? Bezpłatny grader widoczności dla AI od Partsgraph przeprowadza opisane w tym artykule testy na Twojej własnej domenie pod adresem [/audit](/audit).