Tener un WordPress hackeado significa que una persona o proceso no autorizado consiguió modificar, utilizar o controlar alguna parte de la página, sus archivos, base de datos, cuentas o infraestructura.

La infección puede manifestarse mediante redirecciones hacia páginas extrañas, administradores desconocidos, contenido spam en Google, archivos modificados, correos enviados sin autorización, publicidad inesperada, caídas o un consumo inusual de recursos.

WordPress señala como indicadores claros de compromiso las modificaciones no autorizadas, nuevos usuarios, alertas de malware, bloqueos del hosting o advertencias de buscadores. También recomienda documentar el incidente antes de empezar a modificar la instalación.

El objetivo no es encontrar un archivo sospechoso y borrarlo. Para eliminar malware de WordPress correctamente necesitamos contener el incidente, conservar evidencias, detectar mecanismos de persistencia, identificar cómo entró el atacante y cerrar esa vulnerabilidad antes de devolver la página a producción.

Si tu página procesa pagos, almacena datos personales, maneja información sensible o ha sufrido una intrusión importante, evita continuar realizando cambios sin documentarlos. Conserva una copia del sitio comprometido y considera solicitar asistencia especializada. Dependiendo de los datos afectados y la jurisdicción, también pueden existir obligaciones legales relacionadas con el incidente.

Esta guía ofrece un procedimiento técnico general. No sustituye un análisis forense, asesoría jurídica, una respuesta profesional a incidentes ni la investigación que pueda realizar el proveedor de hosting.

Cómo saber si WordPress fue hackeado

Un solo síntoma no identifica necesariamente la vulnerabilidad original. Sin embargo, varios de ellos justifican una revisión inmediata.

Síntoma	Posible problema	Prioridad
Redirecciones hacia otros sitios	JavaScript, PHP o reglas inyectadas	Crítica
Administradores desconocidos	Cuenta o credenciales comprometidas	Crítica
Google muestra casino, medicamentos o contenido extraño	SEO spam	Alta
Chrome presenta una advertencia	Malware, phishing o ingeniería social	Crítica
Archivos desconocidos o modificados	Malware o posible persistencia	Crítica
WordPress envía correos extraños	Abuso de correo o cuenta comprometida	Alta
La infección reaparece después de limpiar	Persistencia o vulnerabilidad activa	Crítica
CPU o recursos se disparan	Malware, bots o procesos anómalos	Alta
Plugins aparecen modificados	Código alterado o instalación comprometida	Alta
Search Console muestra Security Issues	Google detectó contenido comprometido o peligroso	Crítica

WordPress recomienda utilizar los síntomas como indicadores de compromiso y combinar diferentes métodos de análisis, ya que ningún escáner cubre todos los escenarios. También aconseja revisar el computador desde el cual se administra la página, porque credenciales de WordPress, SFTP o panel de hosting pueden ser robadas fuera del servidor.

Google puede mostrar advertencias cuando detecta malware, contenido engañoso o páginas comprometidas. El informe Security Issues de Search Console permite identificar problemas detectados sobre el sitio.

Qué hacer inmediatamente si detectas una infección

Antes de limpiar, evita tomar decisiones que eliminen evidencia útil.

No conviene:

• Borrar archivos sospechosos al azar.
• Actualizar todos los componentes antes de documentar el estado.
• Restaurar inmediatamente una copia.
• Cambiar cinco configuraciones simultáneamente.
• Eliminar los logs.
• Solicitar de inmediato una revisión de Google.

En cambio:

1. Registra cuándo notaste el problema.
2. Guarda capturas.
3. Documenta los últimos cambios realizados.
4. Revisa notificaciones del hosting.
5. Comprueba Search Console.
6. Identifica si los visitantes continúan expuestos.
7. Conserva registros y archivos.
8. Contacta al hosting si sospechas un compromiso del servidor.

La documentación oficial de WordPress recomienda explícitamente documentar síntomas, horarios y cambios recientes antes de comenzar la reparación. También aconseja tomar una nueva copia del entorno comprometido antes de avanzar con la limpieza.

