Cómo saber si tu web ha sido hackeada (y qué hacer)

El 43% de los ciberataques van dirigidos a pequeñas empresas. La mayoría de estas empresas lo descubren tarde: cuando un cliente les avisa, cuando Google las marca como peligrosas o cuando sus emails empiezan a ir a la carpeta de correo no deseado. En ese momento, el daño ya está hecho.

El patrón se repite: pymes con la web comprometida desde hace meses, sin saberlo. Este artículo te explica las 8 señales más habituales, qué hacer si detectas alguna, y cómo es de verdad la recuperación, tanto la limpieza del código como la vuelta al buscador.

1. Por qué las pymes son el objetivo preferido de los hackers

Cuando piensas en un ciberataque, te imaginas a un hacker atacando a Google o a un banco. La realidad es mucho más práctica: los hackers atacan las webs más fáciles. Y las webs más fáciles son las de pequeñas empresas.

Tres razones:

No se mantiene el software. El 70% de las webs WordPress hackeadas tienen plugins desactualizados. Cada mes se descubren vulnerabilidades nuevas en plugins populares; los hackers las explotan antes de que los propietarios las actualicen.

No hay monitorización. Una pyme no tiene un equipo de seguridad que vigile la web 24/7. Puede pasar meses con código malicioso inyectado sin darse cuenta. El cliente medio solo mira su web 2 o 3 veces al mes.

Las contraseñas son débiles. “admin / 123456” sigue siendo una de las combinaciones más habituales. Los hackers prueban miles de combinaciones por minuto con herramientas automatizadas. Una contraseña de 6 caracteres se rompe en menos de un minuto.

Y las consecuencias son desproporcionadas: para una multinacional, un ataque es una molestia. Para una pyme, puede significar cerrar el negocio.

2. Las 8 señales de que tu web ha sido hackeada

Señal 1: Resultados extraños cuando buscas tu negocio en Google

Busca en Google el nombre de tu web entre comillas (por ejemplo: site:tunegocio.com). Si ves páginas con títulos en japonés, contenido sobre productos farmacéuticos, casinos en línea o palabras clave que no tienen nada que ver con tu negocio, tu web está hackeada.

Es la forma más habitual de ataque SEO: los hackers inyectan cientos de páginas nuevas en tu web con contenido spam, aprovechando tu dominio para posicionar productos que quieren vender.

Señal 2: Google Search Console te notifica problemas de seguridad

Si tienes tu web verificada en Google Search Console (y deberías tenerla), aquí es donde recibirás los primeros avisos. En el apartado “Problemas de seguridad”, Google te notifica si detecta:

• Malware (código malicioso que infecta a los visitantes)
• Software malicioso o no deseado (extensiones, descargas sospechosas)
• Phishing (intentos de robar datos)
• Contenido hackeado (cambios no autorizados en tu web)

Si ves cualquier notificación en este apartado, actúa inmediatamente. No esperes más de 24 horas.

Señal 3: Pop-ups que no has puesto tú

Si visitas tu web y de pronto aparecen pop-ups, anuncios extraños, redirecciones a otras webs o un contador supuestamente oficial diciendo “tu ordenador está infectado”, la web está comprometida. Los hackers han inyectado código JavaScript que se ejecuta en los visitantes.

Importante: puede que estos pop-ups solo aparezcan en determinados navegadores o países. Prueba la web en modo incógnito y desde otro dispositivo.

Señal 4: Cuentas de administrador desconocidas

Si usas WordPress, ve a Usuarios > Todos los usuarios y mira si hay alguna cuenta de administrador que no reconozcas. Los hackers suelen crear cuentas con nombres técnicos (wpadmin, support, admin1) para mantener el acceso aunque cambies tu contraseña.

Mira también si hay usuarios con fechas de creación recientes que no recuerdes haber creado tú.

Señal 5: Archivos nuevos o modificados en el servidor

Si tienes acceso FTP o al gestor de archivos del hosting, busca archivos con nombres extraños: wp-x.php, wso.php, marvin.php, index2.php. Estos son nombres típicos de “shells” (programas que los hackers usan para controlar la web).

Mira también las fechas de modificación. Si ves archivos de WordPress modificados recientemente sin que hayas hecho ninguna actualización, es una señal de alerta.

Señal 6: Caída brusca de tráfico en Google Analytics

Si tu web recibía 500 visitas mensuales y de pronto baja a 50, es muy posible que Google te haya penalizado. La causa más habitual de una caída de esta magnitud es contenido hackeado o malware que ha activado un filtro de Google.

Mira también si la caída afecta solo a ciertas páginas: si Google ha detectado malware en una sección concreta, puede desindexar solo esa sección.

Señal 7: El navegador marca tu web como peligrosa

Visita tu web con Chrome y Firefox. Si ves una pantalla roja con mensajes como “Sitio engañoso a la vista” o “Este sitio puede dañar tu ordenador”, Google ya ha detectado el ataque y ha bloqueado la web a sus usuarios.

Es el peor escenario: en este momento, el 95% del tráfico potencial huye sin ni siquiera ver tu contenido.

Señal 8: Tu hosting te notifica actividad sospechosa

