Vores WordPress plugin-stack i 2026 – de samme 9 plugins

Der findes tusindvis af WordPress-plugins, og næsten alle lister på nettet lover dig den perfekte kombination.

Men en god plugin-stack handler ikke om at installere flest mulige værktøjer. Den handler om at have så få moving parts som muligt uden at mangle noget vigtigt.

I NyeHøjder bruger vi derfor de samme ni plugins som udgangspunkt på praktisk talt alle almindelige WordPress-projekter. Ikke fordi de ni plugins er de bedste for alle. Og heller ikke fordi vores stack nu er færdig for evigt.

Det er de værktøjer, der lige nu giver os den bedste balance mellem fleksibilitet, kvalitet, ejerskab og vedligeholdelse.

I dette indlæg viser jeg:

• hvad vi installerer som standard
• hvorfor hvert værktøj har fået en fast plads
• hvad vi kun tilføjer, når et projekt kræver det
• hvad vi bevidst har valgt fra
• hvilke erfaringer der har fået os til at ændre næsten hele vores måde at bygge WordPress-hjemmesider på

Det her er med andre ord ikke en facitliste. Det er et transparent kig ind under motorhjelmen på den måde, vi bygger i NyeHøjder i 2026.

Åbenhed om Etch: Jeg har været ambassadør for og investor i Etch siden den første fremvisning. Det er vigtigt at vide, når du læser min vurdering. Etch er samtidig et værktøj, vi bruger på rigtige projekter, og i dette indlæg forsøger jeg at være lige så tydelig om dets nuværende begrænsninger som om potentialet.

Hvad mener jeg med en plugin-stack?

Når jeg siger plugin-stack, mener jeg ikke alle plugins, vi nogensinde kunne finde på at installere.

Jeg mener de værktøjer, vi som udgangspunkt bygger oven på, fordi de løser tilbagevendende behov på tværs af vores projekter.

Et kundespecifikt bookingsystem, en webshopfunktion eller en særlig integration er ikke en del af grundstacken. Det bliver valgt til, når projektet kræver det.

Den skelnen er vigtig. Ellers ender hjemmesiden som en værktøjskasse, hvor nogen har taget alt med, bare fordi det måske bliver nyttigt en dag.

Et plugin får kun en fast plads hos os, hvis det:

1. løser et problem, vi møder igen og igen
2. er bedre end selv at bygge og vedligeholde funktionen
3. spiller ordentligt sammen med resten af systemet
4. kan vokse med projektet uden at gøre simple opgaver unødigt komplicerede
5. har en rimelig chance for stadig at kunne vedligeholdes om flere år

Antallet af plugins fortæller i øvrigt ikke i sig selv, om en hjemmeside er hurtig eller langsom, sikker eller usikker. Ét dårligt plugin kan skabe flere problemer end ti veldesignede plugins. Det interessante er, hvad hvert værktøj gør, hvordan det er bygget, hvad der bliver aktiveret, og hvordan delene spiller sammen.

Fra 50 plugins til en bevidst grundstack

Jeg byggede min første hjemmeside for mere end 20 år siden i noget, der mindede om Wix eller Squarespace. Alt var statisk: Det, jeg byggede, var det, man så.

Da jeg senere skiftede til WordPress, var det indbyggede CMS mit første store unlock. Indhold og layout kunne skilles ad. Jeg kunne bygge én skabelon og lade den vise forskellige indlæg automatisk i stedet for at bygge hver side manuelt.

I dag lyder det ikke revolutionerende. Dengang føltes det sådan.

Jeg kom imidlertid fra drag-and-drop-land og vidste meget lidt om kode. Det meste af min tid gik med min egentlige passion, musik. Derfor føltes Elementor som superkræfter, da jeg opdagede det. Pludselig kunne jeg visuelt bygge næsten alt, og hvis jeg sad fast, fandtes der endnu en YouTube-video og endnu et plugin, som kunne løse problemet.

Det virkede – indtil det ikke længere gjorde.

Mine hjemmesider endte ofte med omkring 50 plugins. De var langsomme, rodede og frustrerende at arbejde videre på. Hver genvej løste ét problem og skabte ofte to nye. Jeg lærte et proprietært system virkelig godt, men jeg lærte ikke nødvendigvis det sprog, nettet faktisk er bygget af.

