7 WordPress problemer fra dårlig hosting

Kort svar: De syv WordPress problemer, der oftest skyldes dårlig hosting, er langsom wp-admin, ujævn frontend, memory exhaustion, importfejl, forsinkede WP-Cron-opgaver, 502 Bad Gateway og 503-fejl. Fælles for dem er, at de rammer bredt og især under belastning – ikke kun én bestemt funktion. Kig på mønstret og i logfilerne, før du skifter plugins ud, og vælg næste hosting ud fra ressourcer, cron, logadgang og support.

Fagligt gennemgået: 2. oktober 2026

Når en WordPress-side bliver ustabil, tænker mange først på plugins, temaer eller opdateringer. Det er ofte relevant, men hosting er mindst lige så tit den skjulte årsag. Dårlig hosting viser sig nemlig sjældent kun som “en lidt langsom hjemmeside”. Den viser sig som konkrete fejl i drift, administration og automatisering.

Det gør forskellen vigtig. En WordPress-installation kan være teknisk korrekt sat op og stadig føles tung, fejle ved import, springe planlagte opgaver over eller give 502- og 503-fejl, hvis servermiljøet er presset eller begrænset forkert. Den gode nyhed er, at mønstrene som regel er tydelige, når du ved, hvad du skal kigge efter.

Hvorfor dårlig WordPress hosting giver konkrete fejl

WordPress er afhængig af mere end diskplads og et domæne. Platformen bruger PHP, database, cache, filsystem, cron-opgaver og ofte mange plugins, som alle stiller krav til serverens ressourcer og opsætning. Når en host sætter lave grænser for hukommelse, CPU, uploadstørrelse eller kørselstid, begynder problemerne at vise sig på præcise steder.

Det betyder også, at “langsom hosting” er en upræcis diagnose. I praksis møder man et mere genkendeligt sæt symptomer: trægt kontrolpanel, afbrudte imports, forsinkede planlagte indlæg, ustabile checkout-forløb og serverfejl ved spidsbelastning. I WordPress’ egne supportfora bliver hostingmiljøet jævnligt peget ud som årsag, når fejl som uploadgrænser, 503-fejl og memory exhaustion dukker op.

WordPress-problem	Typisk hostingårsag	Synligt symptom
1. Langsom administration	For få serverressourcer, langsom database, svag cache	Træg wp-admin og lange svartider
2. Langsom frontend	Delt server med høj belastning, dårlig PHP-performance	Sider loader ujævnt eller langsomt
3. Memory exhaustion	For lav PHP memory limit	Hvide sider, fatale fejl, pluginfejl
4. Importfejl	Lav uploadgrænse eller timeout	Store filer kan ikke importeres
5. Forsinket WP-Cron	Ingen rigtig system-cron, lav trafik	Planlagte opgaver kører for sent
6. 502 Bad Gateway	Server- eller gatewayfejl mellem webserver og PHP	Siden er utilgængelig i perioder
7. 503-fejl	Overbelastning eller host-relateret driftsproblem	Midlertidig nedetid under belastning

Det er præcis derfor, valget af hosting har direkte betydning for, hvor stabilt WordPress arbejder i hverdagen.

1. Langsom WordPress administration og lange svartider

Et af de første tegn er et tungt kontrolpanel. Når wp-admin føles langsom, handler det ikke kun om brugeroplevelse. Det er et signal om, at serveren kæmper med forespørgsler, databasekald eller PHP-processer. Hver gang en side i administrationen åbnes, skal WordPress hente data, køre pluginlogik og opdatere brugerfladen. Hvis hostingmiljøet er underdimensioneret, bliver selv simple opgaver langsomme.

Det rammer især sider med mange plugins, mange sider, mange produkter eller et aktivt WooCommerce-setup. Og bemærk: et CDN løser ikke dette alene. Et CDN kan hjælpe besøgende på frontend, men det gør meget lidt for et langsomt kontrolpanel eller en database, der halter.

Typiske tegn kommer ofte snigende, før siden bryder helt sammen:

• Langsomt login til wp-admin
• Tunge indlæsninger af sider og indlæg
• Ventetid ved gem, opdater og publicér
• Forsinkede pluginopdateringer
• Ujævne svartider i WooCommerce-ordrer

