En React- eller Next.js-webbplats kan se komplett ut för besökaren samtidigt som Google möter tomt eller ofullständigt innehåll. Här får ni veta hur renderingen granskas och vilka tekniska krav som skyddar synlighet och leads.
Har ni betalat för en komplett React-webbplats som i praktiken visar Google en tom produktsida? Ja, det kan vara precis vad som händer när produktnamn, pris, beskrivning och länkar inte finns i serverns HTML utan hämtas först efter att JavaScript har körts. Det betyder inte att Google aldrig kan rendera JavaScript, men det gör upptäckt och indexering beroende av fler steg som kan fördröjas eller misslyckas. Bra JavaScript SEO börjar därför inte med antaganden om ramverket, utan med att kontrollera vilket innehåll som faktiskt levereras, renderas och hamnar i index.
JavaScript SEO: kontrollera tre versioner av sidan
När ett mindre e-handelsbolag såg att kategorisidorna tappade trafik fungerade allt normalt för personalen i Chrome, men en jämförelse avslöjade tre olika sidor: serverns ursprungliga HTML, webbläsarens renderade DOM och den version Google senast hade indexerat. Börja med att köra exempelvis curl mot en enskild produkt-, tjänste- eller kategori-URL och sök efter sidans unika huvudrubrik, produktbeskrivning, pris och viktigaste interna länkar; om de saknas är innehållet beroende av JavaScript, även om det inte automatiskt bevisar att Google aldrig kan läsa det. Jämför därefter svaret med Chrome DevTools Elements, där ni ser DOM:en efter att skript och API-anrop har lyckats, men granska själva HTML-strukturen och inte bara en till synes korrekt skärmbild eftersom en cookie-dialog, ett laddningsläge eller ett dolt felmeddelande kan täcka över saknad text. I Google Search Consoles URL-granskning visar live-testet vad Google kan hämta och rendera nu, medan uppgifterna om den indexerade URL:en speglar vad som användes vid en tidigare genomsökning, så två gröna besked betyder inte nödvändigtvis att versionerna innehåller samma text eller metadata. Gör kontrollen på URL:er som faktiskt skapas från CMS, produktdatabas eller externa flöden, inte bara på startsidan, eftersom ett fel i en dynamisk mall kan slå ut hundratals intäktsdrivande sidor samtidigt som företagets mest testade sida fortsätter fungera.
API-anrop efter sidladdning är den vanligaste riskzonen
I en typisk React-lösning returnerar komponenten först en tom behållare eller en skeleton, varefter useEffect hämtar produktdata från ett API och fyller sidan med innehåll; då finns både JavaScript-körningen och API-svaret som separata felpunkter. Ett anrop som är snabbt för utvecklaren med varm cache kan vara långsamt för en förstagångsbesökare, och det kan dessutom stoppas av autentisering, CORS-regler, rate limiting, robots.txt, brandvägg, geoblockering eller ett bot-skydd som behandlar Googlebot annorlunda. Risken ökar om API:t kräver cookies, lokal lagring eller en aktiv användarsession, eftersom sökmotorn inte säkert har samma tillstånd som den inloggade medarbetare som kvalitetssäkrade sidan. Samma osäkerhet uppstår när SEO-kritisk text eller länkar visas först efter ett klick, en filtrering, scrollning eller annan interaktion som Google inte kan förväntas utföra, vilket kan lämna både produkter och undersidor oupptäckta. I ett verklighetsnära test kan en kategorisida därför gå från 24 produkter till noll när API-anropet blockeras i DevTools Network, trots att dokumentet fortfarande svarar med HTTP-status 200 och ser tekniskt fungerande ut för övervakningssystemet.
Serverrendering krävs när innehållet måste synas i första HTML-svaret
Server-side rendering eller statisk generering är motiverad när innehållet förklarar sidans sökintention och affärserbjudande, exempelvis huvudrubrik, brödtext, produktlista, pris, centrala fakta, interna länkar och metadata. I Next.js kan stabila tjänste- och kategorisidor förgenereras, medan ofta uppdaterade produkt-, lager- eller annonssidor kan renderas på servern vid anrop eller använda tidsstyrd omgenerering genom cache och revalidering. Det innebär inte att varje komponent behöver serverrenderas: prisfilter, kalkylatorer, kundvagnar, personalisering och andra interaktiva förbättringar kan fortfarande köras i klienten efter att det grundläggande innehållet har levererats. Ett praktiskt acceptanskriterium är att sidans unika H1, primära erbjudande, viktigaste faktauppgifter, relevanta metadata och centrala HTML-länkar ska gå att hitta i svaret utan att JavaScript körs. Den avgränsningen minskar risken för tappad organisk trafik utan att företaget behöver betala kostnaden eller prestandapåslaget för dynamisk serverrendering på varje vy och varje användaranrop.
Next.js SEO best practices: metadata och länkar måste skapas i rätt skede
Att flytta en webbplats från React till Next.js löser inte automatiskt problemen med Next.js SEO, eftersom data som fortfarande hämtas i en klientkomponent efter montering inte nödvändigtvis finns i första HTML-svaret. I App Router bör sidans stabila data normalt hämtas i serverkomponenter, medan Metadata API eller generateMetadata kan leverera titel, metabeskrivning, canonical och delningsmetadata utifrån samma tillgängliga underlag; i äldre Pages Router fyller bland annat statisk generering och getServerSideProps motsvarande funktioner. Ett Next.js SEO-plugin kan förenkla mallar och konsekvent märkning, men det kan inte rädda metadata som bygger på ett blockerat API eller ersätta en renderingsstrategi som inte levererar huvudinnehållet. Kontrollera också att kategorier, produkter och tjänster nås genom vanliga <a href>-länkar med riktiga URL:er, eftersom knappar, filterstatus och oändlig scroll annars kan göra navigeringen begriplig för människor men opålitlig för sökmotorer. En användbar Next.js SEO-checklist slutar därför inte vid korrekt kod i Git-repot, utan kräver verifiering av rå HTML, renderad HTML, canonical, strukturerad data, länkar och den faktiskt indexerade versionen för ett representativt urval av URL:er.
Fördjupning: upptäck när JavaScript döljer affärskritiskt innehåll
Den renderade webbläsaren kan ge en falsk bild av vad som faktiskt publiceras
Den som öppnar en sida i sin vanliga Chrome-session ser slutresultatet efter cache, JavaScript, API-svar och eventuella användaruppgifter, inte nödvändigtvis det dokument som först publicerades. Kontrollera därför rå HTML från servern, DOM efter rendering och den version som Google kan hämta och har valt att indexera för exakt samma URL. Skillnaden är central vid Google-indexering av JavaScript: en komplett DOM hos utvecklaren visar att koden kan fungera under goda förhållanden, men inte att Google fick samma innehåll när sidan genomsöktes.
Exempel: Jämför Visa sidkälla, Chrome DevTools Elements och URL-granskning i Google Search Console och sök efter samma unika produktnamn i alla tre vyerna.
API-anrop efter sidladdning skapar fler felpunkter än teamet normalt testar
När viktigt innehåll kommer från ett separat API kan lång svarstid, autentiseringsproblem, CORS-regler eller tillfällig rate limiting lämna sidan nästan tom, även om grunddokumentet och JavaScript-filen laddas korrekt. Utvecklingsteamet missar ofta risken eftersom testerna sker från kontoret med stabil uppkoppling, redan satta cookies och varm cache, medan sökmotorn eller den nya kunden möter den långsamma första hämtningen. För ett SME-företag kan resultatet bli dubbelt dyrt: landningssidan tappar möjligheten att ranka samtidigt som annonserad trafik möter en tom produktlista och lämnar innan ett köp eller en offertförfrågan hinner ske.
Exempel: En kategorisida gick från 24 synliga produkter till noll när API-anropet blockerades i DevTools Network, trots att sidans HTTP-status fortsatte vara 200.
En laddningsindikator i HTML är inte en acceptabel reservversion
Skeletons och texten ”Laddar innehåll” kan göra väntan mindre störande, men de berättar inte för Google eller kunden vad sidan erbjuder. Om JavaScript kraschar efter att behållaren har skapats kan sidan fortfarande ha navigation, färger och en korrekt statuskod samtidigt som rubrik, internlänkar, pris och konverteringsinnehåll aldrig visas. En fungerande reservnivå måste därför innehålla själva budskapet, inte bara ett löfte om att budskapet snart ska laddas.
Exempel: Före åtgärden innehöll HTML endast <div id="app"></div>; efter serverrendering fanns H1, produkttext, pris och länkar i svaret redan vid första byte.
Serverrendering måste omfatta innehållet som avgör sidans syfte
Det räcker inte att serverrendera sidhuvud, sidfot och navigation om det unika huvudinnehållet fortfarande kräver ett lyckat klientanrop. På en jobbannons, produktsida eller lokal landningssida bör titel, beskrivning, centrala fakta och viktiga länkar finnas i ursprunglig HTML, medan JavaScript kan reserveras för filtrering, formulärval och personalisering. Prioriteringen gör lösningen robust utan att förvandla varje mindre gränssnittsfunktion till ett dyrt serverjobb.
Exempel: Efter SSR innehöll första HTML-svaret jobbets titel, ort, sista ansökningsdag och ansökningslänk i stället för att hämta hela annonsen från /api/jobs/4821 efter sidladdning.
Frågor som avslöjar vad sökmotorer faktiskt ser
Finns vårt viktigaste innehåll i den HTML som servern skickar, eller skapas det först efter att JavaScript har körts?
Öppna sidans råa källkod, inte bara webbläsarens inspektör, och sök efter huvudrubrik, brödtext, priser, kontaktvägar och interna länkar. Om innehållet saknas är sidan beroende av JavaScript-rendering, vilket kan fördröja indexering och skapar ytterligare felpunkter som måste testas. Använd flera sidtyper och URL:er med olika data, eftersom ett godkänt test av en manuellt byggd landningssida inte säger något om tusen databasdrivna produkter.
Kan Google se samma innehåll som våra besökare ser?
Testa URL:en i Google Search Console och jämför renderad HTML och skärmbild med den riktiga sidan, men jämför också live-resultatet med informationen från den indexerade versionen. Saknade texter, länkar, produktuppgifter eller metadata avslöjar ofta blockerade resurser, API-fel eller kod som Google inte lyckades köra vid rätt tillfälle. Dokumentera skillnaderna med datum, testad URL och förväntat innehåll så att utvecklarna får ett reproducerbart fel i stället för ett allmänt påstående om försämrad SEO.
Är viktiga sidor nåbara via vanliga HTML-länkar utan att användaren först måste klicka, filtrera eller scrolla?
Google behöver riktiga länkar med beständiga URL:er för att upptäcka sidor och förstå relationen mellan kategorier, tjänster och produkter. Om nästa uppsättning produkter endast laddas när besökaren scrollar, eller om en undersida öppnas genom en JavaScript-händelse utan href, kan centrala URL:er bli svåra att hitta. Behåll gärna oändlig scroll som användarupplevelse, men komplettera den med en crawlbar sidindelning och serverlevererade länkar.
Använder vår React- eller Next.js-lösning rätt renderingsmetod för affärskritiskt innehåll?
Landningssidor, kategorier, produkter och redaktionella sidor bör normalt använda statisk generering, tidsstyrd omgenerering eller serverrendering när innehållet behöver vara synligt direkt. Klientrendering är ett rimligt val för sådant som bygger på användarinteraktion och inte avgör sidans grundbetydelse, exempelvis ett prisfilter eller en inloggad kundvagn. Om hela sidan ändå klientrenderas behöver teamet kunna förklara varför och visa testresultat som bekräftar att innehåll, metadata och länkar konsekvent indexeras.
Vad händer med sidan när JavaScript är långsamt, blockeras eller kraschar?
Stäng av JavaScript, blockera relevanta API-anrop och testa med långsam mobil uppkoppling samt begränsad processor i Chrome DevTools. Om huvudbudskap, kontaktvägar, köpknappar eller ansökningslänkar försvinner har företaget inte bara ett SEO-problem, utan en direkt risk för tappade kunder och bortkastad annonsbudget. Ett test med kall cache är särskilt värdefullt eftersom det bättre efterliknar en ny besökare än utvecklarens återkommande session.
Börja med de sidor som driver flest leads, köp eller organiska besök och jämför serverns HTML med det användaren faktiskt ser. När kritiskt innehåll, länkar och metadata finns tillgängliga från start blir webbplatsen robustare för både sökmotorer och kunder, samtidigt som fel kan upptäckas innan de kostar trafik och intäkter. Arbetet med JavaScript SEO bör sedan följas upp med återkommande stickprov efter releaser, förändringar i API:er och uppdateringar av React eller Next.js. Ett erfaret team eller en teknisk partner angriper problemet genom att först bevisa var skillnaden uppstår, prioritera affärskritiska URL:er och därefter välja den minsta renderingsförändring som ger ett verifierbart resultat.