Da jeg fandt ACF og senere JetEngine, gik det op for mig, hvor meget mere WordPress kunne være end sider og blogindlæg. Med egne indholdstyper, felter og relationer kunne vi bygge strukturerede løsninger til blandt andet ydelser, medarbejdere, bøger, film eller hvad projektet nu krævede.

JetEngine blev samtidig værktøjet, der ændrede min holdning til betalte plugins. Jeg havde længe tænkt, at jeg ikke ville betale for noget, hvis der fandtes en gratis løsning. Men “gratis” blev hurtigt dyrt, hvis jeg brugte flere dage på at omgå begrænsninger eller reparere noget, der ikke virkede som forventet.

Da jeg begyndte på min bachelor i datalogi og faktisk lærte at programmere, ændrede min værktøjskasse sig igen. Jeg gik fra Elementor til Bricks, og for første gang i mange år følte jeg ikke, at værktøjet holdt mig tilbage. Bricks gav lettere adgang til rigtig HTML og CSS og kom tættere på den måde, professionelle webudviklere arbejder på.

Gennem Bricks-miljøet fandt jeg også Kevin Geary og hans undervisning i systemer, vedligeholdelse, skalerbarhed og webstandarder. Det var et markant skifte fra hacks, tricks og genveje til at forstå fundamentet.

Bricks var det rigtige værktøj for os i en periode. Men efter en større overhaling oplevede jeg, at ting, som tidligere fungerede, blev påvirket af opdateringer, og at jeg brugte mere og mere tid på at tilsidesætte builderens valg med min egen kode. Til sidst var interfacet oftere i vejen, end det hjalp.

Det er den udvikling, vores nuværende stack kommer ud af. Ikke en jagt på nye, skinnende værktøjer, men et forsøg på at fjerne friktion og bygge tættere på nettets egne standarder.

Et værktøj kan være det rigtige valg i flere år og stadig blive det forkerte senere. Det er ikke et nederlag. Det er en del af arbejdet.

De ni plugins i korte træk

Værktøj	Opgave i stacken	Hvorfor det er med
Etch	Visuelt udviklingsmiljø og builder	Samler udvikling, kode og kundens indholdsredigering i en mere web-nativ arbejdsgang
Automatic.css	Design tokens, variabler, responsivitet og CSS-system	Skaber et konsistent og skalerbart fundament under designet
Admin and Site Enhancements	Små WordPress-forbedringer	Samler en række tilbagevendende funktioner, som ellers ville kræve flere små plugins
WS Form Pro	Formularer og formularlogik	Kan håndtere både simple kontaktformularer og avancerede flows uden at blive en flaskehals
Rank Math	Teknisk SEO og metadata	Giver et praktisk interface til blandt andet metadata, sitemaps og schema – uden at blive forvekslet med en SEO-strategi
Plausible Analytics	Webanalyse	Gør de vigtigste data lettere at forstå og bruge for mindre virksomheder
WP Mail SMTP	Afsendelse af WordPress-mails	Forbinder hjemmesiden til en rigtig mailudbyder og giver et mere pålideligt mailsetup
WPCode Lite	Mindre kodebidder og scripts	Giver små snippets et kendt og kontrollerbart hjem
LiteSpeed Cache	Cache og performance	Passer til vores nuværende LiteSpeed-baserede hosting – og er derfor et bevidst hostingafhængigt valg

Lad os se nærmere på, hvorfor hvert værktøj er med.

1. Etch: den største ændring i vores stack

Den største ændring i NyeHøjders stack i 2026 er Etch.

Etch bliver ofte placeret i kategorien page builder, men ambitionen er større end det. Det er bygget som et samlet visuelt udviklingsmiljø til WordPress, hvor struktur, styling, dynamisk indhold og kode er tilgængeligt fra det samme interface.

Den største praktiske forskel for mig er mængden af friktion, der er forsvundet.

Tidligere kunne en arbejdssession let ende med 20 åbne faner: builderen, WordPress-admin, et CSS-interface, custom fields, skabeloner, dokumentation og en håndfuld andre “magic areas”, som jeg konstant skulle skifte imellem.

I Etch kan jeg ofte arbejde med én eller to faner. Det lyder som en lille ting, men man bliver overrasket over, hvor meget tid og koncentration der forsvinder, når man hele tiden leder efter det rigtige vindue.

