Hvad der konkret går galt når en hjemmeside ikke vedligeholdes — uanset stack

"Min hjemmeside er bygget på Shopify — jeg behøver ikke vedligeholdelse." Eller: "Vi er på Next.js, det opdaterer sig selv." Eller: "Vi har auto-updates på WordPress, så vi er dækket."

Alle tre er forkerte. Hver stack har sine egne svigt-mønstre når den ikke vedligeholdes — og forskellen er bare HVOR fejlene rammer, ikke OM de rammer.

Lad mig være konkret. Det her er fejl jeg har set i produktion de sidste 12 måneder, fordelt på stack.

WordPress + WooCommerce

WordPress driver 43% af internettet. Det betyder også at WordPress er angrebsmål nr. 1 for automatiserede bots. Her er hvad der sker når en WP/WC-side bliver liggende.

1. Plugin-konflikt efter WooCommerce-major-release WooCommerce udgiver et major release ~hvert 4. måned. Dine 15-30 plugins er ikke alle kompatible med det samme tidsrum. Resultat: en plugin der ikke er opdateret stopper checkout uden synlig fejl. Kunder kan komme til checkout, men "Place order" gør ingenting. Konverterings-rate falder til 0% på dele af trafikken.

Detection-tid uden monitoring: typisk 3-9 dage. Indtil en kunde ringer eller en revisor kigger på omsætningstal.

2. PHP-deprecation gør admin utilgængelig Hosting-udbyderen opgraderer PHP fra 8.1 til 8.3. Et af dine plugins bruger en deprecated function. WP-admin viser hvid skærm — du kan ikke logge ind. Forsiden virker stadig (cache), men du kan ikke ændre noget.

Realt eksempel: En kunde der havde 14 måneder gamle plugins. PHP-opgraderingen ramte natten over. Forsiden var oppe i 5 dage uden mulighed for at opdatere produkter eller priser, indtil de fandt en der kunne hjælpe.

3. Brute force på /wp-login.php Standardplaceringen af WP-admin er hvad scriptede bots prøver. Hvis du ikke har rate-limiting eller 2FA, vil du have 200-2.000 forsøg om dagen. Det belaster serveren, og hvis en bruger har et svagt password, er det et spørgsmål om tid før de er inde.

4. Outdated theme bruger gamle WP-funktioner Theme er fra 2019. Bruger en API der blev fjernet i WP 6.4. Forsiden ser fin ud, men 3 sider deep crasher med fatal error. Google ser fejlerne og deindekserer dem stille.

5. wp-cron der ikke kører WooCommerce' baggrunds-jobs (mail-sending, abandoned cart, stock-updates) kører på wp-cron, der hænger på besøgs-trafik. Sider med lav trafik får cron-tasks der bygger op i køen. Mails sendes ikke. Lager-niveauer er forkerte. Ordrer fastlåses i "Processing".

Shopify

"Shopify er managed, så jeg behøver ikke vedligeholdelse." Det er delvist sandt. Shopify holder selv platformen opdateret. Men det er HALVDELEN af din side.

1. Apps der opsiges eller går konkurs Du har 15-25 Shopify Apps installeret. Hver app er et separat firma. Mindst én af dem (typisk 1-3 om året) bliver enten: - Opsagt af udvikleren (sælger virksomheden eller stopper) - Inkompatibel med Shopify's nye API-version - Acquired og prisen 5-dobles

Resultat: en feature på din side stopper. Hvis du ikke opdager det, kører siden videre med en delvis funktion (fx ingen reviews vises, eller upsell-bannere vises ikke).

2. Theme-update tager hardcoded customizations med sig Theme-developeren udgiver en ny version. Du har customiseret liquid-koden direkte. Når du opdaterer themet, mister du alle dine ændringer.

Korrekt approach: customizations i et child-theme. Men 80% af de Shopify-shops jeg ser har gjort det direkte i parent-themet.

3. Shopify's egne breaking changes på Checkout Extensibility Shopify migrerer fra checkout.liquid til Checkout Extensions. Apps der ikke er opdateret virker ikke i den nye checkout. Hvis dit bureau ikke har tjekket dette, vil din checkout fra august 2024 være en hybrid hvor nogle features virker og andre ikke.

4. Metafield-schemas der drifter Du har custom metafields på produkter (fx ingredienser, materialer). Når Shopify ændrer metafield-API, holder dine custom queries op med at returnere data. Side viser tomme felter — men ingen error.

5. SEO-redirects der ikke vedligeholdes Når du fjerner et produkt, skal der laves en 301-redirect til en relevant kategori. Sker det ikke automatisk? På de fleste Shopify-shops nej. Resultat: hundredvis af 404'ere over tid, og SEO-juice der lækker.

Next.js / Headless

"Vi er på Next.js, det er moderne — vi behøver ikke vedligeholdelse." Sjovt nok er Next.js-sider ofte de værste til at vedligeholde, fordi ejerne tror at "moderne stack" betyder "self-maintaining".

1. Node.js LTS-version expirer Node.js LTS-versioner supporteres typisk i 30 måneder. Vercel og lignende platforme tvinger upgrade. Hvis din side bruger deprecated APIs, brækker den.

2. Dependencies med kritiske sårbarheder Et typisk Next.js-projekt har 800-1.500 transitive dependencies via npm. Hver uge findes der nye sårbarheder i nogle af dem. Hvis du ikke har `npm audit` i CI eller månedlig Dependabot-review, kører din side med kendte CVE'er som angribere kan exploitere via dependency-confusion eller supply-chain attacks.

3. Next.js-major-versions med breaking changes Next.js 13 → 14 → 15 → 16 har alle haft breaking changes (App Router, async params, fetch caching, etc.). Hvis du bygger en gang og glemmer den, vil dine deployments efter 12-18 måneder fejle fordi peer dependencies kræver nyere versioner.