Los hostings serios monitorizan sus servidores. Si reciben alertas de que tu cuenta está enviando spam, consumiendo recursos excesivos o teniendo conexiones sospechosas, te envían un email de aviso. Lee siempre los emails de tu hosting; muchos propietarios los ignoran pensando que son publicidad.

3. Qué hacer si encuentras alguna de estas señales

Si has identificado alguna de las 8 señales, sigue este protocolo en este orden exacto:

Paso 1: NO BORRES NADA. El primer instinto es limpiarlo todo de una vez, pero puedes destruir pruebas valiosas sobre cómo ocurrió el ataque. Haz una copia de seguridad completa antes de tocar nada.

Paso 2: Pon la web en modo mantenimiento. Si tu plataforma lo permite, muestra una página temporal “Volvemos pronto”. Esto evita que los visitantes queden infectados mientras limpias la web.

Paso 3: Cambia todas las contraseñas. Todas. La de WordPress, la del FTP, la del panel del hosting, la de la base de datos, la del correo corporativo si usa el mismo dominio. Usa contraseñas de 16+ caracteres generadas con un gestor como 1Password o Bitwarden.

Paso 4: Escanea la web con una herramienta especializada.

• Sucuri SiteCheck (gratuito): escanea tu web y te dice si detecta malware, blacklist o vulnerabilidades conocidas.
• Wordfence (para WordPress): escanea todos los archivos de tu web buscando código malicioso.
• VirusTotal (gratuito): comprueba si tu dominio está en listas negras de seguridad.

Paso 5: Restaura una copia de seguridad anterior a la infección. Si tienes copias de seguridad (y deberías tenerlas), restaura una de antes de que empezaran los problemas. Comprueba primero la fecha exacta de la infección mirando los archivos modificados.

Paso 6: Actualiza todo el software. WordPress, plugins, temas, PHP, base de datos. Si hay plugins que ya no se mantienen, bórralos y busca alternativas activas.

Paso 7: Notifica a Google Search Console que has resuelto el problema. En el apartado “Problemas de seguridad”, pulsa “Solicitar revisión” una vez hayas limpiado la web. Google revisa la solicitud entre 24 y 72 horas.

Paso 8: Si no sales adelante, contrata a un profesional. Empresas como Sucuri, Wordfence o consultores de ciberseguridad pueden hacer una limpieza profesional por entre 200 y 500 EUR en el mercado. Vale la pena: una web hackeada pierde clientes cada día que sigue infectada.

4. La otra mitad del trabajo: recuperar la visibilidad

Aquí es donde la mayoría de propietarios creen que ya han terminado. No es así. Limpiar el código malicioso y recuperar el sitio en el buscador son dos trabajos distintos, con plazos distintos, y el segundo es más largo.

Qué pasa exactamente mientras la web está marcada

Cuando Google clasifica una web como comprometida, ocurren tres cosas a la vez. Los navegadores muestran la pantalla roja de aviso, y el visitante se va antes de ver nada. Las páginas spam inyectadas entran en el índice con tu dominio, y empiezan a competir con tus páginas reales. Y las páginas legítimas que el atacante ha modificado pierden sus posiciones porque el contenido ya no corresponde a la consulta.

Por eso la limpieza técnica no revierte el daño por sí sola: aunque el código malicioso desaparezca hoy, el índice de Google sigue reflejando la web infectada hasta que la vuelve a rastrear.

El proceso de reindexación, paso a paso

1. Confirma que la web está realmente limpia antes de pedir nada. Si pides la revisión con restos de código malicioso, Google la deniega y la siguiente petición tarda más. Escanea dos veces, con dos herramientas distintas, y revisa a mano los archivos modificados más recientemente.

2. Pide la revisión de seguridad en Search Console. En “Problemas de seguridad”, explica en el formulario qué pasó, cómo lo limpiaste y qué has hecho para que no vuelva a ocurrir. Una descripción concreta se resuelve más rápido que una genérica. La respuesta suele llegar entre 24 y 72 horas. Cuando se aprueba, el aviso rojo del navegador desaparece.

3. Elimina las páginas spam del índice. Las URL inyectadas deben devolver un código 404 o 410, no una redirección a tu portada. Una vez lo devuelven, usa la herramienta de eliminación de URL de Search Console para quitarlas de la vista mientras Google las vuelve a rastrear. Si eran cientos, esta parte es la que más trabajo lleva.

4. Revisa el archivo robots.txt y el mapa del sitio. Los atacantes suelen modificarlos para esconder su contenido o bloquear el rastreo de tus páginas. Vuelve a generarlos desde cero y envía el mapa del sitio actualizado.

5. Vuelve a enviar a indexar las páginas importantes. Con la inspección de URL de Search Console, pide la indexación de tus páginas principales, una a una. Prioriza las que te traían tráfico comercial.

6. Vigila la evolución durante las semanas siguientes. Mira impresiones y posiciones en Search Console, no solo visitas. Las impresiones se recuperan antes que los clics, y son la primera señal de que el rastreo se ha normalizado.

Plazos realistas

