Seguridad en WordPress: actualizaciones, usuarios, copias, bloquear IPs y escanear la web
La seguridad de un WordPress se sostiene sobre tres hábitos: tener al día el núcleo, los plugins y los temas, dar a cada usuario solo el acceso que necesita con una contraseña larga y un segundo factor, y hacer copias de seguridad que sepas restaurar. Bloquear IPs, poner un cortafuegos o pasar un escáner suma, pero no sustituye nada de lo anterior. Ningún sistema es infalible, y lo que sí puedes hacer es ponerle las cosas difíciles a quien intente entrar.
Actualizaciones: lo primero y lo que más protege
La documentación oficial de WordPress lo dice sin rodeos: las versiones antiguas no reciben parches de seguridad. WordPress trae actualizaciones automáticas desde la versión 3.7, y desde la 5.5 puedes activar también las actualizaciones automáticas plugin a plugin y tema a tema. En la pantalla de Plugins hay una columna de actualizaciones automáticas con el enlace «Activar las actualizaciones automáticas», y también se puede hacer en bloque con las acciones de la lista. En los temas, pinchas en la miniatura dentro de Apariencia y el enlace sale debajo del autor.
WordPress lanza esas actualizaciones dos veces al día y te manda un correo cuando un plugin o un tema se actualiza o falla. Dependen del cron de WordPress, así que si no ves que se apliquen, mira Herramientas > Salud del sitio, que avisa de los fallos de las tareas programadas y de otros problemas de seguridad. Yo las activaría en casi todo y dejaría para hacer a mano, con copia previa, los plugins grandes de los que depende la web, como la tienda o el maquetador.
Dos detalles más que pide la propia guía de endurecimiento. Descarga WordPress solo de wordpress.org y los plugins y temas de su directorio o de empresas conocidas, nunca versiones «gratis» de plugins de pago. Y borra los plugins y temas que no uses, porque desactivados siguen en el servidor. Pregunta también en tu hosting qué versión de PHP tienes: WordPress recomienda PHP 8.3 o superior y avisa de que las versiones antiguas ya no reciben soporte.
Usuarios, contraseñas y segundo factor
Cada persona debe tener su propio usuario y el rol mínimo para su trabajo. El administrador tiene acceso a todo el sitio, el editor publica y gestiona entradas de cualquiera, y el autor solo las suyas. Quien solo escribe no necesita ser administrador, y si un día le roban la contraseña, el daño se queda en sus entradas. Evita nombres de usuario como admin o webmaster, que son los primeros que prueban los ataques.
La contraseña, larga y única para esta web. WordPress muestra un medidor de fortaleza al cambiarla, y si te cuesta recordarlas, en cómo crear una contraseña segura y no tener que recordarlas todas tienes la parte del gestor de contraseñas. Encima de eso, activa el segundo factor. El plugin Two Factor, publicado por WordPress.org, añade códigos de una app de autenticación (TOTP), códigos por correo y diez códigos de respaldo. Cada usuario lo configura en su perfil, y conviene generar los códigos de respaldo para no quedarte fuera si pierdes el móvil.
Otro ajuste que recomienda la documentación es desactivar el editor de archivos del escritorio, porque es lo primero que usa un atacante que consigue entrar como administrador. Se hace con una línea en wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );
Y trabaja siempre por HTTPS, también en el panel. Sin cifrar, la contraseña viaja a la vista en cualquier red que no sea de fiar.
Copias de seguridad que sirvan de verdad
Una copia de WordPress tiene dos partes, los archivos y la base de datos, y necesitas las dos para recuperar la web. Bajar la carpeta por FTP no copia la base de datos, que vive aparte en MySQL o MariaDB. La guía oficial propone una copia semanal para webs pequeñas y diaria para las que publican mucho, y guardar entre tres y cinco copias recientes en sitios distintos: una en el servidor, otra en la nube, como Dropbox o Google Drive, y otra en tu ordenador.
Tener varios días guardados tiene su porqué. Si la web se compromete un día y no lo notas hasta una semana después, la copia de anoche ya trae el problema dentro y solo te salvan las anteriores. Y una copia que nunca has probado a restaurar no es una copia, es una esperanza. De vez en cuando, haz una copia manual y comprueba que puedes recuperarla.
Hace años recomendé aquí WordPress Backup to Dropbox para mandar las copias a Dropbox. Su ficha en wordpress.org indica que se cerró el 7 de febrero de 2018 y ya no se puede descargar. Hoy esa función la cubren plugins como UpdraftPlus, que programa copias y las envía a Dropbox, Google Drive, Amazon S3, FTP o correo. Si tu hosting hace copias del servidor, pregunta cuántos días guarda y cómo se restaura antes de dar el tema por resuelto.
Bloquear una IP con .htaccess
Si una IP concreta te machaca los comentarios o el formulario de acceso, en un servidor Apache puedes cerrarle la puerta desde el .htaccess de la carpeta de la web. Con Apache 2.4 la forma correcta es esta, que es la que pone su documentación con el ejemplo, precisamente, de alguien que llena de spam un foro:
<RequireAll>
Require all granted
Require not ip 203.0.113.45
</RequireAll>
Cambia la IP del ejemplo por la que quieras bloquear. Puedes añadir más líneas Require not ip, una por IP o rango. Las antiguas directivas Order, Allow y Deny son de Apache 2.2 y la documentación desaconseja mezclarlas con las nuevas. Para que el bloqueo funcione en .htaccess, el hosting tiene que permitir ese tipo de directivas (AuthConfig), y en servidores nginx no hay .htaccess: el equivalente es la directiva deny en su configuración.
Antes de bloquear, dos comprobaciones. La primera, que no sea un buscador legítimo: Google explica cómo verificar a Googlebot con una consulta de DNS inversa (la IP debe resolver a un nombre de googlebot.com o google.com, y ese nombre devolver la misma IP). La segunda, si tu web va detrás de Cloudflare u otro proxy, en los registros del servidor verás la IP del proxy y no la del visitante, y bloquearla dejaría fuera a gente que no tiene nada que ver. Ten en cuenta también que una IP se cambia fácil. Bloquear sirve para cortar un abuso puntual, no como defensa principal.
Escanear la web desde fuera
Zerodayscan, el escáner online que reseñamos en 2010, ya no existe. Para una revisión rápida desde fuera tienes Sucuri SiteCheck, gratuito, que busca malware visible, presencia en listas negras y software desactualizado. El propio servicio advierte de que solo ve lo que vería un navegador y no detecta lo que hay escondido en el servidor, así que un resultado limpio no garantiza que la web esté sana.
Si tienes la web dada de alta en Search Console, el informe de problemas de seguridad te avisa cuando Google detecta que el sitio está pirateado o distribuye malware. El HTTP Observatory de Mozilla revisa las cabeceras de seguridad del servidor. Y si te manejas en la terminal, WPScan analiza un WordPress y cruza plugins y versiones con su base de datos de vulnerabilidades, para lo que pide registrarse y usar un token gratuito de 25 consultas al día. Úsalo solo con webs tuyas o con permiso de su dueño.
Para comprobar si una web ajena es fiable antes de comprar en ella, el enfoque es otro y lo cuento en cómo comprobar si una web es segura antes de entrar o comprar.
Revisado y actualizado en octubre de 2026.
Deja un comentario