¿Cómo limpiar un sitio WordPress infectado con malware paso a paso? 🛡️
Hay pocas escenas digitales tan desagradables como abrir tu sitio WordPress una mañana y encontrarlo convertido en una feria clandestina: redirecciones a páginas extrañas, anuncios farmacéuticos en japonés, alertas rojas de Google, formularios que envían spam o una lentitud tan espesa como miel fría. Ayer era tu web. Hoy parece una casa ocupada por desconocidos con muy mal gusto.
Lo irónico —con esa ironía fina que no consuela, pero al menos explica— es que muchas infecciones no llegan por una gran conspiración de hackers encapuchados, sino por algo bastante doméstico: un plugin sin actualizar, una contraseña reciclada, un tema abandonado, un hosting mal configurado o un archivo subido hace años y olvidado como una llave debajo del felpudo. La seguridad web rara vez cae por una puerta blindada rota; suele caer por una ventana pequeña, mal cerrada, que nadie miraba.
Limpiar un sitio WordPress infectado con malware exige calma, método y cierta desconfianza saludable. No basta con instalar un plugin de seguridad y pulsar “scan”, aunque sería bonito vivir en ese mundo. El malware en WordPress puede esconderse en archivos PHP, en la base de datos, en usuarios administradores falsos, en tareas programadas, en reglas de .htaccess, en wp-config.php, en mu-plugins, en directorios de carga e incluso en el propio servidor. Es una maleza con raíces. Si solo cortas las hojas, volverá.
Esta guía explica, paso a paso y con mirada profesional, cómo diagnosticar, contener, limpiar y proteger un sitio WordPress infectado. Sirve tanto para propietarios de sitios como para desarrolladores, administradores de sistemas y responsables de mantenimiento web. No promete magia. Promete algo mejor: criterio.
Contenido de la guía
- Síntomas de una infección en WordPress
- Qué hacer antes de tocar nada
- Paso 1: poner el sitio en cuarentena
- Paso 2: crear una copia completa del sitio infectado
- Paso 3: identificar el tipo de malware
- Paso 4: limpiar archivos del núcleo de WordPress
- Paso 5: revisar plugins, temas y uploads
- Paso 6: limpiar la base de datos
- Paso 7: revisar usuarios, contraseñas y permisos
- Paso 8: comprobar tareas cron, backdoors y persistencia
- Paso 9: actualizar, endurecer y proteger
- Paso 10: solicitar revisión a Google y otros servicios
- Cómo evitar una reinfección
Síntomas de un sitio WordPress infectado con malware 🚨
Una infección no siempre entra con fanfarria. A veces se presenta como un pequeño retraso en la carga, una línea rara en el código fuente o un enlace que no recuerdas haber puesto. Otras veces aparece con sirenas: el navegador bloquea la página, Google muestra “Este sitio puede haber sido hackeado” y los clientes escriben correos con signos de exclamación como si estuvieran apagando un incendio con cubos de agua.
Algunos síntomas frecuentes de malware en WordPress son:
- Redirecciones no autorizadas a sitios de apuestas, criptomonedas, contenido adulto, falsos sorteos o páginas de soporte técnico fraudulento.
- Archivos PHP desconocidos en carpetas donde no deberían existir, especialmente en
wp-content/uploads. - Usuarios administradores nuevos que nadie creó.
- Alertas de Google Safe Browsing, Search Console, antivirus o proveedores de hosting.
- Resultados SEO contaminados: títulos y descripciones en otros idiomas, páginas indexadas con spam, enlaces ocultos.
- Consumo excesivo de CPU o memoria en el servidor.
- Envío masivo de correos spam desde el dominio.
- Archivos modificados recientemente sin intervención legítima.
- Errores 500, pantallas blancas o caídas intermitentes.
- Reglas sospechosas en
.htaccesso scripts inyectados en cabeceras y pies de página.
Conviene distinguir entre infección y vulnerabilidad. La vulnerabilidad es la puerta floja; la infección es el intruso dentro. Tapar la puerta sin sacar al intruso es una estrategia admirablemente inútil, como cerrar el paraguas después de meterse al río.
Antes de limpiar: tres verdades incómodas
La limpieza de malware en WordPress no debe hacerse con prisa. La prisa aquí tiene dedos torpes. Borra pruebas, rompe dependencias, deja puertas traseras y convierte una infección reparable en una restauración caótica.
1. No restaures una copia antigua sin investigar
Restaurar un backup puede funcionar, sí. Pero si no sabes cuándo empezó la infección, quizá estás recuperando una versión que ya estaba comprometida. Además, si la causa fue un plugin vulnerable o una contraseña robada, el atacante podría volver a entrar en cuestión de horas. Restaurar sin corregir es barrer ceniza mientras el incendio sigue en la cocina.
2. No borres archivos al azar
Hay código legítimo que parece sospechoso. Funciones como base64_decode, eval, gzinflate, str_rot13 o shell_exec pueden aparecer en malware, pero también en herramientas válidas, aunque algunas sean señales de alarma claras según el contexto. El análisis debe hacerse mirando ubicación, fecha de modificación, propietario del archivo, contenido y relación con el resto del sistema.
3. No confíes en una sola herramienta
Los escáneres son útiles, pero no infalibles. Wordfence, Sucuri SiteCheck, MalCare, VirusTotal, ImunifyAV, ClamAV o las herramientas del hosting pueden detectar patrones conocidos. Sin embargo, un malware nuevo o bien ofuscado puede pasar como un pez oscuro bajo una barca. Combina análisis automático con revisión manual.
Nota profesional: si el sitio gestiona pagos, datos sanitarios, información sensible o credenciales de usuarios, la infección puede tener implicaciones legales y de cumplimiento normativo. En esos casos conviene documentar el incidente, preservar evidencias y consultar con especialistas en ciberseguridad o protección de datos.
Paso 1: poner el sitio en cuarentena 🧯
Lo primero no es limpiar. Es contener. Un sitio infectado puede seguir dañando visitantes, enviando spam o propagando malware. Debes reducir el impacto mientras trabajas.
Acciones recomendadas:
- Activa un modo mantenimiento real, preferiblemente desde el servidor o el hosting, no desde un plugin comprometido.
- Bloquea temporalmente el acceso público mediante autenticación básica HTTP, restricción por IP o reglas del servidor si el caso es grave.
- Desactiva tareas automáticas sospechosas si detectas envío de spam o actividad anómala intensa.
- Suspende formularios vulnerables o integraciones externas que puedan estar siendo abusadas.
- Notifica al hosting si hay consumo elevado, bloqueo de correo o alertas de seguridad.
Si tienes una tienda WooCommerce o un sitio con alta actividad, la decisión duele. Cerrar temporalmente parece perder dinero; mantenerlo abierto puede perder confianza. Y la confianza, a diferencia del tráfico, no siempre vuelve cuando le pones un anuncio.
Paso 2: crear una copia completa del sitio infectado 💾
Aunque suene contradictorio, antes de eliminar malware debes guardar una copia del estado infectado. No para restaurarla en producción, sino para análisis, trazabilidad y recuperación de elementos legítimos si algo sale mal.
La copia debe incluir:
- Todos los archivos del sitio: núcleo de WordPress,
wp-content, plugins, temas, uploads, archivos ocultos y configuraciones. - Base de datos completa en formato SQL.
- Registros del servidor: access logs, error logs, logs de FTP/SFTP, logs del panel de hosting si están disponibles.
- Lista de usuarios WordPress y usuarios del servidor.
- Información de versiones: WordPress, PHP, MySQL/MariaDB, plugins y temas.
Guarda esta copia fuera del servidor infectado. Si es posible, usa un entorno local o staging aislado para analizar. Trabajar directamente en producción puede ser necesario en emergencias, pero no es lo ideal. Es como operar un reloj mientras sigue dando la hora en una torre pública: se puede, pero cada movimiento se oye demasiado.
Paso 3: identificar el tipo de malware y el alcance de la infección 🔍
No todo malware busca lo mismo. Algunos quieren robar credenciales. Otros desean insertar enlaces SEO. Otros crean puertas traseras para volver. Otros convierten tu servidor en una humilde fábrica de spam, ese sueño empresarial que nadie pidió.
| Tipo de infección | Señales comunes | Dónde suele esconderse |
|---|---|---|
| Redirecciones maliciosas | Visitantes enviados a dominios extraños, sobre todo desde móvil o tráfico de buscadores | .htaccess, functions.php, base de datos, JavaScript inyectado |
| Spam SEO | Páginas indexadas con casinos, medicamentos, enlaces ocultos o texto en otros idiomas | wp_posts, wp_options, plantillas del tema, archivos PHP modificados |
| Backdoors | Reinfección tras limpiar, archivos con nombres parecidos a legítimos, usuarios admin ocultos | wp-content/uploads, mu-plugins, plugins falsos, wp-config.php |
| Phishing | Carpetas con páginas falsas de bancos, correo o pasarelas de pago | Subdirectorios públicos, uploads, carpetas con nombres aleatorios |
| Mailer spam | IP bloqueada, cola de correo enorme, quejas de proveedores | Scripts PHP sueltos, plugins vulnerables, formularios abusados |
| Cryptominer o consumo abusivo | CPU alta, procesos extraños, lentitud persistente | Servidor, cron jobs, archivos ejecutables, scripts PHP persistentes |
Herramientas útiles para el diagnóstico
- Google Search Console: revisa “Problemas de seguridad”, “Acciones manuales” e indexación de URLs extrañas.
- Sucuri SiteCheck: escaneo externo para detectar malware visible, listas negras y redirecciones.
- VirusTotal: análisis de URLs y archivos concretos con múltiples motores.
- Wordfence o MalCare: escaneo interno desde WordPress, útil si el panel aún es confiable.
- WP-CLI: excelente para verificar checksums, usuarios, plugins y temas desde consola.
- Comandos del servidor:
find,grep,staty revisión de logs.
Si tienes acceso SSH, puedes buscar archivos PHP modificados recientemente:
find . -type f -name "*.php" -mtime -15 -print
También puedes buscar funciones comúnmente asociadas con código ofuscado:
grep -RIn --include="*.php" "base64_decode\|eval(\|gzinflate\|str_rot13\|shell_exec\|passthru\|assert(" .
Pero atención: estos comandos no dictan sentencia. Señalan lugares donde mirar. Un buen análisis no funciona como una guillotina, sino como una lupa.
Paso 4: limpiar archivos del núcleo de WordPress 🧱
El núcleo de WordPress es relativamente fácil de verificar porque sus archivos oficiales son públicos y tienen checksums. Si el malware modificó archivos como wp-settings.php, wp-load.php, index.php o archivos dentro de wp-admin y wp-includes, lo más seguro es reemplazarlos por copias limpias.
Opción recomendada: reinstalar el núcleo de WordPress
Desde el panel, si puedes acceder y confías mínimamente en el entorno:
- Ve a Escritorio > Actualizaciones.
- Haz clic en Reinstalar la versión actual.
Desde WP-CLI:
wp core verify-checksums wp core download --force --locale=es_ES
El comando wp core verify-checksums compara los archivos del núcleo con los oficiales de WordPress.org. Si muestra modificaciones en archivos core, no intentes “arreglar línea por línea” salvo que tengas una razón muy concreta. Reemplaza.
Archivos que debes revisar con especial cuidado
index.phpen la raíz.wp-config.php..htaccessen Apache o reglas equivalentes en Nginx.wp-settings.php,wp-load.phpy archivos dewp-includes.- Archivos ocultos como
.user.ini,php.inio.well-knownsi contienen instrucciones extrañas.
El archivo wp-config.php merece atención especial. No debes reemplazarlo sin conservar credenciales de base de datos, salts, prefijo de tablas y configuraciones legítimas. Busca líneas que carguen archivos remotos, código ilegible, llamadas a eval, inclusiones sospechosas o definiciones ajenas a WordPress.
Un wp-config.php limpio suele contener configuración clara. Un archivo infectado a veces parece escrito por una impresora poseída: cadenas largas, caracteres sin sentido y una confianza excesiva en ocultar lo evidente.
Paso 5: revisar plugins, temas y la carpeta uploads 🧩
En WordPress, los plugins y temas son poderosos. Esa es su virtud y su peligro. Cada extensión añade funcionalidad, pero también superficie de ataque. Un plugin abandonado puede ser una invitación con mantel blanco para un atacante automatizado.
Plugins: eliminar, reinstalar, actualizar
Haz una lista completa de plugins activos e inactivos. Luego:
- Elimina plugins inactivos. Si no se usan, no deben estar ahí.
- Reinstala plugins desde fuentes oficiales, no sobreescribas a ciegas una versión sospechosa.
- Actualiza todo lo que tenga actualización disponible.
- Revisa plugins premium descargados de sitios no oficiales. Los llamados “nulled” son una ruleta rusa con interfaz bonita.
- Comprueba vulnerabilidades conocidas en bases como WPScan Vulnerability Database, Patchstack o Wordfence Intelligence.
Con WP-CLI puedes ver plugins instalados:
wp plugin list
Y reinstalar un plugin concreto desde el repositorio oficial:
wp plugin install nombre-del-plugin --force
Temas: no olvides el tema inactivo
Muchos atacantes modifican functions.php del tema activo, pero también pueden esconderse en temas inactivos. Conserva solo:
- El tema activo.
- Un tema oficial de respaldo actualizado, como Twenty Twenty-Four o similar.
- El tema hijo si realmente se usa.
Revisa especialmente:
functions.phpheader.phpfooter.php404.php- Archivos PHP con nombres raros o fechas recientes.
Uploads: donde no debería vivir PHP
La carpeta wp-content/uploads debería contener imágenes, PDFs, vídeos y archivos multimedia. No debería contener scripts PHP ejecutables. Si encuentras archivos .php dentro de uploads, míralos con enorme sospecha.
Busca archivos PHP en uploads:
find wp-content/uploads -type f -name "*.php" -print
También revisa extensiones camufladas:
find wp-content/uploads -type f \( -name "*.php*" -o -name "*.phtml" -o -name "*.phar" \) -print
Una buena medida de endurecimiento es impedir la ejecución de PHP en uploads. En Apache, dentro de wp-content/uploads/.htaccess, puedes usar:
<FilesMatch "\.php$"> Require all denied </FilesMatch>
En Nginx, la regla se aplica en la configuración del servidor, por ejemplo denegando ejecución PHP en /wp-content/uploads/. Cada hosting tiene su forma; lo importante es el principio: las imágenes no necesitan hablar PHP.
Paso 6: limpiar la base de datos de WordPress 🗄️
La base de datos es la memoria del sitio. Y como toda memoria, puede guardar cosas que uno preferiría olvidar. Muchos ataques insertan JavaScript malicioso, iframes ocultos, enlaces spam, usuarios falsos, opciones alteradas o contenido invisible para administradores pero visible para Google.
Advertencia: antes de modificar la base de datos, crea una copia SQL. Un error en una consulta puede borrar contenido legítimo. Aquí no hay papelera elegante ni botón de arrepentimiento.
Tablas que debes revisar
wp_posts: entradas, páginas, revisiones, productos, custom post types.wp_postmeta: metadatos donde algunos constructores visuales guardan contenido serializado.wp_options: opciones del sitio, widgets, transients, configuraciones de plugins.wp_usersywp_usermeta: usuarios y roles.wp_comments: spam, enlaces, scripts o iframes.
Ten en cuenta que el prefijo puede no ser wp_. Algunos sitios usan prefijos personalizados como abc123_. No asumas; verifica en wp-config.php.
Qué buscar en la base de datos
Patrones frecuentes:
<scriptiframedisplay:nonebase64_decode- Dominios desconocidos.
- Enlaces a casinos, medicamentos, sorteos, criptomonedas o sitios acortadores.
- Código JavaScript ofuscado.
Consulta orientativa para buscar scripts en entradas:
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
Para buscar iframes:
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%iframe%';
Para revisar opciones sospechosas:
SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%base64%' OR option_value LIKE '%iframe%';
Pero cuidado con los constructores visuales, formularios, píxeles de analítica y herramientas legítimas de marketing. No todo script es veneno. La diferencia entre medicina y tóxico, como sabía cualquier boticario antiguo, está en la dosis y en la intención.
El peligro del contenido serializado
WordPress y muchos plugins guardan datos serializados en la base de datos. Si editas manualmente una cadena serializada y cambias la longitud de un texto sin ajustar el contador, puedes romper configuraciones enteras. Para reemplazos masivos, usa herramientas que respeten serialización, como WP-CLI:
wp search-replace 'dominio-malicioso.com' '' --all-tables
Primero ejecuta en modo simulación:
wp search-replace 'dominio-malicioso.com' '' --all-tables --dry-run
Paso 7: revisar usuarios, contraseñas y permisos 🔐
Después de limpiar archivos y base de datos, toca revisar quién tiene llaves. Porque sería bastante poético —y bastante absurdo— restaurar la casa y dejar al ladrón sentado en el sofá.
Usuarios de WordPress
Revisa todos los administradores. Elimina cuentas desconocidas. Cambia contraseñas de:
- Todos los usuarios administradores.
- Editores con permisos amplios.
- Cuentas de soporte o agencias antiguas.
- Usuarios FTP/SFTP.
- Panel de hosting.
- Base de datos.
- Correo asociado al dominio.
- APIs externas conectadas al sitio.
Desde WP-CLI:
wp user list --role=administrator
También puedes forzar restablecimiento de contraseñas o cambiar una concreta:
wp user update nombre_usuario --user_pass='NuevaContraseñaMuySegura'
Usa contraseñas largas, únicas y generadas por un gestor. Activa autenticación en dos factores para administradores. No es paranoia; es cerrar la segunda cerradura cuando sabes que alguien ya intentó entrar por la primera.
Permisos de archivos y propietarios
Los permisos dependen del hosting, pero como regla general:
- Directorios:
755 - Archivos:
644 wp-config.php:600o640si el servidor lo permite
Evita permisos 777. Dar escritura total al mundo es una filosofía de vida interesante para un monasterio, no para un servidor web.
Comandos orientativos:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
Consulta siempre las recomendaciones de tu proveedor, especialmente en servidores con configuraciones específicas de usuario/grupo.
Paso 8: buscar backdoors, cron jobs y mecanismos de persistencia 🕳️
El malware profesional no solo entra: aprende a quedarse. Una puerta trasera permite reinfectar el sitio aunque hayas borrado los archivos visibles. Es la semilla bajo la tierra quemada.
Lugares comunes de persistencia en WordPress
wp-content/mu-plugins: los must-use plugins se cargan automáticamente y muchos propietarios ni saben que existen.wp-content/uploads: scripts PHP camuflados entre imágenes.wp-content/plugins: carpetas con nombres parecidos a plugins legítimos.wp-content/themes: archivos modificados en temas activos o inactivos..htaccess: redirecciones condicionales por user-agent, referer o dispositivo..user.ini: directivas PHP que cargan archivos maliciosos conauto_prepend_file.- Cron jobs del sistema o WP-Cron.
- Usuarios administradores ocultos o recreados automáticamente.
Revisar WP-Cron
WordPress usa un sistema de tareas programadas llamado WP-Cron. Algunos plugins legítimos lo usan para mantenimiento, publicaciones programadas o sincronizaciones. El malware también puede usarlo para regenerarse.
Con WP-CLI:
wp cron event list
Busca hooks desconocidos, nombres aleatorios o tareas vinculadas a plugins que ya no existen.
Revisar cron del servidor
Si tienes acceso al sistema:
crontab -l
Y según permisos, revisa cron global:
ls -la /etc/cron.*
En hosting compartido quizá no tengas acceso a todo. En ese caso, pide al proveedor que revise procesos, tareas programadas, envíos de correo y scripts sospechosos en tu cuenta.
Paso 9: actualizar y endurecer WordPress después de limpiar ⚙️
Una vez eliminado el malware, empieza el trabajo menos vistoso y más importante: cerrar la causa. Aquí se separan los arreglos cosméticos de la seguridad real. Una web limpia pero no endurecida es una puerta recién pintada sin cerradura.
Actualiza todo
- WordPress core.
- Plugins.
- Temas.
- Versión de PHP.
- Dependencias del servidor si lo administras tú.
WordPress publica actualizaciones de seguridad con frecuencia cuando se detectan vulnerabilidades. Mantener versiones antiguas por “estabilidad” puede tener sentido durante unos días de prueba; mantenerlas durante meses es nostalgia peligrosa.
Elimina lo innecesario
Menos componentes, menos riesgo. Desinstala plugins redundantes, temas viejos, scripts de prueba, copias comprimidas dentro del public_html y archivos como backup.zip, old-site, test.php o adminer.php si no son necesarios. Muchos ataques empiezan en restos arqueológicos del sitio.
Configura claves de seguridad nuevas
Regenera las salts de WordPress desde el generador oficial:
https://api.wordpress.org/secret-key/1.1/salt/
Copia las nuevas claves en wp-config.php. Esto cerrará sesiones activas y obligará a iniciar sesión de nuevo.
Desactiva la edición de archivos desde el panel
Añade en wp-config.php:
define('DISALLOW_FILE_EDIT', true);
Esto no impide que un atacante con acceso al servidor modifique archivos, pero reduce el daño si compromete una cuenta administradora de WordPress.
Configura un firewall de aplicaciones web
Un WAF puede bloquear patrones de ataque antes de que lleguen a WordPress. Opciones populares:
- Cloudflare WAF.
- Sucuri Firewall.
- Wordfence Firewall.
- Reglas ModSecurity gestionadas por el hosting.
No todos los firewalls son iguales. Un WAF bien configurado es como un portero atento; uno mal configurado es un señor dormido junto a una cuerda de terciopelo.
Protege el acceso al administrador
- Activa autenticación en dos factores.
- Limita intentos de inicio de sesión.
- Usa contraseñas únicas y robustas.
- Evita usuarios llamados
admin. - Restringe
wp-adminpor IP si el equipo es pequeño y estable. - Revisa sesiones activas y desconecta las sospechosas.
Cabeceras de seguridad recomendadas
Dependiendo del sitio, puedes aplicar cabeceras HTTP como:
Strict-Transport-SecurityX-Content-Type-OptionsX-Frame-OptionsoContent-Security-Policy frame-ancestorsReferrer-PolicyPermissions-PolicyContent-Security-Policy, con pruebas cuidadosas para no romper scripts legítimos
La Content Security Policy puede ayudar a mitigar inyecciones JavaScript, pero debe implementarse con prudencia. Una CSP demasiado estricta rompe funcionalidades; una demasiado permisiva queda como un cartel de “prohibido pasar” en una puerta abierta.
Paso 10: verificar la limpieza y solicitar revisión a buscadores ✅
Después de limpiar, no basta con mirar la portada y respirar. Hay que verificar desde varios ángulos: navegador, servidor, buscadores, logs y herramientas externas.
Lista de verificación posterior
- Escanea de nuevo con herramientas internas y externas.
- Revisa que no existan redirecciones sospechosas en móvil, escritorio, tráfico orgánico y acceso directo.
- Comprueba páginas clave: inicio, entradas, productos, checkout, login, sitemap y robots.txt.
- Revisa el código fuente en busca de scripts desconocidos.
- Consulta logs recientes para detectar peticiones repetidas a archivos sospechosos.
- Verifica que no se regeneren archivos eliminados.
- Comprueba que el correo del dominio no siga enviando spam.
- Revisa Search Console en busca de URLs indexadas que no pertenecen al sitio.
Solicitar revisión en Google Search Console
Si Google marcó tu sitio con problemas de seguridad:
- Entra en Google Search Console.
- Selecciona la propiedad afectada.
- Ve a Seguridad y acciones manuales.
- Abre Problemas de seguridad.
- Describe qué encontraste, qué limpiaste y qué medidas tomaste para evitar reinfección.
- Solicita revisión.
No escribas “ya está arreglado” y nada más. Explica con claridad: archivos reemplazados, plugins actualizados, backdoors eliminados, contraseñas cambiadas, WAF activado. Google no necesita poesía; necesita evidencias. La poesía ya la ponemos nosotros en sobrevivir al incidente.
Cómo evitar que WordPress vuelva a infectarse 🌱
La prevención no es una tarea única, sino una disciplina. Menos heroica que limpiar malware a medianoche, sí, pero infinitamente más rentable. En seguridad web, el mantenimiento constante es el personaje aburrido que salva la historia.
Rutina mensual mínima
- Actualizar WordPress, plugins y temas.
- Revisar usuarios administradores.
- Comprobar copias de seguridad y hacer una restauración de prueba ocasional.
- Analizar el sitio con un escáner de malware.
- Revisar logs de acceso y errores.
- Eliminar plugins o temas que ya no se usan.
- Comprobar el estado en Search Console.
Copias de seguridad bien diseñadas
Un backup útil debe ser:
- Automático, no dependiente de la memoria humana.
- Frecuente, según el ritmo del sitio.
- Externo, almacenado fuera del servidor principal.
- Versionado, con varias fechas disponibles.
- Probado, porque un backup no restaurable es decoración digital.
Para un blog pequeño, una copia diaria puede bastar. Para WooCommerce, quizá necesites copias en tiempo real o incrementales. No es lo mismo perder una entrada que perder pedidos, clientes y facturación.
Elegir plugins con criterio
Antes de instalar un plugin, revisa:
- Última actualización.
- Compatibilidad con tu versión de WordPress.
- Número de instalaciones activas.
- Historial de vulnerabilidades y respuesta del desarrollador.
- Reputación del proveedor.
- Necesidad real: si solo añade una función menor, quizá no compensa.
El ecosistema WordPress es generoso, casi exuberante. También es una selva. Hay flores, frutos y algún bicho con demasiadas patas.
Hosting seguro y actualizado
Un buen hosting no convierte un sitio vulnerable en invencible, pero ayuda mucho. Busca proveedores que ofrezcan:
- Versiones modernas de PHP.
- Aislamiento entre cuentas.
- Backups externos.
- WAF o reglas ModSecurity.
- Escaneo de malware.
- Soporte técnico competente.
- Acceso SSH/SFTP seguro.
- Registros disponibles para auditoría.
El hosting barato no siempre sale caro, pero cuando sale caro lo hace con entusiasmo.
Checklist rápida para limpiar malware en WordPress 🧾
| Fase | Acción | Estado |
|---|---|---|
| Contención | Poner el sitio en mantenimiento, bloquear accesos maliciosos y avisar al hosting | ☐ |
| Backup | Copiar archivos, base de datos y logs antes de modificar | ☐ |
| Diagnóstico | Escanear con varias herramientas y revisar síntomas | ☐ |
| Núcleo | Verificar checksums y reinstalar WordPress core | ☐ |
| Plugins | Eliminar innecesarios, reinstalar desde fuentes oficiales y actualizar | ☐ |
| Temas | Revisar tema activo, tema hijo e inactivos; borrar lo que no se use | ☐ |
| Uploads | Buscar PHP, phtml, phar y bloquear ejecución | ☐ |
| Base de datos | Eliminar scripts, iframes, spam SEO y opciones maliciosas | ☐ |
| Usuarios | Eliminar administradores desconocidos y cambiar contraseñas | ☐ |
| Persistencia | Revisar cron, mu-plugins, .htaccess, .user.ini y backdoors | ☐ |
| Hardening | Activar 2FA, WAF, permisos correctos y desactivar edición de archivos | ☐ |
| Validación | Escanear de nuevo, revisar logs y solicitar revisión a Google si aplica | ☐ |
Errores comunes al eliminar malware en WordPress
Hay errores que se repiten tanto que parecen tradición. Conviene nombrarlos para no rendirles culto.
- Limpiar solo lo que ve el navegador: muchas infecciones se activan solo para ciertos países, dispositivos o visitantes procedentes de Google.
- Confiar en un único plugin de seguridad: ayuda, pero no sustituye una auditoría.
- No cambiar contraseñas: si las credenciales fueron robadas, el atacante puede volver sin explotar ninguna vulnerabilidad.
- No revisar la base de datos: el malware no siempre vive en archivos.
- Ignorar los logs: allí suele estar la primera pista de entrada.
- Mantener plugins premium nulled: ahorrar en licencias para pagar limpiezas de emergencia es una economía bastante creativa.
- No corregir permisos: especialmente en servidores donde el usuario web puede escribir demasiado.
- No comprobar reinfección: algunos backdoors regeneran archivos al cabo de minutos u horas.
¿Cuándo conviene contratar a un especialista?
Puedes limpiar muchos casos si tienes conocimientos técnicos, acceso al servidor y paciencia. Pero hay situaciones en las que llamar a un profesional no es lujo, sino prudencia:
- El sitio procesa pagos o datos sensibles.
- Hay reinfección después de varias limpiezas.
- El hosting ha suspendido la cuenta.
- Google mantiene la advertencia tras solicitar revisión.
- Hay múltiples sitios infectados en el mismo servidor.
- No tienes acceso a logs o consola.
- El malware afecta al servidor, no solo a WordPress.
Un especialista no solo borra archivos. Reconstruye la historia del ataque: por dónde entró, qué tocó, qué dejó preparado y cómo impedir que vuelva. Esa diferencia importa. Mucho.
Un sitio limpio no es el final: es el principio de una web más seria
Limpiar un sitio WordPress infectado con malware es una mezcla extraña de cirugía, arqueología y trabajo detectivesco. Hay que cortar sin dañar, excavar sin romper y sospechar sin perder la cabeza. En el proceso uno aprende una verdad sencilla: la seguridad no es un plugin, ni una contraseña larga, ni una copia de seguridad aislada. Es un sistema de hábitos.
WordPress, bien mantenido, es una plataforma sólida, flexible y capaz. WordPress abandonado, en cambio, se convierte en una ciudad sin farolas: no necesariamente peligrosa por naturaleza, pero demasiado amable con quien prefiere moverse en la oscuridad.
Si tu sitio ha sido infectado, no lo tomes solo como una catástrofe. Tómalo como una auditoría brutalmente honesta. El malware señala grietas que quizá llevaban años esperando. Limpia, actualiza, endurece, documenta y vigila. La web, como un jardín después de la tormenta, puede volver a florecer. Pero esta vez conviene no olvidar dónde crecía la maleza. 🌿