Verkkokaupan hakukoneoptimointi - Miten se eroaa tavallisesta SEOsta?

Verkkokaupan hakukoneoptimointi ei ole tavallista SEOa

Kun puhutaan hakukoneoptimoinnista, useimmat ohjeet on kirjoitettu blogeja ja yrityssivustoja varten. Optimoi title-tagit, kirjoita hyvät metakuvaukset, hanki linkkejä. Se toimii sivustoille, joissa on kymmeniä tai jopa satoja sivuja.

Verkkokaupassa samat ohjeet toimivat — mutta vain tiettyyn pisteeseen asti. Loput haasteet tulevat siitä, että verkkokauppa tuottaa sivuja automaattisesti, muuttuvalla tahdilla, tavalla jota tavallinen sivusto ei tee.

Tässä artikkelissa käydään läpi mistä nämä ongelmat syntyvät, miksi ne ovat erilaisia kuin muualla, ja miten niitä lähestytään järjestelmällisesti.

Skaalautumisongelma: sivuja syntyy itsekseen

Tavallisella sivustolla jokainen sivu on tietoinen päätös. Joku suunnitteli sen, loi sen, kirjoitti sisällön ja julkaisi sen.

Verkkokaupassa sivuja syntyy sivuvaikutuksena. Lisäät tuotteen — syntyy tuotesivu. Lisäät kategorian — syntyy kategoriasivuja. Otat käyttöön suodattimet — syntyy kymmeniä, satoja tai tuhansia URL-osoitteita, joista suurin osa on sisällöltään lähes identtisiä keskenään.

Shopify tekee tämän. WooCommerce tekee tämän. Magento tekee tämän. Kaikki suuret verkkokauppa-alustat luovat suodatinpohjaisia URL-osoitteita oletuksena, ilman että se edellyttää mitään suurempia asetusten muokkauksia.

Katsotaan yksinkertainen esimerkki. Kategoriasivulla ”Juoksukengät” on kolme suodatinta:

Koko: 38, 39, 40, 41, 42, 43 → 6 vaihtoehtoa
Väri: musta, valkoinen, sininen, punainen, harmaa, vihreä, oranssi, beige → 8 vaihtoehtoa
Merkki: Nike, Adidas, Puma, Asics → 4 vaihtoehtoa

Pelkät täyskombinaatiot — kaikki kolme valittuna kerralla — tuottavat 6 × 8 × 4 = 192 URL-osoitetta. Mutta todellisuudessa käyttäjä voi valita myös vain yhden tai kahden suodattimen yhdistelmän. Kaikki kombinaatiot laskettuna:

Yhdistelmä	URL-osoitteita
Vain koko	6
Vain väri	8
Vain merkki	4
Koko + väri	6 × 8 = 48
Koko + merkki	6 × 4 = 24
Väri + merkki	8 × 4 = 32
Koko + väri + merkki	6 × 8 × 4 = 192
Yhteensä	314

Tämä on vasta yksi kategoria, kolmella suodattimella. Lisää lajittelu, sivutus, hintarajaus ja saatavuus — URL-avaruus kasvaa tuhansiin nopeasti.

Huom!!
Tämä ei tarkoita, että Google automaattisesti indeksoi ne kaikki. Near-duplicate-sisältö, canonical-signaalit ja heikko laatu estävät usein indeksoinnin. Mutta ne voivat silti kuluttaa crawl-budjetin — eli sen, kuinka monta kohdetta, Google on valmis käymään läpi sivustollasi.

Tämä on ongelma siksi, että hakukoneiden crawlereilla on rajallinen määrä aikaa käytettäväksi sivustollasi. Tätä kutsutaan crawl-budjetiksi. Mitä enemmän se kuluu suodatinsivuihin, sitä vähemmän aikaa jää tuotesivuille ja kategoriasivuille, jotka oikeasti tuottavat myyntiä.

Mitä crawl-budjetti tarkoittaa käytännössä?

Crawl-budjetti ei ole luku, jonka esim. Google kertoo sinulle. Se on käyttäytymismalli, jonka näet epäsuorasti.

Googlen dokumentaation mukaan se muodostuu kahdesta tekijästä:

Crawl rate limit Kuinka usein Googlebot voi crawlata sivustoasi ennen kuin se alkaa kuormittaa palvelintasi liikaa. Google säätää tätä automaattisesti – jos palvelimesi vastaa hitaasti, Google hidastaa crawlausta.

Kuinka paljon hakukone voi kuormittaa palvelintasi
Minkälainen on sivuston suorituskyky (nopeat vs. hitaat sivut)
Jos sivusto on hidas → Google vähentää crawl-määrää