4. Stale ISR/cache-bugs Incremental Static Regeneration kører i baggrunden. Hvis en regenerate-request fejler (database timeout, API-fejl), serverer Next.js den gamle version. Du kan have produkter der har været udsolgt i 3 uger men stadig vises som "På lager" — uden nogen fejl-rapport.

5. CDN edge-caches der ikke flushes Vercel/Cloudflare cacher aggressivt. Hvis du laver en ændring uden at flushe, vises ændringen kun nogle steder i verden. Test fra én browser ser fint ud, mens 30% af besøgende ser gammel content.

6. Environment variables der udløber Tredje-parts API-keys (Stripe, SendGrid, Algolia) skal forny. Hvis ingen kigger på det, går de ud, og features stopper stille uden synlig fejl i UI'en.

Custom-bygget (egen kode, egen server)

Det her er den dyreste at neglecte fordi der er færre off-the-shelf-løsninger.

1. SSL-certifikat udløber Hvis du bruger Let's Encrypt med auto-renew via certbot, og servercertifikatet skifter, brækker auto-renew. Hver 90. dag — uden warning — viser din side "Not Secure". Browser-trust forsvinder.

2. Database-schema-drift Migrations er ikke kørt. Backup-scripts virker, men restoren tester ingen. Når du faktisk har brug for backup, opdager du at den ikke kan restores.

3. Log-files fylder disken Server-disken fyldes med logs, db-dumps, og temporary files. Dag 500 fyldes disken — applikationen crasher fordi den ikke kan skrive til logs.

4. Manglende OS-security-patches Ubuntu/Debian release security patches ugentligt. Hvis du ikke kører `unattended-upgrades` eller månedlig manuel review, samler kendte CVE'er sig.

5. Cron-jobs der fejler stille Daglige jobs (backup, billing, email-digest) crasher pga. en eksternt API-ændring. Du ved det ikke fordi cron mailer ikke ved fejl — og hvem læser /var/mail anyway.

Tværgående problemer (uanset stack)

Det her rammer alle stacks lige.

1. DNS-config-drift DKIM/DMARC/SPF-records udløber eller bliver forkert konfigureret. Dine mails havner i spam — du opdager det først når kundeservice klager over mange "har I virkelig modtaget min ordre?"-mails.

2. Tredjeparts-integrationer der ændrer API Stripe v1 → v2. Mailchimp ændrer endpoint. Klaviyo skifter auth-format. Hvis du har en webhook-integration der ikke er rørt i 18 måneder, er sandsynligheden for at den stopper >50%.

3. Domain registrant-bruger der forlader virksomheden Hvis domænet er registreret på en gammel medarbejder/ekstern udviklers konto, og de forlader uden at overdrage — gæt selv hvor svært det bliver at forny eller flytte.

4. Google Search Console-warnings ingen læser Google sender alerts om indexerings-problemer, manuelle actions, structured data-fejl. Hvis ingen tjekker GSC månedligt, opdager du først problemerne når organisk trafik er faldet 30%.

5. Performance-degradering over tid Hver eneste tilføjelse (et nyt script, et nyt billede, en ekstra tracking-pixel) gør siden langsommere. Uden månedlig Core Web Vitals-review degraderer hastigheden mærkbart over 12-24 måneder, og Google ranker dig lavere.

Den kommercielle realitet

Det er ikke et spørgsmål om OM noget på din side vil fejle de næste 12 måneder. Det er et spørgsmål om HVOR og HVOR DYRT.

For en gennemsnitlig dansk SMV-hjemmeside, der bidrager til omsætning:

• →Sandsynlighed for mindst én alvorlig fejl over 12 mdr uden vedligeholdelse: ~75%
• →Gennemsnitlig nedetid pr. fejl: 2-7 dage
• →Gennemsnitlig direkte omkostning pr. fejl: 5-25.000 kr.
• →Gennemsnitlig indirekte omkostning (mistet trafik, kunder, omdømme): 10-50.000 kr.

Vedligeholdelse koster typisk 2.500-18.000 kr/år. Det er en absurd god ROI på en risiko-forsikring.

Hvad ordentlig vedligeholdelse SKAL inkludere — uanset stack

Hvis dit bureau ikke har de her fem ting i deres vedligeholdelses-pakke, er det ikke vedligeholdelse:

• →Monitoring der detekterer fejl før kunderne (uptime + funktionelle checks + log-analyse)
• →Verificerede backups — ikke bare "vi tager backup" men "vi tester restore månedligt"
• →Proaktive opdateringer på staging før produktion — aldrig direkte på produktion uden test
• →Security-scanning — ugentlige scans mod kendte CVE'er
• →Månedlig status-rapport — du skal kunne se hvad der er gjort, hvad der er forhindret, hvad der står på roadmap

Hvad du bør gøre

Hvis du har en hjemmeside du er afhængig af for omsætning, og du ikke aktivt får leveret de fem punkter ovenfor:

• →Få lavet en gratis sundheds-scan af din nuværende side. Vi laver dem på 30 min, og giver en konkret risiko-rapport.
• →Bed dit nuværende bureau om en rapport over hvad de har gjort de sidste 90 dage. Hvis de ikke kan svare præcist, har de ikke vedligeholdt.
• →Skift til en vedligeholdelses-aftale med fast scope og månedlig rapportering — uanset hvem du vælger.

Hvis du vil have os til at lave sundheds-scanen: kontakt os her. Gratis, ingen forpligtelse, 30 min af min tid.

Læs videre

• →En WordPress-side uden vedligeholdelse er en tidsbombe
• →'Ingen binding' er det dyreste løfte du kan give din kunde
• →Hjemmeside til 0 kr — hvad du faktisk får