WordPress 404 na permalinks oplossen (2026)

Geeft WordPress na het opslaan van permalinks een 404, dan bereiken mooie URL’s meestal niet meer de juiste WordPress-rewrite rule of ontbreekt de route van de webserver naar index.php. Leg de bestaande URL-structuur vast, maak een back-up en vernieuw diezelfde structuur één keer voordat je afzonderlijk Apache of nginx controleert.

Wat deze 404 precies betekent

Een HTTP 404 betekent volgens MDN over 404 Not Found dat de server de aangevraagde bron niet kan vinden. Bij WordPress kan de inhoud wel in de database bestaan, terwijl de webserver het leesbare pad niet aan WordPress doorgeeft of WordPress geen passende rewrite rule heeft.

De officiële WordPress-uitleg over permalinks aanpassen noemt een permalink de permanente URL van een bericht, pagina of archief. Verander de structuur daarom niet als snelle test. Daarmee kunnen bestaande links echt een nieuw adres krijgen en heb je naast de storing ook redirects nodig.

Gebruik eerst dit onderscheid:

• Alleen één pagina geeft 404. Controleer publicatiestatus, slug, bovenliggende pagina en een botsing met een categorie of custom post type.
• Alle berichten en pagina’s met een mooie URL geven 404, maar de homepage werkt. Onderzoek de rewrite rules en webserverroute.
• Ook de homepage of wp-admin faalt. Dit is waarschijnlijk breder dan permalinks. Volg bij een weigering de 403 Forbidden-handleiding of bij een serverfout de 500-foutdecoder.
• De URL wisselt steeds tussen adressen. Gebruik de aanpak voor te veel redirects in WordPress.

Stappenplan: een 404 na permalinks herstellen

1. Maak een herstelpunt zonder URL’s te wijzigen

Maak een actuele back-up van bestanden en database en controleer of die herstelbaar is. Download bij Apache of LiteSpeed ook .htaccess. Heb je een zelfbeheerde nginx-server, bewaar dan een kopie van het actieve serverblok en de meegelezen configuratie.

Open Instellingen > Permalinks en maak een screenshot van:

• de geselecteerde structuur;
• de volledige aangepaste structuur als die wordt gebruikt;
• de categorie- en tagbasis;
• eventuele instellingen die plugins aan dit scherm toevoegen.

Noteer daarnaast één werkende en twee falende URL’s. Kies bij voorkeur een gewoon bericht, een pagina en een route van een plugin of custom post type. Met dit herstelpunt kun je aantonen dat een latere test geen adressen heeft veranderd.

2. Bevestig dat de inhoud en het adres nog bestaan

Open het bericht of de pagina in WordPress en controleer of de status Gepubliceerd is. Vergelijk de zichtbare permalink teken voor teken met de falende URL. Let op een gewijzigde slug, een bovenliggende pagina, dubbele slashes, URL-codering en een categorie- of taalprefix.

Kijk ook in de prullenbak naar een pagina met dezelfde slug. Controleer of een categorie, tag, mediabestand of custom post type hetzelfde basispad claimt. De officiële handleiding voor custom post types registreren waarschuwt dat generieke slugs kunnen botsen met andere typen.

Verander in deze stap niets in de database en bewerk geen guid-waarden. De zichtbare permalink en publicatiestatus geven genoeg informatie om een inhoudsprobleem uit te sluiten.

3. Test WordPress zonder de mooie URL

Zoek het numerieke bericht-ID in de bewerk-URL en vraag op dezelfde site tijdelijk dit adres op:

https://voorbeeld.nl/?p=123

Deze test verandert geen instelling. Werkt de query-URL en toont hij het juiste gepubliceerde bericht, terwijl de mooie permalink 404 geeft, dan zijn WordPress en de inhoud bereikbaar. De breuk zit waarschijnlijk tussen het leesbare pad, de webserver en de rewrite rules.

Geeft ook de query-URL een 404, controleer dan opnieuw status en ID. Geeft hij een kritieke fout of wit scherm, stap dan over op de kritieke-foutdecoder of de uitleg voor een wit WordPress-scherm. Rewrite rules repareren geen PHP-fout.

4. Sluit cache en een verkeerde testrespons uit

