Checklist de seguridad WordPress para empresas de la UE (2026)

Esta checklist de seguridad para WordPress reúne las 25 medidas que recomendamos para cualquier web empresarial en la UE, agrupadas en seis áreas: hosting, software de WordPress, cuentas, vigilancia, copias de seguridad y documentación. Recórrala de arriba abajo: los tres primeros bloques frenan la mayoría de los ataques; los tres últimos le ayudan a detectar un incidente, recuperarse y demostrar lo que hizo.

Cada punto incluye el motivo en una línea y, cuando hace falta, un enlace a una guía más detallada. Ninguna lista hace que un sitio sea «100 % seguro», pero esta le da una protección que podrá explicar a un cliente, a un auditor o a una autoridad de control.

Por qué importa la rapidez: la empresa de seguridad Patchstack contabilizó 11.334 vulnerabilidades nuevas en el ecosistema WordPress en 2025, el 91 % de ellas en plugins, y constató que aproximadamente la mitad de las de alto impacto se explotaron en menos de 24 horas (Patchstack, State of WordPress Security in 2026, informe de un proveedor del sector). La rutina vale más que cualquier herramienta aislada.

Hosting y servidor

Si el servidor es débil, nada de lo que configure dentro de WordPress lo compensa del todo.

• HTTPS en todas las páginas y, después, HSTS. HTTPS cifra en tránsito los inicios de sesión, los formularios y los pedidos, y el art. 32, apartado 1, letra a), del RGPD menciona expresamente el cifrado. Active HSTS (RFC 6797) solo cuando HTTPS funcione en todo el sitio y empiece con un max-age corto: durante ese periodo, los navegadores rechazarán cualquier conexión HTTP sin cifrar.
• Una versión de PHP con soporte. Las ramas de PHP que han llegado al final de su vida útil ya no reciben parches de seguridad; compare su versión con la lista oficial.
• SFTP o SSH en lugar de FTP, y una cuenta aislada para cada sitio. FTP envía las contraseñas sin cifrar y, sin aislamiento, un sitio hackeado puede infectar a todos los demás alojados en la misma cuenta.
• Nada de ejecutar PHP en la carpeta de subidas. En uploads solo debería haber archivos multimedia; un archivo PHP ahí dentro es casi siempre una web shell.

Para Apache 2.4, coloque esto en wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

En nginx, añada esto al bloque server, por encima de su bloque general location ~ \.php$ (se aplica la primera location con expresión regular que coincida):

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Compruebe la configuración de nginx con nginx -t antes de recargarla. Sea cual sea el servidor, verifique después que las imágenes siguen cargando y que un archivo .php de prueba en uploads devuelve «403 Forbidden».

Núcleo de WordPress, plugins y temas

Los plugins concentran la mayoría de las vulnerabilidades, así que este bloque necesita una rutina semanal. Nuestra guía sobre plugins vulnerables de WordPress entra en más detalle.

• Mantenga activas las actualizaciones automáticas de seguridad del núcleo. Por defecto, WordPress instala en segundo plano las versiones menores, que son las que traen los parches de seguridad. Asegúrese de que ningún ajuste ni herramienta del hosting las haya desactivado.
• Actualice plugins y temas en días, no en meses. En las vulnerabilidades más explotadas, Patchstack midió una mediana ponderada de cinco horas hasta la explotación masiva. Las actualizaciones automáticas, disponibles desde WordPress 5.5, acortan ese margen en los plugins de bajo riesgo.
• Elimine lo que no use. Los archivos de un plugin desactivado siguen en el servidor y pueden seguir siendo explotables; wp plugin list --status=inactive le muestra los candidatos.
• Sustituya los plugins abandonados y no use nunca copias «nulled». En los datos de Patchstack, el 46 % de las vulnerabilidades no tenía parche cuando se hicieron públicas. Un plugin abandonado quizá no lo reciba nunca, y una copia pirata no recibe ninguna actualización.
• Desactive el editor de archivos del escritorio. define( 'DISALLOW_FILE_EDIT', true ); en wp-config.php elimina el editor de archivos de temas y el de plugins, de modo que quien robe un acceso de administrador no pueda pegar código sin más en un archivo del tema.

Cuentas e inicios de sesión

Un administrador puede instalar plugins, es decir, ejecutar código en su servidor. Los roles predeterminados (Administrador, Editor, Autor, Colaborador y Suscriptor) facilitan aplicar el principio de mínimo privilegio.

• Contraseñas únicas y autenticación de dos factores para cada Administrador y Editor. Los ataques de relleno de credenciales (credential stuffing) prueban justamente contraseñas filtradas y reutilizadas. El núcleo de WordPress no incluye 2FA; nuestra guía de autenticación de dos factores explica las opciones.
• Una cuenta personal por persona, con el rol más bajo que le sirva. Los accesos compartidos «de la agencia» ocultan quién hizo qué y no se pueden revocar limpiamente.
• Elimine las cuentas antiguas y las contraseñas de aplicación que no se usen. Los antiguos empleados y agencias conservan el acceso hasta que alguien lo borra; las contraseñas de aplicación (desde WordPress 5.6) aparecen en el perfil de cada usuario.
• Limite los intentos de acceso y desactive XML-RPC si nada lo usa. XML-RPC está activado por defecto y acepta contraseñas fuera del formulario de acceso normal. Compruebe antes si algún plugin o aplicación sigue dependiendo de él.