Hvis administrationen er tung hver dag, er det sjældent bare “sådan er WordPress”. Det er oftest et hostingproblem eller en kombination af hosting og belastning. Læs også om langsomt wp-admin, hvis du vil udelukke heartbeat, autoload og plugins først.

2. Langsom og ujævn frontend under belastning

Frontenden er det, dine besøgende mærker. På en presset delt server kan samme side loade hurtigt det ene øjeblik og langsomt det næste, fordi andre kunder på serveren bruger CPU og disk samtidig. Det giver ujævne målinger, som er svære at forklare ud fra dit eget site.

Det tydeligste tegn er en høj TTFB (time to first byte) på sider, der ikke kommer fra cache. Hvis forsiden er hurtig, når den er cachet, men produktsider, søgning og kurv er langsomme, er det PHP og database, der ikke får ressourcer nok. Se guiden til høj TTFB i WordPress for, hvordan du skiller cache, PHP og database ad.

Page cache dækker meget, men den kan ikke dække alt. Loggede brugere, kurv, checkout og søgning skal altid beregnes af serveren, og her er det serverens rå kapacitet, der afgør oplevelsen.

3. Memory exhaustion i WordPress ved plugins og WooCommerce

Memory exhaustion er blandt de mest klassiske WordPress-fejl på svag hosting. Den opstår, når PHP får lov til at bruge mindre hukommelse, end processen faktisk kræver. Resultatet kan være en fatal fejl, en blank side eller en funktion, der bare stopper midt i arbejdet.

Det sker ofte ved backup-plugins, importværktøjer, sidebyggere, store produktkataloger og tunge WooCommerce-processer. Jo mere data WordPress skal bearbejde i én kørsel, desto større er risikoen. På et billigt eller hårdt begrænset webhotel er der tit sat lave memory limits, og så skal der ikke meget til, før grænsen rammes.

Problemet bliver tit misforstået som et rent pluginproblem. Plugins kan naturligvis være tunge, men hvis et normalt vedligeholdt site konstant rammer hukommelsesgrænsen, er det relevant at se på servermiljøet. En stærkere WordPress-hosting med mere generøs PHP-hukommelse og bedre processtyring giver ofte mærkbar forskel med det samme.

Du kan se den aktuelle grænse under Værktøjer → Webstedets helbred → Info → Server (PHP memory limit). Bemærk, at WP_MEMORY_LIMIT i wp-config.php ikke kan hæve grænsen ud over det, serveren tillader. Fejlen og løsningerne er gennemgået i guiden til Allowed memory size exhausted.

4. Importfejl i WordPress på grund af uploadgrænse og timeouts

Import af indhold, produkter, billeder eller komplette site-pakker er en anden klassiker. Når importen fejler, er årsagen ofte ikke selve filen, men serverens grænser.

De typiske flaskehalse er uploadstørrelse (upload_max_filesize og post_max_size), maksimal kørselstid (max_execution_time) og tilgængelig hukommelse. Hvis en import skal behandle store mængder data, men serveren lukker processen efter kort tid, får du enten en tydelig fejl eller en import, der hænger uden forklaring. For webshops er det særligt dyrt, fordi produktdata, variationer og billeder ofte er tunge.

Derfor er importfejl ikke bare et irritationsmoment ved opstart eller flytning. De er et tegn på, at hostingmiljøet er for snævert til den faktiske brug. Det gælder også, når et site skal flyttes, genskabes fra backup eller bygges op i staging. Se også 413 Request Entity Too Large og Maximum execution time exceeded.

5. Forsinkede planlagte opgaver i WordPress med WP-Cron

WordPress bruger WP-Cron til tidsstyrede opgaver. Det dækker blandt andet kontrol af opdateringer, planlagte indlæg og jobs fra plugins. Det særlige er, at WP-Cron ikke kører konstant som et klassisk system-cronjob. Det bliver udløst af sidevisninger.

