WordPress 403 Forbidden oplossen (2026)

Een 403 Forbidden in WordPress betekent dat de server je verzoek begrijpt, maar de toegang weigert. Maak eerst een back-up van de configuratie die je mogelijk gaat wijzigen en bepaal daarna met URL, tijdstip en logs welke laag de blokkade oplegt.

Wat een 403 wel en niet zegt

Een 403 is een HTTP-status, geen specifieke WordPress-melding. Volgens MDN over 403 Forbidden heeft de server het verzoek begrepen, maar weigert hij het te verwerken. Opnieuw inloggen of de pagina steeds verversen lost een echte toegangsregel daarom meestal niet op.

Vergelijk de fout met meldingen die een andere route nodig hebben:

• 401 vraagt doorgaans om geldige authenticatie.
• 404 betekent dat de aangevraagde bron niet is gevonden of bewust niet wordt getoond. Ontstaan zulke fouten na een URL-wijziging, volg dan de uitleg voor een WordPress-404 na permalinks.
• 500 wijst op een fout tijdens verwerking. Gebruik daarvoor de gerichte decoder voor een 500 Internal Server Error.
• Een kritieke fout of wit scherm in WordPress komt meestal uit PHP nadat het verzoek wel is toegelaten.

Een 403 kan vóór WordPress ontstaan, bijvoorbeeld in een CDN, web application firewall, hostingfilter of webserver. Begin daarom niet met willekeurig plugins verwijderen of rechten verruimen.

Bepaal eerst hoe groot de blokkade is

Noteer welke van deze situaties klopt:

1. de hele site, inclusief de homepage, geeft 403;
2. alleen /wp-admin/ of wp-login.php is geblokkeerd;
3. één map, bestand, REST-route of upload geeft 403;
4. alleen opslaan, uploaden of een formulierverzoek mislukt;
5. alleen één bezoeker, netwerk of land ziet de fout;
6. de fout ontstond direct na een plugin-, firewall- of hostingwijziging.

Test dezelfde URL afgemeld in een privévenster en via een tweede netwerk. Controleer in de netwerkdetails van je browser of de status echt 403 is. Een vormgegeven foutpagina kan namelijk door een CDN worden getoond, terwijl de achterliggende server een andere melding registreert.

Is de site na een HTTPS- of domeinwijziging in een lus terechtgekomen, gebruik dan de aparte stappen voor te veel redirects in WordPress. Dat probleem los je niet op met bestandsrechten.

Stappenplan: WordPress 403 veilig oplossen

1. Leg een herstelpunt en de beginsituatie vast

Maak vóór een wijziging een actuele back-up van de WordPress-bestanden en database. Download daarnaast losse kopieën van bestanden die je mogelijk aanpast, zoals .htaccess of een nginx-serverblok. Controleer of je weet hoe je die kopie terugzet via SFTP, het hostingpaneel of de beheerconsole.

Noteer vervolgens:

• de volledige probleem-URL;
• datum, tijd en tijdzone;
• je openbare IP-adres als de fout persoonsgebonden lijkt;
• de laatste geslaagde aanvraag;
• updates en configuratiewijzigingen vlak vóór de fout;
• welke test-URL’s nog wel werken.

De officiële WordPress-handleiding over serverconfiguratie adviseert bij serverwijzigingen een actuele back-up en een kopie van de oorspronkelijke configuratie. Dat maakt elke volgende stap omkeerbaar.

2. Zoek de laag die de 403 teruggeeft

Open rond het genoteerde tijdstip de access- en errorlogs van je hosting, webserver en eventuele firewall of CDN. Zoek op het exacte pad en, waar mogelijk, je IP-adres. Let op woorden als denied, forbidden, access, permission, rule, WAF en een firewallregel-ID.

De afzender bepaalt de volgende stap:

• Een firewallregel-ID wijst naar CDN-, WAF- of hostingbeveiliging.
• client denied by server configuration wijst vaak naar Apache-toegangsregels.
• access forbidden by rule wijst vaak naar een nginx-regel.
• permission denied met een bestandspad wijst naar eigenaar, rechten of een bovenliggende map.
• Een WordPress-pluginpad of pluginlog wijst naar applicatiebeveiliging.

