Astro ja SEO: mitä julkaisualusta teknisesti ratkaisee

Hakukoneet ja tekoälybotit arvostavat kahta asiaa ylitse muiden: nopeutta ja sitä, kuinka helppoa sisällön lukeminen on ilman ylimääräistä työtä. Julkaisualustan valinta ei ole pelkkä tekninen mieltymyskysymys: se ratkaisee suoraan, kuinka paljon työtä hakukoneen tai tekoälybotin pitää tehdä päästäkseen käsiksi sisältöösi, ja kuinka vakaana sivu näyttäytyy kävijälle latautumisen aikana. Tässä artikkelissa käydään läpi, mitä Astro tekniikkana oikeasti tekee toisin ja mitä se ei tee puolestasi.

Staattinen HTML oletuksena: mitä se tarkoittaa käytännössä

Kun selain tai botti pyytää sivua monilta moderneilla JavaScript-kehyksillä (esim. tavanomaisilla React- tai Vue-pohjaisilla single-page-sovelluksilla) rakennetuilta sivustoilta, palvelin lähettää usein lähes tyhjän HTML-rungon ja erillisen JavaScript-paketin. Vasta kun selain on ladannut, jäsentänyt ja suorittanut tuon JavaScriptin, varsinainen sisältö piirtyy näkyviin. Tätä kutsutaan client-side-renderöinniksi. Ihmiskäyttäjä ei tätä välttämättä huomaa, koska nykyaikaiset selaimet ovat nopeita, mutta viive on silti mitattavissa, ja se moninkertaistuu hitaammalla laitteella tai yhteydellä.

Astro toimii oletuksena toisin: sivut renderöidään valmiiksi staattisena HTML:nä joko build-hetkellä tai palvelimella, ja selain saa heti täyden, sisällöllä täytetyn HTML-dokumentin, eikä tyhjää runkoa, jota täytetään jälkikäteen. Tämä ei ole pieni yksityiskohta hakukoneiden kannalta: vaikka Googlebot pystyy nykyään renderöimään JavaScriptiä, se tapahtuu erillisessä, resursoidussa renderöintijonossa, joka voi viivästää indeksointia merkittävästi verrattuna suoraan luettavaan HTML:ään. Moni muu botti (mukaan lukien suuri osa tekoälyjärjestelmien käyttämistä hakubottien ja koulutusaineistoa keräävien crawlereiden versioista) ei renderöi JavaScriptiä lainkaan, vaan lukee vain sen, mitä palvelin ensimmäisessä vastauksessa lähettää. Jos sisältösi on vasta JavaScript-suorituksen takana, osa näistä botteista ei näe sitä koskaan.

Islands-arkkitehtuuri: JavaScriptiä vain sinne missä sitä oikeasti tarvitaan

Suurin osa tyypillisen yrityssivuston sisällöstä (tekstit, kuvat, otsikot, navigaatio) ei tarvitse interaktiivisuutta ollakseen olemassa. Interaktiivisuutta tarvitaan vain tietyissä, rajatuissa kohdissa: lomakkeissa, karuselleissa, suodattimissa, kartoissa. Perinteinen JS-kehys ei kuitenkaan tyypillisesti erottele näitä toisistaan: koko sivu “hydratoidaan”, eli JavaScript-koodi ladataan ja suoritetaan sivun jokaista osaa varten, vaikka valtaosa sisällöstä ei koskaan reagoi mihinkään.

