JavaScript SEO tarkoittaa sitä, että JavaScriptillä rakennettu sisältö on hakukoneiden löydettävissä, luettavissa ja indeksoitavissa oikein. JavaScript-sivustolla käyttäjä ja hakukone näkevät usein eri sivun: käyttäjän selain suorittaa koodin ja näyttää valmiin sisällön, mutta hakukone suorittaa sen erikseen ja viiveellä, ja tekoälybotit eivät useimmiten suorita sitä lainkaan.
Siksi aihe on käytännössä tärkeä yrityksille ja verkkokaupoille, jotka käyttävät JavaScriptiä sivustoillaan ja haluavat parantaa näkyvyyttä sekä hakutuloksissa että AI-vastauksissa. Jos botti ei näe sisältöä, linkkejä tai metatietoja samalla tavalla kuin käyttäjä, sivuja voi jäädä indeksoitumatta, sisällöstä voi puuttua olennaisia osia ja näkyvyys voi kärsiä ilman että ongelma näkyy tavallisessa selainnäkymässä.
Tässä oppaassa käydään läpi JavaScriptin hakukoneoptimoinnin perusteet, Googlen renderöintiprosessi, testaus- ja auditointityökalut, server side renderingin ja client side renderingin vaikutukset, sisäiset linkitykset, metatiedot, yleiset ongelmat sekä konkreettiset korjaukset. Et löydä tästä yleistä JavaScript-opetusta, vaan käytännön näkökulman siihen, miten tarkistat mitä hakukone todella näkee ja miten korjaat erot.
Mitä JavaScript SEO tarkoittaa
JavaScript vaikuttaa hakukoneiden kykyyn indeksoida verkkosivustoja.
JavaScript SEO tarkoittaa sen varmistamista, että JavaScriptillä rakennettu sisältö on hakukoneiden löydettävissä, luettavissa ja indeksoitavissa.
Ongelma ei ole JavaScript itsessään. Ongelma on, että sisältö on olemassa vasta koodin suorittamisen jälkeen, ja suorittaminen on hakukoneelle vaihe, joka voi epäonnistua, viivästyä tai jäädä tekemättä.
HTML kertoo rakenteen, CSS ulkoasun ja JavaScript toiminnallisuuden. Kun sisältö siirtyy HTML:stä JavaScriptin vastuulle, se siirtyy samalla pois siitä osasta, jonka jokainen crawler näkee varmasti.
Miten Google renderöi JavaScriptin
Googlen renderöintiprosessin vaiheet
Google käsittelee JavaScript-sivut kolmessa vaiheessa, ja ne tapahtuvat eri aikaan.
- Crawl. Googlebot hakee URL-osoitteen ja saa palvelimen palauttaman response HTML:n. Tässä vaiheessa JavaScriptiä ei ole suoritettu.
- Render. Sivu asetetaan jonoon, jossa se suoritetaan selainmoottorilla. Jono ei ole välitön. Renderöinti voi tapahtua minuutteja tai päiviä crawlauksen jälkeen.
- Index. Vasta renderöity sisältö päätyy hakemistoon.
Käytännön seuraus: kaikki, mikä on vain rendered HTML:ssä, indeksoituu myöhemmin kuin muu sisältö, ja osa siitä ei koskaan. Kriittinen sisältö pitää siksi tarjota alkuperäisessä HTML:ssä eikä jättää pelkän JavaScriptin tai renderöidyn näkymän varaan. Mitä nopeammin sisältö muuttuu, sitä suurempi ongelma tämä on.
Tätä kutsutaan kaksivaiheiseksi indeksoinniksi, ja se on JavaScript SEO:n tärkein yksittäinen käsite.
Testaa Google Search Consolen URL Inspection -työkalulla
Liitä URL-osoite URL Inspection -työkaluun ja valitse ”Testaa julkaistua sivua”. Avaa sen jälkeen ”Näytä testattu sivu”.
Tarkista seuraavat asiat:
- HTML-välilehti. Tämä on rendered HTML. Löytyykö sisältö?
- Kuvakaappaus. Näyttääkö sivu siltä kuin pitää?
- Sivun resurssit. Estettiinkö jokin tiedosto, jota renderöinti tarvitsi?
Ota kuvakaappaus talteen ja kirjaa löydetyt puuttuvat metatiedot. Ne ovat auditoinnin tärkein yksittäinen todiste.
Vertaa response HTML ja rendered HTML
Tehokkain yksittäinen testi on verrata näitä kahta rinnakkain. Screaming Frog osaa ajaa saman sivuston molemmilla tavoilla ja listata erot.
| Ero | Miksi ongelma |
|---|---|
| H1 vain rendered HTML:ssä | Otsikko puuttuu, kunnes renderöinti valmistuu |
| Title muuttuu JavaScriptillä | Hakutulokseen voi päätyä väärä otsikko |
| Meta description vain rendered HTML:ssä | Kuvaus voi jäädä kokonaan pois |
| Canonical eri response ja rendered HTML:ssä | Google käyttää yleensä response-versiota, ristiriita johtaa väärään pääversioon |
| Noindex vain response HTML:ssä | Sivu jää indeksoimatta, vaikka rendered versio poistaisi merkinnän |
| Sisäiset linkit vain rendered HTML:ssä | Linkkivoima ei kulje, syvät sivut jäävät löytymättä |
Canonical- ja noindex-ristiriidat ovat näistä vaarallisimmat, koska ne vaikuttavat hiljaa eivätkä näy käyttäjälle mitenkään.
Muut työkalut
- Chrome DevToolsin Coverage-työkalu näyttää, kuinka paljon ladatusta JavaScriptistä on käytössä.
- Rich Results Test kertoo, näkyykö strukturoitu data renderöinnin jälkeen.
- Selaimen ”näytä sivun lähdekoodi” näyttää response HTML:n, kun taas Inspect-näkymä näyttää rendered DOM:in. Tämä ero kannattaa opetella, koska se on nopein tapa nähdä ongelma ilman työkaluja.
Näkeekö tekoäly JavaScript-sisältösi
Tekoälybotit ja JavaScript
Tämä on kysymys, jota Suomessa ei juuri esitetä, ja vastaus on useimmiten ei.
Google renderöi JavaScriptin. Suuri osa muista boteista ei. Kielimallien käyttämät crawlerit toimivat pääosin response HTML:n varassa. Jos tuotekuvauksesi, hintasi tai asiantuntijasisältösi ilmestyy vasta selaimessa, se ei ole olemassa tekoälyvastausta kirjoittavalle mallille. Kun sisältö jää renderöinnin taakse, se heikentää myös käyttäjäkokemusta ja voi vaikuttaa orgaaniseen liikenteeseen.
Tämä on merkittävä ero perinteiseen SEO:hon. Sivusto voi sijoittua Google Searchissa hyvin ja jäädä silti kokonaan mainitsematta AI-vastauksissa, koska malli ei ole koskaan nähnyt sen sisältöä.
Testaa yksinkertaisesti: katso sivun lähdekoodia selaimen ”näytä sivun lähdekoodi” -toiminnolla, ei kehittäjätyökalujen Elements-välilehdeltä. Jos tekstisi ei näy siellä, se ei näy myöskään useimmille AI-boteille.
Server side rendering ja hakukonenäkyvyys
Mitä on server side rendering (SSR)?
Server side rendering eli SSR tarkoittaa, että palvelin suorittaa JavaScriptin ja lähettää valmiin HTML:n.
SSR parantaa indeksointia verrattuna client side renderingiin, koska hakukoneet saavat sisällön näkyviin heti ilman erillistä renderöintivaihetta.
Hyödyt:
- Sisältö on olemassa heti ensimmäisessä response-vastauksessa
- Renderöintijono ei viivästytä indeksointia
- Myös ne crawlerit, jotka eivät suorita JavaScriptiä, näkevät sisällön
- Ensimmäinen sisältöelementti latautuu nopeammin, mikä parantaa LCP-arvoa
Server side rendering SSR kannattaa, kun:
- Sisältö muuttuu usein, kuten verkkokaupan hinnat ja saatavuus
- Sivuja on paljon
- Näkyvyys tekoälyhauissa on tavoite
- Sivusto on rakennettu Reactilla, Vuella, Angularilla tai vastaavalla ja sisältö tulee rajapinnasta
Toteutusmallit ja vaihtoehdot
Yleisimmät frameworkit tarjoavat SSR:n valmiina: Next.js Reactille, Nuxt Vuelle, SvelteKit Sveltelle, Angular Universal Angularille.
- Static rendering. Sivut rakennetaan valmiiksi julkaisuhetkellä. Paras vaihtoehto, kun sisältö muuttuu harvoin. Nopein mahdollinen ja helpoin välimuistittaa.
- Prerendering. Boteille tarjotaan valmiiksi renderöity versio. Toimii, mutta lisää ylläpidettävän kerroksen ja voi ajautua eroon oikeasta sivusta.
- Hydration. Palvelin lähettää HTML:n ja selain herättää sen interaktiiviseksi. Tämä on useimpien nykyisten frameworkien oletusmalli.
Käytä CDN:ää ja pitkää välimuistia staattisille resursseille. Se vähentää palvelimen kuormaa ja nopeuttaa sekä käyttäjää että crawleria.
Client side rendering ja single page -sovellukset
Mitä on client side rendering (CSR)?
Client side rendering eli CSR tarkoittaa, että selain rakentaa sivun kokonaan. Suurin riski on, että kriittinen sisältö on olemassa vasta suorituksen jälkeen. JavaScript helpottaa dynaamisen sisällön hallintaa sivustotasolla, mutta CSR kasvattaa indeksointiriskejä.
Single page -sovelluksissa riskit kasautuvat, koska koko sivusto on teknisesti yksi sivu.
Käytä oikeita URL-osoitteita
- Jokaisella näkymällä pitää olla oma URL, joka toimii suoraan avattuna.
- Käytä History APIa, älä risuaitaosoitteita.
- Osoite, joka toimii vain sovelluksen sisällä navigoimalla, ei ole indeksoitavissa.
Anna jokaiselle näkymälle omat metatiedot
- Uniikki title ja meta description jokaiselle single page -näkymälle.
- Jos ne tuotetaan palvelimella, ne ovat varmasti oikein.
- Jos ne asetetaan JavaScriptillä, testaa jokainen näkymä erikseen.
Vältä soft 404 -virheitä
Single page -sovelluksissa poistettu tuote palauttaa usein HTTP-tilakoodin 200 ja näyttää ”ei löytynyt” -tekstin. Hakukoneelle tämä on olemassa oleva sivu, jolla on ohut sisältö.
Korjaus: palauta oikea 404 tai 410, tai ohjaa 301:llä vastaavaan sivuun.
Älä estä JavaScript-resursseja
Jos robots.txt estää kriittisiä JavaScript-tiedostoja, Google ei voi renderöidä sivua. Tarkista, ettei Disallow-riveissä ole kansioita, joissa sovelluksen koodi sijaitsee, kuten /app/, /assets/ tai /static/.
Sisäiset linkit JavaScript-sivustoilla
Linkkien merkitys hakukoneille
Sisäinen linkitys on yleisin hiljainen virhe.
Hakukone seuraa linkkiä, joka on <a href=”/osoite”>. Se ei seuraa elementtiä, joka reagoi klikkaukseen JavaScriptillä ja vaihtaa näkymän ilman URL-osoitetta.
HTML-linkit ovat hakukoneille helpompia kuin JavaScript-linkit sekä crawlaus- että indeksointivaiheessa.
Käytännön säännöt:
- Navigaatio rakennetaan oikeista ankkurielementeistä
- Linkillä on aina href, joka osoittaa todelliseen osoitteeseen
- Suodattimet ja lajittelut eivät saa olla ainoa reitti tuotesivuille
- Sisäiset linkit näkyvät myös response HTML:ssä
- Tärkeät sivut ovat korkeintaan kolmen klikkauksen päässä etusivulta
Meta description ja dynaamiset metatiedot
Metatietojen oikea toteutus
Meta description pitää olla renderöidyssä HTML:ssä viimeistään, mutta mieluiten jo response-vastauksessa.
Syy on yksinkertainen: jos metatiedot muuttuvat vasta renderöinnissä, hakutulokseen voi päätyä väärä tai tyhjä kuvaus siltä ajalta, kun Google on crawlannut mutta ei vielä renderöinyt.
- Generoi title ja meta description palvelinpuolella.
- Testaa lopputulos SERP-esikatselussa.
- Varo erityisesti tilannetta, jossa JavaScript päivittää metatiedot vasta sekunteja latauksen jälkeen.
JS-sivuston tekninen auditointi vaiheittain
1. Tarkista estot
- Robots.txt ja noindex, sekä response että rendered HTML:stä.
2. Aja crawl kahdesti
- Kerran ilman renderöintiä, kerran renderöinnin kanssa.
- Vertaa sivumääriä. Jos rendered crawl löytää selvästi enemmän sivuja, navigaatio on JavaScriptin varassa.
3. Vertaa metatiedot
- Title, meta description, canonical ja robots-merkinnät molemmista versioista.
4. Tarkista Google Search Console
- Sivut-raportin tilaluokat.
- JavaScript-ongelmat näkyvät usein tilana ”Crawled, currently not indexed”.
5. Testaa yksittäiset sivut
- URL Inspection tärkeimmille sivutyypeille: etusivu, kategoriasivu, tuotesivu, artikkeli.
6. Tarkista strukturoitu data
- Jos schema lisätään JavaScriptillä, varmista että se selviää renderöinnistä.
- Strukturoitu data auttaa Googlea ymmärtämään sivun sisällön ja voi tuoda rikastetun hakutuloksen.
Yleiset ongelmat ja niiden ratkaisu
Kriittinen sisältö vain JavaScriptin takana
Ratkaisu:
- Tuota vähintään otsikko, pääteksti ja hinta palvelimella. Loput voi jäädä selaimen vastuulle.
Sisäiset linkit eivät välitä linkkivoimaa
Ratkaisu:
- Korvaa JavaScript-klikkaukset oikeilla <a href> -linkeillä.
- Varmista, että ne näkyvät myös response HTML:ssä.
Metatiedot muuttuvat vasta renderöinnissä
Ratkaisu:
- Siirrä title, meta description ja canonical palvelimen vastaukseen.
- Nämä kolme eivät kestä viivettä.
Renderöinti kestää liian kauan
Ratkaisu:
- Vähennä rajapintakutsujen määrää, jotka estävät sisällön näkymisen.
- Jokainen odotettu kutsu pidentää renderöintiaikaa ja kasvattaa riskiä keskeytyksestä.
- Raskas JavaScript hidastaa myös latausnopeutta ja näkyy Core Web Vitals -mittareissa.
Yhteenveto ja seuraavat askeleet
Kolme tärkeintä toimenpidettä prioriteettijärjestyksessä
- Vertaa response ja rendered HTML. Kaikki muu seuraa tästä.
- Siirrä metatiedot ja kriittinen sisältö palvelimelle. Title, canonical, robots ja pääteksti.
- Korjaa sisäiset linkit oikeiksi ankkureiksi.
Jos tavoitteena on näkyä myös tekoälyvastauksissa, server side rendering ei ole optimointi vaan edellytys.
Seuraa tilannetta jatkuvasti. Uusi frameworkin versio tai yksi kehittäjän muutos voi palauttaa ongelman, joka oli jo korjattu.
Tarvitsetko apua
Tarvitsetko teknistä SEO-asiantuntijaa? Teen JavaScript-sivustojen renderöintianalyysit osana teknistä SEO-auditointia. Kerro sivustosi osoite ja käytetty framework.