Zet WP_DEBUG_DISPLAY niet aan op een live site om een 403 te onderzoeken. Een blokkade vóór PHP verschijnt niet in WordPress-debuguitvoer en zichtbare debugdetails kunnen gevoelige informatie lekken. Als WordPress wel wordt uitgevoerd, laat je volgens de officiële uitleg voor debuggen in WordPress fouten tijdelijk naar een log schrijven en schakel je dat na de test weer uit.

3. Test een beveiligingsplugin zonder je herstelroute te verliezen

Kun je nog in WordPress, pauzeer dan alleen de plugin die in de log of laatste wijziging wordt genoemd. Leeg de cache van die plugin, vraag de probleem-URL één keer opnieuw op en activeer de plugin weer als de fout blijft.

Kun je niet inloggen, gebruik dan SFTP of het bestandsbeheer van je host. Hernoem alleen de map van de vermoedelijke plugin, bijvoorbeeld van security-plugin naar security-plugin.test-uit. Test opnieuw. Geef de map direct de oorspronkelijke naam terug als de 403 blijft, zodat instellingen en updates niet onnodig worden verstoord.

Schakel niet alle beveiligingslagen tegelijk uit. Als de fout dan verdwijnt, weet je nog steeds niet welke regel de oorzaak was en staat de site tijdens de test onnodig open. Leidt een pluginwijziging tot een PHP-fout, ga dan verder met de handleiding voor een kritieke WordPress-fout.

4. Controleer CDN, WAF en hostingbeveiliging

Hostingafhankelijke route: open het beveiligings- of firewalloverzicht van je provider. Zoek de geblokkeerde aanvraag op basis van tijd, IP, URL en regel-ID. Controleer of een rate limit, botfilter, landblokkade, hotlinkbeveiliging of beheerders-IP-lijst is geactiveerd.

Maak een smalle uitzondering voor het specifieke geldige verzoek als je de oorzaak hebt bevestigd. Schakel niet de volledige firewall uit en zet een brede uitzondering niet permanent aan. Test de uitzondering, documenteer de reden en verwijder hem weer als hij de fout niet oplost.

Heb je geen toegang tot deze logs, stuur de provider je meetgegevens en vraag expliciet welke laag en regel de 403 produceerde. Een provider die alleen je IP-adres deblokkeert zonder oorzaak, kan hetzelfde probleem bij de volgende bezoeker laten terugkomen.

5. Volg op Apache de .htaccess-route

Alleen voor Apache of LiteSpeed: Apache kan toegangsregels uit de serverconfiguratie en, wanneer toegestaan, uit .htaccess lezen. De officiële Apache-uitleg over toegangscontrole beschrijft onder meer Require-regels en een RewriteRule met de vlag [F], die bewust een 403 teruggeeft.

Download eerst .htaccess en bewaar de exacte bestandsnaam, inhoud en rechten. Hernoem het bestand daarna tijdelijk naar bijvoorbeeld .htaccess.before-403-20260728. Test één keer:

• Verdwijnt de 403, vergelijk de oude regels met de standaardregels die WordPress of je host voor deze installatie genereert. Let vooral op Require all denied, oude Deny from all, IP-filters en rewrite-regels met [F].
• Blijft de 403, zet de oorspronkelijke bestandsnaam meteen terug. De oorzaak zit dan waarschijnlijk elders.

Verwijder geen beveiligingsblok zonder te weten welk pad het beschermt. Regels die toegang tot wp-config.php, back-ups of verborgen bestanden blokkeren, horen vaak bewust een 403 te geven. De Apache-handleiding voor .htaccess legt bovendien uit dat serverconfiguratie de voorkeur heeft wanneer je daar toegang toe hebt.

6. Herstel alleen aantoonbaar verkeerde eigenaar of rechten

Controleer het pad uit de foutlog, inclusief alle bovenliggende mappen. Een bestand kan leesbaar lijken, terwijl de webserver een bovenliggende map niet mag doorlopen. Vergelijk eigenaar, groep en rechten met een werkend bestand van hetzelfde type en met de richtlijnen van je host.

