Cómo limpiar un WordPress hackeado: guía técnica para agencias
Un WordPress hackeado es una emergencia. Cada hora que el sitio permanece infectado, Google puede marcar el dominio como peligroso, los visitantes reciben avisos de seguridad en el navegador y el posicionamiento orgánico se deteriora. Para una agencia que gestiona el sitio de un cliente, el riesgo es doble: técnico y reputacional.
Esta guía describe el proceso completo de limpieza de un WordPress hackeado desde la perspectiva de una agencia que opera en marca blanca. Cubre la detección, la eliminación del malware, la recuperación de archivos, el blindaje posterior y la notificación a Google Search Console para retirar los avisos de seguridad. El proceso se basa en la metodología de Kalyma Studio desarrollada a partir de cientos de limpiezas realizadas en proyectos de agencias partner en España.
Por qué se hackean los sitios WordPress
Antes de limpiar, conviene entender por qué ocurrió el hackeo. La mayoría de las intrusiones no son ataques dirigidos: son el resultado de herramientas automatizadas que escanean millones de sitios buscando vulnerabilidades conocidas.
Las tres causas más frecuentes, por orden de incidencia:
Plugins y temas desactualizados: El 90% de las vulnerabilidades de WordPress entran por plugins o temas con versiones antiguas que tienen exploits públicos documentados. Un plugin abandonado por su desarrollador es una puerta de entrada permanente hasta que se elimina o reemplaza.
Plugins y temas desactualizados: WordPress requiere PHP activo con soporte de seguridad. Las versiones de PHP que ya no reciben parches de seguridad (PHP 7.4 y anteriores a fecha de 2026) exponen el servidor a vulnerabilidades conocidas que no se van a corregir. Según los datos de WordPress.org del informe de estadísticas de 2025, el 23% de los sitios WordPress activos siguen ejecutándose en versiones de PHP sin soporte oficial.
Versiones de PHP obsoletas: WordPress requiere PHP activo con soporte de seguridad. Las versiones de PHP que ya no reciben parches de seguridad (PHP 7.4 y anteriores a fecha de 2026) exponen el servidor a vulnerabilidades conocidas que no se van a corregir. Según los datos de WordPress.org del informe de estadísticas de 2025, el 23% de los sitios WordPress activos siguen ejecutándose en versiones de PHP sin soporte oficial.
Contraseñas débiles y credenciales reutilizadas: Los ataques de fuerza bruta contra wp-login.php son continuos. Una contraseña de ocho caracteres sin caracteres especiales puede resolverse en minutos con herramientas automatizadas. Las credenciales de wp-admin reutilizadas en otras plataformas son especialmente vulnerables si esas plataformas han sufrido filtraciones de datos.
Señales de que un WordPress ha sido hackeado
No todos los hackeos son visibles de inmediato. Estas son las señales que indican que un sitio puede estar comprometido:
– Google Search Console muestra avisos de contenido malicioso o phishing
– El navegador muestra una pantalla de advertencia de «sitio peligroso» al acceder
– El sitio redirige a páginas externas desconocidas en determinados navegadores o dispositivos
– Aparece contenido en idiomas extraños o enlaces a sitios de spam en el código fuente
– El servidor envía correos masivos no autorizados desde la cuenta de hosting
– El panel de WordPress muestra usuarios administradores que nadie ha creado
– Los archivos del core de WordPress o de plugins conocidos han sido modificados recientemente sin motivo
Fase 1 — Contención inmediata
Antes de limpiar, hay que detener el daño.
Poner el sitio en modo mantenimiento: Evita que los visitantes accedan al sitio mientras está comprometido y protege la reputación del cliente.
Cambiar todas las credenciales de acceso de forma inmediata: wp-admin, FTP/SFTP, base de datos y cPanel o panel de hosting. Si las credenciales de wp-admin se reutilizaban en otros servicios, cambiarlas también en esos servicios.
Hacer una copia del estado actual: Antes de eliminar nada, hacer un backup completo del sitio infectado. Esto permite analizar el vector de entrada y recuperar contenido si el proceso de limpieza elimina algo por error.
Notificar al equipo: Si la agencia gestiona el sitio en nombre de un cliente, documentar el incidente internamente antes de iniciar la limpieza. En modelo marca blanca, el cliente no necesita saber los detalles técnicos del proceso, pero la agencia debe tener un registro interno de lo ocurrido.
Fase 2 — Detección y análisis del malware
La limpieza sin diagnóstico previo es ineficaz. Hay que identificar qué tipo de infección es, dónde están los archivos comprometidos y cuál fue el vector de entrada antes de empezar a eliminar.
Escaneo con herramientas especializadas: Los plugins de seguridad como Wordfence o MalCare permiten escanear el sistema de archivos completo del sitio comparando los archivos actuales contra las versiones oficiales del repositorio de WordPress. Los archivos modificados aparecen como alertas.
Revisión manual de archivos críticos: El malware suele insertarse en wp-config.php, en los archivos .htaccess, en el directorio /wp-includes/ y en los archivos functions.php de los temas activos. Una búsqueda de funciones PHP sospechosas como eval(), base64_decode(), str_rot13() o gzinflate() en el código de archivos que no deberían contenerlas identifica la mayoría de las inyecciones.
Revisión de usuarios administradores: Acceder a Usuarios > Todos los usuarios en el panel de WordPress y verificar que no hay cuentas con rol de administrador que no hayan sido creadas por el equipo legítimo.
Revisión de tareas programadas: El malware frecuentemente añade tareas en wp-cron.php para ejecutarse periódicamente. Revisar las tareas programadas activas con un plugin como WP Crontrol.
Fase 3 — Limpieza del malware
Una vez identificados los archivos comprometidos, el proceso de limpieza sigue este orden:
Reinstalar el core de WordPress desde cero: Descargar la versión oficial de WordPress desde wordpress.org y reemplazar los archivos del core (/wp-admin/ y /wp-includes/) con las versiones limpias. No eliminar el directorio /wp-content/ durante este proceso.
Reinstalar los plugins desde el repositorio oficial: Eliminar todos los plugins y reinstalarlos desde el repositorio oficial de WordPress o desde el proveedor autorizado. No restaurar plugins desde la copia de seguridad del sitio infectado.
Limpiar o reemplazar los temas: Revisar los archivos functions.php de todos los temas instalados, incluidos los inactivos. Los temas inactivos con malware son un vector de reinfección habitual. Si el tema tiene una versión de soporte activo, reinstalarlo desde cero.
Limpiar o reemplazar los temas: Revisar los archivos functions.php de todos los temas instalados, incluidos los inactivos. Los temas inactivos con malware son un vector de reinfección habitual. Si el tema tiene una versión de soporte activo, reinstalarlo desde cero.
Revisar y limpiar el archivo .htaccess: Regenerar el archivo .htaccess desde WordPress (Ajustes > Enlaces permanentes > Guardar cambios) después de verificar que no contiene redirecciones no autorizadas.
En Kalyma Studio, el proceso de limpieza se realiza en entornos de staging neutros o directamente en la infraestructura del cliente bajo protocolos de acceso restringido. Al sustituir los archivos del core y los plugins por versiones oficiales, se mantiene la integridad de la maquetación en Elementor y las configuraciones SEO intactas.
Fase 4 — Blindaje post-limpieza
Limpiar el sitio sin blindarlo es garantizar que vuelva a infectarse. Estas son las medidas que Kalyma Studio aplica después de cada limpieza:
Cambio completo de credenciales: SFTP, base de datos, wp-admin y salts de WordPress. Las salts se regeneran editando wp-config.php con valores nuevos desde api.wordpress.org/secret-key/1.1/salt/. Al regenerarlas, todas las sesiones activas quedan invalidadas.
Actualización completa del entorno: WordPress core, todos los plugins y el tema activo a sus versiones más recientes. Si algún plugin no tiene actualizaciones desde hace más de 12 meses, evaluar si existe una alternativa mantenida.
Verificación de la versión de PHP: Confirmar que el servidor ejecuta una versión de PHP con soporte oficial activo. En 2026, las versiones con soporte son PHP 8.1, 8.2 y 8.3.
Instalación de un firewall a nivel de aplicación: Wordfence en modo firewall activo o una solución equivalente que bloquee patrones de ataque conocidos antes de que lleguen al código de WordPress.
Autenticación de dos factores en wp-admin: Especialmente para cuentas con rol de administrador.
Eliminación de usuarios administradores no autorizados: Verificar que solo tienen rol de administrador las cuentas que corresponden a usuarios legítimos.
Fase 5 — Notificación a Google Search Console
Si Google había marcado el sitio como peligroso, la limpieza técnica no es suficiente. Hay que notificar a Google que el sitio está limpio para que retire los avisos de seguridad del navegador y restaure el posicionamiento.
El proceso en Search Console:
- Acceder a Search Console con la cuenta propietaria del dominio
- Ir a Seguridad y acciones manuales > Problemas de seguridad
- Verificar qué tipo de problema detectó Google (malware, phishing, contenido engañoso)
- Hacer clic en «Solicitar una revisión» y describir las medidas tomadas con detalle
- Google revisa el sitio en un plazo de entre 1 y 3 días para sitios con problemas de malware
Si el sitio tenía posicionamiento antes del hackeo, la recuperación del CTR comienza cuando Google retira el aviso y los usuarios dejan de ver la pantalla de advertencia en el navegador.
El coste real de un hackeo para una agencia
Un hackeo no es solo un problema técnico. Es un problema financiero.
El tiempo de intervención para limpiar un sitio WordPress comprometido varía entre 4 y 16 horas dependiendo de la complejidad de la infección. A una tarifa de 50 euros por hora, eso supone entre 200 y 800 euros de trabajo no planificado por cada incidente.
Si la agencia gestiona 20 sitios de clientes y uno se hackea cada trimestre por falta de mantenimiento preventivo, el coste anual de las limpiezas reactivas supera con frecuencia el coste de un plan de mantenimiento que las hubiera evitado.
La conclusión que Kalyma Studio extrae de cientos de limpiezas es siempre la misma: el hackeo es el síntoma de un abandono técnico. Un sitio WordPress con actualizaciones al día, versión de PHP soportada y contraseñas robustas tiene un perfil de riesgo significativamente menor que uno sin mantenimiento activo.
Fecha de modificación: 15 de junio 2026