WordPress standaard .htaccess-bestand: inhoud en herstel

Het standaard .htaccess-bestand van WordPress is het korte RewriteEngine-blok dat de software in de .htaccess in de hoofdmap van je site schrijft, zodat permalinks zoals /2026/10/berichtnaam/ worden opgelost in plaats van 404 te geven. Het ziet er zo uit:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Dat is het exacte blok, overgenomen uit de officiële WordPress-gids over de Apache HTTP Server en de rewrite-logica die beschreven staat op de HelpHub-pagina over pretty permalinks. Is je RewriteBase niet / — bijvoorbeeld omdat WordPress in een submap is geïnstalleerd — dan komt die overeen met dat pad, en dat is net zo normaal en wordt ook door WordPress zelf gegenereerd.

Kernpunten

• WordPress genereert dit blok automatisch, alleen op Apache en LiteSpeed, zodra het bestand beschrijfbaar is en je Instellingen > Permalinks opslaat.
• Ontbreekt het bestand of is het beschadigd, dan geven alle permalinks behalve de homepage een 404, omdat alleen de homepage zonder de rewrite-regels gevonden kan worden.
• Alles wat jij of een plugin toevoegt moet boven # BEGIN WordPress staan, nooit binnen de markeringen — WordPress overschrijft alles daartussen bij elke permalink-opslag.

Moet het bestand opnieuw worden opgebouwd met je echte pad en wat extra regels? De WordPress .htaccess-generator stelt er direct in je browser een correcte samen.

Wat elke regel doet

RewriteEngine On schakelt de mod_rewrite-module van Apache in voor deze map; zonder deze regel is al het volgende inactief.

RewriteBase / vertelt Apache dat herschreven paden relatief zijn aan de hoofdmap van de site. WordPress stelt dit in op basis van waar de site echt staat — een installatie in een submap krijgt RewriteBase /blog/, niet /.

RewriteRule ^index\.php$ - [L] is een bewaker zonder effect: is het verzoek al index.php, dan stopt het herschrijven en gaat het verzoek ongewijzigd door.

De twee RewriteCond-regels vormen de echte logica. %{REQUEST_FILENAME} !-f en !-d vragen “is dit verzoek GEEN echt bestand, en GEEN echte map?”. Beide moeten waar zijn voordat de laatste regel afgaat — zo wordt een echte afbeelding, CSS-bestand of geüploade PDF direct geserveerd en komt nooit in aanraking met de routing van WordPress.

RewriteRule . /index.php [L] is wat permalinks laat werken: alles wat de twee voorwaarden hiervoor heeft doorstaan — dus geen echt bestand of map is — wordt naar index.php gestuurd, en de eigen routing van WordPress (WP_Query, rewrite-tags) bepaalt welk bericht, pagina of archief die URL werkelijk bedoelt.

Wanneer WordPress dit bestand opnieuw aanmaakt, en wanneer niet

WordPress probeert .htaccess zelf te schrijven elke keer dat je Instellingen > Permalinks opent en op Wijzigingen opslaan klikt, ook als er niets op het scherm is veranderd. Dat opslaan triggert flush_rewrite_rules(), dat probeert .htaccess te openen om te schrijven en het huidige blok tussen de markeringen in te voegen.

Die poging mislukt stilletjes, waardoor het bestand ontbreekt of verouderd blijft, wanneer:

• Het bestand of de bovenliggende map niet beschrijfbaar is voor de gebruiker waarmee PHP draait. Bij veel shared hosting draait PHP onder een andere systeemgebruiker dan degene die bestanden via FTP heeft geüpload, waardoor rechten die in een FTP-client correct lijken, WordPress toch kunnen blokkeren.
• Je op nginx draait. .htaccess is uitsluitend een mechanisme van Apache en LiteSpeed (de Apache-documentatie over AllowOverride legt uit waarom: nginx heeft geen configuratiebestand per map dat het bij elk verzoek opnieuw inleest). Het equivalent op nginx is een try_files-directive in het server-blok, die alleen iemand met serverstoegang kan bewerken; WordPress kan die nooit voor je schrijven.
• AllowOverride op None staat voor de map van je site in de hoofdconfiguratie van Apache. Dat is de instelling die een .htaccess überhaupt iets laat overschrijven; de Apache-documentatie is duidelijk: bij AllowOverride None “worden .htaccess-bestanden volledig genegeerd” — WordPress kan een perfect bestand schrijven, en het blijft zonder effect totdat die instelling op serverniveau wordt aangepast.
• Het bestand is verwijderd of heeft nooit bestaan en iets bij het opslaan triggerde geen regeneratie — meestal omdat de permalinkstructuur al dezelfde was, waardoor WordPress geen wijziging zag om weg te schrijven.

Zo herstel je het handmatig

Als berichten en pagina’s 404 geven terwijl de homepage nog wel werkt, is dat de typische aanwijzing van een ontbrekend of kapot .htaccess-bestand. Verhelp dit in twee stappen.

1. Probeer eerst de oplossing in één klik. Ga naar Instellingen > Permalinks in het WordPress-dashboard en klik op Wijzigingen opslaan zonder iets te veranderen. Is het bestand beschrijfbaar, dan regenereert dit het alleen al, en ben je klaar.

