Se for deg en butikk der hvert dashbord ser fint ut. Forsiden er indeksert, Lighthouse er grønt, og valideringen av strukturerte data viser ingen feil. Men samtidig stemmer ikke prisen i Google Shopping med prisen i handlekurven, mobilfilterpanelet fanger tastaturbrukere, og hvert kjøp registreres to ganger.
Ingenting av dette dukker opp i en rask helsesjekk. Det er fordi en nettbutikk er et sammenkoblet system, ikke bare en enkel samling sider. Produktdata flyter inn i siden, de strukturerte dataene og handlefeedene. Skript og tredjepartstagge bestemmer hvor raskt alt lastes. Kassen gjør interesse om til inntekter, og analysen skal registrere hele reisen nøyaktig. Når én del svikter, kan den stille og rolig forvrenge alt annet.
Derfor følger en nyttig e-handelsrevisjon kunden, ikke sitemapet. Sjekklisten nedenfor starter med å oppdage butikken og slutter med en fullført ordre. Den gir deg en rangert liste over reelle problemer, hvert med bevis, en ansvarlig og en tydelig test for når det er rettet.
Når du bør kjøre denne revisjonen, og hvorfor rekkefølgen betyr noe
Kjør hele revisjonen når du tar over en ny e-handelskunde, etter en redesign eller plattformmigrering, før en stor vekstsatsing, eller når en rutinekontroll avdekker en regresjon som rammer hele butikken. Sett av tre til seks timer til en lett gjennomgang, eller én til to dager for en standardrevisjon som tester hver viktig mal ordentlig. Dypdykk i logger, feeder eller analyse trenger vanligvis egen tid.
Rekkefølgen er bevisst. Det er ingen vits i å vurdere friksjon i konverteringen hvis Google ikke kan indeksere kategorisidene, og ingen vits i å stole på traktrapporten hvis kjøpstaggen utløses to ganger.
En duplisert kjøpshendelse er ikke bevis på mer salg, og en rask produktside er ikke sunn hvis prisen Google ser, avviker fra prisen i handlekurven. Derfor beveger revisjonen seg i etapper. Den starter med første oppdagelse, går videre til sannheten om produktene, hastighet og selve kjøpet, og først deretter til måling.
Før du begynner, samle det du trenger. Det betyr tilgang til:
- Search Console,
- Analyse,
- Tag Manager,
- katalog- eller feedkilde,
- Merchant Center,
- en liste over nylige endringer på nettstedet.
Etappe 1: Kan søkemotorer finne katalogen?
1. Bygg et utvalg som representerer hele butikken
De fleste e-handelsfeil bor i delte maler og uvanlige produkttilstander. En ren forside sier ingenting om filtrerte kategorier, variantlogikk, utsolgte varer eller kassen. Derfor bør du starte med å bekrefte at du tester det levende produksjonsnettstedet i riktig marked, valuta og språk. Velg deretter minst én URL for hvert av disse:
- forsiden
- en prioritert kategori
- en dypere kategori eller en godkjent filterside
- et typisk produkt
- et produkt med varianter
- et utsolgt eller utgått produkt
- en side med interne søkeresultater, inkludert en som ikke gir treff
- handlekurven, kassen og ordrebekreftelsessiden
Legg til et vanskelig eller uvanlig eksempel for enhver mal som virker risikabel. Rapporten over landingssider i analysen og en katalogeksport hjelper deg å velge.
Du er ferdig når hver viktig mal og hver kassestatus har en navngitt test-URL, og alt du ikke kunne teste er merket “ikke testet”.
2. Sjekk crawlbarhet, indeksering, kanoniske URL-er og sitemaps
Hvis crawlstien er brutt, vil publisering av flere produkter bare mangedoble antallet berørte URL-er. Motstridende signaler gjør også problemer vanskeligere å diagnostisere. Robots-regler kan si én ting, mens kanoniske tagger og sitemap kan si noe helt annet.
Gå gjennom robots.txt, XML-sitemapene, svarkoder, robots-metatagger og -headere, kanoniske tagger, paginering og interne lenker. Bruk URL Inspection i Search Console for å se hvilken kanonisk URL Google faktisk valgte for utvalgssidene dine. Sammenlign deretter sitemapet med virkeligheten. Det skal liste opp levende, indekserbare sider som returnerer status 200, ikke omdirigeringer, feil, noindex-sider eller duplikater.
Du er ferdig når de tiltenkte landingssidene dine returnerer 200, kan crawles, følger en konsistent policy for kanoniske URL-er og indeksering, og vises i sitemapet. Hver betydningsfull utelatelse bør ha en forklaring eller en ansvarlig.
3. Følg lenkene: omdirigeringer, feil og JavaScript
En butikk kan se komplett ut i en nettleser mens crawlerne og hjelpeteknologi ser en mye tynnere versjon. Kjør en crawler for å finne brutte interne lenker, omdirigeringskjeder, løkker og myke 404-er. Sammenlign deretter den rendrede siden med rå HTML. Produktkort, paginering, brødsmuler og kategorilenker bør være ekte og crawlbar, og viktig innhold bør ikke være avhengig av JavaScript alene.
Du er ferdig når interne lenker peker rett til sitt endelige mål, feilsider returnerer riktig statuskode, og prioriterte produkter kan finnes uten å være avhengig av uendelig rulling.
4. Test kategorier, filtre, paginering og søk på nettstedet
Kategori- og filtersystemer kan samtidig skape crawl-feller for søkemotorer og frustrasjon for kunder. En side kan være teknisk indekserbar og likevel være en svak landingsside hvis halvparten av produktene på den er irrelevante.
Prøv filtrene på desktop og mobil. Sjekk flervalg, “fjern alle”, antall treff, sortering, paginering eller “last inn mer”, og filterkombinasjoner som ikke gir treff. Se på URL-ene filtrene genererer, og sammenlign dem med butikkens indekseringspolicy. Legg også merke til om en lang tekstblokk i kategorien skyver produktnettet under skjermkanten.
Du er ferdig når kontrollene oppfører seg konsistent, tilfeldige filterkombinasjoner ikke blir utilsiktede landingssider, og kunder kan angre et filter uten å miste plassen sin.
Klar til å vokse bedriften din?
Start din gratis prøveperiode i dag og se resultater i løpet av få dager.
Etappe 2: Forteller produktdataene sannheten?
5. Avstem produktidentitet, pris, lager og varianter
Ett feil felt kan ikke bare villede en kunde, men gå helt til å forårsake avvik i kassen. Samtidig kan dataene være perfekt formatert og likevel feil.
For en håndfull representative produkter, sammenlign navn, merke, SKU, GTIN eller EAN, valgt variant, pris, valuta, tilgjengelighet, bilder og nøkkelspesifikasjoner overalt hvor de vises. Sjekk det som vises på siden, i de strukturerte dataene, i merchant-feeden, i handlekurven og i kassen. Ta med salgsvarer, varianter, utsolgte varer, forhåndsbestillinger og utgåtte produkter.
Du er ferdig når de utvalgte fakta stemmer på tvers av alle flater, og enhver tilsiktet forskjell, som merke versus produsent, er eksplisitt i datamodellen.
6. Valider strukturerte data mot det kundene ser
Strukturerte data hjelper bare når de beskriver siden nøyaktig. En validator godtar gjerne “InStock” mens både siden og kassen sier at produktet ikke er tilgjengelig. Derfor bør du kjøre hver produkttilstand gjennom Google Rich Results Test eller Schema.org Validator. Sammenlign deretter de markerte verdiene med det synlige innholdet og kildefeeden. For produkter med varianter, sjekk at tilnærmingen til markup og oppsettet av kanoniske URL-er samsvarer med hvordan sidene faktisk er bygget.
Du er ferdig når utvalgte kvalifiserte sider ikke mangler påkrevde egenskaper, markupen samsvarer med det som er synlig, og anmeldelser og vurderinger bare er markert opp når kundene kan se dem på det produktet.
Etappe 3: Er butikken rask for ekte kunder?
7. Mål Core Web Vitals fra feltdata først
Data fra virkelige brukere og en enkelt Lighthouse-kjøring svarer på forskjellige spørsmål. Lighthouse hjelper deg å reprodusere et problem, men kan ikke si om ekte kunder består eller ikke.
Start med PageSpeed Insights og Core Web Vitals-rapporten i Search Console. Noter om feltdata finnes for den eksakte URL-en eller bare for hele nettstedet. Googles terskler for “god”, målt ved 75-persentilen, er:
- LCP (lasting): 2,5 sekunder eller mindre
- INP (respons): 200 millisekunder eller mindre
- CLS (visuell stabilitet): 0,1 eller mindre
Se på mobil og desktop hver for seg. Hvis det ikke finnes feltdata, registrer resultatet som ukjent og behandle laboratorieresultater som foreløpige. Ukjent er ikke det samme som grønt.
Du er ferdig når hver prioritert mal har en feltdom per enhet, eller en tydelig angitt mangel på data, med kilde og datoperiode registrert.
8. Finn årsaken, ikke bare scoren
Generiske råd som “komprimer bildene” eller “reduser JavaScript” treffer ofte ikke den virkelige flaskehalsen og skaper arbeid som ikke flytter den sviktende målingen. Finn det spesifikke elementet, forespørselen eller skriptet som er ansvarlig.
Identifiser LCP-elementet og hva som forsinker det. Sjekk deretter de vanlige mistenkte, som bildestørrelse, lazy-loading på bilder over skjermkanten, render-blokkerende CSS, fontlasting, tredjepartsskript, lange oppgaver, caching, servertid, kilder til layoutforskyvning og tagger som lastes to ganger.
Kjør gjentatte tester under samme forhold og sammenlign en konsistent statistikk, ikke din beste kjøring. Husk at Total Blocking Time er et nyttig laboratoriesignal, men det er ikke INP.
Du er ferdig når hvert betydningsfulle ytelsesfunn navngir den sviktende målingen, den berørte malen, en reproduserbar årsak og en ansvarlig.
Bli med i vårt nyhetsbrev
Få de siste tipsene, trendene og tilbudene gratis.
Etappe 4: Kan folk faktisk kjøpe noe?
9. Test mobilbrukervennlighet og tilgjengelighet på ekte handlekontroller
Automatiserte scorer dekker ikke hver interaksjon. En butikk kan bestå en skanning mens filterpanelet fanger tastaturfokus, cookie-banneret dekker knappen for å legge i handlekurven, eller størrelsesvelgeren mangler en tilgjengelig etikett.
Test ved telefonbredder på 360 til 390 piksler, zoom teksten, og prøv hele reisen med bare tastatur. Følg med på fokusrekkefølge og synlighet i menyer, paneler og dialoger. Sjekk at etiketter, knapper, skjemafeil og berøringsmål fortsatt gir mening.
Du er ferdig når en kunde kan komme gjennom hovedreisen uten skjulte kontroller eller fokusfeller, og ingenting på mobil skjuler pris, tilgjengelighet, variantvalg, knappen for å legge i handlekurven eller kassen.
10. Kjør handlekurven og kassen som en kontrollert test
En synlig kasseknapp beviser ikke at kassen virker. Feil i kassen er kommersielle hendelser, og de undergraver også analysen din.
For å teste dette, legg et vanlig produkt og en variant i handlekurven. Endre antallet, fjern en vare, og bruk en kupong (eller en bevisst ugyldig en) hvis du har en. Test deretter kasse som gjest og med konto, fraktalternativer, betalingsvalg, valideringsfeil, tilbakeknappen og mobillayouten. Bruk en testordre eller en godkjent vei som ikke belaster noen. Legg aldri inn en ekte ordre uten tillatelse.
Du er ferdig når kjøpet fullføres eller når den avtalte testgrensen, totalene holder seg korrekte, feilmeldinger forteller folk hva de skal gjøre, og enhver blokkert vei er dokumentert med bevis og forretningspåvirkning.
Etappe 5: Måler du reisen riktig?
11. Verifiser analyse, dupliserte tagger og samtykke
Dupliserte tagger blåser opp sidevisninger, hendelser for å legge i handlekurven og kjøp. Manglende eller feilformede verdier gjør inntektsrapporter utrygge å basere beslutninger på. Målet er enkelt: én kundehandling skal gi én hendelse, med riktig produkt, verdi, valuta, transaksjons-ID og samtykkestatus.
List opp hver tag manager-container, Google-tag, annonsepiksel, affiliateskript og serversideintegrasjon. Spor deretter, i en kontrollert økt, view_item, add_to_cart, begin_checkout og purchase. Sammenlign det nettleseren sender med GA4 DebugView og ordreregistreringen i backend. Test før og etter at kunden tar et samtykkevalg.
Du er ferdig når hver handling utløser hendelsen sin nøyaktig én gang, kjøp har en stabil transaksjons-ID, verdier og valuta stemmer med backend, og ikke-essensielle tagger respekterer samtykkepolicyen.
12. Avstem Search Console og Merchant Center mot det du fant
En lokal sidetest kan ikke vise deg hver indeksert kanoniske URL, sitemap-advarsel, avviste produkt eller tapte søk. Et varsel i dashbordet kan derimot beskrive et problem som allerede er løst.
Inspiser de prioriterte URL-ene dine i Search Console, gå gjennom rapportene for produkter og merchant-oppføringer, og sjekk Merchant Center-diagnostikk mot det du så på det levende nettstedet. Noter datoene, fordi recrawling og feedbehandling ligger etter utrullinger.
Du er ferdig når hvert betydningsfulle dashbordproblem samsvarer med levende bevis eller er merket som venter på forplantning, og hvert åpne problem har en ansvarlig.
Etappe 6: Ville en kunde stolt på denne butikken?
13. Sjekk tillitssignaler, kontaktinformasjon, frakt og returer
Skjult eller motstridende kommersiell informasjon får kunder til å nøle og øker antallet supporthenvendelser. Sammenlign header og footer, kontaktsiden, kassen og policysidene.
Du er ferdig når virksomhetens identitet er tydelig, påstander om frakt, returer og betaling stemmer gjennom hele reisen, og ingen tillitsmerke er ubekreftelig.
14. Sjekk HTTPS, blandet innhold og frontend-hygiene
Dette er ikke en penetrasjonstest, men et spørsmål om grunnleggende datahygiene. Bekreft at HTTP omdirigeres til HTTPS i ett hopp, at sertifikatet er gyldig, at det ikke finnes blandet innhold, og at skjemaer sendes inn riktig. Sjekk konsollen for alvorlige feil. Hvis noe ser ut som en reell sikkerhetssårbarhet, send det videre til en spesialist i stedet for å diagnostisere det ut fra en generisk advarsel.
Du er ferdig når prioriterte sider og kassen lastes sikkert, omdirigeringer tar ett hopp, og skjemaer oppfører seg som forventet.
Fra funn til rettinger
15. Gjør funn om til en eid utbedringskø
En revisjon som ender i skjermbilder eller en score, reduserer ikke risikoen. Femti symptomer forårsaket av én ødelagt mal bør ikke bli femti urelaterte saker. Grupper funnene etter årsak. Noter om det er komponenten, malen, feedregelen eller sporingsoppsettet. Behold de berørte URL-ene som bevis. Prioriter deretter:
- P0: en aktiv svikt som blokkerer virksomheten, eller et kritisk problem på tvers av hele nettstedet
- P1: en betydelig feil du er trygg på
- P2: et viktig problem med begrenset omfang
- P3: en forbedring å overvåke
Du er ferdig når hvert betydningsfulle funn har én ansvarlig, en frist, en test for “rettet” og en dato for å sjekke det igjen etter utrulling.
Leveransen
Overlever et versjonert dokument eller regneark med én rad per funn og et kort sammendrag øverst. Hver rad bør dekke:
- Atferden,
- forventet atferd,
- de berørte URL-ene,
- bevisene og når du samlet dem inn,
- alvorlighetsgrad og sikkerhet,
- den sannsynlige årsaken,
- anbefalt retting,
- den ansvarlige og testen som beviser at det er gjort.
Men husk at du ikke skal merke et problem som rettet fordi noen lukket saken. Merk det som verifisert når testen passerer i produksjon.
Verktøy for jobben
Du trenger ingen abonnementer for å gjennomføre en solid første runde. Alt du trenger er disse gratisverktøyene:
- Google PageSpeed Insights for feltdata (der det finnes) og Lighthouse-diagnostikk
- Google Search Console for indeksering, sitemaps, URL Inspection, Core Web Vitals og rapporter om strukturerte data
- Google Rich Results Test og Schema.org Validator for strukturerte data
- Chrome DevTools og Lighthouse for nettverk, ytelse, layoutforskyvninger, tilgjengelighet og konsollsjekker
- Google Tag Assistant og GA4 DebugView for hendelsessporing
- SSL Labs Server Test for TLS-konfigurasjon
Hvis du vil ha en snarvei, lar AmICited deg samle alle disse bevisene og beholde utgangspunktet for senere. Visningen Performance Impact sammenligner maler etter LCP, INP, CLS og servertid. URL Inspection og Sitemaps and Indexing sporer indeksering for prioriterte URL-er. Products og Assortment viser hvilke deler av katalogen som har størst kommersiell vekt. Kommentarer i Reports Hub knytter hver utrulling til det som skjedde etterpå. Verktøyene leverer bevisene. Butikkeieren, utvikleren eller analytikeren bestemmer fortsatt hva som er riktig og hvilke avveininger som er akseptable.
Etter revisjonen
Send hvert bekreftede problem til spesialistprosessen som kan lukke det: crawl- og renderingsproblemer til en teknisk SEO-revisjon , svikt i felt-ytelse til utbedring av Core Web Vitals , problemer med fasetter og lagerstatus til en gjennomgang av kategorier og produkter , og sporingsproblemer til den som eier analysen.
Det er ikke nødvendig å kjøre hele revisjonen på nytt etter hver retting. Test det berørte området på nytt, kommenter utrullingen slik at du ser hva som endret seg etterpå, og la den vanlige helsesjekken fange neste regresjon.
Tilbake til butikken der alt så fint ut
Husker du butikken fra begynnelsen? Forsiden var indeksert, Lighthouse var grønt og validatoren var ren. Likevel viste Google Shopping feil pris, filterpanelet fanget tastaturbrukere, og hvert salg ble talt to ganger.
Ingen dashbord flagget noe av det. Denne sjekklisten ville fanget alle tre: prisavviket i trinn 5, fokusfellen i trinn 9 og det dobbelttalte kjøpet i trinn 11. Hver av dem bryter sammen et sted langs kundens vei, og det er nettopp der revisjonen ser.
Det er dette du får av å følge kunden i stedet for sitemapet. Du slutter å spørre “ser nettstedet sunt ut?” og begynner å stille fire vanskeligere spørsmål. Kan folk finne produktet? Er det butikken sier om det sant? Kan de faktisk kjøpe det? Og kan du se at de gjorde det? En butikk som kan svare ja på alle fire, er i bedre form enn en med perfekt score.
Så velg utvalgs-URL-ene dine, sett av tiden og start med etappe 1. Den første runden er den tregeste. Etter det går jobben stort sett ut på å sikre at det du rettet, forblir rettet.
