En e-handelswebbplats förlorade 47 % av sin synlighet i AI-sök efter att en uppdatering ändrade hur sidorna renderas. Samma produktsidor rankades fortfarande i Google. Men ChatGPT, Claude och Perplexity gav noll träffar. Skillnaden var JavaScript-rendering.
Det här händer varje webbplats som bygger på rendering i webbläsaren. En landningssida för en SaaS-tjänst, byggd med ett JavaScript-ramverk, dyker aldrig upp i ChatGPT:s svar. En nyhetssajt som kör på ett JavaScript-ramverk har ingen närvaro alls i Perplexity. En kunskapsbas som renderar sitt innehåll med ett JavaScript-bibliotek förblir osynlig för AI-crawlers. Det här är inga udda fall. Det är standardbeteendet hos de flesta moderna webbramverk.
Skillnaden mellan en JavaScript-driven webbplats och en som syns för AI handlar inte om komplexitet eller budget. Det handlar om att förstå vad som händer under de första millisekunderna när en crawler kommer fram.
Det AI-crawlers ser när de hämtar din sida
Googles crawler kör JavaScript. Den väntar tills sidan har renderats, fångar det slutliga visuella läget och indexerar det. De flesta AI-crawlers gör inte det.
När ChatGPT:s crawler (GPTBot) kommer till din webbplats går det till så här: 1. Den hämtar HTML-filen 2. Den plockar ut den text som syns i den råa HTML-koden 3. Den går vidare till nästa sida
JavaScriptet som renderar din rubrik, din produktbeskrivning och din artikeltext körs aldrig. Crawlern ser referenserna till JavaScript-filerna men ignorerar dem. Din sida ser ut som ett tomt skal utan innehåll.
Det beror på att AI-crawlers är byggda för fart och effektivitet. Att köra JavaScript är långsamt. Det kräver att man startar en webbläsare, väntar på att resurser laddas, hanterar fel och tidsgränser. När du crawlar miljarder sidor varje dag blir JavaScript-körning orimligt dyrt.
Google satsar på den infrastrukturen eftersom sökresultaten beror på att förstå visuell rendering. AI-sökmotorer prioriterar rå textextraktion. De är optimerade för att hämta fakta och citat direkt från HTML-koden, inte från det som visas efter att JavaScript har ändrat sidan.
Vilken rendering skapar problem för AI-crawlers
Inte alla JavaScript-ramverk ger samma synlighetsförlust. Problemet gäller specifikt rendering i webbläsaren (CSR), där JavaScript körs *i webbläsaren* och bygger sidan efter att HTML-koden har laddats.
Rendering i webbläsaren (CSR): populära JavaScript-ramverk när de är inställda på CSR. HTML-koden kommer tom eller med platshållare. JavaScript fyller i innehållet efter nedladdningen. AI-crawlers väntar inte.
Rendering på servern (SSR): ramverk som är byggda för serverrendering. Servern bygger sidan med innehållet redan inlagt i HTML-koden. Webbläsaren får komplett HTML. AI-crawlers ser allt direkt.
Statisk generering (SSG): statiska webbplatsgeneratorer. Sidorna byggs i förväg och publiceras som statiska HTML-filer. Ingen rendering sker när sidan efterfrågas. AI-crawlers får hela innehållet direkt.
Ensidesappar (SPA): Den kategori som har störst risk. En SPA laddar en enda HTML-fil och använder JavaScript för att byta innehåll när man navigerar. Varje sökväg ser likadan ut för en crawler, om inte servern hanterar varje sökväg för sig.
I samma stund som du väljer CSR som renderingsstrategi har du skapat en osynlig barriär mellan ditt innehåll och alla AI-crawlers på internet.
Därför spelar det större roll än du kanske tror
AI-sök är fortfarande i ett tidigt skede, men användningen växer snabbt. Studier visar att sökfrågor i AI växer snabbare än traditionella webbsökningar. ChatGPT, Perplexity och Claude blir primära researchverktyg för yrkesverksamma, studenter och beslutsfattare.
När någon frågar ChatGPT om "bästa webbplatsbyggare för småföretag" väljer AI:n vilka varumärken den citerar. Det beslutet beror på vilket innehåll den kan läsa. Om din sida drivs av JavaScript är den osynlig.
Det här är inget framtida problem. En analys från 2025 av över 500 miljoner GPTBot-förfrågningar visade att JavaScript-beroende webbplatser fick betydligt färre citat än serverrenderade konkurrenter i samma bransch. Gapet blev större för tekniskt innehåll, produktsidor och guider, alltså precis den typ av innehåll som AI-motorer prioriterar.
För B2B-företag och e-handlare blir AI-citat ett sätt att synas före konkurrenterna. Att bli citerad i ett ChatGPT-svar eller ett Perplexity-utdrag kan ge samma trafikvärde som en förstasidesplacering i Google. Men du kan inte bli citerad om crawlern inte kan läsa ditt innehåll.
Så avgör du vad du ska göra åt det
Alla webbplatser behöver inte lämna rendering i webbläsaren. Beslutet beror på tre faktorer: vilken typ av innehåll du har, vem din publik är och vilket affärsvärde AI-synlighet har i just din situation.
Ställ dig de här frågorna först:
Är ditt innehåll värt att citera i AI? Nyheter, guider, produktjämförelser, forskningsartiklar, expertråd. Sådant blir citerat av AI. Teknisk dokumentation, interaktiva verktyg och kontrollpaneler som mest finns för inloggade användare blir det inte. Om din webbplats mest är det senare spelar JavaScript-rendering mindre roll.
Söker din publik i AI-motorer? B2B-proffs, produktforskare, studenter och utvecklare. De använder AI-sök flitigt. Om din publik är mycket smal och bara söker i Google ger AI-synlighet mindre avkastning på kort sikt.
Vad kostar det att vara osynlig? För en nyhetssajt eller en kunskapsbas är noll AI-citat en konkurrensnackdel. För ett företags intranät eller en SaaS-tjänst bara för medlemmar spelar det ingen roll. För en e-handelswebbplats beror det på om dina kunder hittar produkter genom AI-shoppingtips.
Om du svarade "innehåll som är värt att citera i AI", "ja, min publik använder AI-sök" och "förlorad synlighet är en verklig kostnad", gå vidare. Om svaren är blandade kan du prioritera annorlunda.
Rendering på servern: den mest kompletta lösningen
SSR löser JavaScript-problemet helt. Servern bygger hela sidan med allt innehåll innan den skickas till webbläsaren. När en crawler kommer fram finns innehållet redan där.
Så fungerar det: När någon (eller en bot) ber om en sida kör din server koden och skapar den färdiga HTML-koden. Den innehåller din rubrik, din artikeltext och dina produktuppgifter. Webbläsaren får en komplett sida och visar den direkt. JavaScript kan fortfarande göra sidan mer interaktiv, men innehållet är redan tillgängligt.
Verktyg som gör SSR enkelt: flera moderna ramverk är byggda just för att göra SSR enkelt. Du skriver dina komponenter en gång, ramverket sköter renderingen på servern och sidan kommer färdigbyggd.
Avvägningen: SSR kräver serverresurser. Din server behandlar varje förfrågan, bygger HTML-koden och skickar ut den. Det tar mer processorkraft och minne än att leverera färdiga statiska filer. Långsamma eller komplexa sidor kan öka svarstiden, vilket påverkar prestandamått som First Contentful Paint (FCP) och Core Web Vitals.
För de flesta webbplatser är prestandaförlusten liten. För webbplatser med mycket trafik och komplexa sidor blir den märkbar. Det går att lösa med cachning, edge-beräkning eller kodoptimering, men det kräver arkitekturbeslut.
Förrendering: ett lättare sätt för statiskt innehåll
Förrendering bygger dina sidor i förväg och publicerar dem som statiska HTML-filer. När en crawler kommer fram får den en komplett sida direkt. När någon besöker sidan får hen en statisk fil som laddas extremt snabbt.
Tjänster för förrendering automatiserar det här. Du pekar dem mot din webbplats, de besöker varje adress i din sitemap, renderar varje sida (och kör JavaScriptet), fångar den slutliga HTML-koden och visar de statiska versionerna för crawlers, medan webbläsare fortfarande får den interaktiva versionen.
Det här fungerar om: Ditt innehåll ändras sällan. Blogginlägg, produktsidor, dokumentation. Innehåll som uppdateras kanske en gång per dag.
Det här fungerar inte om: Ditt innehåll är dynamiskt. Lagersaldon, användarspecifika data, information i realtid, personligt anpassat innehåll. Om sidan ser olika ut för varje besökare fångar förrendering inte alla versioner.
Kostnad och komplexitet: Sådana tjänster kostar ungefär 99-499 USD i månaden beroende på antal sidor. Du underhåller två uppsättningar innehåll: en för webbläsaren (JavaScript) och en förrenderad för crawlers. Det dubblar underhållsbördan. När du publicerar en ny artikel måste du bygga om och publicera om den statiska versionen.
För webbplatser med stabilt innehåll är förrendering ett praktiskt mellanläge mellan att inte göra något och att gå över till SSR.
Dynamisk rendering: ett taktiskt alternativ för vissa webbplatser
Dynamisk rendering känner av vilken användaragent som gör förfrågan. Om det är en crawler får den serverrenderad HTML. Om det är en webbläsare får den JavaScript-versionen. Då behåller du din nuvarande teknik och ger ändå crawlers fullständigt innehåll.
Idén är elegant i teorin. I praktiken är den skör. Du måste:
Underhålla en lista över AI-crawlers användaragenter och uppdatera den hela tiden när nya crawlers dyker upp. Missar du en ser den crawlern den tomma sidan.
Bygga serverrendering särskilt för crawlers och behålla rendering i webbläsaren för webbläsare. Det är i praktiken att bygga två versioner av din webbplats.
Testa att båda versionerna hålls synkade. Ett fel i crawlerversionen förstör din AI-synlighet utan att du märker det.
Dynamisk rendering fungerar för enkla innehållssajter. För komplexa applikationer är det mer besvär än det är värt. Om du ändå ska rendera på servern för crawlers kan du lika gärna rendera för alla (det är SSR).
Så ser du om din webbplats har problemet just nu
Du behöver inte gissa. Du kan kontrollera direkt.
Visa sidans källkod: Högerklicka på din sida, välj "Visa sidkälla" och sök efter din rubrik. Om rubriken inte finns i den råa HTML-koden är den renderad med JavaScript. AI-crawlers ser den inte.
Hämta med curl: Kör curl https://yoursite.com/your-page i terminalen. Om innehållet inte finns där har JavaScript renderat det.
Kontrollera din robots.txt: Om du hindrar crawlers från att köra JavaScript ser de bara den råa HTML-koden. Kontrollera din robots.txt eller webbplatsens crawlinställningar.
Använd ett crawlerverktyg: Ett SEO-crawlerverktyg kan hämta dina sidor som en crawler gör. Om innehållet syns i webbläsaren men inte i crawlern är JavaScript boven.
Sök direkt i AI-motorer: Sök i ChatGPT, Perplexity eller Claude efter specifika fraser från dina sidor. Om ditt innehåll aldrig dyker upp har du ett problem med JavaScript och synlighet.
Optimering för olika AI-crawlers
Inte alla AI-crawlers beter sig likadant. De har olika förmåga att rendera, olika crawlfrekvens och olika preferenser för innehåll.
ChatGPT (GPTBot): Kör inte JavaScript. Hämtar rå HTML. Använder ett externt sökindex för innehåll i realtid. Frekvens: ungefär varje vecka för etablerat innehåll.
Claude: Kör inte JavaScript. Hämtar rå HTML. Prioriterar färskt, auktoritativt innehåll. Frekvens: varierar efter signaler om hur nytt innehållet är.
Perplexity: Kör inte JavaScript. Hämtar rå HTML. Väger färskhet mycket tungt. Innehåll som är äldre än 48 timmar kan prioriteras ner. Frekvens: hög för heta ämnen, låg för statiskt innehåll.
Googles AI Overviews: Kör *faktiskt* JavaScript, eftersom de använder samma renderingsinfrastruktur som Google Sök. Men optimera som om de inte gjorde det, då syns du bättre för andra AI-sökmotorer.
Den praktiska slutsatsen: optimera inte för en enda crawler. Serverrendera ditt viktigaste innehåll, så syns du för alla.
Det här hjälper WEMASY till med
WEMASY:s webbplatsbyggare skapar serverrenderad HTML som standard. Varje sida du skapar byggs med innehållet i HTML-koden innan den når webbläsaren. Ingen JavaScript-rendering. Dina sidor syns direkt för AI-crawlers.
Om du jämför webbplatsbyggare och AI-synlighet spelar roll för ditt företag bör serverrendering vara ett krav, inte en eftertanke. Se vad som ingår i varje WEMASY-paket.
Vanliga frågor
Kan jag använda JavaScript för interaktiva funktioner utan att blockera AI-crawlers?
Ja. Serverrendera kärninnehållet (rubriken, artikeltexten, produktuppgifterna) och använd JavaScript för förbättringar (animationer, validering av formulär, interaktiva widgetar). Det kallas "progressive enhancement". Innehållet finns redan i HTML-koden och JavaScript lägger till finish ovanpå. AI-crawlers ser kärninnehållet. Webbläsare får hela den interaktiva upplevelsen. Med WEMASY:s webbplatsbyggare kan du ställa in det direkt på din webbplats.
Gör det min webbplats långsammare att gå över till serverrendering?
Det kan det göra, om din server är underdimensionerad eller dina sidor är komplexa. Modern serverrendering med cachelager (som edge-cachning hos moderna hostingplattformar) kan faktiskt vara snabbare än rendering i webbläsaren. Skillnaden är liten för de flesta webbplatser. Om prestanda oroar dig, testa i en testmiljö innan du bestämmer dig.
Måste jag byta hela min teknikstack?
Om du använder ett JavaScript-ramverk med CSR betyder en övergång till ett ramverk med SSR att du måste skriva om dina komponenter så att de fungerar med serverrendering. Det är inget snabbt byte. Om din webbplats är helt ny, välj ett ramverk med SSR i första hand från början. Har du en etablerad webbplats kan förrendering eller dynamisk rendering vara mer praktiskt på kort sikt.
Vad händer om AI-crawlers så småningom stöder JavaScript?
Det är möjligt, men inte snart. JavaScript-körning är beräkningsmässigt dyrt i stor skala. Om inte affärsvärdet av AI-citat motiverar infrastrukturkostnaden fortsätter crawlers att hämta rå HTML. Tills vidare: serverrendera ditt innehåll och minska risken.
Skadar min webbplats JavaScript-rendering mina rankningar i Google?
Nej. Googles crawler kör JavaScript, så dina rankningar i Google påverkas inte. Problemet gäller AI-sökmotorer som ChatGPT, Claude och Perplexity. De kör inte JavaScript. Serverrendera ditt innehåll om du vill synas i AI-sökresultat, inte för att Google kräver det. Det är ett separat problem från SEO.
Har nyhetssajter samma JavaScript-problem?
Ja, och det förbises ofta. En nyhetssajt som är byggd på ett JavaScript-ramverk som renderar innehållet i webbläsaren får noll AI-citat, även om innehållet är publicerat och indexerat. Nyhetsutgivare har upptäckt det av en slump, när artiklar som rankades i Google News fick noll omnämnanden i ChatGPT eller Perplexity. Kontrollera sidans källkod. Om din rubrik inte finns där, åtgärda det.