Den anden store forskel er adgangen til koden. Etch skjuler ikke HTML, CSS, JavaScript og PHP bag et proprietært system. Jeg kan arbejde visuelt, direkte i koden eller skifte mellem de to alt efter opgaven.

Det betyder ikke, at man skal kunne programmere for at bruge Etch. De velkendte visuelle elementer og drag-and-drop-arbejdsgange er stadig tilgængelige. Forskellen er, at værktøjet ikke tvinger alle – begyndere og professionelle – ind i et parallelt sprog, som kun eksisterer i den pågældende builder.

Det gør også Etch interessant i en tid, hvor alle forsøger at bygge AI ind i deres produkter. AI-modeller kender allerede sprogene og principperne bag almindelig webudvikling. Jo mindre de først skal lære et lukket buildersystem, desto lettere er det at bruge dem som en reel del af arbejdsgangen.

For kunden bliver det, vi bygger i Etch, gjort til brugerdefinerede Gutenberg-blokke. Etch er udviklingsmiljøet, mens WordPress’ blokeditor kan være det mere enkle sted, hvor kunden redigerer sit indhold. Indholdet ligger fortsat i WordPress i stedet for at være gemt i et lukket builderformat.

Der er dog en vigtig nuance: Vi har kun bygget vores første rigtige kundeprojekt i Etch. Jeg er meget positiv, men jeg kommer ikke til at kalde det den evige løsning på baggrund af ét projekt.

Til almindelige virksomhedshjemmesider er Etch vores nye udgangspunkt. Til webshops bruger vi fortsat Bricks, indtil Etchs e-commerce-understøttelse er klar til de behov, vi møder. Stacken skal følge virkeligheden – ikke vores begejstring.

2. Automatic.css: systemet under designet

Automatic.css – ofte forkortet ACSS – er ikke med for at undgå CSS. Det er med for at gøre vores CSS mere systematisk.

Vi bruger det til at definere designets grundregler: farver, typografi, afstande, størrelser, breakpoints og de variabler, resten af hjemmesiden bygger på.

I stedet for at gætte, om afstanden mellem to elementer skal være 73 eller 86 pixels, vælger vi fra et bevidst system. Hvis den grundlæggende afstand senere skal ændres, kan vi rette variablen ét sted og lade ændringen slå igennem på hele hjemmesiden.

Det samme gælder farver, skriftstørrelser og mange andre designbeslutninger.

Det betyder, at vi kan starte med struktur, indhold og brugerrejse, før alle visuelle detaljer er låst. Har kunden allerede en udførlig brandguide, kan vi få brandet ind i systemet fra begyndelsen. Er designretningen stadig under udvikling, kan vi skitsere direkte på hjemmesiden og justere systemet senere uden at starte forfra.

ACSS hjælper også med at gøre typografi og afstande flydende på tværs af skærmstørrelser og giver os gennemarbejdede mønstre til blandt andet responsivitet og tilgængelighed. Et framework gør ikke automatisk en hjemmeside perfekt eller fuldt tilgængelig, men det gør det langt lettere at indbygge gode beslutninger i fundamentet i stedet for at huske dem manuelt på hver eneste side.

Nogle oplever systemer som en begrænsning af kreativiteten. Jeg ser det omvendt.

Hvis hver overskrift, afstand og farve vælges på ny, bliver resultatet sjældent mere kreativt. Det bliver bare mere tilfældigt. Et tydeligt system fokuserer kreativiteten på de beslutninger, der faktisk gør en forskel.

3. Admin and Site Enhancements: mange små forbedringer samlet ét sted

WordPress har en række små irritationer og manglende funktioner, der ofte bliver løst med hvert sit plugin eller en samling tilfældige snippets.

Admin and Site Enhancements, eller ASE, samler mange af dem i ét modulært værktøj.

Den vigtige del af den sætning er modulært. Vi aktiverer ikke alt, bare fordi det findes. Vi tænder kun de funktioner, det konkrete projekt har brug for.

På et almindeligt projekt kan det blandt andet være:

• duplikering af indhold
• udskiftning af mediefiler og mulighed for SVG-upload for administratorer
• oprydning og organisering i WordPress’ adminområde
• en anden loginadresse og begrænsning af gentagne loginforsøg
• kontrol over revisioner og WordPress Heartbeat
• flere brugerroller, når projektet kræver det

På den måde har ASE erstattet flere mindre plugins, vi tidligere installerede hver for sig. Det giver færre leverandører, færre interfaces og ét kendt sted at administrere de små forbedringer.

