WordPress vs. Payload CMS: Beslutningskriterier for projekter

Du kender måske øjeblikket: Hjemmesiden „fungerer“ – indtil den pludselig ikke gør. Ikke fordi den er nede, men fordi den bremser teamet. En lille indholdsopdatering bliver til en kø af billetter, en plugin-opdatering til en nervepirrende oplevelse, nye landingssider føles som copy & paste. Og på et tidspunkt spørger man sig selv: „Skal vi skifte systemet?“

I vores projekter er det sjældent en rent teknisk diskussion. Det er en organisationsspørgsmål. Hvem må offentliggøre indhold? Hvem har ansvar for opdateringer? Hvad sker der, hvis personen, der „kan WordPress“, forlader virksomheden? Og hvor hurtigt skal du egentlig kunne reagere, hvis tilbud, støtteordninger eller kampagner ændrer sig?

Vores Perspektiv: Konflikt mellem Fleksibilitet og Kompleksitet

Vi ser ofte et typisk vækstpres: Først er hjemmesiden et udstillingsvindue, så bliver det et arbejdsredskab. Den skal skaffe leads, indsamle ansøgninger, vise begivenheder, levere indhold på flere sprog, måske endda kobles på en app eller et medlemsområde. Senest der bliver CMS til driftsystemet for din kommunikation.

Her kommer vores første heuristik i spil, som vi internt kalder „Tre-spørgsmåls-tjek“. Hvis du svarer ja til alle tre spørgsmål, er det værd at overveje Payload seriøst – uanset hvor godt WordPress føles lige nu: 1) Skal indhold ende i mere end en kanal (hjemmeside, app, nyhedsbrev, portal)? 2) Er der klare godkendelser og roller, som I virkelig lever efter? 3) Er jeres hjemmeside mere produkt end kampagne, altså langsigtet videreudvikle?

Hvis et lille team derimod hurtigt vil publicere, indhold forbliver primært på hjemmesiden, og du har brug for et robust, velkendt økosystem, er WordPress ofte det pragmatiske svar. Ikke „fordi alle bruger det“, men fordi drift og redaktionsrealitet passer sammen.

Og der bliver sammenligningen relevant: ikke i maskinrummet, men i hverdagen.

Der er en grund til, at WordPress så ofte er på bordet: Du får hurtigt noget live, redaktører finder intuitivt rundt, og til næsten enhver krav findes der en plugin. I praksis betyder det: Hvis du driver en klassisk hjemmeside med sider, blog, formularer og et overskueligt team, kan WordPress være et meget solidt hjem.

Hvor WordPress er stærk

Vi oplever WordPress som særlig nyttig, når organisationen har en klar kommunikationsrytme: Indhold bliver planlagt, offentliggjort, sjældent „videregivet til systemer“. Et godt setup med rent tema, reduceret plugin-sæt og klare roller kan bære i årevis. Og ja: WordPress kan være hurtig – men det er et spørgsmål om disciplin. Ydeevne skabes her ikke automatisk, men gennem beslutninger: Billedstørrelser, caching, blok-overhead, unødvendige scripts.

Hvor det tipper

Grænsen viser sig ofte ikke i frontend, men i afhængighederne. WordPress-projekter bliver hurtigt til „plugin-landskaber“. Det føles i starten som fleksibilitet, men bliver senere governance: Hvilke plugins er kritiske? Hvem tester opdateringer? Hvad er planen, hvis et plugin ikke længere vedligeholdes?

Vores anden heuristik kalder vi „Plugin-gæld-indeks“. Ikke som Excel-værktøj, men som samtale: Hvis mere end en lille kerne af jeres vigtigste funktioner er dækket af tredjeparts-plugins (f.eks. Multilingual, SEO, formularer, Custom Fields, medlemskab), så stiger jeres drifts- og sikkerhedsbyrde mærkbart. Det er ikke nødvendigvis slemt – men det skal være ønsket. Fordi med hver afhængighed vokser indsatsen for tests, backups, staging og rollbacks.

