¿WordPress es seguro? Por qué pasar a un sitio a medida

WordPress mueve más de 4 de cada 10 sitios web del mundo. Justamente por eso es el blanco favorito de los ataques automatizados: una sola falla sirve contra millones de sitios. Con la inteligencia artificial, esos ataques llegan cada vez más rápido. Te explico qué está pasando, por qué un sitio a medida con su propio panel de administración es más seguro, y cómo protejo los sitios que desarrollo.

Los números de 2025

El informe anual de Patchstack, especialista en seguridad WordPress, es claro:

El núcleo de WordPress en sí es bastante sólido (solo 6 fallas reportadas en 2025). El problema está en todo lo que se le agrega: plugins de formularios, sliders, tiendas, constructores visuales… cada uno escrito por un autor distinto, algunos abandonados hace años.

La IA acelera los ataques

Antes, entre la publicación de una falla y su explotación pasaban días. Hoy se cuentan en horas: con la IA, un atacante compara la versión corregida con la anterior, entiende qué se arregló y genera un ataque listo para lanzarse contra miles de sitios.

El mejor ejemplo es «wp2shell», en julio de 2026: la primera falla crítica en el núcleo de WordPress explotable sin contraseña en casi una década, según Wordfence. Fue descubierta con ayuda de un modelo de IA. El parche salió el 17 de julio y en pocas horas ya circulaban ataques públicos, con decenas de miles de intentos y cuentas de administrador falsas creadas en sitios sin actualizar (BleepingComputer).

Por qué el WordPress de una pyme es tan vulnerable

• Muchos plugins de terceros, cada uno con su propio código y sus propias fallas.
• Actualizaciones que nadie hace: el sitio se hizo hace años y nadie lo mantiene.
• Direcciones conocidas por todos: /wp-admin, /wp-login.php, /xmlrpc.php. Los robots las prueban en todos los sitios de internet, todo el día.
• Un mismo ataque sirve para millones de sitios: es rentable para el atacante.

Por qué un sitio a medida es más seguro

• Menos superficie de ataque: solo existe el código que tu negocio necesita, sin plugins de terceros.
• Sin ataque «en serie»: una falla genérica de WordPress no sirve contra un sistema único.
• Tu propio panel de administración, en una dirección que no es la de todos, con contraseñas robustas, bloqueo tras varios intentos fallidos y roles (cada usuario ve solo lo suyo).
• Una plataforma con soporte: .NET recibe parches de seguridad de Microsoft, y las consultas a la base de datos son parametrizadas, lo que cierra la puerta a la inyección SQL.

Ojo: «a medida» no es sinónimo automático de «seguro». Un sistema a medida mal hecho también es vulnerable. Lo que cuenta son las buenas prácticas, y estas son las mías.

Cómo protejo los sitios que desarrollo

1. Un filtro de seguridad en la aplicación

• Bloquea las herramientas de ataque conocidas (sqlmap, nikto, wpscan, nuclei…) por su firma.
• Bloquea las rutas sospechosas: /wp-admin, /wp-login, .env, .git, phpmyadmin, web.config, appsettings.json. Paradoja: mis sitios en .NET reciben cada día pruebas de ataques a WordPress, y se cortan de inmediato.
• Limita la cantidad de peticiones por dirección IP y bloquea temporalmente a quien abusa.
• Detecta intentos de inyección SQL y XSS con firmas precisas, no con reglas groseras. Aprendí que un filtro demasiado amplio hace más daño que bien: una regla que bloqueaba toda URL con «0x» rompía al azar algunos archivos del sitio.

2. Nunca bloquear a Google (ni a la IA que te recomienda)

Un filtro agresivo que devuelve «acceso prohibido» a Googlebot saca tu sitio de Google. Los buscadores y los asistentes de IA legítimos quedan exentos del límite de peticiones, y el robots.txt bloquea en cambio a los scrapers de SEO que solo consumen recursos.

3. Formularios blindados

Validación en el servidor, protección antifalsificación, reCAPTCHA o un campo trampa invisible que solo los robots llenan, y detección de envíos demasiado rápidos para ser humanos.

4. Un servidor IIS bien configurado

• HTTPS obligatorio con HSTS, y redirección a una sola dirección (con www).
• Cabeceras de seguridad y ocultar la versión del servidor.
• Límite de tamaño de los archivos subidos.
• Los secretos (contraseñas, claves de API) fuera del código y fuera de la carpeta pública.
• Cada sitio con su propia identidad de grupo de aplicaciones, con los permisos mínimos.

Un extracto del web.config que uso:

<system.webServer>
  <security>
    <requestFiltering removeServerHeader="true">
      <requestLimits maxAllowedContentLength="10485760" />
    </requestFiltering>
  </security>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

5. Respaldos y seguimiento

Respaldos automáticos de la base de datos, restauración probada, y revisión de los registros para detectar lo anormal.

Pasar de WordPress a un sitio a medida sin perder Google

La migración conserva el contenido, las imágenes y, sobre todo, las direcciones: cada URL antigua redirige (301) a la nueva para no perder el posicionamiento ganado. De paso, se gana velocidad, y un panel de administración pensado solo para lo que tú necesitas. Más detalles en cómo migrar un sitio antiguo, en mi guía de seguridad web para pymes y en la historia de un sitio perdido y reconstruido.