WordPress-mappestruktur: Sådan lukker du adgang til "wp-includes" og beskytter din side

WordPress mappestruktur-sikkerhed handler om at beskytte de centrale mapper mod uautoriseret adgang – især “wp-includes”-mappen. Den bedste og mest stabile metode er ikke at blokere hele mappen blindt, men i stedet at forhindre direkte kørsel af PHP-filer og deaktivere mappevisning. “wp-includes” indeholder vitale scripts, CSS og statiske filer til WordPress’ kerne; fuld blokering kan ødelægge designet, editoren eller plugins. Den rigtige tilgang er at begrænse PHP-adgang med .htaccess-regler (Apache) eller location-blokke (Nginx), og derefter verificere med 403/404-svar og kritiske side-tests. Overvej også at kombinere med WordPress hosting og SSL certifikat for et stærkere sikkerhedssetup.

En klassisk fejl i WordPress-sikkerhed er at nøjes med stærke passwords eller sikkerhedsplugins. Hackere scanner ofte efter kernefiler, gamle plugins, forkerte filrettigheder og åbne mappevisninger. “wp-includes” er et oplagt mål. I denne guide får du trin-for-trin metoder til at begrænse adgang til “wp-includes”, undgår fejl der kan ødelægge din side, får eksempler til Apache og Nginx, testprocedurer og en tjekliste for løbende sikkerhed. For ekstra beskyttelse kan du læse om Sikker Web Hosting og Domænesikkerhed.

Hvad er wp-includes, og hvorfor skal den beskyttes?

“wp-includes” er en af WordPress’ kernemapper, hvor grundlæggende biblioteker til temaer, blokeditoren, REST API, billedhåndtering, klasser, funktioner og JavaScript-filer ligger. Kort sagt: det er en “maskinrum”-mappe, ikke et sted brugere skal besøge direkte.

En almindelig besøgende skal aldrig åbne dinside.dk/wp-includes/. Men i kildekoden til dine sider kan der være referencer til statiske elementer fra denne mappe – fx scripts og editor-komponenter. Sikkerhedsarbejdet handler derfor om at lukke for PHP-kørsel uden at blokere vigtige statiske filer.

Denne nuancerede tilgang er fundamentet for professionel WordPress mappestruktur-sikkerhed. Blind blokering kan give hvide sider, defekt admin-panel, fejl i editoren eller ødelagt design. Målet er at beskytte nødvendige filer og minimere angrebsfladen.

Hvad opnår du ved at lukke wp-includes?

At forhindre direkte PHP-kørsel i “wp-includes” stopper ikke alle angreb, men reducerer risikoen betydeligt. Hvis malware rammer din side, forsøger angribere ofte at uploade eller kalde PHP-filer i tilgængelige mapper. Ved at blokere PHP i “wp-includes” skaber du et ekstra sikkerhedsfilter.

Fordelene inkluderer:

• Begrænser direkte kald til kerne-PHP via URL.
• Hjælper med at skjule mappeindhold hvis mappevisning er slået til.
• Reducerer data-lækage fra automatiske bots og scanners.
• Giver serverbaseret beskyttelse – også uden plugin.
• Styrker lagdelt sikkerhed sammen med WAF, SSL, opdateret PHP og korrekte filrettigheder.

Dette er blot ét sikkerhedslag – ikke hele løsningen. Hvis du har gamle plugins, svage admin-adgangskoder eller kompromitterede FTP-konti, er det ikke nok. Sikkerhed kræver en kombination af hosting, applikation, brugerstyring og vedligeholdelse. Se også Webhosting backup og Virksomheds Hosting for ekstra lag.

Typiske fejl når wp-includes lukkes

Blokering af hele mappen

Den mest almindelige fejl er at blokere alle HTTP-forespørgsler til “wp-includes” med en 403. Det virker logisk, men WordPress loader vigtige statiske filer herfra – fx editor-scripts og JavaScript. Resultatet kan være at editoren ikke åbner, scripts ikke loader, eller at designet brydes.

Uden test i produktion

En enkelt fejl i .htaccess eller Nginx-konfiguration kan give 500 Internal Server Error. På sites med meget trafik er det riskabelt at implementere uden test. Tag backup først, prøv på et staging-miljø og rull ud gradvist. Hvis din hosting har staging eller backup, er køb SSL certifikat et naturligt link.

At stole 100% på plugins

Sikkerhedsplugins er nyttige – men serverbaserede regler aktiveres tidligere i processen. Hvis en forespørgsel blokeres af Apache/Nginx før PHP, sparer du ressourcer. Brug derfor både plugins og serverregler.

Tjekliste før du går i gang

Før du begrænser adgang til “wp-includes”, bør du forberede dig. Følg denne tjekliste – især på live-sider:

• Backup af nuværende .htaccess/Nginx-konfiguration.
• Opdater WordPress, temaer og plugins.
• Sikr dig at PHP-versionen er supporteret og sikker.
• Tjek filrettigheder: mapper bør være 755, filer 644.
• Undgå for åbne skrive-rettigheder på wp-config.php og .htaccess.
• Planlæg cache-rensning hvis du bruger cache, CDN eller sikkerhedsplugin.
• Lav en test-liste for admin, forsiden, blog-indlæg, kontaktformular og betalingsside.