Det er en smart løsning på mange typer hosting, men den har en klar svaghed. Hvis sitet har lav trafik, eller hvis servermiljøet er presset, kan tidsstyrede opgaver blive forsinkede. WordPress’ egen dokumentation nævner, at mange delte hostingmiljøer ikke giver adgang til en rigtig system-scheduler, og så bliver WP-Cron mere sårbar.

Resultatet er ofte mærkelig adfærd, som ikke straks ligner hostingfejl:

• Planlagte indlæg: publiceres minutter eller timer for sent
• WooCommerce-opgaver: lageropdateringer, abonnementer eller oprydningsjobs kører ujævnt
• E-mails: udsendes først, når nogen besøger sitet
• Backup-plugins: planlagte kørsler springes over

Når kritiske processer afhænger af sidevisninger, er stabilitet svær at sikre. Løsningen er at sætte define('DISABLE_WP_CRON', true); i wp-config.php og lade en system-cron kalde wp-cron.php med fast interval. Det kræver, at hosten giver adgang til rigtige cronjobs. Fremgangsmåden står i guiden til cron uden wp-cron-fælder.

6. 502 Bad Gateway fra servermiljøet

Nogle fejl er så tydelige, at de straks peger mod serveren. 502 Bad Gateway er et godt eksempel. Fejlen betyder, at en server i kæden, typisk webserveren eller en proxy, ikke fik et gyldigt svar fra det næste led, ofte PHP. Det er med andre ord sjældent et enkelt indlæg, der er gået galt.

Typiske årsager er PHP-processer, der bliver dræbt eller hænger, for få PHP workers til antallet af samtidige requests, eller en proxy som Cloudflare, der ikke kan få kontakt til serveren. Når fejlen kommer i perioder med meget trafik, er kapaciteten det første sted at kigge.

7. 503-fejl og midlertidig nedetid under belastning

503-fejl ligger i samme kategori. I WordPress.org-supporten bliver det ofte fremhævet, at 503-fejl kommer fra hostingmiljøet, og at man derfor bør tage fat i hostens support. Det kan skyldes overbelastning, ressourcegrænser på kontoen, processer der bliver dræbt, eller fejl i serverstakken.

En undtagelse er, når WordPress selv sætter sitet i vedligeholdelsestilstand under en opdatering. Hænger beskeden fast, skyldes det ofte en afbrudt opdatering, ikke hosten. Se WordPress sidder fast i vedligeholdelsestilstand.

Når fejlene optræder sporadisk, bliver de tit overset. Brugeren genindlæser siden, og alt virker igen. Men sporadiske serverfejl er stadig driftsfejl. De skader tillid, statistik, salg og SEO, især hvis de rammer checkout, login eller kampagnesider. Både 502 og 503 peger mod et miljø, der ikke leverer stabil drift under den belastning, sitet skaber.

Sådan vurderer du, om din WordPress hosting er flaskehalsen

Det første skridt er at se på mønstret, ikke på enkeltstående hændelser. Hvis sitet er langsomt efter hver opdatering, ved hver import eller i travle perioder, tyder det på kapacitetsproblemer. Hvis det kun fejler ved én bestemt funktion, kan det være et pluginproblem, men hosting skal stadig undersøges.

Logfiler er guld værd her. PHP-fejl, memory exhaustion, gatewayfejl og timeouts efterlader ofte tydelige spor. En moden hostingløsning bør give adgang til relevante logs eller kunne hjælpe med at læse dem. Hvis supporten kun svarer med generelle råd uden at se på serverdata, går man ofte i ring. Guiden til loglæsning for ikke-teknikere viser, hvad du skal kigge efter.

Det kan også betale sig at teste realistisk. Et lille visitkortsite og en WooCommerce-butik har helt forskellige krav. Det samme gælder et bureau-site med staging, et nyhedssite med trafikspidser og en medlemsplatform med mange loggede brugere. WordPress er fleksibelt, men hostingen skal passe til belastningen.

Når du vurderer en mulig flytning, er disse spørgsmål nyttige:

• Spørg om: PHP memory limit, CPU/RAM og grænser for samtidige processer
• Undersøg: om der er adgang til system-cron eller en stabil løsning for WP-Cron
• Kræv: hurtige backups, staging og let adgang til logs
• Vurdér: kvaliteten af supporten ved 502-, 503- og timeoutfejl