Vigilancia y detección

Solo podrá cumplir un plazo de notificación de 72 horas si antes se da cuenta de la brecha.

• Análisis programados de malware y de integridad de archivos. Archivos PHP nuevos en uploads, archivos del núcleo modificados y código ofuscado son huellas típicas de un compromiso. wp core verify-checksums compara los archivos del núcleo con las sumas de verificación oficiales de WordPress.org. Consulte 12 señales de que su sitio ha sido hackeado.
• Registros de actividad y alertas ante nuevos administradores. Las cuentas de administrador ocultas son una vía habitual para que el atacante conserve el acceso. Los registros ayudan a reconstruir un incidente; fije un plazo de conservación, porque contienen direcciones IP.
• Alertas de vulnerabilidades para los plugins que realmente usa. Una base de datos de vulnerabilidades, por ejemplo la de WPScan o la de Patchstack, le avisa cuando uno de sus plugins tiene un fallo conocido.
• Google Search Console y monitorización de disponibilidad. Search Console informa de los problemas de seguridad que Google detecta en su sitio, como spam inyectado; los controles de disponibilidad detectan las caídas.

El plugin Security Audit & Compliance de secaudit.eu automatiza varias de estas comprobaciones (integridad de archivos, firmas de malware, administradores ocultos, plugins desactualizados, contraseñas débiles y ajustes de bastionado) y relaciona sus hallazgos con el art. 32 del RGPD y el art. 21 de la Directiva NIS2.

Copias de seguridad y recuperación

El art. 32, apartado 1, letra c), del RGPD exige la capacidad de restaurar rápidamente la disponibilidad y el acceso a los datos personales tras un incidente. Solo las copias probadas cumplen esa promesa.

• Copias automáticas de archivos y base de datos, al menos diarias en sitios con actividad. Los pedidos y los envíos de formularios cambian cada día; una copia de hace una semana los pierde.
• Al menos una copia fuera del servidor y fuera de su alcance. Un archivo de copia en la raíz web puede descargarlo cualquiera que adivine su nombre, y una copia que el propio sitio puede borrar también puede borrarla un atacante.
• Pruebe una restauración al menos dos veces al año. Una copia que nunca ha restaurado es una esperanza, no un plan, y el art. 32, apartado 1, letra d), le exige verificar sus medidas con regularidad.
• Un plan de incidentes de una página. Quién decide, quién llama al hosting, dónde están las copias limpias y cómo notificar una brecha de datos en 72 horas. Nuestro plan de eliminación de malware cubre la limpieza.

Documentación y cumplimiento

Según el art. 5, apartado 2, del RGPD, usted debe poder demostrar sus medidas. Bastan registros breves y fechados.

• Un inventario de plugins, temas, servicios externos y accesos. No se puede parchear ni revisar lo que no se conoce. Las peticiones a terceros, como Google Fonts cargadas desde los servidores de Google, también deben figurar en la lista.
• Contratos de encargo del tratamiento con su hosting y su agencia. Quien trate datos personales por cuenta de usted, incluida una agencia con acceso de administrador, necesita uno según el art. 28 del RGPD.
• Un registro de brechas e incidentes. El art. 33, apartado 5, le obliga a documentar toda violación de la seguridad de los datos personales, también las que no tuvo que notificar.
• Pruebas fechadas, revisadas al menos una vez al año. Los registros de actualizaciones, los informes de análisis y las pruebas de restauración demuestran que sus medidas funcionan de verdad.

Cómo encaja esta checklist de seguridad WordPress con el RGPD y la NIS2

El art. 32, apartado 1, del RGPD exige medidas técnicas y organizativas apropiadas, teniendo en cuenta el estado de la técnica, los costes de aplicación y el riesgo. El art. 21, apartado 2, de la Directiva NIS2 enumera diez medidas mínimas para las entidades incluidas en su ámbito.

La NIS2 se dirige sobre todo a medianas y grandes empresas de los sectores que enumera, y los detalles varían de un país a otro, así que consulte la ley nacional que la transpone en su país. Los proveedores más pequeños se ven afectados de forma indirecta, porque las entidades sujetas deben gestionar la seguridad de su cadena de suministro y pedir pruebas. Consulte nuestros artículos sobre el art. 32 del RGPD y el ámbito de la NIS2. Si vende plugins o temas, el Reglamento de Ciberresiliencia (CRA) le añade obligaciones como fabricante.

Preguntas frecuentes

¿Cada cuánto debo repasar esta lista?

Recomendamos una revisión completa al menos una vez al año y después de cualquier cambio importante, como un nuevo hosting o una nueva agencia.

¿Completar la lista hace que mi sitio cumpla el RGPD?

Ninguna lista puede lograrlo por sí sola. El art. 32 se basa en el riesgo: una tienda con cuentas de clientes necesita más que una web corporativa. La lista cubre la base técnica; su documentación explica por qué esa base se ajusta a su riesgo.

Solo tenemos una pequeña web corporativa. ¿Esto nos afecta?

En su mayor parte, sí. Los ataques automatizados no miran el tamaño de la empresa, y el RGPD se aplica en cuanto un formulario de contacto recoge datos personales.

Este artículo es información general, no asesoramiento jurídico.