WordPress hackeado: 11 pasos efectivos para eliminar malware

1. Contén el incidente y protege a los visitantes

Objetivo: impedir que la página continúe distribuyendo contenido malicioso, capturando datos o afectando clientes.

Si detectas malware, phishing, formularios manipulados o redirecciones, evalúa:

• Activar temporalmente mantenimiento.
• Restringir el acceso público.
• Pausar el checkout.
• Deshabilitar formularios comprometidos.
• Detener temporalmente una integración afectada.
• Solicitar al hosting que aísle la cuenta.

Una página de mantenimiento no es suficiente si el código malicioso continúa ejecutándose en segundo plano. Cuando existe distribución activa de malware, el aislamiento a nivel de servidor puede ser necesario.

Google utiliza advertencias de seguridad para proteger a los visitantes frente a malware o ingeniería social. Si detecta una amenaza, puede advertir al usuario antes de acceder a la página.

Riesgo: medio, porque determinadas medidas pueden detener ventas o formularios.

Cómo comprobarlo: verifica desde otro navegador y una conexión distinta que los visitantes ya no puedan acceder al contenido comprometido.

Cuándo pedir ayuda: cuando no puedas aislar la página sin afectar otros sitios o cuando la cuenta completa de hosting parezca comprometida.

2. Crea una copia completa del sitio comprometido

Objetivo: conservar evidencia y una referencia del incidente antes de modificar la instalación.

Guarda:

• Todos los archivos.
• Base de datos.
• Logs.
• .htaccess.
• wp-config.php.
• Plugins.
• Temas.
• MU Plugins.
• Lista de usuarios.
• Versiones.
• Fecha y hora.
• Capturas.
• Alertas del hosting.
• Avisos de Search Console.

Etiqueta claramente esta copia como COMPROMETIDA / NO RESTAURAR EN PRODUCCIÓN.

Su función es permitir comparar archivos, recuperar contenido legítimo y analizar qué ocurrió. No debe confundirse con una copia limpia.

WordPress indica que un respaldo completo requiere tanto archivos como base de datos y recomienda conservar varias copias en ubicaciones diferentes. En su guía para sitios hackeados también aconseja tomar una instantánea del entorno aunque esté infectado antes de comenzar la limpieza.

Riesgo: bajo si el respaldo se almacena aislado.

Cómo comprobarlo: verifica que puedas abrir el archivo de respaldo y que la exportación de la base de datos exista.

Cuándo pedir ayuda: si el sitio es muy grande, la base de datos falla o el hosting no permite crear la copia.

3. Identifica el alcance y revisa todos los accesos

Objetivo: conocer qué cuentas y sistemas pudieron utilizarse durante el ataque.

Revisa:

• Administradores de WordPress.
• Usuarios creados recientemente.
• Panel del hosting.
• SFTP.
• SSH.
• Base de datos.
• CDN o Cloudflare.
• Search Console.
• Cuentas de correo.
• API keys.
• Contraseñas de aplicación.
• SMTP.
• Pasarelas de pago.
• Integraciones externas.

Revoca inmediatamente un acceso claramente ajeno, pero no elimines una cuenta hasta confirmar quién la utiliza.

WordPress recomienda revisar todos los puntos de acceso, no solamente la contraseña de wp-admin. La guía oficial menciona WordPress, FTP/SFTP, panel de hosting y base de datos como accesos que deben protegerse tras una intrusión.

Las Application Passwords de WordPress también deben revisarse. WordPress permite ver cuáles existen, cuándo se utilizaron y revocarlas individualmente; recomienda rotarlas después de una posible filtración.

Inventario de accesos