Crawl demand Kuinka paljon Google haluaa crawlata sivustoasi sen perusteella, kuinka suosittu ja arvostettu sivusto on. Arvostettu, paljon linkitettyjä sivusto saa enemmän crawlausbudjettia kuin tuore tai heikosti linkitetty sivusto.

Kuinka kiinnostava sivustosi on hakukoneelle

Vaikuttavia tekijöitä:

Sivuston auktoriteetti (backlinkit)
Sisällön tuoreus
Sivujen päivitystiheys
Sivujen suosio

Jos sinulla on 2 000 tuotetta ja 800 niistä on indeksoitu, lopuilla on jokin este. Se voi olla crawl-budjettiongelma, tekninen este, tai molemmat. Mutta se tarkoittaa, että 1 200 tuotesivuasi ei näy Googlessa — riippumatta siitä, kuinka hyvin ne on kirjoitettu.

Tämä on se, josta verkkokaupan SEO-työ aloitetaan. Ei avainsanat, ei metatekstit — vaan se, kuinka suuri osa sivustosta on oikeasti Googlen tavoitettavissa.

Viisi tavallista tilannetta, jotka aiheuttavat suurimman osan ongelmista

Suodatinsivut ilman hallintaa

Suodatinsivuja ei voi poistaa käytöstä — ne ovat olennainen osa käyttökokemusta. Mutta niitä voidaan ja niitä pitää hallita.

Lähtökohta on erottaa kaksi tapausta toisistaan: suodatinsivut, joilla on hakukysyntää, ja suodatinsivut, joilla ei ole.

”Naisten juoksukengät sininen koko 39” — onko tällä hakua? Tarkista Search Consolesta, analytiikasta sekä mahdollisesta avainsanatyökaluista. Jos on, sivu kannattaa pitää indeksoitavana ja optimoida. Jos ei ole, sivun näkyvyyttä kannattaa kontrolloida.

Sulkemiseen on kaksi tapaa, ja niiden ero on tärkeä:

Noindex
noindex-tagi sivulla kertoo Googlelle: ”käy täällä, mutta älä näytä tätä hakutuloksissa.” Google käy sivulla lukemassa tagin. Crawl-budjettia kyllä kuluu tähän käyntiin, mutta huomattavasti vähemmän. Google käy sivulla jatkossakin tarkistamassa ajoittain, mutta crawl frequency todennäköisesti vähenee eli sivu pyritään crawlaamaan harvemmin.

robots.txt
robots.txt-esto kertoo Googlebotille: ”älä käy täällä lainkaan.” Googlebot lukee sivustolle tultaessa /robots.txt- tiedoston, löytää sieltä Disallow-säännön eikä crawlaa kyseistä estettyä kohdetta jolloin myös crawl-budjetti säästyy. Tätä on siis hyvä hyödyntää, kun haluaa estää kokonaisen URL-parametriluokan — esimerkiksi kaikki ?sort-parametrit.

Käytännössä useimmissa verkkokaupoissa yhdistetään molempia: robots.txt hoitaa selkeästi turhat parametrit, noindex hoitaa tapaukset joissa tilanne on epäselvempi tai muuttuva.

Canonical-logiikka, joka ei toimi johdonmukaisesti

Canonical-tagi kertoo Googlelle, mikä on sivun ”oikea” versio silloin, kun samasta sisällöstä on useita URL-osoitteita. Tyypillinen tilanne verkkokaupassa: sama tuote löytyy useasta kategoriasta eri URL-poluilla.

/tuotteet/kengat/nike-air-max-270/
/tarjoukset/kengat/nike-air-max-270/
/uudet-tuotteet/nike-air-max-270/

Kaikki kolme voivat osoittaa samaan tuotteeseen. Ilman canonical-tageja Google päättää itse, mitä se näyttää — ja päätös ei välttämättä ole se, mitä toivoisit.

Canonical korjaa tämän, mutta vain jos se on asetettu oikein.

Yleisimmät virheet:

Canonical osoittaa estettyyn sivuun. Jos canonical-tagi osoittaa URL-osoitteeseen, joka on estetty robots.txt-tiedostossa, Google ei pysty vahvistamaan sitä. Canonical ohitetaan kokonaan.

Canonicalit muodostavat ketjun. Sivu A → canonical → sivu B → canonical → sivu C. Google alkaa epäillä logiikkaa ja saattaa jättää ketjun huomiotta. Canonical pitää aina osoittaa suoraan lopulliseen URL-osoitteeseen. Tämä on hyvin yleinen tilanne jos sivuston osoitteita on muutettu tai taustalla on sivustomigraatio.

