WordPress-berichten geven een 404 maar de homepage werkt wel

Als je homepage prima laadt maar elk afzonderlijk bericht en elke pagina een 404 geeft, dan ontbreken de URL-herschrijfregels waar WordPress op leunt of zijn ze kapot in je .htaccess-bestand. De snelste oplossing: ga naar Instellingen → Permalinks in wp-admin en klik op Wijzigingen opslaan zonder ook maar iets te veranderen. Daarmee dwing je WordPress om het herschrijfblok opnieuw te genereren. Blijven de 404’s aanhouden, dan is je .htaccess niet beschrijfbaar voor de webserver, is Apache zo ingesteld dat het het bestand negeert, of draai je op Nginx (dat helemaal geen .htaccess gebruikt).

Waarom de homepage werkt maar berichten niet

Je homepage werkt omdat een aanvraag naar / rechtstreeks vanuit index.php in de documentroot wordt geserveerd. Er is geen herschrijving nodig.

Een aanvraag naar /2026/my-post/ is iets anders. Dat pad is geen echte map op de schijf. Om die aanvraag te kunnen beantwoorden, moet Apache de aanvraag intern doorsturen naar index.php, waarna WordPress REQUEST_URI uitleest, dit vergelijkt met de herschrijfregels die zijn opgeslagen in de optie rewrite_rules in de database, de query-variabelen oplost (WP::parse_request()) en het juiste bericht laadt.

De overdracht van Apache naar index.php is het stuk dat stukgaat. Die is volledig afhankelijk van dit blok in .htaccess:

# 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

De twee RewriteCond-regels zeggen: als het aangevraagde pad geen echt bestand is (!-f) en geen echte map (!-d), stuur het dan naar index.php. Verwijder dat blok en Apache gaat op zoek naar een letterlijke map /2026/my-post/, vindt die niet, en geeft zijn eigen 404 terug — nog voordat WordPress de aanvraag ooit te zien krijgt.

Waarom WordPress .htaccess overschrijft wanneer je permalinks opslaat

Dit is het stuk dat de meeste handleidingen overslaan. Wanneer je op Opslaan klikt in het Permalinks-scherm, roept WordPress flush_rewrite_rules() aan. Op Apache met een beschrijfbare .htaccess triggert dat save_mod_rewrite_rules(), die het bovenstaande blok opnieuw genereert via WP_Rewrite::mod_rewrite_rules() en terugschrijft met insert_with_markers().

insert_with_markers() raakt alleen de regels aan tussen # BEGIN WordPress en # END WordPress. Alles buiten die markeringen blijft ongemoeid. Alles daarbinnen wordt weggegooid en herschreven. Nieuwere WordPress-versies printen de waarschuwing zelfs rechtstreeks in het bestand:

Any changes to the directives between these markers will be overwritten.

Dus “WordPress overschrijft mijn .htaccess” klopt, maar is beperkt: het herschrijft alleen zijn eigen gemarkeerde blok, en alleen wanneer het bestand beschrijfbaar is. Is het bestand niet beschrijfbaar, dan doet de opslag stilletjes helemaal niets op de schijf. WordPress toont een gele melding op het Permalinks-scherm waarin staat dat je de regels handmatig moet plakken, en als je die melding mist, blijft je herschrijfblok ontbreken en blijft elk bericht een 404 geven.

Zo los je het op, stap voor stap

1. Sla je permalinks opnieuw op. Instellingen → Permalinks → Wijzigingen opslaan. Je hoeft niets te wijzigen. Hiermee draait de flush opnieuw en wordt het blok herschreven. Dit verhelpt het merendeel van de gevallen, inclusief verouderde regels na een migratie.

2. Controleer of .htaccess bestaat en beschrijfbaar is. Het staat in dezelfde map als wp-config.php. Het is een dotfile, dus zet “verborgen bestanden tonen” aan in je FTP-client of gebruik:

ls -la /path/to/wordpress/.htaccess

Ontbreekt het, maak het dan aan en plak het juiste blok erin. Staat je installatie in een submap, dan moeten RewriteBase en het uiteindelijke herschrijfdoel met dat pad overeenkomen — dit fout hebben is de meest voorkomende reden dat een handmatig geplakt blok alsnog een 404 geeft. Onze .htaccess-generator bouwt het exacte blok voor jouw installatiepad, zodat je niet hoeft te gokken.

3. Bevestig dat Apache .htaccess mag lezen. Heeft de virtual host AllowOverride None, dan negeert Apache het bestand volledig, ongeacht de inhoud. Je hebt AllowOverride All nodig (of op zijn minst FileInfo) op de WordPress-map. Dit staat in de serverconfiguratie, niet in .htaccess, dus je hebt servertoegang nodig:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Bevestig dat mod_rewrite is ingeschakeld. Op Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Op Nginx is er geen .htaccess. Herschrijvingen komen in plaats daarvan in het serverblok:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Snelle diagnose: van wie is de 404?

Kijk naar de 404-pagina. Is het een ongestylede Apache- of hostingfoutpagina, dan heeft Apache WordPress nooit bereikt — dat is een probleem met .htaccess of de serverconfiguratie (stappen 2–4). Is het de gestylede 404 van je eigen thema, dan ontvangt WordPress de aanvraag wel maar kan het geen match maken — de regels in de database zijn verouderd, en de permalinks opnieuw opslaan (stap 1) is de oplossing. Dit ene onderscheid bespaart de meeste mensen een uur giswerk.

Wat je niet moet doen

Schakel niet eerst al je plugins uit. Een puur “berichten geven 404, homepage werkt”-symptoom is een herschrijfprobleem, geen pluginconflict. Plugins uitzetten is de reflexoplossing op fora en raakt dit vrijwel nooit.

Gebruik geen chmod 777 op je .htaccess. WordPress heeft het bestand nodig als beschrijfbaar voor de webserver-gebruiker, en dat is niet hetzelfde als beschrijfbaar voor iedereen. 644 met de juiste eigenaar is prima en veilig; 777 is een beveiligingslek dat de routing sowieso niet oplost.

Plak geen eigen herschrijfregels binnen de markeringen # BEGIN WordPress / # END WordPress. Die worden gewist zodra iemand de volgende keer de permalinks opslaat. Zet eigen directives boven de regel # BEGIN WordPress.

Herinstalleer WordPress niet. De kernbestanden zijn in orde. Dit is één ontbrekend blok tekst, geen beschadigde installatie.

Geef je thema niet de schuld. Permalink-routing is WordPress-core. Een thema kan het niet veroorzaken en niet oplossen.

Nog steeds vast?

Heb je de permalinks opnieuw opgeslagen, bevestigd dat het blok aanwezig en beschrijfbaar is en AllowOverride All ingesteld, dan is de overgebleven verdachte een beveiligingsplugin of een regel op hostniveau die .htaccess achter je rug om opnieuw genereert of vergrendelt. Controleer de wijzigingstimestamp van het bestand direct na een permalink-opslag — is die niet veranderd, dan blokkeert iets het schrijven. Genereer een schoon blok met de .htaccess-generator, plak het erin en test opnieuw met een harde vernieuwing.