Arreglar un Sitio WordPress Hackeado: guía de recuperación de emergencia en 9 pasos

Si estás buscando en Google “arreglar un sitio WordPress hackeado”, probablemente estés viendo algo preocupante: redirecciones raras, nuevos usuarios administradores, páginas de spam apareciendo en Google o una advertencia del navegador que destruye la confianza en segundos. Y sí, puedes solucionarlo. Respira: la mayoría de los hackeos de WordPress se pueden recuperar, pero el orden de los pasos importa. El mayor error es pasar directo a borrar archivos o restaurar un respaldo al azar sin antes detener al atacante y conservar lo necesario para diagnosticar por dónde entró.

Esta guía usa un enfoque simple de tres fases: contener → limpiar → reforzar. Primero, vas a contener el daño (modo mantenimiento, bloqueo de accesos y una captura completa) para que el hack no siga propagándose mientras trabajas. Luego, vas a limpiar la infección (eliminar puertas traseras, reemplazar archivos comprometidos, purgar basura inyectada en la base de datos y auditar usuarios) hasta que los escaneos y las revisiones puntuales confirmen que realmente está limpio. Por último, vas a reforzar el sitio (actualizaciones, autenticación fuerte, mínimo privilegio, copias de seguridad y monitoreo) para que la misma vulnerabilidad no te vuelva a pegar la próxima semana y recibas alertas antes que tus clientes.

Antes de empezar, intenta reunir acceso de administrador de WordPress, credenciales de hosting/SFTP, acceso a la base de datos y cualquier respaldo reciente. La mayoría de las limpiezas toman 30–120 minutos, según el alcance. Si te falta algún acceso, no entres en pánico: vamos a indicar alternativas y el punto exacto en el que es más inteligente escalar con tu hosting o un profesional de seguridad. Si tu objetivo es arreglar un sitio WordPress hackeado de forma rápida y segura, comienza por la contención y sigue los pasos en orden.

Señales de que tu sitio WordPress está hackeado

Checklist rápido de síntomas

Si algo se siente “raro”, confía en ese instinto. La mayoría de los compromisos no son dramáticos: son sigilosos. Estas son las señales de alerta más comunes:

• Redirecciones inesperadas (especialmente solo en móvil) a páginas de apuestas, “pharma”, cripto o “premios”
• Un nuevo usuario administrador que no creaste, o tu email/contraseña de admin cambió de repente
• Páginas de spam o URLs extrañas indexadas en Google (a menudo con slugs aleatorios o palabras clave en otros idiomas)
• Advertencias del sitio en Chrome/Safari (“Sitio engañoso,” advertencia de malware)
• Alertas del hosting sobre malware, abuso de recursos o scripts sospechosos
• Caída repentina de SEO o desplome de tráfico que no coincide con la estacionalidad
• Popups/anuncios apareciendo cuando no instalaste un plugin de anuncios
• Sitio lento / picos de CPU (puede ser minería inyectada, tráfico de bots o generación de spam)
• Archivos desconocidos de plugins/temas o archivos core modificados (cambios en wp-includes/wp-admin)
• Correos enviados desde tu dominio (restablecimientos de contraseña que no pediste, quejas por spam)

Una pista grande: el sitio se ve normal para ti, pero los visitantes ven algo distinto. Eso suele significar malware condicional (por dispositivo, ubicación o referidor).

Confirma con Search Console + logs

Ahora valida con evidencia, no con suposiciones.

• Google Search Console: revisa Problemas de seguridad y Acciones manuales. También mira Páginas/Indexación por un salto de URLs “Indexadas” que no reconoces y revisa en Resultados de búsqueda si aparecen palabras clave de spam asociadas a tu dominio.
• Logs de acceso del servidor: busca hits repetidos a wp-login.php, xmlrpc.php, wp-admin/admin-ajax.php o ráfagas raras de POST a endpoints desconocidos.
• Logs de errores: escanea advertencias PHP sospechosas ligadas a archivos desconocidos en /wp-content/uploads/, /mu-plugins/ o directorios nuevos aleatorios.
• Cambios en archivos: si tu hosting entrega listas de “archivos modificados”, revisa qué cambió recientemente—especialmente archivos core y .htaccess.

Si aparecen dos o más señales, trátalo como un compromiso real y pasa a contención de inmediato.

