Mönstret är så vanligt att det går att förutsäga. Ett team lanserar en ny single page-applikation. Allt fungerar i webbläsaren. Sex veckor senare är den organiska trafiken ner 60 %, sidor saknas i indexet och ingen kan peka på något trasigt.
Orsaken är nästan alltid rendering. Google kan köra JavaScript, vilket har lett till antagandet att JavaScript-SEO är ett löst problem. Det är det inte. Google renderar med fördröjning, inom resursgränser, utan användarinteraktion och utan tålamod med långsamma skript. Och 2026 finns en andra publik: de flesta AI-crawlers kör ingen JavaScript alls.
Vill du hitta SEO-problem på vilken webbplats som helst?
Testa WebSEO Auditor gratis — kör din första granskning på sekunder.
Testa gratisSå behandlar Google JavaScript
- Crawl. Googlebot hämtar rå HTML — exakt det curl returnerar, innan något skript körts.
- Renderingskö. Behöver sidan JavaScript hamnar den i kö. Det kan ta minuter, på lågprioriterade sajter betydligt längre.
- Rendering och indexering. En headless Chromium kör skripten, och den resulterande DOM:en är det som indexeras.
- Allt som inte finns i rå HTML indexeras sent — om alls.
- Renderaren scrollar inte, klickar inte och accepterar inga cookies. Innehåll bakom interaktion är osynligt.
- Rendering har budget. Långsamma eller havererande skript kan överges mitt i, och den partiella DOM:en indexeras.
Tumregeln: Google indexerar din råa HTML omedelbart och din renderade DOM så småningom. Allt kritiskt hör hemma i den första.
De fem felmönstren
1. Innehåll som kräver interaktion
Flikar, dragspel, "ladda mer"-knappar, oändlig scroll och innehåll bakom cookievägg. Dragspel är undantag endast när innehållet finns i DOM:en och bara döljs med CSS.
2. Klientroutning utan riktiga URL:er
Navigering byggd på onclick ger inga crawlbara länkar. Varje internt mål behöver ett riktigt ankare med href mot en serverupplösbar URL.
3. Blockerade JavaScript-resurser
Blockerar robots.txt dina skript- eller CSS-buntar kan renderaren inte bygga sidan. Att blockera assets för att spara crawlbudget är en falsk besparing.
4. Mjuka 404:or i SPA:er
En saknad produkt visar "hittades inte" på en sida som returnerar HTTP 200. Varje klientsidigt 404-läge måste paras med en äkta 404-status från servern.
5. Sena metataggar och strukturerad data
Titlar, canonicals och JSON-LD som injiceras efter laddning är opålitliga. All head-metadata ska finnas i det första HTML-svaret.
Renderingsstrategier jämförda
| Strategi | Vad crawlern får i rå HTML | SEO-lämplighet |
|---|---|---|
| Klientrendering (CSR) | En tom div | Dålig — undvik för indexerbart innehåll |
| Serverrendering (SSR) | Komplett HTML per anrop | Utmärkt |
| Statisk generering (SSG) | Förbyggd komplett HTML | Utmärkt — snabbast |
| Inkrementell statisk regenerering | Komplett HTML, byggs om periodiskt | Utmärkt för stora kataloger |
| Öar / partiell hydrering | Komplett HTML plus små JS-öar | Utmärkt |
| Dynamisk rendering | Annan HTML för bottar | Föråldrad lösning |
Revidera renderingen på en kvart
- Visa källkod, inte inspektera element. Sök efter en distinkt mening ur ditt huvudinnehåll.
- Hämta sidan med curl — det råa svaret är sanningen för icke-renderande crawlers.
- Stäng av JavaScript i DevTools och ladda om.
- Kör live-testet i URL-inspektion i Search Console.
- Jämför ordantal mellan rå HTML och renderad DOM.
- Räkna ankare med href i den råa HTML:en.
- Verifiera head-metadata i rå HTML.
- Testa en 404-rutt och kontrollera att statuskoden verkligen är 404.
Problemet med AI-crawlers
Crawlarna bakom AI-assistenter är i regel enkla HTTP-hämtare. De kör ingen webbläsare och väntar inte på hydrering. En klientrenderad sajt kan därför vara hyfsat indexerad av Google och i praktiken osynlig för AI-sök. Om AI-synlighet spelar roll är serverrendering inte längre en prestandapreferens utan ett inträdeskrav. Mer i AI och tolkning av revisionsresultat.
Ramverksspecifika noteringar
- React och Next.js: serverkomponenter renderas på servern, men klientkomponenter som hämtar egen data återinför problemet. Revidera per rutt.
- Vue och Nuxt: universal-läge fungerar, SPA-läge inte. Kontrollera vad produktionsbygget faktiskt använder.
- Angular: kräver Angular Universal, annars är råsvaret i praktiken tomt.
- Astro och öarkitektur: statisk HTML som standard — säkrast för innehållssajter.
- Headless e-handel: vanligaste källan till allvarliga problem.
Rendering kostar även prestanda
Tunga bundles fördröjer LCP eftersom huvudinnehållet inte kan målas innan skripten körts, och hydrering på huvudtråden driver upp INP i mobilen. Mindre JavaScript löser båda problemen samtidigt — se webbplatsens laddningshastighet och SEO.
Checklista i 12 punkter
- Huvudinnehållet syns i källkoden, inte bara i renderad DOM.
- Titel, canonical, meta robots och hreflang finns i första HTML-svaret.
- JSON-LD renderas på servern.
- Intern navigering använder ankare med riktiga href.
- Inget indexerbart innehåll ligger bakom klick, scroll eller cookievägg.
- JavaScript och CSS är inte blockerade i robots.txt.
- Saknade sidor returnerar äkta 404 eller 410.
- Paginering använder crawlbara länkar.
- Renderat resultat är identiskt för bottar och användare.
- URL-inspektion visar förväntat renderat innehåll.
- Rå HTML räcker för icke-renderande AI-crawlers.
- Bundle-storleken övervakas.
Symtom, orsak, åtgärd
De flesta JavaScript-SEO-utredningar landar i en av sex diagnoser. Tabellen kortar vägen från observation till reparation.
| Symtom | Trolig orsak | Åtgärd |
|---|---|---|
| Sidor indexerade men nästan tomma | Renderingen tog slut på tid eller ett skript havererade | Serverrendera huvudinnehållet, minska bundlen |
| Nya sidor dyker upp först efter veckor | Fördröjning i renderingskön | Lägg innehållet i första HTML-svaret och skicka in sitemap |
| Djupa sidor upptäcks aldrig | Navigering byggd på klickhanterare | Använd riktiga ankare med href |
| Fel titel i sökresultaten | Titeln skrivs om i klienten | Rendera titeln på servern |
| Rika resultat försvann | JSON-LD injiceras efter rendering | Skicka strukturerad data i HTML-svaret |
| Tomma sidor indexeras för borttagna produkter | Mjuk 404 med status 200 | Returnera äkta 404 eller 410 |
Övervaka renderingen över tid
Renderingsregressioner syns inte i kodgranskning. En refaktorering som flyttar datahämtning från servern till klienten ser korrekt ut i alla webbläsare och tömmer tyst den råa HTML:en. Fånga det i pipelinen i stället för i Search Console sex veckor senare.
- Testa rå HTML i CI. Hämta den byggda sidan utan att köra skript och verifiera att titel, H1, canonical och en känd innehållssträng finns. Några rader kod fångar merparten av regressionerna.
- Följ HTML-svarets storlek per mall. Ett plötsligt fall från 60 kB till 4 kB är en renderingsförändring ingen aviserade.
- Övervaka bundle-storleken med en budget som fäller bygget.
- Bevaka täckningsrapporten — tillväxt i "Genomsökt, för närvarande inte indexerad" är ofta första yttre symtomet.
- Kontrollera efter varje ramverksuppgradering. Standardinställningar för rendering ändras mellan större versioner oftare än release-noteringarna antyder.
Cookiebanners, samtycke och geo-omdirigeringar
Tre interaktionsmönster blockerar crawlers lika effektivt som vilken renderingsbugg som helst — och alla tre implementeras oftast av någon utanför SEO-samtalet.
Samtyckesväggar som döljer innehåll tills ett val gjorts gör att crawlern ser bannern och inget annat. Innehållet ska finnas i DOM:en oavsett samtyckesläge; samtycke styr spårning och personalisering, inte om artikeltexten existerar.
Klientsidiga geo-omdirigeringar skickar besökare till en lokaliserad version baserat på IP eller språk. Googlebot crawlar från ett fåtal platser, så aggressiv omdirigering gör att hela språkversioner aldrig genomsöks. Använd hreflang plus en förslagsbanner.
Åldersgrindar och inloggningsväggar gömmer allt bakom en interaktion renderaren aldrig utför. Ska innehållet ranka måste en meningsfull del synas utan inloggning.
Om du inte kan byta arkitektur
Alla kan inte gå över till serverrendering nästa månad. Tre mellansteg ger merparten av nyttan till betydligt lägre kostnad.
- Prerendera bara de publika sidorna. Marknadssidor, artiklar och produktsidor kan genereras statiskt även om den inloggade delen förblir klientrenderad.
- Flytta head-metadata till servern. Titel, beskrivning, canonical och JSON-LD är små ändringar som löser en oproportionerligt stor del av problemen.
- Rendera första vyn på servern och hydrera resten. Det ensamt lägger huvudinnehållet i rå HTML och förbättrar LCP samtidigt.
Går inget av detta på kort sikt: dokumentera risken och mät den. Håll en siffra på hur många procent av dina viktigaste sidor som är tomma i rå HTML. Den siffran är lätt att lägga fram nästa gång arkitekturbeslutet diskuteras.
Vad du bör mäta löpande
Tre nyckeltal räcker för att hålla renderingen under kontroll: andelen viktiga sidor vars huvudinnehåll finns i rå HTML, mediantiden från publicering till indexering, och antal sidor i "Genomsökt, för närvarande inte indexerad". Rör sig något av dem åt fel håll är det nästan alltid rendering eller innehållskvalitet — och du vet vilket genom att titta på det första talet.
Invändningar från utvecklare — och svaren
"Google kör ju JavaScript." Ja, men i kö och med resursgränser. Frågan är inte om utan när och hur tillförlitligt — och vad de crawlers gör som inte kör skript alls.
"Serverrendering komplicerar arkitekturen." Stämmer. Därför ska avgränsningen göras per sidtyp: publika sidor på servern, applikationsvyer i klienten. Hela appen behöver inte byggas om.
"Vi har redan en prerender-tjänst för bottar." Det är en föråldrad och skör lösning: den måste underhållas, kan gå sönder obemärkt och innebär att bottar och användare får olika HTML. Bygg inget nytt på den.
"Vi hinner inte den här sprinten." Den lättaste versionen är att flytta head-metadata och första vyns huvudinnehåll till servern. Det är oftast några dagars arbete och täcker merparten av risken.
Det mest effektiva sättet att föra samtalet är att visa, inte hävda: kör curl mot er viktigaste sida och titta tillsammans på vad svaret innehåller. En tom div avslutar diskussionen snabbare än något argument.
Innan ni väljer ramverk
Beslutet som avgör hur mycket JavaScript-SEO-arbete ni kommer att ha ligger före den första kodraden. Ställ tre frågor vid teknikvalet: renderas publika sidor som komplett HTML utan extra konfiguration, går metadata och strukturerad data att sätta per rutt på servern, och finns ett dokumenterat sätt att returnera riktiga statuskoder för saknade sidor?
Ramverk som svarar ja på alla tre kostar ingenting extra i SEO-arbete. Ramverk som kräver tillägg för varje punkt kostar det varje kvartal, i all framtid.
Kontrollera din egen sajt på två minuter
Öppna din viktigaste sida, visa källkoden och sök efter första meningen i huvudinnehållet. Saknas den ser varje icke-renderande crawler en tom sida.
Kör en gratis revision med WebSEO Auditor och se hur dina sidor ser ut för crawlers innan någon JavaScript körts.