Skip to main content
← Back to blog

Guía SEO Paso 7: Seguridade — A Base que Google Espera en 2026

·13 min read·by LANGR SEO

Guía SEO Paso 7: Seguridade

Este é o Paso 7 da Guía SEO de 13 Pasos. A seguridade non só se trata de protexer usuarios — ten un impacto directo nas túas clasificacións de busca. Google utilizou HTTPS como unha sinal de clasificación desde 2014, e as expectativas só aumentaron.

A maioría dos propietarios de sitios consideran a seguridade como un binario: "Temos SSL, así que estamos seguros." Na realidade, Google evalúa unha ducia de sinais de seguridade. Os sitios con cabeceiras de seguridade adecuadas, certificados válidos e sen contido misto superan a aqueles que só teñen un certificado SSL básico — todo o resto sendo igual.

A boa noticia: a maioría das correccións de seguridade son configuracións únicas. Configuraas unha vez, e protexen as túas clasificacións de forma permanente.

Configuración de SSL

SSL (técnicamente TLS) cifra a conexión entre o teu servidor e os visitantes. Desde 2014, Google confirmou explícitamente HTTPS como unha sinal de clasificación. En 2026, non ter HTTPS non é só un problema de clasificación — Chrome marca os sitios HTTP como "Non Seguro" na barra de enderezos, destruíndo a confianza dos usuarios.

Requisitos para un SSL adecuado:

| Requisito | Por que | Como verificar | |--------------------|---------------------------------------------|----------------------------------| | Certificado válido | Expirado = advertencia no navegador = usuarios que abandonan | Comprobar a data de expiración | | Cadea completa | Cadenas incompletas fallan en algúns dispositivos | Proba de SSL Labs | | TLS 1.2+ | As versións anteriores teñen vulnerabilidades coñecidas | Proba de SSL Labs | | Sen SHA-1 | Desbotada, os navegadores rexeitan dela | Detalles do certificado | | Cobertura SAN | www e non-www deben estar ambos cubertos | Detalles do certificado | | Auto-renovación | Previne desastres de expiración | Configuración de Let's Encrypt / provedor |

Clasificación de SSL:

100% = Certificado válido + Cadea completa + TLS 1.3 + Cifrado forte + Auto-renovación
  0% = Certificado expirado ou ausente

Erros comúns de SSL:

  1. O certificado expira sen aviso — Configura o seguimento (Paso 6) como mínimo 30 días antes da expiración
  2. Cadea de certificado incompleta — O servidor debe enviar certificados intermedios, non só o da folla
  3. Contido misto — Páxina HTTPS carga recursos HTTP (imaxes, scripts, follas de estilos)
  4. Bucles de redirección — Ciclos HTTP → HTTPS → HTTP causados por CDN/proxy mal configurados
  5. Desaxeitación non-www vs www — O certificado cubre un pero non o outro

Vitoria rápida: Executa o teu dominio a través de SSL Labs (ssllabs.com/ssltest). Calquera cousa por debaixo dunha valoración "A" ten problemas de acción. A maioría dos provedores de hospedaxe solucionan isto cun clic.

Cabeceiras de Seguridade

As cabeceiras de seguridade son cabeceiras de resposta HTTP que instrúen aos navegadores sobre como comportarse ao cargar o teu sitio. Preven categorías enteiras de ataques — e os rastrexadores de Google verifícanas.

As cabeceiras de seguridade sonenciais:

Content-Security-Policy (CSP)

CSP é a cabeceira de seguridade máis potente. Indica aos navegadores exactamente que recursos (scripts, estilos, imaxes, fontes) están autorizados a cargar nas túas páxinas.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none';

Que prevén os CSP:

  • Ataques de scripting entre sitios (XSS)
  • Ataques de inxeción de datos
  • Clickjacking (a través de frame-ancestors)
  • Execución non autorizada de scripts (criptominadores, inxectores de anuncios)

Estratexia de implementación de CSP:

  1. Comeza con Content-Security-Policy-Report-Only (registra violacións sen bloquear)
  2. Monitorea os informes durante 1-2 semanas
  3. Blanquea fontes lexítimas
  4. Cambia ao modo de aplicación
  5. Engade report-uri ou report-to para o rexistro continuo de violacións

X-Frame-Options

Preven que o teu sitio se incruste en iframes en outros dominios (protección contra clickjacking).