Contén el daño antes de limpiar

Modo mantenimiento / modo seguro

Antes de tocar archivos o ejecutar herramientas de “limpieza”, detén el sangrado. Tu objetivo es evitar que los visitantes (y Googlebot) sean redirigidos o reciban malware mientras trabajas. Pon el sitio en modo mantenimiento o una página simple de “Volvemos pronto”. Si tu hosting lo permite, habilita temporalmente reglas de WAF / cortafuegos o el modo “bajo ataque” para reducir tráfico de bots. Evita cambiar demasiadas cosas a la vez: la contención debe ser rápida, reversible y enfocada en limitar la exposición.

Si el hack está redirigiendo activamente a usuarios, considera restringir el acceso temporalmente por IP (permitir solo tu IP) o proteger el sitio con contraseña a nivel servidor mientras limpias. Esto no es la solución final: es una barrera de seguridad.

Congela el acceso (contraseñas/keys)

Asume que las credenciales están comprometidas. Rota de inmediato lo esencial:

• Contraseñas de admin en WordPress (y fuerza el reset para todos los admins si es posible)
• Panel de control del hosting, SFTP/SSH y contraseñas de la base de datos
• Cualquier credencial de SMTP / email transaccional vinculada a WordPress
• API keys guardadas en plugins (formularios, pagos, analítica, integraciones)

Además, cierra sesión en todas las sesiones, elimina usuarios admin desconocidos y habilita 2FA si está disponible. Si reutilizas contraseñas en algún lado, cámbialas también.

Snapshot/backup para recuperación + evidencia

Ahora toma una captura completa antes de la limpieza: archivos del sitio + base de datos. Esto te protege si un paso rompe el sitio y conserva evidencia para identificar el punto de entrada (para que no te reinfecten). Etiquétalo claramente con fecha/hora. Si puedes, exporta logs alrededor de la ventana sospechosa del compromiso. Esa captura es tu “botón de deshacer” y tu referencia forense: no te la saltes.

Cómo arreglar un sitio WordPress hackeado rápido: el plan de emergencia en 9 pasos

Paso 1 — Detén el sangrado (modo mantenimiento + bloquea tráfico malo obvio)

Saca a los usuarios del peligro de inmediato. Activa modo mantenimiento/seguro y agrega un bloqueo temporal a nivel servidor si hay redirecciones activas (protege con contraseña o permite solo tu IP). Si tienes un WAF/cortafuegos, actívalo ya para reducir el ruido de bots mientras trabajas.

Paso 2 — Asegura el acceso (hosting, WP admin, DB, SFTP/SSH, email)

Rota credenciales en este orden: panel del hosting → SFTP/SSH → usuario de base de datos → admins de WordPress → email/SMTP/API keys. Cierra todas las sesiones y elimina accesos desconocidos. Si puedes, habilita 2FA para cuentas admin antes de seguir.

Paso 3 — Toma una captura limpia (backup completo + anota timestamps)

Crea un backup completo de archivos + base de datos y etiquétalo con la hora exacta. Este es tu punto de retorno si la limpieza rompe algo. También anota cuándo notaste los síntomas por primera vez y cualquier actualización/instalación reciente (esos timestamps importan para el análisis de causa raíz).

Paso 4 — Escanea + identifica el alcance (archivos vs DB vs usuarios)

Ejecuta un escaneo confiable (plugin de seguridad + escáner del hosting si está disponible). No solo busques “malware encontrado”: mapea dónde vive el problema—archivos infectados, contenido inyectado en la base de datos, usuarios sospechosos o redirecciones maliciosas en .htaccess/reglas del servidor.

Paso 5 — Elimina admins/usuarios sospechosos + restablece roles

Audita todos los usuarios buscando nuevos admins, emails cambiados o nombres de usuario raros. Elimina cuentas sospechosas, restablece contraseñas para roles privilegiados y confirma asignaciones de roles (que ningún “Editor” haya sido elevado a “Administrador” en silencio). Revisa también “application passwords” o tokens API ocultos.

Paso 6 — Limpia/reemplaza archivos comprometidos (integridad de core/tema/plugins)