Suodatinsivu osoittaa itseensä. Jos /tuotteet/kengat/nike-air-max-270/?size=42 sisältää self-referencing canonicalin — eli osoittaa omaan URL-osoitteeseensa — Google tulkitsee sen viralliseksi versioksi ja pyrkii nostamaan kyseisen sivun hakutuloksiin. Yleensä canonicalin pitäisi osoittaa pääsivuun /tuotteet/kengat/nike-air-max-270/.

Tarkistaminen on mekaanista työtä: Sivusto käydän läpi crawl-työkalulla(esim. Screaming Frog), canonicalit exportataan raportista ja tarkistetaan, että jokainen osoittaa oikeaan paikkaan eikä estettyyn URL-osoitteeseen tai ketjuun.

Sivustorakenne, joka ei helpota Googlebotin polkua

Sisäinen linkitys — eli se, miten sivustosi sivut linkittyvät toisiinsa — on verkkokaupassa tärkeämpi kuin useimmilla muilla sivustotyypeillä.

Googlebot ei arvaa mitä sivuja sivustollasi on. Se seuraa linkkejä niin ulkoisia, kuin sisäisiäkin. Jos tuotesivulle ei johda sisäisiä linkkejä mistään muualta sivustoltasi, Googlebot ei välttämättä löydä sitä lainkaan — vaikka sivu olisi sitemapissa.

Yleinen virhe:
Tuotesivut linkitetään vain tuotekategorian kautta, mutta kategoriasivulla on paginaatio, joka ei tue hakubotin liikettä. Sivu 1 näkyy suoraan kategoriapääsivulta. Sivu 4 on neljä klikkausta syvemmällä. Googlebotilla on taipumus crawlata syvemmälle vain sivuille, jotka näyttävät tärkeiltä linkkimääränsä perusteella. Sivun 4 tuotteet jäävät usein vähemmälle huomiolle — tai kokonaan löytymättä jos paginaatio on teknisesti heikko.

Ratkaisuja:

Liittyvät tuotteet-osiot tuotesivuilla eivät ole pelkästään käyttökokemus — ne ovat sisäisiä linkkejä, jotka rakentavat crawl-polkuja koko katalogiin.

Jos verkkokaupassa on blogi, joka kerää liikennettä niin myös sieltä kannattaa linkittää tehokkaasti tuotteisiin ja kategoriatasoihin riippuen konteskstista.

Kategoriasivun paginaatio tulee aina testata ja korjata tarvittaessa siten, että se tukee hakubotin liikettä.

Tuotteet loppu varastosta — mitä tehdä sivuille, joita ei enää ole?

Tämä on haaste, johon törmää lähes jokaisessa verkkokaupan auditointitilanteessa, eikä siihen ole yhtä oikeaa vastausta. Mutta väärät vastaukset ovat selkeitä.

Älä poista sivua ilman uudelleenohjausta
Jos tuotesivu on kerännyt linkkejä tai orgaanista liikennettä, sen poistaminen 404-virheellä hävittää saavutetun arvon. Googlebot löytää rikkinäisen linkin, merkitsee sivun virheelliseksi ja crawl-budjetti menee turhaan rikkinäisiin URL-osoitteisiin.

Vaihtoehdot riippuvat tilanteesta
Tuote on tilapäisesti loppu varastosta: Pidä sivu voimassa. Merkitse saatavuus selkeästi sivulla ja schemassa. Google ei rankaise varastosta loppuneista tuotteista — mutta se rankaisee sivuista, jotka antavat hakijalle epäasiallisen vastauksen.

Esim.
Product-schema

Tuote poistetaan pysyvästi
Ohjaa 301-uudelleenohjauksella lähimpään samankaltaisen tuotteen kategoriapääsivulle tai samankaltaiseen tuotteeseen. Älä ohjaa kaikkia poistuneita tuotteita etusivulle — se tulkitaan Google Search Consolessa ”soft 404” -virheenä, eli sivu joka teknisesti toimii mutta ei vastaa hakijan tarpeeseen. Tämä voi myös aiheuttaa sen, että poistunut tuote jää Googlen hakutuloksiin ”kummittelemaan” pidemmäksi aikaa.

Tuotevariantti (väri, koko) poistetaan mutta päätuote jää
Päivitä canonical-tagi osoittamaan päätuotesivulle mikäli se on aiemmin osoittanut itseensä.

Sivuston nopeus mobiilissa — ja miksi se on myyntiongelma, ei tekninen ongelma

LCP (Largest Contentful Paint) mittaa, kuinka nopeasti sivun tärkein sisältöelementti — yleensä tuotekuva tai pääotsikko — latautuu käyttäjän näytölle. Googlen suositeltu raja on alle 2,5 sekuntia 75% sivuista.

Useimmissa verkkokaupoissa mobiili-LCP on 5–10 sekuntia. Se tarkoittaa, että käyttäjä odottaa latautumista 5–10 sekuntia ennen kuin hän näkee mitään relevanttia. Käyttökokemus laskee huomattavasti ja

