Sitio web hackeado: qué hacer las primeras 24 horas

Si tu página web fue hackeada considero que lo que hagas en las primeras 24 horas pesa mucho más que la herramienta que uses después. El orden que yo sigo es este: confirmar que de verdad es un hackeo, aislar el sitio, sacar una copia tal como está (con el malware adentro), cambiar las claves desde un equipo limpio y recién ahí decidir si se restaura un respaldo sano o se limpia. En el medio hay cosas que en mi opinión no conviene tocar y la principal es ponerse a borrar archivos sospechosos a mano, eso potencialmente puede tapar el rastro de por dónde entraron y muchas veces no saca todo dado que las técnicas para inyectar archivos maliciosos y donde se esconden estos varían cada día.

Uso WordPress de ejemplo, pero el orden sirve para casi cualquier página web.

Qué hacer con un sitio web hackeado, en orden

Anota qué ves, a qué hora lo notaste y qué cambió hace poco. Si eres una persona técnica, asegúrate de agregar detalles de cambios en desarrollo / actualizaciones.
No borres archivos, no desinstales plugins y no restaures nada todavía.
Aísla el sitio (modo mantenimiento o bloqueo desde el hosting) y avísale al hosting.
Saca o pídele al hosting una copia completa del sitio tal como está, con los registros de acceso.
Con la copia guardada, procede a cambiar las claves desde un equipo limpio, empezando por el panel del hosting.
Si vendes en línea y sospechas del checkout, avísale el mismo día a tu pasarela de pago.
Recién ahí decide si restauras un respaldo o limpias.

Pequeño resumen

Momento	Qué hacer	Qué no hacer
Primera hora	Confirmar que es un hackeo y anotar qué ves	Borrar archivos, desinstalar plugins o restaurar algo
Primeras horas	Aislar el sitio y avisar al hosting	Dejarlo abierto “mientras tanto” si redirige a tus visitantes
Antes de cambiar nada	Copia completa de archivos, base de datos y registros, tal como están	Cambiar claves o restaurar antes de tener esa copia
Mismo día	Cambiar todas las claves (hosting, dominio, correo, base de datos, WordPress) desde un equipo sano	Cambiarlas desde el computador que pudo haber filtrado las anteriores
Decisión	Restaurar un respaldo anterior al hackeo, o limpiar	Elegir lo que parece más rápido sin saber cuándo empezó
Después	Revisar usuarios, archivos y otros sitios de la cuenta, pedir revisión a Google, evaluar datos personales	Dar el tema por cerrado sin saber por dónde entraron

¿Es un hackeo o es otra cosa?

No todo sitio caído o raro está hackeado, así que antes de tocar nada descarto esto:

El sitio no carga en absoluto. Puede ser una caída del hosting, un servicio suspendido por un pago pendiente o un dominio vencido. Revisa el correo del hosting y el vencimiento del dominio (en NIC Chile si es un .cl). También puedes revisar si el servidor al completo está caído con un ping a tu IP (te recomiendo encarecidamente que sepas la IP de tu servidor), aunque muchos hostings no responden al ping, así que un ping sin respuesta no prueba que esté caído y un ping que responde no prueba que el sitio esté sano.
Cambiaste el DNS o de proveedor hace poco. Si el dominio apunta a otro lado vas a ver otra cosa sin que nadie haya entrado a tu sitio.
Te llegó un correo que dice que te hackearon y te pide pagar o hacer clic. La gran mayoría de estos correos son engaños y estafas. No respondas y revisa el sitio entrando tú directamente.
El navegador dice “No seguro”. Suele ser un problema del certificado SSL que permite que tu sitio se sirva por HTTPS. Un aviso rojo de “sitio engañoso” o “peligroso” es distinto y sí apunta a un compromiso.