Sistema	Usuario o integración	¿Es legítimo?	Último uso	Acción
WordPress	Administrador	Sí / No	Fecha	Mantener / revocar
Hosting	Usuario	Sí / No	Fecha	Revisar
SFTP	Cuenta	Sí / No	Fecha	Rotar
SSH	Usuario / clave	Sí / No	Fecha	Rotar
Base de datos	Usuario	Sí / No	Fecha	Revisar
API	Integración	Sí / No	Fecha	Revocar / renovar
Application Password	Aplicación	Sí / No	Fecha / IP	Revocar
CDN	Usuario	Sí / No	Fecha	Rotar

4. Escanea archivos, base de datos, logs y computadores

Objetivo: identificar qué partes del entorno fueron modificadas y buscar pistas sobre el punto de entrada.

No dependas de un único escáner.

WordPress recomienda combinar escáneres de aplicación y análisis externos porque cada enfoque detecta problemas diferentes. También recomienda analizar los computadores de administración, ya que malware local puede capturar accesos a WordPress o SFTP.

Archivos

Revisa especialmente:

• WordPress Core.
• wp-content/plugins.
• wp-content/themes.
• wp-content/mu-plugins.
• wp-content/uploads.
• wp-config.php.
• .htaccess.
• index.php.
• Archivos modificados recientemente.

Base de datos

Busca anomalías como:

• Administradores desconocidos.
• Contenido spam.
• URLs externas inesperadas.
• JavaScript o iframes que no corresponden.
• Opciones modificadas.
• Widgets alterados.
• Tareas desconocidas.

No elimines datos simplemente porque contienen código. Muchos plugins legítimos almacenan HTML, scripts o configuraciones en la base de datos.

Registros

Consulta:

• Access logs.
• PHP logs.
• SFTP/SSH.
• Firewall.
• WAF.
• Panel del hosting.
• Solicitudes POST.
• Errores recientes.

Equipos locales

Escanea los computadores desde los que se administró la web y actualiza sistema operativo, navegador y herramientas utilizadas. WordPress advierte que un dispositivo con malware o keylogger puede comprometer de nuevo las credenciales aunque el servidor esté limpio.

Riesgo: bajo durante análisis, alto si comienzas a borrar sin verificar.

Cómo comprobarlo: crea un inventario de archivos, usuarios y eventos sospechosos antes de modificar nada.

5. Verifica y reemplaza los archivos del núcleo

Objetivo: comprobar si los archivos oficiales de WordPress fueron alterados.

Si tienes WP-CLI y experiencia técnica, puedes utilizar:

wp core verify-checksums

El comando compara los archivos instalados con los checksums publicados por WordPress.org para esa versión. Funciona antes de cargar WordPress, lo que es especialmente útil durante un diagnóstico.

El resultado puede señalar archivos oficiales modificados, pero no verifica todo wp-content ni demuestra que la instalación completa esté libre de malware.

Si necesitas reemplazar Core:

1. Descarga WordPress únicamente desde WordPress.org.
2. Utiliza la versión apropiada.
3. Sustituye archivos oficiales.
4. Conserva y revisa wp-config.php.
5. Conserva wp-content para analizarlo por separado.

La guía de WordPress para sitios hackeados destaca que wp-admin y wp-includes pueden reemplazarse con copias oficiales durante la recuperación.

Riesgo: medio.

Cuándo pedir ayuda: si utilizas una instalación modificada, Multisite o no puedes determinar qué versión corresponde.

6. Reinstala plugins y temas desde fuentes confiables

Objetivo: reemplazar componentes alterados por versiones originales.

Revisa:

• Plugins modificados.
• Plugins abandonados.
• Componentes no utilizados.
• Plugins o temas nulled.
• Temas inactivos.
• Código personalizado.

Cuando sea posible:

1. Documenta la versión actual.
2. Descarga una copia limpia desde la fuente oficial.
3. Compara personalizaciones.
4. Reinstala el componente.
5. Elimina copias desconocidas.
6. Conserva solo lo que realmente utiliza la página.

WordPress recomienda descargar Core, temas y plugins únicamente de fuentes confiables y mantenerlos actualizados. La guía de hardening advierte específicamente contra componentes obtenidos de fuentes desconocidas.