No “edites a mano” archivos core a menos que sea imprescindible: reemplaza el core de WordPress con copias nuevas desde WordPress.org. Reinstala temas/plugins desde fuentes confiables. Elimina cualquier cosa nulled, abandonada o desconocida. Pon atención especial a /wp-content/uploads/, mu-plugins y archivos PHP nuevos raros.

Paso 7 — Limpia inyecciones en base de datos (options, posts, redirecciones)

Busca scripts/links inyectados en wp_options (siteurl/home, opciones autoload), posts/páginas de spam y contenido de widgets. Elimina redirecciones maliciosas, blobs base64 e iframes ocultos. Si se crearon URLs de spam, planea noindex/eliminación y limpiar sitemaps después.

Paso 8 — Cierra puntos de entrada (actualiza, elimina nulled, permisos, keys)

Actualiza WordPress, plugins y temas. Regenera salts/keys en wp-config.php. Arregla permisos (nada con escritura para todos), deshabilita la edición de archivos en wp-admin y bloquea endpoints de alto riesgo si hace falta (por ejemplo, XML-RPC). El objetivo: detener la reinfección.

Paso 9 — Verifica que está limpio + monitorea (reescaneo, logs, uptime, WAF)

Reescanea después de limpiar y confirma que los síntomas desaparecieron (sin redirecciones, sin usuarios sospechosos, sin archivos nuevos apareciendo). Revisa logs de acceso por patrones repetidos, activa monitoreo de uptime + cambios y mantén una línea base de WAF/seguridad corriendo. Si algo reaparece en 24–48 horas, escala a causa raíz (a menudo el hosting o una puerta trasera persistente).

Eliminación de malware (práctico): archivos, base de datos, usuarios y backdoors

Hotspots de limpieza de archivos (uploads, mu-plugins, wp-config, carpetas temporales)

La mayoría del malware en WordPress se esconde donde la gente no mira—o donde se camufla. Empieza por /wp-content/uploads/. Uploads debería contener principalmente imágenes y medios, no PHP. Si encuentras .php, .phtml, archivos .ico raros o carpetas con nombres aleatorios, trátalos como sospechosos. Luego revisa /wp-content/mu-plugins/ (plugins obligatorios). Muchos dueños olvidan que esta carpeta existe, y por eso es un lugar favorito para código persistente.

Después inspecciona wp-config.php y .htaccess (o tu configuración de Nginx). Señales comunes incluyen llamadas include() desconocidas, cadenas largas ofuscadas, reglas de rewrite raras o redirecciones que solo se activan para tráfico móvil o por referidor. También busca archivos nuevos en la raíz de WordPress que no deberían estar ahí (archivos .php aleatorios junto a wp-login.php). Por último, revisa directorios temporales/de caché creados por plugins y el hosting: a veces el malware suelta payloads ahí porque reciben menos atención.

Mejor práctica: reemplaza, no parchees. Reinstala el core de WordPress desde una fuente confiable. Reinstala temas/plugins desde fuentes oficiales o del proveedor. Elimina cualquier cosa “nulled”, abandonada o desconocida. Si un archivo se ve ofuscado y tú no lo pusiste ahí, elimínalo y verifica que nada dependa de él.

Patrones de limpieza en DB (blobs base64, scripts inyectados, opciones sospechosas)

Un sistema de archivos “limpio” puede seguir dejando tu sitio comprometido si la base de datos está inyectada. Enfócate en tres áreas:

1. wp_options: busca valores sospechosos en home, siteurl, active_plugins y entradas grandes con “autoload”. El malware suele guardar payloads en opciones autoload para que se ejecuten en cada carga.
2. wp_posts / wp_postmeta: busca etiquetas <script> inyectadas, iframes ocultos, links salientes de spam o shortcodes raros. Algunas campañas crean cientos de páginas en borrador/privadas.
3. widgets + menús: algunas inyecciones terminan en texto de widgets, bloques de header/footer o elementos de menú.

Señales rojas: blobs codificados en base64, eval(), gzinflate(), str_rot13() o cadenas largas que no coinciden con configuraciones normales. Si tienes duda, compara con un respaldo conocido como limpio o un entorno de pruebas (staging) y elimina las entradas maliciosas.

Detección de backdoors + checks de integridad

Las puertas traseras son la razón por la que los sitios se reinfectan. Después de la limpieza inicial, ejecuta checks de integridad:

• Compara archivos core contra checksums oficiales (o simplemente reemplaza el core completo).
• Usa un escáner de seguridad que detecte archivos core modificados y funciones sospechosas.
• Revisa archivos modificados recientemente por timestamp (que algo cambie después de limpiar es una pista enorme).
• Busca patrones comunes de backdoor en el código: eval, base64_decode, preg_replace con /e, assert, system, shell_exec, passthru.

Si los mismos archivos siguen reapareciendo, detente e investiga el punto de entrada (usuario del hosting comprometido, credenciales robadas, plugin vulnerable o una puerta trasera en mu-plugins). Aquí “limpiar más fuerte” no sirve: necesitas eliminar la fuente de reinfección.

Checklist para arreglar un sitio WordPress hackeado: restaurar + verificar que estás limpio

Restaurar desde un backup conocido como limpio (cuándo es la mejor opción)

Restaurar un respaldo suele ser la vía más rápida—si puedes confirmar que el backup es anterior al compromiso. “Conocido como limpio” significa: sin redirecciones raras en ese momento, sin URLs de spam indexadas, sin cambios sospechosos en admins y, idealmente, con un escaneo limpio de esa captura. Si tu backup es de la semana pasada pero la infección lleva un mes corriendo silenciosamente, restaurar solo trae el malware de vuelta.

Usa restauración cuando:

• Tienes un backup reciente de antes de que empezaran los síntomas
• El hack afectó muchos archivos y la limpieza manual sería un caos
• Puedes parchear de inmediato la vulnerabilidad después de restaurar (actualizaciones, reset de contraseñas, eliminar el plugin/tema vulnerable)

Después de restaurar, igual haz los pasos de refuerzo (credenciales, actualizaciones, keys, WAF). Restaurar sin reforzar es la receta para que te rehackeen el mismo día.

Enfoque de reinstalación limpia (core/temas/plugins desde fuentes confiables)

Si no tienes un backup seguro—o no confías en lo que se modificó—usa un enfoque de reinstalación limpia:

1. Reemplaza el core de WordPress con archivos nuevos desde WordPress.org (no sobrescribas wp-config.php hasta haberlo auditado).
2. Reinstala tu tema desde la fuente oficial o descarga del proveedor (nada de zips “bundled” de sitios raros).
3. Reinstala plugins solo desde el repositorio de WordPress o cuentas del proveedor. Elimina cualquier plugin nulled, abandonado o innecesario.
4. Conserva el media de uploads/, pero elimina cualquier PHP o archivo sospechoso dentro.
5. Resetea salts/keys en wp-config.php y asegúrate de que los permisos de archivos estén correctos.

Este enfoque reduce la posibilidad de que se te escape una puerta trasera, porque estás reconstruyendo con componentes conocidos como limpios en lugar de intentar editar quirúrgicamente cada archivo infectado.

Checklist de verificación (tests de redirección, auditoría de usuarios, diff de archivos, reescaneo)

Antes de sacar el sitio de modo mantenimiento, verifica que realmente está limpio:

• Tests de redirección: revisa home + páginas principales en desktop y móvil, en incógnito y desde otra red. Confirma que no haya redirecciones condicionales.
• Auditoría de usuarios: confirma que solo existan los admins esperados; verifica emails; resetea contraseñas; cierra todas las sesiones.
• File diff / archivos modificados: revisa archivos modificados después de la limpieza—nada debería seguir cambiando sin que tú lo toques.
• Reescaneo: ejecuta tu escaneo de seguridad de nuevo y confirma que no queden alertas críticas.
• Chequeo rápido en Search Console: busca nuevas páginas de spam, acciones manuales o advertencias de seguridad.
• Uptime + monitoreo de cambios: activa monitoreo para enterarte rápido si algo vuelve.

Si algún paso falla (vuelven las redirecciones, reaparecen archivos, aparecen nuevos admins), pausa y pasa al análisis de causa raíz: la reinfección sigue activa.

Recuperación SEO + listas negras (Google, navegadores, hosting)

Elimina URLs de spam + corrige cadenas de redirección

