WooCommerce hosting: 10 krav til drift

Kort svar: De vigtigste krav til WooCommerce hosting er aktuel PHP (8.3 eller nyere), en understøttet MySQL- eller MariaDB-version, nok CPU og RAM til de dynamiske sider, NVMe-lager, objektcache og en sidecache, der aldrig cacher kurv, checkout og min konto. Dertil kommer testet backup og gendannelse, staging, sikkerhed i flere lag og overvågning af selve købsflowet. Mål altid kurv og checkout – ikke kun forsiden.

Fagligt gennemgået: 2. oktober 2026

WooCommerce hosting er den del af din webshopdrift, der afgør, om kurv, checkout og ordreflow fungerer hurtigt og stabilt, også når trafikken stiger. En webshop opfører sig ikke som en almindelig hjemmeside: lageropslag, betalingsmoduler, rabatter og produktfiltre skaber mange dynamiske databasekald.

Den rigtige hosting beskytter dig mod tabt omsætning fra langsom svartid, fejl i checkout og nedbrud under kampagner. Her er kravene, du bør stille, og hvordan du tjekker dem.

Hvad er WooCommerce hosting, og hvordan adskiller det sig fra et webhotel?

WooCommerce hosting er drift, der er sat op til webshops, ikke bare et standard-webhotel. WooCommerce og WordPress skaber tunge PHP- og databasekald i kurv, checkout og lagerstyring, så svag hosting giver langsomme sider, tabte ordrer og dårligere konvertering.

En almindelig firmaside kan ofte klare sig med beskedne ressourcer og aggressiv sidecache. En webshop kan ikke. Kurv, checkout, konto og lagerstatus er dynamiske elementer, som hele tiden ændrer sig. Hvis hostingen behandler webshoppen som en statisk side, får du hurtigt fejl, udløbne sessioner og forkerte priser.

Det er også derfor, at svartid på produktsider ikke er hele sandheden. En butik kan virke hurtig på forsiden og stadig være langsom der, hvor pengene tjenes. Tip: mål altid kategori, produktside, kurv og checkout hver for sig. Hvis checkout er langsom, hjælper en flot PageSpeed-score sjældent på omsætningen. Se langsom checkout i WooCommerce.

Krav 1: Hvilke serverkrav skal WooCommerce hosting opfylde?

Moderne WooCommerce hosting kræver aktuel PHP og en hurtig, understøttet database. WooCommerce anbefaler selv PHP 8.3 eller nyere (testet op til PHP 8.4), MySQL 8.0 eller nyere eller MariaDB 10.6 eller nyere, en PHP-hukommelsesgrænse på mindst 256 MB og HTTPS.

Vær opmærksom på, at MySQL 8.0 og MariaDB 10.6 begge har nået end of life i 2026. Kræv derfor en version, der stadig får sikkerhedsopdateringer, fx MySQL 8.4 LTS eller MariaDB 10.11 eller 11.4 LTS. Det samme gælder PHP: PHP 8.1 får ikke længere sikkerhedsrettelser, og PHP 8.2 får det kun til udgangen af 2026.

I praksis bør du se efter PHP-FPM eller LiteSpeeds PHP-håndtering, OPcache, InnoDB, Redis eller tilsvarende objektcache og NVMe-lager frem for ældre SSD. Hvis din shop har mange variationer, søgefiltre eller importer, bliver disk-I/O og CPU vigtigere end rå diskplads.

Miljøet bør mindst kunne følgende:

• PHP-version: 8.3 eller 8.4, så længe dine plugins understøtter det
• Database: MySQL 8.4 LTS eller MariaDB 10.11/11.4 LTS med InnoDB
• Hukommelsesgrænse: mindst 256 MB, ofte 512 MB eller mere til større shops
• Lagring: NVMe for høj IOPS ved produktkataloger og ordredata
• Webserver: LiteSpeed eller nginx med korrekt cachepolitik

En udbredt misforståelse er, at “ubegrænset trafik” alene betyder høj ydelse. Det gør det ikke. Hvis CPU, RAM og database er flaskehalsen, hjælper båndbredde meget lidt. Skal du opgradere PHP på en eksisterende shop, så test først i staging, se fejl efter PHP-opgradering.

Krav 2: Hvordan sammenligner du WooCommerce hosting-udbydere?

Den rigtige løsning afhænger af trafikmønster, supportbehov og hvor meget drift du vil håndtere selv. Når du sammenligner udbydere, så se på mere end prisen. Den laveste månedspris bliver ofte dyr, hvis checkout går ned under en kampagne.