Para plugins alojados en WordPress.org, WP-CLI permite comprobar checksums:

wp plugin verify-checksums --all

La herramienta compara los archivos contra los checksums de WordPress.org. Los plugins premium o personalizados pueden no disponer de esta referencia pública.

Riesgo: medio.

Evita: borrar un plugin personalizado antes de confirmar qué funcionalidad aporta.

7. Busca persistencia y limpia la base de datos

Objetivo: impedir que el atacante recupere acceso después de borrar el malware visible.

Una backdoor es un mecanismo oculto que permite volver a acceder al sistema posteriormente. Puede estar ubicada en más lugares que el archivo inicialmente detectado.

Revisa:

• MU Plugins.
• Archivos inesperados dentro de uploads.
• Cron y tareas programadas.
• .htaccess.
• wp-config.php.
• Administradores.
• Opciones de WordPress.
• Widgets.
• Entradas y páginas.
• JavaScript inyectado.
• Caché.
• Plugins aparentemente legítimos.
• Base de datos.

No asumas que todo archivo PHP encontrado dentro de una carpeta poco habitual es automáticamente malicioso. Algunos sistemas almacenan archivos legítimos fuera de las rutas más comunes.

La propia documentación de WP-CLI muestra que los MU Plugins continúan cargándose incluso cuando se utiliza la opción para omitir plugins convencionales, por lo que deben revisarse expresamente durante un diagnóstico.

No ejecutes consultas SQL encontradas en Internet sin comprender qué tablas o datos modificarán.

Riesgo: alto.

Cómo comprobarlo: después de eliminar el componente identificado, monitoriza si reaparece el mismo archivo, usuario, tarea o modificación.

8. Corrige la vulnerabilidad que permitió el ataque

Objetivo: cerrar la puerta utilizada durante la intrusión.

Si solo eliminas el malware, pero mantienes el mismo punto de entrada, la reinfección puede ser inmediata.

Posibles causas:

• WordPress desactualizado.
• Plugin vulnerable.
• Tema vulnerable.
• PHP obsoleto.
• Software nulled.
• Contraseña reutilizada.
• Credencial robada.
• Código personalizado inseguro.
• Permisos excesivos.
• Usuario administrativo innecesario.
• Equipo local comprometido.
• Otro sitio infectado dentro del mismo hosting.

WordPress considera la seguridad como reducción de riesgo, no como eliminación absoluta del riesgo. Recomienda actualizar Core, utilizar software confiable, revisar la seguridad del servidor y limitar los puntos de acceso.

Procedimiento:

1. Identifica los cambios o accesos previos al incidente.
2. Actualiza WordPress después de preservar evidencia.
3. Actualiza plugins y temas.
4. Elimina software abandonado o no utilizado.
5. Revisa PHP y servidor.
6. Corrige permisos.
7. Revisa otros sitios alojados en la misma cuenta.
8. Consulta los registros del hosting.
9. Revisa código propio o integraciones.

No basta con “actualizar todo” sin investigar primero. La actualización puede cerrar una vulnerabilidad, pero también puede destruir información que ayudaba a identificar el punto de entrada.

Riesgo: alto si se modifica producción sin pruebas.

9. Rota todas las credenciales y secretos

Objetivo: invalidar accesos que pudieron ser robados.

Una vez eliminados los mecanismos de persistencia y corregida la vulnerabilidad, cambia:

• Administradores de WordPress.
• Panel de hosting.
• SFTP.
• SSH.
• Usuario y contraseña de base de datos.
• Correos.
• CDN.
• SMTP.
• API keys.
• Contraseñas de aplicación.
• Integraciones.
• Credenciales de pago potencialmente expuestas.

Las contraseñas deben ser largas, únicas y no reutilizadas. WordPress recomienda proteger todos los accesos, no únicamente wp-admin.

También debes invalidar sesiones activas. La guía oficial de recuperación recomienda renovar las claves secretas de WordPress para expulsar sesiones existentes y volver a cambiar las contraseñas después de completar la limpieza.