Open de falende URL afgemeld in een privévenster en bekijk de netwerkstatus. Leeg daarna alleen de relevante pagina-, server- en CDN-cache. Test opnieuw met een unieke queryparameter, bijvoorbeeld ?permalinktest=20260728, zonder de slug te wijzigen.

Controleer bij een CDN of proxy zowel de publieke URL als de origin volgens de veilige methode van je host. Een oude 404 kan in de cache blijven staan nadat de origin al is hersteld. Noteer altijd welke laag de responseheader of foutpagina lijkt te leveren.

5. Vernieuw exact dezelfde WordPress-regels één keer

Controleer je screenshot en laat alle velden op Instellingen > Permalinks ongewijzigd. Klik één keer op Wijzigingen opslaan. Kies dus niet tijdelijk voor Eenvoudig, wijzig geen slugs en voer geen zoek-en-vervangactie in de database uit.

WordPress beschrijft in de Rewrite API dat permalinks na nieuwe rewrite rules één keer moeten worden ververst. De codebeschrijving van flush_rewrite_rules() vermeldt ook dat deze bewerking kostbaar is en alleen moet gebeuren wanneer dat nodig is.

Test nu de eerder genoteerde URL’s. Werken ze weer, vergelijk dan met je screenshot of de structuur gelijk is gebleven en ga door naar de eindcontrole. Blijven ze 404 geven, kies de juiste webserverroute.

6. Controleer Apache of LiteSpeed afzonderlijk

Alleen voor Apache of LiteSpeed: WordPress kan de rewrite rules in het beheerde blok van .htaccess schrijven als bestand en serverconfiguratie dat toestaan. Download opnieuw de versie van na stap 5 en vergelijk die met je back-up.

Controleer het blok tussen de WordPress-markeringen. Kopieer niet zomaar een voorbeeld van een andere site: een installatie in een submap, multisite of aangepaste documentroot kan andere paden nodig hebben. Als WordPress het bestand niet kan schrijven, gebruik dan alleen het regelsblok dat jouw eigen WordPress-beheerscherm toont en bewaar eigen beveiligingsregels buiten het beheerde blok.

De officiële Apache-uitleg over .htaccess beschrijft dat zulke regels alleen werken als de server dit toestaat. Laat je provider daarom controleren of:

1. mod_rewrite actief is;
2. overrides voor de WordPress-map zijn toegestaan, doorgaans minstens voor FileInfo;
3. .htaccess in dezelfde route als de publieke index.php staat;
4. eigenaar en rechten aansluiten op de hostingconfiguratie;
5. een bovenliggend .htaccess-bestand de route niet overschrijft.

Pas alleen het aantoonbaar ontbrekende WordPress-blok aan. Test, en herstel je back-up onmiddellijk als de 404 blijft of een nieuwe 403 of 500 ontstaat. Gebruik geen 777 om WordPress schrijfbaar te maken.

7. Controleer nginx afzonderlijk

Alleen voor nginx en alleen met servertoegang: nginx gebruikt geen .htaccess, en WordPress kan het actieve serverblok niet voor je bijwerken. De officiële WordPress-handleiding voor nginx legt dit verschil uit en toont voor een gewone installatie deze kernroute:

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

De regel laat bestaande bestanden en mappen direct laden en stuurt een ander pad naar WordPress. De officiële nginx-documentatie van try_files beschrijft die bestandscontrole en interne doorverwijzing.

Neem dit voorbeeld niet blind over. Een submap, multisite, reverse proxy, cachelaag of afwijkende documentroot vraagt om aangepaste paden. Vergelijk eerst met de laatst werkende configuratie. Maak één gerichte wijziging, voer nginx -t uit en herlaad nginx alleen als de syntaxiscontrole slaagt en je bevoegd bent. Zet de configuratiekopie terug als de URL-test niet verbetert.

Bij managed nginx-hosting is dit volledig een providerroute. Stuur de falende en werkende URL, het tijdstip en de uitkomst van de ?p=123-test. Vraag of het actieve location-blok onbekende paden aan de juiste WordPress-index.php doorgeeft.

8. Onderzoek custom post types en pluginroutes

