Un sitio comprometido no siempre se nota a simple vista: muchos ataques están diseñados deliberadamente para ser invisibles al propietario del sitio mientras generan valor para el atacante (tráfico de spam, enlaces manipulados, redirecciones a otros dominios) solo ante rastreadores o ante usuarios que llegan desde una búsqueda concreta. Entender cómo detectar estos compromisos técnicamente, antes de que Google los detecte y aplique una acción manual, es la diferencia entre una limpieza discreta y semanas de pérdida de tráfico mientras se resuelve una advertencia pública en los resultados de búsqueda.
Inyección de contenido spam: el ataque más común y más fácil de pasar por alto
El patrón más habitual consiste en inyectar contenido (normalmente enlaces o texto relacionado con farmacia, apuestas, o réplicas de productos de marca) en páginas legítimas del sitio, a menudo oculto visualmente mediante CSS (texto del mismo color que el fondo, o posicionado fuera de la pantalla) para que no lo note un visitante humano pero sí lo procese un rastreador. Buscar en Google site:tudominio.com junto a términos evidentemente ajenos al negocio (por ejemplo, "viagra" o "casino") es una comprobación rápida y gratuita que revela si Google ya ha indexado contenido inyectado de este tipo.
Cloaking: mostrar algo distinto a Google que a los usuarios
El cloaking consiste en servir contenido distinto según quién hace la petición: a Googlebot se le muestra una página aparentemente normal, mientras que a un usuario humano que llega desde el resultado de búsqueda se le redirige a otro dominio (habitualmente publicidad fraudulenta o malware). Es una de las técnicas de manipulación más graves para Google, con consecuencias de penalización severas si se detecta, y también una de las más difíciles de detectar por el propio propietario del sitio, precisamente porque navegando normalmente (sin llegar desde una búsqueda real) el problema no es visible.
// Comprobación básica: comparar la respuesta del servidor
// según distintos user-agents desde la línea de comandos
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://tudominio.com/pagina
curl -A "Mozilla/5.0 (Windows NT 10.0)" https://tudominio.com/pagina
// Si el contenido difiere sustancialmente, hay indicios de cloakingRedirecciones maliciosas condicionales
Una variante frecuente redirige a los usuarios (pero no a los rastreadores) hacia otro dominio solo bajo ciertas condiciones: dispositivos móviles, un referer concreto (llegar desde Google específicamente), o incluso solo la primera visita de cada usuario para dificultar la detección. Estos patrones suelen estar inyectados en archivos .htaccess comprometidos o en código PHP añadido a plantillas del CMS, y una revisión de integridad de archivos (comparando los archivos actuales contra una copia de seguridad limpia conocida) es la forma más fiable de encontrarlos.
Cómo Google comunica un compromiso detectado
Search Console tiene una sección específica, Problemas de seguridad, donde Google notifica de forma explícita si ha detectado malware, contenido pirateado, ingeniería social (phishing) o spam inyectado en el sitio. La gravedad de la respuesta varía: desde una advertencia visible en el resultado de búsqueda ("este sitio puede estar hackeado") hasta la eliminación completa del sitio del índice en los casos más graves o si el problema persiste sin resolverse.
El proceso técnico de limpieza: por qué desactivar el síntoma no basta
Un error habitual es limpiar únicamente el síntoma visible (borrar el texto spam inyectado, desactivar un plugin sospechoso) sin encontrar ni cerrar la puerta de entrada real que permitió el compromiso. Si esa puerta de entrada (una contraseña débil, un plugin desactualizado con una vulnerabilidad conocida, un permiso de archivo mal configurado) sigue abierta, el ataque se repite en días o semanas, a menudo de forma más agresiva. El proceso técnico correcto incluye: identificar el vector de entrada real (revisando logs del servidor en busca de peticiones anómalas y el historial de cambios en archivos), limpiar todo el código inyectado (no solo el que es visible, sino también puertas traseras ocultas que permiten reinyectar contenido más tarde), actualizar todo el software vulnerable (CMS, plugins, dependencias), y cambiar todas las credenciales de acceso, no solo las que se sospecha comprometidas.
Solicitar la revisión: el orden importa
Una vez confirmada la limpieza completa, Search Console permite solicitar una revisión manual del problema de seguridad. Solicitarla antes de haber resuelto realmente la causa raíz (por ejemplo, solo tras borrar el contenido visible pero sin cerrar la vulnerabilidad) suele alargar el proceso: si el revisor humano de Google encuentra el mismo problema al revisar, o si el sitio vuelve a comprometerse durante la revisión, la solicitud se deniega y hay que volver a empezar el proceso desde cero.
Prevención: reducir la superficie de ataque de forma continua
Más allá de la recuperación tras un compromiso, un conjunto de prácticas técnicas reduce sustancialmente el riesgo de que ocurra: mantener el CMS, plugins y dependencias siempre actualizados a su última versión estable; usar contraseñas únicas y robustas para cada cuenta con acceso al servidor o al panel de administración; limitar los permisos de archivos y carpetas al mínimo necesario para que la aplicación funcione; y hacer copias de seguridad periódicas y verificadas (probar que realmente se pueden restaurar, no solo que se generan) que permitan revertir a un estado limpio conocido si un compromiso pasa desapercibido durante un tiempo.
Preguntas frecuentes
¿Cuánto tarda Google en quitar la advertencia de seguridad tras una limpieza?
Una vez solicitada la revisión manual con la limpieza ya confirmada, el proceso suele tardar entre unos días y dos semanas, dependiendo del volumen de solicitudes que esté gestionando Google en ese momento y de la complejidad del caso.
¿Un hackeo afecta al posicionamiento aunque no reciba ninguna acción manual visible?
Sí: incluso sin una advertencia visible en resultados, un sitio comprometido suele sufrir una caída de rendimiento indirecta por la degradación técnica que el propio ataque introduce (código malicioso ejecutándose, recursos del servidor consumidos por el atacante, posibles redirecciones que Google detecta como señal de mala calidad).
¿Cómo sé si mi web ha sido víctima de cloaking sin saberlo?
Comparar la respuesta del servidor con distintos user-agents (como se muestra en el ejemplo de esta guía) es la comprobación técnica más directa; también conviene revisar el informe de Problemas de seguridad de Search Console periódicamente, no solo cuando se sospecha un problema.
¿Basta con restaurar una copia de seguridad anterior al ataque?
Solo si esa copia es anterior al momento real del compromiso (no solo anterior a cuando se detectó, que puede ser mucho después) y si además se cierra la vulnerabilidad que permitió la entrada; restaurar sin cerrar esa puerta suele resultar en una reinfección a corto plazo.
¿Los hosting compartidos son más vulnerables que uno dedicado?
Pueden serlo si el aislamiento entre cuentas del mismo servidor es deficiente: un fallo de seguridad en otra web alojada en el mismo servidor puede, en configuraciones mal aisladas, afectar también a las demás cuentas del mismo hosting, algo mucho menos probable en un servidor dedicado o con aislamiento robusto entre cuentas.