Revisa y revoca Application Passwords desconocidas o innecesarias. WordPress recomienda una credencial diferente por integración y rotarlas cuando existe sospecha de filtración.

Habilita autenticación multifactor para administradores y cuentas privilegiadas. WordPress no incluye actualmente 2FA en Core, pero recomienda implementarlo mediante una solución confiable.

Cambiar contraseñas mientras una backdoor continúa activa puede no servir: el atacante podría obtener nuevamente las credenciales.

10. Refuerza WordPress para reducir el riesgo de reinfección

Objetivo: mejorar la postura de seguridad después de recuperar el control.

Mantén actualizado el software

Actualiza:

• WordPress.
• Plugins.
• Temas.
• PHP.
• Componentes del servidor.

WordPress advierte que mantener versiones antiguas aumenta la exposición frente a vulnerabilidades conocidas.

Aplica mínimo privilegio

No todos los usuarios necesitan ser administradores.

Reduce cuentas privilegiadas y asigna únicamente los permisos necesarios para cada función.

Refuerza la autenticación

Utiliza:

• Contraseñas únicas.
• Gestor de contraseñas.
• MFA.
• Rate limiting.
• WAF cuando corresponda.

WordPress recomienda 2FA para administradores y controles frente a ataques automatizados, preferiblemente en el servidor, CDN o WAF cuando sea posible.

Revisa permisos

No utilices permisos 777 como solución general.

WordPress recomienda restringir la escritura tanto como permita la instalación y mantener plugin, Core y archivos administrativos bajo el propietario apropiado.

Evalúa desactivar el editor interno

WordPress permite desactivar desde wp-config.php la edición de archivos PHP en el escritorio:

define( 'DISALLOW_FILE_EDIT', true );

Esta configuración elimina las capacidades para editar archivos de plugins y temas desde el panel. Debe implementarse con respaldo y según el flujo de mantenimiento del sitio.

Mejora los respaldos

Mantén archivos y base de datos, varias versiones y copias en ubicaciones diferentes. WordPress recomienda tratar archivos y base de datos como un mismo conjunto de recuperación y verificar periódicamente que el sistema de respaldo funciona.

Monitoriza

Revisa:

• Logs.
• Cambios de archivos.
• Usuarios.
• Accesos fallidos.
• Disponibilidad.
• WAF.
• Consumo de recursos.
• Search Console.

11. Recupera Google y monitoriza posibles reinfecciones

Objetivo: recuperar la visibilidad y comprobar que el sitio continúa limpio después de volver a producción.

Revisa Search Console

Comprueba:

• Security Issues.
• Manual Actions.
• Indexación.
• Sitemap.
• URLs desconocidas.
• Páginas spam.
• Cambios inesperados.

Google clasifica como contenido hackeado aquel que fue colocado en una página sin autorización debido a vulnerabilidades de seguridad. También puede mostrar advertencias a los visitantes cuando identifica malware o contenido engañoso.

Gestiona las URLs creadas por el atacante

Las páginas de spam que no tienen reemplazo deberían devolver un estado apropiado, como 404 o 410.

No redirijas automáticamente miles de URLs de casino, medicamentos o spam hacia el inicio. Una redirección solamente tiene sentido cuando existe una página legítima equivalente.

Solicita revisión después de terminar

Si Search Console mantiene un aviso de seguridad, primero limpia completamente el sitio y corrige la vulnerabilidad. Después solicita una revisión desde el informe de Security Issues. Google indica que, una vez corregido el problema, puede solicitarse la revisión desde ese informe.

No la solicites mientras la infección continúe activa.

Monitoriza durante las semanas posteriores

Revisa:

• Archivos modificados.
• Nuevos administradores.
• CPU.
• Logs.
• WAF.
• Redirecciones.
• URLs indexadas.
• Search Console.
• Correos.
• Tareas programadas.

Una reinfección rápida es una fuerte señal de que quedó algún mecanismo de persistencia, una credencial comprometida o el punto de entrada continúa activo.

