Teknisk gæld: Regningen kommer altid — og den vokser med renters rente
Forestil dig, at din virksomhed købte en maskine, der var livsnødvendig for produktionen. Hver dag kører den, men du skifter aldrig olie. Du udskifter ikke sliddele. Du lader de små advarselslamper sidde, fordi "det virker jo stadig".
De fleste SMV-ejere ville kalde det vanvid. Men præcis det samme gør de med deres website og digitale systemer hver eneste dag.
Hvad teknisk gæld rent faktisk er
Teknisk gæld er alt det, du burde have gjort, men ikke gjorde. Det er:
- WordPress-versionen, der er tre udgaver bagud, fordi "sidste gang gik noget i stykker"
- Plugins, der ikke er blevet opdateret i to år, fordi de stadig virker
- Det hurtige CSS-fix, der blev smidt ind i stedet for den rigtige løsning
- E-mail-formularen, der ikke håndterer fejl korrekt, så kundehenvendelser forsvinder sporløst
- Koden, der fungerer fint, men som ingen andre tør røre ved, fordi de ikke forstår den
- Siden, der loader på 4 sekunder, fordi ingen har ryddet op i gamle scripts
Hver eneste af dem er et lille lån. Og ligesom med rigtige lån: jo længere du venter med at betale, jo mere koster det.
Gældsspiralen: hårdere i SMV'er end i store virksomheder
Store virksomheder har et helt IT-hold til at fordele den tekniske gæld ud på flere personer. De har budget til at sætte en uge af til "tekniske forbedringer" et par gange om året.
SMV'er har én person, oftest ejeren, der også skal drive forretning, sælge, levere og bokse med banken.
Resultatet: den tekniske gæld akkumulerer hurtigere, fordi der aldrig er tid til at betale af. For hvert år, du venter, bliver lånet dyrere:
| Tidspunkt | Hvad sker der |
|---|---|
| Første år | Siden virker. Du bemærker ikke noget. |
| Andet år | Opdateringer tager længere tid. Der dukker små advarsler op. |
| Tredje år | Plugins bliver inkompatible. Noget virker ikke efter en opdatering. Du overvejer at skifte platform. |
| Fjerde år | Et problematisk plugin eller en kendt sårbarhed gør, at du ikke kan opdatere længere. Reparationen bliver større end den løbende drift altid ville have været. |
Det er det forløb, jeg ofte overtager: det, der startede som "det fikser vi næste måned" i år 1, ender som en presset reparation i år 4, fordi ét plugin endelig har spredt et problem, der lå skjult hele vejen. Jeg kan ikke dokumentere et gennemsnitligt beløb for det, fordi det afhænger helt af, hvor dybt gælden sidder. Men forskellen mellem "reparer på en time" og "kan ikke opdatere, fordi backup og adgang er uklare" er den største enkeltpost i regningen.
De 4 dyreste former for teknisk gæld i SMV-land
1. Forældet CMS eller platform
Hvis dit website kører på et CMS, der ikke længere får sikkerhedsopdateringer, er det ikke bare gammelt, men en risiko. WordPress skriver det selv i Hardening WordPress: ældre versioner vedligeholdes ikke længere med sikkerhedsopdateringer, og når en sårbarhed opdages og lappes, er gamle versioner mere udsatte, fordi informationerne om udnyttelsen som regel er offentligt tilgængelige.
Samtidig understreger WordPress, at din hosting ikke er ansvarlig for den applikation, du har valgt at installere. Infrastruktur og gæld er to forskellige regninger.
Løsning: vær på en platform, der aktivt vedligeholdes, og hold den opdateret. WordPress har haft automatiske opdateringer siden version 3.7, så "opdateringer tager for lang tid" er som regel et spørgsmål om, at nogen har slået dem fra.
2. Utestet backup
"Vi har backup" er en af de farligste sætninger i SMV-DK. WordPress anbefaler at tage regelmæssige snapshots af hele installationen, både filer og database, og at opbevare dem et pålideligt sted. Men en backup uden bevis på, at den kan gendannes, er en backup, du ikke har.
Se på, hvad der typisk fejler, når siden først brænder:
- Backuppen har ikke kørt i måneder, fordi en ændring på serveren slog cron-scriptet ihjel
- Gendannelsen kræver en PHP-version, som din hosting ikke længere understøtter
- Backuppen indeholder kun databasen og ikke filerne, eller omvendt
Løsning: test din backup. Sæt en kalenderpåmindelse én gang hver måned: gendan til et testmiljø. WordPress peger i hardening-guiden også på dataintegritet: krypter backuppen, og hav en uafhængig kontrol med hashes, så du kan se, om filerne er blevet ændret. Hvis gendannelsen virker, er du godt dækket. Hvis ikke, har du netop sparet dig selv for en kæmpe regning.
3. Ingen dokumentation
Den person, der byggede dit website, stoppede for to år siden. Koden har ingen kommentarer. Adgangskoderne står på en Post-it under tastaturet hos ham, der stoppede. Login til hostingen eksisterer kun som en slettet mail.
Når noget går i stykker, starter du forfra med timevis af gravearbejde for at finde ud af, hvordan tingene hænger sammen. Og du betaler en udvikler for at lære din egen side at kende.
Løsning: brug en password manager (Bitwarden, 1Password), og slå totrinsgodkendelse til på din WordPress-adgang. WordPress anbefaler det direkte, fordi adgang til en administratorkonto giver adgang til hele serveren. Dokumentér server-setup, domæner, DNS og kritiske adgange ét sted. Del det med præcis dem, der skal bruge det.
4. "Det virker, så lad det være"
Den mest snigende form. Siden virker. Den skuffer ikke. Men hvert år du ikke opdaterer, bygger du på en stak af kompromiser, der en dag vælter.
Løsning: teknisk vedligeholdelse er ikke en udgift, men en forsikring. Den sikrer, at din side er oppe, sikker og hurtig. Springer du den over, sparer du den månedlige drift og ender i stedet med en akut reparation, der koster mere, fordi valgene så ikke længere er dine. På sitet ligger den løbende drift fra 2.500 kr. pr. måned; et website-tjek med overblik og prioriteret roadmap ligger på 9.000 kr. Se pakkerne for hele prisarkitekturen.
Hvordan AI gør oprydningen billigere
En manuel gennemgang af et website for teknisk gæld er efter min erfaring et dagsarbejde: logge ind, inspicere plugins, tjekke sikkerhed, måle hastighed, læse logs og skrive en rapport.
I dag bruger jeg AI til:
- Automatiseret gennemgang: scan hele sitet for forældede pakker, kendte sårbarheder og konfigurationsfejl på minutter
- Kodeanalyse: find inkompatible plugins, forældede funktionskald og sikkerhedshuller i custom-kode
- Loganalyse: find mønstre i fejlene, fx en formular, der taber henvendelser i korte perioder, eller et billede, der crasher ved upload
Det gør gennemgangen billig nok til, at den kan gentages, så den bliver en del af den løbende drift frem for en engangsreparation. AI'en gennemgår og sorterer; beslutningen og ansvaret er stadig mine.
Sådan bryder du spiralen
Hvis du genkender dig selv i ovenstående, er vejen ud ret ligetil, men den kræver, at du tager det første skridt:
- Få et overblik. Hvad kører der? Hvornår blev det sidst opdateret? Er der backup? Få et ærligt sæt af svar.
- Luk hullerne. De kritiske (sikkerhed, backups, dokumentation) ordnes først. Alt andet kan vente en uge.
- Læg en plan for resten. Teknisk gæld betales af i rater. Prioritér det, der giver mest værdi for færrest timer.
- Sørg for, at det ikke sker igen. Løbende vedligeholdelse koster langt mindre end akut ombygning. Sæt et system op, der automatisk holder dig ajour.
Audit-tjeklisten: otte kontroller, du kan køre selv
De fire forbedringsmuligheder ovenfor er diagnosen. Her er den konkrete tjekliste, jeg selv gennemgår et site med. Sæt kryds ved dem, du kan svare ja til. Resten er din gæld.
1. Driftsmiljø og krav
- Kører WordPress på PHP 8.3 eller nyere, MariaDB 10.11+/MySQL 8.0+ og HTTPS? Det er det, WordPress selv anbefaler. Ældre versioner er officielt end-of-life og kan efterlade dig med sikkerhedshuller.
- Er WordPress-core opdateret til den seneste version?
2. Temaer og plugins
- Er alle plugins opdateret, og har de været opdateret siden sidste kerneopdatering? Ifølge WordPress' egen plugin-dokumentation kan et plugin, der ikke er opdateret siden den seneste core-opdatering, være inkompatibelt eller have ukendt kompatibilitet.
- Er ubrugte plugins slettet, ikke bare deaktiveret?
- Har du tjekket
wp-content/mu-plugins? Must-use plugins dukker ikke op i plugin-listen og kan kun fjernes ved at slette filen.
3. Opdateringsstand
- Kan du køre "Opdater nu" uden at være bange for følgerne?
- Er automatiske opdateringer slået fra, og ved du hvorfor?
- Tager du en frisk kopi af databasen, før du opdaterer?
4. Backup
- Tager du jævnligt snapshots af både filer og database, og ligger de uden for webroden?
- Er den seneste backup verificeret, ikke bare grøn i oversigten?
5. Restore-test
- Har du genskabt en backup for nylig, og ved du, hvor lang tid det tog? En backup, der aldrig er testet, er en backup, du ikke har.
6. Adgang
- Kender du alle aktive admin-konti, og er det kun dig, der har adgang til hosting og domæne?
- Er der totrinsgodkendelse på, og bruger hver konto sin egen stærke adgangskode i en password manager?
7. Formularer og lead-rute
- Har du indsendt din egen kontaktformular for nylig og set henvendelsen komme frem?
- Findes der en fejllog, du faktisk har set på, så en svigtende formular ikke kan stå skjult i en måned?
8. Næste konkrete ejerhandling
- Har du ét navngivet tidspunkt, hvor der sker noget: hvem, hvad og senest hvornår? Ellers er det ikke en plan, men en hensigt.
Prioritér fundene: P0 til P3
Når listen er gennemgået, er spørgsmålet ikke "hvad fejler der", men "hvad gør jeg først". Jeg prioriterer i fire niveauer, og rammen er min redaktionelle syntese, ikke en WordPress-standard:
| Niveau | Hvad der hører her | Hvorfor først |
|---|---|---|
| P0: akut | Aktivt nedbrud, fejl på henvendelsesruten, kendt kompromittering eller en backup, der ikke findes eller ikke kan gendannes | Skaden sker nu, og hver dag gør den dyrere |
| P1: sikkerhed | Kerne/PHP/database/HTTPS under minimum, forældede plugins, ubrugte plugins liggende, gammelt administratorlogin uden totrinsgodkendelse | Mindsker risikoen, mens du stadig kan vælge selv |
| P2: gendannelse og overvågning | Utestet backup, ingen fejllog, ingen dokumentation, ingen adgangs- og adgangskodehåndtering | Gør den næste fejl hurtigere at opdage og nemmere at komme ud af |
| P3: ydeevne og hygiejne | Langsomhed, gamle scripts, skjulte CSS-fixes, SEO-teknik | Måles og optimeres, når de tre foregående er lukket |
Rækkefølgen er vigtigere end listen. En P3-hastighedsoptimering på en side med en manglende backup (P0) er spildt arbejde.
Bevare, reparere eller modernisere?
Når gælden er kortlagt, er beslutningen typisk en af tre:
- Bevare. Sund kerne, opdateret, backup verificeret. Gælden er overfladisk. Ryd op, og stop med at ændre ved den.
- Reparere. Der er konkrete huller, men arkitekturen holder. Det er det billigste valg og det, de fleste SMV'er bør starte med.
- Modernisere. Selve fundamentet bærer ikke længere: flere plugins, end løsningen er værd, eller der kræves en PHP/database-opgradering, der ikke kan gennemføres uden nedetid. Nyere WordPress stiller krav om PHP 8.3+, MariaDB 10.11+/MySQL 8.0+ og HTTPS, så det er her, en gammel installation ofte ender.
Hvis du ikke kan svare på, hvilken af de tre din side er, er det præcis det, en audit skal svare på.
Få et konkret svar: website-tjek til fast pris med prioriteret roadmap
Fast pris, 5-7 hverdage. Du får audit + overblik, en prioriteret roadmap (impact/effort) og et anbefalet næste skridt, ikke en 40-siders rapport.
Kilder
De konkrete krav og anbefalinger i denne artikel er hentet fra WordPress' egen dokumentation og kontrolleret 25. september 2026:
- Requirements — PHP 8.3+, MariaDB 10.11+/MySQL 8.0+, HTTPS
- Manage Plugins — kompatibilitet, backup før opdatering, slet ubrugte plugins, must-use plugins
- Hardening WordPress — forældede versioner, ansvar mellem hosting og applikation, adgangskonti, totrinsgodkendelse, backups, dataintegritet, logging og monitorering
Priserne nævnt i artiklen er Mahopes egne, offentlige priser: løbende drift fra 2.500 kr. pr. måned (pakker) og sikkerhedstjek på website-tjekket til 9.000 kr.
