Cómo cambiar la URL de acceso de WordPress (/wp-login.php)

Abre el log de accesos de cualquier sitio WordPress que lleve unos pocos días en línea y busca wp-login.php. Encontrarás cientos, a menudo miles, de entradas desde direcciones IP de las que nunca has oído hablar, todas probando combinaciones habituales de usuario y contraseña. El acceso a WordPress es uno de los endpoints más atacados de la web pública, simplemente porque la URL es universal. Cada sitio WordPress del mundo sirve el formulario de acceso en /wp-login.php y /wp-admin. Eso hace que sea trivial para las botnets atacar a gran escala.

Mover la URL de acceso a algo personalizado no soluciona el problema de fondo (alguien con un interés real en tu sitio concreto encontrará la nueva URL de todos modos), pero saca al sitio de los millones de listas automatizadas que rastrean y machacan el endpoint por defecto. En la práctica eso reduce el tráfico de acceso en un 95% o más, lo cual ya es una victoria importante solo por la carga del servidor. Esta guía explica qué consigue realmente este cambio, las distintas formas de implementarlo y los escollos que hay que evitar.

Lo que sí hace y lo que no hace cambiar la URL de acceso

Conviene ser preciso, porque el tema se tergiversa en ambas direcciones. Algunas guías lo venden como una defensa completa, otras lo descartan como teatro de seguridad. La postura correcta está entre las dos.

Lo que hace bien:

• Detiene las botnets automatizadas que apuntan directamente a /wp-login.php. La inmensa mayoría del tráfico de fuerza bruta son scripts tontos iterando sobre listas de palabras. No buscan la nueva URL porque eso requiere una visita real y parsear HTML.
• Te saca de las listas de "login de WordPress presente" que los escáneres construyen para encontrar objetivos rápidamente.
• Reduce drásticamente la carga del servidor y el ruido en los logs. En sitios con tráfico elevado, esto por sí solo ya es razón suficiente.
• Disminuye la visibilidad accidental del panel de administración. La página de acceso filtra información solo por existir: mensajes de error, el favicon, el logo de WordPress, la versión de la plantilla de login. Ocultar la URL oculta todo eso.

Lo que no hace:

• Detener a un atacante decidido que ataque específicamente a tu sitio. Encontrará la nueva URL por cualquiera de estas vías: la redirección de login que ocurre tras cerrar sesión, el correo de restablecimiento de contraseña que enlaza a la nueva URL, la ruta de la cookie, un enlace filtrado en tu CMS, o simplemente probando slugs habituales.
• Sustituir a las contraseñas fuertes o a la autenticación de doble factor. La URL de acceso es una capa por delante de la autenticación real. La verdadera defensa sigue siendo lo que hay en el formulario, no dónde vive el formulario.
• Proteger frente a vulnerabilidades a nivel de aplicación. Si un plugin tiene un bug de ejecución remota de código, la URL de acceso es irrelevante.

Encuadre pragmático: cambiar la URL de acceso es un cambio de alto retorno y bajo esfuerzo que aborda una clase específica de ataque (fuerza bruta automatizada y no dirigida). Encaja bien con contraseñas fuertes, 2FA y un limitador de tasa, pero no sustituye a ninguno de ellos.

La forma recomendada: WPS Hide Login (o equivalente)

Para el 95% de los sitios, la solución más limpia es el plugin gratuito WPS Hide Login. Es pequeño (menos de 100KB), lleva años mantenido activamente, tiene más de un millón de instalaciones activas y hace exactamente una cosa: cambiar el slug de la URL de acceso. Sin upsells, sin un panel de ajustes lleno de funciones no relacionadas.

La instalación lleva un minuto:

1. Instala WPS Hide Login desde el directorio de plugins.
2. Actívalo.
3. Ve a Ajustes, WPS Hide Login.
4. Introduce tu nuevo slug en el campo "Login URL". Ejemplos: mi-acceso-secreto, backstage, access-2347. Evita opciones obvias como admin, secret, login, el nombre de tu dominio con un número añadido, etc.
5. Opcionalmente, configura una "Redirection URL" para las visitas al antiguo /wp-login.php. El comportamiento por defecto devuelve un 404, que es lo que quieres frente a los escáneres. Una redirección personalizada a la página de inicio también vale.
6. Guarda.

A partir de ese momento, https://tudominio.com/wp-login.php devuelve un 404 a los de fuera, y tú accedes vía https://tudominio.com/mi-acceso-secreto. Guarda la nueva URL en marcadores inmediatamente. El plugin no almacena el slug en ningún sitio visible desde fuera, así que si olvidas la URL y no tienes acceso por FTP, tienes un problema (aunque más abajo se describe una vía de recuperación).

Alternativa: un slug personalizado sin plugin

Si prefieres no añadir otro plugin, puedes implementar el mismo efecto con código. Coloca esto en un must use plugin en 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 = 'mi-acceso-secreto';

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

    // Permitir el acceso vía el slug personalizado sirviendo wp-login.php
    if ($path === CUSTOM_LOGIN_SLUG) {
        require_once ABSPATH . 'wp-login.php';
        exit;
    }

    // Bloquear el acceso directo a la URL de acceso por defecto
    if (preg_match('#(^|/)wp-login\.php$#', $path)) {
        status_header(404);
        nocache_headers();
        include get_404_template();
        exit;
    }
});

// Reescribir la URL en correos y redirecciones de login
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);
});

La ventaja de este enfoque es el control total y cero dependencias de plugins. La desventaja es que tienes que mantenerlo tú mismo, y los casos límite (multisite, flujos de registro personalizados, ciertos page builders que usan el formulario de acceso) requieren tratamiento extra. Para la mayoría de los sitios, WPS Hide Login es honestamente la respuesta más práctica.

Cómo elegir un buen slug

El slug solo tiene que ser no obvio, no criptográficamente secreto. Algunas reglas básicas:

• Evita variaciones habituales de "login", "admin" o "wp". Los escáneres que van más allá de /wp-login.php suelen tener una lista: /login, /admin, /secure-login, /wp-secret, /backend, /dashboard. Elige algo que no esté en esa lista.
• Elige algo memorable para ti, no aleatorio. Un slug que puedas teclear de memoria está bien. mi-gato-tofu es mucho mejor que k7Hg2P porque este último lo guardarás en un gestor de contraseñas y el primero no lo olvidarás.
• No incluyas el dominio o el nombre de la empresa. example-login en example.com es lo primero que un atacante dirigido prueba.
• Minúsculas, sin caracteres especiales. Las URLs son técnicamente sensibles a mayúsculas y minúsculas, pero los usuarios reales se equivocan con las mayúsculas todo el tiempo. Un slug en minúsculas evita toda esa clase de tickets de "no puedo iniciar sesión".

Escollos habituales y casos límite

Hay un puñado de cosas que se rompen o se comportan de forma inesperada al mover la URL de acceso. Conviene conocerlas de antemano.

• Página "Mi cuenta" de WooCommerce. El acceso de cliente en /my-account/ es un flujo separado y no se ve afectado por el cambio. Solo ocultas el acceso de administración. Los clientes de WooCommerce siguen accediendo con normalidad.
• Plugins de autenticación de doble factor. La mayoría de los plugins de 2FA importantes (Wordfence, WP 2FA, miniOrange, etc.) funcionan bien con WPS Hide Login. Se enganchan al proceso de login en una capa por debajo de la URL y no les importa dónde viva el formulario. Pruébalo una vez tras la activación.
• REST API y XML RPC. El cambio de la URL de acceso no afecta a /wp-json/ ni a /xmlrpc.php. Si tienes aplicaciones que se autentican contra esos endpoints, siguen funcionando como antes. Si no usas activamente XML RPC, este es un buen momento para deshabilitarlo por completo (guía aparte en nuestra base de conocimiento).
• Plugins de caché. Algunas cachés de página agresivas (LiteSpeed Cache con edge caching, Cloudflare APO) pueden cachear la nueva URL de acceso o, peor, cachear una respuesta de administrador con sesión iniciada y servirla a visitantes sin sesión. Tras el cambio, visita la nueva URL en una ventana privada. Si ves la vista de administrador con sesión iniciada, la caché está rota; vacíala y añade el slug a la lista de exclusión de caché.
• Correos de restablecimiento de contraseña. Tanto WPS Hide Login como el snippet de código anterior reescriben automáticamente la URL de restablecimiento de contraseña, pero los plugins de correo personalizados o las integraciones de correo transaccional a veces tienen wp-login.php hardcodeado en sus plantillas. Envíate un restablecimiento de contraseña de prueba después del cambio.
• Instalaciones en subdirectorio y multisite. Ambas funcionan, pero ojo con que el slug se añada a la URL base equivocada. Si WordPress está en /blog/, la nueva URL es https://tudominio.com/blog/mi-acceso-secreto, no https://tudominio.com/mi-acceso-secreto.

Recuperación: qué hacer si te quedas fuera

Pasa. Configuras el slug, cierras sesión, cierras la pestaña, y una semana después no recuerdas si usaste guiones, guiones bajos o cuál era la tercera palabra. No estás atascado, pero la vía de recuperación depende del método que hayas usado.

Si usaste WPS Hide Login: desactiva el plugin vía SFTP. Renombra la carpeta wp-content/plugins/wps-hide-login a wps-hide-login.disabled, o elimínala por completo. La URL por defecto /wp-login.php vuelve inmediatamente. Inicia sesión, busca tu slug en los ajustes del plugin y vuelve a activarlo. Como alternativa, mira directamente en la base de datos de WordPress: el slug se guarda en la tabla wp_options bajo la clave whl_page.

Si usaste el código personalizado: entra por SFTP en wp-content/mu-plugins/, abre el archivo y lee el slug de la constante CUSTOM_LOGIN_SLUG. O renombra temporalmente el archivo para deshabilitarlo, inicia sesión y vuelve a dejarlo como estaba.

En ambos casos, anota la URL en algún sitio persistente en el momento mismo de configurarla. Gestor de contraseñas, documentación del proyecto, cualquier cosa que sobreviva a la pérdida de un marcador del navegador.

Cómo verificar que el cambio está activo

1. Abre https://tudominio.com/wp-login.php en una ventana privada del navegador. Resultado esperado: una página 404.
2. Misma comprobación para https://tudominio.com/wp-admin/. También debería redirigir al 404, no al formulario de acceso.
3. Abre la nueva URL https://tudominio.com/mi-acceso-secreto. Debería mostrar el formulario de acceso estándar de WordPress.
4. Inicia sesión con normalidad, cierra sesión y haz clic en el enlace "Cerrar sesión". La redirección debería aterrizar en la nueva URL, no en /wp-login.php.
5. Lanza un restablecimiento de contraseña para ti mismo. El enlace del correo debería apuntar a la nueva URL.
6. Lanza un nuevo análisis de InspectWP. Las comprobaciones relacionadas con la URL de acceso deberían reflejar el nuevo estado.

Una vez verificado, el único mantenimiento continuo es asegurarse de que el plugin (o tu código personalizado) sigue funcionando con las actualizaciones del núcleo de WordPress, cosa que debería ocurrir. Si alguna vez una actualización mayor cambia internamente cómo funciona el flujo de acceso, WPS Hide Login es uno de los primeros plugins en sacar un parche, normalmente en cuestión de días.

Todo el cambio son media hora de trabajo a cambio de una reducción permanente de la superficie de ataque y una caída notable de la carga del servidor. No hay ninguna buena razón para dejar el acceso de WordPress en su ubicación por defecto en cualquier sitio en producción.