SEO för single page-applikationer: så får du en SPA indexerad av Google och läst av AI

SEO för single page-applikationer är de tekniker som gör en JavaScript-app byggd med React, Vue, Angular eller Svelte lika lätt att genomsöka som en klassisk webbplats. Problemet är väl dokumenterat: Google förklarar i sina grunder för JavaScript-SEO att de behandlar JavaScript-sidor i tre faser (genomsökning, rendering, indexering), och varje svaghet hos en SPA sitter någonstans i den kedjan. Den här guiden fokuserar på SPA:er; för JavaScript-webbplatser i allmänhet, läs vår guide om JavaScript-SEO.

Vad är en single page-applikation, och varför är den svår för SEO?

En klassisk webbplats returnerar ett komplett HTML-dokument för varje URL. En SPA returnerar nästan samma dokument för varje URL: en tom <div id="root">, några metataggar och ett stort JavaScript-paket. Webbläsaren laddar ner paketet, anropar ett API och ritar sedan sidan. När besökaren klickar på en länk byter JavaScript ut innehållet utan att sidan laddas om.

För en människa med en snabb telefon känns resultatet omedelbart. För en crawler är det första svaret ett tomt skal: ingen rubrik, ingen text, inga länkar. Allt beror på om roboten kör JavaScriptet, och när. Den enda faktan förklarar de flesta problemen med SEO för SPA:er:

• Fördröjt eller saknat innehåll: texten finns bara efter rendering, som Google utför senare och andra robotar hoppar över.
• En URL för många vyer: äldre SPA:er routar med fragment (/#/pricing), och delen efter # skickas aldrig till servern, så alla vyer slås ihop till en URL.
• Identiska titlar och beskrivningar: skalet bär en enda <title>, och om routern inte uppdaterar den delar varje sida den.
• Länkar utan href: knappar och onClick-hanterare navigerar för användarna men ger crawlers ingenting att följa.
• Mjuka 404-fel: servern svarar 200 för varje sökväg, även för sidor som inte finns, så felvyer indexeras som tunna sidor.
• Tung JavaScript: stora paket saktar ner den första visningen och interaktionerna, vilket skadar Core Web Vitals.

Hur genomsöker och renderar Google en SPA?

Googlebot hämtar först den råa HTML:en och läser länkarna och direktiven som finns där. Sidor som returnerar statuskoden 200 placeras sedan i en kö för Web Rendering Service, en headless Chromium. Google säger att en sida „kan stanna i kön i några sekunder, men det kan ta längre tid än så”. När sidan är renderad analyseras den resulterande HTML:en igen för innehåll och länkar, och indexeras sedan.

Fyra detaljer i Googles dokumentation spelar roll för SPA:er:

1. Bara <a>-element med en href är pålitliga länkar. Länkar som JavaScript lägger till är bra så länge de följer det formatet.
2. Fragment är inga separata sidor. Google ber dig använda History API (pushState) i stället för #-rutter. Google avvecklade sitt gamla AJAX-genomsökningsschema (URL:erna med #!) i oktober 2015.
3. En noindex i den ursprungliga HTML:en gäller. Google kan hoppa över renderingen när den ser noindex, så att ta bort den med JavaScript senare fungerar inte.
4. Renderingen använder cachade filer. Googlebot cachar JavaScript och CSS aggressivt, så använd filnamn med fingeravtryck (en innehållshash i filnamnet) för att undvika föråldrade paket.

Den praktiska konsekvensen: Google kan indexera en klientrenderad SPA, men du lägger till ett andra steg, en fördröjning och en felpunkt på varje sida. En timeout, ett blockerat API-anrop eller ett JavaScript-fel under renderingen lämnar den indexerade versionen tom. Kontrollera vad Google ser med verktyget URL-kontroll i Search Console, och läs vår guide om hur Googles indexering fungerar om sidor fortsätter att saknas i indexet.

Läser ChatGPT, Claude och Perplexity JavaScript?

Oftast inte. I en studie publicerad i december 2024 om trafiken i sitt nätverk fann Vercel och MERJ att „inga av de större AI-crawlerna för närvarande renderar JavaScript”: GPTBot, OAI-SearchBot och ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent och Bytespider läser alla bara den råa HTML:en. De laddar ner JavaScript-filer (ungefär 11,5% av ChatGPTs förfrågningar och 23,8% av Claudes) men kör dem inte. Undantagen är Gemini, som bygger på Googles renderingsinfrastruktur, och AppleBot, som använder en webbläsarbaserad crawler.

För en klientrenderad SPA betyder det att AI-crawlerna som matar ChatGPT, Claude och Perplexity ser en tom sida. Din produkt kan rankas på Google och ändå vara osynlig i AI-svar, eftersom assistenten aldrig läste ett ord av den. Samma gäller för de flesta länkförhandsvisningsrobotar i sociala nätverk och meddelandeappar, som läser Open Graph-taggarna i den råa HTML:en. När innehållet väl finns i HTML:en, kontrollera också att din robots.txt tillåter de AI-crawlers du vill ha.

Vilken renderingsstrategi bör en SPA använda?

Lösningen är att skicka riktig HTML i det första svaret. Google kallar dynamisk rendering (att bara skicka en förrenderad version till robotar) „en lösning för stunden och inte en rekommenderad lösning” i sin dokumentation om dynamisk rendering, och pekar i stället på serverrendering, statisk rendering eller hydrering. Definitionerna nedan följer referensen Rendering on the Web på web.dev.

De flesta moderna ramverk låter dig blanda strategier per rutt: statiskt för marknadsföringssidor, serverrenderat för katalogen, klientrenderat för den inloggade appen. Den hybrida uppsättningen ger sökrobotar fullständig HTML där söktrafiken finns och behåller SPA-upplevelsen där den tillför värde.

Alternativ bland ramverk

Webbplatser som genereras av AI-webbplatsbyggare förtjänar en särskild notering: många exporterar en klientrenderad React-app. Om du byggt din webbplats med en sådan, läs våra anteckningar om SEO och GEO för Lovable innan du antar att Google och ChatGPT kan läsa den.

Checklista för SEO i SPA:er: vad du ska åtgärda rutt för rutt

1. Ge varje vy en ren URL som går att genomsöka

Använd History API (/pricing, aldrig /#/pricing), en URL per innehållsstycke, och samma URL oavsett om besökaren kommer direkt eller via navigering i appen. Varje URL måste ladda rätt innehåll när den öppnas i en ny flik, vilket är testet en crawler gör.

2. Använd riktiga länkar

Varje navigeringselement som leder till en indexerbar sida bör vara en <a href="/path">. Ramverkens länkkomponenter (Link, NuxtLink, routerLink) skapar den här märkningen; egna klickhanterare på div- eller button-element gör det inte. Bra länkar bär också din webbplatsarkitektur: om en sida inte är länkad hittar crawlers den sällan.

3. Uppdatera titel, beskrivning och kanonisk länk per rutt

Varje rutt behöver sin egen titel, metabeskrivning, kanonisk länk och Open Graph-taggar, genererade på servern när det är möjligt. Vår sida om metataggar listar vad som ska sättas. Behåll en enda kanonisk tagg: Google rekommenderar att sätta den i HTML:en, och om JavaScript ändrar den får resultatet inte motsäga originalet.

4. Returnera ärliga statuskoder

Saknade produkter och raderade artiklar får inte svara 200 med ett felmeddelande. Med SSR returnerar du en riktig 404 eller 410 från servern. I en ren SPA godkänner Google två reservlösningar: omdirigera med JavaScript till en URL som returnerar 404, eller lägg till en noindex-metatagg för robotar på felvyn.

5. Lägg huvudinnehåll och strukturerad data i HTML:en

Rubriker, brödtext, priser, FAQ och JSON-LD-strukturerad data bör finnas i serverns svar, inte laddas efter ett klick eller en scroll. Innehåll bakom flikar som renderas vid behov, eller bakom knappar för „visa fler”, missas ofta.

6. Håll JavaScriptet lätt

Dela upp paketet per rutt, skjut upp det som inte behövs för första vyn och undvik att rendera om hela sidan vid hydrering. Observera att Chrome-fältdata (CrUX) tillskriver mätvärdena för navigering i appen till den URL som besökaren laddade först, så testa dina viktigaste mallar var för sig.

7. Testa vad robotarna får

Jämför tre versioner av varje viktig mall: den råa HTML:en (visa källkoden eller hämta sidan med ett kommandoradsverktyg), Googles renderade HTML (URL-kontroll, sedan „Visa genomsökt sida”) och sidan med JavaScript avstängt. Om huvudtexten bara syns i den andra versionen ser inte AI-crawlers den. Vår kostnadsfria granskning av genomsökbarhet för AI och kontroll av indexerbarhet gör dessa kontroller på valfri URL.

Hur vet du om din SPA har ett SEO-problem?

SEO för SPA:er och GEO: att hittas på Google och citeras av AI

I åratal var rendering i klienten en hanterbar risk, eftersom Google så småningom renderade JavaScript. Eftersom en del av upptäckten nu sker i ChatGPT, Claude, Gemini och Perplexity har kostnaden förändrats: en sida som bara finns efter att JavaScript körts saknas i de källor de flesta assistenter kan läsa. Genomsökbarhet i den råa HTML:en har blivit det första villkoret för generativ motormarknadsföring.

När HTML:en är komplett gäller resten de vanliga reglerna: sidor som besvarar en fråga tydligt, med källbelagda fakta och strukturerad data, är de som assistenterna citerar. Soranks GEO-optimering hjälper dig att skriva och publicera det innehållet, och spårning av AI-omnämnanden visar om ChatGPT, Claude och Gemini citerar ditt varumärke efter renderingsfixen.

Den viktigaste regeln i SEO för single page-applikationer får plats i en mening: det du vill att Google ska rangordna och AI ska citera måste finnas i den HTML som servern skickar. Behåll SPA:n för den inloggade upplevelsen, rendera publika sidor på servern eller vid bygget, och testa sedan vad robotarna får före och efter varje release.