Lagerstatus opdateres forkert i WooCommerce

Kort svar: Når WooCommerce-lageret ikke opdateres korrekt, er årsagen næsten altid én af fire: siden vises fra cache, ordren nåede aldrig en status, der trækker lager, en integration eller import overskriver tallet bagefter, eller lageret styres to steder (hovedprodukt og variant). Sammenlign tallet i wp-admin med forsiden i et privat vindue, og læs ordrenoterne på de seneste ordrer. Så ved du, om det er visning, ordreflow eller data, der er galt.

Fagligt gennemgået: 2. oktober 2026

Forkert lagerstatus koster på to måder: du sælger varer, du ikke har, eller du skjuler varer, du faktisk har. Begge dele kan se ud som “WooCommerce opdaterer ikke lageret”, men årsagerne er vidt forskellige.

Afgør først, hvor fejlen sidder. Åbn produktet i wp-admin og på forsiden i et privat vindue. Er tallet forskelligt, er det cache. Er det ens og forkert begge steder, er det data – og så skal du finde ud af, hvem der sidst skrev tallet.

Før du ændrer noget: Tag en backup af databasen, før du retter lagertal i bulk, kører en CSV-import eller regenererer opslagstabeller. Notér de nuværende tal på de berørte produkter. Ret ikke lageret manuelt, mens en integration kører – så ved du ikke bagefter, hvilken ændring der kom fra hvem.

Symptomer og sandsynlig årsag

Symptom	Sandsynlig årsag	Første kontrol
Forsiden viser et andet tal end wp-admin	Sidecache, CDN eller browsercache	Privat vindue og cache-headere
Lageret falder ikke ved salg	Ordren står stadig som “Afventer betaling”, eller lagerstyring er slået fra	Ordrestatus og ordrenoter
Tallet passer efter salg, men ændrer sig senere	ERP, lagerprogram eller import skriver bagefter	Integrationens log
Varen står som udsolgt, selv om ingen har betalt	Reservation i en ubetalt ordre eller “Grænse for udsolgt”	Hold lager-indstillingen og ubetalte ordrer
Variabelt produkt viser forkert	Lagerstyring på både hovedprodukt og variant	Lagerfanen på produkt og varianter
Filtre og kategorier viser forkerte varer	Produktopslagstabellen er ude af trit	WooCommerce → Status → Værktøjer

1. Udelukk cache

Produktsider må gerne caches, men lagerstatus skal opdateres. Sæt cachen til at blive ryddet for et produkt, når lageret ændres, eller undlad at vise præcise tal i oversigten og nøjes med “på lager” og “udsolgt”.

Kør du LiteSpeed Cache, har pluginet en WooCommerce-indstilling for, hvornår et produkt skal ryddes fra cachen ved ændring af antal eller lagerstatus – se LiteSpeed Cache til WooCommerce. Ligger der en CDN-cache foran, som Cloudflare med en regel, der cacher HTML, skal den også ryddes eller undtages. Tjek svar-headerne med:

curl -sI https://dinshop.dk/produkt/eksempel/ | grep -i -E "cache|age"

Ser du et cache-hit med en høj age-værdi lige efter et salg, er det cachen, der viser det gamle tal. Kurv, kasse og Min konto må aldrig caches – se også hvad der skal undtages fra cache i WooCommerce.

2. Find ud af, hvem der sidst rørte lageret

WooCommerce skriver en note på ordren, hver gang den ændrer lager – fx at lagerbeholdningen er reduceret fra 5 til 4 – med tidspunkt. Åbn de seneste ordrer på produktet, og sammenlign noterne med det tal, du ser nu. Passer tallet med ordrenoterne, er det ikke WooCommerce, der har taget fejl – så er det noget udefra, der har skrevet et andet tal bagefter. Passer det ikke, er det ordreflowet eller cachen. Har du et lagersystem koblet på, så slå dets egen log op på samme produkt; de fleste ERP-integrationer logger hver synkronisering med tidspunkt og værdi.

Med WP-CLI kan du se de rå værdier for et produkt uden at stole på det, temaet viser:

wp wc product get 123 --user=1 --fields=id,manage_stock,stock_quantity,stock_status
wp post meta get 123 _stock
wp post meta get 123 _stock_status