Det er værd at understrege, at en ændret loginadresse og begrænsede loginforsøg ikke i sig selv er en komplet sikkerhedsstrategi. Sikkerhed afhænger også af hosting, opdateringer, adgangsstyring, backups, overvågning og resten af infrastrukturen. ASE løser bestemte opgaver; det fritager os ikke fra at tænke på helheden.

Efter skiftet til Etch bruger både vi og kunderne mindre tid i den traditionelle WordPress-backend. Den ligner stadig lidt en dinosaur. Men når vi er der, gør ASE oplevelsen mere overskuelig.

4. WS Form Pro: formularen må ikke være hjemmesidens svageste led

De fleste virksomhedshjemmesider har brug for mindst én formular. Derfor er formularsystemet en fast del af vores stack.

Vi bruger WS Form Pro.

Til en helt enkel kontaktformular kan næsten alle formularplugins løse opgaven. Forskellen viser sig, når kunden senere får brug for betinget logik, beregninger, betaling, integrationer, dynamiske værdier eller et flow, der opretter og opdaterer indhold i WordPress.

Jeg vil hellere lære og bruge ét stærkt formularværktøj konsekvent end starte med en begrænset gratis løsning og bygge det hele om, når projektet vokser.

Det betyder ikke, at alle formularer skal være avancerede. Det betyder bare, at fundamentet ikke bliver flaskehalsen.

Jeg har tidligere brugt både gratis og betalte formularplugins – blandt andet JetFormBuilder, som fulgte med min Crocoblock-licens. Flere gange har jeg brugt dage på noget, der burde have været enkelt, eller først opdaget uger senere, at et flow ikke opførte sig som forventet.

Da et projekt krævede noget mere avanceret, gav jeg WS Form en chance. Jeg har ikke haft lyst til at skifte siden.

Det skyldes både funktionerne og oplevelsen omkring produktet. Min egen erfaring med udvikleren Mark Westguards support har været usædvanligt god. Når jeg er løbet ind i et problem eller har manglet en funktion, har jeg fået reel hjælp fra en person, der forstår både produktet og den konkrete opgave – i nogle tilfælde med en løsning eller opdatering meget hurtigt.

WS Form integrerer med en lang række værktøjer og tjenester, og det spiller sammen med Automatic.css, så formularerne kan tage udgangspunkt i det samme designsystem som resten af hjemmesiden.

Det er et godt eksempel på, at prisen på et plugin ikke kun handler om licensen. Hvis værktøjet sparer flere dages arbejde, reducerer fejl og kan bruges på tværs af projekter, kan den betalte løsning være den billige.

5. Rank Math: et SEO-plugin er ikke en SEO-strategi

Til de tekniske og redaktionelle SEO-grundopgaver bruger vi Rank Math.

Det giver os blandt andet et praktisk sted at arbejde med sidetitler, metabeskrivelser, sitemaps, indeksering, Open Graph-data og schema.

Der findes flere kompetente SEO-plugins, og forskellene er ikke nødvendigvis afgørende for de fleste hjemmesider. Vi har valgt Rank Math, fordi det passer ind i vores arbejdsgang og løser de opgaver, vi har brug for. Derfor bruger vi ikke tid på at genåbne den samme værktøjsdiskussion på hvert projekt.

Men et SEO-plugin gør ikke en hjemmeside god til SEO.

Det kan hjælpe med at implementere en strategi. Det kan ikke vælge den rigtige målgruppe, forstå kundernes søgeintention, skrive indholdet, opbygge virksomhedens troværdighed eller skabe en side, der fortjener at rangere.

Derfor behandler vi hverken grønne lamper eller en høj plugin-score som et mål i sig selv. En tekst kan få en flot score og stadig være ubrugelig for det menneske, der lander på siden.

Værktøjet er et middel. Strategien og indholdet er arbejdet.

6. Plausible Analytics: mere data er ikke automatisk mere indsigt

Til de fleste selvstændige og mindre virksomheder, vi arbejder med, bruger vi Plausible Analytics.

Det er ikke, fordi Google Analytics kan mindre. Tværtimod. GA4 er mere omfattende og kan være det rigtige valg til avanceret annoncering, attribution, større marketingteams eller virksomheder med komplekse analysebehov.

Men mere data er ikke automatisk mere indsigt.

