Kaava on niin tuttu, että sen voi ennustaa. Tiimi julkaisee kauniin uuden yhden sivun sovelluksen. Selaimessa kaikki toimii. Kuusi viikkoa myöhemmin orgaaninen liikenne on pudonnut 60 %, sivuja puuttuu indeksistä eikä kukaan osaa osoittaa yhtäkään rikkinäistä kohtaa.
Syy on lähes aina renderöinti. Google osaa suorittaa JavaScriptiä, mistä on syntynyt laaja oletus, että JavaScript-SEO on ratkaistu ongelma. Ei se ole. Google renderöi viiveellä, resurssirajojen sisällä, ilman käyttäjän vuorovaikutusta ja ilman kärsivällisyyttä hitaita skriptejä kohtaan. Ja vuonna 2026 on toinenkin yleisö: valtaosa tekoälycrawlereista ei suorita JavaScriptiä lainkaan.
Haluatko löytää SEO-ongelmat miltä tahansa sivustolta?
Kokeile WebSEO Auditoria ilmaiseksi — tee ensimmäinen auditointi sekunneissa.
Kokeile ilmaiseksiTämä opas näyttää, miten auditoit sen mitä hakukoneet oikeasti näkevät, mitkä vikatilat aiheuttavat vahingon ja miten kukin korjataan.
Miten Google todella käsittelee JavaScriptin
JavaScript-sivun indeksointi ei ole yksi vaihe vaan kolme:
- Crawl. Googlebot hakee raa'an HTML-vastauksen — täsmälleen sen, minkä curl palauttaa ennen kuin yksikään skripti ajetaan.
- Renderöintijono. Jos sivu tarvitsee JavaScriptiä, se menee jonoon. Se voi kestää minuutteja ja matalamman prioriteetin sivustoilla huomattavasti kauemmin.
- Renderöinti ja indeksointi. Headless Chromium ajaa skriptit, ja syntynyt DOM on se mikä indeksoidaan.
Putkesta seuraa suoraan kolme asiaa, ja niistä syntyy lähes jokainen JavaScript-SEO-ongelma:
- Kaikki mikä ei ole raa'assa HTML:ssä indeksoituu myöhässä — jos ollenkaan. Uutisille, tuotelanseerauksille ja aikakriittiselle sisällölle myöhässä tarkoittaa ei koskaan.
- Renderöijä ei vieritä, klikkaa, hiiritä eikä hyväksy evästeitä. Vuorovaikutuksen takana oleva sisältö on näkymätöntä.
- Renderöinnillä on budjetti. Hitaat, kaatuvat tai hitaasta rajapinnasta riippuvat skriptit voidaan hylätä kesken, jolloin osittainen DOM indeksoidaan.
Luotettava ajatusmalli: Google indeksoi raa'an HTML:si heti ja renderöidyn DOM:isi joskus. Kaikki kriittinen kuuluu ensimmäiseen.
Viisi vikatilaa
1. Sisältö, joka vaatii vuorovaikutusta
Välilehdet, harmonikat, "lataa lisää" -napit, ääretön vieritys ja evästemuurin takana oleva sisältö. Jos käyttäjän täytyy klikata nähdäkseen sen, renderöijä ei näe sitä koskaan. Harmonikat ovat poikkeus vain silloin, kun sisältö on DOM:issa ja vain piilotettu CSS:llä — supistettu on ok, puuttuva ei.
2. Selainpuolen reititys ilman oikeita URL-osoitteita
Navigaatio, joka on toteutettu onclick-käsittelijöillä tai napeilla, ei tuota crawlattavia linkkejä. Jokainen sisäinen kohde tarvitsee aidon ankkurin href-attribuutilla, joka osoittaa oikeaan palvelimella ratkeavaan osoitteeseen.
3. Estetyt JavaScript-resurssit
Jos robots.txt estää skripti- tai CSS-nippusi, renderöijä ei pysty rakentamaan sivua. Tätä tapahtuu yhä säännöllisesti sivustoilla, jotka estävät /static/- tai /assets/-polut crawl-budjetin säästämiseksi. Se on näennäissäästö, joka maksaa koko renderöidyn sivun.
4. Pehmeät 404:t yhden sivun sovelluksissa
Puuttuva tuote renderöi "ei löytynyt" -viestin sivulle, joka palauttaa HTTP 200:n. Hakukone indeksoi tyhjän sivun kelvollisena. Jokainen selainpuolen 404-tila pitää yhdistää aitoon 404-statukseen palvelimelta.
5. Myöhässä lisätyt meta-tagit ja rakenteinen data
JavaScriptin latauksen jälkeen lisäämät otsikot, kanoniset tagit, metakuvaukset ja JSON-LD ovat epäluotettavia. Erityisesti kanonisia tageja sivuutetaan usein, jos ne ilmestyvät vasta renderöinnin jälkeen. Kaiken head-metatiedon pitää olla ensimmäisessä HTML-vastauksessa.
Renderöintistrategiat vertailussa
| Strategia | Mitä crawler saa raa'assa HTML:ssä | Soveltuvuus SEO:on |
|---|---|---|
| Selainpuolen renderöinti (CSR) | Tyhjä div | Huono — vältä indeksoitavassa sisällössä |
| Palvelinrenderöinti (SSR) | Täysi HTML per pyyntö | Erinomainen |
| Staattinen generointi (SSG) | Valmiiksi rakennettu HTML | Erinomainen — nopein vaihtoehto |
| Inkrementaalinen staattinen regenerointi | Täysi HTML, ajoittain uudelleenrakennettu | Erinomainen isoille katalogeille |
| Saarekkeet / osittainen hydraatio | Täysi HTML ja pienet JS-saarekkeet | Erinomainen |
| Dynaaminen renderöinti | Eri HTML boteille | Vanhentunut kiertotie — älä rakenna uutta sen varaan |
Päätössääntö on yksinkertainen: jokaisen indeksoitavaksi tarkoitetun sivun pitää saapua täytenä HTML:nä ensimmäisessä vastauksessa. Käytä JavaScriptiä valmiin sivun rikastamiseen, älä sen rakentamiseen.
Renderöinnin auditointi vartissa
- Näytä sivun lähdekoodi, älä tarkastele elementtiä. Elements-paneeli näyttää renderöidyn DOM:in; lähdekoodinäkymä näyttää sen, minkä crawler saa ensin. Etsi lähteestä tunnistettava lause pääsisällöstäsi.
- Hae sivu curlilla. Raaka vastaus on totuus siitä, mitä renderöimätön crawler näkee.
- Poista JavaScript käytöstä DevToolsissa ja lataa sivu uudelleen. Jäljelle jäävä on karkeasti pahin mahdollinen indeksoitava sivusi.
- Aja URL-tarkistuksen live-testi Search Consolessa ja lue renderöity HTML sekä konsolivirheet.
- Vertaa sanamääriä raa'an HTML:n ja renderöidyn DOM:in välillä. Iso ero mittaa renderöintiriippuvuutesi.
- Tarkista sisäiset linkit raa'asta HTML:stä. Laske href-attribuutilliset ankkurit.
- Varmista head-metatiedot raa'asta HTML:stä — otsikko, kanoninen, meta robots, hreflang, JSON-LD.
- Testaa 404-reitti ja varmista, että HTTP-status on aidosti 404 eikä 200.
Tekoälycrawlereiden ongelma
Tämä on osa, joka muuttui viimeksi, ja syy siihen miksi JavaScript-SEO ansaitsee uutta huomiota vuonna 2026. Tekoälyavustajien ja vastauskoneiden crawlerit ovat ylivoimaisesti useimmiten yksinkertaisia HTTP-hakijoita. Ne eivät aja headless-selainta, eivät odota hydraatiota eivätkä suorita nippuasi.
Käytännön seuraus: selainpuolella renderöity sivusto voi olla Googlelle riittävästi indeksoitu ja tekoälyhaulle käytännössä näkymätön. Tuotekuvauksesi, hintasi ja dokumentaatiosi eivät yksinkertaisesti ole olemassa crawlerille, joka lukee vain raa'an vastauksen.
Jos tekoälynäkyvyydellä on liiketoiminnallista merkitystä, palvelinrenderöity tai staattisesti generoitu HTML ei ole enää suorituskykymieltymys vaan pääsyvaatimus. Laajempi kuva on artikkelissa tekoäly SEO-auditoinnin tulkinnassa.
Frameworkkohtaiset huomiot
- React ja Next.js: App Routerin palvelinkomponentit renderöityvät oletuksena palvelimella, mutta jokainen client-komponentti joka hakee datansa selaimessa tuo ongelman takaisin. Auditoi reitti kerrallaan, ei projekti kerrallaan.
- Vue ja Nuxt: Universal-tila on kunnossa, SPA-tila ei. Varmista mitä tilaa tuotantobuildi oikeasti käyttää — julkaisukonfiguraatio poikkeaa usein kehitysympäristöstä.
- Angular: Vaatii Angular Universalin palvelinrenderöintiin. Ilman sitä raaka vastaus on käytännössä tyhjä.
- Astro ja saarekearkkitehtuurit: Staattista HTML:ää oletuksena ja valikoiva hydraatio — turvallisin oletus sisältösivustoille.
- Headless-verkkokauppa: Yleisin vakavien ongelmien lähde, koska tuotedata haetaan usein selaimessa erillisestä rajapinnasta latauksen jälkeen.
Renderöinti maksaa myös suorituskykyä
Raskas selainpuolen renderöinti vahingoittaa Core Web Vitalsia siinä missä indeksointiakin. Isot niput viivästyttävät LCP:tä, koska pääsisältö ei voi piirtyä ennen JavaScriptin suoritusta, ja hydraatio pääsäikeessä kasvattaa INP:tä mobiililaitteilla.
JavaScriptin vähentäminen korjaa siis molemmat ongelmat samalla kertaa — sama korjaus, joka tekee sivuista indeksoitavia, tekee niistä nopeampia. Suorituskykypuoli on käyty läpi artikkelissa verkkosivuston latausnopeus ja SEO.
12 kohdan JavaScript-SEO-tarkistuslista
- Pääsisältö näkyy lähdekoodissa, ei vain renderöidyssä DOM:issa.
- Otsikko, kanoninen, meta robots ja hreflang ovat ensimmäisessä HTML:ssä.
- JSON-LD-rakenteinen data renderöityy palvelimella.
- Sisäinen navigaatio käyttää ankkureita oikeilla href-attribuuteilla.
- Indeksoitavaa sisältöä ei ole klikkausten, vierityksen tai evästemuurin takana.
- JavaScript- ja CSS-resursseja ei ole estetty robots.txt:ssä.
- Puuttuvat sivut palauttavat aidon 404- tai 410-statuksen.
- Sivutus käyttää crawlattavia linkkejä, ei klikkauskäsittelijöitä.
- Renderöity lopputulos on sama boteille ja käyttäjille — ei cloakingia.
- Search Consolen URL-tarkistus näyttää odotetun renderöidyn sisällön.
- Pelkkä raaka HTML sisältää tarpeeksi sisältöä renderöimättömille tekoälycrawlereille.
- Nipun kokoa seurataan, koska sekä renderöintibudjetti että LCP riippuvat siitä.
Oire, syy, korjaus
Useimmat JavaScript-SEO-selvitykset päätyvät johonkin kuudesta diagnoosista. Tämä taulukko lyhentää matkaa havainnosta korjaukseen.
| Oire | Todennäköinen syy | Korjaus |
|---|---|---|
| Sivut indeksissä mutta lähes tyhjinä | Renderöinti aikakatkaistiin tai skripti kaatui | Renderöi pääsisältö palvelimella, pienennä nippua |
| Uudet sivut ilmestyvät vasta viikkojen päästä | Renderöintijonon viive | Sisällytä sisältö ensimmäiseen HTML:ään ja lähetä sivukartassa |
| Syvät sivut eivät löydy koskaan | Navigaatio rakennettu klikkauskäsittelijöistä | Käytä aitoja ankkureita href-attribuutilla |
| Väärä otsikko hakutuloksissa | Otsikko kirjoitetaan uusiksi selaimessa | Renderöi otsikko palvelimella |
| Rikkaat tulokset katosivat | JSON-LD lisätään renderöinnin jälkeen | Tuota rakenteinen data HTML-vastauksessa |
| Poistetuille tuotteille indeksoituu tyhjiä sivuja | Pehmeä 404 statuksella 200 | Palauta aito 404 tai 410 palvelimelta |
Renderöinnin seuranta ajan yli
Renderöintiregressiot ovat näkymättömiä koodikatselmoinnissa. Komponenttirefaktorointi, joka siirtää datan haun palvelimelta selaimeen, näyttää oikealta jokaisessa selaimessa ja tyhjentää hiljaa raa'an HTML:n. Nappaa se putkessa äläkä Search Consolesta kuuden viikon päästä.
- Tarkista raaka HTML CI:ssä. Hae rakennettu sivu ilman skriptien suoritusta ja varmista, että otsikko, H1, kanoninen tagi ja tunnettu sisältömerkkijono löytyvät. Muutama rivi koodia nappaa valtaosan regressioista.
- Seuraa HTML-vastauksen kokoa sivupohjittain. Äkillinen pudotus 60 kilotavusta neljään on renderöintimuutos, josta kukaan ei kertonut.
- Valvo nipun kokoa budjetilla, joka kaataa buildin ylityksestä.
- Tarkkaile Search Consolen kattavuutta — "Indeksoitu, ei tällä hetkellä indeksissä" -määrän kasvu on usein ensimmäinen ulkoinen oire.
- Tarkista uudelleen jokaisen framework-päivityksen jälkeen. Renderöinnin oletusarvot muuttuvat pääversioiden välillä useammin kuin julkaisutiedotteista päättelisi.
Sama putkitarkistus suojaa myös toisen asteen ongelmalta: sivulta, joka renderöityy Googlebotille oikein mutta ei toimita mitään hyödyllistä crawlereille jotka eivät aja skriptejä lainkaan.
Evästebannerit, suostumus ja geo-ohjaukset
Kolme vuorovaikutuskaavaa estää crawlerin yhtä tehokkaasti kuin mikä tahansa renderöintibugi, ja kaikki kolme toteuttaa yleensä joku SEO-keskustelun ulkopuolelta.
Suostumusmuurit, jotka piilottavat sisällön kunnes valinta on tehty, tarkoittavat että crawler näkee bannerin eikä mitään muuta. Sisällön pitää olla DOM:issa suostumustilasta riippumatta; suostumus koskee seurantaa ja personointia, ei sitä onko artikkelin teksti olemassa.
Selainpuolen geo-ohjaukset siirtävät kävijän lokalisoituun versioon IP:n tai selaimen kielen perusteella. Googlebot crawlaa pääosin harvoista sijainneista, joten aggressiivinen ohjaus tarkoittaa että kokonaisia kieliversioita ei crawlata koskaan. Käytä hreflangia ja ehdotusbanneria.
Ikäportit ja kirjautumismuurit piilottavat kaiken vuorovaikutuksen taakse, jota renderöijä ei tee. Jos sisällön on tarkoitus sijoittua, merkittävän osan siitä pitää näkyä ilman kirjautumista.
Mitä tehdä, jos et voi vaihtaa arkkitehtuuria
Kaikki eivät voi siirtyä palvelinrenderöintiin ensi kuussa. Kolme välivaihetta tuottaa suurimman osan hyödystä pienemmällä työllä.
- Prerenderöi vain julkiset sivut. Markkinointisivut, artikkelit ja tuotesivut voidaan generoida staattisesti, vaikka sovelluksen kirjautunut puoli jäisi selainpuolelle.
- Siirrä head-metatiedot palvelimelle. Otsikko, kuvaus, kanoninen ja JSON-LD ovat pieniä muutoksia ja korjaavat suhteettoman ison osan ongelmista.
- Renderöi ensimmäinen näkymä palvelimella ja hydratoi loput. Tämä yksin tuo pääsisällön raakaan HTML:ään ja parantaa LCP:tä samalla.
Jos mikään näistä ei ole mahdollista lyhyellä aikavälillä, dokumentoi riski ja mittaa se: pidä listaa siitä, montako prosenttia tärkeimmistä sivuistasi on tyhjiä raa'assa HTML:ssä. Se luku on helppo esittää, kun renderöintipäätöstä seuraavan kerran käsitellään.
Yleisimmät vastaväitteet kehittäjiltä
"Googlehan osaa ajaa JavaScriptiä." Osaa, mutta jonossa ja rajallisilla resursseilla. Kysymys ei ole pystyykö vaan milloin ja kuinka luotettavasti — ja mitä tekevät ne crawlerit, jotka eivät aja skriptejä lainkaan.
"Palvelinrenderöinti monimutkaistaa arkkitehtuuria." Pitää paikkansa. Siksi rajaus kannattaa tehdä sivutyypeittäin: julkiset sivut palvelimelle, sovellusnäkymät selaimeen. Koko sovellusta ei tarvitse muuttaa.
"Meillä on jo prerender-palvelu boteille." Se on vanhentunut ratkaisu ja hauras: se pitää ylläpitää, se voi hajota huomaamatta ja se tarkoittaa että botit ja käyttäjät saavat eri HTML:n. Uutta ei kannata rakentaa sen varaan.
"Emme ehdi tähän tässä sprintissä." Kevyin versio on siirtää pelkät head-metatiedot ja pääsisällön ensimmäinen näkymä palvelimelle. Se on tyypillisesti muutaman päivän työ ja kattaa suurimman osan riskistä.
Hyödyllisin tapa käydä keskustelu on näyttää, ei väittää: aja curl tärkeimmälle sivulle ja katsokaa yhdessä mitä vastaus sisältää. Tyhjä div lopettaa väittelyn nopeammin kuin mikään argumentti.
Tarkista oma sivustosi kahdessa minuutissa
Avaa tärkein sivusi, näytä lähdekoodi ja etsi pääsisältösi ensimmäinen lause. Jos sitä ei ole siellä, jokainen crawler joka ei renderöi JavaScriptiä katsoo tyhjää sivua — ja tuohon joukkoon kuuluu nyt valtaosa tekoälyjärjestelmistä, joista tuleva liikenteesi riippuu.
Aja ilmainen auditointi WebSEO Auditorilla ja katso, miltä sivusi näyttävät crawlerille ennen kuin yksikään skripti on ajettu.