X-Frame-Options: DENY

Ou se necesitas permitir o enmarcado de mesma orixe:

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

Preven que os navegadores fagan sniffing de tipo MIME (interpretando arquivos como tipos diferentes aos declarados).

X-Content-Type-Options: nosniff

Esta liña única prevén ataques onde un arquivo .jpg contén JavaScript oculto que o navegador podería executar.

Referrer-Policy

Controla cantidade de información de referencia que se envía cando os usuarios fan clic en enlaces do teu sitio.

Referrer-Policy: strict-origin-when-cross-origin

Isto envía a URL completa para solicitudes de mesma orixe, pero só a orixe (dominio) para solicitudes de orixe cruzada. Equilibra as necesidades de analítica cunha maior privacidade.

Permissions-Policy

Controla que funcións do navegador (cámara, micrófono, xeolocalización, etc.) se poden usar no teu sitio.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Deshabilitar funcións que non usas prevén que scripts de terceiros as abusen.

Exemplo de implementación de cabeceiras (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

Implementación de cabeceiras (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Implementación de cabeceiras (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Vitoria rápida: Engade todas as 5 cabeceiras anteriores á configuración do teu servidor. Isto leva 5 minutos e mellora inmediatamente a túa postura de seguridade en calquera ferramenta de escaneado.

HSTS Preload

HTTP Strict Transport Security (HSTS) informa aos navegadores que deben sempre usar HTTPS para o teu dominio — mesmo antes da primeira solicitude. Sen HSTS, a primeira visita ao teu sitio pode seguir usando HTTP (vulnerable a interceptación) antes de que suceda o redireccionamento a HTTPS.

Cabeceira HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

As tres directrices:

| Directriz | Significado | |--------------------|---------------------------------------------| | max-age=31536000 | Recorda isto durante 1 ano (en segundos) | | includeSubDomains| Aplícase tamén a todos os subdominios | | preload | Solicita inclusión nas listas de preload dos navegadores |

Lista de preload HSTS:

A protección HSTS definitiva. Os navegadores traen consigo unha lista incorporada de dominios que deben usar sempre HTTPS. Enviar o teu dominio a hstspreload.org significa:

  • Os visitantes por primeira vez obtén HTTPS inmediatamente (sen redireccionamento HTTP → HTTPS)
  • Imposible para os atacantes de degradar conexións
  • Permanente (difícil de eliminar unha vez enviado)

Requisitos para HSTS preload:

  1. Certificado HTTPS válido
  2. Redireccionar todo HTTP a HTTPS (incluíndo subdominios)
  3. Cabeceira HSTS con max-age >= 31536000
  4. A cabeceira HSTS inclúe includeSubDomains
  5. A cabeceira HSTS inclúe preload
  6. Todos os subdominios deben soportar HTTPS

Advertencia: Só envía a preload se TODOS os teus subdominios soportan HTTPS. A directriz includeSubDomains significa que calquera subdominio só HTTP será inaccesible.

Vitoria rápida: Se xa tes HTTPS en todos os subdominios, engade a cabeceira HSTS completa e envía a hstspreload.org. O proceso leva unhas semanas, pero a protección é permanente.

Exploración de Vulnerabilidades

A exploración automática de vulnerabilidades identifica problemas de seguridade coñecidos na túa estructura antes de que os atacantes os exploten.

Que verifica a exploración de vulnerabilidades:

  • Software desactualizado: WordPress, complementos, bibliotecas JavaScript con CVEs coñecidos
  • Arquivos expostos: .env, .git, wp-config.php, volcado de bases de datos
  • Fugas de información: Cabeceiras de versión do servidor, modo depuración, rastros de pila
  • Credenciais predeterminadas: Páxinas de administración sen autenticación, contrasinais predeterminados
  • Ports/servizos abertos: Servizos innecesarios expostos a internet
  • Puntos de inxeción: Formularios sen protección CSRF, entradas non validadas

Vulnerabilidades comúns por plataforma:

| Plataforma | Vulnerabilidade Principais | Solución | |------------|----------------------------|----------------------------------| | WordPress | Complementos desactualizados| Auto-actualización + WAF | | Shopify | Permisos de aplicación de terceiros| Auditoría da lista de aplicación trimestral | | Next.js | Rotas de API expostas | Middleware de autenticación + limitación de taxa | | Sitios estáticos | Malconfiguración de CDN | Revisar regras de caché | | Personalizado | Inxección SQL | Consultas parametrizadas |

Frecuencia de escaneado:

  • Diariamente: Escaneo automático de superficie (SSL, cabeceiras, arquivos expostos)
  • Semanalmente: Verificación de vulnerabilidades de dependencia (npm audit, escáner de complementos de WordPress)
  • Mensualmente: Escaneo profundo con probas autenticadas
  • Despois de cada implementación: Verificación de regresión

Vitoria rápida: Executa npm audit (Node.js) ou verifica a lista de complementos do teu CMS en busca de componentes desactualizados. Soluciona inmediatamente problemas de severidade crítica/alta.

Contido Misto

O contido misto ocorre cando unha páxina HTTPS carga recursos (imaxes, scripts, follas de estilos, iframes) a través de HTTP. Isto rompe parcialmente a cifrado e desencadea advertencias do navegador.

Tipos de contido misto:

| Tipo | Severidade | Exemplo | Comportamento do Navegador | |---------|------------|-------------------------------------|-------------------------------| | Activo | Alto | Script HTTP, iframe, CSS | Bloqueado por defecto | | Pasivo | Medio | Imaxe HTTP, vídeo, audio | Cargado con advertencia |

O contido misto activo é bloqueado por navegadores modernos — o que significa que os teus scripts e estilos simplemente non se cargarán. O contido misto pasivo carga pero mostra advertencias de seguridade.

Encontrar contido misto:

  1. Abre Chrome DevTools → Consola
  2. Busca advertencias de "Contido Misto"
  3. Alternativamente, escanea cun rastreador (Screaming Frog, LANGR)

Fontes comúns de contido misto:

  • URLs http:// codificadas no contido (publicacións do blog, descricións de produtos)
  • Widgets de terceiros que cargan recursos HTTP
  • Contido incrustado (vinculacións de YouTube vellas, widgets de redes sociais)
  • CSS background-image con URLs HTTP
  • Fuentes cargadas a través de HTTP

Corrixindo o contido misto:

<!-- Malo -->
<img src="http://example.com/image.jpg" />

<!-- Bo -->
<img src="https://example.com/image.jpg" />

<!-- O mellor (relativo ao protocolo, adapta ao protocolo da páxina) -->
<img src="//example.com/image.jpg" />

Corrixir base de datos (WordPress):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

Vitoria rápida: Abre a túa páxina de inicio en Chrome, pulsa F12, comproba a pestana de Consola en busca de advertencias de contido misto. Soluciona calquera que apareza — estas son directamente visibles para Google.

Riscos dos Scripts de Terceiros

Cada script externo que cargas é un potencial pasivo de seguridade (e de rendemento). Os scripts de terceiros poden:

  • Ser comprometidos (ataques de cadea de subministro)
  • Rastrear os teus usuarios sen consentimento (violación do GDPR)
  • Atrasar o teu sitio (bloqueo de renderizado, latencia de rede)
  • Romper funcionalidade (actualizacións de versión, caídas)
  • Inxectar contido non desexado (scripts de anuncios que fallan)

Audita os teus scripts de terceiros:

| Script | Necesario? | Nivel de Risco | Alternativa | |-------------------------------|-----------|----------------|-------------------------------| | Google Analytics | A miúdo si | Baixo | Seguimento do lado do servidor | | Widgets de chat | Quizais | Medio | Solucións auto-aloxadas | | Botóns de compartir sociais | Raramente | Medio | Enlaces de compartición estáticos | | Probas A/B | Ás veces | Alto | Probas do lado do servidor | | Pixels de reorientación | Decisión empresarial | Alto | Datos de primeira parte | | CDNs de fontes | Conveniente | Baixo | Fontes auto-aloxadas |

Mitigación de risco para scripts de terceiros esenciales:

  1. Integridade de subrecursos (SRI): A verificación de hash prevén que scripts manipulados se carguen
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. Restricións de CSP: Permitir só scripts de dominios coñecidos
  2. Iframes en contido illado: Aíslan widgets de terceiros
  3. Auditorías regulares: Revisión trimestral de todos os recursos externos
  4. Monitoreo: Alerta sobre novos dominios externos que aparecen nas túas páxinas

Vitoria rápida: Lista cada etiqueta