2. Werkt dat niet, maak het bestand dan handmatig aan. Verbind via FTP/SFTP of de bestandsbeheerder van je hoster, ga naar de map waar WordPress is geïnstalleerd (die met wp-config.php) en controleer of .htaccess überhaupt bestaat — het is een verborgen bestand, sommige bestandsbeheerders verbergen het standaard; zet “verborgen bestanden tonen” aan.

• Ontbreekt het, maak dan een nieuw bestand aan met precies de naam .htaccess (geen .txt, niets voor de punt).
• Plak het standaardblok van hierboven, en pas RewriteBase aan als WordPress in een submap staat.
• Sla op en herlaad de permalink van een bericht om te bevestigen dat het werkt.

Geeft het daarna nog steeds 404, dan is de oorzaak verschoven van “.htaccess ontbreekt” naar “.htaccess wordt genegeerd” — vraag je hoster naar AllowOverride, want een correct bestand in een map waar Apache de opdracht heeft het te negeren, gedraagt zich identiek aan geen bestand.

Je eigen regels versus het blok van WordPress

Een plugin of handmatige bewerking kan eigen regels toevoegen — redirects, hotlink-bescherming, cache-headers. Dat is een ander, apart blok van wat WordPress genereert, en de twee zouden nooit moeten overlappen:

# Regels die jij of een plugin hebt toegevoegd — BOVEN de WordPress-markeringen
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # voorbeeld: hotlink-bescherming, cache-regels, enz.
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Alles dat tussen # BEGIN WordPress en # END WordPress staat, wordt stilletjes verwijderd de volgende keer dat iemand het Permalinks-scherm opslaat, omdat WordPress dat hele stuk als zijn eigen terrein behandelt en volledig herschrijft. Dit is de meest voorkomende oorzaak van “mijn eigen regel is verdwenen” — die is nooit opzettelijk verwijderd, maar stond gewoon in een blok dat WordPress als het zijne beschouwt. Voor redirects specifiek, zie WordPress .htaccess redirect-regels goed gedaan voor waar ze horen en hoe je loops voorkomt.

Het is ook de meest voorkomende oorzaak van een plotselinge 500 Internal Server Error direct na het bewerken van het bestand: een regel gekopieerd van een forumpost geschreven voor een andere Apache-versie (2.2-syntax Order/Deny gemengd met 2.4-syntax Require) breekt het parsen van het hele bestand, inclusief het WordPress-blok eronder, waardoor de hele site plat gaat — niet alleen het deel dat je aanraakte.

Verder dan het standaardblok

Het standaardblok regelt alleen de permalink-routing. Wil je ook de toegang tot gevoelige bestanden aanscherpen of de handvol .htaccess-regels toevoegen die écht het aanvalsoppervlak verkleinen — PHP-uitvoering in /uploads blokkeren, directe verzoeken naar wp-config.php weigeren — bekijk dan WordPress .htaccess-beveiligingsregels die echt helpen. En geven permalinks 404 om een andere reden — verkeerde permalinkstructuur, een cachelaag die oude regels serveert, multisite-conflicten in submappen — dan behandelt WordPress-permalinks werken niet de andere oorzaken.

Veelgestelde vragen

Wat is het standaard .htaccess-bestand van WordPress? Het is het RewriteEngine-blok dat WordPress tussen # BEGIN WordPress en # END WordPress schrijft zodat permalinks naar index.php worden opgelost in plaats van 404 te geven.

Wat is de exacte standaard .htaccess-code van WordPress? RewriteEngine On, RewriteBase /, een doorlaatregel voor index.php, twee voorwaarden die controleren dat het verzoek geen echt bestand of map is, en een afsluitende regel die al het andere naar index.php stuurt. Het volledige blok staat boven in deze gids.

Waarom geven al mijn berichten 404, behalve de homepage? De homepage is te vinden zonder enige rewrite-regel; elke andere permalink heeft ze nodig. Een ontbrekend of beschadigd .htaccess op Apache produceert precies dit patroon.

Maakt WordPress .htaccess automatisch opnieuw aan? Alleen als het bestand beschrijfbaar is — opnieuw opslaan van Instellingen > Permalinks triggert dit. Is het bestand niet beschrijfbaar, ontbreekt het bij een hoster die het niet automatisch genereert, of staat AllowOverride uit, dan kan WordPress dit niet voor je oplossen en moet je het bestand zelf aanmaken of herstellen.

Waarom heeft nginx geen WordPress .htaccess-bestand? .htaccess werkt alleen op Apache en LiteSpeed. nginx heeft geen configuratiebestand per map en negeert .htaccess volledig; dezelfde routing wordt geschreven als een try_files-regel in het server-blok van nginx.

Waarom ging mijn .htaccess kapot nadat ik permalinks opsloeg? Een eigen regel werd binnen de markeringen # BEGIN WordPress / # END WordPress geplaatst in plaats van erboven, en WordPress overschreef dat hele stuk bij de volgende opslag van permalinks.

---

Bouw een schoon, correct .htaccess-bestand — standaard permalinkblok plus alle beveiligings- of redirect-regels die je echt nodig hebt — met de gratis WordPress .htaccess-generator.