Vi anbefaler i sådanne tilfælde næsten altid et setup, der tager driften seriøst: Staging-miljø, automatiserede backups, opdateringsproces og klare ansvarsområder. Hvis du ikke kan eller vil afbilde det organisatorisk, bliver WordPress på et tidspunkt ikke „dårligt“, men „for dyrt i hverdagen“.

En typisk udvej er så ikke straks en komplet re-platforming, men en ærlig genopbygning inden for WordPress: færre plugins, klarere indholdsmodel, bedre skabeloner. Og nogle gange er det netop den rigtige beslutning.

Når vi hjælper med CMS-beslutninger, taler vi på et tidspunkt mindre om „Kan systemet X?“ og mere om „Hvem gør det virkelig?“ Præcis her fejler mange sammenligninger: Funktioner virker håndgribelige, drift virker usynlig. Men drift er det, du betaler hver måned – i tid, nerver og risiko.

Ejerskab er et spørgmål om roller

Et CMS har brug for ejere. Ikke juridisk, men praktisk: Hvem overvåger opdateringer? Hvem beslutter, hvilken udvidelse der må med? Hvem vedligeholder rettigheder og roller? I WordPress ligger dette ansvar ofte i en blanding af bureau, IT og „nogen fra teamet, der tager sig af det“. Det kan fungere – så længe det er klart.

I Payload flyttes ejerskab ofte mere mod produktteam eller udviklingspartner, fordi en del af logikken ligger i koden. Det lyder som „mere arbejde“, men er ofte „mere klarhed“: Ændringer er versioneret, kontrollerbare, testbare. Det reducerer overraskelser – men forudsætter, at du accepterer et minimum af proces.

Vores driftsbrille: Samtale om TCO

Vi bruger en enkel samtalestruktur, der har vist sig effektiv. Vi kalder den „TCO i tre skåle“ (Total Cost of Ownership, men uden controlling-snak): For det første løbende vedligeholdelse (opdateringer, overvågning, backups), for det andet forandring (nyt indhold, nye moduler, nye kampagner), for det tredje hændelser (sikkerhedsfejl, plugin-konflikter, nød-rollbacks).

Mange teams budgetterer kun skål to – den synlige videreudvikling. Skål et og tre bliver gjort „i forbifarten“. Hvis du kigger ærligt, er det der, WordPress-projekter kan blive dyre: ikke fordi WordPress er dyrt, men fordi systemet inviterer dig til at undervurdere driften.

Leverandørrisiko er ikke kun et spørgsmål om licens

Et andet punkt, der sjældent diskuteres åbent: Leverandørrisici opstår også i open-source-økosystemer. I WordPress kan de snige sig ind via plugins og temaer. I Payload mere gennem spørgsmålet om, hvor godt jeres setup er dokumenteret, og om I har en ren kodebase.

Vores praktiske tip: Uanset hvad du vælger – invester tidligt i dokumentation og en reproducerbar build-proces. Det er ikke glamourøst, men det er den type bæredygtighed, der gør digitalt arbejde virkelig stabilt.

Sikkerhed er den del af CMS-valget, som ingen bestiller som et „feature“ – indtil der er en hændelse. Og fordi vi arbejder med mange impact-orienterede organisationer, er skaden ikke kun finansiel. Det handler om tillid.

Forskellige angrebsflader

WordPress er meget udbredt. Det gør det attraktivt for automatiserede angreb, især hvor installationer er forældede eller plugins har sårbarheder. Det betyder ikke, at WordPress er usikkert. Det betyder: Du har brug for en opdateringsrutine, der ikke er valgfri.

Payload er i mange setups mindre sårbar „udefra“, fordi det ikke typisk består af tusind plugin-byggesten. Men her hænger sikkerheden mere på jeres udrulning, jeres miljøvariabler, jeres adgangsdata og på, hvordan I beskytter jeres API. Det er en anden risikoprofil: mindre masseangreb, mere „driftshygiejne“.

