SEO tekoälyllä rakennetuille sivustoille: mikä oikeasti merkitsee
Tekoälyllä rakennettu sivusto voi sijoittua yhtä hyvin kuin mikä tahansa muu: hakukoneet arvioivat, mitä sivu sisältää ja kuinka hyvin se palvelee kävijää, eivät sitä, mikä työkalu koodin kirjoitti. Koukku on tekninen. Monet tekoälyrakentajat tuottavat yksisivuisia sovelluksia, jotka lähettävät selaimelle lähes tyhjän HTML-tiedoston ja piirtävät sisällön JavaScriptillä, mikä vaikeuttaa jokaisen sivun lukemista indeksoijille ja jakamista. Korjaa tämä esirenderöinnillä tai palvelinpuolen renderöinnillä, anna jokaiselle sivulle oma otsikko, kuvaus ja URL-osoite, lisää sivukartta, pidä sivusto nopeana ja tee sitten se osa, jota mikään työkalu ei tee puolestasi: kirjoita sisältöä, jota ihmiset hakevat.
Miksi yksisivuiset sovellukset voivat kamppailla hauissa
Perinteinen verkkosivusto lähettää kunkin sivun koko tekstin HTML:ssään. Yksisivuinen sovellus (SPA) — monien tekoälyrakentajien oletustulos, tyypillisesti React ja Vite — lähettää pienen HTML-kuoren, jossa on esimerkiksi tyhjä <div id="root">, sekä JavaScript-paketin. Selain ajaa JavaScriptin, joka rakentaa sivun.
Tällä on hakuun kolme vaikutusta:
- Renderöinti on ylimääräinen vaihe. Google kuvaa JavaScript-sivuille kolme vaihetta: se indeksoi HTML:n, renderöi sen headless Chromium -selaimessa ja indeksoi renderöidyn tuloksen. Googlen oma ohjeistus sanoo, että palvelinpuolen renderöinti tai esirenderöinti on silti hyvä idea, koska se on nopeampaa käyttäjille ja indeksoijille, eikä kaikki botit osaa ajaa JavaScriptiä.
- Muut sivusi lukijat eivät renderöi lainkaan. Linkkien esikatselut chat-sovelluksissa ja sosiaalisissa verkostoissa sekä monet muut indeksoijat lukevat yleensä vain alkuperäisen HTML:n. Jos otsikon ja esikatselukuvan asettaa JavaScript latauksen jälkeen, esikatselut näyttävät tyhjän kuoren oletukset — usein saman otsikon jokaisella sivulla.
- Kaikki jakavat yhden HTML-tiedoston. Ellei sovellus päivitä sitä, jokaisella URL-osoitteella on sama
<title>ja kuvaus, mikä kertoo hakukoneille vähän kustakin sivusta.
Nämä eivät tarkoita, ettei SPA:ta voisi indeksoida. Ne tarkoittavat, että luotat indeksoijan tekevän enemmän työtä, ja menetät hallinnan siitä, mitä ei-renderöivät lukijat näkevät.
Valitse renderöintitapa
On neljä yleistä tapaa tuottaa oikea HTML indeksoijille. Järjestyksessä siitä, kuinka paljon ne muuttavat sovellustasi:
| Tapa | Miten se toimii | Sopii | Kompromissi |
|---|---|---|---|
| Staattinen sivusto | Sivut ovat valmiiksi rakennettuja HTML-tiedostoja | Markkinointisivut, portfoliot, dokumentaatio, blogit | Vähemmän sopiva kirjautuneille, personoiduille sivuille |
| Esirenderöinti (staattinen sivugenerointi) | Rakennusvaiheessa jokainen julkinen reitti renderöidään HTML-tiedostoksi; JavaScript ottaa vallan selaimessa | SPA:t, joilla on tunnettu joukko julkisia sivuja | Sivut päivittyvät vain uudelleenrakennuksessa |
| Palvelinpuolen renderöinti (SSR) | Palvelin renderöi HTML:n jokaiselle pyynnölle (Next.js, Remix, Nuxt ja vastaavat) | Suuri tai usein muuttuva julkinen sisältö, esim. ilmoitukset | Vaatii käynnissä olevan palvelimen; enemmän liikkuvia osia |
| Dynaaminen renderöinti | Esirenderöity HTML botteille, SPA ihmisille | Vanha kiertotie | Google kutsuu sitä nykyään kiertotieksi, ei pitkän aikavälin ratkaisuksi, ja suosittelee sen sijaan SSR:ää, staattista renderöintiä tai hydraatiota |
Käytännön sääntö: sivustosi julkisen, haettavan osan pitää olla staattinen tai esirenderöity; sen takana oleva kirjautunut sovellus voi pysyä tavallisena SPA:na. Hakukoneiden ei pidä indeksoida kojelautoja joka tapauksessa.
Jos aloitat tyhjästä ja SEO on tärkeä, kerro se ensimmäisessä kehotteessa, jotta tekoäly valitsee sopivan rakenteen:
Rakenna markkinointisivusto fysioterapiaklinikalle, jossa on sivut Etusivu, Palvelut (yksi sivu per palvelu), Meistä, Hinnoittelu ja Yhteys. SEO on tärkeä: jokaisen sivun täysi sisältö, oma otsikko ja meta-kuvaus pitää toimittaa alkuperäisessä HTML:ssä — käytä staattista tai esirenderöityä rakennetta, älä pelkästään asiakaspuolella renderöityä yksisivuista sovellusta.
Jos sinulla on jo Vite-SPA, pyydä julkisten reittien esirenderöintiä:
Pidä tämä React-sovellus ennallaan, mutta esirenderöi julkiset reitit (/, /pricing, /about, /blog ja jokainen /blog/:slug) staattiseksi HTML:ksi rakennusvaiheessa, kullakin oma otsikko, meta-kuvaus, canonical-URL ja Open Graph -tagit. Kirjautuneet /app-reitit voivat pysyä asiakaspuolella renderöityinä.
Tarkista sen jälkeen itse: avaa sivu, valitse Näytä sivun lähdekoodi (ei kehittäjätyökalujen Elements-paneelia, joka näyttää renderöidyn sivun), ja varmista, että teksti ja otsikko ovat raakassa HTML:ssä.
Hallitse sivun perusasiat
Nämä pätevät riippumatta renderöintitavasta.
Otsikot ja meta-kuvaukset
- Yksi ainutlaatuinen
<title>per sivu, ja sivun pääaihe ensin. Noin 50–60 merkkiä on yleinen ohje, koska pidemmät otsikot katkeavat tuloksissa. - Yksi ainutlaatuinen meta-kuvaus per sivu — lause, jonka ihminen haluaa klikata, ei avainsanalista. Google voi kirjoittaa sen uudelleen, mutta hyvää käytetään usein.
- Jätä meta-avainsanat pois. Google sanoo, ettei tagilla ole vaikutusta indeksointiin tai sijoitukseen.
URL-osoitteet, otsikot ja linkit
- Oikeat URL-osoitteet oikeille sivuille. Jokaisella sisällöllä pitää olla oma polku (
/services/sports-massage), ei välilehteä tai modaalia, joka on olemassa vasta klikkauksen jälkeen. Vältä#-fragmenttireititystä sisällölle, jonka haluat indeksoitavan. - Yksi
h1per sivu, sitten järkeväh2/h3-rakenne. Tekoälyn luomissa malleissa otsikoita käytetään joskus tyylittelyyn; pyydä semanttisia otsikoita. - Indeksoitavat linkit. Käytä navigoinnissa oikeita
<a href>-linkkejä. Painikkeet, jotka vaihtavat sivua JavaScriptillä, ovat näkymättömiä indeksoijille, jotka seuraavat linkkejä. - Canonical-tagit, jotka osoittavat kunkin sivun suosittuun URL-osoitteeseen, jotta
?utm=-muunnelmat ja loppuviivallisten osoitteiden kaksoiskappaleet eivät kilpaile keskenään. - Kuvaava alt-teksti merkityksellisille kuville.
Sosiaalisen median esikatselut
Lisää Open Graph -tagit (og:title, og:description, og:image, og:url) jokaiselle julkiselle sivulle alkuperäiseen HTML:ään. Tämä on osa, jonka SPA:t useimmin tekevät väärin, koska linkkien esikatselubotit eivät aja JavaScriptiä.
Sivukartat ja robots.txt
Sivukartta on XML-tiedosto, joka listaa URL-osoitteet, jotka haluat indeksoitavaksi. Se auttaa hakukoneita löytämään sivut, erityisesti uusilla sivustoilla, joilla on vähän sisäänmeneviä linkkejä. Googlen dokumentaation mukaan syyskuusta 2026 alkaen:
- Yksi sivukartta voi sisältää enintään 50 000 URL-osoitetta tai 50 Mt pakkaamattomana; jaa suuremmat sivustot sivukarttaindeksillä.
- Google ohittaa
<priority>- ja<changefreq>-tagit. - Google käyttää
<lastmod>-tagia vain, jos se on johdonmukaisesti tarkka, joten päivitä se oikeissa sisältömuutoksissa, ei joka rakennuksella.
Tiedosto robots.txt kertoo indeksoijille, mitä polkuja ei saa indeksoida. Käytä sitä pitämään indeksoijat poissa poluilta /app, /admin ja API-reiteiltä, ja osoita siitä sivukarttaan. Muista, että robots.txt estää indeksoinnin, ei indeksointia: jos haluat pitää sivun pois tuloksista, käytä noindex-robots-meta-tagia ja anna sivun tulla indeksoiduksi.
Lähetä sivukartta Google Search Consolessa, kun sivusto on lopullisella verkkotunnuksellaan. Search Console näyttää myös, mitkä sivut on indeksoitu ja miksi toiset eivät ole — paras ilmainen SEO-työkalu, mitä on.
Rakenteinen data
Rakenteinen data on koneluettavaa merkintää, joka kuvaa, mitä sivu on: organisaatio, paikallinen yritys, tuote, artikkeli tai tapahtuma. Google suosittelee JSON-LD-muotoa ja on selvä kahdesta asiasta:
- Se voi tehdä sivusta kelvollisen rikkaisiin tuloksiin, mutta ei takaa niitä.
- Sen on kuvattava tietoa, joka on näkyvissä sivulla. Älä merkitse arvosteluja, hintoja tai UKK:ta, joita kävijät eivät näe.
Järkeviä lähtökohtia: Organization tai LocalBusiness etusivulla, Product tuotesivuilla, Article blogikirjoituksissa ja BreadcrumbList syvemmillä sivuilla. Testaa Googlen Rich Results Test -työkalulla.
Lisää JSON-LD-rakenteinen data: LocalBusiness etusivulle käyttäen sivulla jo näkyviä osoitetta, puhelinnumeroa ja aukioloaikoja, ja Article jokaiseen blogikirjoitukseen. Älä lisää arvioita tai arvosteluja.
Nopeus ja mobiili
Google käyttää sivukokemuksen signaaleja, mukaan lukien Core Web Vitals -mittarit, ja nopeus on tärkeää kävijöille joka tapauksessa. Googlen ”hyvä”-rajat, mitattuna sivulatausten 75. prosenttipisteessä, ovat:
| Mittari | Mittaa | Hyvä |
|---|---|---|
| Largest Contentful Paint (LCP) | Kuinka nopeasti pääsisältö ilmestyy | 2,5 s tai vähemmän |
| Interaction to Next Paint (INP) | Kuinka nopeasti sivu reagoi syötteeseen | 200 ms tai vähemmän |
| Cumulative Layout Shift (CLS) | Kuinka paljon ulkoasu hyppii latautuessa | 0,1 tai vähemmän |
Tekoälyllä rakennettujen sivustojen yleiset korjaukset:
- Kuvat — pienennä, pakkaa, käytä nykyaikaisia formaatteja, aseta leveys ja korkeus (mikä estää ulkoasun hyppimisen) ja lataa taitteen alapuoli laiskasti.
- JavaScript — suuri paketti hidastaa kaikkea SPA:ssa. Esirenderöinti auttaa; auttaa myös koodin jakaminen reittikohtaisesti.
- Fontit — rajoita perheiden ja painojen määrää ja esiladaa taitteen yläpuolella käytetty.
- Kolmannen osapuolen skriptit — jokainen chat-widget ja seurantapikseli maksaa nopeutta. Pidä vain ne, joita käytät.
Testaa live-osoite PageSpeed Insightsilla tai Lighthousella mobiilitilassa.
Sisältö on yhä suurin osa
Tekninen SEO poistaa esteitä; se ei luo kysyntää. Sivut sijoittuvat, koska ne vastaavat hakuun paremmin kuin vaihtoehdot. Useimmille pienille sivustoille tämä tarkoittaa:
- Yksi sivu per aihe, jota ihmiset hakevat. Putkimies tarvitsee sivun per palvelu ja per palvelualue, ei yhtä ”Palvelut”-sivua, joka listaa kaiken.
- Konkreettista, omaperäistä yksityiskohtaa — hintoja, prosessia, kuvia oikeasta työstä, vastauksia kysymyksiin, joita asiakkaat soittavat esittämään.
- Päivitetty, kun asiat muuttuvat. Vanhentuneet aukioloajat ja vanhat hinnat menettävät luottamuksen nopeasti.
Tekoäly voi luonnostella sivuja nopeasti, mikä houkuttelee julkaisemaan paljon ohuita, samankaltaisia sivuja. Googlen ohjeistus kohdistuu sisältöön, joka on tehty pääasiassa sijoittumista varten eikä ihmisten auttamiseksi, riippumatta siitä, miten se tuotettiin. Käytä tekoälyä luonnosteluun ja lisää sitten se, minkä vain sinä tiedät. Hakemistomaiset sivustot kohtaavat tämän eniten; katso kuinka rakennat hakemistosivuston, miten listaussivuista saa indeksoimisen arvoisia.
Julkaisun tarkistuslista
- Julkiset sivut toimittavat täyden sisällön alkuperäisessä HTML:ssä (tarkista ”Näytä sivun lähdekoodi”)
- Ainutlaatuinen otsikko, meta-kuvaus ja canonical-URL jokaisella sivulla
- Open Graph -tagit ja jakokuva jokaisella julkisella sivulla
- Yksi
h1per sivu, oikeat<a href>-linkit, alt-teksti kuvissa -
sitemap.xmloikeilla URL-osoitteilla;robots.txtestää sovellus- ja API-polut - Rakenteinen data vain näkyvälle sisällölle, testattu
- LCP, INP ja CLS ”hyvä”-alueella mobiilissa
- Sivusto lopullisella verkkotunnuksella HTTPS:llä ja lähetetty Search Consoleen
Siirtyminen omaan verkkotunnukseen ennen kuin rakennat hakuliikennettä välttää myöhemmät uudelleenohjaukset — katso kuinka yhdistät oman verkkotunnuksen. Laajempaan rakennusprosessiin lue kuinka rakennat verkkosivuston tekoälyllä, ja kävijöitä konvertoiviin sivuihin kuinka rakennat konvertoivan laskeutumissivun.
SEO Mythexissä
Mythexissä ei ole erillistä SEO-paneelia; parannat SEO:ta muuttamalla sovellusta chatin tai koodin kautta. Uudet verkkosovellukset oletuksena ovat Vite- ja React-yksisivuisia sovelluksia, joten kun haku on tärkeä, pyydä staattista tai esirenderöityä sivustoa tai Next.js:ää alusta asti. Dokumentaatiossa on aloituskehote otsikoille, Open Graph -tageille, sivukartalle ja robots.txt:lle kohdassa SEO sovelluksellesi, ja staattiset sivustot käsittelee sisältökeskeisiä sivustoja. Muutosten jälkeen julkaise uudelleen, jotta live-sivusto ottaa ne käyttöön. Omat verkkotunnukset ovat saatavilla Pro-paketissa.
Kysymykset
Ovatko tekoälyllä rakennetut sivustot huonoja hakukoneoptimoinnille?
Eivät sinänsä. Hakukoneet arvioivat sivua, eivät sitä työkalua, joka sen kirjoitti. Yleinen ongelma on tekninen: monet tekoälyrakentajat tuottavat yksisivuisia sovelluksia, joiden sisältö ilmestyy vasta, kun JavaScript on ajettu, ja osa indeksoijista käsittelee sen huonosti. Esirenderöinti tai palvelinpuolen renderöinti korjaa tämän.
Voiko Google indeksoida React-yksisivuisen sovelluksen?
Google osaa renderöidä JavaScriptiä, joten se voi usein indeksoida asiakaspuolella renderöidyn React-sovelluksen. Renderöinti on kuitenkin ylimääräinen vaihe, ja Google itse huomauttaa, ettei kaikki botit osaa ajaa JavaScriptiä, joten se suosittelee palvelinpuolen renderöintiä tai esirenderöintiä aina kun mahdollista.
Ovatko meta-avainsanat yhä tärkeitä?
Eivät. Google ilmoittaa, ettei se käytä meta-avainsanatagia indeksointiin eikä sijoitukseen. Panosta sen sijaan kunkin sivun ainutlaatuiseen otsikkoon ja meta-kuvaukseen.
Parantaako rakenteinen data sijoituksia?
Rakenteinen data auttaa hakukoneita ymmärtämään sivun ja voi tehdä siitä kelvollisen rikkaisiin tuloksiin, mutta se ei takaa niitä. Sen on kuvattava sisältöä, joka on oikeasti näkyvissä sivulla.