Din startsida svarar med 200 OK, upptidsmonitorn lyser grönt och ändå hör kunderna av sig: de kan inte slutföra sitt köp. Det här är en av de mest kostsamma situationerna för en WooCommerce-butik, eftersom problemet är osynligt för de flesta verktyg. Nedan går vi igenom varför en fungerande startsida inte betyder en fungerande kassa, och hur du felsöker steg för steg.
Varför 200 OK på startsidan inte säger något om kassan
En vanlig upptidskontroll hämtar en enda URL, oftast startsidan, och kontrollerar att servern svarar med HTTP 200. Men ett köp är inte en sida, det är ett flöde: produktsida, lägg i varukorg, varukorg, kassa och till sist betalning via en extern gateway. Varje steg körjs av olika kod, olika plugins och ibland externa tjänster. Startsidan kan cachas statiskt och laddas felfritt medan kassan, som aldrig cachas, kraschar på grund av ett JavaScript-fel eller ett brutet API-anrop till betalleverantören.
Steg 1: Återskapa hela köpflödet manuellt
Börja alltid med att gå igenom exakt det kunden gör. Öppna butiken i ett inkognitofönster så att du inte påverkas av inloggning eller cache:
- Öppna en produktsida och lägg produkten i varukorgen.
- Gå till varukorgen och kontrollera att summan stämmer.
- Fortsätt till kassan och fyll i uppgifter.
- Välj betalsätt och försök faktiskt genomföra en betalning, gärna i testläge.
Notera exakt var det brister. Fastnar det redan vid "lägg i varukorg" eller först när du klickar på "betala"? Det snävar in felet dramatiskt.
Steg 2: Kontrollera betalgatewayen och senaste uppdateringar
Betalningen är det vanligaste felstället eftersom den beror på en tredjepart. Kontrollera i din betalleverantörs kontrollpanel (Stripe, Klarna, Swish, PayPal) om det finns misslyckade eller avbrutna transaktioner. Titta också på tidslinjen: ett kassafel som började direkt efter en plugin- eller gateway-uppdatering är ett starkt spår. WooCommerce, betal-pluginet eller ett tema kan ha uppdaterats automatiskt natten innan. Rulla tillbaka den senaste ändringen på en testmiljö och se om felet försvinner.
Steg 3: Läs WooCommerce status och loggar
Gå till WooCommerce > Status och leta efter röda varningar, saknade tabeller eller föråldrade mallar. Under fliken Loggar hittar du felmeddelanden från gateways, ofta med den exakta orsaken, till exempel en avvisad API-nyckel eller ett timeout mot betalleverantören. Aktivera även WordPress felsökningsläge (WP_DEBUG_LOG) och titta i wp-content/debug.log för PHP-fel som utlöses just vid kassan.
Steg 4: Kontrollera mallöverskrivningar
Många teman och plugins skriver över WooCommerces kassamallar genom att lägga egna filer i tema/woocommerce/. När WooCommerce uppdateras kan dessa kopior bli föråldrade och sluta rendera viktiga fält eller knappar. WooCommerce Status visar en lista med mallar som är "out of date". Uppdatera eller ta tillfälligt bort överskrivningen och testa igen.
Steg 5: Öppna webbläsarens konsol vid kassan
Ett tomt betalfält eller en knapp som inte gör något beror nästan alltid på ett JavaScript-fel. Öppna utvecklarverktygen (F12), gå till fliken Console och ladda om kassan. Röda fel här, ofta en krock mellan två plugins eller ett skript som inte laddas, pekar direkt på boven. Titta även på fliken Network efter anrop till gatewayen som får statuskod 400 eller 500.
Steg 6: Uteslut cache och tredjepartsskript
Aggressiv cachning är en tyst bov vid kassan. Om en cache-plugin eller en CDN av misstag börjar cacha kassan eller varukorgen kan besökare få en gammal, felaktig sida med ogiltiga nonces, vilket får WooCommerce att avvisa åtgärden. Kontrollera att kassan, varukorgen och mitt-konto-sidorna är undantagna från all sidcache. Testa också att tillfälligt inaktivera tredjepartsskript som chattwidgetar, spårningspixlar och A/B-testverktyg, eftersom de ofta laddar tungt JavaScript just på kassan och kan krocka med gatewayens skript.
Steg 7: Kontrollera nonces och sessionshantering
WooCommerce använder nonces för att skydda mot förfalskade förfrågningar. Om en besökares session löper ut, eller om cachning serverar en föråldrad nonce, kan kassan svara med ett tyst fel eller ladda om utan att gå vidare. Detta är särskilt vanligt när sidan legat öppen en stund innan kunden klickar på betala. I felsökningsloggen visar det sig ofta som en misslyckad AJAX-förfrågan mot ?wc-ajax=checkout med statuskod 403. Om du ser detta mönster är cache eller sessionslängd nästan alltid orsaken.
Gör genomgången till en kontroll som körs med några minuters mellanrum
Steg 1 är rätt test – det ska bara inte behöva vänta på att en kund klagar. Ett syntetiskt flöde upprepar det i en riktig webbläsare enligt schema. Ge varje steg en kontroll som visar att det faktiskt fungerade, inte bara att en sida laddades:
- Produktsidan: knappen ”Lägg i varukorgen” finns och svarar.
- Varukorgen: rätt produkt och rätt summa visas.
- Kassan: formuläret renderas och inga JavaScript-fel loggas.
- Betalningen: betalleverantörens fält eller knapp laddas faktiskt – steget en vanlig HTTP-kontroll aldrig når.
Håll det fritt från bieffekter: använd betalleverantörens testläge eller stanna före den slutliga bekräftelsen, och ge flödet en egen testprodukt så att det aldrig rör riktiga ordrar, lagersaldon eller kundmejl. Mät också tiden per steg – en ”lägg i varukorgen” som kryper från en sekund till tre är en varning innan den blir ett avbrott.
Så slutar du bli överraskad av kassafel
Det verkliga problemet med kassafel är att de upptäcks av kunden innan de upptäcks av dig. En vanlig upptidskontroll av startsidan hade aldrig fångat något av ovanstående. Det är precis här syntetisk övervakning gör skillnad.
Ravnsight kör så kallade syntetiska flöden: en riktig webbläsare går igenom hela köpresan, från produkt till varukorg till kassa, precis som en kund, och larmar när ett steg går sönder. Vår WooCommerce Detective fångar dessutom gateway-fel, orderproblem och misslyckade webhooks direkt i butiken. En misslyckad kontroll bekräftas alltid från en andra plats innan larm skickas, så att du slipper falsklarm. Då vet du att kassan fungerar, inte bara att startsidan svarar.
