JavaScript SEO za React in SPA spletne strani

Google izvaja JavaScript, vendar to ni dovoljenje za šibek HTML

Google JavaScript aplikacije obdela v treh fazah: crawling, rendering in indexing. Renderiranje potrebuje dodatne vire in se lahko zgodi pozneje od prvega pregleda HTML-ja. Drugi crawlerji, delilniki povezav in nekateri AI sistemi JavaScripta sploh ne izvajajo ali ga izvajajo omejeno. Ključna vsebina zato ne sme obstajati samo po uspešnem zagonu aplikacije.

Najvarnejši rezultat je, da začetni odziv vsebuje pravi title, description, canonical, H1, glavno besedilo, navigacijo in povezave. Interaktivnost lahko React nato hidrira. SSR ali build-time prerender nista čarobna ranking signala, odstranita pa pomembno tehnično negotovost ter izboljšata dostopnost vsebine.

Izberite pravilen način renderiranja za vrsto strani

Marketinške strani, storitve in članki se spreminjajo redkeje, zato so odlični kandidati za statično generiranje. Produktni katalogi in strani z rednimi spremembami lahko uporabljajo SSR ali inkrementalno regeneracijo. Uporabniški dashboard, ki ni namenjen indeksiranju, lahko ostane čisti SPA. Ena aplikacija lahko smiselno kombinira vse tri načine.

Odločitev naj temelji na indeksabilnosti, svežini podatkov, obsegu URL-jev in strošku renderiranja. Dinamično renderiranje samo za bote ustvarja operativno kompleksnost in možnost razlik med verzijami. Če je mogoče, uporabnikom in crawlerjem servirajte isti vsebinski HTML.

• Statični HTML za članke in storitve
• SSR za pogosto posodobljene javne strani
• SPA za zasebne aplikacijske zaslone
• Enaka bistvena vsebina za uporabnike in crawlerje

Routing mora ustvariti resnične, povezljive URL-je

Vsak indeksabilen pogled potrebuje stabilen URL in neposreden strežniški odziv. Uporabljajte History API ter običajne povezave z atributom href; navigacija, ki obstaja samo kot onClick dogodek, crawlerju ne predstavlja zanesljive poti. Hash fragmenti niso primerna osnova za ločene indeksabilne strani.

Strežnik oziroma CDN mora poznati vse javne poti. Če neznan URL vedno vrne status 200 z aplikacijsko lupino, nastanejo soft 404 strani. Obstoječi URL mora vrniti 200, trajno premaknjen 301 ali 308, odstranjen 404 ali 410, strežniška napaka pa 5xx. HTTP signal mora opisovati resnično stanje.

Metadata in schema morata biti del prvega odziva

Client-side knjižnica lahko po navigaciji spremeni title, toda crawler ali socialni bot lahko prebere samo začetni dokument. Vsaka pot naj zato že v HTML-ju vsebuje unikaten naslov, opis, canonical in Open Graph podatke. En generičen title v predlogi razvrednoti vse podstrani, četudi ga brskalnik pozneje popravi.

Enako velja za strukturirane podatke. Schema mora opisovati vidno vsebino posamezne poti, ne generičnega podjetja na vseh URL-jih. Article, Service, Product in BreadcrumbList ustvarite na strežniku ali med buildom ter poskrbite, da se po hidraciji ne podvojijo ali spremenijo v nasprotujočo različico.

Testirajte tisto, kar prejme crawler

View Source pokaže začetni HTML, DevTools pa DOM po izvajanju JavaScripta. Potrebujete oba pogleda. Z URL Inspection preverite Googlov render, z izklopljenim JavaScriptom pa ocenite, koliko pomena ostane drugim crawlerjem. Preglejte blokirane skripte, neuspele API klice, console napake in vsebino, ki se pojavi šele po uporabniški interakciji.

Avtomatski build test naj za vsako javno pot preveri title, canonical, robots, H1, minimalno vsebino, notranje povezave in status kode. Tako SEO ni ročni pregled pred lansiranjem, ampak lastnost sistema. Nova stran brez metapodatkov ali SSR vsebine mora prekiniti build, preden pride v produkcijo.

Pogosta vprašanja