WordPress standaard .htaccess-bestand: code 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/post-name/ werken in plaats van een 404 te geven. Het ziet er zo uit:

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

Deze regels komen uit de code waarmee WordPress het blok genereert, en ze komen overeen met de eigen .htaccess-gids van WordPress. WordPress schrijft ook drie commentaarregels direct na # BEGIN WordPress, met de waarschuwing dat wijzigingen tussen de markeringen worden overschreven. Ze veranderen niets aan de werking van de regels.

Bij een installatie in een submap zet WordPress het pad van de submap in zowel RewriteBase als de laatste regel, bijvoorbeeld RewriteBase /blog/ en RewriteRule . /blog/index.php [L]. Multisite-netwerken gebruiken een ander blok, en WordPress schrijft dit bestand daarvoor niet automatisch.

De belangrijkste punten

• WordPress genereert dit blok op Apache en LiteSpeed als het schrijfrechten heeft en mooie permalinks aanstaan. Instellingen > Permalinks openen is genoeg.
• Als het bestand ontbreekt of beschadigd is, geven permalinks een 404 terwijl de homepage nog laadt, omdat de homepage de rewrite-regels niet nodig heeft.
• Zet alles wat jij of een plugin toevoegt boven # BEGIN WordPress, nooit binnen de markeringen. WordPress vervangt alles daartussen wanneer het het bestand bijwerkt.

Wat elke regel precies doet

RewriteEngine On zet de Apache-module mod_rewrite aan voor deze map; zonder deze regel doen de rewrite-regels eronder niets.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] laat de URL ongemoeid (dat betekent de -) en kopieert de Authorization-header van het verzoek naar een servervariabele. WordPress leest die variabele om een gebruikersnaam en wachtwoord op te halen die in de header zijn meegestuurd, zoals een applicatiewachtwoord.

RewriteBase / stelt het padvoorvoegsel in dat Apache gebruikt voor herschreven URL’s. WordPress stemt het af op de plek waar de site staat, dus een installatie in een submap krijgt RewriteBase /blog/.

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

De twee RewriteCond-regels zijn de eigenlijke logica. %{REQUEST_FILENAME} !-f en !-d vragen: “komt dit verzoek NIET overeen met een echt bestand, en NIET met een echte map?” Beide moeten waar zijn voordat de laatste regel wordt uitgevoerd, dus een echte afbeelding, een CSS-bestand of een geüploade pdf wordt direct geserveerd en raakt de routing van WordPress nooit.

RewriteRule . /index.php [L] zorgt ervoor dat permalinks werken. Alles wat door die twee voorwaarden is gekomen, gaat naar index.php, en WordPress bepaalt welk bericht, welke pagina of welk archief de URL betekent.

Wanneer WordPress dit bestand opnieuw aanmaakt, en wanneer niet

WordPress leegt zijn rewrite-regels telkens wanneer het scherm Instellingen > Permalinks laadt, dus openen is genoeg en je hoeft niet op Wijzigingen opslaan te klikken. Als .htaccess ontbreekt, maakt WordPress het aan zolang de map beschrijfbaar is en mooie permalinks aanstaan. Als het bestand bestaat en beschrijfbaar is, vervangt WordPress het blok tussen de markeringen.

In deze gevallen lost dat het probleem niet op:

• Het bestand of de map is niet beschrijfbaar voor de gebruiker waarmee PHP draait. Het scherm toont een foutmelding dat het .htaccess-bestand niet beschrijfbaar is, samen met de regels om te plakken. Bij sommige hosts draait PHP als een andere systeemgebruiker dan de eigenaar van je FTP-uploads, dus rechten die in een FTP-client goed lijken, kunnen WordPress toch blokkeren.
• Je zit op nginx. De nginx-gids van WordPress zegt dat nginx geen configuratiebestand op mapniveau heeft zoals .htaccess, en dat WordPress de serverconfiguratie niet kan wijzigen. De gelijkwaardige routing is een try_files-directive in de serverconfiguratie, die een beheerder moet bewerken.
• AllowOverride staat op None voor de map van je site in de hoofdconfiguratie van Apache. De documentatie van Apache zegt: “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Oftewel: .htaccess-bestanden worden volledig genegeerd tenzij je ze expliciet voor een map inschakelt. WordPress kan een perfect bestand schrijven en het doet dan nog steeds niets. Rewrite-regels hebben AllowOverride FileInfo (of All) nodig, en mogelijk moet je host dat aanpassen.
• Je permalinks staan op Eenvoudig. Eenvoudige URL’s hebben geen rewrite-regels nodig, dus WordPress maakt het bestand daarvoor niet aan.

Zo herstel je het handmatig

Als berichten en pagina’s een 404 geven terwijl de homepage nog werkt, controleer je als eerste of .htaccess ontbreekt of kapot is. Los het op in twee stappen.