No hay una cifra garantizada, y quien te la dé no la puede cumplir. Lo que sí se puede decir con honestidad es el orden de magnitud de cada fase:

• Limpieza técnica: de unas horas a unos días, según el tamaño de la web y si hay una copia de seguridad limpia anterior a la infección.
• Retirada del aviso del navegador: normalmente entre 24 y 72 horas una vez aprobada la revisión de Google.
• Vuelta al índice de las páginas legítimas: días o semanas, según la frecuencia con la que Google rastrea tu dominio.
• Recuperación de posiciones y tráfico: semanas, y en sitios que ya tenían poca autoridad puede alargarse más. Algunas páginas no vuelven exactamente donde estaban.

Dos cosas aceleran este proceso mucho más que cualquier otra: tener una copia de seguridad limpia y fechada, y haber detectado el ataque pronto. Una web comprometida durante tres días se recupera de forma muy distinta a una que lo ha estado durante ocho meses.

Mientras dura la recuperación

Avisa a los clientes si el ataque ha podido afectar a datos personales: no es opcional, el RGPD obliga a notificar a la autoridad de control en 72 horas cuando hay riesgo para los derechos de las personas afectadas. Revisa también que el correo del dominio no haya acabado en listas negras, porque los atacantes suelen usarlo para enviar spam, y eso afecta a tu capacidad de llegar a la bandeja de entrada mucho después de que la web ya esté limpia.

5. Cómo prevenirlo para el futuro

Recuperar una web hackeada es caro y estresante. Prevenirlo es barato y fácil. Estas son las 5 medidas básicas:

1. Actualizaciones automáticas. Activa actualizaciones automáticas para WordPress core, plugins y temas. Si usas otro CMS, configura recordatorios semanales para actualizar manualmente.

2. Contraseñas fuertes y autenticación de dos factores (2FA). Nunca uses “admin” o “123456”. Activa 2FA siempre que sea posible (Google Authenticator, Authy).

3. Copias de seguridad automáticas y externas. Las copias deben ser diarias y guardarse fuera del servidor (Google Drive, Dropbox, AWS S3). Una copia en el mismo servidor no sirve de nada si el servidor está comprometido.

4. Firewall a nivel de servidor o aplicación. Cloudflare, Sucuri o Wordfence ofrecen firewalls que bloquean ataques conocidos antes de que lleguen a tu web. Hay versiones gratuitas que ya son útiles.

5. Reducir la superficie de ataque. Cada plugin que añades es un punto de entrada potencial. Borra los plugins que no uses. Borra los temas que no estés utilizando. Menos código = menos vulnerabilidades.

6. Por qué una web estática reduce tanto la superficie de ataque

En serpixel no usamos WordPress. Las webs que construimos se hacen con Astro, un framework que genera HTML estático en el momento de publicar.

¿Qué significa esto para la seguridad?

Sin base de datos. Ninguna consulta SQL, ninguna inyección posible, ningún login a una base de datos.

Sin PHP. El servidor no ejecuta ningún código cuando alguien visita la web. Solo envía archivos HTML pre-generados. Sin ejecución = sin vulnerabilidades de ejecución.

Sin plugins de terceros vulnerables. Cada funcionalidad se construye como código propio, revisado y auditado. No dependemos de cientos de pequeños plugins hechos por desarrolladores anónimos.

Sin panel de administración público. En WordPress, cualquiera puede intentar entrar en tudominio.com/wp-admin. En Astro no hay panel de admin: la web se genera desde el repositorio de código y se publica vía Git. Para atacar la web, un hacker tendría que comprometer nuestro repositorio de GitHub y el proceso de despliegue de Vercel.

CDN con protección DDoS incluida. Vercel incluye protección contra ataques de denegación de servicio, bloqueo automático de bots maliciosos y monitorización constante.

Ninguna web es invulnerable, y quien diga lo contrario te está vendiendo humo. Lo que sí cambia con una arquitectura estática es la superficie: los vectores de ataque más habituales contra una pyme (plugin desactualizado, login expuesto, inyección SQL) sencillamente no están.

Las rutinas de mantenimiento que evitan llegar hasta aquí

Estas son las revisiones que hacemos sobre las webs que mantenemos, y que puedes exigir a cualquier proveedor:

1. Actualizar todas las dependencias de la web y revisar si hay vulnerabilidades nuevas en npm advisories
2. Monitorizar los logs del servidor para detectar comportamientos sospechosos
3. Verificar con Sucuri SiteCheck que el dominio no ha entrado en ninguna lista negra
4. Comprobar que Google Search Console no muestra problemas de seguridad
5. Mantener el historial completo mediante Git, de forma que cada cambio queda registrado y se puede revertir a un estado limpio conocido

Este último punto es el que más importa el día malo. Si toda la web vive en un repositorio de código versionado, la “copia de seguridad limpia anterior a la infección” no es una esperanza: es un commit concreto con fecha.

Si sospechas que tu web tiene un problema de seguridad, o si ya la has limpiado y no acabas de recuperar las posiciones, hablémoslo en 30 minutos. Repasamos qué muestra tu Search Console, en qué punto de la recuperación estás y qué tocaría hacer a continuación.