Stil de samme spørgsmål til alle udbydere:

• Servertype og ressourcer: hvilken CPU, hvor meget RAM, og hvor mange PHP-processer har din shop til rådighed?
• Lager: NVMe eller ældre SSD, og er lageret samlet eller pr. site?
• Cache: hvilken sidecache og objektcache findes, og er kurv og checkout undtaget fra start?
• Backup: hvor ofte, hvor længe gemmes den, ligger der en kopi et andet sted, og kan du selv gendanne?
• Staging: kan du teste opdateringer på en kopi, før de går live?
• Datacenter: hvor står serverne, og er der en databehandleraftale?
• Support: åbningstider, sprog og om supporten forstår WooCommerce.
• Begrænsninger: står det tydeligt, hvad der sker, når du rammer en grænse?

Til mindre shops er administreret WooCommerce hosting oftest det enkleste valg. Til bureauer og større shops kan en VPS eller dedikeret server være rigtigt, hvis der også følger WooCommerce-kompetence og proaktiv drift med.

Hostious’ WooCommerce hosting kører på LiteSpeed-servere i Europa med NVMe-lager, daglig og manuel backup med selvbetjent gendannelse, gratis SSL, gratis migrering og dansk support døgnet rundt. Staging er med fra Woo StartUp.

Krav 3: Hvordan vurderer du CPU, RAM og NVMe trin for trin?

Du kan vurdere kapacitet systematisk. WooCommerce reagerer tydeligt på flaskehalse i CPU, RAM og disk, så tre enkle trin giver et bedre beslutningsgrundlag end planens markedsføringsnavn.

Trin 1: Kortlæg belastningen. Se på samtidige brugere, antal produkter, variationer, plugin-tung funktionalitet og spidsbelastninger. En butik med 5.000 produkter og facetteret søgning stiller helt andre krav end en butik med 50 produkter.

Trin 2: Mål de rigtige signaler. Kig på CPU-udnyttelse, hukommelsesforbrug, TTFB, database-svartid og disk-I/O under realistisk trafik. Hvis CPU topper, men disken er rolig, har du brug for flere kerner. Hvis query-tiderne stiger, er hurtig disk og databaseoptimering vigtigere.

Trin 3: Test under kampagnelignende forhold. Lav en belastningstest 2 til 4 uger før større udsalg. Tip: test ikke kun produktsider. Hvis checkout og AJAX-kald ikke indgår, får du et falsk grønt lys.

Langsomme databasekald kan du finde med Query Monitor, før du køber mere hardware.

Krav 4: Hvordan sætter du caching og database rigtigt op til WooCommerce?

Korrekt cacheopsætning gør WooCommerce hurtigt uden at ødelægge checkout. LiteSpeed Cache og Redis er gode eksempler, men kun når kurv, checkout og min konto er undtaget fra fuld sidecache.

Trin 1: Del siden op i trafik, der kan caches, og trafik, der ikke kan. Forside, kategorier og mange produktsider kan ofte caches. Kurv, checkout, konto og personaliserede dele må normalt ikke serveres som statiske sider.

Trin 2: Brug objektcache til databasearbejdet. Redis kan reducere belastningen fra gentagne forespørgsler på produkter, transients og indstillinger. Hvis du har mange filtre eller en stor variationstabel, giver objektcache ofte mere end aggressiv sidecache. Se object cache med Redis i LiteSpeed Cache.

Trin 3: Finjustér databasen. Sørg for en opdateret MariaDB eller MySQL, ryddet autoload-data, begrænset plugin-støj og løbende oprydning i revisioner og sessionsdata. Hvis antallet af plugins stiger, og svartiden følger med op, så mål query-volumen, før du køber mere hardware.

Mange tror, at mere cache altid er bedre. Det er forkert i e-handel. Forkert cache kan vise forkerte priser, gamle lagerstatusser eller en anden kundes kurv, og det er langt værre end en lidt lavere cache-hit-rate. Se kunder ser hinandens kurv og LiteSpeed Cache til WooCommerce.

Krav 5: Hvad er forskellen på delt hosting, VPS og dedikeret WooCommerce hosting?

Delt hosting er billigst, VPS er mest fleksibel, og dedikeret eller administreret WooCommerce hosting giver mere forudsigelig drift. Valget står ofte mellem lav pris nu og færre driftsproblemer senere.

På delt hosting deles CPU, RAM og I/O med mange andre kunder. Det kan fungere til små shops med lav trafik og få plugins. Ulempen er, at du sjældent styrer støjen fra naboerne på serveren, og at spidsbelastninger rammer hårdt.