WordPress.org pide partir por síntomas concretos: listas negras de Google o Bing, el hosting que deshabilitó el sitio, antivirus que lo marcan, usuarios que nadie creó. Yo sumo dos que Google describe en su política sobre contenido hackeado, redirecciones que dependen del dispositivo o de dónde viene la visita (por ejemplo, solo desde el celular o solo desde Google) y páginas nuevas que tú nunca publicaste. Esas páginas aparecen al buscar site:tudominio.cl y pueden ser spam de cualquier tema, por ejemplo casinos, farmacias o réplicas de productos de marca.

En una investigación propia sobre 25.399 sitios WordPress chilenos comparé lo que cada sitio le muestra a Googlebot con lo que le muestra a una persona. Los que mostraban cosas distintas tenían malware de cloaking: decenas de sitios presentaban este problema y a todo el mundo se le veían normales. A las empresas afectadas se les avisó y tengo la impresión que les costó creerme aunque mandé pruebas dado que el cloaking funcionaba solo una vez por IP, a la siguiente vez que entraras a la web no te redirigía ni mostraba cosas raras. Busqué un solo síntoma que también es el más silencioso, así que lo que no busqué no se cuenta, y por eso que tú veas bien tu sitio no alcanza para descartar un hackeo. Si tienes Search Console, el informe de Problemas de seguridad es el chequeo más rápido (más abajo cuento cómo se usa), y el de Acciones manuales junto con la inspección de URL los explico en mi página no aparece en Google.

¿Qué no tocar en las primeras horas?

Con los nervios del momento yo no haría esto:

Borrar archivos que se ven raros. Es habitual que el malware no esté en un solo archivo, así que si borras el que encontraste el resto puede seguir ahí y además perdiste una pista.
“Limpiar” con el primer plugin que aparece. Un escáner ayuda a encontrar cosas, pero algunos sacan lo visible y dejan la puerta de entrada abierta.
Restaurar un respaldo encima sin guardar antes lo que hay. Pierdes la evidencia y si el respaldo también estaba infectado terminas en el mismo lugar.
Reinstalar WordPress desde el botón del panel. La guía de WordPress.org advierte que esos instaladores a menudo solo sobrescriben archivos existentes, mientras que los hackeos suelen agregar archivos nuevos. Si se reinstala, es con la misma versión exacta y subiendo los archivos por SFTP.

¿Cómo aíslo el sitio?

Aislar sirve para que el sitio deje de hacer daño a tus visitas mientras se trabaja. La guía de web.dev para sitios hackeados (actualizada en 2015) también pone la cuarentena antes de la limpieza.

Modo mantenimiento. Si todavía controlas el panel, un plugin de mantenimiento muestra una página fija. Ojo que el malware que redirige puede actuar antes de que cargue ese plugin, así que verifica desde otro equipo y desde el celular que de verdad quedó tapado.
Bloqueo desde el hosting. Pedirle al hosting que restrinja el acceso público o protegerlo con contraseña desde su panel. Es más confiable porque no depende de WordPress.
Avisarle al hosting de todas formas. WordPress.org lo recomienda porque en hosting compartido el hackeo puede haber tocado más que tu sitio y porque el hosting a veces puede confirmar si es un hackeo o una falla del servicio.

Si tienes una tienda, aislar significa dejar de vender por unas horas y eso es, en mi opinión, preferible a seguir vendiendo con el checkout comprometido, porque ahí hay datos de clientes en juego. Si sospechas del checkout, la pasarela de pago tiene que saberlo ese mismo día.

¿Por qué copiar el sitio infectado antes de limpiarlo?

Porque ahí queda la evidencia de qué pasó. WordPress.org recomienda tomar esa copia aunque esté infectada, para tener una referencia si la limpieza sale mal. Va antes de cambiar las claves, porque la clave de la base de datos y las claves de seguridad se cambian editando wp-config.php, uno de los archivos que conviene guardar como estaba. Si la copia se va a demorar, cambia primero solo la clave del panel del hosting, que no toca archivos del sitio.

