AI-crawlers kör inte JavaScript

Det korta svaret

AI-crawlers kör inte JavaScript. När GPTBot, ClaudeBot eller PerplexityBot begär en sida gör den en vanlig HTTP GET, tar emot de bytes som servern returnerar och tolkar dem som text. Det finns ingen webbläsare, ingen DOM-uppbyggnad, ingen hydrering och ingen väntan på att XHR-anrop ska besvaras. En gemensam analys från Vercel och MERJ, över ett nätverk som under en enda månad hanterade 569 miljoner GPTBot-förfrågningar och 370 miljoner ClaudeBot-förfrågningar, fann inga belägg för att någon större AI-crawler kör JavaScript. Crawlerna laddar visserligen ibland ner skriptfiler — GPTBot hämtade JavaScript i 11,50 % av förfrågningarna, ClaudeBot i 23,84 % — men kör dem aldrig.

Google är undantaget, och det är därför så många team inte har lagt märke till problemet. Googlebot driver en renderingstjänst med headless Chromium, och Gemini hämtar sitt underlag från samma infrastruktur. En parametrisk katalog som renderas på klientsidan kan alltså ranka utmärkt i Google Search och samtidigt saknas helt i ChatGPT, Claude och Perplexity. Det är inte längre samma publik: Forresters köparundersökning för 2026 visade att 94 % av företagsköparna nu använder AI under sin inköpsprocess, och Adobe mätte att AI-hänvisad trafik till handelssajter växte 393 % jämfört med föregående år under Q1 2026.

Vad GPTBot faktiskt tar emot

Det lönar sig att vara exakt med vilka två dokument det handlar om, eftersom de flesta katalogteam bara någonsin tittar på det andra.

Rå HTML är den byteström som origin-servern skriver till svaret. Det är vad curl skriver ut, vad view-source: visar och vad en HTTP-klient som bara hanterar text tolkar.

Den renderade DOM:en är det som finns i minnet efter att webbläsaren har tolkat den HTML-koden, laddat ner och kört varje skript, löst ut varje fetch()-anrop och tillämpat varje mutation. Det är vad panelen Elements i webbläsarens utvecklingsverktyg visar.

I en modern SPA-katalog har de två dokumenten nästan ingenting gemensamt. Den råa HTML-koden är ett skal: en <div id="root">, ett preload-manifest och hundra kilobyte med referenser till bundles. Varje meningsfull uppgift — artikelnummer, kapsel, tolerans, arbetstemperaturområde, RoHS-status, livscykelstatus, lagersaldo, prisstaffel — kommer senare, från ett API-anrop som crawlern aldrig kommer att göra.

En AI-crawler ser din råa HTML och ingenting annat. Om en specifikation inte finns i de bytes som servern returnerar, existerar den specifikationen inte för modellen.

Vilka klienter renderar och vilka gör det inte

Varje "Nej" i tabellen är uppmätt beteende från datamängden hos Vercel och MERJ, inte en gissning. Varje "Ja" är dokumenterat av operatören: Google publicerar sin renderingspipeline, och Apples egen crawler-dokumentation anger att Applebot "kan rendera innehållet på din webbplats i en webbläsare". De nyare agenterna Claude-SearchBot och Claude-User från Anthropic tillkom efter studien och mättes inte separat; ingen operatör har sedan dess aviserat någon renderingspipeline för dem.

Den praktiska konsekvensen är asymmetrisk på ett olyckligt sätt. Rendering är den dyra delen av att crawla, och de operatörer som hoppade över den är precis de som nu står mellan din produkt och din köpare.

Varför parametriska kataloger faller sämre ut än allt annat

I Adobes analys från april 2026 poängsattes handelssajters sidor efter maskinläsbarhet, och produktsidorna hamnade på 66 % — lägst av alla sidtyper, under startsidor (75 %), kategorisidor (74 %) och till och med FAQ-sidor (80 %). Den ordningen är ingen slump. De sidor som bär den mest strukturerade, mest värdefulla och mest beslutsrelevanta datan är också de som byggts med mest JavaScript.

Fem mönster står för merparten av skadan:

1. 01Filtertillståndet ligger i klienten. Din parametriska väljare är en React-komponent som läser från en lokal store. Det finns ingen serverrenderad URL för "0603, 100nF, X7R, 50V", alltså finns det ingenting för en crawler att hämta och ingenting att citera.
2. 02Specifikationstabellen är ett API-svar. Sidskalet renderas, sedan fyller en förfrågan till /api/product/attributes tabellen. Crawlern kommer inte längre än till skalet.
3. 03Pris och tillgänglighet ligger medvetet på klientsidan. Rimligt av cachningsskäl. Ödesdigert för maskinsynligheten, eftersom en modell som inte kan se lagersaldot inte kommer att rekommendera artikeln.
4. 04Flikar och dragspelsmenyer skjuter upp sitt innehåll. Datablad, applikationsnoter, intyg om regelefterlevnad och CAD-länkar laddas vanligen först vid klick. En crawler klickar aldrig.
5. 05Oändlig scroll ersätter paginering. Från produkt 51 och framåt finns ingen crawlbar URL över huvud taget.

Partsgraph granskade 984 distributörs- och tillverkardomäner världen över — Nordamerika, Europa och Asien — i augusti 2026. Medianvärdet för AI-synlighet var 50 av 100, och 70 % av gruppen fick betyget D eller F. Ungefär hälften kunde inte leverera en enda läsbar katalogsida till en vanlig klient utan webbläsare. Elektronikdistribution var det svagaste segmentet, med en median på 34.

Hur testar jag om AI-crawlers kan läsa min katalog?

