No necesitas saber configurar un firewall, interpretar un registro del servidor ni distinguir un ataque XSS de uno de fuerza bruta.
Pero si tu empresa depende de una web WordPress, sí necesitas saber quién se ocupa de ella, qué riesgos estás dispuesto a asumir y qué medidas has decidido exigir.
Ese matiz es importante.
En muchas pymes, la seguridad de la web acaba funcionando por acumulación de supuestos:
El problema aparece cuando nadie puede convertir esas frases en respuestas concretas.
Y el contexto no invita precisamente a dejarlo para más adelante. El informe State of WordPress Security in 2026 de Patchstack señala que el 91 % de las nuevas vulnerabilidades detectadas en el ecosistema WordPress correspondieron a plugins y que las vulnerabilidades calificadas como altamente explotables aumentaron un 113 % respecto al año anterior.
Eso no significa que WordPress sea intrínsecamente inseguro.
Significa que alrededor de una instalación WordPress hay muchas piezas: plugins, temas, usuarios, hosting, contraseñas, copias, actualizaciones e integraciones. Y cada una necesita que alguien tome decisiones.
Tu trabajo como responsable de una empresa no debería ser ejecutar técnicamente esas medidas.
Debería ser asegurarte de que estas diez decisiones están tomadas y alguien responde por ellas.
Esta debería ser la primera pregunta:
¿quién tiene hoy la responsabilidad de mantener seguro vuestro WordPress?
No quién podría hacerlo.
No quién instaló la web hace cuatro años.
No quién tiene las claves.
Quién tiene actualmente el encargo.
Puede ser:
Lo problemático es responder «supongo que el hosting».
El alojamiento tiene responsabilidades sobre su infraestructura, pero eso no significa que revise tus plugins, usuarios, formularios, integraciones o contraseñas.
Lo explicamos con más detalle en Tu hosting no es tu equipo de seguridad.
La responsabilidad debería quedar repartida de forma explícita:
El hosting protege y mantiene su infraestructura.
El responsable de WordPress mantiene la aplicación.
La empresa controla quién puede acceder y qué puede hacer.
Si nadie puede decir quién ocupa el segundo puesto, ya has encontrado el primer problema.
Una contraseña como empresa2026! puede parecer mejor que 123456, pero sigue siendo una mala política.
Y reutilizar la misma contraseña del correo, WordPress, hosting y otros servicios convierte una filtración en un problema mucho mayor.
La documentación oficial de WordPress recomienda utilizar contraseñas fuertes y añade expresamente la autenticación en dos pasos como una medida adicional de seguridad. Su guía actual frente a ataques de fuerza bruta también recomienda contraseñas únicas, gestores de contraseñas y 2FA para las cuentas administradoras.
Para una empresa, la decisión puede simplificarse mucho:
No necesitas imponer a todo el equipo una política de seguridad bancaria.
Sí deberías proteger especialmente las cuentas capaces de modificar la web.
Porque quien consigue entrar como administrador puede hacer bastante más que cambiar un texto.
Puede instalar código.
Hay otra costumbre aparentemente cómoda:
Usuario: marketing
Contraseña: ********
Y cinco personas utilizando la misma cuenta.
Funciona hasta que necesitas saber quién hizo algo.
O hasta que alguien abandona la empresa.
Entonces aparecen preguntas incómodas:
Cada persona debería disponer de su propio acceso y únicamente con los permisos que necesita.
La persona que publica artículos probablemente no necesita instalar plugins.
Quien modifica fichas de producto tampoco tiene por qué poder crear nuevos administradores.
Y la empresa que únicamente introduce contenidos no necesita necesariamente acceso completo a toda la instalación.
WordPress dispone precisamente de un sistema de roles y capacidades para separar funciones.
La regla empresarial es sencilla:
menos administradores y más permisos ajustados al trabajo real de cada persona.
Y cuando alguien deja de trabajar con la empresa, su acceso se elimina.
No dentro de seis meses.
Ese día.
Eliminar o evitar cuentas genéricas como admin sigue siendo una buena práctica organizativa porque facilita identificar usuarios y reduce credenciales previsibles.
Pero conviene no exagerar su importancia.
Cambiar admin por otro nombre no convierte por sí solo una web en segura.
Una contraseña fuerte, 2FA, limitación de intentos y una gestión adecuada de permisos tienen mucho más peso.
Las webs WordPress reciben continuamente intentos automatizados de acceso.
No significa necesariamente que alguien haya elegido específicamente tu empresa como objetivo.
Muchos ataques simplemente recorren miles de sitios buscando instalaciones mal protegidas.
La propia documentación de WordPress recomienda aplicar limitación de intentos, 2FA y, cuando sea posible, controles en el servidor, CDN o WAF para frenar este tráfico antes de que llegue a WordPress.
La decisión empresarial sería:
nuestro login no puede aceptar intentos ilimitados sin controles.
La implementación puede incluir:
No hace falta discutir en una reunión si el límite deben ser cuatro intentos o cinco.
Eso es una decisión técnica.
Lo que sí necesitas decidir es que existirá algún mecanismo de protección y alguien comprobará que sigue funcionando.
Esta decisión tiene mucho más impacto del que parece.
Porque en WordPress instalar un plugin no equivale a instalar una pequeña extensión inocua en el navegador.
Estás añadiendo código que se ejecutará dentro de tu web.
Y Patchstack sitúa precisamente los plugins como origen del 91 % de las nuevas vulnerabilidades registradas en su informe de seguridad de 2026.
Eso no significa que los plugins sean malos.
WordPress debe buena parte de su flexibilidad precisamente a ellos.
El problema es instalar sin criterio.
La política debería responder al menos a estas preguntas:
Esta medida también evita otro problema habitual: el plugin bloat.
Una web puede acabar acumulando extensiones para:
Más plugins no implican automáticamente más inseguridad.
Pero cada componente adicional introduce otra dependencia que mantener.
En Errores de seguridad en WordPress: 7 fallos y cómo solucionarlos incluimos precisamente la revisión de plugins abandonados dentro de las comprobaciones periódicas que conviene realizar.
«Actualizamos cuando nos acordamos» no es un procedimiento.
Tampoco lo es:
Si funciona, mejor no tocarlo.
Una web no deja de tener vulnerabilidades porque nadie la modifique.
WordPress, sus temas y sus plugins reciben actualizaciones periódicas, algunas de ellas relacionadas específicamente con seguridad. La documentación oficial mantiene mecanismos de actualización automática y distingue entre actualizaciones del núcleo, plugins, temas y traducciones.
Eso no significa que haya que pulsar «actualizar todo» indiscriminadamente cada mañana.
Hay instalaciones donde conviene:
Nosotros lo explicamos en Actualizar WordPress por seguridad: guía completa, donde planteamos las actualizaciones como un proceso controlado y no como una acción aislada.
Para una pyme puede bastar con una política comprensible:
Una revisión mensual puede ser un punto de partida razonable para muchas webs corporativas.
Pero no debería interpretarse como «esperar siempre un mes». Una vulnerabilidad crítica explotada activamente puede exigir actuar antes.
Aquí dejamos de hablar de informática y empezamos a hablar de negocio.
Imagina que mañana a las 11:00 hay que restaurar tu WordPress.
La última copia disponible es de las 02:00.
¿Qué ha ocurrido durante esas nueve horas?
En una web corporativa quizá nada.
En un WooCommerce podrían haberse producido:
En una web de servicios:
Por eso la pregunta no es simplemente:
¿Tenemos backups?
La pregunta es:
¿Cuántas horas de información podemos permitirnos perder?
Una estrategia razonable debería incluir archivos y base de datos, automatización, retención suficiente y al menos una copia independiente del servidor principal.
CISA recomienda la estrategia 3-2-1 y subraya además la necesidad de probar las copias, especialmente frente a ransomware.
En arreglotuweb.com hemos dedicado un artículo completo a esta cuestión: Copias de seguridad en WordPress: la diferencia entre creer que las tienes y saber que funcionan.
La parte más importante no es generar el archivo.
Es saber recuperarlo.
Por eso debería existir también una prueba periódica de restauración.
Una vez al año debería considerarse un mínimo muy modesto para una web de empresa. En sitios con actividad crítica tiene sentido probar con mayor frecuencia.
La seguridad funciona mejor por capas.
Una de ellas puede ser un WAF, o Web Application Firewall.
En lenguaje de negocio: un filtro situado delante de tu web que analiza solicitudes y puede bloquear determinados patrones de ataque antes de que alcancen WordPress.
La documentación oficial de WordPress recomienda precisamente priorizar, cuando sea posible, protecciones en el servidor o en el perímetro mediante CDN/WAF para determinados ataques de fuerza bruta.
A esa capa pueden añadirse:
Ninguna herramienta convierte una web en inexpugnable.
Eso no existe.
El objetivo es otro:
reducir las oportunidades de ataque y detectar antes los comportamientos anómalos.
Y aquí vuelve a aparecer la importancia del hosting.
Un alojamiento adecuado puede aportar parte de esas capas, pero no necesariamente todas.
Por eso conviene saber exactamente qué cubre tu hosting y qué debería asumir quien mantiene WordPress.
Esta decisión suele tomarse demasiado tarde.
Cuando ya aparece una página extraña.
Cuando Google muestra resultados japoneses que nadie ha creado.
Cuando los clientes llaman porque el navegador advierte que la web es peligrosa.
Cuando el administrador deja de permitir el acceso.
Entonces empieza el improvisado grupo de WhatsApp:
«¿Quién tiene las claves?»
«¿Llamamos al hosting?»
«¿Restauramos?»
«¿De qué día es la copia?»
«¿Desconectamos la web?»
«¿Esto afecta a datos de clientes?»
Un pequeño procedimiento de incidentes evita parte de ese caos.
No hace falta un manual de 80 páginas.
Para una pyme puede bastar con dejar claras cinco cosas:
Y hay una cuestión especialmente importante:
no siempre conviene restaurar inmediatamente.
Si ha habido una intrusión, primero puede ser necesario conservar evidencias, identificar el problema y asegurarse de que la copia elegida es limpia.
En Web WordPress hackeada: cómo detectarla y arreglarla explicamos un procedimiento que comienza por aislar, preservar información, cambiar credenciales y determinar qué se ha comprometido antes de dar el incidente por resuelto.
El objetivo del procedimiento no es evitar todos los problemas.
Es reducir el tiempo perdido improvisando cuando aparecen.
Tu responsable de marketing no necesita aprender administración de servidores.
Quien publica artículos tampoco necesita convertirse en especialista en ciberseguridad.
Pero algunas conductas tienen suficiente impacto como para que todo el equipo las conozca.
Por ejemplo:
Una sesión breve anual puede ser más útil que enviar un manual que nadie va a leer.
Especialmente para quienes trabajan habitualmente con:
Hay una razón sencilla.
Muchas decisiones de seguridad se toman fuera del departamento técnico.
Se toman cuando alguien comparte una contraseña, instala un plugin, concede acceso a un proveedor o pulsa un enlace.
Si diriges una pyme, probablemente no necesitas otra checklist de 70 configuraciones.
Necesitas poder sentarte con quien mantiene vuestra web y hacerle estas diez preguntas:
Las respuestas deberían ser concretas.
«Sí, creemos que eso lo hace el hosting» no cuenta.
Buena parte de estas decisiones forman parte de lo que debería cubrir un mantenimiento WordPress profesional.
No se trata de instalar un plugin de seguridad y esperar.
Primero necesitamos saber qué existe.
Revisamos aspectos como:
Es una forma de separar los riesgos reales de la acumulación de recomendaciones genéricas.
Una vez ordenada la instalación, el objetivo es que no vuelva a deteriorarse poco a poco.
Esto incluye actualización, supervisión, copias y resolución de incidencias dentro de un proceso continuo.
En Cómo trabajamos el mantenimiento WordPress explicamos nuestro modelo de seguimiento, que incluye monitorización, copias automáticas y actualizaciones.
No damos por buena una copia simplemente porque una tarea programada figure como completada.
La capacidad de recuperación forma parte de la seguridad.
También comprobamos si el alojamiento encaja realmente con las necesidades de la web.
Porque algunas deficiencias se pueden solucionar dentro de WordPress.
Otras requieren actuar sobre la infraestructura.
Y cuando varias personas gestionan contenidos o marketing, podemos establecer unas normas simples de acceso y trabajo para evitar que el sistema vuelva a desordenarse.
Hay una decisión número once que en realidad resume todas las anteriores:
seguir improvisando o convertir la seguridad de la web en una responsabilidad gestionada.
No necesitas convertirte en experto en WordPress.
Tampoco comprar cinco herramientas de seguridad.
Necesitas saber qué riesgos tienes cubiertos, cuáles no y quién actuará cuando haya que hacerlo.
Si no puedes responder con seguridad a las diez preguntas anteriores, en arreglotuweb.com podemos revisar vuestra instalación WordPress y convertirlas en un plan concreto: qué está bien, qué hay que corregir y qué merece realmente la pena proteger primero.
Ese es el objetivo de una auditoría útil.
No darte otra lista de problemas.
Darte prioridades.