Esa copia incluye archivos, base de datos y, si el hosting los entrega, los registros de acceso. Va fuera del servidor y con un nombre que deje claro que está infectada, para que nadie la restaure por error. Con ella se ve qué archivos cambiaron. Sus fechas de modificación orientan, pero se pueden falsificar, y lo que fecha el incidente son los registros de acceso del servidor, por eso se le piden al hosting antes de que los descarte.

Puedes simplemente restaurar un backup, actualizar core y plugins y quizás te funcione, pero en mi experiencia lo normal es que el problema vuelva o que ni siquiera se haya ido nunca (porque el hack llevaba meses latente sin activarse y los backups lo siguen teniendo).

¿Qué claves cambio y desde dónde?

Todas las que dan acceso al sitio, desde un computador que no esté comprometido. WordPress.org recuerda que en muchos casos la infección parte en el equipo del dueño, con un troyano que captura las claves de FTP o del panel, así que cambiarlas desde ese mismo equipo puede servir de poco. Usa otro computador o pásale antes un antivirus completo al tuyo. Lo que yo personalmente cambio es esto, partiendo por lo que da más acceso:

Panel del hosting y FTP o SFTP, borrando las cuentas FTP que no reconozcas.
El registrador del dominio (NIC Chile si es un .cl), el DNS si lo administras en otro servicio y las cuentas de correo del hosting.
Usuario y clave de la base de datos, actualizando el wp-config.php para que el sitio siga conectando.
Usuarios de WordPress, empezando por todos los administradores y no solo el tuyo.
Las claves de seguridad de wp-config.php. Al cambiarlas se invalidan las cookies de sesión de todos los usuarios, pero eso no elimina un administrador que haya creado el atacante, ni las contraseñas de aplicación, ni una puerta trasera en los archivos, por eso lo siguiente es revisar usuarios y archivos.
Claves de API que el sitio tenga guardadas (pasarela de pago, correo transaccional, servicios externos) y el correo de la cuenta administradora si sospechas de él.

Después de limpiar, WordPress.org pide cambiar las claves otra vez. En ese momento también activaría el doble factor para los administradores / gestores de tienda.

¿Cómo recupero un WordPress hackeado, con respaldo o limpiando?

Depende de si sabes cuándo empezó el hackeo y de qué cambió en el sitio desde ese momento.

Situación	Lo que yo haría
Respaldo de antes del hackeo y un sitio que casi no cambia (web informativa)	Restaurar ese respaldo, actualizar todo y cerrar la entrada
Respaldo, pero sin saber cuándo empezó	Restaurar y revisar igual archivos y usuarios, porque el respaldo puede venir infectado
Tienda con pedidos, clientes o formularios posteriores al respaldo	Limpiar, o restaurar y recuperar a mano lo que se perdería
Sin respaldo, o todos posteriores al hackeo	Limpiar, reinstalando core, plugins y temas desde fuentes oficiales
El hackeo vuelve después de una limpieza	Asumir que la entrada sigue abierta y buscarla antes de limpiar otra vez

Restaurar es más predecible, pero si vuelve el mismo plugin vulnerable quien entró puede volver por el mismo lado. Limpiar toma más tiempo y pide más criterio. WordPress.org dice que /wp-admin y /wp-includes se pueden reemplazar completas, que wp-content se revisa con más cuidado y que conviene mirar siempre el .htaccess y archivos como index.php, header.php, footer.php y functions.php, porque si los modifican afectan todas las páginas.

Qué reviso dentro de WordPress y en el hosting

Restaure o limpie siempre reviso esto:

Usuarios administradores. Una cuenta que no reconoces se investiga, y las que sobran (proveedores que ya no trabajan contigo, cuentas de prueba) se eliminan. Como hay malware que oculta administradores en la pantalla de Usuarios, yo revisaría también la tabla de usuarios directamente en la base de datos (phpMyAdmin u otra herramienta del hosting), y en el perfil de cada usuario revocaría las contraseñas de aplicación que nadie reconozca.
Plugins y temas. Cuáles no usas, cuáles llevan mucho tiempo sin actualizarse y si hay alguno que tú no instalaste. Los que no se usan se borran en vez de dejarlos desactivados.
Archivos modificados. Comparar core, plugins y temas contra su versión oficial muestra rápido qué se tocó.
Base de datos y tareas programadas. El malware a veces vive en opciones de la base de datos, en tareas programadas de WordPress o en las del panel del hosting (cron), y por eso reaparece después de limpiar los archivos.
Otros sitios de la misma cuenta. Si en la misma cuenta del hosting tienes otros sitios, yo asumiría que también pueden estar comprometidos (WordPress.org advierte que el hackeo puede haber tocado más que tu sitio) y los revisaría todos, porque uno sin limpiar puede volver a infectar al que ya limpiaste.

Uno de los rescates que tengo publicados es el de Comercial Moya, cuyo sitio fue hackeado en 2022. Ahí se limpió, se documentó lo ocurrido en un informe para la clienta y se endureció la plataforma.

¿Y Google?

Si Google detectó el problema, lo vas a ver en Search Console, en el informe de Problemas de seguridad (contenido hackeado, malware o ingeniería social) y a veces en Acciones manuales. Lo que Google pide es corregir todos los problemas en todas las páginas y recién ahí usar el botón Solicitar revisión de ese mismo informe, describiendo el problema, qué hiciste y qué resultado obtuviste. Según la ayuda de Search Console, la revisión toma de unos pocos días a unas pocas semanas.

En Search Console revisa también Usuarios y permisos, en Configuración. La ayuda de Google dice que un propietario que no reconoces puede ser señal de que hackearon el sitio, y que al quitarlo su token de verificación no se borra solo, así que además hay que eliminar el archivo, la etiqueta o el registro DNS con que se verificó.

Yo no pido la revisión el mismo día. Primero confirmo que no quedó nada y que la entrada está cerrada, porque si Google encuentra restos el aviso sigue y perdiste semanas.

¿Tengo que avisar a mis clientes?

Depende de si el hackeo tocó datos personales. Separo lo que dice la ley de lo que haría yo, aclarando que no soy abogado.

La Ley 21.719 incorpora a la Ley 19.628 un artículo 14 sexies que obliga al responsable de los datos a reportar a la Agencia de Protección de Datos Personales, “por los medios más expeditos posibles y sin dilaciones indebidas”, las vulneraciones de seguridad que afecten datos personales cuando exista un riesgo razonable para los titulares. Además hay que avisar a cada persona afectada cuando se trata de datos sensibles, datos de niños menores de catorce años o datos de obligaciones económicas, financieras, bancarias o comerciales, en lenguaje claro, con los datos afectados, las posibles consecuencias y las medidas tomadas. Si no se puede avisar a cada una, se hace con un aviso en un medio masivo de alcance nacional. El artículo no fija un número de horas y pide dejar registro de esas comunicaciones.

Ojo con la fecha. La fecha legal de vigencia sigue siendo el 1 de diciembre de 2026, pero desde el 1 de septiembre de 2026 el Senado tramita un proyecto del Gobierno (boletín 18.623-07, con suma urgencia) que la movería al 1 de diciembre de 2027. Mientras esa ley no se publique rige la fecha original (el detalle está en qué es la Ley 21.719 y desde cuándo rige). Si tu incidente pasa antes, yo lo documentaría igual como si la ley ya aplicara, y avisarle a un cliente cuyos datos se filtraron me parece lo correcto aunque todavía no sea exigible.

Los datos personales de un sitio común están en lugares que se olvidan (formularios guardados en la base de datos, pedidos, cuentas de clientes, respaldos), y si hubo acceso a la base de datos yo asumiría que pudieron verlos.

