De WordPress login-URL wijzigen (/wp-login.php)

Open het toegangslogboek van een WordPress-site die langer dan een paar dagen online is en zoek naar wp-login.php. U vindt honderden, vaak duizenden regels van IP-adressen waarvan u nog nooit heeft gehoord, allemaal proberend gebruikelijke combinaties van gebruikersnamen en wachtwoorden. WordPress-login is een van de zwaarst aangevallen endpoints op het openbare web, simpelweg omdat de URL universeel is. Elke WordPress-site ter wereld serveert het loginformulier op /wp-login.php en /wp-admin. Dat maakt het triviaal eenvoudig voor botnets om op grote schaal aan te vallen.

Het verplaatsen van de login-URL naar iets aangepasts lost het onderliggende probleem niet op (iemand met werkelijke interesse in uw specifieke site zal de nieuwe URL toch vinden), maar het verwijdert de site van de miljoenen geautomatiseerde lijsten die het standaardendpoint scrapen en bestoken. In de praktijk laat dat het loginverkeer met 95% of meer dalen, wat alleen voor serverbelasting al een betekenisvolle winst is. Deze gids legt uit wat de wijziging daadwerkelijk bewerkstelligt, de verschillende manieren om deze te implementeren en de valkuilen om te vermijden.

Wat het wijzigen van de login-URL wel en niet doet

De moeite waard om hier precies over te zijn, omdat het onderwerp in beide richtingen verkeerd wordt voorgesteld. Sommige gidsen verkopen het als een complete verdediging, andere wuiven het weg als beveiligingstheater. De accurate positie ligt tussen de twee in.

Wat het goed doet:

• Stopt geautomatiseerde botnets die zich rechtstreeks richten op /wp-login.php. De overgrote meerderheid van het brute-force-verkeer zijn domme scripts die door woordenlijsten itereren. Ze zoeken niet naar de nieuwe URL omdat dat een echt bezoek en HTML-parsing vereist.
• Verwijdert u uit "WordPress login aanwezig"-filterlijsten die scanners bouwen om snel doelwitten te vinden.
• Vermindert serverbelasting en logruis drastisch. Op drukke sites is dit alleen al reden genoeg.
• Beperkt onbedoelde adminzichtbaarheid. De loginpagina lekt al door zijn bestaan: foutmeldingen, het favicon, het WordPress-logo, de versie van de logintemplate. Het verbergen van de URL verbergt dat allemaal.

Wat het niet doet:

• Een vastberaden aanvaller stoppen die zich specifiek op uw site richt. Ze zullen de nieuwe URL vinden via een van: de loginredirect die plaatsvindt na uitloggen, de wachtwoordresetmail die naar de nieuwe URL linkt, het cookiepad, een gelekte link in uw CMS, of door gewoon gebruikelijke slugs te raden.
• Sterke wachtwoorden of tweefactorauthenticatie vervangen. De login-URL is een laag voor de werkelijke authenticatie. De echte verdediging is nog steeds wat zich op het formulier bevindt, niet waar het formulier staat.
• Beschermen tegen kwetsbaarheden op applicatieniveau. Als een plug-in een externe code-uitvoeringsbug heeft, is de login-URL irrelevant.

Het pragmatische frame: de login-URL wijzigen is een wijziging met hoog rendement en weinig moeite die één specifieke klasse van aanvallen aanpakt (ongerichte geautomatiseerde brute-forcing). Het past goed bij sterke wachtwoorden, 2FA en een rate limiter, maar vervangt geen van deze.

De aanbevolen manier: WPS Hide Login (of equivalent)

Voor 95% van de sites is de schoonste oplossing de gratis plug-in WPS Hide Login. Hij is klein (onder 100KB), wordt al jaren actief onderhouden, heeft meer dan een miljoen actieve installaties en doet precies één ding: de login-URL-slug wijzigen. Geen upsells, geen instellingenpaneel volgepropt met irrelevante functies.

Setup duurt een minuut:

1. Installeer WPS Hide Login vanuit de plug-in-directory.
2. Activeer hem.
3. Ga naar Instellingen, WPS Hide Login.
4. Voer uw nieuwe slug in het veld "Login-URL" in. Voorbeelden: mijn-geheime-login, backstage, access-2347. Vermijd voor de hand liggende keuzes zoals admin, secret, login, uw domeinnaam met een nummer eraan toegevoegd, etc.
5. Stel optioneel een "Doorverwijzings-URL" in voor bezoeken aan de oude /wp-login.php. Het standaardgedrag retourneert een 404, wat is wat u wilt tegen scanners. Een aangepaste doorverwijzing naar de homepage is ook prima.
6. Sla op.

