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. Emnet er vigtigt, fordi en webshop ikke opfører sig som en almindelig hjemmeside: lageropslag, betalingsmoduler, rabatter og produktfiltre skaber mange dynamiske databasekald. Det primære problem, den rigtige hosting løser, er tabt omsætning fra langsom svartid, fejl i checkout og nedbrud under kampagner. Når driften er bygget korrekt, bliver højere konvertering og færre driftsafbrydelser en naturlig følge.
WooCommerce hosting er specialiseret drift, 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 sessions og misvisende 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. Pro 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.
Moderne WooCommerce hosting kræver aktuel PHP og hurtig database. PHP 8.2 og MariaDB 10.6 er stærke pejlemærker, mens NVMe, flere CPU-kerner og mindst 512 MB PHP memory limit ofte er det praktiske niveau for seriøse shops.
WooCommerce anbefaler HTTPS og opdaterede versioner af PHP og database. I praksis bør du se efter PHP-FPM, OPcache, InnoDB, Redis eller tilsvarende objektcache og disk på NVMe frem for ældre SSD. Hvis din shop har mange variationer, søgefiltre eller importer, bliver disk-I/O og CPU vigtigere end rå diskplads.
Efter de fleste driftsstandarder bør miljøet mindst kunne følgende:
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.
De stærkeste løsninger kombinerer WooCommerce-viden med hurtig infrastruktur. Hostious.io, Kinsta og SiteGround er relevante benchmarks, men 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 pris. Kig på servertype, cacheopsætning, backupfrekvens, datacenterplacering, supportens åbningstid og hvor tydeligt de beskriver begrænsninger. Billigste månedpris bliver ofte dyrest, hvis checkout går ned under kampagner.
Du kan vurdere kapacitet systematisk. WooCommerce og Redis reagerer tydeligt på flaskehalse i CPU, RAM og disk, så tre enkle målinger giver et langt 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, memory pressure, TTFB, database-responstid og disk-I/O under realistisk trafik. Hvis CPU topper, men disk er rolig, har du brug for flere kerner. Hvis query-tider stiger, er NVMe og databaseoptimering vigtigere.
Trin 3: Test under kampagne-lignende forhold. Lav en belastningstest 2 til 4 uger før større udsalg. Pro tip: test ikke kun produktsider. Hvis checkouts og AJAX-kald ikke indgår, får du et falsk grønt lys.
Korrekt cacheopsætning gør WooCommerce hurtigt uden at ødelægge checkout. LiteSpeed og Redis er stærke eksempler, men kun når kurv, checkout og “min konto” er undtaget fra fuld sidecache.
Trin 1: Del siden op i cachebar og ikke-cachebar trafik. Forside, kategorier og mange produktsider kan ofte cachelagres. 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 sessions. Hvis du har mange filtre eller en stor variationstabel, giver objektcache ofte more end aggressiv sidecache.
Trin 3: Finjustér databasen. Sørg for opdateret MariaDB eller MySQL, ryddet autoload-data, begrænset plugin-støj og løbende oprydning i revisions- og sessionsdata. Hvis antallet af plugins stiger, og svartiden følger med op, skal du måle 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.
Delt hosting er billigst, VPS er mest fleksibel, og dedikeret eller stærkt managed WooCommerce hosting giver mest 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øjniveauet fra naboer på serveren, og at spidsbelastninger rammer hårdt.
En VPS giver mere kontrol og isolerede ressourcer. Den er velegnet, 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 managed WooCommerce hosting koster mere pr. måned, men du køber typisk hurtigere hardware, stærkere isolation, bedre support og et miljø, der er sat op til WordPress og WooCommerce fra start. Hvis omsætning er afhængig af stabil checkout, er det ofte den mest rationelle model.
Backup skal være hyppig og testet. WooCommerce og Plesk 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. Hvis du mister ordrer hver time, er daglig backup for lidt. Mange shops bør have backups mindst flere gange dagligt, og ved høj ordrevolumen er 2-timers backup et stærkere niveau.
Trin 2: Tag kopier af både filer og database, gerne on-site og off-site. Hvis kun filer kopieres, mangler ordrer og lagerhistorik. Hvis kun database gemmes, mangler mediefiler, temaer og uploadede dokumenter.
Trin 3: Test restore i et stagingmiljø. En backup er først værdifuld, når den kan gendannes hurtigt og korrekt. Almindelig misforståelse: “Vi har backup, så vi er sikre.” Hvis restore tager seks timer midt i en kampagne, er risikoen stadig høj.
Det rigtige spørgsmål er derfor ikke, om backup findes, men hvor hurtigt du kan være tilbage i drift uden at miste nye ordrer.
Sikker WooCommerce hosting kræver flere lag. TLS, firewall og malware-scanning er basiskrav, mens DDoS-beskyttelse, mindst privilegium og hurtig patching afgør, om små hændelser bliver til driftstab.
SSL er kun begyndelsen. Betalingsflows, login, kundedata og admin kræver konsekvent HTTPS, stærke adgangsregler og løbende opdateringer af WordPress, temaer og plugins. Hvis et betalingsplugin eller et SEO-plugin halter bagud, kan det blive den hurtigste vej ind.
De vigtigste kontrolpunkter ser typisk sådan ud:
Pro tip: spørg ikke kun “har I firewall?”. Spørg i stedet, hvordan de håndterer kompromitterede plugins, restore, logbevaring og alarm ved mistænkelig aktivitet. Det svar afslører driftens modenhed.
Skalering kræver 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 på samme miljø. Det er ofte den hurtigste løsning for små og mellemstore shops. Horisontal skalering betyder flere noder, load balancing eller read-replicas, 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 page cache meget effektive. Hvis du har mange personaliserede flows, store kataloger og tung søgning, flytter belastningen mod PHP-workers og database, og så hjælper caching alene mindre.
En praktisk tommelfingerregel er enkel: Hvis du kører kampagner, nyhedsbreve eller annoncer med forventet trafikspids, så aftal kapacitetsløft på forhånd. Den bedste host kan ikke kompensere for nul planlægning.
Support, overvågning og GDPR er driftskrav, ikke pynt. Danmark og EU er stærke rammer, men du skal stadig kræve 24/7 hjælp, klare alarmer og en tydelig databehandleraftale.
Supporten skal kunne mere end at genstarte en server. Den skal forstå WooCommerce, plugin-konflikter, betalingsgateways, cachefejl og performance-flaskehalse. Hvis svaret på et checkout-problem er “kontakt din udvikler” hver gang, er det ikke specialiseret hosting.
Overvågning bør dække oppetid, CPU, RAM, disk, SSL, svartider og fejlmønstre i logs. En oppetidsgaranti på 99,9 procent er et minimum i mange miljøer, men vigtigere er, hvor hurtigt nogen reagerer, når alarmer går. Pro tip: bed om at få forklaret eskalationsvejen, ikke kun supportens åbningstider.
På GDPR-siden bør du se efter EU-hosting, databehandleraftale, backup-politik, logning og klare processer for sletning og adgangskontrol. Hvis målgruppen er dansk eller europæisk, giver lokal hosting ofte lavere latenstid og enklere compliance. Her er danske miljøer med dokumenteret GDPR-fokus, som Hostious.io, naturligt lettere at vurdere end mere uklare internationale setups.
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.
De fleste betalingsfejl opstår ikke i selve checkout-vinduet, 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:
Har du mange ordrer, bør du også aktivere HPOS (High-Performance Order Storage) i WooCommerce. Ordredata flyttes til dedikerede tabeller, så ordresøgning og ordrelister belaster databasen mindre end den klassiske lagring i posts-tabellen.
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 restore skabe nye problemer, mens den løser de gamle.
Det klassiske scenarie: en fuld restore 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 restorekvalitet. 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 restore |
| 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 |
| Restore-proces | Utestet gendannelse giver høj risiko under pres | Dokumenteret runbook og faste øvelser |
Når skaden er sket, bør gendannelsen følge en fast rækkefølge:
Validér desuden hver restore-test 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.
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 i frontend.
Opdateringer er det andet klassiske risikoområde. En moden rutine ser typisk sådan ud:
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.
Her er et miljø med daglig backup, staging og dansk support døgnet rundt, som Hostious’ WooCommerce hosting fra 239 kr./md., ofte den enkleste vej til at få rutinerne bygget ind i platformen frem for at vedligeholde dem manuelt.
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.
PHP 8.1+ med tilstrækkelige workers, MariaDB eller MySQL med InnoDB, objekt-cache som Redis og NVMe-lager. Det er den kombination, der holder svartiden nede under samtidige ordrer.
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.
