SEO for enkeltsideapplikasjoner: slik får du en SPA indeksert av Google og lest av AI

SEO for enkeltsideapplikasjoner er settet med teknikker som gjør en JavaScript-app bygget med React, Vue, Angular eller Svelte like lett å crawle som et klassisk nettsted. Problemet er godt dokumentert: Google forklarer i sitt grunnleggende om SEO for JavaScript at den behandler JavaScript-sider i tre faser (crawling, rendering, indeksering), og hver svakhet i en SPA ligger et sted i den rørledningen. Denne guiden fokuserer på SPA-er; for JavaScript-nettsteder generelt, les vår guide til SEO for JavaScript.

Hva er en enkeltsideapplikasjon, og hvorfor er den vanskelig for SEO?

Et tradisjonelt nettsted returnerer et komplett HTML-dokument for hver URL. En SPA returnerer nesten det samme dokumentet for hver URL: en tom <div id="root">, noen metataggar og en stor JavaScript-pakke. Nettleseren laster ned pakken, kaller et API, og tegner så siden. Når besøkende klikker på en lenke, bytter JavaScript ut innholdet uten å laste siden på nytt.

For et menneske med en rask telefon føles resultatet øyeblikkelig. For en crawler er første svar et tomt skall: ingen overskrift, ingen tekst, ingen lenker. Alt avhenger av om roboten kjører JavaScript-en, og når. Den ene faktaen forklarer de fleste SEO-problemene i SPA-er:

• Forsinket eller manglende innhold: teksten finnes først etter rendering, som Google utfører senere, og andre roboter hopper over.
• Én URL for mange visninger: eldre SPA-er ruter med fragmenter (/#/pricing), og delen etter # sendes aldri til serveren, så alle visninger faller sammen til én URL.
• Identiske titler og beskrivelser: skallet har én <title>, og hvis ruteren ikke oppdaterer den, deler alle sidene den.
• Lenker uten href: knapper og onClick-behandlere navigerer for brukere, men gir crawlere ingenting å følge.
• Myke 404-feil: serveren svarer 200 på alle stier, også på sider som ikke finnes, så feilvisninger blir indeksert som tynne sider.
• Tung JavaScript: store pakker bremser den første visningen og interaksjonene, noe som skader Core Web Vitals.

Hvordan crawler og renderer Google en SPA?

Googlebot henter først den rå HTML-en og leser lenkene og direktivene den finner der. Sider som returnerer statuskode 200, legges deretter i kø for Web Rendering Service, en headless Chromium. Google sier at en side «kan bli stående i denne køen i noen sekunder, men det kan ta lengre tid». Når siden er rendret, analyseres den resulterende HTML-en på nytt for innhold og lenker, og deretter indekseres den.

Fire detaljer fra Googles dokumentasjon betyr noe for SPA-er:

1. Bare <a>-elementer med en href er pålitelige lenker. Lenker som JavaScript setter inn, er greie så lenge de følger det formatet.
2. Fragmenter er ikke egne sider. Google ber deg bruke History API (pushState) i stedet for #-ruter. Google utfasa sin gamle AJAX-crawlingordning (#!-URL-ene) i oktober 2015.
3. En noindex i den opprinnelige HTML-en vinner. Google kan hoppe over rendering når den ser noindex, så det hjelper ikke å fjerne den med JavaScript senere.
4. Rendering bruker bufrede filer. Googlebot bufrer JavaScript og CSS aggressivt, så bruk filnavn med fingeravtrykk (en innholdshash i filnavnet) for å unngå utdaterte pakker.

Den praktiske konsekvensen: Google kan indeksere en SPA med rendering i klienten, men du legger til et andre steg, en forsinkelse og et feilpunkt på hver side. En tidsavbrudd, et blokkert API-kall eller en JavaScript-feil under rendering etterlater den indekserte versjonen tom. Sjekk hva Google ser med URL-inspeksjonsverktøyet i Search Console, og les vår guide om hvordan indeksering hos Google fungerer hvis sider blir værende utenfor indeksen.

Leser ChatGPT, Claude og Perplexity JavaScript?

Stort sett ikke. I en studie publisert i desember 2024 om trafikken i sitt nettverk fant Vercel og MERJ at «ingen av de store AI-crawlerne rendrer JavaScript i dag»: GPTBot, OAI-SearchBot og ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent og Bytespider leser alle bare den rå HTML-en. De laster ned JavaScript-filer (rundt 11.5% av ChatGPTs forespørsler og 23.8% av Claudes), men kjører dem ikke. Unntakene er Gemini, som bruker Googles renderingsinfrastruktur, og AppleBot, som bruker en nettleserbasert crawler.

For en SPA med rendering i klienten betyr det at AI-crawlerne som mater ChatGPT, Claude og Perplexity ser en tom side. Produktet ditt kan rangere på Google og likevel være usynlig i KI-svar, fordi assistenten aldri leste et ord av det. Det samme gjelder de fleste lenkeforhåndsvisningsrobotene i sosiale nettverk og meldingsapper, som leser Open Graph-taggene i den rå HTML-en. Når innholdet står i HTML-en, bør du også sjekke at din robots.txt slipper til AI-crawlerne du ønsker.

Hvilken renderingsstrategi bør en SPA bruke?

Løsningen er å sende ekte HTML i første svar. Google kaller dynamisk rendering (å servere en forhåndsrendret versjon bare til roboter) «en omvei og ikke en anbefalt løsning» i sin dokumentasjon om dynamisk rendering, og peker i stedet på rendering på server, statisk rendering eller hydrering. Definisjonene nedenfor følger referansen Rendering på nettet på web.dev.

De fleste moderne rammeverk lar deg blande strategier per rute: statisk for markedsføringssider, rendret på server for katalogen, rendret i klienten for den innloggede appen. Dette hybride oppsettet gir crawlere full HTML der søketrafikken er, og beholder SPA-opplevelsen der den tilfører verdi.

Alternativer for rammeverk

Nettsteder generert av AI-nettstedsbyggere fortjener en spesiell nevnelse: mange eksporterer en React-app som rendres i klienten. Hvis du har bygget nettstedet ditt med en slik, se våre notater om SEO og GEO for Lovable før du antar at Google og ChatGPT kan lese det.

Sjekkliste for SEO i SPA-er: hva du skal fikse rute for rute

1. Gi hver visning en ren URL som crawlere kan finne

Bruk History API (/pricing, aldri /#/pricing), én URL per stykke innhold, og den samme URL-en enten besøkende kommer direkte eller via navigasjon i appen. Hver URL må laste riktig innhold når den åpnes i en ny fane, som er testen en crawler gjør.

2. Bruk ekte lenker

Hvert navigasjonselement som fører til en indekserbar side, bør være en <a href="/path">. Lenkekomponentene i rammeverkene (Link, NuxtLink, routerLink) gir denne markeringen; egne klikkbehandlere på div- eller button-elementer gjør ikke det. Gode lenker bærer også nettstedsarkitekturen din: hvis en side ikke er lenket, finner crawlere den sjelden.

3. Oppdater tittel, beskrivelse og kanonisk URL per rute

Hver rute trenger sin egen tittel, metabeskrivelse, kanonisk URL og Open Graph-tagger, generert på serveren når det er mulig. Vår side om metatagger lister hva du bør sette. Behold én kanonisk tagg: Google anbefaler å sette den i HTML-en, og hvis JavaScript endrer den, må resultatet ikke motsi originalen.

4. Returner ærlige statuskoder

Manglende produkter og slettede artikler må ikke svare 200 med en feilmelding. Med SSR returnerer du en ekte 404 eller 410 fra serveren. I en ren SPA godtar Google to reserveløsninger: omdirigere med JavaScript til en URL som gir en 404, eller legge til en noindex-robotmetatagg på feilvisningen.

5. Legg hovedinnholdet og de strukturerte dataene i HTML-en

Overskrifter, brødtekst, priser, FAQ og JSON-LD-strukturerte data bør stå i serverresponsen, ikke lastes etter et klikk eller en rulling. Innhold bak faner som rendres på forespørsel, eller bak knapper for «last inn flere», blir ofte oversett.

6. Hold JavaScript-en lett

Del pakken opp per rute, utsett det som ikke trengs for den første visningen, og unngå å rendre hele siden på nytt under hydrering. Merk at felt-data fra Chrome (CrUX) tilskriver målingene av navigasjoner i appen til URL-en besøkeren først lastet, så test de viktigste malene dine hver for seg.

7. Test hva roboter får

Sammenlign tre versjoner av hver viktig mal: den rå HTML-en (vis kilden, eller hent siden med et kommandolinjeverktøy), Googles rendrede HTML (URL-inspeksjon, deretter «Vis gjennomsøkt side») og siden med JavaScript slått av. Hvis hovedteksten bare dukker opp i den andre versjonen, ser ikke AI-crawlerne den. Vår gratis revisjon av gjennomsøkbarhet for AI og sjekkeren for indekserbarhet kjører disse testene på en hvilken som helst URL.

Hvordan vet du om SPA-en din har et SEO-problem?

SEO for enkeltsideapplikasjoner og GEO: å bli funnet på Google og sitert av AI

I årevis var rendering i klienten en håndterbar risiko, fordi Google til slutt rendret JavaScript. Nå som en del av oppdagelsen skjer i ChatGPT, Claude, Gemini og Perplexity, har kostnaden endret seg: en side som bare finnes etter JavaScript-kjøring, mangler i kildene de fleste assistentene kan lese. Gjennomsøkbarhet i den rå HTML-en har blitt det første kravet for generativ motoroptimalisering.

Når HTML-en er komplett, følger resten de vanlige reglene: sider som svarer tydelig på ett spørsmål, med kildebelagte fakta og strukturerte data, er de assistentene siterer. GEO-optimalisering fra Sorank hjelper deg å skrive og publisere det innholdet, og sporing av AI-omtaler viser om ChatGPT, Claude og Gemini siterer merket ditt etter rendringsfiksen.

Hovedregelen for SEO for enkeltsideapplikasjoner får plass i én setning: alt du vil at Google skal rangere og AI skal sitere, må stå i HTML-en serveren sender. Behold SPA-en for den innloggede opplevelsen, render offentlige sider på serveren eller ved bygging, og test deretter hva roboter får før og etter hver utgivelse.