Vanaf dit punt retourneert https://uwdomein.nl/wp-login.php een 404 voor buitenstaanders, en logt u in via https://uwdomein.nl/mijn-geheime-login. Bookmark de nieuwe URL onmiddellijk. De plug-in slaat de slug niet op een plaats op die van buitenaf zichtbaar is, dus als u de URL vergeet en u geen FTP-toegang heeft, hebt u een probleem (hoewel er een herstelpad is dat hieronder beschreven wordt).

Alternatief: een aangepaste slug zonder plug-in

Als u liever geen extra plug-in toevoegt, kunt u hetzelfde effect in code implementeren. Plaats dit in een must-use-plug-in onder wp-content/mu-plugins/custom-login-url.php:

<?php
/**
 * Plugin Name: Custom Login URL
 * Description: Hides /wp-login.php behind a custom slug.
 */

if (!defined('ABSPATH')) {
    exit;
}

const CUSTOM_LOGIN_SLUG = 'my-secret-login';

add_action('init', function () {
    $requestUri = isset($_SERVER['REQUEST_URI']) ? (string) $_SERVER['REQUEST_URI'] : ';
    $path = parse_url($requestUri, PHP_URL_PATH) ?? ';
    $path = trim($path, '/');

    // Allow access via the custom slug by serving wp-login.php
    if ($path === CUSTOM_LOGIN_SLUG) {
        require_once ABSPATH . 'wp-login.php';
        exit;
    }

    // Block direct access to the default login URL
    if (preg_match('#(^|/)wp-login\.php$#', $path)) {
        status_header(404);
        nocache_headers();
        include get_404_template();
        exit;
    }
});

// Rewrite the URL in emails and login redirects
add_filter('site_url', function ($url, $path) {
    if (str_contains((string) $path, 'wp-login.php')) {
        return str_replace('wp-login.php', CUSTOM_LOGIN_SLUG, $url);
    }
    return $url;
}, 10, 2);

add_filter('wp_redirect', function ($location) {
    return str_replace('wp-login.php', CUSTOM_LOGIN_SLUG, $location);
});

Het voordeel van deze aanpak is volledige controle en nul plug-in-afhankelijkheden. Het nadeel is dat u het zelf moet onderhouden, en randgevallen (multisite, aangepaste registratiestromen, bepaalde page builders die het loginformulier gebruiken) hebben extra afhandeling nodig. Voor de meeste sites is WPS Hide Login werkelijk het praktischere antwoord.

Een goede slug kiezen

De slug hoeft alleen niet voor de hand liggend te zijn, niet cryptografisch geheim. Een paar vuistregels:

• Vermijd gebruikelijke variaties van "login", "admin" of "wp". Scanners die verder gaan dan /wp-login.php hebben meestal een lijst: /login, /admin, /secure-login, /wp-secret, /backend, /dashboard. Kies iets dat niet op die lijst staat.
• Kies iets dat voor u memorabel is, niet willekeurig. Een slug die u uit het hoofd kunt typen is prima. mijn-kat-tofu is veel beter dan k7Hg2P omdat u de laatste in een wachtwoordmanager opslaat en de eerste niet vergeet.
• Gebruik niet het domein of de bedrijfsnaam. example-login op example.com is het eerste wat een gerichte aanvaller probeert.
• Kleine letters, geen speciale tekens. URL's zijn technisch hoofdlettergevoelig, maar echte gebruikers vertypen hoofdletters voortdurend. Een slug in kleine letters voorkomt die hele klasse van "ik kan niet inloggen"-tickets.

Veelvoorkomende valkuilen en randgevallen

Een handvol dingen breekt of gedraagt zich onverwacht wanneer u de login-URL verplaatst. De moeite waard om vooraf te weten.

