JS SEO & rendering
JavaScript kan gömma ert innehåll för både Google och AI-crawlers. Förstå skillnaden på CSR, SSR och SSG, och testa vad sökmotorerna faktiskt kan läsa.
Moderna webbplatser byggs i stor utsträckning med JavaScript, och det finns goda skäl till det: snabbare utveckling, rikare upplevelser, flexibla arkitekturer. Men JavaScript väcker en fråga som klassisk HTML aldrig ställde: ser maskinerna samma sida som besökarna? Svaret avgör om ert innehåll alls kan hittas, i Google såväl som i AI-ytorna.
Varför rendering avgör er synlighet
Rendering är processen där JavaScript bygger den färdiga sidan. På en serverrenderad sajt ligger innehållet klart i den HTML servern skickar. På en client-side renderad sajt skickar servern i stället ett nästan tomt skal, och innehållet uppstår först när JavaScript har körts i webbläsaren.
För besökaren är slutresultatet ofta detsamma. För maskinerna är skillnaden avgörande: en crawler som inte kör JavaScript ser det tomma skalet. Ingen text, inga länkar, inga produkter.
Så hanterar Google JavaScript
Google kan rendera JavaScript och gör det med en uppdaterad Chromium-webbläsare. Men renderingen sker i två steg: Googlebot hämtar först sidans råa HTML, och själva JavaScript-renderingen hamnar i en kö som betas av när det finns resurser. Det ger tre konsekvenser.
- Fördröjning. Innehåll som bara finns efter rendering kan upptäckas och uppdateras långsammare än innehåll i den råa HTML-koden.
- Resurser. Rendering är dyrt, och stora sajter kan uppleva att bara en del av sidorna renderas så ofta som innehållet ändras.
- Fel. Blockerade JavaScript-filer, timeouts eller script som kraschar i Googles miljö lämnar sidan halvtom i indexet, utan att någon märker något i webbläsaren.
Länkarna förtjänar en egen punkt. Googlebot följer a-taggar med href-attribut. Navigation som bara fungerar via JavaScript-event kan lämna hela sektioner av sajten utan interna länkvägar att följa. Det underminerar både crawling och indexering och er interna länkstruktur.
AI-crawlers renderar som regel inte JavaScript
Här skiljer AI-ytorna sig från den klassiska diskussionen om JavaScript och SEO. Crawlerna bakom ChatGPT, Claude, Perplexity och de övriga hämtar i allt väsentligt bara den råa HTML-koden. De kör inte er JavaScript. Innehåll som bara existerar efter client-side rendering är därför osynligt för de flesta AI-ytor, hur bra det än står sig i Google.
Det gör serverrenderat innehåll till det säkra valet på båda ytorna: den HTML servern skickar som svar på första förfrågan ska innehålla ert verkliga innehåll. Klassisk search och AI-search ställer här exakt samma krav, och arbetet med AI Search-optimering börjar därför ofta just här.
Renderingsstrategier: CSR, SSR och SSG
- Client-side rendering (CSR). Allt byggs i webbläsaren. Snabbt att utveckla, men den svagaste lösningen för synlighet: Google får vänta på renderingskön, och AI-crawlers ser ett tomt skal. Rena client-side-appar i React eller Vue lägger så mycket arbete i webbläsaren att sidan riskerar att läsas fel eller inte alls.
- Server-side rendering (SSR). Servern bygger färdig HTML vid varje förfrågan. Innehållet är komplett från första byte, och JavaScript tar därefter över interaktiviteten i webbläsaren.
- Static site generation (SSG). Sidorna byggs som färdig HTML i förväg och levereras blixtsnabbt från ett CDN. Idealiskt för innehåll som inte ändras minut för minut, och moderna ramverk kan bygga om enskilda sidor löpande när innehållet uppdateras.
I praktiken väljer de flesta moderna ramverk, Next.js, Nuxt, SvelteKit, Astro och liknande, en hybrid: statisk eller serverrenderad HTML som fundament, JavaScript ovanpå för interaktivitet. Det ger samtidigt ett bra utgångsläge för Core Web Vitals, eftersom besökaren ser innehåll innan all JavaScript är hämtad och körd.

Headless CMS: frontenden avgör, inte CMS:et
Många JavaScript-diskussioner börjar i själva verket i ett CMS-val. Headless-arkitekturer, där innehållet ligger i system som Storyblok, Sanity, Contentful, Strapi eller Prismic och levereras via API till en fristående frontend, har blivit helt vanliga. Ur ett SEO-perspektiv är själva CMS-valet mindre viktigt än det ofta görs till.
Maskinerna kan inte se vilket CMS som ligger bakom. De ser uteslutande den HTML frontenden levererar. Innehållssystemet bestämmer alltså vad ni kan publicera, medan frontend-ramverket bestämmer vad maskinerna får se av det. Ett väl valt headless-upplägg med serverrendering kan därför vara ett starkt fundament, medan exakt samma CMS bakom en ren client-side-app gömmer bort allt innehåll. Lägg alltså uppmärksamheten där beslutet hör hemma: i frontend-arkitekturen. Mer om avvägningarna står i guiden till headless CMS, och det är också här vi oftast arbetar tillsammans med kundernas utvecklare eller vårt eget team inom webbutveckling.
Så testar ni vad maskinerna ser
- Visa källan. Öppna sidans källkod, inte inspektören, och sök efter en mening ur brödtexten. Står den där är innehållet serverrenderat. Inspektören visar i stället den färdigrenderade DOM:en, och skillnaden mellan de två är precis vad JavaScript bygger.
- Stäng av JavaScript. Inaktivera JavaScript i webbläsaren och ladda om sidan. Det ni ser nu är ungefär vad en AI-crawler ser.
- Använd URL-inspektion i Search Console. Verktyget visar den renderade HTML Google faktiskt indexerar, och avslöjar blockerade resurser och renderingsfel.
- Hämta sidan som en bot. Ett curl-anrop mot URL:en visar exakt den råa HTML servern levererar till crawlers utan rendering.
Typiska fallgropar
- Metadata som sätts i webbläsaren. Sidtitlar, metabeskrivningar och canonical-taggar som först infogas av JavaScript läses opålitligt. De hör hemma i den råa HTML-koden.
- Innehåll bakom interaktion. Text som hämtas först vid klick, scroll eller flikbyte indexeras som regel inte.
- Blockerad JavaScript. Ligger era script bakom blockeringar i robots.txt kan Google inte rendera sidan korrekt.
- Soft 404. Client-side-appar svarar ofta 200 OK på sidor som inte finns. Se till att statuskoderna är riktiga, så att fel kan upptäckas och hanteras. Det hänger tätt samman med er site health och era redirects.
JavaScript och SEO kan mycket väl fungera ihop, om rendering behandlas som ett arkitekturbeslut i stället för något man ordnar sist. Är ni osäkra på vad maskinerna faktiskt ser på er sajt kartlägger en gratis SEO-analys det tillsammans med resten av ert tekniska fundament.
