Loglæsning for ikke-teknikere: find svar i access- og fejllogs

Kort svar: Du behøver ikke være tekniker for at læse server-logs – du skal vide, hvor du kigger, og hvad du kigger efter. Fejlloggen fortæller, hvorfor noget gik i stykker: ved hvid skærm læser du de seneste linjer, og står der “Fatal error” med et pluginnavn i filstien, har du din hovedmistænkte. Accessloggen fortæller, hvem der bad om hvad: ved langsomhed afslører den bots eller enkelte IP-adresser, der hamrer løs, og ved 404-bølger hvilke adresser der rammes. Læs logs, når der er symptomer, og brug statuskoderne som kompas.

Fagligt gennemgået: 2. oktober 2026

“Har du kigget i loggen?” er supportens første spørgsmål – og for mange site-ejere et lukket land. Det er en skam, for loglæsning på begynderniveau kan læres på en halv time.

Bagefter kan du gå fra “det virker bare ikke” til “der står Fatal error, og stien peger på booking-pluginet”. Det sparer tid, uanset om du selv løser fejlen eller giver den videre.

De to logs – og hvad de kan

Accessloggen er besøgsprotokollen: én linje pr. forespørgsel med IP-adresse, tidspunkt, adresse, statuskode og browser eller bot (user agent). Den svarer på mængdespørgsmål: hvor kom trafikken fra, hvad blev ramt, og hvem hamrer løs?

Fejlloggen er skadestuen: her lander PHP-fejl, databaseklager og serverproblemer med tidspunkt og filsti. Den svarer på hvorfor-spørgsmål: hvorfor hvid skærm, hvorfor fejl 500, hvorfor langsomt efter opdateringen?

Begge findes typisk i hostingpanelets logsektion. WordPress har desuden sin egen debug-log, som normalt er slået fra og kun tændes målrettet under fejlfinding.

To ting er vigtige at vide på forhånd. Logs roterer: gamle linjer arkiveres eller slettes efter dage eller uger, så opslag skal ske, mens sporet er friskt. Og tidszonen kan variere – mange servere logger i UTC, så et klokkeslæt i loggen kan ligge en eller to timer fra dansk tid.

Læs en linje i accessloggen

En linje i accessloggen ser typisk sådan ud (eksemplet er opdigtet):

203.0.113.45 - - [02/Oct/2026:14:03:21 +0200] "GET /kurv/ HTTP/2" 200 18234 "https://eksempel.dk/shop/" "Mozilla/5.0 (iPhone; ...)"

Læs den som en sætning: IP-adressen 203.0.113.45 bad kl. 14.03 om adressen /kurv/ og fik statuskode 200 og 18.234 byte. Den kom fra shopsiden og brugte en iPhone. Statuskoderne er dit kompas:

Kode	Betyder	Hvad du gør
200	OK	Intet
301/302	Omdirigeret	Fint – medmindre det går i ring, se for mange redirects
403	Adgang nægtet	Ofte sikkerhedsregler, der også kan ramme rigtige brugere
404	Findes ikke	Enkeltvis harmløst, i bølger et symptom
429	For mange forespørgsler	En grænse for antal forespørgsler er ramt – se 429-guiden
500	Serverfejl	PHP gik ned – gå til fejlloggen
502/504	Gateway-fejl eller timeout	Noget bag webserveren svarede ikke eller for langsomt
503	Utilgængelig	Overbelastning eller vedligeholdelsestilstand

Læs en linje i fejlloggen

En typisk fatal PHP-fejl ser sådan ud (også opdigtet):

