Abres tu web una mañana y algo no encaja.
Aparecen enlaces que nadie ha creado. Google muestra páginas extrañas bajo tu dominio. Desde el móvil te redirige a una tienda sospechosa, aunque desde el ordenador parece funcionar. El hosting te escribe porque ha detectado malware o un consumo anómalo de recursos.
En ese momento es fácil cometer el primer error: empezar a tocar cosas sin saber qué ha ocurrido.
Desactivar plugins al azar, borrar archivos sospechosos, instalar tres herramientas de seguridad o restaurar la primera copia que encuentres puede esconder los síntomas sin cerrar la entrada utilizada por el atacante.
Si tu web WordPress ha sido comprometida, el orden importa.
Esta guía está pensada para propietarios de pequeñas empresas, no para especialistas en ciberseguridad. El objetivo es que sepas qué decisiones tomar durante las primeras horas, qué información conservar y en qué punto merece la pena dejar el trabajo en manos de alguien que pueda analizar la instalación completa.
WordPress tiene una superficie de ataque amplia porque alrededor del núcleo funcionan miles de plugins y temas.
El informe State of WordPress Security in 2026 de Patchstack contabilizó 11.334 nuevas vulnerabilidades durante 2025, un 42 % más que el año anterior. El 91 % se localizó en plugins y solo seis vulnerabilidades afectaron al núcleo de WordPress, todas de baja prioridad.
El dato más relevante para una pyme es la velocidad.
Patchstack calcula una mediana de unas cinco horas hasta la explotación masiva en las vulnerabilidades que terminaron siendo muy explotadas. En casos concretos el plazo fue incluso menor: una vulnerabilidad crítica de SureTriggers empezó a recibir intentos de explotación unas cuatro horas después de hacerse pública.
Esto explica por qué una web que funcionaba ayer puede tener hoy un problema serio sin que nadie de la empresa haya cambiado nada.
Los atacantes no necesitan conocerte. Muchos procesos son automáticos y buscan versiones vulnerables de plugins, credenciales débiles, archivos expuestos o configuraciones conocidas.
No todo comportamiento extraño significa malware.
Una actualización defectuosa puede romper el diseño. Un problema de DNS puede hacer que la web deje de cargar. Una mala configuración de caché puede mostrar contenido antiguo.
Hay señales que sí merecen tratarse como un posible incidente de seguridad.
Comprueba si han aparecido:
Un nuevo administrador que nadie del equipo reconoce es una señal especialmente preocupante.
Algunos ataques intentan pasar desapercibidos.
La web puede funcionar correctamente cuando entras directamente desde tu ordenador, pero redirigir a otra página cuando:
Google advierte de que algunos atacantes ocultan deliberadamente el contenido malicioso cuando detectan que quien visita la página puede ser el propietario. Por eso recomienda revisar las URLs sospechosas desde un dispositivo o una red diferentes.
No ignores mensajes relacionados con:
Pide al proveedor los detalles técnicos que tenga: nombres de archivos, fecha de detección, registros y acciones que haya realizado.
Esa información puede ayudar después a identificar el origen.
Google Search Console dispone de un informe específico de Problemas de seguridad que avisa cuando Google detecta contenido hackeado, malware o comportamientos peligrosos.
También merece la pena buscar en Google:
site:tudominio.com
y revisar si aparecen páginas que nunca has creado.
Google recomienda precisamente esta comprobación periódica para localizar contenido añadido por terceros.
Un archivo con un nombre extraño no es necesariamente malware y uno llamado index.php puede contener código malicioso aunque parezca normal.
Borrar sin analizar puede:
Cuando una instalación está comprometida no sabes todavía qué partes puedes considerar fiables.
Instalar una herramienta nueva puede ayudar en el diagnóstico, pero hacerlo como primera reacción sin copia ni estrategia añade otro componente a un sistema cuyo estado desconoces.
Una copia puede estar infectada.
También puede ser tan antigua que al restaurarla pierdas:
Primero hay que averiguar de qué fecha es y qué información contiene.
Modificar DNS, dominio o nameservers rara vez es la primera respuesta a una infección dentro de WordPress.
Puedes terminar añadiendo una caída de correo o del dominio al problema de seguridad original.
La prioridad inicial es evitar que el incidente siga perjudicando a visitantes y negocio.
Si el sitio:
puede ser sensato aislarlo o limitar temporalmente el acceso.
Habla con el hosting antes de improvisar.
Según el incidente puede convenir:
Esto no «oculta» el problema. Evita que más usuarios queden expuestos mientras se analiza.
Aunque parezca contradictorio, antes de limpiar conviene conservar una copia de archivos y base de datos tal como están.
Puede servir para:
No debe utilizarse después como copia limpia de producción.
Si existe la posibilidad de robo de credenciales, cambia las claves de:
Utiliza contraseñas distintas para cada servicio.
WordPress recomienda contraseñas fuertes y autenticación en dos pasos como medidas básicas de protección. También recuerda que un administrador comprometido puede instalar código capaz de afectar a todo el servidor.
Evita FTP sin cifrar. Para transferencia de archivos Google recomienda utilizar protocolos seguros como SFTP o SSH.
En WordPress entra en:
Usuarios → Todos los usuarios
Busca:
No borres automáticamente una cuenta sospechosa antes de documentarla. Anota nombre, correo, rol y fecha si está disponible.
Durante una recuperación también puede ser necesario regenerar las claves de autenticación de WordPress.
Cambiar las security keys y salts invalida las sesiones existentes, lo que ayuda a expulsar sesiones que puedan haber sido robadas.
Esta operación debe realizarla alguien que sepa editar wp-config.php sin romperlo.
Una copia limpia puede acortar muchísimo una recuperación.
Busca en varios sitios.
Muchos alojamientos generan copias automáticas diarias o semanales.
Pregunta:
Herramientas como UpdraftPlus y otros sistemas pueden guardar copias en:
Comprueba fechas antes de restaurar.
Puede existir una copia manual creada durante:
Algún miembro del equipo puede conservar una descarga antigua de archivos o base de datos.
No es la situación ideal, pero puede resultar útil.
Puedes ampliar este punto en nuestra guía sobre copias de seguridad en WordPress.
Una copia útil para recuperación debería cumplir tres condiciones.
Este punto parece obvio, pero muchas infecciones permanecen ocultas durante semanas.
La fecha en la que descubres el problema no tiene por qué coincidir con el momento del acceso inicial.
Una copia de ayer podría contener ya la puerta trasera.
Necesitas ambos.
En los archivos están:
En la base de datos están:
Una copia que nunca se ha probado es una posibilidad de recuperación, no una certeza.
Cuando el negocio depende de la web, las restauraciones deberían probarse periódicamente.
Este es uno de los errores más peligrosos.
Supongamos que un plugin vulnerable permitió entrar al atacante el lunes.
El viernes detectas malware y restauras la copia del domingo anterior.
La web vuelve a funcionar.
Pero el plugin vulnerable sigue instalado.
El atacante puede entrar de nuevo.
Por eso la recuperación tiene dos partes:
Si haces únicamente la primera, puedes acabar limpiando la misma web varias veces.
Aquí es donde el trabajo deja de ser razonable para la mayoría de propietarios de pymes.
Una infección puede esconderse en:
wp-config.php..htaccess.La documentación oficial de WordPress parte de tres ideas para proteger una instalación: limitar accesos, contener el daño y mantener copias que permitan recuperarla.
Una limpieza profesional debería asumir que el archivo visible es solo una parte del problema.
Hay que conocer:
Los archivos del núcleo pueden sustituirse por copias limpias de la misma versión o actualizarse de forma controlada.
Esto permite descartar modificaciones dentro de WordPress.
Los componentes deben clasificarse:
WordPress recomienda obtener temas y plugins únicamente desde repositorios o proveedores de confianza.
Un componente abandonado no debería quedarse instalado simplemente porque «todavía funciona».
El malware también puede introducir:
Limpiar archivos sin revisar la base de datos puede dejar parte del incidente activa.
Las tareas automáticas pueden utilizarse para recrear archivos eliminados.
Por eso una web que parece limpia puede infectarse de nuevo horas después sin que nadie vuelva a atacarla desde fuera.
Una puerta trasera permite recuperar acceso incluso después de cambiar contraseñas.
Puede estar escondida dentro de archivos aparentemente legítimos y utilizar código ofuscado para dificultar su detección.
Una recuperación es buen momento para reducir la superficie de ataque.
Pregunta por cada plugin:
¿Por qué sigue instalado?
Si nadie sabe responder, merece una revisión.
Patchstack registró que el 91 % de las vulnerabilidades descubiertas en WordPress durante 2025 pertenecían a plugins.
Eso no significa que los plugins sean intrínsecamente peligrosos.
Significa que cada componente adicional introduce código que debe mantenerse.
En cuántos plugins conviene utilizar en WordPress explicamos por qué importa más la calidad y el mantenimiento que perseguir un número concreto.
Una web recién recuperada no debería volver a producción con exactamente la misma configuración.
WordPress permite editar archivos de plugins y temas desde el panel.
En una instalación corporativa suele ser razonable impedir esa capacidad mediante configuración, porque una cuenta de administrador comprometida tendría una vía directa para modificar código.
La propia guía de endurecimiento de WordPress incluye la desactivación de la edición de archivos como una medida de seguridad.
Una contraseña fuerte sigue siendo necesaria, pero una segunda capa reduce el impacto de una credencial robada.
Debe aplicarse como mínimo a:
No todos los usuarios necesitan el máximo nivel de permisos.
Un responsable de contenidos puede trabajar como editor.
Un comercial probablemente no necesita acceso a plugins.
Cuantas más cuentas administrativas existan, más credenciales pueden acabar expuestas.
Una instalación recuperada debería volver a una combinación compatible y mantenida.
Evita el impulso de actualizar todo a ciegas sobre una web que acaba de salir de un incidente. Hazlo primero en staging y prueba las funciones críticas.
Puedes consultar nuestra guía sobre actualizaciones de WordPress para empresas.
Una limpieza sin análisis de causa raíz deja una pregunta incómoda:
¿Qué impide que vuelva a ocurrir?
No siempre será posible determinar el origen con certeza, especialmente cuando no existen registros suficientes.
Sí se pueden identificar causas probables.
Es uno de los primeros candidatos.
Durante 2025 Patchstack detectó 11.334 vulnerabilidades nuevas y el 91 % correspondían a plugins. Además, el 17 % presentaba un riesgo alto de explotación masiva.
Y los atacantes pueden moverse muy rápido. En otro incidente relacionado con OttoKit/SureTriggers, Patchstack observó intentos de explotación aproximadamente una hora y media después de divulgarse el fallo.
Si la vía fue un plugin:
Otra causa posible es una contraseña:
También conviene comprobar los ordenadores desde los que se administra WordPress. La documentación oficial recuerda que proteger el servidor sirve de poco si el dispositivo del administrador contiene un keylogger o malware.
Un tema o plugin puede seguir funcionando y llevar años sin mantenimiento.
Ese es precisamente el problema.
La ausencia de errores visibles no demuestra que el software siga siendo seguro.
Si varias webs del mismo alojamiento presentan problemas, la investigación debe ampliarse.
No centres todo el análisis en WordPress cuando existe la posibilidad de que el acceso se produzca a nivel de cuenta, servidor o credenciales del hosting.
Después de limpiar, revisa Google Search Console → Problemas de seguridad.
Google utiliza este informe para mostrar amenazas como contenido hackeado o software malicioso.
Comprueba también:
Google recomienda verificar que ningún propietario desconocido haya sido añadido a Search Console después de un compromiso.
Cuando hayas eliminado el contenido peligroso, puedes solicitar una revisión desde el informe de Problemas de seguridad.
No la solicites antes de terminar.
Los sitios que reinciden repetidamente en comportamientos peligrosos pueden ser clasificados por Safe Browsing como reincidentes, lo que limita temporalmente la posibilidad de pedir nuevas revisiones.
Que la página vuelva a cargar no significa que puedas cerrar la incidencia.
Durante los días posteriores vigila:
Una reinfección rápida suele indicar que:
Documenta lo ocurrido.
No necesitas un informe forense de cien páginas, pero sí dejar constancia de:
Esto evita que dentro de seis meses nadie recuerde qué ocurrió.
Una vez recuperada la web aparece la pregunta importante:
¿Volvemos a dejarla sola?
Los incidentes de WordPress actuales muestran que limitarse a actualizar cuando alguien entra en el panel no es suficiente.
Patchstack observó que un 46 % de las vulnerabilidades de 2025 no recibieron parche del proveedor antes de hacerse públicas. Esto significa que en algunos casos ni siquiera existe una actualización disponible cuando el riesgo se conoce.
Hace falta vigilancia.
WordPress, plugins y tema deben mantenerse al día con criterio.
Una actualización crítica de seguridad no debería esperar al mantenimiento trimestral.
El proveedor debería saber si un plugin instalado aparece en bases de vulnerabilidades conocidas y actuar según su severidad.
No almacenes la única copia dentro del mismo servidor.
Una incidencia de hosting, borrado o malware puede afectar también a los backups locales.
No esperes a un hackeo para descubrir que la copia no funciona.
Si la web cae un domingo, alguien debería enterarse antes que el primer cliente del lunes.
Revisa periódicamente:
Los componentes que dejan de utilizarse deben eliminarse.
Los abandonados deben sustituirse.
Los duplicados deben simplificarse.
En nuestro artículo sobre mantenimiento web WordPress en 2026 explicamos por qué este trabajo continúa aunque la empresa apenas actualice sus contenidos.
Un hackeo no es el momento de vender un rediseño innecesario.
Pero si ya tienes que revisar toda la instalación puede ser razonable corregir deuda acumulada.
Elimina funciones que nadie utiliza.
Si la infraestructura lleva años sin tocarse, puede necesitar una puesta al día.
Una instalación llena de código antiguo también suele acumular problemas de velocidad.
Elimina cuentas de antiguos empleados, agencias y colaboradores.
La empresa debería saber quién tiene acceso a:
Este reparto forma parte del enfoque que explicamos en qué puedes tocar tú en WordPress y qué conviene delegar.
Cuando contratas ayuda para recuperar una web, pregunta qué incluye exactamente.
Un servicio serio debería poder explicarte:
Aunque no siempre pueda determinarse el origen exacto, debe diferenciar hechos de hipótesis.
Archivos, base de datos, usuarios, tareas y otros componentes revisados.
Plugins, temas, contraseñas y versiones.
Actualizaciones, permisos, 2FA, claves, eliminación de software vulnerable y otras medidas.
Ningún proveedor serio puede prometer que una web «nunca volverá a ser hackeada».
[Unverified] Una promesa de seguridad absoluta no es técnicamente defendible.
Lo razonable es reducir el riesgo, detectar problemas pronto y disponer de un procedimiento de recuperación.
En Arreglo tu Web podemos intervenir en instalaciones WordPress comprometidas o sospechosas.
El proceso se adapta al incidente, pero normalmente comienza por cuatro preguntas:
Después se trabaja sobre:
Puedes consultar también nuestra guía específica sobre cómo recuperar y reforzar un WordPress después de un hackeo y la dedicada a eliminar malware sin romper WordPress.
No puedes asegurar que una web nunca vaya a sufrir un incidente.
Sí puedes decidir si ese día tendrás que improvisar.
Una pyme debería saber, antes de necesitarlo:
Ese plan no elimina los ataques.
Reduce el caos.
Y en una incidencia real, las primeras horas pueden marcar la diferencia entre una restauración controlada y varios días intentando averiguar quién tiene la contraseña del hosting.
Si sospechas que tu WordPress está comprometido, evita empezar a borrar cosas. Contacta con Arreglo tu Web y revisaremos primero qué está pasando, qué se puede conservar y cuál es la forma más segura de recuperar la instalación.
Y si tu web está funcionando perfectamente ahora mismo, mejor momento todavía para comprobar las copias, accesos y mantenimiento antes de tener que utilizarlos de verdad.
