/wp-admin en /wp-login.php zijn de twee meest aangevallen URL's op elke WordPress-site. Botnetwerken proberen daar onophoudelijk combinaties van gebruikersnaam en wachtwoord uit. Op een onbeschermde site zijn een paar duizend brute-force-pogingen per dag normaal — en zeer zelden onschuldig. Het eenvoudigste, meest effectieve eerste beschermingsmechanisme: de inlog-URL verplaatsen. In dit artikel laat ik u zien hoe u dat doet zonder serverconfiguratie en zonder het risico uzelf buiten te sluiten.
Waarom de inlog-URL überhaupt wijzigen?
Drie effecten:
- Brute-force-pogingen lopen dood. Bots blijven
/wp-login.phpproberen — uw echte inlog-URL kennen ze niet. - De serverbelasting daalt. Elke brute-force-poging verbruikt PHP- en databasebronnen. Op shared hosting meetbaar.
- Het beveiligingslogboek wordt schoner. U ziet werkelijke aanvallen in plaats van 99 % botruis.
Het is geen volledige bescherming — een professionele aanvaller vindt de nieuwe URL via scanners of fingerprints (structuren van het inlogformulier). Maar het schakelt 95 % van de geautomatiseerde druk uit.
Methode 1 (aanbevolen): plugin „WPS Hide Login“
De plugin doet precies één taak, doet die netjes en heeft geen serverrechten nodig. Ruim 1 miljoen actieve installaties, doorlopend onderhouden.
Zo gaat u te werk:
- Plugins → Nieuwe plugin → zoeken naar „WPS Hide Login“ → installeren, activeren.
- Voer onder Instellingen → WPS Hide Login de nieuwe inlogslug in, bijv.
mijn-toegangofnoorderster-42. Vermijd woorden als „admin“, „login“, „secret“, die in woordenlijsten van scanners staan. - Stel de redirect-URL in — waarheen niet-ingelogde bezoekers worden doorgestuurd wanneer ze
/wp-adminoproepen. Standaard: de 404-pagina. Ik raad in plaats daarvan de homepage of een eigen pagina aan. - Opslaan.
Belangrijk — voordat u opslaat: noteer de nieuwe slug op een veilige plek, idealiter in uw wachtwoordmanager. Vergeet u hem, dan moet u de plugin via FTP uitschakelen (zie het noodgedeelte hieronder).
Test onmiddellijk na het opslaan:
https://uw-domein.nl/wp-admin→ zou naar het redirect-doel moeten leiden.https://uw-domein.nl/wp-login.php→ hetzelfde.https://uw-domein.nl/mijn-toegang→ het inlogformulier verschijnt.
Klopt alles: werk meteen ook de bladwijzers in de wachtwoordmanager bij.
Methode 2: als ingebouwde functie in de beveiligingsplugin
Gebruikt u toch al Solid Security (vroeger iThemes Security) of Wordfence, dan heeft u geen extra plugin nodig. Beide bieden „Hide Backend“/„Hide Login URL“ als ingebouwde functie.
Voordeel: een plugin minder. Nadeel: bij een pluginwissel moet u opletten dat de nieuwe inlog-URL behouden blijft of bewust gewijzigd wordt.
Bij Solid Security: Solid → Settings → Hide Backend → activeren → URL instellen → opslaan.
Meer over de vergelijking van beveiligingsplugins in mijn pijlerartikel WordPress-plugins 2026 en in het bestaande WordPress-beveiligingsmaatregelen.
Methode 3: serverzijdig via .htaccess (Apache)
Voor ervaren gebruikers met Apache-hosting. De inlog-URL wordt zonder plugin verplaatst:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^mijn-toegang/?$ /wp-login.php [L]
RewriteCond %{REQUEST_URI} ^/wp-login\.php [NC]
RewriteCond %{HTTP_REFERER} !mijn-toegang [NC]
RewriteRule ^.*$ - [F,L]
</IfModule>Voordelen: geen pluginbelasting, zeer vroeg in de verwerking van het verzoek. Nadelen: wordt de .htaccess bij een thema- of plugin-update door een ander gereedschap aangepast, dan wordt de regel vaak overschreven. Meer onderhoud dus.
Bij Nginx (in plaats van Apache) werkt dit niet — daar is een ingreep in de Nginx-configuratie nodig, wat bij de meeste hosters niet is toegestaan. De pluginoplossing is dan de pragmatische weg.
De inlog-URL alleen volstaat niet — de drie aanvullingen
Bent u toch in beveiligingsmodus, vul dan deze drie dingen aan:
1. Tweefactorauthenticatie (2FA)
De belangrijkste afzonderlijke beveiligingsmaatregel. Zelfs bij een correct wachtwoord beschermt 2FA de toegang.
Aanbevolen plugins:
- WP 2FA (gratis)
- Two-Factor (open source, van WordPress-core-ontwikkelaars)
- Solid Security Pro (ingebouwd)
U scant een QR-code met een authenticator-app (Google Authenticator, Authy, 1Password, Bitwarden) en bij het inloggen voert u na het wachtwoord een zescijferige code in.
2. Standaardgebruikersnaam „admin“ verwijderen
Heet uw beheerdersaccount nog „admin“, dan is de eerste helft van de brute-force-poging al geraden. Maak een nieuw beheerdersaccount met een andere naam aan, ontneem de oude „admin“-gebruiker zijn rechten, log in met de nieuwe gebruiker en verwijder de oude. Inhoud van de oude gebruiker wordt bij het verwijderen aan een andere gebruiker toegewezen — geen gegevensverlies.
3. Inlogpogingen begrenzen
Zelfs met een verplaatste URL — wordt de nieuwe URL ooit toch gevonden, dan moet de aanvaller na 5 foute pogingen een uur geblokkeerd zijn.
Plugins: Limit Login Attempts Reloaded (gratis); Solid Security en Wordfence hebben dit ingebouwd.
Wilt u WordPress-beveiliging niet in stukjes leren, maar als samenhangend systeem? In mijn onlinecursus laat ik u de gelaagde beveiligingsstack zien die ik op elke nieuwe site inricht — van inlog tot firewall. → Naar de onlinecursus
Noodgeval: buitengesloten omdat u de URL vergeten bent
Het gebeurt. Vooral na een hosterwissel of wanneer de plugin na een update de URL tijdelijk terugzet. Zo komt u weer binnen:
- Ga via FTP/SFTP naar de map
wp-content/plugins/wps-hide-login/. - Hernoem de map naar
wps-hide-login-uitgeschakeld. - WordPress schakelt de plugin daarmee automatisch uit.
/wp-login.phpis weer bereikbaar onder het standaardpad.- Inloggen, de nieuwe URL-waarde instellen of de plugin opnieuw configureren.
Heeft u geen FTP-toegang: open hetzelfde pad via het bestandsbeheer van uw hosting (cPanel, Plesk, ISPConfig enz.).
Randgeval: WooCommerce-accounts
WooCommerce-klanten melden zich niet via /wp-login.php aan, maar via /mijn-account. De plugin WPS Hide Login laat die route met rust — de WooCommerce-login blijft gewoon werken. Belangrijk: test dat één keer expliciet voordat u de plugin activeert.
Randgeval: membership-plugins (Paid Memberships Pro, Restrict Content Pro)
Deze plugins maken vaak eigen inlogformulieren aan. Net als bij WooCommerce: de eigen inlogroutes worden niet beïnvloed. U verplaatst alleen de toegang tot het beheer.
SEO-effect: positief
Een verplaatste inlog-URL heeft geen rechtstreeks SEO-effect — maar indirect wel:
- De serverbelasting daalt → betere TTFB → betere Core Web Vitals (zie WordPress Page Speed 2026).
- Minder geslaagde hacks → geen blokkade in Google Safe Browsing, geen reputatieverlies.
Meer SEO-achtergrond in WordPress SEO-basis.
Veelgestelde vragen
Werkt dit met multisite?
Ja, WPS Hide Login ondersteunt multisite uitdrukkelijk. Per subsite kan een andere URL worden ingesteld.
Kan ik de URL later weer wijzigen?
Op elk moment. In de plugininstellingen de nieuwe waarde invoeren, opslaan. De oude URL is meteen dood.
Wat gebeurt er met klikken op oude bladwijzers?
Die komen op de redirect-doel-URL uit (homepage of 404, afhankelijk van de instelling).
Herkennen scanners de nieuwe URL toch?
Professionele scanners wel, met voldoende tijd. Standaardbots: meestal niet. De inlog-URL verplaatsen is defense in depth, geen wondermiddel.
Moet ik ook het standaard databasevoorvoegsel wp_ wijzigen?
Bij nieuwe installaties: ja, kan geen kwaad. Bij bestaande installaties: de verhouding tussen moeite en nut is meestal niet gerechtvaardigd — het risico de database te slopen is reëel.
Werkt dit met de REST API en applicatiewachtwoorden?
Ja. REST-API-toegang loopt via /wp-json/, niet via de inlog-URL — onaangetast.
Conclusie
In 5 minuten geïnstalleerd, schakelt het 95 % van de geautomatiseerde brute-force-druk uit. Aangevuld met 2FA, een aangepaste gebruikersnaam en een inloglimiet heeft u een WordPress-site die voor verreweg de meeste aanvallers simpelweg te duur is.
Wilt u WordPress-beveiliging als samenhangend concept leren — niet als tien losse tips — dan is mijn onlinecursus de rechtstreekse weg. → Naar de onlinecursus
Beeldbron featured & inline: zelf gemaakte illustraties in het pletzenauer-design (geen stockfoto's).
Tags