Astron islands-arkkitehtuuri kääntää tämän lähtökohdan ympäri: oletuksena mikään komponentti ei lähetä selaimelle JavaScriptiä. Interaktiiviset osat, eli “saaret”, merkitään erikseen eksplisiittisellä hydraatiodirektiivillä, ja vain ne saavat oman, rajatun JS-pakettinsa. Tällä sivustolla tämä näkyy esimerkiksi siinä, että staattiset komponentit kirjoitetaan .astro-tiedostoina src/components/astro/-kansioon eikä niille lähetetä JavaScriptiä lainkaan, kun taas aidosti interaktiiviset osat ovat React-komponentteja src/components/react/-kansiossa, joille valitaan tapauskohtaisesti sopiva hydraatiotapa: client:visible lataa JavaScriptin vasta kun komponentti vierähtää näkyviin, client:idle vasta kun selain on muuten valmis, ja client:load vain kriittisimmille, heti tarvittaville elementeille. Lopputulos: sivun kokonaispaino ja suoritettavan JavaScriptin määrä pysyvät murto-osassa siitä, mitä ne olisivat, jos koko sivu hydratoitaisiin kerralla.

Core Web Vitals -mekaniikka: mitä Astron rakenne tekee LCP:lle, INP:lle ja CLS:lle

Google mittaa sivukokemusta kolmella Core Web Vitals -mittarilla, ja Astron arkkitehtuuri vaikuttaa kuhunkin eri mekanismilla:

LCP (Largest Contentful Paint) mittaa, kuinka nopeasti sivun suurin näkyvä sisältöelementti (tyypillisesti hero-kuva tai -otsikko) piirtyy näkyviin. Koska Astro lähettää valmiin HTML:n heti eikä odota JavaScript-suoritusta ennen sisällön piirtämistä, selaimella on käytettävissään kaikki tarvittava tieto sisällöstä ja sen asettelusta heti ensimmäisen vastauksen mukana, eikä sen tarvitse odottaa erillistä “hydraatiokierrosta” ennen kuin varsinainen sisältö ilmestyy.
INP (Interaction to Next Paint) mittaa, kuinka nopeasti sivu reagoi käyttäjän toimintoon koko istunnon ajalta. Tämä on usein vaikein mittari optimoida JS-raskailla sivustoilla, koska pääsäie voi olla varattuna suurten JS-pakettien jäsentämiseen ja suorittamiseen juuri silloin, kun käyttäjä yrittää klikata jotain. Koska Astro lähettää JavaScriptiä vain yksittäisiin islands-komponentteihin, pääsäikeellä on vähemmän kilpailevaa työtä, ja se on vapaampi reagoimaan käyttäjän toimintoihin nopeasti.
CLS (Cumulative Layout Shift) mittaa sivun visuaalista vakautta latautumisen aikana: sitä, “hyppiikö” sisältö paikaltaan kun elementtejä latautuu myöhässä. Koska sivun HTML-rakenne ja tyylit ovat valmiina heti, elementit eivät ilmesty ja työnnä muuta sisältöä myöhemmin toisin kuin sivuilla, joissa sisältöä lisätään dynaamisesti JavaScriptillä latautumisen jälkeen.

On syytä olla rehellinen: mikään näistä ei ole automaatio, joka takaa hyviä lukemia. Huonosti optimoitu kuva, fonttien väärä lataustapa tai kolmannen osapuolen skripti voi silti rikkoa minkä tahansa kolmesta mittarista Astro-sivustolla. Arkkitehtuuri poistaa yhden rakenteellisen esteryhmän, ei kaikkia mahdollisia.

Kolmannen osapuolen skriptit: miksi niiden sijoittelu ratkaisee siinä missä kehyskin

Analytiikka-, mainonta- ja muut kolmannen osapuolen skriptit ovat tyypillisesti yksi suurimmista yksittäisistä syistä huonoon INP- ja LCP-tulokseen, riippumatta siitä, millä kehyksellä sivu on rakennettu, sillä nämä skriptit varaavat pääsäikeen aikaa, jota sivu itse tarvitsisi. Tällä sivustolla tähän on ratkaisu: Google Analytics -skripti ladataan Partytownin avulla erilliseen web workeriin (astro.config.mjs:n partytown()-integraatio) sen sijaan, että se kilpailisi pääsäikeen kanssa suoraan. Seurannan käynnistyminen odottaa lisäksi kävijän evästesuostumusta Google Consent Mode v2:n mukaisesti (gtag('consent', 'default', { analytics_storage: 'denied' }) asetetaan oletuksena, ja lupa myönnetään vasta kävijän hyväksynnän jälkeen). Tämä on esimerkki siitä, että itse kehys ratkaisee vain osan: loppu on tietoista arkkitehtuurivalintaa siitä, mihin ja miten kolmannen osapuolen koodi sijoitetaan.