1. Probeer eerst de oplossing met één klik. Open Instellingen > Permalinks in wp-admin en klik op Wijzigingen opslaan zonder iets te veranderen. Als WordPress het bestand kan schrijven, wordt het hiermee opnieuw aangemaakt. Zo niet, dan toont het scherm de foutmelding en de regels die je nodig hebt.

2. Werkt dat niet, maak het bestand dan met de hand aan. Maak verbinding via FTP/SFTP of de bestandsbeheerder van je host en ga naar de hoofdmap van je site, normaal de map waarin wp-admin staat. Controleer of .htaccess bestaat. Het is een dotbestand, dus sommige bestandsbeheerders verbergen het standaard; zet “verborgen bestanden tonen” aan.

• Ontbreekt het, maak dan een nieuw bestand met exact de naam .htaccess (geen .txt, niets voor de punt).
• Plak de regels die WordPress je toonde, of het standaardblok bovenaan deze gids. Pas bij een installatie in een submap RewriteBase en de laatste regel aan.
• Sla op en laad daarna de permalink van een bericht opnieuw om te controleren of het werkt.

Krijg je nog steeds een 404, dan wordt .htaccess misschien genegeerd. Vraag je host naar AllowOverride, want Apache negeert een correct bestand als dat uitstaat.

Je eigen regels en het blok van WordPress

Een plugin of handmatige bewerking kan eigen regels toevoegen, zoals redirects, hotlinkbeveiliging of cacheheaders. Houd die buiten het blok van WordPress, en erboven, zodat ze vóór de algemene regel van WordPress worden uitgevoerd:

# Rules you or a plugin added: ABOVE the WordPress markers
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # example: hotlink protection, caching rules, etc.
</FilesMatch>

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

Alles wat tussen # BEGIN WordPress en # END WordPress staat, gaat verloren zodra WordPress het bestand weer bijwerkt, en het laden van het Permalinks-scherm is daarvoor al genoeg. Regels voor en na de markeringen blijven behouden. Zie voor redirects WordPress .htaccess-redirectregels goed instellen voor waar ze horen en hoe je loops voorkomt.

Een 500 Internal Server Error direct na het bewerken van het bestand wijst op wat je net hebt veranderd. De documentatie van Apache zegt dat het foutenlogboek waarschijnlijk een niet-toegestane directive of een syntaxisfout zal noemen. Regels uit een oude tutorial kunnen dit veroorzaken: Order is een ongeldig commando op Apache 2.4, tenzij mod_access_compat is geladen. Draai de bewerking terug om de site weer online te krijgen en lees daarna het foutenlogboek.

Verder dan het standaardblok

Het standaardblok regelt alleen de permalink-routing en de Authorization-header. Wil je de toegang tot gevoelige bestanden beperken, bijvoorbeeld PHP-uitvoering in /uploads blokkeren of directe verzoeken naar wp-config.php weigeren, zie dan WordPress .htaccess-beveiligingsregels die echt helpen. Geven permalinks om een andere reden een 404, zoals een verkeerde permalinkstructuur, een cachelaag die oude regels serveert of een multisite-conflict in een submap, 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 in het .htaccess-bestand in de hoofdmap van je site. Het geeft de Authorization-header door aan PHP en stuurt elk verzoek dat geen echt bestand of echte map is naar index.php.

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

Waarom geven al mijn berichten 404, behalve de homepage? Een ontbrekend of beschadigd .htaccess-bestand op Apache geeft dit patroon. De server vindt de homepage zonder rewrite-regels. Elke andere permalink heeft die regels nodig om index.php te bereiken, dus zonder die regels zoekt Apache naar een bestand dat niet bestaat en geeft het een 404 terug.

Maakt WordPress .htaccess automatisch opnieuw aan? Ja, op Apache of LiteSpeed met mod_rewrite, als mooie permalinks aanstaan en WordPress daar kan schrijven. Instellingen > Permalinks openen is genoeg. Voor een ontbrekend bestand moet de map beschrijfbaar zijn, en een bestaand bestand moet zelf beschrijfbaar zijn. Anders toont het scherm een foutmelding, samen met de regels die je handmatig moet plakken.

Waarom heeft nginx geen WordPress .htaccess-bestand? nginx heeft geen configuratiebestand op mapniveau zoals de .htaccess van Apache. Dezelfde routing wordt geschreven als een try_files-regel in de serverconfiguratie van nginx, die een beheerder moet bewerken omdat WordPress die niet kan wijzigen.

Waarom ging mijn .htaccess kapot nadat ik permalinks opsloeg? Controleer of er een eigen regel binnen de markeringen # BEGIN WordPress en # END WordPress is gezet. WordPress vervangt alles daartussen wanneer het het bestand bijwerkt, dus die regel gaat verloren. Zet eigen regels boven de markeringen.

Bronnen

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Broncode van WordPress: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Bouw een schone, correcte .htaccess op, met het standaard permalink-blok plus de beveiligings- of redirectregels die je echt nodig hebt, met de gratis WordPress .htaccess-generator.