Föreställ dig en butik där varje dashboard ser bra ut. Startsidan är indexerad, Lighthouse är grönt och validatorn för strukturerad data visar inga fel. Men samtidigt stämmer inte priset i Google Shopping med priset i varukorgen, mobilens filterpanel fångar tangentbordsanvändare och varje köp registreras två gånger.
Inget av detta syns vid en snabb hälsokontroll. Det beror på att en webbutik är ett sammankopplat system, inte bara en enkel samling sidor. Produktdata flödar in i sidan, den strukturerade datan och shoppingflödena. Skript och tredjepartstaggar avgör hur snabbt allt laddas. Kassan omvandlar intresse till intäkter, och analysen ska registrera hela resan korrekt. När en del går sönder kan den tyst förvränga allt annat.
Det är därför en användbar e-handelsgranskning följer kunden, inte webbplatskartan. Checklistan nedan börjar med att hitta butiken och slutar med en slutförd order. Den ger dig en rangordnad lista över verkliga problem, var och en med bevis, en ansvarig och ett tydligt test för när det är åtgärdat.
När du bör köra den här granskningen, och varför ordningen spelar roll
Kör den fullständiga granskningen när du tar över en ny e-handelskund, efter en redesign eller plattformsmigrering, inför en stor tillväxtsatsning, eller när en rutinkontroll hittar en butiksomfattande försämring. Avsätt tre till sex timmar för en lätt genomgång, eller en till två dagar för en standardgranskning som testar varje viktig mall ordentligt. Djupgående utredningar av loggar, flöden eller analys kräver oftast separat tid.
Ordningen är medveten. Det är ingen idé att bedöma friktion i konverteringen om Google inte kan indexera kategorisidorna, och det är ingen idé att lita på trattrapporten om köptaggen utlöses två gånger.
En dubblerad köphändelse är inte bevis på mer försäljning, och en snabb produktsida är inte frisk om priset Google ser skiljer sig från priset i varukorgen. Därför rör sig granskningen i etapper. Den börjar med att hitta butiken, går sedan vidare till produktsanning, snabbhet och själva köpet, och först därefter till mätning.
Innan du börjar, samla det du behöver. Det innebär åtkomst till:
- Search Console,
- Analytics,
- Tag manager,
- Katalog- eller flödeskälla,
- Merchant Center,
- en lista över nyliga ändringar på webbplatsen.
Etapp 1: Kan sökmotorer hitta katalogen?
1. Bygg ett urval som representerar hela butiken
De flesta e-handelsbuggar finns i delade mallar och ovanliga produktstatusar. En städad startsida säger ingenting om filtrerade kategorier, variantlogik, slut-i-lager eller kassa. Därför bör du börja med att bekräfta att du testar den skarpa produktionssajten i rätt marknad, valuta och språk. Välj sedan minst en URL för var och en av dessa:
- startsidan
- en prioriterad kategori
- en djupare kategori eller en godkänd filtersida
- en typisk produkt
- en produkt med varianter
- en produkt som är slut i lager eller utgått
- en sida med interna sökresultat, inklusive en som inte ger några träffar
- varukorgen, kassan och sidan för orderbekräftelse
Lägg till ett knepigt eller ovanligt exempel för varje mall som verkar riskabel. Din rapport över landningssidor i analysen och en katalogexport hjälper dig att välja.
Du är klar när varje viktig mall och kassastatus har en namngiven test-URL, och allt du inte kunde testa är markerat som “inte testat”.
2. Kontrollera genomsökbarhet, indexering, kanoniska taggar och webbplatskartor
Om genomsökningsvägen är trasig kommer publicering av fler produkter bara att multiplicera antalet drabbade URL:er. Motstridiga signaler gör också problem svårare att diagnostisera. Robots-regler kan säga en sak, medan kanoniska taggar och webbplatskartan säger något helt annat.
Granska robots.txt, XML-webbplatskartorna, svarskoder, robots-metataggar och -huvuden, kanoniska taggar, paginering och interna länkar. Använd URL Inspection i Search Console för att se vilken kanonisk URL Google faktiskt valde för dina urvalssidor. Jämför sedan webbplatskartan med verkligheten. Den bör lista live, indexerbara sidor som returnerar status 200, inte omdirigeringar, fel, noindexade sidor eller dubbletter.
Du är klar när dina avsedda landningssidor returnerar 200, kan genomsökas, följer en konsekvent policy för kanoniska taggar och indexering och finns med i webbplatskartan. Varje betydande undantag bör ha en förklaring eller en ansvarig.
3. Följ länkarna: omdirigeringar, fel och JavaScript
En butik kan se komplett ut i en webbläsare medan genomsökare och hjälpmedel ser en mycket tunnare version. Kör en genomsökare för att hitta trasiga interna länkar, omdirigeringskedjor, loopar och mjuka 404:or. Jämför sedan den renderade sidan med rå HTML. Produktkort, paginering, brödsmulor och kategorilänkar bör vara verkliga och genomsökbara, och viktigt innehåll bör inte enbart bero på JavaScript.
Du är klar när interna länkar pekar direkt till sin slutdestination, felsidor returnerar rätt statuskod och prioriterade produkter kan hittas utan att förlita sig på oändlig scrollning.
4. Testa kategorier, filter, paginering och sök på webbplatsen
Kategori- och filtersystem kan skapa genomsökningsfällor för sökmotorer och frustration för kunder samtidigt. En sida kan vara tekniskt indexerbar och ändå vara en svag landningssida om hälften av produkterna på den är irrelevanta.
Prova filtren på desktop och mobil. Kontrollera flerval, “rensa allt”, antal träffar, sortering, paginering eller “ladda fler”, och filterkombinationer som inte ger något. Titta på URL:erna som filtren genererar och jämför dem med butikens indexeringspolicy. Lägg också märke till om ett långt textblock i kategorin trycker ner produktrutnätet under skärmvecket.
Du är klar när kontrollerna beter sig konsekvent, slumpmässiga filterkombinationer inte blir oavsiktliga landningssidor och kunder kan ångra ett filter utan att tappa sin plats.
Redo att växa ditt företag?
Starta din kostnadsfria provperiod idag och se resultat inom några dagar.
Etapp 2: Berättar produktdatan sanningen?
5. Stäm av produktidentitet, pris, lager och varianter
Ett felaktigt fält kan inte bara vilseleda en kund, utan leda hela vägen till en felaktighet i kassan. Samtidigt kan datan vara perfekt formaterad och ändå fel.
För en handfull representativa produkter, jämför namn, varumärke, SKU, GTIN eller EAN, vald variant, pris, valuta, tillgänglighet, bilder och viktiga specifikationer överallt där de visas. Kontrollera vad som visas på sidan, i den strukturerade datan, i handlarflödet, i varukorgen och i kassan. Inkludera reaprodukter, varianter, slut-i-lager, förbeställningar och utgångna produkter.
Du är klar när de granskade uppgifterna stämmer överallt, och varje avsiktlig skillnad, som varumärke kontra tillverkare, är explicit i datamodellen.
6. Validera strukturerad data mot det kunderna ser
Strukturerad data hjälper bara när den beskriver sidan korrekt. En validator accepterar gärna “InStock” medan både sidan och kassan säger att produkten inte är tillgänglig. Därför bör du köra varje produktstatus genom Google Rich Results Test eller Schema.org Validator. Jämför sedan de markerade värdena med det synliga innehållet och källflödet. För produkter med varianter, kontrollera att din uppmärkningsmetod och din kanoniska konfiguration matchar hur sidorna faktiskt är byggda.
Du är klar när granskade kvalificerade sidor inte saknar obligatoriska egenskaper, uppmärkningen matchar det som är synligt och recensioner och betyg bara är uppmärkta när kunderna kan se dem på den produkten.
Etapp 3: Är butiken snabb för riktiga kunder?
7. Mät Core Web Vitals utifrån fältdata först
Data från riktiga användare och en enskild Lighthouse-körning svarar på olika frågor. Lighthouse hjälper dig att återskapa ett problem, men kan inte säga om riktiga kunder klarar sig eller inte.
Börja med PageSpeed Insights och rapporten Core Web Vitals i Search Console. Notera om fältdata finns för den exakta URL:en eller bara för hela webbplatsen. Googles gränsvärden för “bra”, mätta vid 75:e percentilen, är:
- LCP (laddning): 2,5 sekunder eller mindre
- INP (responsivitet): 200 millisekunder eller mindre
- CLS (visuell stabilitet): 0,1 eller mindre
Titta på mobil och desktop separat. Om det inte finns någon fältdata, registrera resultatet som okänt och behandla labbresultat som preliminära. Okänt är inte samma sak som grönt.
Du är klar när varje prioriterad mall har en fältdom per enhet, eller en tydligt angiven avsaknad av data, med källa och datumintervall registrerade.
8. Hitta orsaken, inte bara betyget
Generiska råd som “komprimera dina bilder” eller “minska JavaScript” missar ofta den verkliga flaskhalsen och skapar arbete som inte flyttar det misslyckade måttet. Hitta det specifika element, den begäran eller det skript som är ansvarigt.
Identifiera LCP-elementet och vad som fördröjer det. Kontrollera sedan de vanliga misstänkta, som bildstorlek, lazy-loading på bilder ovanför skärmvecket, renderingsblockerande CSS, teckensnittsladdning, tredjepartsskript, långa uppgifter, cachning, serverns svarstid, källor till layoutförskjutning och taggar som laddas två gånger.
Kör upprepade tester under samma förhållanden och jämför en konsekvent statistik, inte din bästa körning. Kom ihåg att Total Blocking Time är en användbar labbsignal, men det är inte INP.
Du är klar när varje betydande prestandafynd namnger det misslyckade måttet, den påverkade mallen, en reproducerbar orsak och en ansvarig.
Gå med i vårt nyhetsbrev
Få de senaste tipsen, trenderna och erbjudandena gratis.
Etapp 4: Kan folk faktiskt köpa något?
9. Testa användbarhet och tillgänglighet på mobilen med riktiga shoppingkontroller
Automatiserade betyg täcker inte varje interaktion. En butik kan klara en skanning medan filterpanelen fångar tangentbordsfokus, cookiemeddelandet täcker lägg-i-varukorgen-knappen eller storleksväljaren saknar en tillgänglig etikett.
Testa vid telefonbredder på 360 till 390 pixlar, zooma texten och prova hela resan med bara ett tangentbord. Håll koll på fokusordning och synlighet i menyer, paneler och dialogrutor. Kontrollera att etiketter, knappar, formulärfel och touchytor fortfarande är begripliga.
Du är klar när en kund kan ta sig igenom huvudresan utan dolda kontroller eller fokusfällor, och inget på mobilen döljer pris, tillgänglighet, variantval, lägg-i-varukorgen-knappen eller kassan.
10. Kör varukorgen och kassan som ett kontrollerat test
En synlig kassaknapp bevisar inte att kassan fungerar. Buggar i kassan är kommersiella incidenter, och de undergräver också din analys.
För att testa detta, lägg en normal produkt och en variant i varukorgen. Ändra antalet, ta bort en vara och använd en rabattkod (eller en avsiktligt ogiltig sådan) om du har en. Testa sedan gästkassa och kontokassa, fraktalternativ, betalningsval, valideringsfel, bakåtknappen och mobilayouten. Använd en testorder eller en godkänd icke-debiterande väg. Lägg aldrig en riktig order utan tillstånd.
Du är klar när köpet slutförs eller når den överenskomna testgränsen, summor förblir korrekta, felmeddelanden berättar vad folk ska göra och varje blockerad väg dokumenteras med bevis och affärspåverkan.
Etapp 5: Mäter du resan korrekt?
11. Verifiera analys, dubblerade taggar och samtycke
Dubblerade taggar blåser upp sidvisningar, lägg-i-varukorgen-händelser och köp. Saknade eller felaktiga värden gör intäktsrapporter osäkra att fatta beslut utifrån. Målet är enkelt: en kundåtgärd ska ge en händelse, med rätt produkt, värde, valuta, transaktions-ID och samtyckesstatus.
Lista varje tag manager-container, Google-tagg, annonspixel, affiliate-skript och serversidig integration. Spåra sedan, i en kontrollerad session, view_item, add_to_cart, begin_checkout och purchase. Jämför vad webbläsaren skickar med GA4 DebugView och orderposten i backend. Testa före och efter att kunden gör ett samtyckesval.
Du är klar när varje åtgärd utlöser sin händelse exakt en gång, köp bär ett stabilt transaktions-ID, värden och valuta stämmer med backend och icke-nödvändiga taggar följer samtyckespolicyn.
12. Stäm av Search Console och Merchant Center mot det du hittade
Ett lokalt sidtest kan inte visa varje indexerad kanonisk URL, varning i webbplatskartan, produktavslag eller förlorad sökfråga. En dashboard-varning kan å andra sidan beskriva ett problem som redan är åtgärdat.
Granska dina prioriterade URL:er i Search Console, gå igenom rapporterna för produkter och handlarannonser och kontrollera Merchant Center-diagnostiken mot det du såg på den skarpa sajten. Notera datumen, eftersom omsökning och flödesbearbetning släpar efter utrullningar.
Du är klar när varje betydande dashboard-problem matchar bevis från den skarpa sajten eller är markerat som väntande på spridning, och varje öppet ärende har en ansvarig.
Etapp 6: Skulle en kund lita på den här butiken?
13. Kontrollera förtroendesignaler, kontaktuppgifter, frakt och returer
Dold eller motstridig kommersiell information gör kunder tveksamma och driver upp antalet supportärenden. Jämför sidhuvudet och sidfoten, kontaktsidan, kassan och policysidorna.
Du är klar när företagets identitet är tydlig, frakt-, retur- och betalningspåståenden stämmer genom hela resan och ingen förtroendebadge är overifierbar.
14. Kontrollera HTTPS, blandat innehåll och frontend-hygien
Det här är inte ett penetrationstest, utan en fråga om grundläggande datahygien. Bekräfta att HTTP omdirigeras till HTTPS i ett steg, att certifikatet är giltigt, att det inte finns något blandat innehåll och att formulär skickas korrekt. Kontrollera konsolen för allvarliga fel. Om något ser ut som en verklig säkerhetssårbarhet, skicka det till en specialist i stället för att diagnostisera det utifrån en generisk varning.
Du är klar när prioriterade sidor och kassan laddas säkert, omdirigeringar tar ett steg och formulär beter sig som förväntat.
Från fynd till åtgärder
15. Gör fynd till en ägd åtgärdskö
En granskning som slutar i skärmbilder eller ett betyg minskar inte risken. Femtio symptom orsakade av en trasig mall bör inte bli femtio orelaterade ärenden. Gruppera fynden efter grundorsak. Notera om det är komponenten, mallen, flödesregeln eller spårningsuppsättningen. Behåll de påverkade URL:erna som bevis. Prioritera sedan:
- P0: ett aktivt fel som blockerar verksamheten, eller ett kritiskt problem för hela webbplatsen
- P1: ett betydande fel som du är säker på
- P2: ett viktigt problem med begränsad omfattning
- P3: en förbättring att övervaka
Du är klar när varje betydande fynd har en ansvarig, ett förfallodatum, ett test för “åtgärdat” och ett datum för att kontrollera det igen efter release.
Leveransen
Lämna över ett versionshanterat dokument eller kalkylblad med en rad per fynd och en kort sammanfattning högst upp. Varje rad bör täcka:
- Beteendet,
- det förväntade beteendet,
- de påverkade URL:erna,
- bevisen och när du samlade in dem,
- allvarlighetsgrad och säkerhet,
- den troliga orsaken,
- den rekommenderade åtgärden,
- den ansvariga och testet som bevisar att det är klart.
Men kom ihåg att du inte bör markera ett problem som åtgärdat bara för att någon stängde ärendet. Markera det som verifierat när testet passerar i produktion.
Verktyg för jobbet
Du behöver inga prenumerationer för att framgångsrikt göra en stark första genomgång. Allt du behöver är dessa gratisinstrument:
- Google PageSpeed Insights för fältdata (där sådan finns) och Lighthouse-diagnostik
- Google Search Console för indexering, webbplatskartor, URL Inspection, Core Web Vitals och rapporter om strukturerad data
- Google Rich Results Test och Schema.org Validator för strukturerad data
- Chrome DevTools och Lighthouse för nätverk, prestanda, layoutförskjutningar, tillgänglighet och konsolkontroller
- Google Tag Assistant och GA4 DebugView för händelsespårning
- SSL Labs Server Test för TLS-konfiguration
Om du vill ha en genväg låter AmICited dig samla alla dessa bevis och behålla baslinjen för senare. Vyn Performance Impact jämför mallar efter LCP, INP, CLS och serverns svarstid. URL Inspection och Sitemaps and Indexing följer indexering för prioriterade URL:er. Products och Assortment visar vilka delar av katalogen som har störst kommersiell vikt. Annotations in the Reports Hub kopplar varje release till vad som hände efteråt. Verktygen levererar bevisen. Butiksägaren, utvecklaren eller analytikern avgör fortfarande vad som är korrekt och vilka avvägningar som är acceptabla.
Efter granskningen
Skicka varje bekräftat problem till det specialistflöde som kan stänga det: genomsöknings- och renderingsproblem till en teknisk SEO-granskning , fältprestandafel till åtgärdande av Core Web Vitals , problem med fasetter och lagerstatus till en granskning av kategorier och produkter , och spårningsproblem till den som äger analysen.
Det finns ingen anledning att köra om hela granskningen efter varje åtgärd. Testa om det påverkade området, kommentera releasen så att du kan se vad som förändrades efteråt, och låt den regelbundna hälsokontrollen fånga nästa försämring.
Tillbaka till butiken där allt såg bra ut
Kommer du ihåg butiken från början? Dess startsida var indexerad, Lighthouse var grönt och validatorn var ren. Ändå visade Google Shopping fel pris, filterpanelen fångade tangentbordsanvändare och varje försäljning räknades två gånger.
Ingen dashboard flaggade något av det. Den här checklistan skulle ha fångat alla tre: prismismatchen i steg 5, fokusfällan i steg 9 och det dubbelräknade köpet i steg 11. Var och en går sönder någonstans längs kundens väg, och det är precis där granskningen tittar.
Det är vad du får av att följa kunden i stället för webbplatskartan. Du slutar fråga “ser webbplatsen frisk ut?” och börjar ställa fyra svårare frågor. Kan folk hitta produkten? Stämmer det butiken säger om den? Kan de faktiskt köpa den? Och kan du se att de gjorde det? En butik som kan svara ja på alla fyra är i bättre form än en med ett perfekt betyg.
Så välj dina urvals-URL:er, avsätt tiden och börja med etapp 1. Den första genomgången är långsammast. Efter det handlar jobbet mest om att se till att det du åtgärdade förblir åtgärdat.