[02-Oct-2026 12:03:21 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function eksempel_funktion() in /home/bruger/public_html/wp-content/plugins/booking-eksempel/booking.php:112

Fejlloggen læses nedefra: nederst står det nyeste. Den vigtigste linje er den første “Fatal error” lige før symptomets tidspunkt. Læs filstien:

• Står der /wp-content/plugins/NAVN/, er pluginet NAVN din hovedmistænkte.
• Står der /wp-content/themes/, peger sporet på temaet.
• Står der /wp-includes/ eller /wp-admin/, er fejlen ofte udløst af et plugin, der kalder WordPress forkert – kig efter flere linjer i samme sekund.

Advarsler (“Warning”, “Notice”, “Deprecated”) i store mængder er støj under akut fejlfinding. “Fatal” er det, der vælter sitet. “Allowed memory size exhausted” betyder, at PHP løb tør for hukommelse – se guiden om memory-fejlen.

Fire opslag, der løser det meste

Hvid skærm eller fejl 500

Gå til fejlloggens nederste linjer, og find første Fatal omkring tidspunktet. Aflæs plugin eller tema i stien, og sammenhold med ændringsloggen: blev netop dét opdateret? Deaktivér synderen. Guiderne om hvid skærm og 500 Internal Server Error tager dig videre.

Langsomt site

Gå til accessloggen, og kig efter én IP-adresse eller user agent med hundredvis af linjer i minuttet – en aggressiv bot eller scanner. Se også, hvilke adresser der hamres på; søgesider, filtre og kalenderadresser er klassikere. Mængden fortæller, om løsningen er blokering eller mere kapacitet.

404-bølge

Accessloggen viser, hvilke adresser der rammes. Er det gamle sider, opretter du redirects. Er det et slettet billede, retter du henvisningen. Er det varianter af wp-login og mærkelige stier, er det scannere – helt normalt, og noget du kan ignorere eller blokere.

Formular eller mail virker ikke

Kig i fejlloggen omkring indsendelsestidspunktet efter mailrelaterede fejl. Peger sporet på afsendelsen, fortsætter du i hubben om mailfejlfinding.

WordPress’ egen debug-log

Når serverens fejllog ikke siger nok, kan du tænde WordPress’ debug-log midlertidigt. Det sker i wp-config.php over linjen “That’s all, stop editing!”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Så skrives fejlene til filen wp-content/debug.log i stedet for at blive vist for de besøgende. WP_DEBUG_LOG kan også sættes til en filsti uden for den offentlige mappe.

Vigtigt: Tag en kopi af wp-config.php, før du retter i den. Slå debug fra igen, når du har fundet fejlen, og slet debug.log. Filen kan vokse sig stor og kan indeholde stier og oplysninger, som ikke bør kunne hentes udefra.

Botterne i loggen

Åbner du accessloggen første gang, er overraskelsen ofte den samme: en stor del af trafikken er ikke mennesker. Meget af den er godartet – søgemaskinernes crawlere (genkendes på user agent), overvågningstjenester og AI-crawlere – og skal have lov at arbejde.

Resten er støj og scannere: bots, der prøver login-sider, leder efter kendte sårbarheder eller høster indhold uden hæmninger. Reglen for ikke-teknikeren er at reagere på adfærd, ikke på tilstedeværelse. En bot, der henter 10 sider i timen, er hverdag. En, der henter 100 i minuttet og gør sitet langsomt, skal blokeres – via sikkerhedsplugin, firewall eller en henvendelse til hostingen.

Husk, at user agents kan forfalskes. En linje, der siger “Googlebot”, er ikke nødvendigvis Google. Vil du styre de ærlige crawlere mere præcist, er robots.txt-guiden næste skridt.

Rutinen: opslagsværk, ikke avis

Logs skal ikke læses dagligt – de skal kunne slås op i. Rutinen er symptom, log, svar. To faste berøringer er nok:

• Ved kvartalstjekket et blik på fem minutter i fejlloggen. Gentagne advarsler fra samme plugin er et vink om kommende problemer – og billige at handle på i god tid.
• I nedbrudsplanen som fast trin i fejlfindingen.

Skriv vejen til loggene ind i driftsdokumentationen, så også vikaren kan slå op. Og når du kontakter support, så send de relevante linjer med tidspunkt – det gør svaret hurtigere. Med WordPress hosting hos Hostious kan du kontakte den danske support døgnet rundt, når linjerne bliver kryptiske.

Læs også

• Hub: Driftshåndbogen
• Nedbrudsplanen: hvem gør hvad, når sitet er nede?
• Ændringsloggen: dokumentér ændringer, så fejlfinding tager minutter
• Kritisk fejl i WordPress: sådan finder du den konkrete PHP-fejl
• AI-crawlere i robots.txt
• WordPress hosting hos Hostious – LiteSpeed, daglig backup og dansk support døgnet rundt

Ofte stillede spørgsmål om loglæsning

Hvor finder jeg serverens logs?

Typisk i hostingpanelets logsektion: accessloggen (alle forespørgsler) og fejlloggen (PHP- og serverfejl). Find vejen derhen nu, og skriv den i driftsdokumentationen – ikke først under et nedbrud.

Hvad kigger jeg efter ved hvid skærm?

Fejlloggens nederste linjer: første “Fatal error” før tidspunktet. Filstien afslører den mistænkte – /plugins/NAVN/ peger på pluginet, /themes/ på temaet. Sammenhold med ændringsloggen.

Er al bot-trafik i loggen et problem?

Nej. En stor del af trafikken på de fleste sites er bots, og meget af den er godartede crawlere. Reagér på adfærd: hundredvis af forespørgsler i minuttet fra én kilde blokeres, et roligt tempo ignoreres.

Hvorfor passer klokkeslættet i loggen ikke?

Mange servere logger i UTC, mens du tænker i dansk tid. Om sommeren er forskellen to timer, om vinteren én. Tjek tidszonen i linjen, før du sammenholder med ændringsloggen.