Cada vez es más común encontrarse con infecciones y hackeos en sitios WordPress. En los últimos meses me he topado con varios sitios afectados, y hace poco me pidieron hacer un diagnóstico de una web porque había sospechas de que podía estar infectada. De ahí sale este artículo.
Lo que quiero contarte es por dónde empiezo a mirar cuando sospecho que un WordPress está comprometido, para que tú también puedas hacerte una primera idea de si tu sitio tiene un problema o no. Lo escribo pensando en alguien con un conocimiento técnico básico, así que no hace falta ser desarrollador para seguirlo.
Antes de entrar en materia, quiero dejar clara una idea que va a recorrer todo el artículo: no todo aviso es un hackeo. Los sistemas a veces fallan, van lentos o se caen por motivos de software, humanos o de infraestructura. Es parecido a cuando el tráfico se ralentiza por unas obras o por un día de mucha afluencia, y no por eso pensamos que ha habido un accidente. De hecho, muchas de las detecciones automáticas de “archivo malicioso” terminan siendo falsos positivos. Por eso lo primero, antes de tocar nada, es siempre lo mismo: mantener la calma, revisar con criterio y seguir un orden.
Los bots no te odian, te escanean
Hay una idea muy extendida, y muy equivocada, que es pensar que si te hackean es porque alguien la ha tomado contigo. En la inmensa mayoría de los casos no hay nadie al otro lado eligiéndote a ti. Lo que hay son bots automatizados escaneando millones de webs al día, buscando siempre las mismas señales: una versión vieja de un plugin, una ruta de login expuesta, un archivo que delata qué tienes instalado.
Y los datos lo confirman. El núcleo de WordPress es muy seguro; según el informe de seguridad de Patchstack , en todo 2025 se le encontraron solo dos vulnerabilidades. El problema casi nunca está ahí, sino en lo que lo rodea, y muy especialmente en los plugins, que concentran la enorme mayoría de las vulnerabilidades (los análisis del sector lo sitúan en torno al 97%). Los más peligrosos son los plugins abandonados, esos que llevan dos o más años sin recibir una actualización.
El patrón se repite casi siempre de la misma forma. Un desarrollador descubre una vulnerabilidad en un plugin popular y la publica. Ese mismo anuncio, que sirve para que la gente actualice, también le dice a los atacantes exactamente qué tienen que buscar. A partir de ahí, los bots empiezan a escanear en masa en busca de sitios que todavía no han aplicado la actualización, y la ventana entre que se publica el fallo y empieza la explotación puede ser de apenas unas horas.
Por eso los sitios que caen son casi siempre los que están desactualizados o directamente abandonados. No es cuestión de mala suerte, es ser el objetivo más fácil de la lista.
¿Y qué buscan una vez dentro?
En mi experiencia, los objetivos más comunes son dos, y rara vez tienen que ver contigo en concreto.
El primero es el spam SEO. Aquí el atacante usa tu web, y sobre todo tu reputación en Google, para posicionar contenido basura que normalmente redirige a ecommerce chinos o a sitios de dudosa confianza. Es el caso que más me he encontrado. Una forma rápida de detectarlo es buscar en Google site:tudominio.com y revisar si aparecen páginas en chino, japonés o inglés que tú nunca has creado. Si las ves, tienes un problema.
El segundo es el robo de datos para spam o phishing. Si tu web guarda datos de clientes o una base de usuarios, por ejemplo los envíos de tus formularios de contacto, esos datos se pueden robar para enviar campañas de correo fraudulentas. En estos casos suele haber algo más de mano humana detrás del bot, pero el origen sigue siendo el mismo de siempre: encontraron una puerta abierta, no te estaban buscando a ti.
Y de aquí sale una conclusión que es tranquilizadora y exigente a la vez: la mayoría de estos ataques se previenen con higiene básica. No necesitas convertir tu web en una fortaleza, solo necesitas no ser el sitio más fácil de la lista del bot.
Por dónde empiezo a mirar
Cuando reviso un sitio no voy dando palos de ciego. Sigo un orden por capas, de lo más visible a lo más profundo, y te lo cuento en el mismo orden en el que lo hago.
1. Google Search Console
Es mi primer vistazo, y la razón es sencilla: Google lleva rastreando tu web constantemente desde hace tiempo, así que ya tiene una opinión formada sobre ella. Lo que miro aquí es, sobre todo, tres cosas.
Primero, los apartados de Acciones manuales y Problemas de seguridad. Son los dos sitios donde Google te avisa directamente si ha detectado malware, hackeo o spam en tu web. Es la comprobación más directa que existe, y mucha gente ni siquiera sabe que están ahí.
Segundo, el rendimiento y la indexación. Aquí busco picos raros de clics o de páginas indexadas, y muy especialmente páginas que yo no he creado. Un sitemap nuevo o unas URLs que no reconozco son una bandera roja inmediata.
Y tercero, las estadísticas de rastreo. Si veo que el servidor tarda mucho más de lo normal en responder, lo apunto para vigilarlo en los días siguientes.
Un apunte de criterio importante: un pico de tráfico casi siempre tiene una explicación aburrida antes que una maliciosa. Una campaña, un evento, algo estacional. Antes de pensar en un ataque, conviene descartar lo mundano. Solo si ese pico viene de URLs o de idiomas que no encajan con tu web empiezo a preocuparme de verdad.
Después de Search Console, lo coherente es echar un vistazo a Google Analytics, o a la herramienta de analítica que uses. A veces el comportamiento de ese tráfico (de dónde viene, cómo se mueve, si parece humano o automático) te da pistas que en Search Console no se ven igual de claras.
2. WordPress higiénico
Esta es la capa donde se gana o se pierde la partida, así que es la que reviso con más calma.
Lo primero son los usuarios administradores. La pregunta es simple: ¿hay algún admin que nadie reconoce? Un usuario nuevo e inesperado es una de las señales más claras de que algo va mal, y conviene confirmarlos uno a uno en lugar de darlos por buenos de un vistazo.
Después miro las versiones, es decir, que el core, los plugins y los temas estén al día. No es un detalle menor, porque tener todo actualizado es probablemente la mejor defensa que existe contra los escaneos masivos de los que hablábamos antes.
Y luego está la integridad de archivos, que es la parte que más me gusta explicar porque es la que más se malinterpreta. Un análisis de integridad compara los archivos de tu instalación con los archivos originales del repositorio oficial de WordPress, y te avisa cuando algo no coincide. Plugins como NinjaScanner, Wordfence o Health Check & Troubleshooting hacen este tipo de comprobación, y algunos también verifican el código de los plugins contra sus versiones del repositorio.
Aquí viene lo importante, y es que un aviso no significa automáticamente que tengas un archivo infectado. Hay varios motivos perfectamente normales por los que un archivo puede aparecer marcado.
Uno son los plugins y temas premium. Productos como WPML o Elementor Pro no tienen su código en el repositorio público de WordPress, así que el escáner no encuentra con qué compararlos y los marca como archivo desconocido, avisándote de que no existen oficialmente. Es un falso positivo de manual. El otro motivo son los cambios mínimos: a veces basta un salto de línea o una sola línea modificada por una traducción para que un archivo del core salte como modificado, cuando en realidad no hay nada malicioso, solo una diferencia trivial.
Por eso un aviso de integridad no es una sentencia, sino un punto de partida. Antes de alarmarme, lo que hago es revisar qué archivo es exactamente y qué ha cambiado de verdad.
Conviene saber que existen escáneres más profundos, como los basados en reglas YARA, que en lugar de comparar contra el repositorio analizan el contenido de los archivos buscando patrones de código malicioso conocido. Son más potentes a la hora de cazar backdoors, pero también menos habituales en el día a día. Y hay un detalle común a todos estos escáneres que conviene tener en cuenta: consumen recursos del servidor, a veces bastantes. No es buena idea lanzarlos a lo loco, así que recomiendo usarlos con cabeza y, a ser posible, programarlos en horas de poca actividad para no penalizar a quien esté navegando en ese momento.
Por último, un truco sencillo que vale la pena comprobar: en la carpeta de subidas (wp-content/uploads/) no debería haber nunca archivos PHP. Si los encuentras ahí, mala señal.
3. El servidor
Esta capa se olvida muchísimo, y es un error, porque hay un riesgo que no depende de lo bien que cuides tu web. Si tu sitio comparte servidor con otras webs, algo muy habitual en muchos alojamientos, existe lo que se llama contaminación cruzada.
La idea es que, a veces, a un atacante le basta con infectar una sola de las webs del servidor para terminar llegando al resto. Esto significa que una web vieja, abandonada, o un entorno de pruebas que alguien dejó olvidado, pueden convertirse en la puerta de entrada que acabe afectando a tu sitio, por muy actualizado y limpio que lo tengas tú.
De ahí salen un par de recomendaciones que doy siempre. La primera es revisar qué webs conviven en tu servidor y eliminar las que ya no uses, porque una web que nadie mantiene no es solo espacio desperdiciado, es una puerta abierta. La segunda, en la misma línea, es borrar cualquier staging o versión antigua que ya no esté en uso, sin dejarla ahí “por si acaso”. Y la tercera tiene que ver con las cuentas de acceso SFTP o SSH: es muy habitual que en algún momento se le diera acceso a un programador o a una agencia, y que luego nadie cerrara esa cuenta. Cada acceso olvidado es una puerta más para entrar al sitio, sobre todo si esa contraseña termina filtrada en alguna brecha ajena, así que conviene mirar qué cuentas existen, comprobar si se siguen usando y borrar las que no.
Todo esto, además, explica algo que desconcierta mucho a quien lo sufre: por qué a veces se limpia una web, se restauran las copias y se cambian todas las contraseñas, y aun así vuelve a infectarse a los pocos días. Si la fuente del problema está fuera de tu WordPress, ya sea en otra web del servidor o en algún punto de persistencia que la limpieza no llegó a tocar, el problema vuelve una y otra vez. Limpiar solo la superficie no es suficiente.
Si llegado a este punto no has encontrado nada, es una buena señal. En el mejor de los casos, una auditoría termina sin hallazgos, y eso es justo lo que queremos. Aun así, todavía conviene revisar los logs del servidor web, que muchas veces guardan el rastro de accesos o peticiones extrañas que no se ven por ningún otro lado.
4. DNS
No me voy a extender aquí, pero merece al menos una mención. Existen también hackeos que afectan a la configuración DNS de tu dominio, con un objetivo bastante parecido al del spam SEO: sobre todo, crear subdominios o registros que redirigen a sitios de dudosa confianza. Es menos frecuente que el resto, pero conviene saber que esa capa también existe y que también se puede revisar.
Criterio antes que perfección
Si tuviera que quedarme con una sola idea de todo esto, sería que mantener y prevenir es, con diferencia, la mejor herramienta que tienes. Revisar tu web con cierta regularidad sale muchísimo más barato, y duele bastante menos, que tener que recuperarla después de un hackeo.
Y junto a eso, otra cosa que repito mucho: no hace falta tenerlo todo perfecto. Un análisis de seguridad casi nunca sale impoluto, y perseguir el 100% suele ser una forma de tirar el tiempo y los recursos. Lo sano es encontrar un equilibrio entre conveniencia y seguridad, cerrando lo que de verdad importa, asumiendo con conocimiento los riesgos menores y, sobre todo, sin obsesionarse.
Dentro de eso, hay dos hábitos que valen su peso en oro. El primero es cuestionarte tus plugins cada cierto tiempo: preguntarte si de verdad los sigues usando todos, y si alguno ha dejado de desarrollarse. Pasa más de lo que pensamos, que acabamos arrastrando plugins que un día instalamos y que hoy solo suman superficie de ataque sin aportarnos nada. Cuantos menos tengas, mejor. El segundo hábito es recordar que ningún plugin es inmune: las vulnerabilidades van a aparecer siempre, en uno o en otro. Lo que marca la diferencia no es elegir el plugin perfecto, que no existe, sino elegir plugins con soporte activo que se parcheen rápido cuando surge un problema.
Una checklist para que te la guardes
Para resumir, este es el orden básico que sigo cuando reviso un sitio:
- Google Search Console: acciones manuales, problemas de seguridad, y páginas o sitemaps que no reconozco.
- Google Analytics: revisar de dónde viene el tráfico y si su comportamiento parece humano o automático.
- Búsqueda
site:tudominio.com: comprobar si aparecen páginas en otros idiomas que yo no he creado. - Usuarios de WordPress: buscar algún administrador que nadie reconoce.
- Versiones: core, plugins y temas al día.
- Integridad de archivos: con criterio, distinguiendo los falsos positivos (premium, cambios mínimos) de lo que es real.
- PHP donde no debe: que no haya archivos PHP en
uploads/. - El servidor: webs vecinas abandonadas, staging olvidado, cuentas SFTP/SSH sin cerrar y logs del servidor web.
- Calma y orden: no tocar nada en caliente; mirar, entender y solo después actuar.
Esto es solo la punta del iceberg
Todo lo que he contado aquí son pautas básicas para que puedas hacerte una primera idea de si tu sitio está comprometido o no. Pero quiero ser honesto: hay bastante más donde mirar. Los logs del servidor web con más detalle, los problemas en la configuración de PHP, el hardening del sitio, o las técnicas de ocultamiento para que los bots lo tengan más difícil a la hora de descubrir versiones y puertas de acceso. Cada una de esas capas daría perfectamente para su propio artículo.
Si después de revisar todo esto crees que te han hackeado, o simplemente quieres hacer una auditoría de ciberseguridad a fondo de tu WordPress, escríbeme y lo vemos. Estaré encantado de echarte una mano. Mis datos están abajo.
Y si lo que buscas es seguir aprendiendo sobre estos temas, guarda esta página en tus marcadores y pásate de vez en cuando, que voy publicando cosas como esta a medida que me las voy encontrando en el mundo real.