Tämä ei ole vain sijoituskysymys. Se on konversiokysymys. Sivuston nopeus vaikuttaa suoraan siihen, kuinka suuri osa sivulle saapuvista käyttäjistä jatkaa sivustolla.

Verkkokaupassa suurimmat syyt hitaaseen LCP:hen:

Liian suuret tuotekuvat. Tuotekuvat ovat usein 3–5 MB tiedostoja, jotka ladataan sellaisenaan mobiilille. WebP- tai AVIF-formaatti ja responsiiviset kuvan koot (srcset) leikkaavat tästä huomattavan määrän turhaa painolastia.

Render-blocking JavaScript. Ulkoiset skriptit — chat-widgetit, analytiikkakirjastot, mainostagit — voivat estää sivun renderöinnin kokonaan ennen kuin tärkein sisältö latautuu. defer- ja async-attribuutit, tai skriptien uudelleenjärjestäminen esim. sivun loppuun, korjaavat tämän.

Liian myöhäinen LCP-kuvan lataus. Jos tärkein tuotekuva ladataan esim. CSS:n background-image-ominaisuuden kautta tai vaikka JavaScript-komponentin sisältä(esim. SPA tai Angular), selain ei pysty löytämään sitä HTML:n jäsennyksen yhteydessä. Lataus siis alkaa vasta myöhemmässä vaiheessa.

Jos selain ei näe LCP-elementtiä suoraan HTML:ssä, se alkaa ladata sitä liian myöhään — ja se yksin voi pilata koko suorituskyvyn.

Tämä on suorituskyvyn optimoinnin kannalta merkittävää, koska hyvin yleinen (ja virheellinen) tapa pyrkiä parantamaan tätä on optimoida kuvaa. Tässä tilanteessa prosessi voi näyttää esim. tältä

LCP = 4s
→ optimoidaan kuvaa
→ LCP = 3.8s
(oikea ongelma oli TTFB tai JS)

Mistä aloittaa?

Verkkokaupan SEO-ongelmat ovat harvoin yksittäisiä. Ne ovat rakenteellisia — ne toistuvat jokaisella tuotesivulla tai jokaisessa kategoriassa samalla tavalla. Se tarkoittaa, että yksi korjaus voi vaikuttaa tuhansiin sivuihin.

Se on myös syy, miksi ongelmat kannattaa diagnosoida ennen kuin aloittaa mitään. Väärä prioriteetti tarkoittaa kuukausia työtä, joka ei liikuta oikeaa mittaria.

Auditointi ja käytännön järjestys korjauksille

Indeksointistatus ensin. Search Consolesta selviää heti, onko ongelma olemassa ja kuinka suuri se on. Jos indeksoitujen sivujen ja tuotteiden kokonaismäärän välillä on iso kuilu, siinä lähtöpiste.
Crawl-analyysi. Sivuston läpikäynti crawl-työkalulla esim. Screaming Frogilla tai vastaavalla. Selvitetään mitä Google löytää, mitä se ei löydä, ja miksi. Suodatinsivujen määrä, canonical-virheet ja rikkinäiset linkit näkyvät kaikki tässä vaiheessa.
Priorisoitu korjausjärjestys datan perusteella. Kriittiset ongelmat — ne jotka estävät indeksoinnin — ensin.
Sen jälkeen kasvupotentiaali: kategoriasivujen sisältö, tuotesisällöt, schema-implementointi, CTR-optimointi hakutuloksissa.

Yhteinen tekijä kaikissa näissä

Jokainen edellä esitetty tilaanne/haaste johtuu pääsääntöisesti samasta asiasta:

Verkkokauppa-alustat optimoivat käyttäjäkokemuksen, eivät hakukonenäkyvyyden. Ne tekevät asiat, jotka ovat käteviä asiakkaalle — suodattimet, variantit, sivutus — mutta jättävät SEO-vaikutukset oletusasetuksiksi.

Oletusasetukset harvoin palvelevat hakukonenäkyvyyttä.

Tämä ei tarkoita, että alustat ovat rikki. Se tarkoittaa, että niiden konfigurointi vastaamaan liiketoiminnan tavoitteita ja kasvua, vaatii tietoisia päätöksiä — ja tietoa siitä, mitä päätöksiä kannattaa tehdä missäkin järjestyksessä.

Haluatko tietää, mikä sinun verkkokauppasi tilanne on?

Ota yhteyttä lomakkeella tai suoraan niko@abonomad.fi niin sovitaan aika ja katsotaan mistä kannattaisi lähteä liikkeelle.

Verkkokaupan hakukoneoptimointi – Miten se eroaa tavallisesta SEOsta?