Aprende a auditar las 16 reglas de seguridad web más críticas en SEO: HTTPS, HSTS, CSP, X-Frame-Options, cabeceras de protección, secretos filtrados y seguridad SSL. Guía técnica con checklist.
Resumen: Antes de conquistar las primeras posiciones, hay que asegurarse de que el terreno es seguro. La seguridad web no es solo una cuestión técnica: Google usa HTTPS como señal de ranking, Chrome penaliza los sitios sin certificado y los usuarios abandonan páginas que el navegador marca como «No seguro». Esta guía detalla las 16 reglas que debes auditar para que la seguridad de tu web sea el equipamiento sólido que necesitas antes de seguir escalando.
Solicitar auditoría SEO gratuita → Ver servicios SEO →
Google lleva usando HTTPS como señal de ranking desde 2014. Fue un cambio sutil al principio — un pequeño empujón en el algoritmo — pero la señal no ha hecho más que ganar peso con los años. Hoy, un sitio sin HTTPS no solo está en desventaja técnica: Chrome lo marca como «No seguro» directamente en la barra de direcciones, y ese aviso de seguridad hace que los usuarios abandonen la página antes de ver el primer párrafo.
El impacto SEO de la seguridad web se ramifica en tres niveles:
Hay cuatro categorías de problemas que cubren prácticamente todos los errores de seguridad que aparecen en una auditoría: configuración HTTPS y SSL, cabeceras de protección HTTP, control de contenido mixto y exposición de secretos. A continuación, las 16 reglas concretas para auditarlas.
Estas tres reglas son el punto de partida. Sin ellas, el resto del equipamiento de seguridad no sirve de nada.
La primera regla es también la más elemental: todas las páginas del sitio deben estar disponibles exclusivamente a través de HTTPS. Ningún recurso — páginas, imágenes, scripts, fuentes — debe servirse en claro por HTTP.
Cómo verificarlo: introduce la URL de tu home con http:// en el navegador y comprueba que redirige automáticamente a https://. Después, usa una herramienta de rastreo para detectar si hay URLs internas que todavía sirven por HTTP.
✅ escala14.com supera esta regla: toda la web sirve por HTTPS sin excepciones.
No basta con tener el certificado instalado: el servidor debe forzar la redirección de cualquier petición HTTP a su equivalente HTTPS. Si acceder a http://tudominio.com muestra el sitio sin redirigir, los usuarios que escriban la URL sin protocolo pueden acabar navegando en claro sin saberlo.
La redirección debe ser un 301 (permanente), no un 302, para transferir el valor SEO de las URLs antiguas a las nuevas.
✅ escala14.com supera esta regla: cualquier petición HTTP se redirige correctamente a HTTPS.
Los formularios de login, registro o recuperación de contraseña deben enviar los datos siempre a un endpoint HTTPS. Si el action del formulario apunta a una URL HTTP, las credenciales del usuario viajan en claro y cualquier atacante en la misma red puede interceptarlas.
Esta regla es especialmente relevante en sitios con área privada, tiendas online o cualquier formulario que maneje datos sensibles.
✅ escala14.com supera esta regla: todos los formularios tienen su endpoint en HTTPS.
Tener HTTPS no es suficiente si la configuración SSL/TLS subyacente es deficiente. Estas tres reglas cubren los aspectos críticos del protocolo seguro.
Los protocolos SSL 3.0, TLS 1.0 y TLS 1.1 están considerados obsoletos y tienen vulnerabilidades conocidas (POODLE, BEAST, entre otras). Los navegadores modernos ya no los admiten y Google los trata como señal de configuración de seguridad deficiente.
El estándar actual exige TLS 1.2 como mínimo, siendo TLS 1.3 la versión recomendada por su mayor velocidad y seguridad.
Cómo verificarlo: herramientas como SSL Labs (ssllabs.com/ssltest/) analizan en detalle la configuración TLS de tu servidor y te dan una puntuación con los protocolos habilitados.
❌ escala14.com falla esta regla: durante nuestra propia auditoría detectamos que el servidor no tiene configurado correctamente el soporte de protocolos, lo que impide a los navegadores forzar conexiones seguras de forma óptima. Es uno de los cuatro fallos que estamos trabajando en corregir.
Un certificado SSL caducado hace que el navegador muestre un error de seguridad que impide al usuario acceder al sitio. Es un fallo crítico de disponibilidad además de seguridad: si el certificado expira en producción, tu web deja de ser accesible para la mayoría de usuarios.
Los certificados de Let’s Encrypt tienen una validez de 90 días y deben renovarse automáticamente. Los certificados comerciales suelen tener validez anual.
Acción preventiva: configura alertas de caducidad con al menos 30 días de antelación. La mayoría de paneles de hosting y servicios de monitorización incluyen esta funcionalidad.
⚠️ Advertencia en escala14.com: aunque el certificado está activo, la ausencia de HSTS (ver regla 6) significa que los navegadores no pueden garantizar conexiones seguras de forma proactiva, lo que expone al sitio a ataques de degradación incluso con el certificado en vigor.
La cabecera HSTS (Strict-Transport-Security) le indica al navegador que, una vez visitado el sitio por HTTPS, nunca debe intentar conectarse por HTTP en el futuro. Esta instrucción se almacena en el navegador durante el tiempo que especifica la cabecera (max-age).
Sin HSTS, un atacante puede ejecutar un ataque de tipo SSL stripping: interceptar la primera petición HTTP y evitar que el navegador establezca la conexión segura, aunque el servidor tenga HTTPS activo.
# Ejemplo de cabecera HSTS correcta
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadmax-age=31536000 — el navegador recuerda usar HTTPS durante 1 añoincludeSubDomains — aplica también a todos los subdominiospreload — permite incluir el dominio en la lista de preload de los navegadores❌ escala14.com falla esta regla: nuestra web no tiene configurada la cabecera HSTS. Esto significa que aunque la web sirve por HTTPS, un usuario que acceda por primera vez por HTTP podría ser víctima de un ataque de downgrade antes de que se establezca la conexión segura. Es el primer fallo que vamos a corregir.
Estas dos cabeceras protegen contra dos de los vectores de ataque más frecuentes en aplicaciones web: la inyección de scripts maliciosos (XSS) y la manipulación del tipo de contenido.
La cabecera Content-Security-Policy define exactamente qué recursos puede cargar una página: de qué dominios puede cargar scripts, estilos, imágenes, fuentes y conexiones. Es la defensa más efectiva contra ataques XSS (Cross-Site Scripting), donde un atacante inyecta código malicioso que el navegador ejecuta como si fuera legítimo.
Un ataque XSS típico funciona así: el atacante consigue que tu web sirva un script malicioso (por ejemplo, a través de un campo de formulario no sanitizado). Sin CSP, el navegador ejecuta ese script con todos los permisos de tu dominio — puede robar cookies de sesión, redirigir al usuario o modificar el contenido de la página.
# Ejemplo de CSP básica para un sitio estático
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;La CSP es la cabecera más compleja de configurar porque debe adaptarse exactamente a los recursos que carga tu web. Una CSP demasiado restrictiva puede romper funcionalidades; una demasiado permisiva no protege de nada.
⚠️ Advertencia en escala14.com: nuestra web no tiene configurada una política CSP. Para un sitio estático sin autenticación el riesgo es menor, pero es una capa de protección importante especialmente si en el futuro se integran scripts de terceros (analytics, chat, formularios externos).
La cabecera X-Content-Type-Options: nosniff impide que el navegador intente «adivinar» el tipo de contenido de una respuesta cuando el servidor no lo especifica correctamente. Sin esta cabecera, un navegador puede interpretar un archivo de texto como JavaScript y ejecutarlo — un vector de ataque conocido como MIME sniffing.
Un ejemplo práctico: si un atacante consigue subir un archivo de texto a tu servidor y el navegador lo interpreta como JavaScript, puede ejecutar código arbitrario en el contexto de tu dominio.
# Cabecera que resuelve el problema
X-Content-Type-Options: nosniffEs una cabecera de una sola línea, sin opciones de configuración: o está o no está. No hay motivo para no incluirla.
❌ escala14.com falla esta regla: la cabecera X-Content-Type-Options no está presente en las respuestas de nuestro servidor. Es una corrección de cinco minutos que añade una capa de protección sin ningún coste en rendimiento ni compatibilidad.
El clickjacking es un ataque en el que un atacante incrusta tu web en un <iframe> invisible sobre una página trampa. El usuario cree estar haciendo clic en elementos de la página trampa, pero en realidad está interactuando con tu web sin saberlo — puede estar confirmando transacciones, cambiando configuraciones o dando permisos.
La cabecera X-Frame-Options controla si tu página puede ser incrustada en un <iframe> por otro dominio.
# Opciones disponibles
X-Frame-Options: DENY # Nunca puede incrustarse en un iframe
X-Frame-Options: SAMEORIGIN # Solo puede incrustarse desde el mismo dominioDENY es la opción más segura para sitios que no necesitan ser incrustados en ningún lugar. SAMEORIGIN es útil si tienes partes de tu web que se muestran en iframes dentro del mismo dominio.
❌ escala14.com falla esta regla: la cabecera X-Frame-Options no está configurada, lo que significa que cualquier sitio externo podría incrustar nuestra web en un iframe sin restricciones. Es una exposición al clickjacking que vamos a resolver junto con el resto de cabeceras de seguridad.
Nota: la directiva
frame-ancestorsde la CSP es el sucesor moderno deX-Frame-Optionsy ofrece más control. Si configuras una CSP completa conframe-ancestors 'none'oframe-ancestors 'self', no necesitasX-Frame-Options. Sin embargo, para compatibilidad con navegadores más antiguos, lo más recomendable es incluir ambas.
La cabecera Permissions-Policy (antes llamada Feature-Policy) controla qué APIs del navegador puede usar tu página: cámara, micrófono, geolocalización, sensores, pantalla completa, etc. Limitar el acceso a estas APIs reduce la superficie de ataque en caso de que un script de terceros inyectado intente acceder a recursos del usuario.
# Ejemplo: bloquear acceso a cámara, micrófono y geolocalización
Permissions-Policy: camera=(), microphone=(), geolocation=()⚠️ Advertencia en escala14.com: nuestra web no tiene configurada la cabecera Permissions-Policy. Para un sitio informativo sin funcionalidades que requieran hardware del dispositivo, la configuración óptima es bloquear todas las APIs no utilizadas explícitamente.
Cuando un usuario hace clic en un enlace desde tu web hacia otro dominio, el navegador envía al destino la URL desde la que vino el usuario — esto se llama el referrer. Sin una política explícita, el comportamiento por defecto puede enviar URLs completas con parámetros sensibles a dominios externos.
La cabecera Referrer-Policy te permite controlar exactamente qué información comparte tu web con terceros.
# Política recomendada para la mayoría de sitios
Referrer-Policy: strict-origin-when-cross-originCon strict-origin-when-cross-origin, los links internos (mismo origen) comparten la URL completa, pero los links externos solo reciben el dominio de origen — sin ruta ni parámetros.
⚠️ Advertencia en escala14.com: la cabecera Referrer-Policy no está configurada en nuestra web. Esto no es un fallo crítico para un sitio informativo sin URLs con parámetros sensibles, pero es una buena práctica de privacidad que vamos a incluir junto con el resto de cabeceras.
Las URLs con protocolo relativo tienen el formato //ejemplo.com/recurso (sin http: ni https: explícito). El navegador hereda el protocolo de la página donde se carga el recurso: si la página es HTTPS, carga el recurso por HTTPS; si es HTTP, lo carga por HTTP.
Aunque en sitios que ya son 100% HTTPS este comportamiento es inofensivo, las URLs relativas de protocolo son una fuente de mixed content en entornos de desarrollo HTTP y dificultan la migración y el mantenimiento. La práctica recomendada es siempre usar URLs absolutas con https:// explícito.
✅ escala14.com supera esta regla: no hay URLs con protocolo relativo en el código del sitio.
El contenido mixto (mixed content) ocurre cuando una página servida por HTTPS carga algún recurso — imagen, script, hoja de estilos, fuente — por HTTP. Es uno de los problemas de seguridad más frecuentes en migraciones HTTP→HTTPS mal ejecutadas.
Hay dos tipos de mixed content:
En ambos casos, el resultado es una web que no funciona como se espera y que transmite señales negativas tanto a los usuarios como a Google.
Cómo detectarlo con DevTools:
✅ escala14.com supera esta regla: no hay contenido mixto. Todos los recursos se cargan por HTTPS.
Los formularios cuyo atributo action apunta a una URL HTTP envían los datos del usuario en claro, aunque la página donde está el formulario sea HTTPS. Chrome y Firefox muestran avisos específicos cuando detectan este patrón.
<!-- Incorrecto: el formulario está en HTTPS pero envía datos por HTTP -->
<form action="http://tudominio.com/procesar" method="POST">
<!-- Correcto -->
<form action="https://tudominio.com/procesar" method="POST">✅ escala14.com supera esta regla: todos los formularios del sitio envían datos a endpoints HTTPS.
Una de las vulnerabilidades más graves — y más frecuentes en proyectos que empiezan rápido — es dejar credenciales, claves de API, tokens de autenticación o contraseñas directamente en el código fuente del sitio. Si ese código es accesible públicamente (un repositorio abierto, el bundle de JavaScript del frontend), esas credenciales quedan expuestas a cualquier persona.
Los patrones más frecuentes que buscan los auditores automáticos:
apiKey: "AIzaSy...", api_key = "sk-...")Authorization: Bearer eyJ...)Práctica fundamental: usa variables de entorno para todas las credenciales. Nunca las escribas en el código fuente, nunca las subas a un repositorio git (añade .env al .gitignore), y rota cualquier credencial que sospechas que pueda haberse expuesto.
✅ escala14.com supera esta regla: no hay secretos filtrados en el código fuente del sitio.
Los links que abren en nueva pestaña (target="_blank") dan acceso a la nueva página al objeto window.opener de la página de origen — lo que permite a una página maliciosa redirigir la pestaña original. Este ataque se llama reverse tabnapping.
La solución es añadir rel="noopener noreferrer" a todos los links con target="_blank":
<!-- Vulnerable -->
<a href="https://externo.com" target="_blank">Ver más</a>
<!-- Seguro -->
<a href="https://externo.com" target="_blank" rel="noopener noreferrer">Ver más</a>Desde 2021, los navegadores modernos aplican noopener de forma implícita en links con target="_blank", pero incluirlo explícitamente es la práctica recomendada para compatibilidad con navegadores más antiguos y para dejar la intención clara en el código.
✅ escala14.com supera esta regla: los links externos tienen los atributos de seguridad correctos.
Una auditoría de seguridad puede devolver desde un fallo hasta una docena de issues simultáneos. El orden de ataque debe seguir la severidad del riesgo real y el esfuerzo de implementación:
| Prioridad | Regla | Impacto | Esfuerzo |
|---|---|---|---|
| Crítica | HSTS ausente | Ataques de downgrade; sin HSTS el HTTPS no está garantizado | Bajo — una línea de configuración en el servidor |
| Crítica | X-Frame-Options ausente | Exposición a clickjacking | Bajo — una cabecera de servidor |
| Crítica | X-Content-Type-Options ausente | Vulnerabilidad a MIME sniffing | Bajo — una cabecera de servidor |
| Crítica | Protocolo TLS desactualizado | Vulnerabilidades SSL conocidas (POODLE, BEAST) | Medio — configuración del servidor web |
| Alta | CSP ausente | Sin protección contra XSS | Alto — requiere mapear todos los recursos del sitio |
| Alta | Permissions-Policy ausente | APIs del navegador sin restringir | Bajo — una cabecera de servidor |
| Alta | Referrer-Policy ausente | Posible fuga de información en referrers | Bajo — una cabecera de servidor |
| Alta | Certificado SSL próximo a expirar | Riesgo de caída del servicio | Bajo — renovación automática |
| Media | Mixed content | Recursos bloqueados o aviso de seguridad | Variable — localizar y corregir cada recurso HTTP |
| Baja | Formularios en HTTP | Datos enviados en claro | Bajo si la web ya es HTTPS |
| Baja | URLs de protocolo relativo | Riesgo en entornos HTTP | Bajo — búsqueda y reemplazo en el código |
Consejo práctico: las cabeceras de seguridad (HSTS, X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Referrer-Policy) se configuran todas en el mismo lugar — el servidor web o el CDN — y se pueden implementar en una sola sesión de trabajo. Si tienes un hosting con panel de control, busca la sección de cabeceras HTTP personalizadas. Si tienes acceso a la configuración de Nginx o Apache, añádelas en el bloque del servidor.
Nuestro plan en escala14.com: los cuatro fallos críticos y las cuatro advertencias que detectamos en nuestra propia auditoría son correcciones de configuración de servidor. Ninguna requiere cambios en el código del sitio. Las implementaremos todas en una sola actualización de la configuración del CDN.
Usa esta lista como referencia en cada auditoría. El estado indica el resultado de la auditoría sobre escala14.com como referencia real:
HTTPS y contraseñas (1–3)
SSL/TLS y HSTS (4–6)
Strict-Transport-Security con max-age de al menos 1 añoCabeceras de inyección (7–8)
Content-Security-Policy configurada y adaptada a los recursos del sitioX-Content-Type-Options: nosniff presente en todas las respuestasCabeceras anti-clickjacking (9–10)
X-Frame-Options: DENY o SAMEORIGIN (o CSP con frame-ancestors)Permissions-Policy configurada para bloquear APIs no utilizadasPolítica de referencia (11–12)
Referrer-Policy: strict-origin-when-cross-origin configurada//ejemplo.com) en el código fuenteContenido mixto (13–14)
action apuntando a URLs HTTPSecretos y links externos (15–16)
target="_blank" incluyen rel="noopener noreferrer"Resultado de escala14.com: 8 superadas ✅ · 4 advertencias ⚠️ · 4 fallos ❌ → Score: 90/A
Sí. Google confirmó en 2014 que HTTPS es una señal de ranking. El peso de esa señal es relativamente pequeño comparado con factores como la relevancia del contenido o la autoridad de enlace, pero en nichos competitivos puede ser el factor diferenciador entre dos páginas de calidad similar. Más allá del ranking, el impacto en la confianza del usuario es inmediato: Chrome marca los sitios HTTP como «No seguro» de forma visible.
HTTPS significa que la conexión entre el navegador y el servidor está cifrada. HSTS (HTTP Strict Transport Security) es una instrucción adicional que le dice al navegador que en el futuro solo intente conectarse a ese dominio por HTTPS, sin pasar por HTTP. Sin HSTS, el primer acceso de un usuario por HTTP ocurre en claro antes de la redirección. Con HSTS, el navegador va directamente a HTTPS desde la primera visita (después de haberlo visitado una vez).
Sí, si no se hace con cuidado. Una Content-Security-Policy demasiado restrictiva puede bloquear scripts legítimos, estilos en línea, fuentes de Google Fonts o píxeles de seguimiento. Lo mejor es empezar con la cabecera en modo Content-Security-Policy-Report-Only — que solo reporta violaciones sin bloquear nada — analizar los reportes durante unos días y luego afinar la política antes de activarla en modo restrictivo.
Hay varias opciones rápidas y gratuitas: securityheaders.com analiza todas las cabeceras HTTP de tu dominio y te da una nota con los problemas detectados; SSL Labs (ssllabs.com/ssltest/) audita en detalle la configuración TLS; y las DevTools de Chrome (pestaña Network → selecciona cualquier recurso → Headers) te muestran las cabeceras que devuelve tu servidor en tiempo real.
No de forma apreciable. Las cabeceras HTTP tienen un tamaño de bytes despreciable y no añaden ninguna carga de procesamiento al servidor. Las únicas cabeceras que requieren ajuste fino por su impacto funcional son la CSP (que puede bloquear recursos) y HSTS (que, una vez activada con un max-age largo, compromete al dominio a servir siempre por HTTPS). El resto — X-Frame-Options, X-Content-Type-Options, Permissions-Policy, Referrer-Policy — son cambios de configuración de bajo riesgo con beneficio de seguridad inmediato.
La seguridad web es el equipamiento base que necesitas antes de empezar a escalar posiciones. Un sitio con HTTPS mal configurado, sin cabeceras de protección y con posibles fugas de credenciales es como intentar una ascensión con material defectuoso: puede que llegues lejos, pero el riesgo aumenta a cada paso.
Con estas 16 reglas como guía, tienes un mapa claro de qué revisar, qué priorizar y cómo resolver cada fallo. La mayoría de las correcciones son cambios de configuración de servidor que puedes implementar en una tarde — y el resultado es una web más segura, más confiable y mejor preparada para el ascenso SEO.
Si quieres que revisemos la seguridad de tu web y te entreguemos un informe con los problemas priorizados, cuéntanos qué necesitas. Sin compromiso.
Solicitar auditoría SEO gratuita → Ver servicios SEO → Links en SEO: 19 reglas para auditar →
Audita las 10 reglas de internacionalización SEO: atributo lang correcto, validación de hreflang, return links, conflictos y mismatches. Guía técnica con ejemplos de código y herramientas.
Aprende a detectar y corregir los 5 problemas móviles que Google comprueba en tu web: tamaños de fuente, scroll horizontal, intersticiales intrusivos y configuración del viewport. Guía técnica con checklist.
Una redirección mal configurada puede costar posiciones, link equity y rastreabilidad. Audita las 8 reglas de redirects SEO: bucles, tipos 301/302, meta refresh, JavaScript redirects y más.
/ Volver al campamento
Más de 20 artículos publicados sobre SEO, diseño web y marketing digital, con datos reales y reglas auditables.