• WooCommerce "Mijn account"-pagina. De klantenlogin op /mijn-account/ is een afzonderlijke flow en wordt niet beïnvloed door de wijziging. U verbergt alleen de adminlogin. WooCommerce-klanten loggen normaal in.
• Tweefactorauthenticatie-plug-ins. De meeste grote 2FA-plug-ins (Wordfence, WP 2FA, miniOrange, etc.) werken prima met WPS Hide Login. Ze haken in op het loginproces op een laag onder de URL en geven niet om waar het formulier staat. Test eens na activering.
• REST API en XML RPC. De wijziging van de login-URL heeft geen invloed op /wp-json/ of /xmlrpc.php. Als u applicaties hebt die zich tegen die endpoints authenticeren, blijven ze werken zoals voorheen. Als u XML RPC niet actief gebruikt, is dit een goed moment om het volledig uit te schakelen (aparte gids in onze kennisbank).
• Cachingplug-ins. Sommige agressieve paginacaches (LiteSpeed Cache met edge caching, Cloudflare APO) kunnen de nieuwe login-URL cachen of, erger nog, een ingelogde adminreactie cachen en deze aan uitgelogde bezoekers serveren. Bezoek na de wijziging de nieuwe URL in een privévenster. Als u een ingelogde adminweergave ziet, is de cache gebroken; leeg deze en voeg de slug toe aan de cache-uitsluitingslijst.
• Wachtwoordresetmails. Zowel WPS Hide Login als het bovenstaande codefragment herschrijven de wachtwoordreset-URL automatisch, maar aangepaste e-mailplug-ins of transactionele e-mailintegraties hardcoderen soms wp-login.php in hun templates. Stuur na de wijziging een test-wachtwoordreset naar uzelf.
• Submapinstallaties en multisite. Beide werken, maar let op of de slug aan de verkeerde basis-URL wordt toegevoegd. Als WordPress in /blog/ staat, is de nieuwe URL https://uwdomein.nl/blog/mijn-geheime-login, niet https://uwdomein.nl/mijn-geheime-login.

Herstel: wat te doen als u zichzelf buitensluit

Dit gebeurt. U stelt de slug in, logt uit, sluit het tabblad, en een week later kunt u zich niet meer herinneren of u streepjes, underscores hebt gebruikt of wat het derde woord was. U zit niet vast, maar het herstelpad hangt af van de gebruikte methode.

Als u WPS Hide Login hebt gebruikt: deactiveer de plug-in via SFTP. Hernoem de map wp-content/plugins/wps-hide-login naar wps-hide-login.disabled, of verwijder hem volledig. De standaard /wp-login.php-URL komt onmiddellijk terug. Log in, zoek uw slug op in de plug-in-instellingen, activeer dan de plug-in opnieuw. Of alternatief, kijk rechtstreeks in de WordPress-database: de slug wordt opgeslagen in de tabel wp_options onder de sleutel whl_page.

Als u de aangepaste code hebt gebruikt: SFTP naar wp-content/mu-plugins/, open het bestand, lees de slug uit de constante CUSTOM_LOGIN_SLUG. Of hernoem het bestand tijdelijk om het uit te schakelen, log in, plaats het dan terug.

Schrijf in beide gevallen de URL ergens duurzaam op zodra u deze instelt. Wachtwoordmanager, projectdocumentatie, alles dat het verlies van een browser-bookmark overleeft.

Hoe verifieert u dat de wijziging actief is

1. Open https://uwdomein.nl/wp-login.php in een privévenster. Verwacht resultaat: een 404-pagina.
2. Dezelfde controle voor https://uwdomein.nl/wp-admin/. Zou ook moeten doorverwijzen naar de 404, niet naar het loginformulier.
3. Open de nieuwe URL https://uwdomein.nl/mijn-geheime-login. Zou het standaard WordPress-loginformulier moeten tonen.
4. Log normaal in, log uit, klik op de link "Uitloggen". De doorverwijzing zou op de nieuwe URL moeten landen, niet op /wp-login.php.
5. Activeer een wachtwoordreset voor uzelf. De link in de e-mail zou naar de nieuwe URL moeten wijzen.
6. Voer een nieuwe InspectWP-scan uit. Controles met betrekking tot de login-URL zouden de nieuwe status moeten weerspiegelen.

Eenmaal geverifieerd is het enige doorlopende onderhoud ervoor zorgen dat de plug-in (of uw aangepaste code) blijft werken bij WordPress core-updates, wat zou moeten. Als een grote update ooit verandert hoe de loginflow intern werkt, is WPS Hide Login een van de eerste plug-ins die een patch uitbrengt, meestal binnen dagen.

De hele wijziging is een halfuur werk voor een permanente vermindering van het aanvalsoppervlak en een merkbare daling van serverbelasting. Er is geen goede reden om de WordPress-login op een productiesite op zijn standaardlocatie te laten.