De officiële WordPress-handleiding voor het beveiligen van WordPress benadrukt dat rechten zo beperkt mogelijk moeten blijven en dat eigenaarschap afhangt van de serveropzet. 755 voor mappen en 644 voor bestanden zijn veelgebruikte uitgangspunten, maar geen universeel herstelcommando.

Voer dus geen recursieve chmod 777 uit. Laat bij managed hosting de provider eigenaar en groep herstellen. Wijzig bij zelfbeheer alleen het aangetoonde pad, noteer de oude waarde, test en zet de oude waarde terug als de logmelding niet verandert.

7. Volg op nginx de serverconfiguratieroute

Alleen voor nginx en alleen als je serverbeheer hebt: nginx leest geen .htaccess. Controleer het actieve serverblok en meegelezen configuratiebestanden op deny, allow, auth_basic, limit_except, locatieblokken en regels voor verborgen bestanden.

De officiële documentatie van ngx_http_access_module beschrijft dat allow- en deny-regels in volgorde worden geëvalueerd tot de eerste overeenkomst. Een algemene deny all boven of binnen het verkeerde location-blok kan daardoor meer blokkeren dan bedoeld.

Maak een kopie van de actieve configuratie, pas alleen de bewezen regel aan en voer vóór herladen een syntaxiscontrole uit met:

nginx -t

Herlaad nginx pas als de controle slaagt en je daartoe bevoegd bent. Herstel de kopie als de test-URL nog steeds 403 geeft. Bij managed hosting is dit een taak voor de provider: stuur de logregel en vraag om controle van het specifieke server- of locatieblok.

8. Controleer de reparatie en sluit het onderzoek af

Test na de kleinste geslaagde wijziging:

1. de oorspronkelijke URL, afgemeld en ingelogd;
2. de homepage en een gewone pagina;
3. /wp-admin/ en de loginroute;
4. een upload of formulieractie als die eerder faalde;
5. een tweede netwerk als de blokkade IP-afhankelijk was;
6. de server- en firewalllog op nieuwe weigeringen.

Leeg alleen de relevante cache en controleer zowel de origin als de publieke route wanneer een CDN ervoor staat. Zet tijdelijke pluginmapnamen, debuginstellingen en firewalluitzonderingen terug. Bewaar de oorzaak, wijziging en rollbackinstructie bij je technisch beheer.

Veelgemaakte fouten

• 403 behandelen als een WordPress-fout zonder logs. De weigering kan al in CDN, firewall of webserver ontstaan.
• Alle plugins tegelijk uitschakelen. Daarmee vergroot je de impact en verlies je bewijs over de echte veroorzaker.
• De hele firewall uitzetten. Maak alleen na logbevestiging een smalle, tijdelijke uitzondering.
• .htaccess aanpassen op nginx. nginx leest dit bestand niet en vraagt om een andere diagnose.
• Een beveiligingsregel blind verwijderen. Een regel kan gevoelige configuratie of back-ups terecht afschermen.
• Rechten recursief op 777 zetten. Dat is geen diagnose en maakt bestanden onnodig schrijfbaar.
• Alleen in je eigen browser testen. Cache, cookies of een IP-regel kunnen het resultaat vertekenen.
• Geen rollback vastleggen. Zonder originele mapnaam, configuratie en rechten kun je een mislukte test niet betrouwbaar terugdraaien.

Wanneer je hostingbeheer nodig hebt

Vraag hulp als je geen toegang hebt tot firewall- of webserverlogs, als eigenaar en groep niet vanuit je account kunnen worden hersteld, of als de 403 uit een beheerde nginx- of Apache-configuratie komt. Stuur geen wachtwoorden of volledige configuratiebestanden per onbeveiligde mail.

Geef de beheerder de URL, tijd met tijdzone, je IP, foutbereik, relevante regel-ID en je reeds uitgevoerde omkeerbare tests. Voor andere foutmeldingen en veilige herstelroutes staat het overzicht op de WordPress-hub. Wil je dat iemand de oorzaak en reparatie gecontroleerd uitvoert, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.