Nettstedet starter ikke, nettbutikken tar ikke imot bestillinger, eller kontrollpanelet slipper deg ikke inn etter en oppdatering. Jeg heter Mariusz Szatkowski og har jobbet med WordPress siden 2006. Jeg begynner med fakta, tar en kopi, finner laget som sviktet og tester reparasjonen på den samme flyten der feilen oppsto. Siden beskriver også løpende vedlikehold: oppdateringer, sikkerhetskopier og overvåking som gjør at feil oppstår sjeldnere.
Hvem du ansetter
- Kommersiell WordPress siden 2006, før Gutenberg og REST API
- Senior-ledet: ingeniøren fra discovery er den samme i uke seks
- Ingen offshore-overlevering, ingen PM-kostnad fakturert
- WordCamp Europe-arrangør, WordPress Foundation Credits-mentor
- Shopify Academy: CRO-læringssti pluss Partner Marketing (Credly, 2025)
WordPress-reparasjon: symptom, årsak og et trygt første steg
De vanligste feilene har årsaker som er beskrevet i WordPress-dokumentasjonen. Tabellen viser hva som som regel ligger bak symptomet, og hva du kan sjekke selv uten å gjøre vondt verre. Hjelper ikke det første steget, eller har du ikke tilgang til filene, stopper du der og sender en beskrivelse.
| Symptom | Vanligste årsak | Trygt første steg |
|---|---|---|
| Hvit skjerm uten feilmelding | PHP-feil i en utvidelse eller et tema, ofte rett etter en oppdatering | Gi mappen wp-content/plugins et nytt navn via SFTP, og hvis det ikke hjelper, mappen til det aktive temaet |
| «En kritisk feil har inntruffet på dette nettstedet.» | En kritisk PHP-feil som WordPress har fanget opp (fra versjon 5.2) | Sjekk innboksen til administratoradressen: e-posten inneholder en lenke til gjenopprettingsmodus, som setter den skyldige utvidelsen på pause |
| 500 Internal Server Error | Skadet .htaccess-fil, en utvidelse eller minnegrensen | Gi .htaccess et nytt navn, og når nettstedet er oppe igjen, lagre Innstillinger, Permalenker på nytt |
| Feil: klarte ikke å etablere databasetilkobling | Feil opplysninger i wp-config.php eller en databaseserver som ikke svarer | Sammenlign DB_NAME, DB_USER, DB_PASSWORD og DB_HOST med kontrollpanelet hos webhotellet, og spør leverandøren om status for MySQL |
| Allowed memory size exhausted | For lav minnegrense i PHP eller kode som bruker opp minnet i en løkke | Øk WP_MEMORY_LIMIT i wp-config.php, og finn deretter ut hva som bruker så mye, for en høyere grense skyver bare problemet foran seg |
| Nettstedet står fast i vedlikeholdsmodus | En avbrutt oppdatering etterlot filen .maintenance | Slett .maintenance fra rotmappen og fullfør oppdateringen som ble avbrutt |
| Omdirigeringer til fremmede nettsteder, spam i Google-resultatene | Innbrudd, som regel via en utdatert eller forlatt utvidelse | Ikke slett filer i blinde: ta en kopi som bevis, bytt passord til kontrollpanelet, SFTP og databasen, og rydd deretter opp slik siden om å fjerne skadevare fra WordPress beskriver |
| WooCommerce-butikken tar ikke imot bestillinger | Konflikt mellom utvidelser, hurtigbuffer på handlekurven eller en feil hos betalingsløsningen | Åpne WooCommerce, Status, Logger og se hvilket steg bestillingen stopper på |
Kilder: Common WordPress Errors, Debugging in WordPress, Fatal Error Recovery Mode in 5.2, FAQ My site was hacked.
Vedlikehold av WordPress-temaer
Et nettsted bygd etter ditt eget design er i praksis et tilpasset WordPress-tema. Designet og oppsettet leverer du, jeg holder koden ved like: oppdateringer, feilretting og endringer i et Git-repository, slik at hver endring kan spores og rulles tilbake.
Dette bør du vite før du velger mellom å oppdatere selv og å sette det bort:
- WordPress, utvidelsene og temaet ditt får nye versjoner hele tiden. Står de uoppdatert, blir nettstedet lettere å angripe.
- De fleste angrep er automatiserte og blinde. Roboter prøver kjente hull på tusenvis av nettsteder, så et lite firmanettsted er like utsatt som et stort. Et innbrudd kan gå upåaktet hen, for eksempel når bare mobilbesøkende blir sendt videre til et fremmed nettsted.
- Jo lenger oppdateringene utsettes, desto vanskeligere og dyrere blir det å ta dem igjen.
- En oppdatering kan knekke nettstedet, enten delvis eller helt, med hvit skjerm. Derfor tester jeg den på staging først.
- Hver ekstra utvidelse øker både risikoen for konflikter ved oppdatering og angrepsflaten.
- At en utvidelse ikke får nye versjoner, betyr ikke at den er trygg. Den kan være forlatt.
- Ingen kan garantere full beskyttelse mot angrep. Det viktigste du kan ha, er sikkerhetskopier som tas jevnlig og lagres et annet sted enn nettstedet.
Er nettstedet bygd eller kraftig endret av et AI-verktøy, ser oppryddingen annerledes ut. Generert kode skjuler oftere feil antakelser enn åpenbare feil, og det tar jeg som et eget oppdrag under redning av AI-bygde nettsider.
Se hva nettstedet ditt viser offentlig
Oppgi adressen til et nettsted du driver. Vi henter det slik en nettleser ville gjort, og viser hva som følger av det, sammen med nøyaktig det vi leste.
Lim inn adressen til nettstedet ditt. Verktøyet henter siden slik nettleseren til en besøkende gjør, og viser svarkoden etter omdirigeringer, headere, hvor tung siden er ved oppstart og spor av WordPress. Det logger ikke inn og ser ikke kontrollpanelet, så det erstatter ikke en diagnose, men resultatet limt inn i henvendelsen forkorter den første samtalen. Hva verktøyet måler, er beskrevet i sin helhet på siden om WordPress-nettstedsjekk.
Hva dekker det løpende vedlikeholdet?
Et WordPress-nettsted blir ikke dårligere av seg selv, men miljøet rundt endrer seg: PHP-versjoner går ut, utvidelser får sikkerhetsrettelser, og webhotellet oppgraderer serveren. Vedlikeholdet holder tritt med det, slik at du slipper å oppdage problemene når en kunde melder fra.
- Oppdateringer av kjerne, tema og utvidelser, testet på staging før de går til produksjon.
- Sikkerhetskopier av filer og database med minst 30 dagers oppbevaring i EU-land, lagret utenfor webserveren.
- Oppetidsovervåking hvert 1. til 5. minutt med automatisk varsel til meg.
- Versjonskontroll av egen kode i Git, slik at en endring kan rulles tilbake.
- Feilretting når noe slutter å virke, etter samme forløp som en enkelt reparasjon.
- Databehandleravtale etter GDPR artikkel 28, signert før jeg får tilgang til nettstedet.
Hele avtalen er beskrevet under vedlikehold av WordPress-nettsider. Jeg har ingen døgnvakt og lover ingen fast responstid. Hvilke svarveier som gjelder, står i avtalen.
Hvordan foregår en WordPress-reparasjon?
- Henvendelse med fakta. Adressen til siden, når feilen oppsto, de siste endringene og hva som er blokkert: handlekurven, innloggingen eller publiseringen. Nettleser- og serverlogger og nøyaktige steg for å gjenskape feilen forkorter diagnosen mer enn skjermbilder.
- Kopi før endringer. Før jeg rører produksjon, tar jeg et gjenopprettingspunkt for filer og database, og når hendelsen tillater det, gjenskaper jeg feilen på staging.
- Isolering av laget. Hosting, WordPress-kjerne, tema, utvidelse, egen kode, ekstern API, hurtigbuffer eller DNS. Jeg retter det minste laget som har skylden, slik at et synlig symptom ikke ender i en unødvendig ombygging. Sitter feilen dypere, for eksempel i egne REST-endepunkter, betalingscallbacks eller databasen, tar jeg den som et oppdrag for en WordPress-spesialist.
- Test og notat. Reparasjonen er ferdig når den opprinnelige flyten og flytene rundt virker igjen. Ved en feil i kassen tester jeg betaling, bekreftelse, e-post og lagerendring, ikke bare at handlekurven lastes. Ved en redaksjonell feil tester jeg forhåndsvisning, publisering, medier, rettigheter og tømming av hurtigbuffer. Du får skriftlig hva som ble endret, hva som bevisst ble stående og hvordan endringen rulles tilbake.
Ligger årsaken utenfor min kontroll, for eksempel hos webhotellet eller betalingsleverandøren, får du dokumentasjonen og en plan for å begrense skaden, ikke en midlertidig omvei som kalles en løsning.
WordPress-support: dette bør du ha klart når du melder feilen
Mesteparten av tiden i starten går med til å få tilgang og finne ut hva som er endret.
Beskrivelse av feilen
- adressen til siden der problemet vises
- når det dukket opp første gang
- hva som ble endret rett før: en oppdatering, en ny utvidelse, en flytting, en DNS-endring
- teksten i feilmeldingen eller et skjermbilde
Tilganger
- en egen administratorkonto i WordPress, ikke din egen
- SFTP eller SSH til filene på nettstedet
- kontrollpanelet hos webhotellet med tilgang til databasen og feilloggene
- for nettbutikker: lesetilgang til kontrollpanelet hos betalingsløsningen
Send tilganger i en egen kanal, ikke i teksten i skjemaet. Når arbeidet er ferdig, sletter du kontoen du opprettet til meg og bytter SFTP-passordet. Det er god praksis med enhver leverandør. WordPress sine anbefalinger om passord, kontoer og rettigheter står i veiledningen Hardening WordPress.
WooCommerce-hjelp når nettbutikken slutter å selge
En feil i nettbutikken koster mer enn en feil på et firmanettsted, fordi hver time betyr bestillinger som ikke kom inn. At forsiden er oppe igjen, beviser ingenting: reparasjonen er ferdig når en testbestilling går gjennom handlekurven, betalingen, bekreftelsen på e-post og endringen i lagerbeholdningen. WooCommerce skriver feil til logger under WooCommerce, Status, Logger, og systemstatusrapporten på samme sted viser miljøet, versjonene og overstyrte maler. Begge deler er nyttige å legge ved henvendelsen.
Når butikken fungerer, men har mistet bestillinger, betalinger eller integrasjoner over lengre tid, passer en tidsavgrenset WooCommerce rescue sprint bedre enn en enkelt reparasjon.
WordPress-nettstedet virker ikke. Beskriv hva du ser
Adresse, tidspunkt for feilen og de siste endringene holder for å komme i gang. Prisen er individuell og fastsettes etter beskrivelsen av hendelsen, og arbeidet starter når omfanget er skrevet ned.
Send en beskrivelse av feilenRelatert arbeid ligger under WordPress-vedlikehold.