Kuvaoptimointi osana rakennusprosessia, ei jälkikäteistä paikkausta

Kuvat ovat tyypillisesti raskain yksittäinen elementti sivulla, ja ne ovat myös yleisin LCP:tä hidastava tekijä. Astron sisäänrakennettu kuvakäsittely (astro:assets) muuntaa ja pakkaa kuvat build-vaiheessa oikeaan kokoon ja nykyaikaisiin formaatteihin, ja generoi tarvittavat srcset- ja sizes-määritykset automaattisesti, jotta selain lataa vain sen kuvakoon, jota se oikeasti tarvitsee kyseisellä näytöllä. Koska tämä tapahtuu osana build-prosessia eikä erillisenä, jälkikäteen asennettavana lisäosana, optimointi ei voi unohtua tai jäädä puolitiehen yksittäisellä sivulla: se on osa jokaista julkaisua oletuksena.

Miten tämä vaikuttaa tekoälybottien tapaan lukea sivustoa

Perinteinen hakukone rakentaa hakemistonsa etukäteen: se käy sivustolla, tallentaa sisällön, ja hakutulokset haetaan tuosta valmiiksi rakennetusta hakemistosta. Moni tekoälyhakujärjestelmä toimii toisin: se hakee sivuja osittain reaaliajassa juuri sillä hetkellä, kun käyttäjän kysymykseen etsitään vastausta, pilkkomalla kysymyksen useiksi rinnakkaisiksi osakyselyiksi ja noutamalla kuhunkin liittyviä sivuja lennossa. Tässä mallissa palvelimen vasteajalla on suora merkitys: jos sivu ei vastaa riittävän nopeasti, botti yksinkertaisesti luovuttaa ja katkaisee yhteyden ennen kuin se on nähnyt sisältöä lainkaan. Palvelinlokeista tämä näkyy usein epävirallisena HTTP 499 -tilakoodina, joka tarkoittaa asiakkaan katkaisemaa yhteyttä liian pitkän vasteajan takia. Käyttäjän kokema nopeus ja botin kokema nopeus eivät myöskään ole sama asia: yhden sivun sovellus voi tuntua nopealta ihmiselle, jolle sisältö piirtyy asteittain näkyviin, mutta botille, joka ei renderöi sivua selaimen tavoin, ratkaisevaa on vain se, kuinka nopeasti palvelin alkaa lähettää dataa (Time To First Byte). Koska Astro tuottaa valmiin HTML:n eikä vaadi erillistä renderöintivaihetta ennen sisällön näkymistä, tämä rakenteellinen riski pienenee: botti saa vastaansa täyden sisällön heti ensimmäisestä pyynnöstä, ei tyhjää runkoa jota täytetään myöhemmin.

Rehellinen vertailu: Astro vs. WordPress + hakukoneoptimointilisäosat