Después de un hack, “estar limpio” no es lo mismo que “volver a ser confiable”. Primero, identifica cualquier URL de spam que el atacante haya creado (a veces cientos). En Google, busca site:yourdomain.com más palabras clave de spam que hayas notado. En WordPress, revisa Páginas/Entradas por contenido basura y escanea tu base de datos por URLs inyectadas. Elimina esas páginas y asegúrate de que devuelvan 410 (Gone) o 404 (mejor que redirigir todo al home). Si usas un plugin SEO, regenera sitemaps después de limpiar para que esas URLs no sigan “publicándose”.

Luego, corrige cadenas de redirección y reglas maliciosas. Revisa .htaccess (o reglas de Nginx) por rewrites raros, especialmente los que redirigen solo en móvil, solo por ciertos referidores o solo cuando visita Googlebot. También revisa JavaScript inyectado que haga redirecciones del lado del cliente. Tu objetivo: cero 301/302 inesperadas, cero cloaking y cero redirecciones “sombra”.

Pasos en Search Console para problemas de seguridad

En Google Search Console, revisa Problemas de seguridad y Acciones manuales. Si hay Problemas de seguridad, Google suele indicar la categoría (malware, páginas engañosas, contenido hackeado). Después de limpiar el sitio y eliminar el contenido hackeado, usa el flujo de solicitar revisión (donde esté disponible) y sé específico: qué limpiaste, qué reemplazaste y qué cambiaste para evitar reinfección (actualizaciones, reset de contraseñas, eliminación del plugin vulnerable, WAF).

Si los navegadores aún advierten a los usuarios (advertencias estilo Chrome/Safe Browsing), confirma que eliminaste el payload exacto que lo disparó y luego sigue el proceso de revisión correspondiente vía Search Console o tu proveedor de hosting/seguridad.

Reindexa + monitorea errores de rastreo

Cuando ya estés limpio y las URLs de spam estén fuera, envía tu sitemap actualizado en Search Console y usa Inspección de URL en páginas clave para solicitar reindexación. Luego monitorea:

• Reportes de Cobertura/Indexación por URLs de spam persistentes
• Errores de rastreo (picos repentinos pueden indicar enlaces malos o recursos bloqueados)
• Consultas en resultados de búsqueda por palabras clave de spam asociadas a tu dominio
• Tendencias de rendimiento (la recuperación puede tardar días o semanas según la gravedad)

Monitorea esto al menos 2–4 semanas: la recuperación SEO suele ser la parte más lenta, pero la meta es ver mejora constante.

Refuerzo + monitoreo para que no vuelva a pasar

2FA + mínimo privilegio

La mayoría de los rehacks ocurren porque el punto de entrada original sigue abierto—normalmente credenciales débiles, demasiados admins o un plugin con más permisos de los necesarios. Empieza habilitando 2FA para cada cuenta administradora (y cualquier cuenta que pueda instalar plugins). Luego reduce el “radio de explosión”:

• Deja cuentas admin al mínimo posible (1–2 admins reales).
• Asigna a todos los demás el rol más bajo que les permita trabajar (Editor ≠ Admin).
• Usa contraseñas únicas y largas con un gestor y evita reutilizarlas entre hosting/WP/email.
• Elimina cuentas sin uso, contratistas antiguos y accesos “por si acaso”.
• Si permites instalaciones de plugins a clientes o staff, detén eso. Haz las instalaciones como un proceso controlado.

También refuerza ajustes que los atacantes abusan: deshabilita edición de archivos en wp-admin (DISALLOW_FILE_EDIT), considera limitar wp-admin por IP (si tu flujo lo permite) y asegúrate de que el usuario de base de datos tenga solo los privilegios necesarios.

Línea base de WAF/plugin de seguridad

Un plugin de seguridad por sí solo no salva un sitio, pero una buena línea base reduce el ruido y detecta ataques comunes. Elige un plugin de seguridad confiable y configura lo esencial:

• Protección de login (limitación de intentos, bloqueos por fuerza bruta, CAPTCHA si aplica)
• Detección de cambios en archivos y monitoreo de integridad del core
• Bloquear ejecución de PHP en uploads (cuando sea posible)
• Escaneos programados + alertas inmediatas ante hallazgos críticos

Combínalo con un WAF (Web Application Firewall) si puedes—ya sea a nivel DNS/CDN o a través del hosting. Un WAF filtra bots, intentos de explotación y patrones maliciosos antes de que lleguen a WordPress. Si operas e-commerce o generación de leads, el WAF suele valer la pena solo por reducción de riesgo.

