Valinta blog.example.com ja example.com/blog välillä herättää usein vilkasta keskustelua kehittäjien ja SEO-asiantuntijoiden keskuudessa. Totuus on, että Googlen omat edustajat sanovat, että kumpi tahansa lähestymistapa käy – "verkkohaku hyväksyy sekä alidomainit että alihakemistot" – mutta sivustorakenne vaikuttaa silti indeksointiin, analytiikkaan ja siihen, miten käyttäjät ja hakukoneet kokevat sisältösi. Tässä artikkelissa leikkaamme myyttejä tosielämän esimerkkien avulla: monikielisten sivustojen pystyttämisestä SaaS-hallintapaneeleihin, blogeista verkkokaupan kategorioihin ja palvelukohtaisiin mikrosivustoihin. Matkan varrella havaitsemme oivalluksia viimeisimmistä Googlen algoritmipäivityksistä ja jaamme konkreettisia SEO-tilastoja ja kokemuksia.
May 17 2025 • 10 min read • 1967 words
Alidomainit vs Alikansiot: Rento SEO-kaksintaistelu verkkokehittäjille vuonna 2025
Mitä Google Todella Ajattelee (Spoileri: Se on Sinun Päätöksesi)
Googlen ohjeistus on ollut johdonmukaista: laita sisältöä alikansioihin tai aliverkkotunnuksiin sen mukaan, mikä on sinulle järkevää, ei ranking-edun vuoksi. Googlen John Mueller on toistuvasti korostanut, että Google käsittelee näitä rakenteita "suurin piirtein samanarvoisina" rankingin kannalta. Itse asiassa hän sanoi, että hän "henkilökohtaisesti yrittäisi pitää asiat yhdessä niin paljon kuin mahdollista" ja käyttäisi aliverkkotunnuksia vain, kun osiot ovat todella erillisiä. Toisin sanoen, jos sinulla ei ole pakottavaa teknistä tai organisatorista syytä jakaa sivustoa, yksinkertaisempi on yleensä parempi. Tämä toistaa Googlen Matt Cuttsin aiempaa neuvoa: "Ne ovat suurin piirtein samanarvoisia... valitse se, kumpi on helpompi" sisällöllesi ja CMS:lle.
Indeksoinnin ja hakemiston osalta Google voi käsitellä molemmat hyvin. Indeeksoijilla voi vierailla ja indeksoida alikansioita tai aliverkkotunnuksia, mutta huomaa, että saatat tarvita erilliset Google Search Console -omaisuudet kullekin aliverkkotunnukselle (lisää siitä myöhemmin). Lopputulos: älä odota maagista rankingin nousua vain valitsemalla aliverkkotunnuksia. Sen sijaan mieti arkkitehtuuriasi: saman aiheen sivujen ryhmittely yhdelle verkkotunnukselle tekee sisäisestä linkityksestä ja analytiikasta yksinkertaisempaa, kun taas erilliset osiot (sovellukset, kampanjat, tukikeskukset jne.) voivat tarvittaessa olla aliverkkotunnuksilla.
Jopa Googlen kansainväliset SEO-asiakirjat näyttävät molemmat lähestymistavat pätevinä vaihtoehtoina. Esimerkiksi se suosittelee, että jokaiselle kielelle annetaan oma URL-osoite (joko alikansio tai aliverkkotunnus) ja että ne merkitään hreflang-tunnisteilla. Google havainnollistaa tätä selkeästi kuvioilla, kuten de.example.com vs. example.com\/de\/, esittäen kunkin hyödyt ja haitat. Käytännössä tämä tarkoittaa, että voit valita alikansiot tai aliverkkotunnukset kielille ja alueille — varmista vain, että käytät oikeita hreflang-merkintöjä, jotta Google tietää, minkä version näyttää kullekin käyttäjälle.
Monikielisyys & Kohdennus Alueittain
Jos sivustosi tarvitsee useita kieliä tai maakohtaisia versioita, molemmat rakenteet voivat toimia, mutta jokaisella on omat vivahteensa. Esimerkiksi Nikellä on alihakemistoja eri maille: nike.com/au/ (Australia), nike.com/gb/ (Iso-Britannia), nike.com/ca/ (Kanada) jne. Google tulkitsee nämä osaksi pääsivuston rakennetta. Toisaalta Wikipedia käyttää kutakin kieltä aliverkkotunnuksena (esim. en.wikipedia.org, de.wikipedia.org jne.), minkä Google voi myös käsitellä erillisinä sivustoina.
Tärkeää on kertoa Googlelle, mikä on mikä. Käytä hreflang-linkkejä osoittamaan kunkin kieliversion URL-osoitteeseen, olipa kyseessä alihakemisto tai aliverkkotunnus. Googlen omat monialueiset asiakirjat listaavat kunkin asetuksen edut: aliverkkotunnukset (kuten de.example.com) helpottavat alueiden isännöintiä eri palvelimilla tai erillistä kohdennusta, kun taas alihakemistot (example.com/de/) yksinkertaistavat isännöintiä (sama palvelin) ja jakavat verkkotunnusauktoriteetin. Lyhyesti sanottuna päätös riippuu usein teknologiastasi ja organisaatiostasi. Niken kansioiden käyttö osoittaa, kuinka yksi koodipohja voi palvella useita maita helposti, kun taas suuri SaaS- tai teknologiayritys saattaisi suosia aliverkkotunnuksia aidosti itsenäisille alueellisille versioille.
SaaS-tuotteet, sovellukset ja kojelaudat
SaaS-tuotteille (Software-as-a-Service) tai verkkosovelluksille yleinen kaava on markkinointisivusto päädomainissa, sovellus tai kojelauta alidomainissa. Alan asiantuntijat suosittelevat tätä jakoa: pidä etusivusi ja sisältömarkkinointisi example.com-domainissa, ja sijoita kirjautunut sovellus (tai “asiakasportaali”) johonkin app.example.com tai dashboard.example.com tyyppiseen osoitteeseen. Tässä on konkreettisia etuja. Esimerkiksi voit käyttää eri teknologiapinoja tai palvelimia: ehkä pääsivustosi on staattinen sivusto tai CMS, ja sovelluksesi on React-sovellus tai käyttää OAuthia. Eristämällä sovelluksen alidomainiin, voit soveltaa erillistä SSL-sertifikaattia tai domain-pohjaisia evästeitä koskematta pääsivuston konfiguraatioon.
Winderwindin SaaS-arkkitehtuurin opas havainnollistaa asian hyvin: “Markkinointisivuston tulisi olla päädomainissa ja erotettuna tuotesovelluksesta. Tuotesovelluksen tulisi sijaita omassa alidomainissaan”. He jopa mainitsevat oikeita esimerkkejä: Stripe käyttää dashboard.stripe.com, Xero käyttää my.xero.com, GoCardless käyttää manage.gocardless.com ja niin edelleen. Koodipohjien erottamisella on toinenkin etu: voit päivittää markkinointisivustoa (esim. tehdä A/B-testejä tai nopeita muutoksia) vaarantamatta käyttökatkoksia tai regressiota kriittisessä käyttäjäsovelluksessa.
On myös muita palvelutyyppisiä skenaarioita: jos sivustollasi on blogi, joka tarvitsee tietyn CMS:n, tai ohjekeskus kolmannen osapuolen palvelussa. Esimerkiksi Weglot mainitsee, että yritys nimeltä Flodesk käyttää help.flodesk.com tietopankkinsa isäntänä (isännöity ulkoisessa ohjepalvelussa) mieluummin kuin flodesk.com/help. Samoin, jos kehitysresurssisi tai kolmannen osapuolen työkalut eivät integroidu helposti päädomainisi kanssa, alidomain voi sisältää tämän osion ilman kitkaa.
Muista kuitenkin, että alidomaineja on käsiteltävä itsenäisesti joissakin suhteissa. Saatat joutua perustamaan erilliset Search Console -omaisuudet (Googlen webmaster-työkalut) jokaiselle alidomainille, ja analytiikka saattaa vaatia eri domainien välistä seurantaa tietojen yhdistämiseksi. Jos valitset alidomainin sovelluksellesi, varmista, että kaikki on konfiguroitu oikein, jotta liikenne kulkee oikein ja Google tietää, että molemmat osat kuuluvat samaan brändiin.
Blogit ja Sisältöosiot
Blogit, uutisosat ja sisältökeskukset ovat yksi yleisimmistä käyttötapauksista tähän keskusteluun. Tässä SEO:n kompromissit ovat usein keskiössä. Monet sisällön markkinoijat suosivat blogeille alihakemistoja, koska se konsolidoi SEO-arvon yhdelle verkkotunnukselle. Itse asiassa tutkimukset ja tapaustutkimukset viittaavat siihen, että alihakemistoissa oleva sisältö hyödyttää pääverkkotunnuksen sijoituksia. Weglot huomauttaa, että hakukoneet käsittelevät alihakemistoja osana pääverkkotunnustasi, joten "Domain Authority", joka sinulla on, virtaa näille sivuille.
Esimerkiksi, jos example.com on korkea auktoriteetti, niin example.com/blog/hello-world perii tämän voiman. Näin ollen, kaikki blogikirjoituksiisi johtavat paluulinkit kohottavat myös juuritunnuksen auktoriteettia.
Tämä intuitio saa tukea tapaustutkimuksista. Eräs yritys raportoi, että heidän blogin aliverkkotunnus "veti liikennettä", mutta "ei hyödyttänyt pääsivustoamme" – se oli "kuin olisimme pitäneet juhlat, mutta osa vieraistamme piti hauskaa erillisessä huoneessa, kun pääalue ei saanut täyttä hyötyä heidän läsnäolostaan".
Toisin sanoen, heidän pääsivustonsa jäi ilman SEO-boostia. He huomasivat, että blogin siirtäminen example.com/blog -osoitteeseen vastasi paremmin heidän tavoitteitaan (kaikki SEO-rakkaus pysyi pääsivustolla). Yleisesti ottaen, alihakemistot integroituvat saumattomasti: blogi tuntuu osalta sivustoasi, mikä voi olla helpompaa navigoinnin ja käyttäjien linkkien jakamisen kannalta. Toisaalta, jotkut suuret yritykset käyttävät edelleen aliverkkotunnuksia blogeille tai sisältöosioille ilman katastrofia. Esimerkiksi, HubSpot pyörittää kuuluisasti blogiaan blog.hubspot.com -osoitteessa (ja sillä on muita aliverkkotunnuksia, kuten ecosystem.hubspot.com erilaiselle sisällölle). Jos blogisi tai resurssikeskuksesi on hyvin suuri tai tarvitsee erillisen arkkitehtuurin, aliverkkotunnus voi toimia. Googlen kanta ei rankaise sinua siitä valinnasta, mutta sinun tarvitsee rakentaa auktoriteetti erikseen kyseiselle aliverkkotunnukselle.
Verkkokauppasivustoille, joilla on monia kategoria- ja tuotesivuja, yleinen nyrkkisääntö on pitää kaikki pääverkkotunnuksen alla. Kuvittele verkkokauppa, jossa on kategorioita kuten /electronics/phones tai /clothing/shirts; on yleensä parasta laittaa nämä example.com/category/ alle... Miksi? Koska kaikki SEO-pääoma (paluulinkit, sisäiset linkit, ankkuriteksti jne.) pysyy brändin verkkotunnuksessa. Kuten SEMrush huomauttaa, "Google usein näkee aliverkkotunnukset erillisinä kokonaisuuksina, kun taas alihakemistot nähdään osana pääverkkotunnusta". Käytännössä, tämä tarkoittaa, että mikä tahansa linkki example.com/shop/widget vahvistaa kaikkia sivuja example.com:ssa (mukaan lukien muut kategoriat), kun taas linkki shop.example.com:iin vahvistaisi vain kyseisen aliverkkotunnuksen sivustoa.
Useimmat suuret vähittäiskaupan verkkosivustot noudattavat tätä mallia. Esimerkiksi, Amazon, eBay ja Walmart käyttävät alihakemistoja (kuten amazon.com/books/, ebay.com/electronics/phone-accessories/ jne.) erillisen ostosaliverkkotunnuksen sijasta. Kun Googlen ryömijät ja algoritmit arvioivat kategoriasivuja, ne yhdistävät arvon juuritunnuksen mittareihin. Tämä konsolidointi johtaa usein vahvempaan verkkotunnuksen auktoriteettiin ajan myötä. Toisaalta, on olemassa hyväksyttäviä syitä sille, miksi verkkokauppasivusto saattaa käyttää aliverkkotunnusta (esim. integrointi Shopifyyn tai toiseen alustaan). Jos teet niin, ole vain tietoinen siitä, että sitä käsitellään kuin erillistä minisivustoa. Mikään SEO-auktoriteetti, jonka olet rakentanut example.com:iin, ei siirry automaattisesti; sinun täytyy ansaita paluulinkit aliverkkotunnukselle erikseen.
Joskus yritys tarjoaa selvästi erilaisia palveluita tai brändejä yhden sateenvarjon alla, ja se saattaa päättää korostaa näitä eroja aliverkkotunnuksilla. Esimerkiksi, Lego (lelunvalmistaja) pyörittää erikoiskampanjasivustoa osoitteessa ideas.lego.com, jossa käyttäjät voivat lähettää uusia tuoteideoita. Tämä aliverkkotunnus brändää selvästi erillistä aloitetta erillään lego.com:sta. Samoin, jos sivustosi isännöi useita mikrosivustoja markkinointikampanjoille tai yhteisökeskuksille, niiden sijoittaminen aliverkkotunnuksiin voi pitää asiat järjestyksessä. Kuten Weglot toteaa, "jos pyörität digitaalisia markkinointikampanjoita, jotka tarvitsevat erillistä brändäystä ja laskeutumissivuja, voi olla järkevää sijoittaa ne eri aliverkkotunnuksiin". Toinen esimerkki: jos palvelusi ovat hyvin monipuolisia (sano, teet sekä suunnittelua että rakentamista), voit käyttää design.example.com ja build.example.com, jotta kummallakin voi olla oma ilme ja viestintä. Tekninen näkökulma huomioon ottaen, aliverkkotunnus on vain eri isäntä, joten voit osoittaa sen omaan koodipohjaan tai palvelimeen. Mutta muista, tämä tarkoittaa myös, että hakukoneet käsittelevät kutakin pääasiassa erillisinä. Näissä tapauksissa käytä aliverkkotunnuksia vain, jos todella haluat erillisiä markkinointiponnisteluja — muuten saatat jakaa SEO-painoasi.
Päätöstaulukko: Alidomain vs Alikansio
| Harkinta | Alidomain (sub.example.com) |
Alikansio (example.com/sub/) |
|---|---|---|
| SEO-autoriteetti | Erillinen sivusto. Takalinkit hyödyttävät ensisijaisesti alidomainin sijoitusta (ei paranna juuridomainia). Vaatimus rakentaa auktoriteetti jokaiselle alidomainille. | Yhteinen sivusto. Takalinkit alikansioihin parantavat koko domainin auktoriteettia. PageRank virtaa läpi koko sivuston. |
| Infrastruktuuri | Itsenäinen. Voi käyttää eri hostingia, CMS:ää tai tekniikkaa jokaiselle alidomainille. Hyvä mikropalveluille/sovelluksille. | Yhtenäinen. Kaikki sisältö yhdellä palvelimella/pinolla. Yksinkertaisempi käyttöönotto ja ylläpito, mutta vähemmän joustavuutta sekatekniikoille. |
| Asennus & Seuranta | Monimutkaisempi. Tarvitsee DNS:n ja mahdollisesti SSL:n jokaiselle alidomainille, erillinen Search Console & analytiikan seuranta (ristikkäistunnistus). | Yksinkertaisempi. Yksi palvelinvarmenne, yksi Search Console -omaisuus (alikansioilla) ja yksi analytiikkakoodi kattaa kaiken. |
| Käyttötapaukset | Sovellukset, hallintapaneelit tai palvelut, jotka ovat täysin erillisiä tai tarvitsevat omistettuja palvelimia. Monikielinen/alueellinen sisältö (jokainen kieli omalla isännällään). Erityiskampanjat tai kolmannen osapuolen integraatiot (esim. tukipalvelu osoitteessa help.example.com). | Yhdistetty sisältö. Yritysblogi, uutiset tai resurssiosiot, joiden tarkoitus on tukea pääsivuston SEO:ta. Ydinsivuston sisältöä (esim. kauppakategoriat, dokumentit), joiden tulisi hyödyttää päädomainia. |
| Joustavuus | Korkea. Voi siirtää alidomainin uudelle isännälle tai alustalle koskematta pääsivustoa. | Matala. Kaikki sisältö sidottu pääisäntään; osioiden erillinen siirtäminen on vaikeampaa. |
| Domain-autoriteetti | Eristetty. Alidomainilla voi olla oma “Domain Authority” -pisteytys (SEO-työkaluissa) riippumattomana juurista. | Yhtenäinen. Yksi domain-autoriteetti kaikelle; alikansiot jakavat yleensä juuren SEO-signaalit. |
| Esimerkki | app.example.com (asiakasportaali), jp.example.com (maakohtainen sivusto), blog.example.com (jos erillinen CMS). | example.com/app/ (sovellussivut), example.com/jp/ (maan osa), example.com/blog/ (yritysblogi). |
Alidomainin ja alikansion välisessä taistelussa lopullinen päättäjä on yleensä projektisi tarpeet, ei Googlen algoritmit. Kuten Googlen John Mueller muistuttaa, "jos olet kuin 'no en välitä kumpikaan tapa' niin pitäisin sen vain samassa sivustossa". Käytännössä tämä tarkoittaa, että jos kaikki sisältösi – blogi, kategoriat, dokumentit – liittyvät läheisesti toisiinsa, niiden sijoittaminen yhteen domainiin (alikansioilla) maksimoi yleensä SEO-autoriteettisi ja yksinkertaistaa työnkulkua. Toisaalta, jos sinulla on hyvä tekninen tai organisatorinen syy – kuten erillinen SaaS-sovellus, erillinen markkinointikampanja tai tukikeskus toisella alustalla – alidomain on täysin hyväksyttävä ja sitä ei rangaista Googlen silmissä. Ole vain valmis hallitsemaan sitä erillisenä “minisivustona” (omalla seurannalla ja linkkistrategialla). Yhteenvetona: kumpikaan rakenne ei ole itsessään parempi SEO:lle. Googlen algoritmit ovat kehittyneet tunnistamaan ja indeksoimaan molemmat ilman puolueellisuutta. Keskity selkeyteen, käyttäjäkokemukseen ja käytännön ylläpitoon. Useimmille kehittäjille suositeltava lähestymistapa on aloittaa alikansioilla yksinkertaisuuden ja SEO-yhdistämisen vuoksi, ja varata alidomainit selkeille tapauksille, joissa itsenäisyys tai skaalautuvuus on tärkeämpää. Pidä tavoitteesi mielessä, seuraa liikennettäsi ja sijoituksiasi muutosten jälkeen ja iteroi. Huolellisella suunnittelulla voit saada joko vaihtoehdon toimimaan tehokkaasti sivustollesi.
