Empresa de servicios B2B, Europa.

Qué lo disparó

Fue un bloqueo comercial. El filtro DNS corporativo de uno de sus clientes rechazaba el dominio de nuestro cliente, y un proveedor cuya web no resuelve dentro de la red de su cliente tiene un problema de negocio, no de informática.

El encargo llegó como "les parece que estamos hackeados". No lo estaban.

El diagnóstico, en una semana

Entregamos un informe técnico de seguridad, SSL y reputación apoyado en herramientas públicas de referencia: análisis SSL, escaneo de cabeceras HTTP, reputación de dominio, navegación segura y antivirus multi motor. Cualquiera puede repetirlas todas, y esa es justo la gracia.

La conclusión fue clara: la web no estaba comprometida ni figuraba en ninguna lista negra. Era un problema de endurecimiento y configuración, no de infección.

El TLS ya estaba bien antes de empezar: certificado válido, TLS 1.3 activo, sin cifrados débiles, cadena válida y forward secrecy. La calificación SSL del diagnóstico inicial era A, antes de tocar nada. Lo que disparaba la clasificación automática de "postura de seguridad baja" con la que trabajan los filtros corporativos eran otras tres cosas:

• Ninguna cabecera HTTP de seguridad. Nota de cabeceras: F.
• Un certificado de respaldo caducado y no coincidente, expuesto por el hosting compartido.
• Huellas del servidor a la vista: versión del intérprete, firma del panel de control y cabecera de tecnología.

La restricción que decidió la arquitectura

El único acceso disponible era el panel de administración del gestor de contenidos. Sin acceso al hosting, endurecer a nivel de servidor no es aplicable sobre la infraestructura original, así que migrar era la única vía.

La alternativa era rehacer la web en código: una estimación de tres a seis semanas, con el dominio bloqueado durante todas ellas. La migración era reversible y desbloqueaba antes. La reconstrucción en estático se quedó en el cajón, como fase diferida.

Qué se cambió, exactamente

El trabajo fue en tres fases: migración con verificación funcional y repaso de URLs y enlaces permanentes, endurecimiento de seguridad y configuración, y limpieza de reputación.

Cabeceras servidas tras el endurecimiento

HSTS con includeSubdomains, una Content-Security-Policy, la protección legacy contra XSS, nosniff, X-Frame-Options en SAMEORIGIN, una Referrer-Policy estricta, una Permissions-Policy con la lista completa de APIs sensibles deshabilitadas, y una cabecera de servidor sin versión.

La capa del gestor de contenidos

Remapeo de rutas internas, ocultación de rutas y ficheros comunes, login movido con URL de emergencia custodiada, protección de fuerza bruta, firewall de aplicación con bloqueo automático de IPs, XML-RPC desactivado, endpoints de descubrimiento apagados y detectores de tema bloqueados. Los rastreadores de IA se dejaron permitidos a propósito, porque la visibilidad en buscadores formaba parte del encargo.

Lo que afirmamos y lo que no

Solo afirmamos lo que hicimos y medimos. No quedó registrada ninguna lista de CVE ni recuento de vulnerabilidades, así que no publicamos ninguna cifra de vulnerabilidades cerradas.

El cambio de DNS

TTL bajado con 24 a 48 horas de antelación, cambio del registro A y registros de correo (MX, SPF, DKIM y DMARC) intactos, para que el correo corporativo del dominio no se parase ni un minuto.

Cómo se midió, y cuánto vale esa medición

Antes: cabeceras F, SSL A. Después del endurecimiento: A+ en cabeceras, con escaneo forzado sin caché y sin avisos.

Ese A+ se leyó sobre el host de migración, en 2026, antes de cambiar el dominio en vivo. No nos consta un re-escaneo del dominio real después del cambio, así que no presentamos el A+ como resultado de producción.

Esto vale para cualquier web. Una nota de cabeceras es una foto fechada de un host, no una propiedad que la web adquiere para siempre. Un embebido nuevo, un plugin nuevo o el valor por defecto de un proveedor y la nota se mueve. Si quieres saber qué puntúa una web hoy, escanéala hoy.

La auditoría de enlaces, y por qué existe

Tras el cambio de DNS auditamos 24 páginas, 12 en cada idioma, enlace a enlace. Esa pasada localizó y corrigió todas las referencias al entorno de preparación que el primer reemplazo automático había dejado: en el pie global, en los CTA del maquetador, en los enlaces de consentimiento de los formularios, en varios PDF, en textos legales y en una fuente de iconos del tema.

La lección reutilizable: un reemplazo masivo puede ejecutarse en simulación y darse por hecho. Un cambio no está hecho hasta que se valida con una petición real contra el sitio en vivo.

Cierre, y lo que no afirmamos

El proyecto cerró con informe de entrega en PDF, trabajo técnico completo, auditoría de enlaces limpia y garantía técnica de 30 días. Cuatro días desde la adjudicación hasta el cierre técnico.

Lo que no afirmamos: levantar el bloqueo DNS es decisión de ese cliente, y las solicitudes de revisión de reputación presentadas al final seguían en manos de los revisores al cerrar.

El método, en orden

Este orden sirve también para la siguiente web. Medir con herramientas públicas que cualquiera puede repetir. Arreglar la configuración, no el relato. Volver a medir, diciendo sobre qué host y en qué fecha. Y auditar contra el sitio en vivo en lugar de contra el plan.