Dette tager 10-15 minutter – men sparer dig for mange timers nedetid. På virksomheder bør det gøres i lavtrafik-timer.

Sådan lukker du wp-includes PHP-adgang med .htaccess (Apache)

På Apache-baserede hostingmiljøer er .htaccess den typiske metode. Tilføj nedenstående regel til din WordPress .htaccess (tag backup først):

Anbefalet .htaccess-regel

Brug denne regel for kun at blokere PHP-kørsel i “wp-includes”, mens statiske filer stadig virker:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Reglen siger: Hvis URL starter med “wp-includes” og slutter på “.php”, blokeres forespørgslen. Dermed kan statiske filer som .js, .css, .png, .svg stadig hentes, og WordPress fungerer normalt.

Deaktivér mappevisning

Det er også vigtigt at deaktivere mappevisning, så brugere ikke kan se indholdet af mapper uden index-fil. Tilføj denne linje til din .htaccess:

Options -Indexes

Dette skjuler mappelister. De fleste moderne hostings har det slået fra – men det er godt at tjekke.

Test efter ændringer

Efter du har tilføjet reglen, gør følgende:

• Åbn dinside.dk/wp-includes/. Du bør ikke se indholdet.
• Prøv at kalde en kendt PHP-fil i wp-includes direkte – du bør få 403 eller 404.
• Tjek forsiden, blog-indlæg og admin-panel.
• Brug browserens udviklerværktøj – se om der er 404/403 på ressourcer.
• Rens cache hvis du bruger cache/CDN.

Hvis alle tests går godt, kan reglen blive permanent. Ved 500-fejl fjern de nye linjer og gendan din backup.

Sådan lukker du wp-includes PHP-adgang med Nginx

På Nginx (VPS, dedikeret, managed server) virker .htaccess ikke. Her skal reglen ind i Nginx-site-konfigurationen, typisk i en server-blok. Du skal have SSH-adgang og tilladelse til at redigere. Hvis du er usikker, så kontakt dit hostingsupport.

Anbefalet Nginx location-regel

Tilføj følgende blok:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Dette blokerer PHP-kald til “wp-includes”. Test konfigurationen:

nginx -t

Hvis testen er god, reload Nginx:

systemctl reload nginx

Reload er bedre end restart – den bryder ikke aktive forbindelser. Implementér helst i lavtrafik-timer.

Vigtige Nginx-detaljer

• Reglen skal ind i den rigtige server-blok – der kan være flere sites på samme server.
• Hvis du bruger CDN/reverse proxy, test efter at have renset CDN-cache.
• Tjek at PHP-FPM kun håndterer relevante filer.
• Gennemgå logfiler: access.log og error.log viser hurtigt fejl.

Forkert placering af location-blokke kan give uventede resultater – tjek at den ikke konflikter med permalink- eller PHP-blokke.

Sammenligning af metoder

Tabellen her viser de vigtigste metoder til at begrænse adgang til “wp-includes”:

Bedst resultat fås ved at kombinere metoderne. Fx Apache .htaccess, korrekte filrettigheder, opdateret WordPress, SSL og backup giver lagdelt beskyttelse. Sikkerhedsfirewall og isolation er også vigtige – se Installation af gratis SSL for avancerede løsninger.

Filrettigheder og ejerskab

At lukke “wp-includes” er kun effektivt hvis filrettighederne er korrekte. Standard for WordPress er mapper 755, filer 644. Dette tillader webserveren at læse, men minimerer unødvendige skrive-rettigheder. Nogle hostings har særlige bruger- og gruppeindstillinger – følg panelets anbefalinger.

Undgå 777-rettigheder – det åbner for upload af skadelige filer. Selv i upload-mapper bør PHP-kørsel blokeres. “wp-includes” skal normalt kun kunne skrives under WordPress-opdateringer.

Tjek disse værdier:

• wp-includes: typisk 755
• PHP-filer i wp-includes: typisk 644
• wp-config.php: helst 600 eller mere restriktiv
• .htaccess: typisk 644, uden unødvendig skrivning

Forkerte rettigheder kan forhindre opdateringer eller læsning. Efter ændringer bør du tjekke WordPress’ sundhed og error logs.

Kan sikkerhedsplugins gøre dette automatisk?

Plugins som Wordfence og iThemes Security tilbyder “hardening”-regler. De giver beskyttelse mod brute force, filændringer, malware-scanning og login-sikkerhed. Men tjek altid om plugin'et blokerer “wp-includes” korrekt.

Nogle plugins tilføjer automatisk .htaccess-regler, andre beskytter kun på applikationsniveau. Serverbaseret beskyttelse aktiveres tidligere og er derfor stærkere. Professionelle anbefaler at kombinere plugin og server-konfiguration.

Tjek følgende hvis du bruger plugin:

• Tjek om plugin'et tilføjer .htaccess/Nginx-regler.
• Undgå konflikt mellem flere plugins/regler.
• Tjek at indstillingerne ikke ændres efter plugin-opdateringer.
• Overvåg cache og serverressourcer for performance.