Archivos y ubicaciones que conviene revisar

Ubicación	Qué buscar	Precaución
WordPress Core	Modificaciones frente a archivos oficiales	Utilizar checksums cuando corresponda
wp-content/plugins	Plugins modificados o desconocidos	Reinstalar desde fuente confiable
wp-content/themes	Código inesperado	Conservar personalizaciones legítimas
wp-content/mu-plugins	Código cargado automáticamente	Revisarlo expresamente
wp-content/uploads	Ejecutables o archivos inesperados	No eliminar medios legítimos
wp-config.php	Código o configuración desconocida	Archivo crítico con secretos
.htaccess	Redirecciones o reglas extrañas	Crear copia antes
Base de datos	Scripts, spam, usuarios u opciones	Respaldar antes de modificar
Cron	Tareas que no corresponden	Confirmar funciones legítimas
Caché	Copias de contenido inyectado	No confundir caché con origen

La existencia de PHP, JavaScript u otro código en una ubicación concreta no demuestra automáticamente que sea malware. El contexto y las diferencias frente a versiones legítimas son fundamentales.

Causas frecuentes de un WordPress hackeado

Una infección puede comenzar por múltiples vías:

• Plugins vulnerables.
• Temas desactualizados.
• WordPress antiguo.
• Software nulled.
• Contraseñas débiles.
• Contraseñas reutilizadas.
• Equipos locales comprometidos.
• Permisos demasiado amplios.
• Código personalizado vulnerable.
• Credenciales expuestas.
• Usuarios administrativos innecesarios.
• Integraciones comprometidas.
• Otro sitio infectado dentro del mismo servidor.

WordPress recalca que la seguridad depende tanto de la aplicación como del hosting, los equipos de administración, la red y los controles de acceso. También advierte que un sitio dentro de un entorno compartido puede representar un riesgo para otros sitios si existe una brecha de aislamiento.

Conocer la causa es indispensable. Sin ella, limpiar puede convertirse en un ciclo de borrar archivos cada lunes y volver a encontrarlos el martes.

Qué NO hacer con un sitio comprometido

Borrar archivos aleatoriamente: puedes eliminar código legítimo o destruir evidencia.

Restaurar y olvidarse del incidente: la vulnerabilidad puede continuar activa.

Cambiar solamente la contraseña de WordPress: existen otros accesos, credenciales y mecanismos de persistencia.

Instalar varios plugins de seguridad: incrementa complejidad y no sustituye un diagnóstico.

Utilizar plugins o temas nulled: introduce software de procedencia no confiable, contrario a las recomendaciones de WordPress sobre fuentes seguras.

Aplicar permisos 777: amplía innecesariamente el acceso de escritura. WordPress recomienda limitar permisos al mínimo necesario.

Mantener PHP o componentes obsoletos: aumenta exposición a problemas conocidos.

Limpiar solamente la portada: la persistencia puede estar en plugins, base de datos, MU Plugins o tareas.

Ignorar el equipo del administrador: WordPress advierte que malware local puede robar accesos.

Solicitar revisión a Google inmediatamente: primero debe corregirse el problema.

Eliminar logs: pueden ser esenciales para reconstruir el incidente.

Publicar logs completos: pueden contener rutas, usuarios, direcciones IP y otros datos sensibles.

Confiar en un único escáner: WordPress recomienda combinar métodos de análisis.

Volver a producción demasiado pronto: dificulta saber si la limpieza realmente funcionó.

Cómo saber si la limpieza fue efectiva

Utiliza este checklist antes de dar el incidente por cerrado:

• Ya no existen redirecciones inesperadas.
• No aparecen administradores desconocidos.
• Los archivos de Core pasan las verificaciones aplicables.
• Plugins y temas proceden de fuentes confiables.
• Se revisaron MU Plugins.
• No se detectan tareas programadas desconocidas.
• No reaparecen archivos eliminados.
• Se revisó la base de datos.
• Los logs no muestran el mismo acceso anómalo.
• Search Console no detecta nuevas páginas comprometidas.
• Se corrigió el punto de entrada.
• Se rotaron credenciales y secretos.
• Se cerraron sesiones antiguas.
• MFA está activo para administradores.
• Los respaldos están funcionando.
• Se probó el sitio desde otro dispositivo.
• Se monitoriza el entorno después de la recuperación.

