Kuvittele kauppa, jossa jokainen kojelauta näyttää hyvältä. Etusivu on indeksoitu, Lighthouse on vihreä eikä jäsennellyn datan validaattori näytä virheitä. Mutta samaan aikaan Google Shoppingissa näkyvä hinta ei vastaa ostoskorin hintaa, mobiilin suodatinpaneeli vangitsee näppäimistökäyttäjät ja jokainen osto kirjataan kahteen kertaan.
Mikään tästä ei näy nopeassa terveystarkistuksessa. Syy on siinä, että verkkokauppa on yhteen kytketty järjestelmä, ei pelkkä kokoelma sivuja. Tuotedata virtaa sivulle, jäsenneltyyn dataan ja ostosyötteisiin. Skriptit ja kolmannen osapuolen tagit määräävät, kuinka nopeasti kaikki latautuu. Kassa muuttaa kiinnostuksen liikevaihdoksi, ja analytiikan pitäisi tallentaa koko matka tarkasti. Kun yksi osa hajoaa, se voi huomaamatta vääristää kaikkea muuta.
Siksi hyödyllinen verkkokaupan auditointi seuraa ostajaa, ei sivukarttaa. Alla oleva tarkistuslista alkaa kaupan löytämisestä ja päättyy tehtyyn tilaukseen. Se antaa sinulle järjestetyn listan todellisista ongelmista, joista jokaisessa on todisteet, vastuuhenkilö ja selkeä testi sille, milloin se on korjattu.
Milloin tämä auditointi tehdään ja miksi järjestyksellä on väliä
Tee koko auditointi, kun otat uuden verkkokauppa-asiakkaan, uudistuksen tai alustamuuton jälkeen, ennen suurta kasvupanostusta tai kun rutiinitarkistus paljastaa koko kauppaa koskevan heikkenemisen. Varaa kevyeen kierrokseen kolmesta kuuteen tuntia tai yhdestä kahteen päivää vakioauditointiin, joka testaa jokaisen tärkeän mallin kunnolla. Syvälliset selvitykset lokeista, syötteistä tai analytiikasta vaativat yleensä erillisen ajan.
Järjestys on harkittu. Ei ole järkeä arvioida ostopolun kitkaa, jos Google ei pysty indeksoimaan kategorioiden sivuja, eikä ole järkeä luottaa myyntisuppiloraporttiin, jos ostotagi laukeaa kahdesti.
Kahteen kertaan kirjattu ostotapahtuma ei ole todiste suuremmasta myynnistä, eikä nopea tuotesivu ole terve, jos Googlen näkemä hinta poikkeaa ostoskorin hinnasta. Siksi auditointi etenee vaiheittain. Se alkaa löydettävyydestä, siirtyy sitten tuotetietojen totuudenmukaisuuteen, nopeuteen ja itse ostoon ja vasta sen jälkeen mittaukseen.
Kerää ennen aloittamista tarvitsemasi asiat. Tarvitset pääsyn:
- Search Consoleen,
- analytiikkaan,
- tag manageriin,
- valikoiman tai syötteen lähdetietoihin,
- Merchant Centeriin,
- luetteloon sivuston viimeaikaisista muutoksista.
Vaihe 1: Löytävätkö hakukoneet valikoiman?
1. Rakenna otos, joka edustaa koko kauppaa
Suurin osa verkkokaupan virheistä piilee yhteisissä malleissa ja epätavallisissa tuotetiloissa. Puhdas etusivu ei kerro sinulle mitään suodatetuista kategorioista, varianttilogiikasta, varastopuutteista tai kassasta. Siksi sinun kannattaa aloittaa varmistamalla, että testaat tuotantoympäristön live-sivustoa oikealla markkina-alueella, valuutalla ja kielellä. Valitse sen jälkeen vähintään yksi URL-osoite kustakin seuraavasta:
- etusivu
- prioriteettikategoria
- syvempi kategoria tai hyväksytty suodatinsivu
- tyypillinen tuote
- tuote, jossa on variantteja
- loppuunmyyty tai tuotannosta poistettu tuote
- sisäisen haun tulosivu, mukaan lukien sivu, joka ei palauta tuloksia
- ostoskori, kassa ja tilausvahvistussivu
Lisää hankala tai epätavallinen esimerkki jokaisesta mallista, joka vaikuttaa riskialttiilta. Analytiikan laskeutumissivuraportti ja valikoiman vienti auttavat sinua valinnassa.
Olet valmis, kun jokaisella tärkeällä mallilla ja kassatilalla on nimetty testi-URL-osoite ja kaikki testaamatta jäänyt on merkitty “ei testattu”.
2. Tarkista ryömittävyys, indeksointi, kanoniset osoitteet ja sivukartat
Jos ryömintäreitti on rikki, uusien tuotteiden julkaiseminen vain moninkertaistaa ongelmaisten URL-osoitteiden määrän. Ristiriitaiset signaalit tekevät ongelmien diagnosoinnista myös vaikeampaa. Robots-säännöt voivat sanoa yhtä, kun taas kanoniset tagit ja sivukartta voivat sanoa jotain täysin muuta.
Käy läpi robots.txt, XML-sivukartat, vastauskoodit, robots-meta-tagit ja -otsakkeet, kanoniset tagit, sivutus ja sisäiset linkit. Käytä Search Consolen URL Inspection -työkalua nähdäksesi, minkä kanonisen osoitteen Google todella valitsi otoksesi sivuille. Vertaa sen jälkeen sivukarttaa todellisuuteen. Siinä pitäisi luetella elossa olevat, indeksoitavat sivut, jotka palauttavat 200-tilakoodin – ei uudelleenohjauksia, virheitä, noindex-sivuja tai duplikaatteja.
Olet valmis, kun tavoitellut laskeutumissivusi palauttavat 200-tilakoodin, ne voidaan ryömiä, ne noudattavat johdonmukaista kanonista ja indeksointikäytäntöä ja ne näkyvät sivukartassa. Jokaisella merkittävällä poissulkemisella pitäisi olla selitys tai vastuuhenkilö.
3. Seuraa linkkejä: uudelleenohjaukset, virheet ja JavaScript
Kauppa voi näyttää selaimessa valmiilta, kun taas ryömijät ja avustavat teknologiat näkevät paljon ohuemman version. Aja ryömijä löytääksesi rikkinäiset sisäiset linkit, uudelleenohjausketjut, silmukat ja pehmeät 404-virheet. Vertaa sen jälkeen renderöityä sivua raakaan HTML:ään. Tuotekorttien, sivutuksen, murupolkujen ja kategorialinkkien pitäisi olla aitoja ja ryömittäviä, eikä tärkeän sisällön pitäisi olla pelkän JavaScriptin varassa.
Olet valmis, kun sisäiset linkit osoittavat suoraan lopulliseen kohteeseensa, virhesivut palauttavat oikean tilakoodin ja prioriteettituotteet löytyvät ilman tukeutumista loputtomaan vieritykseen.
4. Testaa kategorioita, suodattimia, sivutusta ja sivustohakua
Kategoria- ja suodatinjärjestelmät voivat samaan aikaan luoda ryömintäansoja hakukoneille ja turhautumista ostajille. Sivu voi olla teknisesti indeksoitava ja silti heikko laskeutumissivu, jos puolet sen tuotteista on merkityksettömiä.
Kokeile suodattimia työpöydällä ja mobiilissa. Tarkista monivalinta, “tyhjennä kaikki”, tulosmäärät, lajittelu, sivutus tai “näytä lisää” sekä suodatinyhdistelmät, jotka eivät palauta mitään. Katso suodattimien tuottamia URL-osoitteita ja vertaa niitä kaupan indeksointikäytäntöön. Huomaa myös, työntääkö pitkä kategoriatasoinen tekstikappale tuoteverkoston näkyvän alueen alapuolelle.
Olet valmis, kun säätimet toimivat johdonmukaisesti, satunnaiset suodatinyhdistelmät eivät muutu vahingossa laskeutumissivuiksi ja ostajat voivat peruuttaa suodattimen menettämättä paikkaansa.
Valmis kasvattamaan liiketoimintaasi?
Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.
Vaihe 2: Kertooko tuotedata totuuden?
5. Täsmäytä tuotteen identiteetti, hinta, varasto ja variantit
Yksi väärä kenttä voi paitsi johtaa ostajan harhaan myös aiheuttaa ristiriidan kassalla. Samaan aikaan data voi olla täydellisesti muotoiltua ja silti väärää.
Vertaa muutaman edustavan tuotteen kohdalla nimeä, brändiä, SKU:ta, GTIN- tai EAN-koodia, valittua varianttia, hintaa, valuuttaa, saatavuutta, kuvia ja keskeisiä ominaisuuksia kaikkialla, missä ne esiintyvät. Tarkista, mitä näytetään sivulla, jäsennellyssä datassa, kauppiaan syötteessä, ostoskorissa ja kassalla. Sisällytä mukaan alennustuotteet, variantit, varastopuutteet, ennakkotilaukset ja tuotannosta poistetut tuotteet.
Olet valmis, kun otoksen tiedot täsmäävät jokaisessa kanavassa ja jokainen tarkoituksellinen ero, kuten brändi vastaan valmistaja, on selkeästi ilmaistu datamallissa.
6. Validoi jäsennelty data sitä vasten, mitä ostajat näkevät
Jäsennellystä datasta on hyötyä vain, kun se kuvaa sivua tarkasti. Validaattori hyväksyy mielellään “InStock”-arvon, vaikka sivu ja kassa kertoisivat molemmat, ettei tuote ole saatavilla. Siksi jokainen tuotetila kannattaa ajaa Google Rich Results Testin tai Schema.org Validatorin läpi. Vertaa sen jälkeen merkittyjä arvoja näkyvään sisältöön ja lähdesyötteeseen. Tarkista variantillisten tuotteiden kohdalla, että merkintätapasi ja kanoninen asetuksesi vastaavat sitä, miten sivut on todella rakennettu.
Olet valmis, kun otoksen kelvollisilla sivuilla ei ole puuttuvia pakollisia ominaisuuksia, merkintä vastaa näkyvää sisältöä ja arvostelut ja luokitukset on merkitty vain silloin, kun ostajat näkevät ne kyseisellä tuotteella.
Vaihe 3: Onko kauppa nopea todellisille ostajille?
7. Mittaa Core Web Vitals ensin kenttädatan perusteella
Todellisten käyttäjien data ja yksittäinen Lighthouse-ajo vastaavat eri kysymyksiin. Lighthouse auttaa toistamaan ongelman, mutta se ei kerro, läpäisevätkö todelliset ostajat vai eivät.
Aloita PageSpeed Insightsistä ja Search Consolen Core Web Vitals -raportista. Huomaa, onko kenttädataa juuri kyseiselle URL-osoitteelle vai vain koko sivustolle. Googlen “hyvät” kynnysarvot 75. persentiilissä mitattuna ovat:
- LCP (lataus): 2,5 sekuntia tai vähemmän
- INP (reagoivuus): 200 millisekuntia tai vähemmän
- CLS (visuaalinen vakaus): 0,1 tai vähemmän
Katso mobiilia ja työpöytää erikseen. Jos kenttädataa ei ole, kirjaa tulos tuntemattomaksi ja käsittele laboratoriotuloksia alustavina. Tuntematon ei ole sama kuin vihreä.
Olet valmis, kun jokaisella prioriteettimallilla on kenttädatapohjainen arvio laitekohtaisesti tai selkeästi ilmaistu datan puute, ja lähde sekä aikaväli on kirjattu.
8. Etsi syy, ei vain pistemäärää
Yleiset neuvot, kuten “pakkaa kuvasi” tai “vähennä JavaScriptiä”, ohittavat usein todellisen pullonkaulan ja synnyttävät työtä, joka ei paranna epäonnistuvaa mittaria. Etsi se tietty elementti, pyyntö tai skripti, joka on vastuussa.
Tunnista LCP-elementti ja se, mikä sitä viivästyttää. Tarkista sen jälkeen tavanomaiset epäillyt, kuten kuvien mitoitus, näkyvän alueen kuvien lazy-loading, renderöintiä estävä CSS, fonttien lataus, kolmannen osapuolen skriptit, pitkät tehtävät, välimuisti, palvelimen vasteaika, asettelun siirtymien lähteet ja kahteen kertaan ladatut tagit.
Aja toistuvia testejä samoissa olosuhteissa ja vertaa johdonmukaista tilastoa, älä parasta ajoasi. Muista, että Total Blocking Time on hyödyllinen laboratoriosignaali, mutta se ei ole INP.
Olet valmis, kun jokainen merkittävä suorituskykylöydös nimeää epäonnistuvan mittarin, kyseessä olevan mallin, toistettavan syyn ja vastuuhenkilön.
Liity uutiskirjeellemme
Saa uusimmat vinkit, trendit ja tarjoukset ilmaiseksi.
Vaihe 4: Voivatko ihmiset todella ostaa jotain?
9. Testaa mobiilikäytettävyys ja saavutettavuus todellisilla ostosäätimillä
Automaattiset pistemäärät eivät kata kaikkea vuorovaikutusta. Kauppa voi läpäistä skannauksen, vaikka suodatinpaneeli vangitsisi näppäimistön kohdistuksen, evästebanneri peittäisi ostoskoriin lisää -painikkeen tai kokovalitsimessa ei ole saavutettavaa tunnistetta.
Testaa puhelimen leveyksillä 360–390 pikseliä, suurenna tekstiä ja kokeile koko matka pelkällä näppäimistöllä. Seuraa kohdistuksen järjestystä ja näkyvyyttä valikoissa, paneeleissa ja dialogeissa. Tarkista, että tunnisteet, painikkeet, lomakevirheet ja kosketuskohteet ovat edelleen ymmärrettäviä.
Olet valmis, kun ostaja pystyy kulkemaan pääasiallisen ostopolun läpi ilman piilotettuja säätimiä tai kohdistusansoja, eikä mikään mobiilissa peitä hintaa, saatavuutta, variantin valintaa, ostoskoriin lisää -painiketta tai kassaa.
10. Aja ostoskori ja kassa valvottuna testinä
Näkyvä kassapainike ei todista, että kassa toimii. Kassan virheet ovat kaupallisia ongelmia, ja ne heikentävät myös analytiikkaasi.
Testaa lisäämällä ostoskoriin tavallinen tuote ja variantti. Muuta määrää, poista tuote ja käytä kuponkia (tai tarkoituksella virheellistä sellaista), jos sellainen on. Testaa sen jälkeen vieras- ja tiliostokset, toimitustavat, maksutavan valinta, validointivirheet, takaisin-painike ja mobiiliasettelu. Käytä testitilausta tai hyväksyttyä veloituksetonta reittiä. Älä koskaan tee oikeaa tilausta ilman lupaa.
Olet valmis, kun osto onnistuu tai saavuttaa sovitun testirajan, summat pysyvät oikeina, virheilmoitukset kertovat ihmisille mitä tehdä ja jokainen estynyt reitti on dokumentoitu todisteineen ja liiketoimintavaikutuksineen.
Vaihe 5: Mittaatko ostopolkua oikein?
11. Varmista analytiikka, päällekkäiset tagit ja suostumus
Päällekkäiset tagit paisuttavat sivun katseluita, ostoskoriin lisäämisiä ja ostoja. Puuttuvat tai virheellisesti muotoillut arvot tekevät liikevaihtoraporteista epäluotettavia päätöksenteon pohjaksi. Tavoite on yksinkertainen: yhden ostajan toimenpiteen pitäisi tuottaa yksi tapahtuma, jossa on oikea tuote, arvo, valuutta, tapahtumatunnus ja suostumustila.
Listaa jokainen tag manager -kontti, Google-tagi, mainospikseli, affiliate-skripti ja palvelinpuolen integraatio. Jäljitä sen jälkeen valvotussa istunnossa view_item, add_to_cart, begin_checkout ja purchase. Vertaa sitä, mitä selain lähettää, GA4 DebugViewiin ja taustajärjestelmän tilaustietueeseen. Testaa ennen ostajan suostumusvalintaa ja sen jälkeen.
Olet valmis, kun jokainen toimenpide laukaisee tapahtumansa täsmälleen kerran, ostot sisältävät vakaan tapahtumatunnuksen, arvot ja valuutta täsmäävät taustajärjestelmän kanssa ja ei-välttämättömät tagit noudattavat suostumuskäytäntöä.
12. Täsmäytä Search Console ja Merchant Center löydöksiisi
Paikallinen sivutesti ei näytä sinulle jokaista indeksoitua kanonista osoitetta, sivukarttavaroitusta, hylättyä tuotetta tai menetettyä hakukyselyä. Toisaalta kojelaudan hälytys voi kuvata ongelmaa, joka on jo korjattu.
Tarkista prioriteetti-URL-osoitteesi Search Consolessa, käy läpi tuote- ja kauppiaslistausraportit ja vertaa Merchant Centerin diagnostiikkaa siihen, mitä näit live-sivustolla. Kirjaa päivämäärät, sillä uudelleenryömintä ja syötteen käsittely laahaavat julkaisujen perässä.
Olet valmis, kun jokainen merkittävä kojelaudan ongelma vastaa live-todisteita tai on merkitty odottamaan päivittymistä, ja jokaisella avoimella ongelmalla on vastuuhenkilö.
Vaihe 6: Luottaisiko ostaja tähän kauppaan?
13. Tarkista luottamussignaalit, yhteystiedot, toimitus ja palautukset
Piilotettu tai ristiriitainen kaupallinen tieto saa ostajat epäröimään ja lisää tukipyyntöjä. Vertaa ylätunnistetta ja alatunnistetta, yhteyssivua, kassaa ja käytäntösivuja.
Olet valmis, kun yrityksen identiteetti on selkeä, toimitus-, palautus- ja maksuväittämät ovat yhteneviä koko ostopolulla eikä yksikään luottamusmerkki ole todentamaton.
14. Tarkista HTTPS, sekasisältö ja front-end-hygienia
Tämä ei ole tunkeutumistesti, vaan kyse on perustason datan siisteydestä. Varmista, että HTTP uudelleenohjautuu HTTPS:ään yhdellä hypyllä, sertifikaatti on kelvollinen, sekasisältöä ei ole ja lomakkeet lähetetään oikein. Tarkista konsolista vakavat virheet. Jos jokin vaikuttaa todelliselta tietoturva-aukolta, vie se asiantuntijalle sen sijaan, että diagnosoisit sitä yleisen varoituksen perusteella.
Olet valmis, kun prioriteettisivut ja kassa latautuvat turvallisesti, uudelleenohjaukset vievät yhden hypyn ja lomakkeet toimivat odotetusti.
Löydöksistä korjauksiin
15. Muunna löydökset omistettuun korjausjonoon
Auditointi, joka päättyy kuvakaappauksiin tai pistemäärään, ei vähennä riskiä. Yhdestä rikkinäisestä mallista johtuvasta viidestäkymmenestä oireesta ei pitäisi tulla viittäkymmentä erillistä tikettiä. Ryhmittele löydökset juurisyyn mukaan. Merkitse, onko kyseessä komponentti, malli, syötesääntö vai seuranta-asetus. Pidä ongelmalliset URL-osoitteet todisteina. Priorisoi sen jälkeen:
- P0: aktiivinen vika, joka estää liiketoiminnan, tai kriittinen koko sivuston ongelma
- P1: merkittävä virhe, josta olet varma
- P2: tärkeä ongelma, jonka laajuus on rajattu
- P3: parannus, jota kannattaa seurata
Olet valmis, kun jokaisella merkittävällä löydöksellä on yksi vastuuhenkilö, eräpäivä, testi sille, että se on “korjattu”, sekä päivämäärä, jolloin se tarkistetaan uudelleen julkaisun jälkeen.
Toimitettava aineisto
Luovuta versioitu dokumentti tai laskentataulukko, jossa on yksi rivi löydöstä kohden ja lyhyt yhteenveto alussa. Jokaisen rivin pitäisi kattaa:
- käyttäytyminen,
- odotettu käyttäytyminen,
- ongelmalliset URL-osoitteet,
- todisteet ja niiden keräämisajankohta,
- vakavuus ja varmuus,
- todennäköinen syy,
- suositeltu korjaus,
- vastuuhenkilö ja testi, joka todistaa, että työ on tehty.
Muista kuitenkin, ettei ongelmaa pidä merkitä korjatuksi siksi, että joku sulki tiketin. Merkitse se vahvistetuksi, kun testi menee läpi tuotannossa.
Työkalut työhön
Et tarvitse tilauksia tehdäksesi vahvan ensimmäisen kierroksen onnistuneesti. Tarvitset vain nämä ilmaiset työkalut:
- Google PageSpeed Insights kenttädataan (jos saatavilla) ja Lighthousen diagnostiikkaan
- Google Search Console indeksointiin, sivukarttoihin, URL Inspection -työkaluun, Core Web Vitals -mittareihin ja jäsennellyn datan raportteihin
- Google Rich Results Test ja Schema.org Validator jäsenneltyyn dataan
- Chrome DevTools ja Lighthouse verkkoon, suorituskykyyn, asettelun siirtymiin, saavutettavuuteen ja konsolitarkistuksiin
- Google Tag Assistant ja GA4 DebugView tapahtumaseurantaan
- SSL Labs Server Test TLS-asetuksiin
Jos haluat oikotien, AmICited antaa sinun koota kaikki todisteet yhteen ja säilyttää lähtötason myöhempää käyttöä varten. Performance Impact -näkymä vertaa malleja LCP:n, INP:n, CLS:n ja palvelimen vasteajan perusteella. URL Inspection ja Sitemaps and Indexing seuraavat prioriteetti-URL-osoitteiden indeksointia. Products ja Assortment näyttävät, mitkä valikoiman osat kantavat eniten kaupallista painoarvoa. Reports Hubin merkinnät sitovat jokaisen julkaisun siihen, mitä sen jälkeen tapahtui. Työkalut tuottavat todisteet. Kaupan omistaja, kehittäjä tai analyytikko päättää edelleen, mikä on oikein ja mitkä kompromissit ovat hyväksyttäviä.
Auditoinnin jälkeen
Lähetä jokainen vahvistettu ongelma asiantuntijatyönkulkuun, joka voi sulkea sen: ryömintä- ja renderöintiongelmat tekniseen SEO-auditointiin , kenttäsuorituskyvyn puutteet Core Web Vitals -korjauksiin , fasetti- ja varastotilaongelmat kategoria- ja tuotetarkistukseen ja seurantaongelmat sille, joka omistaa analytiikan.
Koko auditointia ei tarvitse ajaa uudelleen jokaisen korjauksen jälkeen. Testaa uudelleen vain kyseinen alue, merkitse julkaisu niin että näet mitä sen jälkeen muuttui, ja anna säännöllisen terveystarkistuksen napata seuraava heikkeneminen.
Takaisin kauppaan, jossa kaikki näytti hyvältä
Muistatko kaupan alusta? Sen etusivu oli indeksoitu, Lighthouse oli vihreä ja validaattori puhdas. Silti Google Shopping näytti väärän hinnan, suodatinpaneeli vangitsi näppäimistökäyttäjät ja jokainen myynti laskettiin kahteen kertaan.
Mikään kojelauta ei liputtanut mitään tästä. Tämä tarkistuslista olisi napannut kaikki kolme: hintaristiriidan vaiheessa 5, kohdistusansan vaiheessa 9 ja kahteen kertaan lasketun oston vaiheessa 11. Jokainen niistä hajoaa jossain ostajan polun varrella, ja juuri sinne auditointi katsoo.
Tämän saat siitä, kun seuraat ostajaa sivukartan sijaan. Lakkaat kysymästä “näyttääkö sivusto terveeltä?” ja alat kysyä neljää vaikeampaa kysymystä. Löytävätkö ihmiset tuotteen? Pitävätkö kaupan väitteet siitä paikkansa? Voivatko he todella ostaa sen? Ja näetkö sinä, että he ostivat? Kauppa, joka voi vastata kyllä kaikkiin neljään, on paremmassa kunnossa kuin kauppa, jolla on täydellinen pistemäärä.
Valitse siis otoksesi URL-osoitteet, varaa aikaa ja aloita vaiheesta 1. Ensimmäinen kierros on hitain. Sen jälkeen työ on lähinnä sen varmistamista, että korjaamasi asiat pysyvät korjattuina.
