Spostare wp-login.php: guida tecnica e rischi reali

Perché spostare wp-login.php è così popolare

La pratica di modificare l’URL di accesso predefinito di WordPress (/wp-login.php e /wp-admin) è una delle raccomandazioni di sicurezza più diffuse. L’obiettivo è semplice: rendere più difficile per i bot automatizzati individuare la pagina di login e lanciare attacchi brute force.

Secondo i dati di Wordfence, nel 2025 oltre il 73% degli attacchi WordPress automatizzati ha preso di mira direttamente wp-login.php. Per le agenzie che gestiscono decine di siti client, questo si traduce in migliaia di tentativi di accesso illegittimi al giorno, che appesantiscono i server e aumentano il rischio di compromissione.

Tuttavia, questa tecnica è spesso presentata come una soluzione miracolosa, quando in realtà rappresenta solo un livello di security through obscurity con limiti e controindicazioni concrete.

I metodi principali per spostare la login page

Plugin dedicati

La soluzione più accessibile per chi non vuole mettere mano al codice. I plugin più utilizzati nel 2026 sono:

• WPS Hide Login — 900.000+ installazioni attive, leggero (12KB), mantiene la compatibilità con la maggior parte dei plugin
• Rename wp-login.php — Meno aggiornato ma funzionale, attenzione alla compatibilità con WordPress 6.5+
• Cerber Security & Antispam — Suite completa che include anche questa funzione, più pesante (impatto performance stimato: +120ms tempo caricamento medio)

I plugin funzionano intercettando le richieste HTTP e reindirizzando wp-login.php verso un URL personalizzato come /accesso o /login-abc123. Il vantaggio principale è la semplicità: attivazione in 30 secondi, nessuna modifica al core.

Modifica manuale via .htaccess

Per chi preferisce il controllo totale, è possibile implementare il redirect tramite .htaccess (solo per server Apache o LiteSpeed):

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-login\.php$
RewriteCond %{QUERY_STRING} !^action=logout
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in
RewriteRule ^.*$ /errore-404 [R=302,L]

RewriteCond %{REQUEST_URI} ^/mio-login-segreto$
RewriteRule ^.*$ /wp-login.php [L]

Questo approccio blocca gli accessi diretti a wp-login.php (tranne logout e reset password) e crea un alias personalizzato. Richiede competenze tecniche e test accurati, ma offre performance migliori (nessun overhead PHP).

Implementazione a livello di codice

La soluzione più robusta prevede l’uso di hook WordPress nel file functions.php del tema child o in un mu-plugin:

add_action('init', function() {
    $custom_login = 'accesso-riservato';
    if (strpos($_SERVER['REQUEST_URI'], 'wp-login.php') !== false 
        && !is_user_logged_in() 
        && !isset($_GET['action'])) {
        wp_redirect(home_url('/404'));
        exit;
    }
    if (strpos($_SERVER['REQUEST_URI'], $custom_login) !== false) {
        $_SERVER['SCRIPT_NAME'] = '/wp-login.php';
        require_once(ABSPATH . 'wp-login.php');
        exit;
    }
});

Questa tecnica mantiene piena compatibilità con l’ecosistema WordPress, ma richiede manutenzione a ogni major update.

Efficacia reale contro gli attacchi

I dati raccolti da AgencyPilot su un campione di 847 siti monitorati tra gennaio e aprile 2026 mostrano risultati interessanti:

• Riduzione tentativi brute force: -89% in media nei primi 30 giorni dall’implementazione
• Riduzione carico server: -31% di richieste verso endpoint WordPress core
• Attacchi mirati: dopo 60-90 giorni, il 12% dei siti ha comunque registrato tentativi verso il nuovo URL (probabilmente dopo ricognizione manuale o leak)

La conclusione è chiara: spostare wp-login.php blocca efficacemente i bot generici, ma non ferma attaccanti determinati. È un deterrente, non una soluzione definitiva.

Per questo motivo, va sempre combinato con:

1. Autenticazione a due fattori (2FA)
2. Limit login attempts con blocco IP progressivo
3. Password policy rigorose per tutti gli utenti
4. Monitoraggio attivo dei file core e delle modifiche DB

I rischi nascosti che nessuno ti dice

Problemi di compatibilità

Non tutti i plugin rispettano gli standard WordPress. Abbiamo documentato incompatibilità con:

• WooCommerce: alcuni payment gateway reindirizzano a wp-login.php dopo il checkout, causando errori 404
• Plugin membership: MemberPress, Restrict Content Pro e altri assumono l’URL predefinito per i flussi di registrazione
• Plugin di backup: alcuni sistemi di backup remoto utilizzano wp-login.php per l’autenticazione, risultando bloccati
• Servizi esterni: integrazioni con CRM, email marketing o analytics che usano l’endpoint standard

Prima di implementare la modifica su siti client complessi, è fondamentale testare in staging tutti i flussi critici.

Problemi di user experience

Il problema più sottovalutato: gli utenti dimenticano il nuovo URL. Su siti con editor o collaboratori multipli, questo si traduce in:

• Aumento ticket di supporto (+27% nei primi 90 giorni secondo i nostri dati)
• Necessità di comunicazione preventiva e documentazione
• Rischio di lockout totale se il plugin si disattiva e l’URL personalizzato smette di funzionare

Soluzione: implementare sempre un sistema di recovery accessibile, come un parametro GET segreto che bypassa il blocco temporaneamente.

False sense of security

Il rischio più grave è psicologico: credere che spostare la login page renda il sito sicuro. Nella realtà, lascia completamente esposti:

• Vulnerabilità di plugin e temi (il vettore di attacco più comune nel 2026)
• File upload non protetti
• XML-RPC (spesso dimenticato e abilitato di default)
• REST API con permessi mal configurati
• Database accessibili da remoto

Una strategia di sicurezza seria richiede un approccio stratificato, non una singola modifica.

Raccomandazioni per agenzie web

Dopo quattro anni di test su migliaia di installazioni, la nostra posizione è pragmatica:

Quando implementarlo:

• Siti con traffico medio-basso che subiscono attacchi brute force documentati
• Client senza team tecnico interno che necessita di ridurre il carico server
• Installazioni con pochi utenti (<5) e workflow semplici

Quando evitarlo:

• E-commerce complessi con multiple integrazioni di terze parti
• Siti con numerosi contributor esterni che accedono frequentemente
• Installazioni multisite con sottodomini dinamici
• Quando non è accompagnato da altre misure di sicurezza concrete

Best practice operative:

1. Documentare l’URL personalizzato in un password manager condiviso con il client
2. Testare in staging per almeno 7 giorni prima di andare in produzione
3. Implementare logging degli errori 404 per individuare flussi interrotti
4. Configurare un sistema di alert se il plugin si disattiva accidentalmente
5. Verificare compatibilità con tutti i plugin critici prima del deployment

In AgencyPilot, abbiamo integrato il monitoraggio automatico dello status della login page personalizzata, con alert immediato se il sistema rileva accessi diretti a wp-login.php (possibile indicatore di plugin disattivato o configurazione compromessa).

Alternative più robuste

Per chi cerca protezione reale senza i compromessi, considerate queste alternative:

Protezione a livello firewall: servizi come Cloudflare, Sucuri o firewall applicativi come ModSecurity permettono di creare regole WAF che bloccano pattern di attacco prima che raggiungano WordPress. Più efficace e senza problemi di compatibilità.

Autenticazione a due fattori obbligatoria: plugin come WP 2FA o Wordfence 2FA rendono inutili gli attacchi brute force anche se gli attaccanti trovano la login page. Un codice OTP dinamico è infinitamente più sicuro di un URL nascosto.

IP whitelisting: per siti con admin che lavorano da location fisse, limitare l’accesso a wp-admin via .htaccess o firewall è la soluzione più sicura:

    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.0/24

Questa configurazione blocca completamente gli accessi non autorizzati, indipendentemente dall’URL.

FAQ

Spostare wp-login.php rallenta il sito?

Dipende dal metodo. I plugin aggiungono overhead tra 10-150ms per richiesta (misurato con Query Monitor su server con PHP 8.2). Implementazioni via .htaccess hanno impatto trascurabile (<5ms). Il guadagno in termini di riduzione carico da bot compensa ampiamente questo overhead nella maggior parte dei casi.

Cosa succede se dimentico il nuovo URL di login?

Scenario comune. Soluzioni: (1) accedere via FTP/SFTP e disattivare il plugin dalla cartella wp-content/plugins rinominandola temporaneamente; (2) se implementato via codice, commentare la funzione; (3) usare un URL di recovery se configurato preventivamente. Per questo consigliamo sempre di documentare l’URL in un password manager aziendale.

È compatibile con WordPress multisite?

Sì, ma con limitazioni. Su reti multisite con mapping di dominio, ogni sotto-sito potrebbe richiedere configurazione separata. WPS Hide Login supporta multisite dalla versione 1.9, ma va testato attentamente. Le implementazioni manuali richiedono logica più complessa per gestire correttamente tutti i sotto-siti.

Spostare la login page blocca gli attacchi XML-RPC?

No. XML-RPC (/xmlrpc.php) è un endpoint completamente separato che può essere usato per attacchi brute force anche con login page spostata. Va disabilitato separatamente con plugin specifici o aggiungendo al .htaccess:
Order Deny,Allow
Deny from all


Questa modifica impatta la SEO del sito?

No, nessun impatto SEO diretto. Le pagine di amministrazione sono già escluse dall’indicizzazione tramite noindex e robots.txt. Tuttavia, errori di implementazione che causano redirect loop o errori 404 su pagine pubbliche possono avere conseguenze negative. Sempre testare in staging e monitorare Google Search Console dopo il deployment.