¿Por qué entró y cómo evito que vuelva?

Esta es la parte que casi nunca viene incluida cuando “te limpian el sitio” y en mi opinión es la más importante. WordPress.org la llama análisis forense, entender cómo entraron para que no puedan usar de nuevo la misma vía. En WordPress hay tres entradas que se repiten mucho:

Software desactualizado. Core, plugins o tema con una vulnerabilidad conocida que ya tenía arreglo publicado. Me ha tocado limpiar sitios hackeados por software desactualizado, y WordPress.org recomienda actualizar apenas el sitio esté limpio porque las versiones antiguas son más propensas a hackeos.
Plugins abandonados. Un plugin que su autor dejó de mantener no recibe arreglos aunque siga funcionando.
Contraseñas débiles o repetidas. Una clave usada en otro servicio que se filtró, o un administrador sin doble factor.

Por eso, después de un incidente, dejo el sitio con las prácticas de un mantenimiento WordPress serio: actualizaciones probadas, respaldos que se verifican restaurándolos y alguien que mire el sitio todos los meses.

Qué no haría

Pagarle a quien te escribe diciendo que te hackeó o que te puede “desbloquear”. Pagar no garantiza nada y a veces el sitio ni siquiera tenía un problema.
Ocultar el incidente al hosting, a tu equipo y, si hubo datos personales comprometidos, a las personas afectadas.
Hacerlo todo solo si no tienes claro qué estás mirando. WordPress.org reconoce que la limpieza es la parte más difícil del proceso.

En mi opinión conviene llamar a alguien desde el principio si tienes una tienda con pagos y sospechas del checkout, si el hackeo volvió después de una limpieza, si no sabes por dónde entraron o si Google ya muestra el aviso y la revisión hay que pedirla bien a la primera.

Preguntas frecuentes

¿Cuánto tarda en recuperarse un WordPress hackeado?

Depende de qué tan metido esté el malware y de si hay un respaldo sano. Una infección acotada con respaldo limpio puede quedar resuelta en horas. Si el compromiso lleva tiempo y tocó archivos y base de datos toma bastante más, sin contar lo que tarde la revisión de Google.

¿Mi respaldo del hosting sirve para restaurar?

Sirve si es anterior al hackeo. Si no sabes cuándo empezó, un respaldo reciente puede venir infectado. Pregúntale al hosting cuántos días guarda y elige el más reciente que sea anterior al inicio del hackeo, y lo que se haya perdido entre esa fecha y hoy (pedidos, contenido) se recupera a mano.

Si prefieres delegarlo

Si el sitio ya está comprometido y prefieres no hacer esto solo, es parte de lo que hago en seguridad WordPress: contención, limpieza, cierre de la entrada y la solicitud de revisión a Google. Hago un diagnóstico de 30 minutos sin costo en el que reviso el sitio en vivo y te digo en qué escenario estás, escríbeme desde contacto.

Fuentes: FAQ My site was hacked, Documentación de WordPress.org, actualizado el 26 de julio de 2026 · Informe de problemas de seguridad, Ayuda de Search Console · Gestionar propietarios, usuarios y permisos, Ayuda de Search Console · Políticas de spam de la Búsqueda web de Google, contenido hackeado, Google Search Central, actualizado el 1 de septiembre de 2026 · Help, I think I’ve been hacked, web.dev, escrita por miembros del equipo de Chrome y expertos externos, actualizada en 2015 · Ley 21.719, BCN / LeyChile, artículo 14 sexies que incorpora a la Ley 19.628 (texto leído en la versión XML oficial de LeyChile) · Boletín 18.623-07, ficha de tramitación del Senado, ingresado el 1 de septiembre de 2026 · Gobierno ingresa proyecto de ley que posterga en un año la entrada en vigor de la ley sobre protección de datos personales, Carey, 3 de septiembre de 2026. Todas consultadas el 6 de octubre de 2026.

Volver al blog