Endurecer WordPress es cambiar la configuración para que las puertas de siempre queden cerradas. Esta guía es el cómo de la puesta en marcha. Los hábitos y la rutina mensual están en buenas prácticas (en inglés). La lista para tachar está en la checklist de seguridad.
Qué estás endureciendo
Piensa en capas:
- Núcleo y configuración (
wp-config.php, actualizaciones, bloqueo de edición de archivos)
- Plugins y temas (menos, actualizados, de confianza)
- Personas y accesos (contraseñas, 2FA, roles, límite de intentos fallidos)
- Hosting y borde (HTTPS, un hosting decente, firewall)
- Detección y recuperación (escáneres, eventos, copias que puedes restaurar)
La mayoría de los compromisos siguen empezando por plugins desactualizados o por un acceso de administrador débil. Empieza ahí aunque no toques nunca la configuración de Apache.
1. Mantener el software al día
- Actualiza el núcleo de WordPress pronto, sobre todo las versiones de seguridad
- Actualiza plugins y temas con un horario
- Borra plugins y temas sin uso. Desactivado no es borrado
- Mantén PHP en una versión soportada que tu hosting recomiende
Usa staging en sitios frágiles. Activa la actualización automática de los plugins en los que confías, cuando puedas. Después de actualizaciones grandes, vuelve a lanzar las pruebas de seguridad y un escaneo de vulnerabilidades.
2. Endurecer wp-config.php
Genera salts y claves de WordPress nuevas después de un compromiso, o cuando heredas un sitio.
En producción:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
Impide editar archivos de temas y plugins desde wp-admin. Merece la pena en casi cualquier sitio en vivo:
define( 'DISALLOW_FILE_EDIT', true );
Usa DISALLOW_FILE_MODS solo si gestionas las actualizaciones a propósito fuera de wp-admin. Bloquea instalar y actualizar plugins y temas desde el panel.
Un prefijo de tablas propio ayuda un poco contra scripts automáticos tontos. No sustituye actualizaciones ni accesos fuertes. Cambiar el prefijo en un sitio en vivo hay que hacerlo con cuidado. En instalaciones nuevas, hazlo cuando puedas.
3. Permisos de archivos y protección de wp-config
Los valores exactos dependen del hosting, pero una base habitual es:
- Directorios:
755
- Archivos:
644
wp-config.php: más apretado cuando se puede (600 o 640)
Evita 777. Si el sitio se rompe al apretar permisos, pregunta al hosting qué espera su stack de WordPress, en lugar de abrir todo.
En Apache también puedes negar el acceso web a wp-config.php en .htaccess. Cambia una regla cada vez, prueba la portada y /wp-admin/, y guarda una copia del archivo. Fragmentos y notas para volver atrás: seguridad de .htaccess (en inglés). El generador está en herramientas .htaccess.
El escáner del núcleo ayuda a ver cambios inesperados en los archivos de WordPress después de endurecer.
4. Contraseñas fuertes, pocos accesos, 2FA

- Contraseñas largas y únicas en un gestor (ni palabras de diccionario, ni reutilizadas entre sitios)
- Nada de una cuenta compartida de “admin del equipo”
- Pocos administradores. El resto, el rol más bajo que funcione
- Autenticación en dos pasos para administradores
- Limita los intentos fallidos y valora renombrar la URL de acceso con la protección de acceso
Renombrar no basta. Va con límite de tasa y con 2FA. Más profundidad: cómo proteger el acceso a WordPress.
5. Plugins, temas y software sin uso
- Prefiere WordPress.org o vendedores comerciales conocidos
- Mira la fecha de la última actualización antes de instalar
- Nunca uses paquetes “premium” nulled
- Quita plugins abandonados que no puedas sustituir pronto
- Borra también los temas sin uso. Los temas por defecto que no necesitas cuentan
Escanea el software instalado en busca de problemas conocidos con el escáner de vulnerabilidades, incluido en Free. Higiene de plugins, más larga: riesgos de seguridad de los plugins (en inglés).
6. HTTPS, hosting y protección en el borde
- Fuerza HTTPS en todo el sitio. La mayoría de hostings incluyen un certificado gratis. Activa la redirección
- Elige un hosting con copias que funcionen, soporte y fama de mantener el stack parcheado
- Pon un plugin de firewall para WordPress o el firewall en la nube delante de WordPress para cortar ruido de exploits y de fuerza bruta (Pro: más de 600 millones de IP malas, reglas por país y personalizadas)
- Mantén el stack de servidor y PHP actualizado. En planes gestionados esto suele ser del hosting
Los detalles de servidor (cifrados TLS a medida, cirugía de privilegios de la base de datos, cirugía de módulos de Apache) ayudan cuando controlas el VPS. En hosting compartido o WordPress gestionado, gasta el tiempo primero en actualizaciones, accesos, firewall y copias.
Cabeceras de seguridad (están bien, no son magia)
Si el hosting o un plugin de seguridad puede poner cabeceras, las útiles incluyen:
Strict-Transport-Security (HSTS), cuando HTTPS ya está sólido
X-Content-Type-Options: nosniff
Referrer-Policy con un valor sensato
Content-Security-Policy solo si puedes mantenerla (es fácil romper el sitio)
Las cabeceras ayudan a que el navegador se porte mejor. No sustituyen parchear plugins.
Hábitos de base de datos que merecen la pena
- Contraseña de base de datos fuerte y única (el panel del hosting suele ponerla)
- No compartas el usuario de la base de datos entre aplicaciones que no tienen que ver
- Evita privilegios exóticos que el sitio no necesita
- Después de un compromiso, asume que la base de datos puede tener usuarios basura, opciones o contenido inyectado. Restaura o limpia con cuidado
7. XML-RPC: cautela, no un interruptor por defecto
XML-RPC ayuda a algunas apps móviles, a flujos ligados a Jetpack y a herramientas remotas. También es una vía habitual de fuerza bruta y de abuso de pingback.
- Si nada de lo que usas lo necesita, bloquearlo o desactivarlo es razonable
- Si algo se rompe después de bloquearlo, deshaz el cambio
- Prefiere límites en el firewall y autenticación fuerte antes que desactivar funciones que todavía usas
En Apache, añade reglas de una en una y prueba. Detalle y patrones más seguros: guía de .htaccess (en inglés).
8. Detectar problemas pronto
Endurecer sin vigilancia sigue fallando en silencio.
- Lanza escaneos de malware con horario (Pro)
- Mira el registro de eventos por accesos raros, bloqueos y cambios
- Activa alertas (correo o webhooks) para lo que importa
- Revisa Search Console si el tráfico o los avisos se ven mal
- Vuelve a lanzar las pruebas de seguridad después de cambios grandes, para que las regresiones no se queden sin ver
Los análisis programados importan porque la mayoría de quien tiene un sitio no abre el panel cada día. Pon el horario y luego mira los fallos.
9. Copias que puedes restaurar
El endurecimiento reduce el riesgo. Las copias limitan el daño.
- Copias automáticas de archivos y de base de datos
- Copias fuera del sitio cuando se pueda
- Retención suficiente para volver a antes de que empezara una infección
- Una prueba de restauración, para conocer el proceso
Detalle: plan de copias después de un ataque (en inglés).
Guarda las credenciales de la copia fuera del sitio. Si el malware puede leer tu wp-admin, no quieres que el único camino de restauración viva en el mismo compromiso.
10. Un plugin de seguridad que encaje con el trabajo
Un buen plugin de seguridad tiene que ayudar a aplicar y a comprobar el endurecimiento, no a sustituir actualizaciones y accesos fuertes.
Un plugin como Security Ninja cubre pruebas de seguridad, vulnerabilidades e integridad del núcleo en Free. Pro añade Cloud Firewall (más de 600 millones), escáner de malware, análisis programados, protección de acceso y 2FA. El asistente de instalación enciende valores por defecto sensatos para no adivinar qué interruptores importan primero. Evita apilar tres plugins de seguridad que se solapan. Se pelean. Mira conflictos entre plugins de seguridad (en inglés) y los mejores plugins de seguridad WordPress (en inglés) si todavía estás eligiendo.
Un orden de despliegue que se puede seguir
Día 1
- Copias confirmadas
- Actualizar todo y borrar plugins y temas sin uso
- Arreglar cuentas de administrador, contraseñas y 2FA
- Activar protección de acceso y firewall si tienes Pro
Esta semana
DISALLOW_FILE_EDIT y debug apagado en producción
- Revisar permisos y proteger el acceso a
wp-config si Apache lo permite
- Escaneo de vulnerabilidades y de malware, y arreglar lo que salga
- Pruebas de seguridad y la checklist de endurecimiento en Security Ninja
- Decidir XML-RPC solo cuando sepas qué lo usa
En adelante
- Revisión mensual de actualizaciones y de administradores (los hábitos están en buenas prácticas (en inglés))
- Análisis programados y comprobación de que las copias salen bien
Preguntas habituales
¿Hace falta renombrar la carpeta wp-content?
Normalmente no. Rompe cosas, y los bots ya sondean un montón de otras rutas. Céntrate en actualizaciones, accesos y escaneo.
¿Debo desactivar XML-RPC?
Solo si nada de lo que usas lo necesita. Desactivarlo a ciegas puede romper integraciones. Si todavía necesitas la función, prefiere límites en el firewall y autenticación fuerte.
¿Basta con renombrar la URL de acceso?
No. Reduce ruido. Va con límite de intentos fallidos y con 2FA.
¿Puedo endurecer una vez y olvidarme?
No. Salen CVE de plugins constantemente. El endurecimiento es una base más un hábito de mantenimiento.
Si el sitio ya está comprometido
No “endurezcas” encima de malware activo y lo des por terminado. Si no estás seguro, mira primero si han pirateado tu sitio WordPress (en inglés). Quita el malware o restaura, y luego endurece para que no vuelvan a entrar. Guía: sitio WordPress pirateado (en inglés). ¿Necesitas ayuda? Contrata limpieza o una revisión.
Lecturas relacionadas