JS SEO & rendering

Moderne nettsteder bygges i stor grad med JavaScript, og det er gode grunner til det: raskere utvikling, rikere brukeropplevelser, fleksible arkitekturer. Men JavaScript reiser samtidig et spørsmål klassisk HTML aldri stilte. Ser maskinene det samme som brukerne? Svaret avgjør om innholdet deres kan finnes i det hele tatt, i Google så vel som i AI-søkemotorene.

Hvorfor rendering avgjør synligheten

Rendering er prosessen der JavaScript bygger den ferdige siden. På et serverrendret nettsted ligger innholdet klart i HTML-en serveren sender. På et client-side rendret nettsted sender serveren i stedet et nesten tomt skall, og innholdet oppstår først når JavaScript har kjørt i nettleseren.

For brukeren er sluttresultatet ofte det samme. For maskinene er forskjellen grunnleggende: en crawler som ikke kjører JavaScript, ser det tomme skallet. Ingen tekst, ingen lenker, ingen produkter.

Slik behandler Google JavaScript

Google kan rendre JavaScript, og gjør det med en oppdatert Chromium-nettleser. Men renderingen skjer i to trinn. Googlebot henter først sidens rå HTML, og selve renderingen havner i en kø som kjøres når det er ressurser til det. Det gir tre konsekvenser.

• Forsinkelse. Innhold som bare finnes etter rendering, kan oppdages og oppdateres langsommere enn innhold som ligger i den rå HTML-en.
• Ressurser. Rendering er kostbart, og på store nettsteder blir bare en del av sidene rendret så ofte som innholdet endrer seg.
• Feil. Blokkerte JavaScript-filer, tidsavbrudd eller skript som feiler i Googles miljø, etterlater siden halvtom i indeksen, uten at noen ser det i nettleseren.

Lenker fortjener et eget punkt. Googlebot følger a-tagger med href-attributt, altså en lenke som inneholder hele adressen til siden den peker på. Navigasjon som bare fungerer gjennom JavaScript-hendelser, kan etterlate hele deler av nettstedet uten interne stier crawleren kan følge. Det undergraver både crawling og indeksering og den interne lenkestrukturen deres.

Google har også bekreftet at infinite scrolling som regel håndteres greit, men at det avhenger av implementeringen. Fordi Google rendrer sider med et svært stort viewport, vil den se mesteparten av innholdet hvis scrollingen utløses av skjermstørrelsen. Utløses den av at brukeren trykker på "last inn mer", ser Google ingenting: den trykker sjelden på knapper.

AI-crawlere rendrer som hovedregel ikke JavaScript

Her skiller AI-flatene seg fra den klassiske diskusjonen om JavaScript og SEO. Crawlerne bak ChatGPT, Claude, Perplexity og de andre henter i all hovedsak bare den rå HTML-en. De kjører ikke JavaScript-en deres. Innhold som først oppstår etter client-side rendering, er dermed usynlig for de fleste AI-flatene, uansett hvor godt det står i Google.

Det gjør serverrendret innhold til det trygge valget på begge flater: HTML-en serveren svarer med på første forespørsel, må inneholde det reelle innholdet. Klassisk search og AI-søk stiller her nøyaktig samme krav, og arbeidet med AI search-optimalisering begynner derfor ofte nettopp her.

Renderingsstrategier: CSR, SSR og SSG

• Client-side rendering (CSR). Alt bygges i nettleseren. Raskt å utvikle, men den svakeste løsningen for synlighet: Google må vente på renderingskøen, og AI-crawlere ser et tomt skall.
• Server-side rendering (SSR). Serveren bygger ferdig HTML ved hver forespørsel. Innholdet er komplett fra første byte, og JavaScript tar over interaktiviteten i nettleseren etterpå.
• Static site generation (SSG). Sidene bygges som ferdig HTML på forhånd og leveres lynraskt fra et CDN. Ideelt for innhold som ikke endrer seg fra minutt til minutt, og moderne rammeverk kan bygge enkeltsider på nytt løpende når innholdet oppdateres.

I praksis velger de fleste moderne rammeverk, som Next.js, Nuxt, SvelteKit og Astro, en hybrid: statisk eller serverrendret HTML som fundament, JavaScript på toppen for interaktivitet. Det gir samtidig et godt utgangspunkt for Core Web Vitals, fordi brukeren ser innhold før alt JavaScript er hentet og kjørt.

Frontenden avgjør, ikke CMS-et

Mange JavaScript-diskusjoner starter i virkeligheten med et CMS-valg. Headless-arkitekturer, der innholdet ligger i systemer som Storyblok, Sanity, Contentful eller Strapi og leveres via API til en selvstendig frontend, er blitt helt vanlige. Fra et SEO-perspektiv betyr selve CMS-valget mindre enn det ofte gjøres til.

Maskinene ser ikke hvilket CMS som ligger bak. De ser bare HTML-en frontenden leverer. Grovt sagt tar CMS-et vare på innholdet deres, mens frontend-rammeverket tar vare på den tekniske SEO-en. Et godt satt opp headless-oppsett med serverrendering kan derfor være et sterkt fundament, mens nøyaktig samme CMS bak en ren client-side app kan skjule alt innholdet. Legg oppmerksomheten der beslutningen faktisk hører hjemme: i frontend-arkitekturen. Det er også der vi oftest jobber sammen med utviklerne hos kunden, eller med vårt eget team i webutvikling.

Slik tester dere hva maskinene ser

1. Vis kilden. Åpne sidens kildekode, ikke inspektøren, og søk etter en setning fra brødteksten. Står den der, er innholdet serverrendret. Inspektøren viser den ferdig rendrede DOM-en, og forskjellen mellom de to er nøyaktig det JavaScript bygger.
2. Slå av JavaScript. Deaktivér JavaScript i nettleseren og last siden på nytt. Det dere ser nå, er omtrent det en AI-crawler ser.
3. Bruk URL-inspeksjon i Search Console. Verktøyet viser den rendrede HTML-en Google faktisk indekserer, og avslører blokkerte ressurser og renderingsfeil.
4. Hent siden som en bot. Et curl-kall mot URL-en viser den rå HTML-en serveren leverer til crawlere uten rendering.

Typiske fallgruver

• Metadata satt i nettleseren. Sidetitler, meta descriptions og canonical-tagger som først settes inn av JavaScript, leses upålitelig. De hører hjemme i den rå HTML-en.
• Innhold bak interaksjon. Tekst som først hentes ved klikk, scroll eller fanebytte, blir som regel ikke indeksert.
• Blokkert JavaScript. Ligger skriptene bak sperrer i robots.txt, kan ikke Google rendre siden korrekt.
• Soft 404-sider. Client-side apper svarer ofte 200 OK på sider som ikke finnes. Sørg for riktige statuskoder, slik at feil kan oppdages og håndteres. Det henger tett sammen med site health og redirects.

JavaScript og SEO lever fint sammen når rendering behandles som en arkitekturbeslutning framfor noe man ordner til slutt. Er dere i tvil om hva maskinene faktisk ser på nettstedet deres, avdekker en gratis SEO-analyse det sammen med resten av det tekniske fundamentet.