Seguridad, el factor de ranking SEO invisible

¿SEO y seguridad? ¿Qué relación tienen? La seguridad no es solo un tema tecnológico, también influye directamente en el SEO y en la confianza. La seguridad web desempeña hoy un papel clave en la confianza y la experiencia de usuario. La UX es un componente fundamental del SEO. 

Desde hace tiempo Google integra temas de seguridad en sus rankings. Las páginas HTTPS reciben preferencia y Chrome avisa activamente de formularios inseguros. En general, la seguridad es un factor SEO leve. En las Core Web Vitals la seguridad no actúa directamente, sino de forma indirecta a través de señales UX.

En auditorías SEO suelo usar la herramienta Screaming Frog para tener una visión rápida. Durante el rastreo también se revisan aspectos de seguridad y suelen salir los mismos errores o descuidos.

Problemas como estos no solo pueden crear vulnerabilidades, sino también minar la confianza de los usuarios y afectar el ranking.

Las 9 vulnerabilidades más comunes que afectan tu SEO

Un sitio inseguro no solo pierde confianza, también visibilidad. La falta de encabezados de seguridad y de problemas de seguridad en el código desperdicia presupuesto de rastreo, dificulta la indexación y empeora tu ranking. Al final de esta página encontrarás una checklist gratuita para descargar que te guía paso a paso.

Encabezados de seguridad faltantes

Los encabezados de seguridad son instrucciones que el servidor envía al navegador al cargar una página. Definen cómo deben mostrarse, cargarse o protegerse los contenidos. No los ves, pero su impacto es enorme. Sin ellos, tu sitio es como un coche sin airbags: funciona, pero estás desprotegido.

Falta X-Content-Type-Options

El encabezado X-Content-Type-Options: nosniff impide que los navegadores intenten “adivinar” el tipo de archivo (MIME sniffing).
Esto es crucial porque un atacante podría disfrazar un archivo CSS como JavaScript y el navegador podría ejecutarlo.

Este filtro asegura que el navegador respete el tipo de archivo declarado por el servidor y no decida por su cuenta.

Ejemplo: Apache

Header set X-Content-Type-Options "nosniff"

Ejemplo: nginx

add_header X-Content-Type-Options "nosniff";

Falta X-Frame-Options

Con este encabezado indicas si tu página puede incrustarse en un <iframe>. Sin él, un atacante podría incrustar tu sitio en una ventana invisible y engañar al usuario para que haga clic en botones sin darse cuenta (clickjacking).

Así evitas que alguien “envuelva” tu página en otra para engañar al visitante.

Opciones disponibles:

• DENY – Prohíbe toda incrustación
• SAMEORIGIN – Solo permite incrustación desde la misma dominio
• ALLOW-FROM uri – (obsoleto, solo antiguos navegadores)

Por lo general recomiendo SAMEORIGIN, a menos que ofrezcas intencionalmente una app o widget que deba incrustarse.

Además, configura la directiva frame-ancestors en tu CSP. Es el método más moderno, aunque conviene mantener X-Frame-Options por compatibilidad, pese a que devtools lo marquen como “legacy”.

Ejemplo: Apache

Header always set X-Frame-Options "SAMEORIGIN"

Ejemplo: nginx

add_header X-Frame-Options "SAMEORIGIN";

Falta Content-Security-Policy (CSP)

La CSP es un filtro que le dice al navegador qué tipos de contenido (scripts, imágenes, estilos) y de qué orígenes puede cargarlos. Así evitas la inyección de código malicioso de terceros (XSS).

En otras palabras: entregas al navegador una lista: “Solo carga recursos de estas fuentes; todo lo demás se bloquea”.

La CSP es de las configuraciones más complejas, ya que no basta con las fuentes obvias (archivos externos), sino también servicios como Google Analytics, scripts de Meta, Bing, plugins, etc.

Ejemplo CSP para Apache:

Con esta CSP básica solo se permiten recursos del propio servidor.

Header set Content-Security-Policy "default-src 'self';"

Esta CSP más avanzada permite recursos del servidor, seguimiento de Bing (bat.bing.com, bat.bing.net), Google Ads, Google Analytics, OpenStreetMap, y todos los recursos necesarios de WordPress (s.w.org, api.wordpress.org, inline scripts y estilos).