Werken gewone berichten en pagina’s, maar niet een route zoals /cursus/naam/, dan is de algemene serverroute waarschijnlijk goed. Controleer of de verantwoordelijke plugin actief is en het custom post type op de init-hook registreert. Controleer ook of de gekozen basis-slug uniek is.

De WordPress-referentie voor register_post_type() adviseert rewrite rules na registratie bij pluginactivatie te vernieuwen en waarschuwt dat dit nooit op elke paginalaad moet gebeuren. Laat een ontwikkelaar de registratievolgorde herstellen. Blijf niet telkens Permalinks opslaan om foutieve pluginlogica te maskeren.

Schakel alleen de vermoedelijke plugin tijdelijk uit als je een herstelroute hebt en de inhoud daardoor niet wordt verwijderd. Activeer hem weer als de test niets verandert. Een custom post type kan tijdens de deactivatie uit het beheerscherm verdwijnen zonder dat de berichten uit de database zijn verwijderd, maar controleer je back-up voordat je deze test doet.

9. Controleer submappen, domeinen en vaste redirects

Staat WordPress in een submap terwijl het domein uit de root wordt bediend, controleer dan of index.php, siteadres, WordPress-adres en serverroute nog op dezelfde opzet aansluiten. De officiële handleiding voor WordPress in een eigen map behandelt Apache en nginx afzonderlijk en toont dat de frontcontrollerroute dan andere paden kan vragen.

Wijzig site-URL’s niet rechtstreeks in de database als permalinktest. Vraag bij twijfel de host om de actieve documentroot en installatiemap te bevestigen. Controleer ook redirectplugins en serverregels op een oud domein, taalpad of verwijderde categorie.

Als je bewust een permalinkstructuur hebt gewijzigd, herstel dan bij voorkeur eerst de oude structuur uit je notitie. Plan daarna afzonderlijk permanente 301-redirects van ieder oud adres naar het inhoudelijk juiste nieuwe adres. Een algemene redirect naar de homepage maakt kapotte links niet inhoudelijk correct.

10. Valideer breed en bewaar de rollback

Test na de reparatie minimaal:

1. de homepage;
2. een bericht en een pagina;
3. een categorie- en tagarchief;
4. zoeken en paginering;
5. /wp-json/;
6. een route van ieder belangrijk custom post type;
7. login en beheer;
8. een bestaand statisch bestand en mediabestand.

Controleer dat de succesvolle pagina’s status 200 geven en niet via onverwachte redirects eindigen. Bekijk de serverlog op rewritecycli, nieuwe 403’s of 500’s. Bewaar de werkende configuratie, permalink-screenshot, testlijst en terugzetstappen bij je beheerinformatie.

Veelgemaakte fouten

• Tijdelijk een andere permalinkstructuur kiezen. Daarmee verander je echte URL’s terwijl je alleen de rewrite rules wilde vernieuwen.
• guid-waarden of URL’s direct in de database vervangen. Dat is geen veilige diagnose van een routeringsfout.
• .htaccess verwijderen zonder kopie. Eigen beveiligings- en redirectregels kunnen dan verloren gaan.
• Een Apache-regel op nginx toepassen. nginx leest geen .htaccess en vraagt om een serverblok.
• Een standaard nginx-blok blind plakken. Submappen, multisite en proxies kunnen andere paden nodig hebben.
• Rewrite rules bij iedere paginalaad flushen. Dat is kostbaar en verbergt een fout in pluginregistratie.
• Alleen de homepage testen. Die kan werken terwijl berichten, archieven en REST-routes nog 404 geven.
• Een gecachte 404 als originfout behandelen. Controleer na herstel de juiste cachelaag en de echte status.
• Geen rollback na een syntaxisfout hebben. Bewaar altijd het oorspronkelijke .htaccess-bestand of serverblok.

Wanneer je hulp inschakelt

Schakel hostingbeheer in wanneer Apache mod_rewrite of overrides niet beschikbaar zijn, nginx wordt beheerd door je provider, of logs tonen dat de publieke proxy een andere route gebruikt dan de origin. Geef de werkende query-URL, falende permalink, exacte tijd, servertype en je uitgevoerde omkeerbare tests door.

Bekijk voor andere storingen en herstelroutes de WordPress-hub. Wil je dat iemand de rewriteketen controleert en met rollback herstelt, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.