Står stock_quantity til 4, men stock_status til “outofstock”, er der noget, der har sat status direkte uden at røre antallet – typisk en import eller en integration.

3. Kontrollér, at ordren når en status, der trækker lager

WooCommerce reducerer lageret, når en ordre bliver betalt eller går til status “Behandles”, “Gennemført” eller “Afventer” (on-hold, fx ved bankoverførsel). En ordre, der bliver stående som “Afventer betaling”, har ikke trukket lager. Det sker typisk, når betalingsgatewayens callback ikke når frem til shoppen – kunden har betalt, men WooCommerce har aldrig fået besked. Se ordrer, der bliver stående som “Afventer betaling”.

Går lageret op igen uventet, så kig efter annulleringer og refusioner. En annulleret ordre, der allerede havde trukket lager, lægger varen tilbage. Ved en refusion lægges varen kun tilbage, hvis “Genopfyld refunderede varer” er markeret i refusionsdialogen – så det afhænger af, hvem der lavede refusionen, og hvordan.

4. Tjek de planlagte opgaver

Selve lagerreduktionen ved en betalt ordre sker med det samme. Men en række ting omkring lageret afhænger af, at WordPress’ planlagte opgaver kører: annullering af ubetalte ordrer efter “Hold lager”-perioden, webhooks til eksterne systemer og mange ERP- og lagerintegrationer, der bruger Action Scheduler til at sende og hente tal. Går køen i stå, bliver reservationer hængende, og eksterne systemer får ikke besked om salg – og så sælges varer, der reelt er væk.

Kig i WooCommerce → Status → Planlagte handlinger efter “Afventer” ældre end fem minutter og efter “Mislykket”. Er der mange, så se når Action Scheduler ikke kører. Køen kan også køres manuelt med WP-CLI:

wp action-scheduler run
wp cron event list --fields=hook,next_run_relative | grep woocommerce

WordPress’ interne cron starter kun, når nogen besøger sitet, og bliver sat i kø bag alt andet, når serveren er presset. Et rigtigt cron-job fra serveren hvert femte minut gør køen forudsigelig. Se wp-cron virker ikke for opsætningen.

5. Gennemgå lagerindstillingerne

Under WooCommerce → Indstillinger → Produkter → Lager ligger flere indstillinger, der kan ligne fejl:

• Hold lager (minutter). Varer i ubetalte ordrer holdes reserveret i det antal minutter, standard 60. En vare kan derfor ikke købes, selv om ingen har betalt – og bliver frigivet igen, når perioden udløber og ordren annulleres. Det ligner en fejl, men er en reservation.
• Grænse for udsolgt. Står den fx til 2, vises varen som udsolgt, når der er 2 tilbage. Det er nyttigt som buffer, men forvirrende, hvis ingen ved, at den er sat.
• Aktivér lagerstyring. Er den slået fra globalt, trækker WooCommerce slet ikke lager. Den skal også være slået til på det enkelte produkt.
• Restordrer. Tillader produktet restordrer, kan lageret gå i minus, uden at varen bliver udsolgt.

6. Hvis to systemer skriver samtidig

Har du et lagerstyringssystem eller en ERP-integration, kan begge sider skrive til lageret. Uden en klar retning ender de med at overskrive hinanden.

Beslut, hvem der ejer tallet. Er det ERP’et, skal WooCommerce kun modtage – og integrationen skal være sat op, så den ikke sender et gammelt tal tilbage, lige efter WooCommerce har trukket et salg. Kører begge, får du afvigelser, der vokser over tid. Et typisk mønster: WooCommerce sælger én, ERP’et synkroniserer sit tal fra før salget og overskriver, og varen “kommer tilbage” på lager. Se også lagersynkronisering på tværs af kanaler.

Varianter, bundter og lager på produktniveau

Et variabelt produkt kan styre lager to steder: på hovedproduktet eller på hver variant. Er begge slået til, trækker et salg fra det ene sted, mens oversigten viser det andet. Beslut ét niveau – for tøj og sko næsten altid varianten – og slå lagerstyring fra på hovedproduktet. Bundter og pakkeprodukter fra plugins har samme problem i større skala: bundtet har sit eget lager, og komponenterne har hver deres, og kun nogle plugins holder dem synkroniserede. Test med ét køb, og se, hvilke tal der flytter sig. Se også variationer, der vises forkert.

