Een klant vult zijn adres in, kiest iDEAL, klikt op “bestelling plaatsen” en ziet een draaiend rondje. Tien seconden. Dertig. Dan sluit hij het tabblad en bestelt bij een ander. U merkt er niets van, want er komt geen foutmelding en geen bestelling binnen. Pas als de omzet een week later opvallend laag is, of een klant belt met “uw site doet het niet”, komt het aan het licht.
Als de WooCommerce checkout blijft laden, is dat bijna altijd een probleem in de communicatie tussen de browser en uw server: de pagina wacht op een antwoord dat niet komt. De oorzaken zijn divers, maar ze zijn wel in een vaste volgorde uit te sluiten. In dit artikel loopt u door de zeven meest voorkomende, van eenvoudig naar technisch, met per oorzaak hoe u hem herkent.
Eerst: reproduceer het probleem
Voordat u iets aanpast, wilt u het zelf zien. Open de shop in een privévenster, leg een goedkoop product in de winkelwagen en ga naar de afrekenpagina. Let op waar het hangt: bij het laden van de pagina zelf, bij het invullen van het adres (dan worden verzendkosten herberekend), of na de klik op “bestelling plaatsen”. Dat onderscheid wijst de richting.
Open ook de ontwikkelaarsconsole van de browser (F12, tabblad Console en Netwerk). Een rode regel met “wc-ajax” of “admin-ajax.php” en een status 500, 403 of een timeout is de belangrijkste aanwijzing die u kunt meenemen, ook als u niet weet wat hij betekent.
Oorzaak 1: de afrekenpagina wordt gecachet
Dit is verreweg de meest voorkomende oorzaak. De afrekenpagina is per klant anders en mag nooit uit een cache komen. Toch gebeurt dat na de installatie van een cacheplugin of een wijziging bij de host. De pagina laadt dan een versie zonder geldig beveiligingstoken (de zogeheten nonce), en elk verzoek om verzendkosten te berekenen of de bestelling te plaatsen wordt geweigerd, meestal zonder zichtbare fout.
Herkennen: het probleem is er niet als u bent ingelogd als beheerder (ingelogde gebruikers krijgen vaak geen cache). Oplossen: sluit de pagina’s winkelwagen, afrekenen en mijn-account uit van caching, in de cacheplugin én bij servercaching van de host. Leeg daarna alle cachelagen. Werkt de winkelwagen ook raar, dan is dit vrijwel zeker de oorzaak; het verwante probleem "winkelwagen is leeg na toevoegen" heeft dezelfde achtergrond.
Oorzaak 2: een JavaScript-fout op de pagina
De afrekenpagina van WooCommerce is afhankelijk van JavaScript. Als een ander script eerder op de pagina vastloopt, komt het checkout-script nooit aan de beurt en blijft het rondje draaien. Veelvoorkomende boosdoeners: een optimalisatieplugin die scripts uitstelt of samenvoegt, een verouderde plugin die jQuery op een oude manier gebruikt, of een trackingscript dat door een adblocker wordt geblokkeerd en daarbij fouten geeft.
Herkennen: rode meldingen in het tabblad Console. Oplossen: sluit de afrekenpagina uit van JavaScript-optimalisatie (uitstellen, samenvoegen, minimaliseren). Helpt dat, dan weet u de richting; zoek daarna welk script precies botst.
Oorzaak 3: de betaalplugin krijgt geen antwoord
Na de klik op “bestelling plaatsen” maakt de betaalplugin contact met Mollie, Pay.nl of een andere provider om de betaling te starten. Als die verbinding niet lukt, kan de klant niet doorgestuurd worden. De oorzaak kan een verlopen API-sleutel zijn, een firewall op de server die uitgaande verbindingen blokkeert, of een storing bij de provider zelf.
Herkennen: de pagina hangt pas ná het plaatsen, en in WooCommerce verschijnt wél een bestelling met status “in afwachting van betaling”. Oplossen: controleer de statuspagina van de betaalprovider, controleer de API-sleutel in de plugin en kijk in WooCommerce, Status, Logs naar meldingen van de betaalplugin.
Oorzaak 4: verzendkosten die niet berekend kunnen worden
Zodra een klant zijn postcode invult, berekent WooCommerce de verzendopties. Een verzendkoppeling die een externe dienst raadpleegt (bijvoorbeeld voor afhaalpunten of live tarieven) kan daarbij vastlopen als die dienst traag is of de API-sleutel niet meer geldig is. De pagina wacht dan eindeloos op verzendopties.
Herkennen: het hangt tijdens het invullen van het adres, en het probleem verdwijnt als u de verzendkoppeling tijdelijk uitschakelt. Oplossen: update de verzendplugin, controleer de koppeling met de vervoerder en stel zo nodig een fallback-verzendmethode in met een vast tarief.
Oorzaak 5: geheugen of tijdslimiet op de server
De afrekenpagina is een van de zwaarste pagina’s van de shop. Bij een krappe geheugenlimiet of een lage tijdslimiet voor PHP kan het verzoek halverwege afgebroken worden. Dat gebeurt vooral bij shops met veel plugins, grote winkelwagens of complexe btw- en verzendregels.
Herkennen: in het Netwerk-tabblad een status 500 of 504 op het checkout-verzoek; in het foutenlog van de server een melding over “memory exhausted” of “maximum execution time”. Oplossen: verhoog de limieten via de host of wp-config.php, maar zie het als noodverband; de echte oplossing is uitzoeken wat zo veel geheugen vraagt.
Oorzaak 6: een beveiligingsplugin of firewall blokkeert het verzoek
Firewalls kijken naar patronen. Een verzoek naar de afrekenpagina bevat veel velden, soms met tekens die op een aanval lijken. Een te streng ingestelde firewall (in een plugin, bij de host of bij Cloudflare) blokkeert dat dan stilletjes met een 403.
Herkennen: status 403 in het Netwerk-tabblad, of het probleem treedt alleen op bij bepaalde adressen of landen. Oplossen: zoek de geblokkeerde regel op in het log van de firewall en voeg een uitzondering toe voor de checkout.
Oorzaak 7: een conflict na een update
Als het probleem gisteren nog niet bestond en vandaag wel, kijk dan wat er is veranderd. Een update van WooCommerce, het thema of een betaal- of verzendplugin is de gebruikelijke aanleiding. Met name de overgang naar de blokken-checkout heeft veel oudere plugins doen struikelen.
Oplossen: zet op een staging-omgeving de laatste updates één voor één terug tot de checkout weer werkt. Dat is de reden dat wij webshop-updates nooit direct op de live shop doen, maar altijd eerst testen met een proefbestelling; dat is een vast onderdeel van het onderhoud van een WooCommerce-webshop.
Wat u zelf doet en wanneer u belt
Oorzaken 1, 3 en 7 kunt u met wat geduld zelf onderzoeken. Voor 2, 5 en 6 heeft u iemand nodig die logbestanden kan lezen en op de server kan. Belangrijker dan wie het oplost, is hoe snel u het merkt: een afrekenpagina die hangt, kost per uur omzet. Een fietsenwinkel uit Amersfoort verloor naar eigen schatting een week aan online bestellingen voordat iemand het opmerkte; de oorzaak was een cacheplugin die na een hostingmigratie de afrekenpagina was gaan cachen.
Volgende stap: plaats vandaag zelf een testbestelling in een privévenster, helemaal tot en met de betaalpagina. Doe dat wekelijks. Het kost drie minuten en het is de enige manier om dit probleem vóór uw klanten te ontdekken.



