SaaS Købmænd er en af mine favorit-podcasts. Jeg elsker, at de ikke er bange for at dele ud, tage et standpunkt og eventuelt tage fejl. I episode 78, “WordPress er død”, fortæller Bo Møller og Anders Eiler, hvordan AI-agenter har ændret den måde, de bygger hjemmesider på.1
Titlen på podcast-episoden er selvfølgelig sat på spidsen. En journalistisk stramning eller clickbait som det hedder på moderne dansk – ikke en bogstavelig påstand om, at WordPress er dødt. Det interessante er heller ikke at vinde en diskussion om overskriften, men at se på det skifte, den peger på: AI-agenter gør det langt lettere at bygge og vedligeholde websites med Astro, Markdown, statiske filer og uden et traditionelt CMS.
Det synes jeg er et godt afsæt til en større diskussion om WordPress’ rolle i dag.
Hvis en hjemmeside består af et begrænset antal sider, bliver vedligeholdt af en eller to teknisk stærke personer, og en AI-agent kan klare en stor del af ændringerne, så er det ikke sikkert, at man har brug for WordPress.
For mig er spørgsmålet derfor ikke kun, hvordan man bygger hjemmesiden.
Det er mindst lige så vigtigt at spørge:
Hvem skal arbejde med den bagefter?
Det afgørende er ikke kun, hvordan hjemmesiden bliver bygget, men hvem der skal drive den, og hvilke funktioner de har brug for.
Astro og et CMS løser ikke helt det samme problem
Noget bliver let blandet sammen i diskussionen.
Astro er et framework til at bygge websites med. WordPress er blandt andet et content management system.
Man kan bygge et website med Astro og have indholdet liggende i Markdown-filer. Men man kan også bygge det med Astro og koble et CMS på.
Astros egen dokumentation fremhæver et CMS som relevant, når man blandt andet har brug for en visuel editor, standardiserede indholdstyper og mulighed for at samarbejde om indholdet.2
Så det interessante spørgsmål er ikke nødvendigvis:
WordPress eller Astro?
Det er snarere:
Har organisationen overhovedet brug for et CMS?
En AI-agent kan gøre et CMS overflødigt – for nogle
Jeg kan godt se tiltrækningen ved den model.
Forestil dig en SaaS-virksomhed med 20 eller 30 relativt enkle sider.
Stifteren eller marketingchefen vil ændre forsiden og skriver:
Skift teksten i topfeltet, tilføj vores nye integration og opdater priserne på produktsiden.
En AI-agent laver ændringerne i filerne, tester sitet og sender det i produktion.
I sådan en organisation kan et WordPress-dashboard faktisk være et ekstra lag.
Man behøver måske ikke logge ind i et CMS, finde den rigtige side, redigere nogle felter og trykke opdater.
Man fortæller bare agenten, hvad der skal ske.
Det er en reel ændring.
Men modellen fungerer især godt, når den person, der bestiller ændringen, også har lov til at ændre den.
Så snart organisationen bliver større, dukker der nogle andre problemer op.
“Kan du ændre hjemmesiden?” bliver hurtigt et organisationsproblem
Forestil dig i stedet en organisation med:
- en kommunikationsafdeling
- fem projektledere
- en HR-medarbejder
- en kursusansvarlig
- en ekstern kommunikationskonsulent
- en webansvarlig.
De arbejder alle sammen med den samme hjemmeside.
Projektlederne må gerne redigere deres projekter, men ikke hjemmesidens opsætning.
HR skal kunne opdatere medarbejdere og ledige stillinger.
Kommunikationsafdelingen skal kunne publicere nyheder.
En praktikant må gerne skrive et udkast, men ikke publicere det.
Og nogen skal kunne finde ud af, hvad der stod på en side i sidste uge, hvis noget bliver overskrevet ved en fejl.
Her er problemet ikke længere at få genereret noget HTML.
Problemet er governance.
Hvem må gøre hvad? Hvem ejer indholdet? Hvordan undgår vi, at en redaktør ændrer noget, vedkommende ikke skal? Hvordan går indhold fra udkast til publicering? Og hvordan går vi tilbage til en tidligere version?
WordPress har et etableret system med roller og rettigheder, så forskellige brugere kan få forskellige muligheder i administrationen.3 Sammen med revisioner er det blandt de funktioner, der først bliver rigtig interessante, når flere mennesker skal arbejde sikkert på det samme site.
Samarbejde er mere end at skrive i det samme dokument
WordPress er ikke Google Docs, og jeg ville ikke vælge WordPress alene, fordi to mennesker skal kunne skrive samtidig.
Dets styrke ligger et andet sted.
En bidragyder kan for eksempel få lov til at skrive uden at kunne publicere, mens en redaktør kan få bredere adgang. WordPress kan også gemme revisioner af indhold, så tidligere versioner kan findes igen.4
Og man kan bygge redigeringsoplevelsen sådan, at medarbejdere ændrer de oplysninger, de har ansvar for, uden samtidig at skulle tage stilling til hele sidens layout.
Det bliver vigtigt, når en hjemmeside ikke bare skal være nem for udvikleren at bygge, men også enkel og sikker for organisationen at drive.
Det interessante begynder, når indhold ikke længere bare er sider
Jeg synes faktisk, dette er det stærkeste argument for WordPress.
En lille hjemmeside består ofte mest af nogle få sider: Forside, Om os, Produkt og Kontakt. Så kan Markdown være helt fint.
Men forestil jer en organisation med:
- 80 medarbejdere
- 35 projekter
- 20 kurser
- arrangementer
- nyheder
- publikationer
- fagområder.
Man kan selvfølgelig lave 200 individuelle sider.
Men en bedre løsning er ofte at beskrive, hvad indholdet er.
En medarbejder kan eksempelvis have navn, stilling, afdeling, billede, telefon, e-mail og fagområder. Et kursus kan have titel, beskrivelse, dato, sted, underviser og tilmeldingslink.
Det er struktureret indhold.
I WordPress kan man oprette egne indholdstyper og give dem deres egne egenskaber og rettigheder.5
Når en medarbejder derefter opdaterer et kursus, redigerer vedkommende kursets oplysninger. Personen behøver ikke samtidig beslutte, hvordan kurset skal vises på forsiden, på kursets egen side og i kursusoversigten.
Det sørger systemet og skabelonerne for.
Det er en vigtig forskel mellem at redigere en hjemmeside og at vedligeholde indhold i et system.
Smashing Magazine er et interessant eksempel
Smashing Magazine er især interessant i denne diskussion, fordi de faktisk gennemførte et markant skifte væk fra WordPress.
De flyttede i 2019 deres store WordPress-site til en Jamstack-arkitektur og beskrev senere en seksdobling af sidehastigheden. Samtidig flyttede skrivearbejdet fra WordPress over i blandt andet Markdown og Git-baserede arbejdsgange.6
Det var ikke et mislykket eksperiment. Tværtimod beskriver Smashing Magazine både performance- og udviklerfordele ved skiftet.
Men der var også redaktionelle behov, som ikke forsvandt, bare fordi WordPress gjorde.
I 2023 beskrev Smashing Magazine, hvordan de havde lagt TinaCMS oven på deres statiske arkitektur for at få en redigeringsflade, previews og et redaktionelt workflow. De bemærker selv, at en del af funktionerne var ting, de allerede brugte i WordPress før skiftet.7
Det synes jeg er en god illustration af pointen.
Man kan godt fjerne sit CMS.
Men hvis organisationen stadig har de behov, som CMS’et løste, kan man ende med at bygge eller købe funktionerne igen.
Et stort website er ikke automatisk et argument for WordPress
Det er samtidig vigtigt at vende argumentet om.
Jeg ville ikke vælge WordPress, bare fordi et site har 10.000 URL’er.
Et meget stort dokumentationssite kan være oplagt at generere statisk. Et arkiv, der næsten aldrig bliver ændret, behøver heller ikke nødvendigvis et CMS.
Det interessante er ikke kun antallet af sider. Det interessante er blandt andet:
- hvor ofte indholdet ændres
- hvor mange mennesker der arbejder med det
- hvor forskelligt deres ansvar er
- hvor struktureret indholdet er
- hvor mange steder indholdet skal genbruges
- hvor mange funktioner der er knyttet til indholdet.
Et website med 10 sider kan være kompliceret.
Et website med 10.000 sider kan være simpelt.
WordPress kan også bruges på virkelig store redaktionelle løsninger
Det er heller ikke sådan, at WordPress kun hører hjemme på små virksomhedswebsites.
The Times har eksempelvis flyttet en stor del af sin digitale publiceringsproces over på en WordPress VIP-baseret løsning. Ifølge WordPress VIPs egen case blev tiden fra redigering til publicering reduceret med 34 procent, antallet af klik for at publicere en artikel med 62 procent, og oplæring af journalister gik fra to dage til en halv time.8
Det er leverandørens egen case og skal læses som sådan. Men den er stadig et konkret eksempel på, at WordPress kan indgå som publiceringsinfrastruktur i en stor redaktionel organisation.
Størrelsen er altså ikke i sig selv et argument for eller imod WordPress.
WordPress kan også give mening på små sites
Et WordPress-site behøver ikke være stort eller komplekst for at give mening.
Selv et site med ti sider og et kontaktmodul kan være et fornuftigt valg, hvis arbejdsdelingen passer til det.
Udvikleren kan bruge AI til hurtigt at bygge og videreudvikle skabeloner, design og funktioner, mens kunden selv kan logge ind og redigere tekster, billeder og andet indhold uden at skulle arbejde med kode, Git eller en AI-agent.
Kunden kan samtidig få AI-hjælp til selve indholdsarbejdet. Det er den arbejdsgang, jeg beskriver i Fra idé til blogindlæg: AI som hjælp i hverdagen, hvor en AI-assistent kan hjælpe med teksten og gemme den direkte som kladde i WordPress.
Valget behøver derfor ikke være mellem WordPress og AI-baseret udvikling. AI kan bruges til at udvikle WordPress-løsningen, mens WordPress fortsat er den stabile brugergrænseflade for dem, der skal drive hjemmesiden bagefter.
WordPress bliver især interessant, når man rent faktisk har glæde af funktioner som:
- brugere, roller og rettigheder
- kladder og revisioner
- strukturerede indholdstyper
- taksonomier og relationer
- mediehåndtering
- faste skabeloner og mønstre
- begrænsninger af, hvad redaktører kan ændre
- søgning og arkiver
- API’er
- integrationer med andre systemer.
WordPress’ REST API giver blandt andet adgang til indlæg, sider, medier, brugere, taksonomier og indholdstyper og kan bruges til alternative administrationsflader og andre applikationer.9
Det betyder også, at WordPress ikke nødvendigvis behøver at være hele hjemmesiden.
Det kan være systemet, hvor organisationen administrerer sit indhold, mens en anden teknologi står for visningen.
Det bliver først svært at forsvare WordPress, hvis organisationen reelt ikke har brug for CMS’et: Hvis næsten intet indhold ændres, én teknisk person står for alle ændringer, og de funktioner WordPress tilbyder, ikke bliver brugt.
AI kan være brugergrænsefladen til WordPress
Der er også en anden mulighed end at vælge mellem AI og et CMS.
En AI-agent kan for eksempel oprette et udkast, rette en eksisterende side, udfylde strukturerede felter, kategorisere indhold og arbejde gennem hjemmesidens API.
Det interessante er altså ikke kun AI i stedet for CMS, men AI som en ny brugergrænseflade til CMS’et.
Så kan et menneske for eksempel skrive:
Opret et udkast til en case om projektet. Brug kunden, året og platformen fra vores noter, men publicér den ikke.
Agenten kan udføre arbejdet, mens WordPress stadig tager sig af adgang, struktur, kladdestatus, revisioner og publicering.
AI-agenten bliver altså ikke databasen eller rettighedssystemet. Den bliver en ny måde at arbejde med dem på.
Så er WordPress død?
Nej.
Men jeg tror, WordPress har mistet en rolle, det tidligere næsten fik automatisk: standardvalget til enhver hjemmeside.
AI og moderne frameworks gør det langt mere realistisk at bygge små websites uden et traditionelt CMS.
Det synes jeg er positivt.
Et CMS bør ikke installeres af vane. Men det modsatte bør heller ikke ske.
Man skal ikke fjerne CMS’et, bare fordi en AI-agent kan generere en hjemmeside.
Hvis en enkelt teknisk person styrer et forholdsvis enkelt site, kan Astro, Markdown og AI være en meget elegant løsning.
Hvis mange mennesker skal vedligeholde et større og mere struktureret website, er spørgsmål om roller, historik, indholdsstruktur og governance stadig nødvendige.
Og hvis man har brug for en stor del af de funktioner, WordPress allerede indeholder, kan det være mærkeligt først at fjerne WordPress og derefter begynde at bygge dem igen.
WordPress er ikke nødvendigvis fremtiden for alle hjemmesider.
Men det er heller ikke dødt.
Det er et valg, man skal kunne argumentere for.
Har I allerede et WordPress-site, er næste spørgsmål heller ikke nødvendigvis, om det skal skrottes. I Skal jeres WordPress-hjemmeside forbedres eller bygges om? ser vi på, hvornår det giver mening at forbedre det eksisterende, og hvornår man bør starte forfra.
Kilder og noter
- SaaS Købmænd, episode 78: “WordPress er død”. Episodebeskrivelsen omtaler skiftet mod Astro, Markdown og statiske filer samt AI-agenternes rolle. ↩
- Astro Docs: Use a CMS with Astro. Astro fremhæver blandt andet visuel redigering, standardiserede indholdstyper og samarbejde som grunde til at bruge et CMS. ↩
- WordPress.org: Roles and Capabilities. Dokumentation af roller, capabilities og adgangsstyring. ↩
- WordPress Developer Resources: Post Revisions. Dokumentation af revisionsdata og adgang til tidligere versioner via REST API’et. ↩
- Learn WordPress: Custom post types and capabilities samt register_post_type(). ↩
- Smashing Magazine: How Smashing Magazine Manages Content: Migration From WordPress To JAMstack. Beskriver migreringen fra WordPress, Git/Markdown-arbejdsgangen og udfordringer ved et stort redaktionelt site. ↩
- Smashing Magazine: How Smashing Magazine Uses TinaCMS To Manage An Editorial Workflow. Beskriver redigeringsflade, preview og workflow oven på Jamstack-arkitekturen og sammenligner flere funktioner med deres tidligere WordPress-arbejdsgang. ↩
- WordPress VIP: How The Times Accelerated Their Publishing Workflow. Leverandørcase med de angivne resultater for publiceringstid, antal klik og oplæring. ↩
- WordPress REST API Handbook: Reference. Oversigt over endpoints til blandt andet indlæg, sider, revisioner, medier, brugere, taksonomier og indholdstyper. ↩