Seguretat, el factor de classificació SEO invisible

SEO i seguretat? Quina relació tenen? La seguretat no és només un tema tecnològic, també influeix directament en el SEO i en la confiança. Avui, la seguretat web juga un paper clau en la confiança i l’experiència d’usuari. La UX és un component fonamental del SEO.

Des de fa temps, Google integra temes de seguretat als seus rànquings. Les pàgines HTTPS reben preferència i Chrome avisa activament dels formularis insegurs. En general, la seguretat és un factor SEO lleu. En les Core Web Vitals la seguretat no actua directament, sinó de manera indirecta mitjançant senyals UX.

En les auditories SEO acostumo a fer servir l’eina Screaming Frog per tenir una visió ràpida. Durant el rastreig també es revisen aspectes de seguretat i solen aparèixer els mateixos errors o descuits.

Problemes com aquests no només poden crear vulnerabilitats, sinó també minar la confiança dels usuaris i afectar la classificació.

Les 9 vulnerabilitats més comunes que afecten el teu SEO

Un lloc insegur no només perd confiança, sinó també visibilitat. La manca de encapçalaments de seguretat i de problemes de seguretat en el codi malgasta pressupost de rastreig, dificulta la indexació i empitjora la teva classificació. Al final d’aquesta pàgina trobaràs una llista de comprovació gratuïta per descarregar que et guia pas a pas.

Encapçalaments de seguretat absents

Els encapçalaments de seguretat són instruccions que el servidor envia al navegador en carregar una pàgina. Defineixen com s’han de mostrar, carregar o protegir els continguts. No els veus, però el seu impacte és enorme. Sense ells, el teu lloc és com un cotxe sense airbages: funciona, però estàs desprotegit.

Absència de X-Content-Type-Options

L’encapçalament X-Content-Type-Options: nosniff impedeix que els navegadors intentin “endevinar” el tipus de fitxer (MIME sniffing).
Això és crucial perquè un atacant podria disfressar un fitxer CSS com JavaScript i el navegador podria executar-lo.

Aquest filtre assegura que el navegador respecti el tipus de fitxer declarat pel servidor i no decideixi per si mateix.

Exemple: Apache

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

Exemple: nginx

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

Absència de X-Frame-Options

Amb aquest encapçalament indiques si la teva pàgina es pot incrustar en un <iframe>. Sense ell, un atacant podria incrustar el teu lloc en una finestra invisible i enganyar l’usuari perquè faci clic en botons sense adonar-se’n (clickjacking).

Així evites que algú “envolupi” la teva pàgina dins d’una altra per enganyar el visitant.

Opcions disponibles:

• DENY – Prohibeix tota incrustació
• SAMEORIGIN – Només permet incrustació des del mateix domini
• ALLOW-FROM uri – (obsolet, només navegadors antics)

En general, recomano SAMEORIGIN, llevat que ofereixis intencionadament una aplicació o widget que hagi d’incrustar-se.

A més, configura la directiva frame-ancestors a la teva CSP. És el mètode més modern, encara que convé mantenir X-Frame-Options per compatibilitat, tot i que devtools el marqui com “legacy”.

Exemple: Apache

Header always set X-Frame-Options "SAMEORIGIN"

Exemple: nginx

add_header X-Frame-Options "SAMEORIGIN";

Absència de Content-Security-Policy (CSP)

La CSP és un filtre que diu al navegador quins tipus de contingut (scripts, imatges, estils) i de quins orígens es poden carregar. Així evites la injecció de codi maliciós de tercers (XSS).

En altres paraules: lliures al navegador una llista: “Només carrega recursos d’aquestes fonts; tot el demés es bloqueja”.

La CSP és una de les configuracions més complexes, ja que no n’hi ha prou amb les fonts evidents (fitxers externs), sinó que també cal incloure serveis com Google Analytics, scripts de Meta, Bing, plugins, etc.

Exemple CSP per a Apache:

Aquesta CSP bàsica només permet recursos del propi servidor.

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