En VPS giver mere kontrol og isolerede ressourcer. Den passer, hvis du har teknisk kompetence eller et bureau, der tager ansvar for drift, opdateringer og sikkerhed. Til gengæld ligger mere ansvar hos dig.

Dedikeret eller administreret WooCommerce hosting koster mere pr. måned, men du køber typisk hurtigere hardware, bedre isolation, support og et miljø, der er sat op til WordPress og WooCommerce fra start. Hvis omsætningen afhænger af en stabil checkout, er det ofte den mest rationelle model. Se også dedikeret WooCommerce server.

Krav 6: Hvordan planlægger du backup og gendannelse trin for trin?

Backup skal være regelmæssig og testet. Hostingpanelet kan automatisere meget, men målet er lavt datatab og hurtig gendannelse, ikke bare en flot tekst om “daglige backups”.

Trin 1: Fastlæg RPO og RTO, altså hvor meget data du højst må miste, og hvor hurtigt du skal være tilbage. Har du mange ordrer i timen, er én backup i døgnet ikke nok i sig selv. Så skal databasen sikres oftere, eller du skal have en fast procedure for at genskabe ordrer fra gatewayen og ordremails.

Trin 2: Tag kopier af både filer og database, gerne både på serveren og et andet sted. Hvis kun filerne kopieres, mangler ordrer og lagerhistorik. Hvis kun databasen gemmes, mangler mediefiler, temaer og uploadede dokumenter.

Trin 3: Test gendannelse i et stagingmiljø. En backup er først værdifuld, når den kan gendannes hurtigt og korrekt. En almindelig misforståelse er: “Vi har backup, så vi er sikre.” Hvis gendannelsen tager seks timer midt i en kampagne, er risikoen stadig høj. Se test din backup.

Det rigtige spørgsmål er derfor ikke, om der findes en backup, men hvor hurtigt du kan være tilbage i drift uden at miste nye ordrer.

Krav 7: Hvilke sikkerhedskrav skal WooCommerce hosting opfylde?

Sikker WooCommerce hosting kræver flere lag. TLS, firewall og malware-scanning er basiskrav, mens DDoS-beskyttelse, mindst mulige rettigheder og hurtig patching afgør, om små hændelser bliver til driftstab.

SSL er kun begyndelsen. Betalingsflow, login, kundedata og admin kræver HTTPS overalt, stramme adgangsregler og løbende opdateringer af WordPress, temaer og plugins. Hvis et betalingsplugin eller et SEO-plugin halter bagud, kan det blive den nemmeste vej ind.

De vigtigste kontrolpunkter ser typisk sådan ud:

• Netværk: firewall og DDoS-filtrering
• Applikation: malware-scanning og overvågning af sårbarheder
• Adgang: totrinslogin, stramme roller og begrænset admin-adgang
• Data: kryptering under overførsel, sikre backups og logning
• Drift: hurtige opdateringer, staging og mulighed for at rulle tilbage

Tip: spørg ikke kun “har I firewall?”. Spørg i stedet, hvordan de håndterer kompromitterede plugins, gendannelse, logopbevaring og alarm ved mistænkelig aktivitet. Det svar afslører, hvor moden driften er. Læs mere i webshop sikkerhed og løbende beskyttelse.

Krav 8: Hvordan skalerer WooCommerce hosting ved kampagner og trafikspidser?

Skalering kræver en plan, ikke held. Cloudflare, Redis og flere CPU-kerner kan hjælpe, men kun hvis checkout, database og baggrundsjob er tænkt ind, før kampagnen starter.

Vertikal skalering betyder mere CPU, RAM og hurtigere disk i samme miljø. Det er ofte den hurtigste løsning for små og mellemstore shops. Horisontal skalering betyder flere servere, load balancing eller database-replikaer, hvilket er stærkt, men også mere komplekst.

Hvis din butik primært sælger få varer med høj trafik på de samme sider, er CDN og sidecache meget effektive. Hvis du har mange personaliserede flows, store kataloger og tung søgning, flytter belastningen mod PHP-processer og database, og så hjælper caching alene mindre.

Tommelfingerreglen er enkel: kører du kampagner, nyhedsbreve eller annoncer med forventet trafikspids, så aftal kapacitet med din udbyder på forhånd. Ingen hosting kan kompensere for manglende planlægning. Se kapacitetsplanlægning før en kampagne.

Krav 9: Hvad skal du kræve af support, overvågning og GDPR?