No olvides lo básico a nivel servidor: permisos correctos (nada con escritura para todos), PHP actualizado y eliminar software/cuentas sin uso en el entorno de hosting.

Backups + alertas + disciplina de actualizaciones

Tu mejor defensa es poder recuperarte rápido—y enterarte temprano cuando algo va mal. Configura:

• Backups automáticos (DB diaria + backup completo diario/semanal, retención 30–90 días)
• Almacenamiento off-site (no solo en el mismo servidor)
• Un proceso de restauración probado (practícalo una vez—en serio)

Luego agrega alertas que detecten problemas antes que tus clientes:

• Monitoreo de uptime (hace ping al sitio y alerta si cae)
• Alertas de seguridad (nuevo admin creado, cambios en archivos, malware detectado)
• Monitoreo de rendimiento (picos repentinos de CPU pueden indicar abuso)

Por último, adopta disciplina de actualizaciones: mantén WordPress core, plugins, temas y PHP al día. Elimina plugins que no necesitas. Evita descargas “free premium”/nulled por completo. Si tratas actualizaciones y monitoreo como mantenimiento rutinario—y no como reacción de pánico—reduces muchísimo la probabilidad de volver a estar aquí.

Si vuelve a aparecer: análisis de causa raíz

Backdoors persistentes

Si el malware vuelve después de que “limpiaste todo”, asume que todavía existe una puerta trasera o que tus credenciales siguen comprometidas. Los culpables más comunes son archivos PHP ocultos en uploads/, código malicioso en mu-plugins o payloads guardados en la base de datos (a menudo en opciones autoload). Observa este patrón: limpias, todo está bien unas horas, luego vuelven redirecciones o spam—y los timestamps de “archivos modificados” se actualizan sin que tú toques nada. Eso no es mala suerte: es persistencia.

En este punto, deja de hacer ediciones aleatorias. Revisa de nuevo patrones de código ofuscado (eval, base64_decode, gzinflate, preg_replace sospechoso) y rastrea qué archivos cambian después de la limpieza. El archivo que reaparece normalmente está siendo regenerado por otro script oculto.

Señales de compromiso en el hosting

A veces WordPress no es el problema principal: lo es tu usuario de servidor o el entorno de hosting. Señales rojas: varios sitios en la misma cuenta infectándose, cron jobs desconocidos, logins SSH/SFTP no autorizados, nuevos usuarios del sistema o malware que regresa inmediatamente después de una reinstalación limpia. Si estás en hosting compartido, puede haber contaminación cruzada. Pídele al hosting: historial reciente de logins, reportes de escaneo, procesos sospechosos y si pueden aislar/cuarentenar la cuenta.

Cuándo reconstruir vs reparar

Reparar tiene sentido cuando el alcance es limitado y puedes identificar el punto de entrada. Reconstruir es más inteligente cuando: no puedes confiar en el código, la reinfección persiste, el hosting no puede aislar de forma limpia o el sitio ha sido hackeado varias veces. Una reconstrucción limpia suele ser WordPress nuevo + tema/plugins desde fuentes confiables, migrando solo contenido/media verificado, rotando todas las credenciales y, si hace falta, moviéndote a un hosting más seguro. Cuando el tiempo y la confianza están en juego, reconstruir suele ser la forma más rápida de lograr un “arreglo real”.

Puedes recuperarte de un WordPress hackeado sin adivinar: sigue el mismo modelo de tres fases siempre: contener → limpiar → reforzar. La contención detiene el daño y protege a los visitantes. La limpieza elimina malware, usuarios sospechosos y basura inyectada en la base de datos. El refuerzo cierra la puerta para que la misma vulnerabilidad no te golpee mañana.

Tu siguiente paso es simple: completa el checklist de verificación y mantén el monitoreo activo al menos algunas semanas. Si quieres ayuda práctica, enlaza a tu página interna de soporte (agrega aquí tu enlace interno de “Soporte y troubleshooting de WordPress”) para que un experto revise el sitio rápidamente.

Si estás atascado, ves reinfección o estás lidiando con problemas a nivel hosting, escala: contacta a tu hosting para aislamiento/logs o trae a un especialista en seguridad WordPress para terminar la limpieza de forma segura.