For mange mindre virksomheder bliver GA4 så omfattende, at det aldrig bliver åbnet. Eller også drukner ejeren i rapporter uden at kunne se, hvad der konkret skal gøres anderledes.

Plausible giver et langt mere enkelt overblik over blandt andet besøg, populære sider, trafikkilder, kampagner og konverteringer. Det er hurtigere for os at sætte op og lettere for kunden at orientere sig i. Det øger sandsynligheden for, at tallene faktisk bliver brugt.

Plausible er desuden bygget med privatliv som udgangspunkt, anvender ikke cookies til sin almindelige besøgsanalyse og er udviklet og hostet i EU. Det passer godt til den europæiske virkelighed, vi og vores kunder arbejder i.

Det betyder ikke, at installationen af Plausible automatisk gør hele hjemmesiden GDPR-kompatibel. En hjemmeside kan stadig have formularer, indlejrede videoer, annoncer, pixels og andre tjenester, som kræver særskilt stillingtagen. Analyseværktøjet er kun én del af det samlede setup.

Vi har altså ikke “droppet Google” som princip. Vi har droppet idéen om, at alle automatisk skal have den mest komplekse løsning.

Hvis en virksomhed har brug for GA4, sætter vi GA4 op. Hvis behovet er et forståeligt overblik, som ejeren rent faktisk vil bruge, er Plausible som regel vores udgangspunkt.

Har hjemmesiden allerede historik i Google Analytics, understøtter Plausible import af historiske GA4-data. De to værktøjer måler dog ikke på præcis samme måde, så de gamle og nye tal skal ses som sammenhængende historik – ikke som en perfekt én-til-én-sammenligning.

Selvom Plausible koster penge, og Google Analytics ikke har en direkte abonnementspris, er penge heller ikke den eneste pris. Den billigste løsning er ofte den, virksomheden faktisk ender med at få værdi ud af.

7. WP Mail SMTP: en formular er værdiløs, hvis mailen aldrig kommer frem

WP Mail SMTP er et af de mindst spændende plugins på listen. Det løser til gengæld et forretningskritisk problem.

Hvis en potentiel kunde udfylder en formular, men beskeden aldrig når frem, er resten af hjemmesiden ligegyldig.

WordPress kan som udgangspunkt forsøge at sende mails gennem webserverens almindelige mailfunktion. Det er ikke et setup, vi ønsker at basere vigtige henvendelser, ordrebekræftelser eller nulstilling af adgangskoder på.

WP Mail SMTP forbinder derfor WordPress med en rigtig mailudbyder og sørger for, at hjemmesiden bruger den konfigurerede afsender i stedet for blot at håbe på, at serverens standardopsætning virker.

Selve pluginet er ikke mailudbyderen, og det kan ikke alene garantere, at alle mails lander i indbakken. God levering afhænger også af den valgte tjeneste, domænets DNS-opsætning og korrekt godkendelse af afsenderen. Men pluginet giver os et kendt forbindelseslag og en langt bedre forudsætning for at sætte det rigtigt op.

I NyeHøjder bruger vi selv Google Workspace, mens kunderne ofte allerede har Microsoft 365, Google Workspace eller en anden mailudbyder. Derfor standardiserer vi forbindelsen og arbejdsgangen – ikke nødvendigvis leverandøren.

8. WPCode Lite: et kontrolleret hjem til små snippets

Nogle gange er et helt plugin for meget. Andre gange mangler der bare et lille stykke kode.

Til mindre snippets og scripts bruger vi WPCode Lite.

Det giver os ét sted at se, aktivere og deaktivere små funktioner i stedet for at gemme kode i tilfældige theme-filer, globale felter eller fem forskellige interfaces. Vi kan samtidig styre, hvor et snippet skal køre, så en lille funktion ikke nødvendigvis bliver indlæst på hele hjemmesiden.

Men der er en vigtig grænse.

WPCode skal ikke være en losseplads for hele hjemmesidens funktionalitet. Hvis noget bliver stort, forretningskritisk eller afhænger af flere filer og ændringer over tid, skal det behandles som rigtig software. Så hører det hjemme i et rigtigt plugin eller en kodebase med ordentlig versionsstyring, dokumentation og mulighed for test.

En snippet-manager gør små kodeændringer mere overskuelige. Den gør ikke en bunke uoverskuelig kode til en god arkitektur.

