Por qué la seguridad de tu web importa para el negocio
Tres motivos prácticos por los que la seguridad web NO es opcional:
Razón 1: Google penaliza webs inseguras. Webs sin HTTPS aparecen marcadas como “No seguro” en Chrome. CTR baja un 30-50 %. Google las rankea peor.
Razón 2: Los navegadores bloquean contenido. Si tu web es HTTP, Chrome y Safari bloquean formularios, descargas y enlaces a HTTPS. Pierdes funcionalidad.
Razón 3: Una web hackeada pierde la confianza de los clientes. Tras un incidente público, tardas meses en recuperar la marca. A veces no se recupera.
Esta guía te enseña a auditar la seguridad web nivel pyme sin necesidad de ser experto en ciberseguridad.
Paso 1: HTTPS forzado y certificado válido
Comprueba el certificado SSL
Abre tu web en Chrome. Mira el candado al lado de la URL:
- Candado cerrado verde/gris: certificado OK
- Candado tachado o “No seguro”: tienes problema
Si tu web es HTTP, pídele a tu hosting que active SSL. Today es gratis con Let’s Encrypt. Si te cobran por SSL en 2026, cambia de hosting (es inaceptable).
Comprueba la redirección HTTP → HTTPS
Escribe http://tudominio.es (con HTTP, no HTTPS). Debes ir automáticamente a https://tudominio.es con un código 301.
Errores típicos:
- No redirige (queda en HTTP)
- Redirige con código 302 (Google penaliza vs 301)
- Cadena de redirects (HTTP → HTTPS sin www → HTTPS con www)
La cadena correcta:
http://tudominio.es → 301 → https://tudominio.es (un solo salto)
http://www.tudominio.es → 301 → https://tudominio.es (un solo salto)
https://www.tudominio.es → 301 → https://tudominio.es (un solo salto)
Cualquier otro patrón pierde rendimiento.
Comprueba que no hay mixed content
“Mixed content” significa que tu web es HTTPS pero carga recursos (imágenes, scripts, CSS) por HTTP. Chrome los bloquea.
Detecta:
- Abre Chrome DevTools (F12)
- Pestaña “Console”
- Recarga la página
- Mira si hay warnings de mixed content
Si hay, son recursos con URLs http://... en tu HTML/CSS. Cámbialas a https:// o relativas (//).
Paso 2: HSTS (HTTP Strict Transport Security)
HSTS es un header que le dice al navegador “siempre conéctate por HTTPS, nunca HTTP”. Evita ataques tipo “downgrade”.
Cómo comprobarlo
Abre securityheaders.com, introduce tu URL. Mira el grado de seguridad y los headers presentes.
Tu header HSTS debe ser:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age en segundos (31536000 = 1 año). includeSubDomains aplica a todos tus subdominios. preload te incluye en la lista de Chrome.
Cómo configurarlo
Depende del hosting:
- Cloudflare: panel → SSL/TLS → Edge Certificates → activar HSTS
- NGINX:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; - Apache:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" - Cloudflare Pages / Vercel / Netlify: en
_headerso equivalente
Paso 3: Headers de seguridad esenciales
X-Content-Type-Options
Evita que el navegador interprete archivos como otra cosa de la que dicen.
X-Content-Type-Options: nosniff
X-Frame-Options
Evita que tu web se cargue en iframes (protección contra clickjacking).
X-Frame-Options: DENY
O SAMEORIGIN si necesitas embedded propio.
Referrer-Policy
Controla qué info del referrer se envía al hacer clic en enlaces externos.
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
Controla qué APIs del navegador puede usar tu web (cámara, micrófono, geolocalización).
Permissions-Policy: camera=(), microphone=(), geolocation=()
Si no usas estas APIs, ciérralas. Reduce vector de ataque.
Content-Security-Policy (CSP)
El más complejo de configurar pero el de mayor impacto. Define qué fuentes de scripts, imágenes, fuentes y datos puede cargar tu web. Bloquea XSS y código inyectado.
Ejemplo básico:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; img-src 'self' data: https:;
CSP es delicado: una regla mal puesta rompe tu web. Empieza en modo “Report-Only” para detectar problemas antes de aplicarlo.
Paso 4: Permisos y autenticación
Comprueba que NO tienes login expuesto sin protección
Si tu CMS es WordPress, /wp-admin/ está expuesto por defecto. Comprueba:
- ¿Has cambiado el slug de admin? (
/wp-admin/→/panel-secreto/) - ¿Tienes 2FA activado en cuentas admin?
- ¿Limitas intentos de login (Wordfence, Limit Login Attempts)?
- ¿Tu contraseña admin es robusta (mínimo 14 caracteres, mixta)?
XML-RPC desactivado en WordPress
XML-RPC es un protocolo legacy de WordPress que se usa para ataques DDoS y brute force. Desactívalo si no lo necesitas:
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
Información del servidor expuesta
Comprueba los headers de respuesta. Si te muestra:
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3
Estás filtrando versiones exactas de software, facilitando a los atacantes saber qué exploits usar. Configura tu servidor para ocultar versiones.
Paso 5: Vulnerabilidades comunes en WordPress
Si tu web es WordPress (el 40 % de las webs lo son), ten especialmente cuidado:
Plugins desactualizados
El 60 % de los hackeos de WordPress vienen de plugins desactualizados. Audita:
- Lista de plugins instalados
- ¿Todos actualizados a última versión?
- ¿Hay plugins abandonados (sin update en 2+ años)?
- ¿Hay plugins activos que no usas? Bórralos.
Temas pirateados
Plantillas “premium” descargadas de sitios gratis suelen tener malware. Si tu tema es pirateado, hay 70 % de probabilidad de que esté comprometido.
Backups
¿Tienes backup automatizado diario fuera del propio servidor? Si tu hosting es hackeado, los backups del propio hosting también pueden estar comprometidos.
Recomendación: UpdraftPlus + Google Drive externo, o el backup nativo de tu hosting hacia almacenamiento externo.
Plugins de seguridad
Mínimo recomendado en WordPress:
- Wordfence (firewall, malware scan)
- Limit Login Attempts Reloaded (anti brute force)
- WP Hide (oculta info de WordPress)
Paso 6: Comprueba si tu web ha sido comprometida
Search Console: alertas de seguridad
Sección “Seguridad y acciones manuales” → “Problemas de seguridad”. Si Google ha detectado malware en tu web, aparece aquí.
Sucuri SiteCheck
sitecheck.sucuri.net escanea tu URL en busca de malware conocido, blacklists y problemas de seguridad. Gratis.
Have I Been Pwned (para emails de admin)
haveibeenpwned.com te dice si los emails de tus cuentas admin aparecen en bases de datos filtradas. Si aparece tu email + contraseña, asume comprometido y cambia.
Paso 7: SSL Labs (auditoría profesional gratuita)
ssllabs.com/ssltest audita exhaustivamente tu certificado SSL y configuración. Objetivo: grado A o A+.
Si sales con B, C o peor, hay problemas serios:
- Protocolos TLS antiguos habilitados (TLS 1.0, 1.1 deben estar deshabilitados)
- Cipher suites débiles
- Certificate chain incompleto
Corrige en el panel de hosting o pide al admin que lo arregle.
Cómo automatizar el monitoreo
Una vez bien configurado, monitoriza para detectar problemas:
- Uptime Robot (gratis): te avisa si tu web se cae
- Sucuri o Wordfence: monitorizan malware
- Google Search Console: alertas de seguridad automáticas
- Auditoría manual cada 3-6 meses: ejecuta los pasos de arriba
Coste de no auditar la seguridad
Casos reales que vemos en pymes:
- Web hackeada con malware → 500-2.000 € en limpieza + 30-60 días de tráfico perdido
- Search Console marca “sitio no seguro” → CTR cae 60 %, recuperación en 4-12 semanas
- Cuenta admin comprometida → contenido alterado, redirects maliciosos, pérdida de credibilidad
- Multas RGPD por filtración de datos → entre 600 € y 20.000 € según gravedad
La auditoría te lleva 2-3 horas y previene todo esto.
Siguientes pasos
- Audita los headers de seguridad en securityheaders.com.
- Audita tu SSL en ssllabs.com/ssltest.
- Lee la guía completa de auditoría web.
- Si tu web es WordPress con problemas estructurales acumulados, considera migrar a arquitectura estática.
Aplicable a estos sectores
Esta guía aplica especialmente a estos sectores donde trabajamos: