Si solo podés hacer tres cosas para asegurar WordPress, hacé estas: activá 2FA en cada cuenta admin, habilitá actualizaciones automáticas para versiones menores de core y plugins, y configurá backups en una ubicación fuera de tu hosting. Según un análisis publicado en abril de 2026 por alguien con 25 años manteniendo sitios WordPress, esos tres controles detienen aproximadamente el 85% de los ataques reales. El resto del checklist de seguridad WordPress que circula por internet es, en su mayoría, relleno para posicionar en Google.
En 30 segundos
- 2FA para cada cuenta con rol admin es el control más efectivo: detiene ataques de credential stuffing que comprometen miles de sitios por semana.
- Las actualizaciones automáticas de core (versiones menores) y plugins son la segunda prioridad, porque el 96% de las vulnerabilidades conocidas están en plugins desactualizados.
- Los backups externos (fuera del mismo servidor) son el seguro cuando todo lo demás falla.
- Cambiar el prefijo wp_, renombrar el usuario admin, ocultar la versión de WordPress, bloquear tráfico por país: ninguna de esas medidas detiene ataques en 2026.
- Un plugin de seguridad solo no alcanza. Los plugins ayudan, pero no reemplazan los tres controles básicos.
Los 3 controles que realmente protegen WordPress
Un checklist de seguridad WordPress es uno de esos recursos que google todo el mundo y confía poca gente con criterio. Y con razón: la mayoría de las listas mezclan controles reales con medidas que suenan técnicas pero no cambian nada. El problema es que si ponés en el mismo nivel «activar 2FA» y «cambiar el prefijo de las tablas», la gente invierte tiempo en la segunda porque parece más técnica, más profunda, y la primera ya la pospuso para después.
No funciona así. Los ataques reales en 2026 apuntan a credenciales comprometidas, plugins sin actualizar y backups inexistentes (o peor: backups en el mismo servidor que el sitio). El resto son vectores de ataque de hace diez años, o exploits que necesitan acceso previo para funcionar.
WordPress es el CMS que corre aproximadamente el 43% de todos los sitios web del mundo. Eso lo convierte en el blanco más atacado, pero también en el más documentado. Sabemos bien qué funciona y qué no. Lo que sigue es la versión sin relleno.
2FA: la primera línea contra credential stuffing
Los ataques de credential stuffing son simples: alguien tiene una base de datos de emails y contraseñas filtrados de otros servicios, y los prueba automáticamente en tu wp-login.php. Si tu contraseña de WordPress es la misma que usabas en un foro hackeado en 2019, ya perdiste. Y no importa cuán compleja sea la contraseña nueva si reutilizás combinaciones.
2FA corta ese vector completamente. Aunque el atacante tenga tu usuario y contraseña correctos, necesita el segundo factor que solo vos tenés en el momento. Sin acceso al dispositivo físico, no entra.
La implementación correcta es con una app TOTP (Autenticator de Google, Authy, o similar) que genera un código de 6 dígitos que expira cada 30 segundos. SMS no sirve como segundo factor serio: los ataques de SIM swapping permiten interceptar esos mensajes y ya hay casos documentados en Argentina. Si tu proveedor de hosting te ofrece 2FA vía SMS, usalo como primer paso, pero migrá a TOTP cuando puedas. Te puede servir nuestra cobertura de desarrollar plugins de forma segura.
Para configurarlo en WordPress, la documentación oficial de WordPress.org cubre el proceso completo con el plugin nativo. La clave es activarlo para todos los roles admin, no solo para el tuyo. Un colaborador con acceso editor comprometido puede hacer bastante daño.
Actualizaciones automáticas: core, plugins y temas
El 96% de las vulnerabilidades reportadas en WordPress están en plugins. No en el core, no en los temas: en plugins. Y una parte considerable de los sitios hackeados corren versiones con parches disponibles que nunca se aplicaron.
¿Por qué no se actualizan? Dos razones: miedo a que algo se rompa, y el modelo de «actualizo cuando me acuerdo». Ninguna de las dos resiste comparación con el riesgo de correr un plugin con una vulnerabilidad pública conocida.
La solución son las actualizaciones automáticas, pero con matices. Para el core de WordPress, activá las automáticas para versiones menores (las que terminan en el tercer número: de 6.5.3 a 6.5.4). Esas son principalmente parches de seguridad y correcciones de bugs. Las versiones mayores (de 6.5 a 6.6) sí merecen revisión manual porque pueden traer cambios de comportamiento. Para plugins, activá las automáticas para los que usás en producción real y que no sean de desarrollo activo con cambios frecuentes. Si tenés un plugin abandonado hace dos años con una versión antigua, ese es el problema más urgente que tenés, más que cualquier configuración de seguridad.
Backups externos: el seguro cuando todo falla
Ponele que pasan todas las medidas anteriores y un atacante igual encuentra un vector. O que hay un error humano, un plugin que rompe la base de datos, o un problema en el servidor. Si tu único backup está en el mismo servidor que el sitio, no tenés backup: tenés una copia que va a desaparecer junto con el problema.
Un backup real tiene dos componentes: archivos del sitio (todo el directorio de WordPress) y la base de datos MySQL/MariaDB, en una ubicación completamente separada de tu hosting. Puede ser Google Drive, S3, o cualquier servicio de almacenamiento externo. La frecuencia mínima recomendada para un sitio activo es diaria para la base de datos y semanal para los archivos, aunque eso depende de cada operación.
La parte que no mucha gente prueba: restaurar el backup. Un backup que nunca se probó es un backup que tal vez no funcione cuando lo necesitás. Hacé una restauración de prueba en un entorno de staging al menos una vez cada dos meses. Cubrimos ese tema en detalle en proteger tus formularios WordPress.
Medidas que parecen seguridad pero no cambian nada
Acá viene la parte que le va a molestar a gente que invirtió tiempo en algunas de estas cosas (me incluyo).
Cambiar el prefijo wp_ de las tablas
Esta medida aparece en casi todos los checklists. La idea es que si atacante no sabe cómo se llaman tus tablas, no puede hacer inyección SQL. El problema: los ataques de SQL injection exitosos no adivinen el prefijo, lo descubren. Si hay una vulnerabilidad que permite inyección, también permite enumerar las tablas existentes. Y el proceso de cambiar el prefijo en un sitio en producción es manual, tiene varios pasos, y si algo sale mal podés dejar el sitio inaccesible. El riesgo operacional es real; el beneficio de seguridad, marginal.
Renombrar el usuario «admin»
En 2011, los bots de fuerza bruta probaban «admin» como usuario porque era el default. WordPress cambió eso en 2012, el installer ya no crea el usuario «admin» automáticamente. Si todavía tenés un usuario que se llama «admin» en 2026, sí, tiene sentido cambiarlo (aunque la contraseña fuerte + 2FA ya lo mitigan). Pero si esperás que cambiar el username sea tu defensa contra ataques de fuerza bruta, vas a seguir siendo vulnerable porque los bots modernos también prueban el email de admin, que generalmente es público.
Ocultar la versión de WordPress
La «seguridad por oscuridad» no es seguridad. Ocultar el número de versión de WordPress no impide que un atacante use un exploit si existe: lo prueba de todas formas. Y la versión se puede inferir por otros medios (estructura de archivos estáticos, respuestas de API). Lo que sí importa es que la versión esté actualizada, no que esté oculta.
Bloquear tráfico por país
Bloquear China, Rusia, o cualquier otro país suena a control activo. En la práctica, la mayoría de los ataques automatizados usan redes de proxies y servidores comprometidos distribuidos globalmente. El tráfico malicioso no viene «de China», viene de un servidor en Alemania que forma parte de una botnet. El bloqueo geográfico solo agrega fricción a usuarios legítimos de esas regiones, no detiene ataques reales.
Renombrar wp-login.php
Los bots escanean miles de sitios por segundo. Descubrir la nueva URL de login es trivial si tienen acceso al sitio (sitemap, source HTML, error 404 revelador). El esfuerzo de mantenimiento de plugins que hacen esto (que se rompen con actualizaciones, conflictos con otros plugins) no justifica la mínima fricción que agrega. Complementá con automatizar tareas sin comprometer seguridad.
Capas adicionales con ROI real
Los tres controles primarios (2FA, actualizaciones, backups) cubren el 85% del riesgo. Lo que sigue suma, pero con rendimientos decrecientes.
WAF (Web Application Firewall)
Un WAF bien configurado intercepta tráfico malicioso antes de que llegue a WordPress: ataques XSS, SQL injection, scanning de rutas conocidas. La diferencia entre un WAF real y un plugin de seguridad que dice tener firewall es que el primero opera a nivel de infraestructura (antes de que PHP procese el request) y el segundo opera dentro de WordPress (el request ya llegó). Wordfence y Sucuri tienen versiones de plugin que funcionan razonablemente bien para sitios medianos, pero no son equivalentes a un WAF de infraestructura. Si tu hosting en donweb.com incluye protección a nivel de servidor, activala.
Límite de intentos de login
Si tenés 2FA, esto es secundario. Si no tenés 2FA, es urgente. Limitar a 5-10 intentos fallidos antes de bloquear temporalmente la IP reduce la efectividad de ataques de fuerza bruta automatizados. Es una medida simple que tiene sentido implementar, pero no reemplaza la autenticación de dos factores.
HTTPS obligatorio
En 2026, tener un sitio sin HTTPS activo es un problema de SEO antes que de seguridad (Google penaliza el HTTP plano en rankings). Desde el lado de la seguridad, HTTPS protege las credenciales en tránsito. Los certificados SSL son gratis con Let’s Encrypt y la mayoría de los hostings los incluyen. No hay excusa para no tenerlo. Verificá también que WordPress redirija HTTP a HTTPS correctamente y que no haya contenido mixto (assets cargados por HTTP en una página HTTPS).
Security theater vs. inversión real de tiempo
Esto es lo que importa para decidir dónde poner el tiempo:
| Control | Tiempo de implementación | Impacto real | Vale la pena |
|---|---|---|---|
| 2FA para admins | 5-10 minutos | Alto (detiene credential stuffing) | Sí, prioritario |
| Actualizaciones automáticas | 5 minutos | Alto (96% de vulns en plugins) | Sí, prioritario |
| Backups externos automatizados | 30-60 minutos (setup) | Alto (recuperación ante cualquier incidente) | Sí, prioritario |
| Límite de intentos de login | 5 minutos (plugin) | Medio (reduce fuerza bruta) | Sí, como capa adicional |
| WAF de infraestructura | Variable (depende del hosting) | Medio-alto (filtra tráfico malicioso) | Sí, si está disponible |
| Cambiar prefijo wp_ | 30-60 minutos + riesgo operacional | Muy bajo | No |
| Renombrar usuario admin | 5 minutos | Muy bajo (con 2FA activo) | No vale el esfuerzo |
| Ocultar versión de WordPress | Variable (plugin) | Casi nulo | No |
| Bloqueo geográfico | Variable | Muy bajo (bots usan proxies globales) | No |
| Renombrar wp-login.php | Variable + mantenimiento continuo | Bajo (bots escanean rutas) | No |
Con 40 minutos de trabajo podés tener el 85% de protección. Las medidas de «teatro» te pueden consumir horas y no mover esa aguja.
Qué está confirmado y qué no
Confirmado
- 2FA con app TOTP detiene ataques de credential stuffing (el mecanismo de ataque no puede completarse sin el segundo factor físico).
- El 96% de las vulnerabilidades reportadas en WordPress están en plugins, no en el core.
- Las versiones menores de WordPress Core son exclusivamente parches de seguridad y correcciones.
- Los backups en el mismo servidor desaparecen cuando el servidor es comprometido o tiene un fallo catastrófico.
- Los ataques de SQL injection exitosos pueden enumerar tablas de la base de datos, haciendo irrelevante el cambio de prefijo wp_.
No confirmado o con matices
- El dato «85% de ataques detenidos con tres controles» viene del análisis del artículo fuente: es una estimación de experiencia práctica, no un estudio controlado.
- Los plugins de seguridad con «firewall incluido» varían mucho en efectividad real; los benchmarks los publica el propio fabricante.
- Algunas medidas de «teatro» (como limitar intentos de login) pueden seguir siendo útiles contra bots menos sofisticados, aunque no detienen ataques dirigidos.
Errores comunes al configurar seguridad WordPress
Error 1: Activar 2FA solo para tu cuenta. Si otro admin de tu sitio no tiene 2FA, su cuenta es el punto de entrada. Los atacantes van al eslabón más débil. 2FA tiene que ser obligatorio para todos los roles con capacidad de administración.
Error 2: Confundir «plugin de seguridad activo» con «sitio seguro». Wordfence, Sucuri, o cualquier otro plugin de seguridad son capas adicionales, no reemplazos para las tres medidas base. Un sitio con Wordfence instalado pero sin 2FA y con plugins desactualizados sigue siendo vulnerable. El plugin te avisa del problema, no lo resuelve. En implementar feature plugins correctamente profundizamos sobre esto.
Error 3: No verificar los backups. Configurás el backup, ves que «se ejecutó correctamente» en el log, y nunca lo probás. El problema es que los backups pueden corromperse, fallar silenciosamente en la transferencia al destino externo, o estar incompletos. La restauración en staging tiene que ser parte de la rutina, no algo que hacés solo cuando necesitás recuperar el sitio.
Error 4: Tratar las actualizaciones automáticas como todo o nada. O las desactivás por miedo a que algo se rompa, o las activás para todo incluyendo versiones mayores de plugins complejos (WooCommerce con WooCommerce 9.0 → 9.1 puede traer cambios de comportamiento). El punto medio es activar automáticas para versiones de parche (x.y.Z) y revisar manualmente las versiones menores (x.Y.z) de plugins críticos.
Si querés profundizar, acá dejamos nuestro WordPress Security Checklist: 15 Checks That Matter (and 12 .
Preguntas Frecuentes
¿Realmente necesito cambiar el prefijo wp_ de mi base de datos?
No, en la práctica no cambia nada relevante. Los ataques de SQL injection que pueden explotar el prefijo también pueden descubrirlo si tienen acceso para ejecutar consultas. El proceso de cambio en un sitio en producción implica riesgo operacional real (errores manuales pueden dejar el sitio inaccesible) a cambio de un beneficio marginal. El tiempo invertido en esto rinde mucho más configurando 2FA o revisando plugins desactualizados.
¿Funciona renombrar el usuario admin para evitar ataques?
Para ataques de fuerza bruta muy básicos de 2010-2012, tal vez. En 2026, los bots modernos también prueban el email del administrador (que suele ser público en el perfil de autor), así que cambiar el username no elimina el vector. Con 2FA activo, el nombre de usuario pierde relevancia porque aunque el atacante lo sepa, no puede completar el login sin el segundo factor.
¿Puedo confiar solo en un plugin de seguridad para proteger WordPress?
No. Los plugins de seguridad son capas adicionales útiles, no una solución completa. Wordfence puede alertarte sobre una vulnerabilidad en un plugin, pero si ese plugin ya fue explotado antes de que lo actualizaras, el daño ya está hecho. El orden correcto es: primero los tres controles base (2FA, actualizaciones, backups), después los plugins de seguridad como complemento.
¿Qué tan seguido tengo que hacer backups de WordPress?
Para un sitio activo (con contenido nuevo frecuente), la base de datos debería respaldarse diariamente porque ahí está todo el contenido. Los archivos del sistema cambian menos y una copia semanal suele alcanzar. Lo crítico es que el destino sea externo al servidor: Google Drive, S3 u otro servicio de almacenamiento separado de tu hosting. Y probá la restauración al menos una vez cada dos meses.
¿Qué medidas de seguridad WordPress son las más urgentes si parto de cero?
En orden: primero 2FA para todas las cuentas admin (10 minutos, impacto inmediato). Segundo, revisá todos los plugins instalados y actualizá los que tengan versiones disponibles, después activá las actualizaciones automáticas para parches (5 minutos). Tercero, configurá backups externos automatizados con frecuencia diaria para la base de datos (30-60 minutos de setup). Con eso cubrís la mayor parte del riesgo real antes de tocar cualquier otra configuración.
Conclusión
El problema con los checklists de seguridad WordPress es el mismo problema de mucho contenido técnico: están escritos para parecer exhaustivos, no para ser útiles. Cuando una lista mezcla «activar 2FA» con «cambiar el prefijo wp_» como si fueran controles equivalentes, el efecto real es que la gente invierte tiempo en la medida que suena más técnica y pospone la que realmente importa.
El análisis publicado en abril de 2026 que citamos al principio es correcto en su diagnóstico: 2FA, actualizaciones automáticas y backups externos son los tres controles que detienen la mayoría de los ataques reales. No son glamorosos. No implican tocar la base de datos ni instalar plugins de nombres sugestivos. Pero funcionan porque atacan los vectores que los atacantes realmente usan: credenciales comprometidas, plugins vulnerables y ausencia de recuperación.
Si ya tenés los tres en marcha, las capas adicionales (WAF, límite de intentos de login, HTTPS forzado) tienen sentido. Si no los tenés, ninguna de las medidas de la lista larga te protege. Empezá por ahí.
Fuentes
- Nova Pulse – WordPress Security Checklist: 15 checks que realmente importan (abril 2026)
- WordPress.org en español – Cómo configurar autenticación en dos pasos (2FA)
- Donweb Guías – Configurar 2FA en WordPress
- LimpiaTuWeb – Vulnerabilidades de WordPress
- Modulards – 10 vulnerabilidades WordPress más comunes