Det kan du gøre, før du skifter host

Ikke alle problemer kræver en flytning. Prøv disse skridt først, så du ved, om problemet sidder i sitet eller i serveren:

1. Opdatér til en understøttet PHP-version, fx 8.3 eller 8.4, efter test på staging.
2. Find tunge plugins og langsomme databasekald, fx med Query Monitor, og fjern det, du ikke bruger.
3. Aktivér page cache og, hvis hosten understøtter det, en object cache som Redis.
4. Flyt WP-Cron til en system-cron, så planlagte opgaver ikke afhænger af trafik.
5. Bed hosten om at hæve PHP-grænserne, eller spørg, hvad grænserne faktisk er.

Bliver symptomerne ved, selv om sitet er ryddet op, er det et stærkt tegn på, at miljøet er for lille eller overbelastet.

Hvad du bør kræve af WordPress hosting før en flytning

Hvis et site allerede viser tegn på dårlig hosting, bør næste løsning vælges ud fra drift og ikke kun pris. Kig efter et setup, der kan håndtere både daglig brug og spidsbelastning. Det gælder særligt for WooCommerce, bureauer og virksomheder, der er afhængige af, at administration, ordreflow og planlagte opgaver fungerer hver dag.

Her bliver forskellen mellem et generisk webhotel og administreret WordPress-hosting tydelig. En udbyder, der arbejder målrettet med WordPress, vil typisk have bedre cachelag, en hurtigere PHP-stack, mere brugbare sikkerheds- og backup-rutiner og support, der kan se sammenhængen mellem pluginadfærd og servergrænser.

Et stærkt setup vil ofte rumme hurtig serverteknologi, effektiv cache, gratis SSL, staging, hyppige backups og support, der kan reagere døgnet rundt. Hos Hostious kører WordPress hosting på servere i Europa med LiteSpeed og NVMe, daglig og manuel backup med selvbetjent gendannelse, gratis SSL, gratis migrering og dansk support døgnet rundt. Fra WP StartUp får du også staging og understøttelse af Redis object cache.

Det vigtigste er dog enkelt: Hvis WordPress kæmper med hukommelse, importgrænser, cron-opgaver eller serverfejl, er det sjældent nok at optimere lidt i overfladen. Når fundamentet bliver stærkere, bliver resten af sitet markant lettere at drive.

Læs også

• Hub: WordPress fejlfinding – alle fejlguides samlet ét sted
• Allowed memory size exhausted i WordPress
• wp-cron virker ikke: planlagte opgaver kører aldrig
• 504 Gateway Timeout i WordPress — hvad der tager for lang tid
• 7 tegn på at du har brug for premium WP hosting
• WordPress hosting hos Hostious – LiteSpeed, NVMe og dansk support døgnet rundt

Ofte stillede spørgsmål om hosting-relaterede WordPress problemer

Hvordan ved jeg, om et WordPress problem skyldes hostingen?

Test mønsteret: rammer fejlen bredt (admin, imports, cron, spidsbelastning) frem for én funktion, og forsvinder den i et stærkere miljø, peger pilen på serveren – ikke på dine plugins.

Hvad betyder PHP workers, og hvorfor er de vigtige?

De afgør, hvor mange samtidige ucachede requests serveren kan behandle. For få workers giver kødannelse, langsom admin og 502-fejl – præcis de symptomer, man tit fejlfinder alle andre steder først.

Kan jeg løse problemerne uden at skifte host?

Nogle gange: ryd op i tunge plugins, aktivér object cache, flyt WP-Cron til en rigtig cron, og bed hosten hæve PHP-grænserne, hvor det er muligt. Men er serveren grundlæggende overbelastet, er en flytning den eneste varige løsning.

Hvorfor bliver mine planlagte indlæg publiceret for sent?

WP-Cron kører kun, når nogen besøger sitet. Har sitet lav trafik, eller er serveren presset, bliver opgaverne forsinket. Løsningen er at slå den indbyggede trigger fra og lade en system-cron kalde wp-cron.php fast, fx hvert femte minut.