Brug ikke flere sikkerhedsplugins samtidig – det kan give konflikter og fejlagtige blokeringer.

Test af wp-includes-beskyttelse: Praktisk scenarie

Du skal ikke nøjes med at åbne siden og se om den loader. Her er en 7-trins test, relevant for alt fra små firmaer til webshops:

• 1. Åbn forsiden i privat browser og tjek for visuelle fejl.
• 2. Besøg et blog-indlæg, kategori og søgeside.
• 3. Log ind i wp-admin; tjek blokeditor og mediebibliotek.
• 4. Brug browserens Console-værktøj.
• 5. Tjek at statiske filer fra wp-includes ikke blokeres unødvendigt.
• 6. Kald en PHP-fil direkte i wp-includes – forvent 403 eller 404.
• 7. Gennemgå serverens error logs for nye eller gentagne fejl.

Dette tager ca. 5 minutter og fanger fejl hurtigt. E-handelssider bør også teste indkøbskurv, betaling og brugerprofil. Selv små JavaScript-fejl kan påvirke konverteringsraten.

Ekstra sikkerhedsforanstaltninger til WordPress mappe-struktur

Beskyttelse af “wp-includes” er kun startpunktet – du bør tænke holistisk. Her er flere vigtige tips:

• Hold WordPress opdateret, fremfor at skjule versionen.
• Slet ubrugte temaer og plugins.
• Vælg et admin-brugernavn der ikke er let at gætte.
• Brug to-faktor-login.
• Begræns eller deaktiver XML-RPC hvis du ikke bruger det.
• Rate-limit eller ekstra login-beskyttelse på wp-login.php.
• Automatiser backup – og test gendannelse.
• Brug HTTPS på hele siden; SSL beskytter login og data.

SSL lukker ikke wp-includes, men beskytter sessions, forms og admin-trafik. Derfor er SSL et grundlæggende sikkerhedslag. Se Hostragons hostingpakker og Overførsel af WordPress site for mere info.

Hvornår bør du få professionel hjælp?

På en simpel Apache-hosting kan de fleste selv tilføje .htaccess-regler. Men hvis du har avanceret Nginx-setup, multisite-netværk, WooCommerce-shop, nyhedsside med meget trafik eller et virksomhedsportal, bør du overveje eksperthjælp. Sikkerhedsregler skal både være teknisk korrekte og sikre for driften.

Få hjælp hvis:

• Der hostes flere WordPress-sites på samme server.
• Nginx, Varnish, CDN og WAF bruges sammen.
• Du får flere 403, 404 eller 500 efter ændringer.
• Siden tidligere har haft malware.
• Du håndterer betaling, medlemskab eller persondata.

Sikker hosting, isolation, backup og ekspert-support er de usynlige, men kritiske dele af WordPress-sikkerhed. Vælg ikke kun efter diskplads – men også backup, firewall, PHP-version, SSL-håndtering og support. Læs også Hostragons Hosting Pakker og WordPress Site Flytning for gode løsninger.

Konklusion

I WordPress mappestruktur-sikkerhed er den bedste praksis ikke at blokere hele “wp-includes”, men at begrænse PHP-adgang og deaktivere mappevisning. Det kan gøres hurtigt med .htaccess (Apache) eller location-regler (Nginx). Tag altid backup før ændringer og test admin og frontend bagefter.

Opsummeret: Undgå at blokere statiske filer, begræns PHP, deaktiver mappevisning, tjek filrettigheder og opdater løbende. For mere sikker og stabil WordPress-hosting, se Hostragons’ hosting, domæne og SSL-løsninger – eller få hjælp til den rigtige opsætning.

Ofte stillede spørgsmål

Er det sikkert at blokere hele wp-includes?

Nej, det anbefales ikke. “wp-includes” indeholder vigtige JavaScript, CSS og statiske filer. Fuld blokering kan ødelægge design og admin-panel. Begræns kun PHP-adgang for stærk beskyttelse.

Hvad gør jeg hvis jeg får 500-fejl efter .htaccess-reglen?

Fjern de seneste ændringer eller gendan backup af .htaccess. Tjek syntaks for fejl. Hvis problemet fortsætter, gennemgå hostings error logs eller kontakt support.

Virker .htaccess på Nginx-server?

Nej. .htaccess bruges kun på Apache og LiteSpeed. Nginx kræver location-regler i server-blokken og skal testes med nginx -t efter ændring.

Gør dette min WordPress-side 100% sikker?

Nej – at blokere PHP i “wp-includes” er ét vigtigt lag, men ikke nok alene. Brug opdateringer, stærke passwords, to-faktor-login, SSL, backup, firewall og korrekte filrettigheder sammen.

Skal jeg tilføje wp-includes-reglen hvis jeg bruger sikkerhedsplugin?

Afhænger af plugin’et. Nogle tilføjer selv .htaccess-regler, andre beskytter kun på applikationsniveau. Serverbaseret PHP-begrænsning er ofte stærkere – undgå konflikter og brug begge hvor muligt.