Pablo Román
Profesional de la comunicación y el diseño web. Trabajo con contenidos, SEO y WordPress, y sigo de cerca el análisis del mercado laboral y las tendencias de empleo y formación.

«Pero si ya pago un buen hosting…»
Es una reacción habitual cuando una empresa descubre que su WordPress tiene plugins vulnerables, copias que nadie ha comprobado o usuarios administradores que ya no deberían conservar acceso.
El razonamiento parece lógico: si el alojamiento se anuncia como gestionado, protegido o especializado en WordPress, debería encargarse de que la web sea segura.
La realidad es otra.
Un buen hosting es una capa importante de protección, pero no administra por completo la seguridad de tu WordPress. Mantiene la infraestructura sobre la que funciona la página; no necesariamente supervisa todo lo que has instalado, cómo está configurado o qué funciones son críticas para tu negocio.
La diferencia importa. El informe State of WordPress Security in 2026, elaborado por Patchstack con datos de 2025, registró 11.334 nuevas vulnerabilidades en el ecosistema WordPress, un 42 % más que el año anterior. El 91 % apareció en plugins y el 9 % en temas. Solo seis afectaron al núcleo de WordPress y fueron consideradas de baja prioridad.
El problema no es, por tanto, que WordPress sea necesariamente inseguro. El riesgo se concentra en el conjunto de componentes, configuraciones, usuarios e integraciones que forman cada instalación.
Por eso conviene abandonar la idea de una única solución milagrosa y pensar en capas de defensa.
Las prestaciones cambian mucho entre proveedores y planes. No cubre lo mismo un alojamiento compartido económico que un servicio gestionado con aislamiento, monitorización y soporte especializado.
Aun así, normalmente existe una división clara entre la infraestructura del proveedor y la aplicación WordPress del cliente.
El proveedor suele responsabilizarse de:
También puede limitar intentos de acceso, bloquear direcciones IP sospechosas, filtrar patrones conocidos y aislar unas cuentas de otras.
Todo esto es necesario. Un WordPress bien mantenido sobre un servidor mal configurado continúa siendo vulnerable.
Algunos proveedores actualizan automáticamente:
Esta automatización reduce riesgos, pero tiene límites.
El hosting puede instalar una nueva versión de un plugin. Lo que normalmente no hace es comprobar con criterio funcional si, después de la actualización:
Actualizar y verificar no son la misma tarea. Como explicamos en nuestra guía sobre las actualizaciones de WordPress para empresas, cada cambio relevante debería ir acompañado de copias, pruebas y un procedimiento de recuperación.
El informe de Patchstack permite medir una parte de ese hueco.
Para las vulnerabilidades con mayor actividad maliciosa, Patchstack calculó una mediana ponderada de cinco horas entre la divulgación y el primer intento de explotación. Aproximadamente la mitad de las vulnerabilidades de alto impacto analizadas comenzó a explotarse durante las primeras 24 horas.
Esto cambia el modelo tradicional de seguridad.
Ya no siempre basta con recibir una alerta, esperar a que aparezca una actualización y aplicarla durante la revisión mensual. Para entonces, los bots pueden llevar horas buscando instalaciones vulnerables.
Los ataques automatizados tampoco necesitan conocer tu empresa. Exploran grandes cantidades de sitios, detectan versiones concretas de plugins y prueban técnicas de explotación conocidas.
Tu pequeña web corporativa puede ser atacada aunque nadie haya decidido atacarte personalmente.
Patchstack realizó en 2025 dos pruebas sobre defensas habituales de proveedores de hosting, incluidos cortafuegos internos y servicios como Cloudflare.
En una prueba centrada en vulnerabilidades de WordPress ya explotadas, las defensas tradicionales bloquearon el 12 % de los ataques. En otra prueba más amplia, el porcentaje ascendió al 26 %.
Estos resultados no significan que los cortafuegos sean inútiles. Significan que un WAF genérico no conoce necesariamente la lógica interna de todos los plugins de WordPress.
Un filtro convencional puede identificar una inyección SQL evidente o una petición anómala. Resulta más difícil que detecte un fallo de control de acceso que utiliza una petición aparentemente legítima, pero permite a un usuario realizar una acción para la que no debería tener permiso.
La protección del servidor y la protección específica de la aplicación se complementan. No son intercambiables.
El mismo informe señala que el 46 % de las vulnerabilidades no recibió una corrección del desarrollador antes de hacerse pública.
En esos casos, la recomendación «mantén todo actualizado» es insuficiente: no existe todavía una versión segura que instalar.
Puede ser necesario:
Son decisiones que dependen de la función del plugin y de su importancia para el negocio.
Los componentes premium tampoco están automáticamente mejor protegidos.
Patchstack recibió 1.983 informes válidos relacionados con componentes premium o freemium. El 76 % correspondía a vulnerabilidades explotables en ataques reales. Además, su programa de zero-days detectó 33 fallos críticos en componentes premium frente a 12 en componentes gratuitos.
No significa que todos los plugins de pago sean inseguros. Una posible explicación es que su código resulta menos accesible para los investigadores y recibe menos revisión pública que los proyectos disponibles en repositorios abiertos.
La licencia aporta actualizaciones y soporte. No sustituye la vigilancia sobre lo que tienes instalado.
Las condiciones exactas dependen del contrato. Algunos proveedores ofrecen servicios adicionales de seguridad o mantenimiento WordPress.
Pero un plan de alojamiento no suele asumir las siguientes responsabilidades.
El hosting no suele evaluar:
Cada extensión amplía el inventario que hay que revisar. Más plugins no implican automáticamente más riesgo, pero sí más código, dependencias, actualizaciones y posibles conflictos.
Para el proveedor, el servidor puede estar operativo aunque:
Su objetivo principal es mantener disponible la infraestructura. El tuyo es que la web cumpla una función comercial.
Una página que responde con código HTTP 200 puede estar técnicamente activa y, al mismo tiempo, haber dejado de generar oportunidades.
El proveedor tampoco sabe necesariamente:
Estas decisiones corresponden a la gestión de WordPress y a los procedimientos internos de la empresa.
Muchos alojamientos incluyen copias, pero conviene comprobar:
Una copia no verificada es una posibilidad de recuperación, no una recuperación garantizada.
No existe una herramienta capaz de eliminar por sí sola todos los riesgos. Una estrategia razonable para una pyme puede organizarse en tres capas.
La base debería incluir:
Elegir únicamente por precio puede salir caro, pero contratar el plan más caro tampoco resuelve automáticamente los problemas de WordPress.
La elección debe depender del tráfico, las funciones, el volumen de negocio que pasa por la web y el tiempo máximo que puedes permitirte estar fuera de servicio.
Aquí entran los sistemas de inteligencia de vulnerabilidades y el virtual patching.
Un parche virtual es una regla que bloquea la explotación de un fallo conocido sin modificar directamente el código vulnerable. Puede proteger temporalmente una instalación mientras el desarrollador publica una actualización o mientras se prueba la nueva versión.
A diferencia de un WAF genérico, estas reglas pueden estar diseñadas para:
No reemplaza la actualización definitiva. Cierra temporalmente la ventana de exposición y permite aplicar el parche oficial de forma controlada.
También conviene evitar otro extremo: instalar varios plugins de seguridad, cortafuegos y escáneres sin coordinación. Pueden duplicar funciones, consumir recursos, generar falsas alarmas o bloquear tráfico legítimo.
La herramienta debe formar parte de un procedimiento, no convertirse en el procedimiento.
Esta es la capa que conecta la tecnología con el negocio.
Un mantenimiento profesional debería revisar regularmente:
También debe establecer prioridades.
No todas las actualizaciones requieren la misma urgencia. No todos los avisos tienen el mismo impacto. Una vulnerabilidad crítica en un plugin expuesto a usuarios anónimos exige una respuesta distinta a un fallo menor que solo puede aprovechar un administrador autenticado.
En nuestro artículo sobre mantenimiento web WordPress en 2026 explicamos por qué actualizar es solo una parte de un sistema más amplio de prevención, comprobación y recuperación.
No necesitas convertirte en especialista en ciberseguridad. Sí necesitas saber quién es responsable de cada capa.
Hazte una pregunta sencilla:
¿Qué ocurre en tu empresa si la web deja de funcionar durante uno, dos o tres días?
El impacto no es igual para:
Cuanto más negocio dependa de la web, menos razonable resulta delegar toda la seguridad en las prestaciones genéricas del hosting.
Deberías poder responder estas preguntas:
Si la respuesta general es «supongo que lo hace el hosting», existe una responsabilidad sin asignar.
Nuestra guía sobre cómo no ser rehén de tu proveedor web explica qué accesos, documentación y control mínimo debería conservar cualquier empresa.
El alcance debe adaptarse a cada proyecto, pero un servicio serio debería cubrir al menos los siguientes puntos.
No basta con comprobar si hay actualizaciones pendientes. Hay que relacionar:
El procedimiento debería incluir:
Pulsar «actualizar todo» no es un procedimiento de mantenimiento.
Conviene mantener al menos una copia fuera del servidor de producción y realizar pruebas periódicas de restauración.
La frecuencia dependerá de cuánto cambia la web. Una página corporativa puede tolerar una política distinta a una tienda con pedidos diarios o una academia con actividad continua.
Debe incluir:
El servicio debería detectar caídas y disponer de un canal claro para reaccionar ante:
Cuando el problema ya se ha producido, nuestra guía para recuperar un WordPress hackeado explica por qué restaurar una copia sin investigar la causa puede provocar una reinfección.
Un plan de mantenimiento no debería limitarse a buscar malware.
Una instalación lenta, saturada de plugins y llena de código abandonado suele ser también más difícil de proteger y recuperar.
Reducir componentes innecesarios puede aportar:
La velocidad tampoco es únicamente una cuestión técnica. Afecta a la navegación, la conversión y la percepción de confianza. Por eso el mantenimiento debería incorporar mediciones y mejoras sobre Core Web Vitals, rendimiento y estabilidad, especialmente en webs que dependen del posicionamiento o de campañas de captación.
En Arreglo tu Web no sustituimos al proveedor de hosting. Nos ocupamos de la capa que suele quedar entre la infraestructura y las necesidades reales de la empresa.
Antes de proponer un plan, revisamos:
El resultado no debería ser una colección de alertas automáticas difíciles de interpretar. Traducimos los hallazgos a decisiones comprensibles:
Nuestros servicios de mantenimiento WordPress pueden cubrir:
El objetivo no es llenar tu web de herramientas de seguridad. Es reducir la probabilidad de incidentes, detectar antes los problemas y disponer de una respuesta cuando algo falla.
Un buen alojamiento protege la infraestructura. Un sistema específico de seguridad puede bloquear vulnerabilidades conocidas. Un servicio de mantenimiento revisa, decide, prueba y responde teniendo en cuenta cómo funciona tu negocio.
Las tres capas son necesarias en una web crítica.
La pregunta útil no es «¿mi hosting es seguro?», sino:
¿Quién se responsabiliza de todo lo que ocurre entre el servidor y el funcionamiento real de mi web?
Si nadie revisa tus plugins, prueba las copias, controla los accesos y comprueba las funciones importantes después de cada cambio, esa parte sigue desatendida.
Tu hosting pone los cimientos. Pero si tu web genera clientes, reservas o ventas, necesita algo más que unos buenos cimientos: necesita un plan.
Solicita una revisión técnica de tu WordPress y te ayudaremos a detectar qué capas tienes cubiertas, cuáles faltan y qué actuaciones deberías priorizar.