Un checksum correcto o un escáner que no detecta nada es una señal positiva, no una garantía absoluta de ausencia de malware. Los checksums de Core comprueban únicamente los archivos oficiales correspondientes y los de plugins dependen de que exista una referencia en WordPress.org.

Cómo afecta un hackeo al SEO

Un sitio comprometido puede generar:

• Páginas de casino.
• Spam farmacéutico.
• Spam japonés.
• Títulos manipulados.
• Redirecciones.
• URLs desconocidas indexadas.
• Enlaces salientes maliciosos.
• Contenido oculto.
• Advertencias del navegador.
• Caídas de tráfico.

Google identifica como spam el contenido introducido mediante un compromiso de seguridad y puede mostrar advertencias cuando detecta malware o contenido de ingeniería social.

La recuperación orgánica puede requerir tiempo porque Google necesita volver a rastrear y procesar el sitio. No existe un plazo fijo.

Después de limpiar:

1. Revisa Security Issues.
2. Comprueba Manual Actions.
3. Examina el sitemap.
4. Identifica URLs spam.
5. Asegúrate de que desaparecieron.
6. Solicita revisión cuando corresponda.
7. Monitoriza impresiones y clics.

¿Debo restaurar una copia de seguridad?

Una restauración puede ser útil, pero no debe hacerse automáticamente.

Puede ser apropiada cuando:

• Existe un backup anterior al ataque.
• Sabes aproximadamente cuándo comenzó el compromiso.
• El respaldo ha sido revisado.
• Ya corregiste la vulnerabilidad.
• Ya rotaste los accesos necesarios.

No restaures a ciegas cuando:

• No conoces la fecha del ataque.
• La copia podría estar infectada.
• El mismo plugin vulnerable seguirá activo.
• Las credenciales comprometidas continúan funcionando.
• Perderías pedidos o información reciente.

WordPress recomienda respaldar archivos y base de datos y conservar múltiples versiones. Durante una recuperación también aconseja guardar una copia del entorno comprometido para futuras comparaciones.

En una tienda o sistema activo puede ser necesario restaurar una base antigua y recuperar de forma controlada pedidos o datos legítimos posteriores.

Cuándo contactar al hosting

Pide ayuda al proveedor cuando:

• Varias webs de la misma cuenta están afectadas.
• La cuenta fue suspendida.
• No tienes acceso a registros.
• Existen procesos extraños a nivel de servidor.
• CPU o memoria se disparan.
• Hay cambios de propietarios o permisos.
• El malware reaparece después de limpiar.
• Necesitas restaurar una copia del servidor.
• Existen bloqueos de seguridad.
• Debes revisar accesos SFTP o SSH.

WordPress recomienda consultar al hosting especialmente cuando se utiliza alojamiento compartido, ya que el incidente puede afectar o estar relacionado con más de una instalación.

Cuándo solicitar soporte profesional

La asistencia especializada es recomendable cuando:

• Existe WooCommerce o pagos.
• Se almacenan datos de clientes.
• La web genera leads.
• Google marcó el sitio.
• Hay malware persistente.
• Existen posibles backdoors.
• Varias páginas del servidor están afectadas.
• La base de datos fue manipulada.
• No existe un respaldo confiable.
• Hay código personalizado.
• Se sospecha robo de credenciales.
• La empresa necesita reducir el tiempo de indisponibilidad.

En estos escenarios el costo de seguir probando cambios al azar puede superar rápidamente el costo de diagnosticar correctamente el incidente.

Una página profesional también necesita una estrategia de seguridad

La seguridad de una página empresarial no depende únicamente de instalar WordPress o un plugin de protección.