9. LiteSpeed Cache: et bevidst hostingafhængigt valg

Til cache og dele af performanceoptimeringen bruger vi lige nu LiteSpeed Cache.

Det afgørende ord er lige nu.

Vores hjemmesider ligger i øjeblikket hos Hostinger på en LiteSpeed-baseret serverløsning. LiteSpeed Cache kan derfor arbejde sammen med serverens cachemekanisme, og det gør pluginet til et naturligt valg i det konkrete setup.

Hvis vi skifter hosting eller serverteknologi, er det ikke sikkert, at pluginet følger med.

Det er en vigtig pointe, fordi performance-plugins ofte bliver anbefalet, som om de eksisterer i et vakuum. Den rigtige løsning afhænger af serveren, resten af stacken og det konkrete problem, vi forsøger at løse.

Vi har blandt andet overvejet Perfmatters. Det kan være et stærkt værktøj, men på mange af vores projekter vil det sandsynligvis være endnu et lag, vi skal konfigurere og vedligeholde, uden at kunden nødvendigvis får en mærkbar gevinst.

Hvis et konkret projekt har et konkret problem, som Perfmatters løser, vurderer vi det der. Vi installerer det ikke bare, fordi det står på en populær liste.

Værktøjer vi kun bruger, når projektet kræver dem

En stram grundstack betyder ikke, at alle andre værktøjer er forbudte. Det betyder, at de skal gøre sig fortjent til deres plads på det enkelte projekt.

JetEngine

JetEngine har tidligere været en central del af næsten alle vores projekter. Det er et ekstremt kraftfuldt værktøj til egne indholdstyper, felter, relationer, lister og andre former for dynamisk data.

Men power har en pris.

Jo mere vi bygger ind i et specialiseret system, desto mere kompleksitet og afhængighed tager vi også med os. Etch kan nu håndtere størstedelen af de behov, vi normalt brugte JetEngine til. Derfor starter vi uden og tilføjer kun JetEngine, når projektet reelt mangler den ekstra power.

Vi bruger ikke et plugin, bare fordi vi allerede har betalt for licensen.

Bricks

Bricks er heller ikke helt væk.

Vi bruger det fortsat til webshops, indtil Etch er klar til e-commerce på det niveau, vores projekter kræver. Men Bricks er ikke længere vores generelle udgangspunkt til almindelige virksomhedshjemmesider.

Det er et godt eksempel på, at et værktøjsvalg ikke behøver være sort-hvidt. Et værktøj kan være forkert som standard og stadig være det bedste valg til en bestemt opgave.

Crocoblock Wizard

Crocoblock Wizard kan optræde i pluginlisten, når vi bruger JetEngine. Det er et installationsværktøj og ikke en del af den egentlige stack. Det tæller derfor ikke som et tiende værktøj i vores grundsetup.

Det har vi bevidst ikke i grundstacken

Det, der ikke står på listen, fortæller mindst lige så meget om vores tilgang som det, der gør.

Intet separat backup-plugin

I vores nuværende setup håndterer Hostinger backups, så vi installerer ikke automatisk endnu et backup-plugin i WordPress.

Det er ikke en universel anbefaling. En backup er kun nyttig, hvis den opbevares forsvarligt og faktisk kan gendannes. Skifter hostingopsætningen, skal backupstrategien vurderes igen. På mere kritiske løsninger kan flere uafhængige lag også være berettigede.

Intet fast font-plugin

De nødvendige brandfonte hostes lokalt på hjemmesiden. Vi har derfor ikke brug for et generelt font-plugin som standard.

Intet fast ikon-plugin

Vi vælger et konsistent ikonbibliotek, der passer til kundens brand, eksempelvis Untitled UI Icons. Ikonerne er en del af designsystemet – ikke et plugin, der automatisk skal installeres på alle projekter.

Ingen GA4 som automatisk standard

Google Analytics vælges, når virksomhedens marketing- og analysebehov retfærdiggør kompleksiteten. Det installeres ikke just in case.

Ingen Cloudflare bare fordi andre bruger det

Cloudflare kan løse reelle opgaver inden for DNS, CDN, performance og sikkerhed. Men det er en del af infrastrukturen, ikke plugin-stacken, og det tilføjer endnu et lag, som skal forstås og fejlsøges.

Vi tager det ind, når det løser et konkret problem bedre end den kompleksitet, det tilføjer – ikke fordi det er populært.

