Din standardopsætning: en genbrugelig base for nye WordPress-sites

Kort svar: En standardopsætning er et klonbart skabelonsite: ét tema, I kender til bunds, én plugin-stak med præcis ét værktøj pr. opgave, faste konfigurationer (roller, permalinks, sprog, sikkerhed) og jeres dokumentation indbygget. Nye projekter starter som en kopi af basen – aldrig fra en tom WordPress – og basen revideres hvert kvartal med en changelog. Gevinsten er dobbelt: timer sparet pr. projekt og en portefølje, hvor alle sites fejlfindes ens, fordi de er bygget ens.

Fagligt gennemgået: 2. oktober 2026

Mange bureauer ender i den samme fælde: hvert site er sit eget lille kunstværk. 30 sites med 30 temaer, 30 plugin-kombinationer og 30 måder at gå i stykker på. Modtrækket er en standardopsætning – bilfabrikkens platformstænkning overført til WordPress: samme bund under alle, forskellen ligger i karosseriet.

Her er, hvad basen skal indeholde, hvordan du gør den klonbar, og hvordan du holder den i live.

Hvorfor én base slår 30 kunstværker

Standardisering handler mindre om opstartstiden og mere om alt det, der kommer bagefter:

• Driften skalerer, fordi én opdateringsrutine passer til alle sites – se drift af kundesites.
• Fejlfinding går hurtigt, fordi alle sites fejler på de samme genkendelige måder.
• Nye medarbejdere bliver hurtigt produktive, fordi der kun er én måde at bygge på.
• Dine SLA-løfter bliver billige at holde, fordi risikoen er ens overalt.

Hver afvigelse fra basen er til gengæld en ekstraomkostning, der følger sitet resten af dets levetid. Afvigelser skal derfor vælges, fordi kunden har et reelt særbehov – de må aldrig bare ske, fordi en udvikler havde lyst til at prøve noget nyt.

Hvad basen indeholder

Temaet eller builderen: ét, som hele teamet kender til bunds, valgt på vedligeholdelseshistorik og performance – ikke på demositets udseende. Overvejer du en visuel builder, kan du sammenligne to udbredte valg i guiden til Bricks Builder eller Breakdance.

Plugin-stakken: ét værktøj pr. opgave – SEO, formularer, sikkerhed, billedoptimering osv. – hver med en linje om, hvorfor netop det er valgt. Lige så vigtigt er en liste over bevidste fravalg, så diskussionerne ikke starter forfra hvert kvartal. Cache og backup hører som udgangspunkt til i hostinglaget, ikke i plugin-listen.

Konfigurationen: permalinks, sprog og tidszone, roller efter mindste privilegium, kommentarindstillinger, billedstørrelser og de små indstillinger, ingen kan huske, men alle glemmer.

Dokumentationen: en „om dette site“-side i wp-admin eller i jeres dokumentationssystem, der følger med i hver kopi og udfyldes pr. kunde.

Sikkerheds- og driftsindstillinger, der hører med

Nogle valg er så grundlæggende, at de bør være låst i basen og ikke afhænge af den enkelte udvikler:

• Filredigering slået fra i wp-admin med DISALLOW_FILE_EDIT i wp-config.php, så en kompromitteret administratorkonto ikke kan skrive kode direkte – se wp-config-hærdning.
• Totrinslogin klar til alle administrator- og redaktørkonti.
• Begrænset antal revisioner med WP_POST_REVISIONS, så databasen ikke vokser unødigt.
• Ubrugte standardplugins og -temaer fjernet, så der er færre filer at opdatere og angribe.
• En fast opdateringspolitik, der beskriver, hvad der opdateres automatisk, og hvad der testes først – se opdateringspolitikken.

Fra tjekliste til klonbart blueprint

Tjeklisten er første skridt, men mennesket, der følger den, springer punkt 14 over en travl torsdag. Målet er derfor et blueprint: et færdigt skabelonsite, der kopieres som start på hvert projekt.

Der er to gængse måder at gøre det på. Enten holder du et skabelonsite kørende og kopierer det med et migrerings- eller kloningsværktøj til hvert nyt projekt. Eller også vedligeholder du basen som et script, der bygger et nyt site fra bunden med de samme valg hver gang. Mange bureauer kombinerer de to: et script til konfigurationen og en eksport til indholdsstrukturen.

Byg to varianter, „site“ og „shop“ med WooCommerce-laget oveni, og modstå fristelsen til flere. To blueprints kan holdes i live, seks kan ikke. Kopien går derefter gennem jeres normale ændringsproces som ethvert andet stykke arbejde.

Basen som WP-CLI-script

Har hostingen SSH og WP-CLI, kan konfigurationsdelen af basen skrives som et kort script. Fordelen er, at scriptet selv er dokumentationen: det viser præcis, hvad der sættes, og det kan versionsstyres. Et forenklet eksempel, hvor værdierne i vinkelparenteser udskiftes pr. projekt:

# Sprog, tid og datoformat
wp language core install da_DK --activate
wp option update timezone_string "Europe/Copenhagen"
wp option update date_format "j. F Y"

# Permalinks og kommentarer
wp rewrite structure '/%postname%/' --hard
wp option update default_comment_status closed

# Skjul sitet for søgemaskiner, mens det bygges
wp option update blog_public 0

# Ryd op og installér stakken
wp plugin delete hello akismet
wp plugin install <plugin-slug> --activate

# Hærdning i wp-config.php
wp config set DISALLOW_FILE_EDIT true --raw
wp config set WP_POST_REVISIONS 20 --raw

Vigtigt: Indstillingen blog_public 0 beder søgemaskiner om ikke at indeksere sitet. Sæt den tilbage til 1 ved lancering, og skriv punktet ind i jeres lanceringstjekliste – det er en klassisk fejl, at et nyt site går live uden at kunne findes.

Licensnøgler, adgangskoder og API-nøgler hører aldrig hjemme i scriptet. Hent dem fra jeres kodeordsmanager ved opsætningen.

Hostingen som en del af basen

Basen stopper ikke ved WordPress. PHP-version, cache, backup og staging bør også være ens på tværs af porteføljen, ellers opfører to „ens“ sites sig forskelligt. Vælg derfor én hostingopsætning til basen og hold dig til den.

På WordPress hosting hos Hostious kører alle pakker på LiteSpeed og NVMe med daglig og manuel backup samt selvbetjent gendannelse. Fra WP StartUp følger staging med, så kopien af basen kan testes, før den går live, og fra WP StartUp og opefter er der en pluginpakke med bl.a. FlyingPress, Breakdance, Bricks Builder og SureRank Pro. Bureauer med mange kundesites kan læse mere i guiden til bureau hosting til WordPress og WooCommerce.

Hold basen i live

En standardopsætning, ingen vedligeholder, er bare gammel praksis med selvtillid. Sæt en kvartalsvis revision i kalenderen: Er alle valg stadig de rigtige? Opdateres pluginet stadig? Er der kommet noget bedre? Hvad har projekterne lært os, og hvad skal ind eller ud?

Før en kort changelog, fx „Q3: skiftede formularplugin på grund af licensændring“. Den er guld værd, når du om to år står med et site fra dengang og skal forstå fortidens valg, og den hører naturligt hjemme i jeres værktøjskasse-dokumentation.

Ændringer i basen gælder som udgangspunkt kun nye sites. Rul kun ændringer bagud, når sikkerhed eller licenser kræver det. Så undgår du at forstyrre 30 stabile sites for at tilfredsstille én ny idé.

Byg basen uden at stoppe forretningen

Du behøver ikke en projektuge for at komme i gang: byg basen af det næste projekt. Tag det kommende kundesite, dokumentér hvert valg undervejs – tema, plugins, indstillinger og hvorfor – og gem resultatet som første udgave af blueprintet, før kundens indhold lægges på.

Næste projekt starter så fra kopien og gør den lidt bedre. Efter tre–fire projekter har du en gennemprøvet base, der aldrig kostede et internt projekt. Undervejs opdager du uenigheder i teamet („jeg plejer nu at bruge …“). Tag dem én gang, skriv afgørelsen ned, og lad changeloggen være dommer fremover. Diskussionerne flytter fra hvert projekt til ét kvartalsmøde, og hverdagen bliver at bygge.

Læs også

• Hub: For bureauer og freelancere
• Drift af 20+ kundesites: værktøjer og rutiner, der skalerer
• Det nedarvede site: håndtér teknisk gæld fra det forrige bureau
• WP-CLI for begyndere: 10 opgaver, du aldrig mere gør i hånden
• WordPress hosting hos Hostious – staging fra WP StartUp og pluginpakke fra WP StartUp og opefter

Ofte stillede spørgsmål om standardopsætningen

Hvad skal en standardopsætning til WordPress indeholde?

Ét gennemprøvet tema, én plugin-stak med ét værktøj pr. opgave inklusive dokumenterede fravalg, faste konfigurationer for roller, permalinks og sikkerhed – og indbygget dokumentation.

Er et skabelonsite bedre end en tjekliste?

Ja, en kopi kan ikke springe punkt 14 over. Tjeklisten beskriver basen, blueprintet er basen. Hold højst to varianter, site og shop, så de kan vedligeholdes.

Skal ændringer i basen rulles ud til eksisterende sites?

Som udgangspunkt nej, kun når sikkerhed eller licenser kræver det. Basen gælder fremadrettet, og 30 stabile sites skal ikke forstyrres af én ny præference.

Skal basen bygges som script eller som skabelonsite?

Begge virker. Et WP-CLI-script er let at versionsstyre og dokumenterer sig selv, mens et skabelonsite også rummer indholdsstruktur og builder-skabeloner. Mange bureauer bruger scriptet til konfigurationen og skabelonsitet til resten.