Gör det här mot din egen origin. Att testa en konkurrents sajt genom att förfalska en crawlers user-agent ger falska negativa resultat, eftersom bothanterare i företagsklass verifierar crawlers via käll-IP och inte via user-agent-strängen — en förfalskad header från en okänd adress möts av en utmaning oavsett vad robots.txt säger.

1. 01Hämta den råa HTML-koden. Välj din allra viktigaste produktsida.

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

1. 01Leta efter artikelnumret bland bytena. Inte i webbläsaren — i filen.

grep -c "MPN-12345" page.html

Om detta returnerar 0 kan ingen AI-crawler identifiera sidan som en sida om den artikeln.

1. 01Leta efter tre parametriska värden som du förväntar dig att en ingenjör filtrerar på.

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

1. 01Räkna blocken med strukturerad data.

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

Noll betyder att det inte finns någon maskinläsbar produktpost. Ett eller fler betyder att du bör plocka ut den och kontrollera att den faktiskt bär sku, mpn, gtin, brand, offers och dina viktigaste additionalProperty-poster, och inte bara en brödsmulenavigering.

1. 01Jämför med den renderade sidan. Öppna samma URL i en webbläsare med JavaScript avstängt. Det som blir kvar är ungefär vad en crawler får. Skillnaden mellan det och den normala sidan är din osynlighet.

1. 01Kontrollera hela vägen, inte en enskild sida. Upprepa för en kategorisida, en sökresultatsida, en länk till ett datablad och en CAD-nedladdning. En crawler som kan läsa en produktsida men inte når fram till den från en crawlbar kategorilistning står ändå still.

En sida som klarar testet visar artikelnumret dussintals gånger, har de parametriska etiketterna på plats som text och innehåller minst ett JSON-LD-block. Som referens: en välbyggd produktsida returnerar vanligtvis 60–200 KB HTML med hela specifikationstabellen, medan ett trasigt SPA-skal returnerar 4–15 KB som inte innehåller något annat än referenser till bundles.

Hur åtgärdar du det utan att skriva om sajten?

Du behöver inte byta plattform. Du behöver få byten vid origin att innehålla fakta. Det finns fyra vägar, och de utesluter inte varandra.

Serverrendering av produkt- och kategorivägar är det hållbara svaret. Om du redan använder ett ramverk som stöder det är en flytt av katalogvägarna till serverkomponenter eller statisk generering med inkrementell omvalidering oftast en fråga om veckor, inte kvartal, eftersom datalagret redan finns — det anropas bara från fel sida.

Prerendering är den ärliga tillfälliga lösningen. Rendera varje produktsida en gång vid bygget eller enligt ett schema, cachea HTML-koden i edge-lagret och leverera den till alla. Servera samma dokument till människor och maskiner; att med cloaking visa crawlers en annan sida är både en policyrisk och, i praktiken, självförstörande, eftersom modellen citerar just den version den fick.

Serverrenderad JSON-LD är den ändring som ger mest effekt för minst insats. Lägg den i den HTML som servern skickar ut, inte i en tag manager.

<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>

En markdown-spegel är det billigaste sättet att göra en sida entydig. Publicera en motsvarighet i ren text av varje produktsida på en stabil, länkad URL, med specifikationstabellen återgiven som en markdown-tabell. Klienter som bara läser text tolkar den perfekt, det kostar nästan ingenting att generera den från samma datakälla, och du får en kanonisk maskinyta som inte glider iväg när frontenden görs om. Observera att llms.txt inte är detta: i skrivande stund 2026 har ingen större AI-operatör åtagit sig att läsa den, och Search Relations-teamet hos Google har uttryckligen avstått från att ställa sig bakom den. Speglar fungerar därför att de är helt vanliga länkade sidor.

Ett överlagringslager placerar allt ovanstående framför den befintliga sajten i stället för inuti den. En sidecar-tjänst eller edge worker levererar serverrenderade, agentläsbara sidor, JSON-LD, markdown-speglar och en hostad MCP-endpoint på din egen domän, med data hämtad ur ditt befintliga PIM. Ingenting förändras på den kundvända sajten. Det är den ansats Partsgraph använder, och det är också vad allt fler tillverkare bygger i egen regi: Microchip släppte en kostnadsfri, publik MCP-server för sina produktdata i november 2025, och TrustedParts inom ECIA lanserade en AI-agenttjänst för lagersaldon i juni 2026.

Vad du bör göra först, i ordning

1. 01Kör sexstegstestet ovan på dina tio viktigaste produkter och notera antalet byte.
2. 02Serverrendera JSON-LD på produktsidorna. Det är den minsta ändringen med den största mätbara effekten.
3. 03Se till att varje specifikation, länk till datablad och CAD-länk finns med i den initiala HTML-koden, även om den interaktiva versionen får ligga kvar på klientsidan.
4. 04Ge varje parametrisk filterkombination som spelar roll en riktig, crawlbar, serverrenderad URL.
5. 05Publicera en markdown-spegel per produkt och länka till den från sidan.
6. 06Först därefter bör du bry dig om rankningar, prompter och andel av svaren. Hämtning kommer före citering; det finns ingenting att optimera förrän innehållet faktiskt finns i svarskroppen.

Mekanismen här är varken subtil eller omtvistad. En modell kan bara citera det den tog emot, och det den tog emot är din råa HTML. Allt annat är ett renderingssteg som aldrig ägde rum.

Vill du veta var din katalog står? Den kostnadsfria AI-synlighetsmätaren från Partsgraph kör kontrollerna i den här artikeln mot din egen domän på [/audit](/audit).