Header always set Content-Security-Policy "default-src 'self'; \
    script-src 'self' 'unsafe-inline' 'unsafe-eval' \
        https://bat.bing.com \
        https://www.google-analytics.com \
        https://www.googleadservices.com \
        https://pagead2.googlesyndication.com \
        https://s.w.org \
        https://api.wordpress.org; \
    style-src 'self' 'unsafe-inline'; \
    img-src 'self' data: \
        https://bat.bing.net \
        https://www.google-analytics.com \
        https://www.googleadservices.com \
        https://pagead2.googlesyndication.com \
        https://*.openstreetmap.org \
        https://s.w.org; \
    font-src 'self' data: https://s.w.org; \
    connect-src 'self' \
        https://bat.bing.com \
        https://bat.bing.net \
        https://www.google-analytics.com \
        https://www.googleadservices.com \
        https://pagead2.googlesyndication.com \
        https://api.wordpress.org \
        https://*.openstreetmap.org; \
    frame-src 'self'; \
    media-src 'self'; \
    object-src 'none'; \
    base-uri 'self'; \
    form-action 'self';"

Nota: aquí se muestra en varias líneas para claridad, pero en Apache la CSP debe ir en una sola línea en .htaccess. En nginx puede ser multilínea.

Falta Referrer-Policy

El encabezado Referrer-Policy determina cuánta información de la página anterior se envía al siguiente enlace. Es clave para no filtrar IDs de sesión, rutas personales o datos sensibles a terceros. Controlas si el navegador revela la URL de origen.

Valores recomendados:

• same-origin – Solo enviar referrer dentro de tu propio dominio
• no-referrer – No enviar información alguna
• strict-origin-when-cross-origin – En enlaces internos enviar URL completa

Ejemplo Referrer-Policy para Apache:

Header set Referrer-Policy "strict-origin-when-cross-origin"

Mejor práctica: usa strict-origin-when-cross-origin para equilibrar privacidad y analítica.

Falta Strict-Transport-Security (HSTS)

Con el encabezado HSTS indicas al navegador que tu sitio siempre debe usarse vía HTTPS. Incluso si el usuario escribe HTTP, el navegador redirige automáticamente a HTTPS (sin llamar de nuevo al servidor).

Explicado sencillamente: el navegador memoriza: “¡Esta página solo por HTTPS desde ahora!”

Parámetros:

• max-age=63072000 = 2 años
• includeSubDomains = aplica también a subdominios
• preload = Google puede incluir tu dominio en su lista HSTS

Ejemplo HSTS para Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Problemas de seguridad comunes en el código/contenido

Incluso con los encabezados bien configurados, fragmentos HTML, plugins o errores editoriales pueden abrir nuevas vulnerabilidades, afectando presupuesto de rastreo, ranking y confianza. A continuación, las trampas más frecuentes en el código o contenido que puedes arreglar fácilmente.

Contenido mixto (Mixed Content)

Cuando una página HTTPS carga recursos por HTTP (imágenes, scripts), hay “mixed content”. Los navegadores bloquean o advierten cada vez más. Tu sitio está asegurado, pero carga contenido inseguro. ¿No es contradictorio?

Solución:

Busca en el código todas las referencias http:// y cámbialas a https:// o a URLs relativas si son internas.

Como medida rápida, puedes añadir upgrade-insecure-requests en tu CSP. Así todas las peticiones HTTP se actualizan automáticamente a HTTPS, y después ajustas manualmente lo necesario.

Hack CSP contra contenido mixto

Content-Security-Policy: upgrade-insecure-requests

Enlaces HTTP internos o externos

Los enlaces que usan HTTP, ya sean internos o hacia otros sitios, se consideran obsoletos o inseguros.

Formulario en URL HTTP

Formularios que envían datos por conexiones inseguras (HTTP) suponen un gran riesgo. Los navegadores modernos a veces advierten al respecto.

Mejor práctica:

• Asegura que los formularios solo estén disponibles vía HTTPS
• Comprueba que formularios embebidos (de terceros) también usen HTTPS

Enlaces Cross-Origin inseguros

Si abres un enlace con target="_blank", la página nueva puede usar JavaScript para acceder y manipular la original (window.opener), por ejemplo, redirigirla.

¿Qué es “Cross-Origin”?

“Origen” (origin) define la procedencia de una web.

Un origin se define por tres elementos:

• Protocolo (http vs https)
• Dominio (ej. example.com)
• Puerto (ej. :80, :443)

Si alguna de esas cosas difiere, hay una situación Cross-Origin.

¿Cómo evitarlo?

Usa rel="noopener" (o mejor rel="noopener noreferrer") en enlaces externos con target="_blank".

Resumen final

Nueve errores típicos de configuración y contenido pueden costarte confianza, conversiones y visibilidad.

Priorizar es ganar: Empieza por los encabezados de mayor impacto y menor esfuerzo (X-Content-Type-Options, Referrer-Policy). Luego aborda la CSP y el contenido mixto como mini-proyecto, donde obtendrás los mayores efectos combinados en UX y SEO. Si dominas estos nueve puntos, tendrás una base sólida para sitios web tanto seguros como amigables para buscadores.