Forestil dig en butik, hvor alle dashboards ser fine ud. Forsiden er indekseret, Lighthouse er grøn, og valideringen af strukturerede data viser ingen fejl. Men samtidig passer prisen i Google Shopping ikke med prisen i kurven, mobilfilterpanelet fanger tastaturbrugere, og hvert køb registreres to gange.
Intet af dette dukker op ved et hurtigt sundhedstjek. Det skyldes, at en netbutik er et sammenhængende system, ikke bare en simpel samling af sider. Produktdata flyder ind i siden, de strukturerede data og shopping-feeds. Scripts og tredjepartstags bestemmer, hvor hurtigt det hele indlæses. Checkout forvandler interesse til omsætning, og analyser skal registrere hele rejsen præcist. Når én del bryder sammen, kan den lydløst forvrænge alt andet.
Derfor følger en brugbar e-handelsaudit kunden, ikke sitemappen. Tjeklisten nedenfor starter med at opdage butikken og slutter med en gennemført ordre. Den giver dig en prioriteret liste over reelle problemer, hver med dokumentation, en ansvarlig og en klar test for, hvornår det er løst.
Hvornår skal du køre denne audit, og hvorfor rækkefølgen betyder noget
Kør den fulde audit, når du overtager en ny e-handelskunde, efter et redesign eller en platformsmigrering, før et stort vækstfremstød, eller når et rutinetjek afslører en regression på tværs af hele butikken. Afsæt tre til seks timer til en let gennemgang, eller en til to dage til en standardaudit, der tester hver vigtig skabelon ordentligt. Dybdegående undersøgelser af logs, feeds eller analyser kræver normalt separat tid.
Rækkefølgen er bevidst. Der er ingen idé at vurdere konverteringsfriktion, hvis Google ikke kan indeksere kategorisiderne, og der er ingen grund til at stole på tragtrapporten, hvis købstagget udløses to gange.
En dubleret købshændelse er ikke bevis for mere salg, og en hurtig produktside er ikke sund, hvis prisen, Google ser, afviger fra prisen i kurven. Derfor bevæger auditten sig i etaper. Den starter med den første opdagelse, går derefter videre til produktsandhed, hastighed og selve købet, og først derefter til måling.
Før du begynder, skal du samle det, du har brug for. Det betyder adgang til:
- Search Console,
- Analytics,
- Tag manager,
- Katalog- eller feedkilde,
- Merchant Center,
- en liste over nylige ændringer på sitet.
Etape 1: Kan søgemaskiner finde kataloget?
1. Byg et udsnit, der repræsenterer hele butikken
De fleste e-handelsfejl lever i delte skabeloner og usædvanlige produktstatusser. En fejlfri forside fortæller dig intet om filtrerede kategorier, variantlogik, udsolgte varer eller checkout. Derfor bør du starte med at bekræfte, at du tester det live produktionssite i det rigtige marked, den rigtige valuta og det rigtige sprog. Vælg derefter mindst én URL for hver af disse:
- forsiden
- en prioriteret kategori
- en dybere kategori eller en godkendt filterside
- et typisk produkt
- et produkt med varianter
- et udsolgt eller udgået produkt
- en intern søgeresultatside, herunder en der ikke giver resultater
- kurven, checkout og ordrebekræftelsessiden
Tilføj et svært eller usædvanligt eksempel for enhver skabelon, der virker risikabel. Din landingssiderapport i analyser og et katalogeksport hjælper dig med at vælge.
Du er færdig, når hver vigtig skabelon og checkout-tilstand har en navngivet test-URL, og alt, du ikke kunne teste, er markeret som “ikke testet”.
2. Tjek crawlbarhed, indeksering, canonical og sitemaps
Hvis crawlstien er brudt, vil udgivelsen af flere produkter blot mangedoble antallet af berørte URL’er. Modstridende signaler gør det også sværere at diagnosticere problemer. Robots-regler kan sige ét, mens canonical-tags og sitemap kan sige noget helt andet.
Gennemgå robots.txt, XML-sitemaps, svarkoder, robots-metatags og -headers, canonical-tags, paginering og interne links. Brug URL Inspection i Search Console til at se, hvilken canonical Google faktisk valgte til dine udsnitssider. Sammenlign derefter sitemappen med virkeligheden. Den bør liste live, indekserbare sider, der returnerer status 200, ikke omdirigeringer, fejl, noindexede sider eller dubletter.
Du er færdig, når dine tilsigtede landingssider returnerer 200, kan crawles, følger en ensartet canonical- og indekseringspolitik og optræder i sitemappen. Enhver betydningsfuld udelukkelse bør have en forklaring eller en ansvarlig.
3. Følg linkene: omdirigeringer, fejl og JavaScript
En butik kan se komplet ud i en browser, mens crawlere og hjælpeteknologi ser en meget tyndere version. Kør en crawler for at finde brudte interne links, omdirigeringskæder, loops og bløde 404’er. Sammenlign derefter den renderede side med den rå HTML. Produktkort, paginering, brødkrummer og kategorilinks bør være rigtige og crawlbare, og vigtigt indhold bør ikke afhænge af JavaScript alene.
Du er færdig, når interne links peger direkte på deres endelige destination, fejlsider returnerer den rigtige statuskode, og prioriterede produkter kan findes uden at være afhængige af uendelig scroll.
4. Test kategorier, filtre, paginering og søgning på sitet
Kategori- og filtersystemer kan skabe crawl-fælder for søgemaskiner og frustration for kunder på samme tid. En side kan være teknisk indekserbar og stadig være en svag landingsside, hvis halvdelen af produkterne på den er irrelevante.
Prøv filtrene på desktop og mobil. Tjek multi-select, “ryd alle”, resultatantal, sortering, paginering eller “indlæs mere”, og filterkombinationer, der ikke giver noget. Se på de URL’er, filtrene genererer, og sammenlign dem med butikkens indekseringspolitik. Læg også mærke til, om en lang blok med kategoritekst skubber produktgitteret under skærmkanten.
Du er færdig, når kontrollerne opfører sig ensartet, tilfældige filterkombinationer ikke bliver til utilsigtede landingssider, og kunder kan fortryde et filter uden at miste deres placering.
Klar til at vokse din virksomhed?
Start din gratis prøveperiode i dag og se resultater inden for få dage.
Etape 2: Fortæller produktdataene sandheden?
5. Afstem produktidentitet, pris, lager og varianter
Ét forkert felt kan ikke bare vildlede en kunde, men føre hele vejen til en uoverensstemmelse ved checkout. Samtidig kan dataene være perfekt formaterede og stadig være forkerte.
For en håndfuld repræsentative produkter skal du sammenligne navn, brand, SKU, GTIN eller EAN, valgt variant, pris, valuta, tilgængelighed, billeder og nøglespecifikationer overalt, hvor de optræder. Tjek, hvad der vises på siden, i de strukturerede data, i merchant-feedet, i kurven og ved checkout. Medtag tilbudsvarer, varianter, udsolgte varer, forudbestillinger og udgåede produkter.
Du er færdig, når de samplede fakta stemmer på tværs af alle flader, og enhver bevidst forskel, f.eks. brand versus producent, er eksplicit i datamodellen.
6. Validér strukturerede data op imod, hvad kunderne ser
Strukturerede data hjælper kun, når de beskriver siden præcist. En validator accepterer gerne “InStock”, mens siden og checkout begge siger, at produktet ikke er tilgængeligt. Derfor bør du køre hver produktstatus gennem Google Rich Results Test eller Schema.org Validator. Sammenlign derefter de opmærkede værdier med det synlige indhold og kilde-feedet. For produkter med varianter skal du tjekke, at din markup-tilgang og dit canonical-setup matcher måden, siderne faktisk er bygget på.
Du er færdig, når samplede kvalificerede sider ikke mangler påkrævede egenskaber, markup’en matcher det synlige, og anmeldelser og bedømmelser kun er opmærket, når kunderne kan se dem på det pågældende produkt.
Etape 3: Er butikken hurtig for rigtige kunder?
7. Mål Core Web Vitals ud fra feltdata først
Data fra rigtige brugere og en enkelt Lighthouse-kørsel besvarer forskellige spørgsmål. Lighthouse hjælper dig med at reproducere et problem, men kan ikke fortælle, om rigtige kunder består eller fejler.
Start med PageSpeed Insights og Core Web Vitals-rapporten i Search Console. Noter, om der findes feltdata for den præcise URL eller kun for hele sitet. Googles “gode” tærskler, målt ved 75-percentilen, er:
- LCP (indlæsning): 2,5 sekunder eller mindre
- INP (responsivitet): 200 millisekunder eller mindre
- CLS (visuel stabilitet): 0,1 eller mindre
Se på mobil og desktop hver for sig. Hvis der ikke er feltdata, skal du registrere resultatet som ukendt og behandle laboratorieresultater som foreløbige. Ukendt er ikke det samme som grøn.
Du er færdig, når hver prioriteret skabelon har en feltdom per enhed, eller en klart angivet mangel på data, med kilde og datointerval registreret.
8. Find årsagen, ikke bare scoren
Generiske råd som “komprimér dine billeder” eller “reducér JavaScript” rammer ofte ikke den reelle flaskehals og skaber arbejde, der ikke flytter den fejlende metrik. Find det specifikke element, den specifikke request eller det specifikke script, der er ansvarligt.
Identificér LCP-elementet og hvad der forsinker det. Tjek derefter de sædvanlige mistænkte, såsom billeddimensionering, lazy-loading på billeder over skærmkanten, render-blokerende CSS, fontindlæsning, tredjepartsscripts, lange opgaver, caching, serverens svartid, kilder til layoutskift og tags, der indlæses to gange.
Kør gentagne tests under de samme betingelser, og sammenlign en ensartet statistik, ikke din bedste kørsel. Husk, at Total Blocking Time er et nyttigt laboratoriesignal, men det er ikke INP.
Du er færdig, når hver væsentlig ydeevnefund navngiver den fejlende metrik, den berørte skabelon, en reproducerbar årsag og en ansvarlig.
Tilmeld dig vores nyhedsbrev
Få de seneste tips, trends og tilbud gratis.
Etape 4: Kan folk faktisk købe noget?
9. Test mobilbrugervenlighed og tilgængelighed på rigtige shoppingkontroller
Automatiske scorer dækker ikke enhver interaktion. En butik kan bestå en scanning, mens filterpanelet fanger tastaturfokus, cookiebanneret dækker tilføj-til-kurv-knappen, eller størrelsesvælgeren mangler et tilgængeligt label.
Test ved telefonbredder på 360 til 390 pixels, zoom teksten, og prøv hele rejsen med kun et tastatur. Hold øje med fokusorden og synlighed i menuer, paneler og dialoger. Tjek, at labels, knapper, formularfejl og touch-mål stadig giver mening.
Du er færdig, når en kunde kan komme gennem hovedrejsen uden skjulte kontroller eller fokusfælder, og intet på mobil skjuler pris, tilgængelighed, variantvalg, tilføj-til-kurv-knappen eller checkout.
10. Kør kurv og checkout som en kontrolleret test
En synlig checkout-knap beviser ikke, at checkout virker. Checkout-fejl er kommercielle hændelser, og de underminerer også dine analyser.
For at teste dette skal du lægge et normalt produkt og en variant i kurven. Ændr antallet, fjern en vare, og anvend en kupon (eller en bevidst ugyldig en), hvis du har en. Test derefter gæste- og kontocheckout, forsendelsesmuligheder, betalingsvalg, valideringsfejl, tilbage-knappen og mobiloplevelsen. Brug en testordre eller en godkendt ikke-opkrævende vej. Afgiv aldrig en rigtig ordre uden tilladelse.
Du er færdig, når købet gennemføres eller når den aftalte testgrænse, totaler forbliver korrekte, fejlmeddelelser fortæller folk, hvad de skal gøre, og enhver blokeret vej er dokumenteret med bevis og forretningsmæssig påvirkning.
Etape 5: Måler du rejsen korrekt?
11. Verificér analyser, dublerede tags og samtykke
Dublerede tags oppuster sidevisninger, tilføj-til-kurv-hændelser og køb. Manglende eller fejlformede værdier gør omsætningsrapporter utrygge at basere beslutninger på. Målet er enkelt: én kundehandling bør give én hændelse, med det rigtige produkt, den rigtige værdi, valuta, transaktions-ID og samtykkestatus.
List hver tag manager-container, Google tag, annoncepixel, affiliate-script og server-side integration op. Spor derefter i en kontrolleret session view_item, add_to_cart, begin_checkout og purchase. Sammenlign, hvad browseren sender, med GA4 DebugView og ordreregistreringen i backenden. Test før og efter, at kunden træffer et samtykkevalg.
Du er færdig, når hver handling udløser sin hændelse præcis én gang, køb bærer et stabilt transaktions-ID, værdier og valuta stemmer med backenden, og ikke-nødvendige tags respekterer samtykkepolitikken.
12. Afstem Search Console og Merchant Center med det, du fandt
En lokal sidetest kan ikke vise dig alle indekserede canonical-tags, sitemap-advarsler, afviste produkter eller mistede søgeforespørgsler. En dashboard-advarsel kan derimod beskrive et problem, der allerede er løst.
Inspicér dine prioriterede URL’er i Search Console, gennemgå rapporterne for produkter og merchant listings, og tjek Merchant Center-diagnostik op imod det, du så på live-sitet. Noter datoerne, fordi genindeksering og feedbehandling halter efter udrulninger.
Du er færdig, når hvert væsentligt dashboard-problem matcher live-bevis eller er markeret som afventende formering, og hvert åbent problem har en ansvarlig.
Etape 6: Ville en kunde stole på denne butik?
13. Tjek tillidssignaler, kontaktoplysninger, forsendelse og returnering
Skjult eller modstridende kommerciel information får kunder til at tøve og driver supportbilletter op. Sammenlign header og footer, kontaktsiden, checkout og politik-sider.
Du er færdig, når virksomhedens identitet er klar, påstande om forsendelse, returnering og betaling stemmer gennem hele rejsen, og ingen tillidsbadge er ubekræftelig.
14. Tjek HTTPS, mixed content og front-end-hygiejne
Dette er ikke en penetrationstest, men et spørgsmål om grundlæggende datahygiejne. Bekræft, at HTTP omdirigerer til HTTPS i ét hop, at certifikatet er gyldigt, at der ikke er mixed content, og at formularer indsendes korrekt. Tjek konsollen for alvorlige fejl. Hvis noget ser ud som en reel sikkerhedssårbarhed, send det videre til en specialist i stedet for at diagnosticere det ud fra en generisk advarsel.
Du er færdig, når prioriterede sider og checkout indlæses sikkert, omdirigeringer tager ét hop, og formularer opfører sig som forventet.
Fra fund til løsninger
15. Omsæt fund til en ejet udbedringskø
En audit, der ender i skærmbilleder eller en score, reducerer ikke risikoen. Halvtreds symptomer forårsaget af én brudt skabelon bør ikke blive til halvtreds uafhængige tickets. Gruppér fund efter deres grundårsag. Noter, om det er komponenten, skabelonen, feed-reglen eller tracking-opsætningen. Behold de berørte URL’er som bevis. Prioritér derefter:
- P0: en aktiv fejl, der blokerer forretningen, eller et kritisk problem på tværs af hele sitet
- P1: en væsentlig defekt, du er sikker på
- P2: et vigtigt problem med begrænset omfang
- P3: en forbedring, der skal overvåges
Du er færdig, når hvert væsentligt fund har én ansvarlig, en deadline, en test for “løst” og en dato for at tjekke det igen efter udrulning.
Leverancen
Aflever et versionsstyret dokument eller regneark med én række per fund og et kort resumé øverst. Hver række bør dække:
- Adfærden,
- den forventede adfærd,
- de berørte URL’er,
- beviset og hvornår du indsamlede det,
- alvor og sikkerhed,
- den sandsynlige årsag,
- den anbefalede løsning,
- den ansvarlige og den test, der beviser, at det er gjort.
Men husk, at du ikke bør markere et problem som løst, fordi nogen lukkede ticketen. Markér det som verificeret, når testen består i produktion.
Værktøjer til opgaven
Du behøver ikke nogen abonnementer for at gennemføre en stærk første gennemgang. Alt, du har brug for, er disse gratis værktøjer:
- Google PageSpeed Insights til feltdata (hvor det findes) og Lighthouse-diagnostik
- Google Search Console til indeksering, sitemaps, URL Inspection, Core Web Vitals og rapporter om strukturerede data
- Google Rich Results Test og Schema.org Validator til strukturerede data
- Chrome DevTools og Lighthouse til netværk, ydeevne, layoutskift, tilgængelighed og konsoltjek
- Google Tag Assistant og GA4 DebugView til hændelsessporing
- SSL Labs Server Test til TLS-konfiguration
Hvis du vil have en genvej, lader AmICited dig samle alle disse beviser og bevare baseline til senere. Visningen Performance Impact sammenligner skabeloner efter LCP, INP, CLS og serverens svartid. URL Inspection og Sitemaps and Indexing sporer indeksering for prioriterede URL’er. Products og Assortment viser, hvilke dele af kataloget der bærer mest kommerciel vægt. Annotations in the Reports Hub knytter hver udrulning til, hvad der skete bagefter. Værktøjerne leverer beviset. Butiksejeren, udvikleren eller analytikeren beslutter stadig, hvad der er korrekt, og hvilke afvejninger der er acceptable.
Efter auditten
Send hvert bekræftet problem videre til den specialistworkflow, der kan lukke det: crawl- og renderingsproblemer til en teknisk SEO-audit , fejl i felt-ydeevne til udbedring af Core Web Vitals , facet- og lagerstatusproblemer til en kategori- og produktgennemgang , og tracking-problemer til den, der ejer analyserne.
Der er ingen grund til at køre hele auditten igen efter hver løsning. Test det berørte område igen, annotér udrulningen, så du kan se, hvad der ændrede sig bagefter, og lad det regelmæssige sundhedstjek fange den næste regression.
Tilbage til butikken, hvor alt så fint ud
Kan du huske butikken fra starten? Dens forside var indekseret, Lighthouse var grøn, og validatoren var ren. Alligevel viste Google Shopping den forkerte pris, filterpanelet fangede tastaturbrugere, og hvert salg blev talt to gange.
Ingen dashboard markerede noget af det. Denne tjekliste ville have fanget alle tre: prismisforholdet i trin 5, fokusfælden i trin 9 og det dobbelttalte køb i trin 11. Hver af dem bryder sammen et sted langs kundens vej, og det er præcis der, auditten kigger.
Det er, hvad du får ud af at følge kunden i stedet for sitemappen. Du holder op med at spørge “ser sitet sundt ud?” og begynder at stille fire sværere spørgsmål. Kan folk finde produktet? Er det, butikken siger om det, sandt? Kan de faktisk købe det? Og kan du se, at de gjorde det? En butik, der kan svare ja til alle fire, er i bedre form end en med en perfekt score.
Så vælg dine udsnits-URL’er, afsæt tiden, og start med Etape 1. Den første gennemgang er den langsomste. Derefter handler opgaven mest om at sikre, at det, du rettede, forbliver rettet.