También requiere:

• Hosting confiable.
• SSL.
• Actualizaciones.
• Backups.
• Control de accesos.
• Monitorización.
• Rendimiento.
• Search Console.
• Analytics.
• Administración adecuada.
• Soporte técnico.

En Codwelt desarrollamos diseño de páginas web profesionales administrables con WordPress y Elementor.

Los planes publicados actualmente pueden incluir, según el alcance, hosting avanzado, dominio y SSL, diseño adaptado a móviles, optimización de rendimiento, seguridad, Google Analytics, Google Search Console, WhatsApp, blog, SEO apoyado por IA y capacitación. Codwelt también publica soporte técnico durante un año cuando la página se mantiene bajo su infraestructura, sujeto a las condiciones del servicio.

Una infraestructura profesional no vuelve una web invulnerable. WordPress recuerda que la seguridad consiste en reducir riesgo, no eliminarlo por completo. Una buena infraestructura sí facilita prevenir incidentes, mantener respaldos y responder con mayor control cuando aparece un problema.

Solicita tu página web con una infraestructura profesional, segura y preparada para crecer.

Preguntas frecuentes

Conclusión

Cuando encontramos un WordPress hackeado, el proceso correcto debe seguir once etapas:

1. Contener el incidente.
2. Preservar evidencia.
3. Revisar accesos.
4. Analizar archivos, base de datos y registros.
5. Verificar WordPress Core.
6. Reinstalar plugins y temas.
7. Eliminar mecanismos de persistencia.
8. Corregir la vulnerabilidad.
9. Rotar credenciales.
10. Reforzar la seguridad.
11. Recuperar Google y monitorizar.

El objetivo no es solamente borrar el malware visible. Para eliminar malware de WordPress de forma responsable también debemos impedir que el atacante conserve acceso y corregir la causa que permitió el compromiso.

Protege tu presencia digital y evita que un incidente paralice tu negocio. Cotiza tu página web o soporte WordPress con Codwelt.

Fuentes

Codwelt

Codwelt — Diseño de páginas web profesionales
https://codwelt.com/diseno-de-paginas-web-desarrollo-de-sitios-web/

WordPress

WordPress — Mi sitio fue hackeado
https://wordpress.org/documentation/article/faq-my-site-was-hacked/

WordPress — Hardening WordPress
https://developer.wordpress.org/advanced-administration/security/hardening/

WordPress — Seguridad
https://developer.wordpress.org/advanced-administration/security/

WordPress — Backups
https://developer.wordpress.org/advanced-administration/security/backup/

WordPress — Permisos de archivos
https://developer.wordpress.org/advanced-administration/server/file-permissions/

WordPress — Autenticación multifactor
https://developer.wordpress.org/advanced-administration/security/mfa/

WordPress — Protección contra ataques de fuerza bruta
https://developer.wordpress.org/advanced-administration/security/brute-force/

WordPress — Application Passwords
https://developer.wordpress.org/advanced-administration/security/application-passwords/

WordPress — wp-config.php
https://developer.wordpress.org/advanced-administration/wordpress/wp-config/

WP-CLI — Verificar archivos de WordPress Core
https://developer.wordpress.org/cli/commands/core/verify-checksums/

WP-CLI — Verificar checksums de plugins
https://developer.wordpress.org/cli/commands/plugin/verify-checksums/

Google

Google Search Console — Security Issues
https://support.google.com/webmasters/answer/9044101

Google Search Central — Malware and unwanted software
https://developers.google.com/search/docs/monitor-debug/security/malware

Google Search Central — Prevenir infecciones por malware
https://developers.google.com/search/docs/monitor-debug/security/prevent-malware

Google Search Central — Social engineering y phishing
https://developers.google.com/search/docs/monitor-debug/security/social-engineering

Google Search Central — Políticas de spam y contenido hackeado
https://developers.google.com/search/docs/essentials/spam-policies

Fecha de consulta de las fuentes: 10 de agosto de 2026.