Ingen fast billedoptimering endnu

Billeder skal selvfølgelig optimeres. Men i overgangen til den nye Etch-stack har vi endnu ikke låst én bestemt pluginløsning som standard. Den endelige beslutning skal passe til både arbejdsgangen, hostingen og den måde, kunden efterfølgende uploader billeder på.

Det er bedre at være ærlig om en beslutning, der stadig er under afprøvning, end at fylde hullet ud med en anbefaling, vi ikke selv har valideret.

WordPress er gratis. En professionel hjemmeside er det ikke.

WordPress er open source og kan downloades gratis. Det betyder ikke, at en professionel WordPress-hjemmeside er gratis at drive.

Den samlede løsning består også af hosting, premiumlicenser, maillevering, analyse, backups, sikkerhed, overvågning, opdateringer, test og den tid, det kræver at holde delene kørende sammen.

Det er en vigtig forskel, når man sammenligner en billig hostingpakke med en professionelt administreret hjemmeside. Hosting er kun én linje på regningen.

Kyle Van Deusen har lavet en god, konkret opdeling af de løbende omkostninger. Hans stack er ikke den samme som vores, og amerikanske priser kan ikke overføres direkte til en dansk virksomhed. Men princippet er det samme: Den synlige abonnementspris på et plugin er kun en del af den reelle omkostning.

En billig eller gratis løsning kan være den rigtige. Men regnestykket skal også indeholde:

• tiden til opsætning og fejlfinding
• risikoen for at skulle bygge løsningen om senere
• opdateringer og kompatibilitet
• adgang til kvalificeret support
• ansvaret, når host, plugin og mailudbyder peger på hinanden
• den mentale belastning ved selv at skulle holde øje med det hele

Vores kunder betaler derfor ikke først og fremmest for, at vi installerer bestemte plugins. De betaler for, at vi kan træffe beslutningerne, implementere dem ordentligt og tage ansvar for den samlede løsning.

Sådan kan du vurdere din egen stack

Du behøver ikke kopiere vores ni plugins. Det ville faktisk gå imod hele pointen.

Gennemgå i stedet hvert værktøj på din egen hjemmeside og stil fem spørgsmål:

1. Hvilket konkret problem løser det? Hvis svaret er uklart, er pluginet muligvis installeret just in case.
2. Overlapper det med noget andet? To plugins kan være gode hver for sig og stadig være unødvendige sammen.
3. Bliver funktionen faktisk brugt? En slukket funktion skaber ingen værdi, men pluginet skal stadig opdateres og vedligeholdes.
4. Hvem kan overtage det? Vær skeptisk over for løsninger, som kun én person forstår, eller hvor indholdet er låst inde i et proprietært format.
5. Hvad sker der, hvis værktøjet forsvinder? Jo mere forretningskritisk funktionen er, desto vigtigere er dokumentation, eksportmuligheder og en plan B.

Målet er ikke nødvendigvis det lavest mulige antal plugins. Målet er den mindste samling af velvalgte værktøjer, der løser de reelle behov og kan vedligeholdes efter lanceringen.

Den bedste stack er ikke den længste liste

Det her er den WordPress plugin-stack, vi bygger med i NyeHøjder i sommeren 2026.

Den er markant anderledes end den stack, vi brugte for bare et år siden, og den vil næsten sikkert ændre sig igen.

Det er ikke et tegn på, at vi ikke ved, hvad vi laver. Det er en del af arbejdet.

Vi tester løbende nye muligheder, men vi skifter ikke værktøj for forandringens skyld. Et nyt værktøj skal løse et reelt problem bedre end det gamle, og gevinsten skal være større end omkostningen ved at skifte.

Vores kunder betaler ikke for, at vi er loyale over for et pluginlogo. De betaler for, at vi kan vælge, implementere og vedligeholde det system, deres hjemmeside bygger på.

Jeg har brugt utroligt meget tid og mange penge på at lære det gennem forsøg, fejl og rigtige projekter. Hvis den erfaring kan spare dig for bare nogle af de samme omveje, har indlægget gjort sit arbejde.

Hvilket værktøj i din egen WordPress-stack er du mest i tvivl om lige nu? Skriv det gerne i kommentarfeltet. Det fortæller mig, hvilke beslutninger det faktisk er svært at navigere i – og hvad det giver mening at dykke ned i næste gang.