Support, overvågning og GDPR er driftskrav, ikke pynt. Hosting i EU giver gode rammer, men du skal stadig kræve hjælp døgnet rundt, klare alarmer og en tydelig databehandleraftale.

Supporten skal kunne mere end at genstarte en server. Den skal forstå WooCommerce, plugin-konflikter, betalingsgateways, cachefejl og flaskehalse. Hvis svaret på et checkout-problem hver gang er “kontakt din udvikler”, er det ikke WooCommerce-hosting.

Overvågning bør dække oppetid, CPU, RAM, disk, SSL, svartider og fejlmønstre i logs. En oppetidsgaranti er en god start, men vigtigere er, hvor hurtigt nogen reagerer, når en alarm går. Tip: bed om at få forklaret eskalationsvejen, ikke kun supportens åbningstider. Se hvad er uptime garanti på hosting?

På GDPR-siden bør du se efter hosting i EU, databehandleraftale, backuppolitik, logning og klare processer for sletning og adgangskontrol. Hvis målgruppen er dansk eller europæisk, giver servere i Europa kort afstand til kunderne og en enklere vurdering af dataoverførsler. Se, hvad du skal tjekke i databehandleraftalen med dit hostingfirma.

Krav 10: Hvordan sikrer du betalingsgateway og webhooks mod tabte ordrer?

En webshop kan være online og stadig miste salg, hvis betalingslaget svigter. Driftssikkerhed handler derfor ikke kun om oppetid, men om at ordrer bliver afviklet korrekt hele vejen fra betaling til ordrebekræftelse.

Mange betalingsfejl opstår ikke i selve checkout, men i kommunikationen bagefter. Kunden betaler, gatewayen registrerer transaktionen, men webshoppen får aldrig korrekt besked retur via webhook eller callback. Resultatet er ordrer, der hænger i “afventer betaling”, dobbelte betalingsforsøg og manuelle supportsager, som kunne være undgået.

Derfor bør du teste hele kæden, hver gang miljøet ændrer sig. Det gælder ved migrering, domæneskift, nye SSL-certifikater og større pluginopdateringer. Test ikke kun betalingsknappen, men betaling, ordrestatus, kundemail og lageropdatering i et sikkert testmiljø.

Hold øje med disse faresignaler i den daglige drift:

• Mange ordrer i afventende status
• Uforklarlige dubletter af ordrer
• Manglende ordrebekræftelser til kunderne
• Webhook-fejl i logs
• Kunder, der melder om betalt, men ikke registreret ordre

Har du mange ordrer, bør du også bruge HPOS (High-Performance Order Storage) i WooCommerce. Ordredata ligger så i deres egne tabeller, så ordresøgning og ordrelister belaster databasen mindre end den klassiske lagring i posts-tabellen. HPOS er standard på nye butikker, men ældre butikker skal selv skifte. Se også ordrer, der står som ‘Afventer betaling’.

Hvordan gendanner du efter en fejl uden at miste nye ordrer?

Backup er ikke kun filer og database. I en webshop skal du også tænke betalingsreferencer, planlagte jobs og selve gendannelsesprocessen ind, ellers kan en gendannelse skabe nye problemer, mens den løser de gamle.

Det klassiske scenarie: en fuld gendannelse fra nattens backup overskriver de ordrer, der er kommet ind siden. Teknisk set er gendannelsen vellykket, forretningsmæssigt er den et tab. Skeln derfor mellem backupfrekvens og gendannelseskvalitet. Hyppige databasebackups begrænser tabet, men det er metoden ved gendannelse, der afgør, om du mister salg.

Område	Hvorfor det er kritisk	God praksis
Database	Ordrer, kunder, ordrestatus og transaktionsnære data	Hyppige backups og testet gendannelse
Filer	Temaer, plugins, uploads og konfiguration	Automatisk filbackup og versionsstyring ved udvikling
Betalingsdata	Webhooks, tokens og referencer kan blive usammenhængende efter fejl	Afstemning mod gatewayens dashboard efter hændelser
E-mails og cron-jobs	Planlagte processer kan stå stille uden synlig fejl	Overvågning af cron og køer
Gendannelsesproces	Utestet gendannelse giver høj risiko under pres	Dokumenteret drejebog og faste øvelser

Når skaden er sket, bør gendannelsen følge en fast rækkefølge:

1. Sæt butikken i vedligeholdelsestilstand, hvis der er risiko for nye, inkonsistente ordrer.
2. Afgræns problemet: ligger fejlen i filer, database eller en integration?
3. Gendan så snævert som muligt, fx kun temaet eller et enkelt plugin, frem for en ukritisk fuld gendannelse.
4. Afstem ordrer og betalinger mod gatewayens eget dashboard.
5. Test checkout, ordremails, lager og webhook-flow, før du åbner for normal handel igen.

Validér desuden hver gendannelsestest i staging ved at kontrollere ordrer, produkter og betalingsflow, ikke kun at forsiden vises. Vil du sammenligne værktøjer, så se gennemgangen af backupløsninger til webshops og guiden om at gendanne fra backup uden at miste nye ordrer.

Hvilken opdaterings- og overvågningsrutine holder shoppen stabil i hverdagen?

De fleste driftsproblemer i WooCommerce starter småt. En pluginopdatering ændrer checkout-flowet, databasen bliver langsommere måned for måned, et certifikat udløber, eller en produktimport kører skævt. Ingen af delene udløser nødvendigvis en alarm om nedetid, men alle koster salg, hvis de får lov at ligge.

Derfor bør overvågningen række ud over oppetid og serverressourcer. Overvåg specifikt kurv, checkout og betalingsflow, hold øje med uventede filændringer, og kontrollér, at WP-Cron og Action Scheduler faktisk afvikler deres opgaver. Forsinkede cron-jobs rammer ordremails, abonnementsfornyelser, lagersynkronisering og eksterne integrationer, ofte uden synlige fejl på sitet. Se forfaldne planlagte handlinger i WooCommerce.

Opdateringer er det andet klassiske risikoområde. En moden rutine ser typisk sådan ud:

• Staging først: test checkout, lager, mails og integrationer i staging, før ændringen går live
• Backup før ændring: både filer og database skal kunne rulles tilbage
• Udrulning uden for spidsbelastning: læg ændringer, når risikoen for tabt salg er lavest
• Validering efter udrulning: gennemfør en rigtig testordre, ikke kun en sidevisning
• Loggennemgang: tjek fejl i PHP, gateway, cron og API-kald med det samme

Er du i tvivl, om din nuværende drift er moden nok, så kig efter de typiske tegn: langsom checkout, når butikken er presset, usikkerhed om hvornår der sidst blev taget en brugbar backup, og for meget tid brugt på brandslukning med plugins og fejl. Flere kampagner, højere trafik og krav om sikkerhedsdokumentation trækker i samme retning. Se også 7 tegn på, at din webshop mangler bedre hosting.

Vil du have rutinerne bygget ind i platformen frem for at vedligeholde dem manuelt, giver Hostious’ WooCommerce hosting daglig og manuel backup og dansk support døgnet rundt i alle planer fra Woo Mini til 59 kr./md. ekskl. moms. Fra Woo StartUp til 239 kr./md. får du også staging og WooCommerce serviceaftalen, hvor opdateringer og vedligeholdelse er med.

Læs også

• Hub: WooCommerce-fejlfinding – guides til de typiske fejl i en WooCommerce-butik
• 7 tegn på at din webshop mangler bedre hosting
• Langsom checkout i WooCommerce: fra „Afgiv ordre“ til kvittering
• WooCommerce migrering uden tab af salg
• WooCommerce hosting hos Hostious – LiteSpeed, NVMe og staging fra Woo StartUp

Ofte stillede spørgsmål om krav til WooCommerce hosting

Hvorfor kan jeg ikke bare bruge et billigt webhotel til WooCommerce?

Fordi en webshop laver langt flere dynamiske databasekald end en almindelig side. Kurv, lager og betaling kan ikke caches, så uden CPU, RAM og hurtig disk bliver netop købsflowet det langsomste led.

Hvilken PHP- og databaseopsætning bør jeg kræve?

PHP 8.3 eller 8.4 med tilstrækkeligt mange PHP-processer, en understøttet MySQL- eller MariaDB-version med InnoDB, objektcache som Redis og NVMe-lager. Det er den kombination, der holder svartiden nede under samtidige ordrer.

Hvordan tester jeg min WooCommerce hosting før Black Friday?

Kør en belastningstest mod en kopi i staging med realistiske kurv- og checkout-flows, og mål TTFB under pres. Stiger svartiden voldsomt ved få samtidige brugere, er platformen for lille.

Hvor ofte skal en webshop tage backup?

Mindst dagligt, og oftere hvis du har mange ordrer i døgnet. Lige så vigtigt er det, at du har testet gendannelsen og har en plan for de ordrer, der kommer ind mellem backup og fejl.