Proteger el directorio /wp-admin/ con contraseña es una de las primeras medidas de seguridad que se recomiendan en WordPress, pero tiene un efecto colateral que mucha gente no espera: bloquea el acceso a admin-ajax.php y admin-post.php, dos archivos dentro de /wp-admin/ que WordPress usa para peticiones AJAX y que cualquier plugin puede estar llamando desde el frontend. El resultado es un sitio con el panel protegido pero con formularios que no funcionan, carritos de compra rotos o menús que no responden. En Colorvivo te explicamos el problema y cómo solucionarlo.
Por qué proteger wp-admin puede romper tu sitio
Cuando proteges /wp-admin/ con BasicAuth (autenticación HTTP estándar mediante .htpasswd), el servidor pide usuario y contraseña antes de servir cualquier archivo de esa carpeta. El problema es que admin-ajax.php y admin-post.php viven exactamente ahí y los llama continuamente el propio WordPress y sus plugins, también desde páginas públicas. Un visitante sin autenticación en el servidor HTTP nunca podrá completar esas peticiones, aunque tenga acceso normal al frontend de la web.
Esto afecta sobre todo a: plugins de reservas o citas, formularios de contacto (Contact Form 7, Gravity Forms), WooCommerce (el carrito hace peticiones AJAX continuas), plugins de carga dinámica de contenido y cualquier elemento interactivo que use jQuery AJAX en el front.
La solución: excluir admin-ajax.php y admin-post.php de la protección
La protección avanzada de wp-admin más habitual consiste en añadir excepciones en el .htaccess del directorio /wp-admin/ para que los archivos AJAX sean accesibles públicamente aunque el resto del directorio esté restringido. El fragmento a añadir en /wp-admin/.htaccess es el siguiente:
AuthType Basic
AuthName "Sección protegida"
AuthUserFile /ruta/a/tu/.htpasswd
Require valid-user
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
<Files admin-post.php>
Order allow,deny
Allow from all
Satisfy any
</Files>
<Files ".(css|gif|png|jpg|jpeg|webp|avif|js)$">
Order allow,deny
Allow from all
Satisfy any
</Files>Este código protege el acceso al panel de administración y deja accesibles admin-ajax.php, admin-post.php y los archivos estáticos (imágenes, CSS, JS) para cualquier usuario. Sustituye /ruta/a/tu/.htpasswd por la ruta absoluta real al fichero .htpasswd en tu servidor.
Alternativas y medidas complementarias
- Restricción por IP: si siempre administras el sitio desde la misma IP o rango de IPs, puedes restringir el acceso a wp-admin y wp-login.php directamente en .htaccess. Es la medida más sólida cuando es viable.
- Plugins de seguridad: herramientas como Wordfence, iThemes Security o All In One WP Security permiten configurar el acceso según IP, rol de usuario o intentos de login fallidos.
- Funciones en functions.php: con código personalizado puedes restringir el acceso al panel según el rol de usuario, sin tocar la configuración del servidor.
- WAF y mod_security: un servidor con cortafuegos a nivel de aplicación (WAF) o mod_security protege el panel de accesos automatizados sin interferir con el AJAX del frontend.
Para tener la seguridad cubierta desde el inicio del proyecto, conviene revisar los 9 requisitos para una web profesional, donde el servidor y el panel de administración tienen su propio apartado. Y si quieres entender cómo WordPress gestiona sus archivos internos y peticiones, el artículo sobre WordPress como plataforma de experiencia digital ofrece un buen contexto técnico.
¿Por qué falla el carrito de WooCommerce después de proteger wp-admin?
WooCommerce usa peticiones AJAX a admin-ajax.php para actualizar el carrito, calcular el envío y procesar pedidos. Si ese archivo queda bloqueado por la protección de wp-admin, esas peticiones fallan y el carrito deja de funcionar. La solución es añadir la excepción descrita arriba.
¿Hay que proteger también wp-login.php por separado?
Sí, y es muy recomendable. Los ataques de fuerza bruta atacan directamente ese archivo. Puedes protegerlo con BasicAuth por separado o limitando el número de intentos de login fallidos con un plugin como Wordfence o Loginizer.
¿Cómo creo el archivo .htpasswd?
Con la herramienta de línea de comandos htpasswd (disponible en la mayoría de servidores Linux) o con generadores online. El archivo debe almacenarse fuera de la raíz pública del servidor para que no sea accesible desde el navegador.
¿Funciona esta solución en todos los hostings?
En servidores Apache, sí. En servidores con Nginx la configuración es diferente: en lugar de .htaccess se usa el bloque del virtualhost. Consulta con tu proveedor si tienes dudas sobre qué tipo de servidor usa tu alojamiento.