Importerer du produkter via CSV, så vær opmærksom på kolonnen “Lager”. En import med tomme lagerfelter sætter ikke lageret til nul – men en import med et gammelt tal overskriver det aktuelle. Kør importer med “opdater eksisterende” kun med de kolonner, der faktisk skal ændres.

Når filtre og kategorier viser forkert lagerstatus

WooCommerce gemmer en kopi af blandt andet lagerstatus og pris i en opslagstabel, som bruges til filtre og sortering. Er data ændret direkte i databasen eller af en import, der springer WooCommerce’ egne funktioner over, kan tabellen komme ud af trit med produktet. Så viser produktsiden “på lager”, mens filteret “kun varer på lager” skjuler varen. Løsningen ligger under WooCommerce → Status → Værktøjer: regenerér produktopslagstabellerne og ryd WooCommerce-transients. Det kører i baggrunden og kan tage tid på store shops.

Ved samtidige køb

To kunder, der køber den sidste vare næsten samtidig, kan begge komme igennem. WooCommerce opdaterer selve lagertallet i én databaseoperation, og reservationer under checkout mindsker risikoen, men ved betalinger, hvor kunden sendes til en ekstern betalingsside, trækkes lageret først, når betalingen bekræftes. Det sker sjældent på små butikker og jævnligt ved kampagner, hvor lageret så kan ende i minus.

Det er et ressourcespørgsmål lige så meget som et kodespørgsmål: en presset server gør vinduet mellem tjek og reduktion længere. Se de ti krav til drift af en WooCommerce-butik.

Sådan tester du, at det er rettet

• Sæt lageret på et testprodukt til 3, og læg en ordre i et privat vindue. Tallet skal falde til 2 på produktsiden inden for få sekunder – ellers er cachen ikke undtaget eller ordren ikke nået en status, der trækker lager.
• Annullér ordren. Tallet skal gå tilbage til 3. Gør det ikke det, så læs ordrenoterne – blev lageret overhovedet trukket, og er der et plugin, der griber ind?
• Ret lageret i ERP’et (eller i WooCommerce, hvis det ejer tallet), og vent på næste synkronisering. Kun én retning må skrive.
• Kig i Status → Planlagte handlinger efter “Afventer” ældre end fem minutter. Er der ingen, kører køen.
• Test et filter som “kun varer på lager” på en kategoriside, så du ved, at opslagstabellen også er rigtig.

Hvornår skal du have hjælp?

Hent hjælp hos integrationens leverandør, hvis loggen viser, at deres synkronisering skriver forkerte tal, og hos hostingen, hvis planlagte handlinger hober sig op, selv om cron er sat rigtigt op. Saml produkt-ID, ordrenumre, ordrenoter og tidspunkter, før du skriver – så kan fejlen findes på minutter i stedet for dage. På WooCommerce hosting hos Hostious har du staging fra Woo StartUp, daglig backup og dansk support døgnet rundt.

Læs også

• Hub: WooCommerce fejl og fejlfinding
• Forfaldne planlagte handlinger i WooCommerce
• WooCommerce-ordrer bliver stående som “Afventer betaling”
• Lagersynkronisering på tværs af kanaler
• WooCommerce hosting hos Hostious – hosting bygget til webshops med daglig backup og staging fra Woo StartUp

Ofte stillede spørgsmål om WooCommerce-lager

Skal jeg vise præcise lagertal?

Sjældent. “Kun 3 tilbage” sælger, men kræver at tallet er rigtigt. Er du i tvivl, så vis kun på lager eller udsolgt.

Hvorfor stiger lageret nogle gange?

Fordi en annulleret eller refunderet ordre lægger varen tilbage. Sker det uventet, så kig i ordrelogen.

Hvorfor står en vare som udsolgt, selv om ingen har købt den?

Sandsynligvis fordi den ligger i en ubetalt ordre. WooCommerce reserverer varer i det antal minutter, der er sat under ‘Hold lager’, standard 60 minutter, og frigiver dem igen, hvis ordren ikke betales.

Skal lager styres på hovedproduktet eller på varianterne?

Kun ét af stederne. For produkter med størrelser og farver næsten altid på varianten. Er lagerstyring slået til begge steder, trækker salget fra det ene, mens oversigten viser det andet.