Aquesta CSP més avançada permet recursos del servidor, seguiment de Bing (bat.bing.com, bat.bing.net), Google Ads, Google Analytics, OpenStreetMap i tots els recursos necessaris de WordPress (s.w.org, api.wordpress.org, scripts i estils en línia).

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í es mostra en diverses línies per claredat, però en Apache la CSP ha d’anar en una sola línia a .htaccess. A nginx pot ser multilínia.

Absència de Referrer-Policy

L’encapçalament Referrer-Policy determina quanta informació de la pàgina anterior s’envia a l’enllaç següent. És clau per no filtrar IDs de sessió, rutes personals o dades sensibles a tercers. Controla si el navegador revela l’URL d’origen.

Valors recomanats:

• same-origin – Només enviar el referrer dins del teu propi domini
• no-referrer – No enviar cap informació
• strict-origin-when-cross-origin – En enllaços interns enviar l’URL completa

Exemple Referrer-Policy per a Apache:

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

Millor pràctica: usa strict-origin-when-cross-origin per equilibrar privadesa i analítica.

Absència de Strict-Transport-Security (HSTS)

Amb l’encapçalament HSTS indiques al navegador que el teu lloc sempre s’ha d’utilitzar via HTTPS. Fins i tot si l’usuari escriu HTTP, el navegador redirigeix automàticament a HTTPS (sense tornar a trucar al servidor).

Explicat senzillament: el navegador memoritza: “Aquesta pàgina només per HTTPS des d’ara!”

Paràmetres:

• max-age=63072000 = 2 anys
• includeSubDomains = s’aplica també a subdominis
• preload = Google pot incloure el teu domini a la seva llista HSTS

Exemple HSTS per a Apache:

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

Problemes de seguretat comuns al codi/contingut

Fins i tot amb els encapçalaments ben configurats, fragments HTML, plugins o errors editorials poden obrir noves vulnerabilitats, afectant el pressupost de rastreig, la classificació i la confiança. A continuació, les trampes més freqüents al codi o contingut que pots solucionar fàcilment.

Contingut mixt (Mixed Content)

Quan una pàgina HTTPS carrega recursos per HTTP (imatges, scripts), hi ha “mixed content”. Els navegadors bloquegen o avisen cada cop més. El teu lloc està assegurat, però carrega contingut insegur. No és contradictori?

Solució:

Cerca al codi totes les referències http:// i substitueix-les per https:// o per URLs relatives si són internes.

Com a mesura ràpida, pots afegir upgrade-insecure-requests a la teva CSP. Així totes les peticions HTTP s’actualitzen automàticament a HTTPS, i després ajustes manualment allò necessari.

Hack CSP contra contingut mixt

Content-Security-Policy: upgrade-insecure-requests

Enllaços HTTP interns o externs

Els enllaços que utilitzen HTTP, tant si són interns com si apunten a altres llocs, es consideren obsolets o insegurs.

Formulari en URL HTTP

Formularis que envien dades per connexions insegures (HTTP) suposen un gran risc. Els navegadors moderns de vegades en avisen.

Millor pràctica:

• Assegura que els formularis només estiguin disponibles via HTTPS
• Comprova que els formularis incrustats (de tercers) també utilitzin HTTPS

Enllaços Cross-Origin insegurs

Si obres un enllaç amb target="_blank", la pàgina nova pot utilitzar JavaScript per accedir i manipular l’original (window.opener), per exemple, redirigir-la.

Què és “Cross-Origin”?

“Origen” (origin) defineix la procedència d’una web.

Un origin es defineix per tres elements:

• Protocol (http vs https)
• Domini (p. ex. example.com)
• Port (p. ex. :80, :443)

Si algun d’aquests elements difereix, hi ha una situació Cross-Origin.

Com evitar-ho?

Utilitza rel="noopener" (o millor rel="noopener noreferrer") en enllaços externs amb target="_blank".

Resum final

Nou errors típics de configuració i contingut et poden costar confiança, conversions i visibilitat.

Prioritzar és guanyar: Comença amb els encapçalaments de més impacte i menys esforç (X-Content-Type-Options, Referrer-Policy). Després ocupa’t de la CSP i del contingut mixt com un mini-projecte, on obtindràs els majors efectes combinats en UX i SEO. Si domines aquests nou punts, tindràs una base sòlida per a llocs web tant seguros com amigables per als cercadors.