Hvad vi forstår ved en god opdateringsstrategi

I vores projekter skelner vi tydeligt mellem „at gøre opdatering“ og „at have ansvar for opdatering“. At have ansvar betyder: Du har et staging-miljø, du tester kritiske flows (formularer, checkout, søgning), du har en rollback, og du ved, hvem der kan kontaktes om natten, hvis noget går galt.

For WordPress betyder det ofte: Plugin-reduktion, klare afhængigheder, og et hosting, der tager sikkerhed alvorligt. For Payload betyder det: ren CI/CD, regelmæssige dependency-opdateringer i Node-økosystemet og en klar rettighedsadministration i Admin og API.

Vores praksisindikator: Rettigheder er produkt, ikke indstilling

En unik vinkel, som vi sjældent læser i CMS-sammenligninger, men ofte oplever: Mange sikkerhedsproblemer er egentlig rolleproblemer. Når for mange mennesker kan for meget, opstår fejl – ikke med vilje, men af stress.

Derfor behandler vi rettigheder som UX: Hvilke roller er der virkelig? Hvem behøver foresigt, hvem må offentliggøre, hvem må ændre strukturer? I Payload kan dette meget detaljeret afbildes. I WordPress er det også muligt, men du lander ofte ved rolle-plugins og ekstra logik.

Hvis du er usikker, er det en god test: Skriv jeres reelle roller på et stykke papir. Hvis det allerede er svært, er det ikke CMS'et, der er problemet – men den manglende governance. Så kan det være en god idé at tage fat der, før du migrerer.

Ydeevne er for os ikke kun „nice to have“. Det er en del af tilgængelighed, en del af konvertering, og det er også en del af digital bæredygtighed: Færre data, mindre beregningstid, mindre energi – hos dig og hos dine brugere.

Hvad vi ikke gør: Vi kaster ikke med tal, som vi ikke kan dokumentere. Der findes gode arbejder om det digitale infrastrukturs fodaftryk, fx om størrelsesordenen af globale emissioner fra digitale teknologier. The Shift Project (2019)

Til CMS-beslutningen hjælper dig dog især en pragmatisk sandhed fra projekter: Ydeevne opstår sjældent i CMS-kernen, men i det, du bygger rundt omkring.

WordPress: Vægt gennem komfort

WordPress kan være meget hurtig – men mange WordPress-sider bliver tunge, fordi byggesættet er bekvemt. Sidedesignere, ekstra frontend-biblioteker, sliders, tracking, fem formularværktøjer parallelt. Det summer op. I praksis bemærker vi det på to måder: Core Web Vitals lider og mobile brugere springer tidligere fra.

Hvis du bruger WordPress, kan det ofte betale sig med en „vægt-nulstilling“: Optimering af medier konsekvent (f.eks. AVIF/WebP), reducering af script-overskud, korrekt konfiguration af caching, og brug af et tema, der ikke medbringer alt, bare fordi det kan. Her linker vi gerne til PageSpeed Insights som et fælles diagnoseværktøj, fordi det gør diskussioner mere objektive.

Payload: Ydeevne gennem afkobling

Payload bruges ofte sammen med moderne frontends, der kan rendere statisk eller hybrid. Det gør det lettere at levere meget slanke sider, bruge god caching og mindre ballast. I kombination med en frontend som Astro ser vi ofte, at ydeevne ikke behøver „optimeres“, fordi standarden allerede er mere effektiv.

Bæredygtighed betyder også: mindre vedligeholdelsesenergi

En anden unik tilgang fra vores perspektiv: Bæredygtighed handler ikke kun om pageweight, men også om teamenergi. Hvis dit CMS hele tiden udløser vedligeholdelsesbrande, binder det ressourcer, som du egentlig vil investere i indhold, effekt og produktforbedring.

Derfor spørger vi til sidst altid: Hvilken løsning holder jer mentalt og organisatorisk lettere? En bæredygtig hjemmeside er for os en, der laster hurtigt – og som ikke kræver din opmærksomhed hver uge.