WordPress on edelleen maailman käytetyin julkaisujärjestelmä, eikä sillä rakennettu sivusto ole automaattisesti huono hakukoneille: hyvin toteutettuna ja oikein virityksellä WordPress-sivusto voi pärjätä erinomaisesti. Ero ei ole siinä, että WordPress olisi tekniikkana mahdoton optimoida, vaan siinä, mitä optimointi vaatii: WordPress on lähtökohtaisesti dynaaminen, palvelinpuolella joka pyynnöllä uudelleen renderöitävä järjestelmä, ja hyvän suorituskyvyn saavuttaminen edellyttää tyypillisesti useiden lisäosien (välimuistitus, kuvaoptimointi, koodin minimointi) asentamista, konfigurointia ja ylläpitoa, ja jokainen lisäosa on myös oma ylläpito- ja yhteensopivuusriskinsä versiopäivitysten yhteydessä. Astrossa vastaava lopputulos (staattinen HTML, optimoitu kuvien lataus, minimaalinen JavaScript) on oletusarvoinen käyttäytyminen ilman erillistä lisäosakerrosta. Käytännön ero on siis pikemminkin “pitääkö optimointi rakentaa päälle vai onko se sisäänrakennettu lähtökohta” kuin “kumpi kehys on ylipäätään kykenevä hyvään tulokseen”.

Mitä Astro ei ratkaise: rajat, jotka kannattaa tuntea

Tekninen alusta ei ole taikatemppu, eikä sitä kannata markkinoida sellaisena. Muutama asia, jota Astro ei tee puolestasi:

Se ei kirjoita sisältöä puolestasi. Nopea, teknisesti puhdas sivu, jolla ei ole vastausta hakijan kysymykseen, ei sijoitu paremmin kuin hidas sivu, jolla on. Tekninen perusta on edellytys, ei korvike on-page-hakukoneoptimoinnille: otsikkorakenteelle, kohdeavainsanoille, strukturoidulle datalle ja sisällön syvyydelle.
Se ei takaa nopeutta automaattisesti. Huonosti pakatut kuvat, liian raskaat kolmannen osapuolen skriptit tai huolimattomasti valittu hydraatiodirektiivi (esim. client:load sinne missä client:visible riittäisi) voivat silti tuottaa hitaan sivun Astrolla rakennettuna. Arkkitehtuuri poistaa rakenteellisia esteitä, ei valvo jokaista yksittäistä toteutuspäätöstä.
Se ei korvaa näkyvyyttä tekoälyhaussa. Nopea ja hyvin renderöity sivu on edellytys sille, että tekoälybotti ylipäätään ehtii lukea sisällön ennen aikakatkaisua, mutta se, siteerataanko sisältöäsi tekoälyn vastauksissa, riippuu vähintään yhtä paljon siitä, kuinka hyvin sisältö on jäsennelty ja kuinka kattavasti se vastaa aiheeseen liittyviin kysymyksiin. Ks. tarkemmin Tekoälyoptimointi (GEO) -palvelumme.
Se ei ole ainoa tapa saavuttaa sama lopputulos. Muutkin moderneista lähestymistavoista (esim. muut staattisiin sivuihin tai palvelinpuolen renderöintiin nojaavat kehykset) voivat päätyä teknisesti samankaltaiseen ratkaisuun. Astron etu on siinä, että staattinen HTML ja islands-arkkitehtuuri ovat sen oletuskäyttäytymistä ilman erillistä virittämistä, ei siinä, että sama lopputulos olisi mahdoton saavuttaa muualla.

Yhteenveto

Astron tekninen valinta ratkaisee juuri sen kerroksen, jota moni muu julkaisualusta joutuu rakentamaan erikseen päälle: valmiin, heti luettavan HTML:n, minimaalisen JavaScript-kuorman ja rakenteellisen perustan, joka tukee sekä perinteisiä hakukoneita että reaaliajassa hakevia tekoälybotteja. Se ei korvaa hyvää sisältöä, harkittua otsikkorakennetta eikä muuta on-page-työtä, mutta se poistaa suuren osan siitä teknisestä riskistä, joka muuten pitäisi tunnistaa ja korjata erikseen jokaisella sivustolla. Tämän takia rakennamme jokaisen asiakkaamme kotisivut Astro-pohjaisena: emme siksi, että se olisi ainoa oikea ratkaisu, vaan siksi, että se tekee oikean lopputuloksen oletukseksi eikä poikkeukseksi.