HTTPS et SEO : configuration SSL/TLS sans erreurs

Un site e-commerce de 22 000 pages migre vers HTTPS en 2024. Le certificat est valide, le cadenas s'affiche. Pourtant, six semaines plus tard, le trafic organique a chuté de 34 %. Le coupable : des milliers de redirections en chaîne HTTP → HTTPS → HTTPS avec trailing slash, un header HSTS absent, et du mixed content sur 40 % des pages produit. Le cadenas vert ne suffit pas — c'est la configuration derrière qui fait ou défait le SEO.

Le signal HTTPS : ce qu'il pèse réellement dans le ranking

Google a confirmé HTTPS comme signal de classement dès 2014. Mais le poids réel de ce signal est souvent surestimé. La documentation officielle de Google Search Central le qualifie de "lightweight ranking signal" — un signal léger, qui départage à la marge deux pages de qualité équivalente.

Le vrai impact de HTTPS sur le SEO n'est pas dans le boost de ranking. Il est indirect et se manifeste à trois niveaux :

Chrome et les navigateurs. Depuis Chrome 68 (juillet 2018), toute page HTTP est marquée "Non sécurisé" dans la barre d'adresse. Sur mobile, ce badge rouge augmente le taux de rebond de façon mesurable. Vous perdez du trafic non pas parce que Google vous déclasse, mais parce que les utilisateurs fuient.

Les referrers. Un lien depuis un site HTTPS vers un site HTTP envoie un header Referer vide par défaut (la spec HTTP interdit le downgrade de sécurité du referrer). Vous perdez des données analytics, mais surtout, certains mécanismes de crawl discovery de Googlebot reposent sur ces referrers. Moins de signaux, moins de crawl.

HTTP/2 et HTTP/3. Les gains de performance liés à HTTP/2 (multiplexage, server push, header compression) ne sont disponibles que sur HTTPS dans la quasi-totalité des implémentations navigateur. Sans HTTPS, vous restez sur HTTP/1.1, ce qui impacte directement vos Core Web Vitals — notamment le LCP.

Choisir et configurer le bon certificat TLS

Types de certificats : DV, OV, EV

Google ne fait aucune distinction entre un certificat Domain Validation (DV) à 0 € via Let's Encrypt et un Extended Validation (EV) à 500 €/an. Le ranking signal est identique. La différence est purement côté confiance utilisateur — et depuis que les navigateurs ont supprimé la barre verte EV (Chrome 77, septembre 2019), même cet avantage a disparu.

Pour le SEO pur, un certificat DV suffit. Utilisez Let's Encrypt avec certbot pour l'automatisation :

# Installation certbot sur Ubuntu/Debian avec Nginx
sudo apt update && sudo apt install certbot python3-certbot-nginx -y

# Obtention et installation automatique du certificat
sudo certbot --nginx -d www.monsite-ecommerce.fr -d monsite-ecommerce.fr

# Vérifier le renouvellement automatique
sudo certbot renew --dry-run

# Le cron de renouvellement est ajouté automatiquement dans
# /etc/cron.d/certbot ou via systemd timer

La chaîne de certificats : un piège silencieux

L'erreur la plus fréquente n'est pas le certificat lui-même, mais une chaîne de certificats incomplète. Votre serveur doit servir le certificat leaf ET les certificats intermédiaires. Si un intermédiaire manque, certains clients (dont Googlebot dans certaines configurations) échouent à valider la chaîne.

Vérifiez avec openssl :

# Tester la chaîne complète
openssl s_client -connect www.monsite-ecommerce.fr:443 -servername www.monsite-ecommerce.fr 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Vérification approfondie avec affichage de toute la chaîne
openssl s_client -connect www.monsite-ecommerce.fr:443 -servername www.monsite-ecommerce.fr -showcerts 2>/dev/null | grep -E "s:|i:"

# Résultat attendu : 2 ou 3 certificats (leaf + intermediate(s))
# Si vous ne voyez que le leaf, la chaîne est incomplète

Autre outil indispensable : SSL Labs Server Test de Qualys. Visez un score A ou A+. Un score B ou inférieur signale généralement des protocoles obsolètes (TLS 1.0/1.1) ou des cipher suites faibles, qui peuvent provoquer des erreurs de connexion pour une partie des clients — y compris des crawlers.

Versions TLS : couper TLS 1.0 et 1.1

TLS 1.0 et 1.1 sont officiellement dépréciés depuis mars 2021 (RFC 8996). Tous les navigateurs modernes les ont désactivés. Googlebot utilise des versions récentes de Chrome pour le rendu, donc TLS 1.2 minimum est nécessaire.

Configuration Nginx recommandée :

server {
    listen 443 ssl http2;
    server_name www.monsite-ecommerce.fr;

    ssl_certificate /etc/letsencrypt/live/www.monsite-ecommerce.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.monsite-ecommerce.fr/privkey.pem;

    # TLS 1.2 et 1.3 uniquement
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites modernes — priorité au serveur
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

    # OCSP Stapling — évite une requête DNS supplémentaire au client
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # Session tickets et cache pour performance TLS
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;  # Désactivé pour forward secrecy

    # HSTS — section détaillée plus bas
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

Le point sur OCSP Stapling mérite une attention particulière. Sans OCSP stapling, chaque client doit contacter l'autorité de certification pour vérifier si le certificat est révoqué. Cette requête ajoute de la latence au handshake TLS — parfois 100-300 ms. Pour le SEO, cette latence pénalise le Time to First Byte (TTFB), qui impacte le LCP.

HSTS : le header que 60 % des sites configurent mal

HTTP Strict Transport Security (HSTS) indique au navigateur de ne jamais tenter une connexion HTTP vers votre domaine. Sans HSTS, même après une migration HTTPS complète, la première visite d'un utilisateur qui tape monsite.fr dans la barre d'adresse passe par HTTP, puis subit une redirection 301 vers HTTPS. Ce round-trip supplémentaire coûte du temps et, pour Googlebot, du crawl budget.

Les trois paramètres HSTS et leurs implications SEO

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

max-age : durée en secondes pendant laquelle le navigateur force HTTPS. 63072000 = 2 ans. Ne commencez jamais par un max-age élevé lors d'une première mise en place. Procédez par étapes : 300 (5 min) → 86400 (1 jour) → 2592000 (30 jours) → 63072000 (2 ans). Si votre configuration HTTPS casse pendant que le max-age est à 2 ans, vos utilisateurs ne pourront plus accéder au site en HTTP — aucun contournement possible côté serveur.
includeSubDomains : applique HSTS à tous les sous-domaines. Attention piège : si vous avez un sous-domaine legacy.monsite.fr qui sert encore du HTTP (un vieux back-office, un service tiers), ce sous-domaine deviendra inaccessible. Auditez vos sous-domaines avant d'activer ce paramètre.
preload : permet l'inscription dans la HSTS preload list embarquée dans les navigateurs. Une fois inscrit, même la première visite est forcée en HTTPS — zéro redirection HTTP → HTTPS, jamais. L'inscription prend plusieurs semaines et la désinscription peut prendre des mois. Décision quasi irréversible à court terme.

Impact sur le crawl

Un point rarement documenté : Googlebot respecte HSTS. Quand votre site est dans la preload list ou que Googlebot a vu le header HSTS lors d'une visite précédente, il ne tente plus les URLs HTTP. Les chaînes de redirections HTTP → HTTPS disparaissent du crawl, ce qui libère du budget crawl pour vos pages réelles.

Vérification depuis la Search Console : dans le rapport de couverture, filtrez les URLs "Explorée, actuellement non indexée". Si vous voyez des variantes HTTP de vos pages, c'est que HSTS n'est pas correctement en place ou que Googlebot n'a pas encore intégré votre politique.

Mixed content : le tueur silencieux de migrations HTTPS

Le mixed content désigne le chargement de ressources HTTP depuis une page HTTPS. Les navigateurs distinguent deux types :

Mixed active content (scripts, iframes, fetch requests) : bloqué par défaut. Votre JavaScript ou votre iframe ne se charge tout simplement pas.
Mixed passive content (images, vidéos, audio) : historiquement autorisé avec un avertissement, mais Chrome auto-upgrade désormais ces requêtes vers HTTPS (depuis Chrome 80). Si la ressource n'est pas disponible en HTTPS, elle échoue silencieusement.

Détecter le mixed content à l'échelle

Sur un site de 22 000 pages, l'inspection manuelle n'est pas viable. Trois approches complémentaires :

1. Le header Content-Security-Policy en mode report-only :

# Ajoutez ce header dans votre config Nginx
add_header Content-Security-Policy-Report-Only
    "default-src https:; report-uri https://monsite-ecommerce.fr/csp-report" always;

Ce header ne bloque rien, mais envoie un rapport JSON à votre endpoint chaque fois qu'une ressource HTTP est détectée. Laissez-le actif une semaine, agrégez les rapports, et vous obtenez la liste exhaustive de vos ressources mixed content.

Voici un endpoint minimaliste en Node.js pour collecter ces rapports :

import express from 'express';
import fs from 'fs/promises';

const app = express();
app.use(express.json({ type: 'application/csp-report' }));

interface CSPReport {
  'csp-report': {
    'document-uri': string;
    'blocked-uri': string;
    'violated-directive': string;
    'original-policy': string;
  };
}

const reportLog = new Map<string, Set<string>>();

app.post('/csp-report', async (req, res) => {
  const report = req.body as CSPReport;
  const page = report['csp-report']['document-uri'];
  const blocked = report['csp-report']['blocked-uri'];

  if (!reportLog.has(page)) {
    reportLog.set(page, new Set());
  }
  reportLog.get(page)!.add(blocked);

  // Écriture incrémentale dans un fichier pour analyse ultérieure
  await fs.appendFile(
    '/var/log/csp-reports.jsonl',
    JSON.stringify({
      timestamp: new Date().toISOString(),
      page,
      blockedResource: blocked,
      directive: report['csp-report']['violated-directive']
    }) + '\n'
  );

  res.status(204).end();
});

app.get('/csp-report/summary', (_req, res) => {
  const summary = Array.from(reportLog.entries()).map(([page, resources]) => ({
    page,
    mixedContentCount: resources.size,
    resources: Array.from(resources)
  }));
  res.json(summary.sort((a, b) => b.mixedContentCount - a.mixedContentCount));
});

app.listen(3000, () => console.log('CSP report collector on :3000'));

2. Screaming Frog en mode audit : configurez un crawl avec le filtre "Insecure Content" activé (Config > Spider > Advanced). Sur un site de 22 000 pages, comptez 30-45 minutes de crawl. Exportez le rapport "Insecure Content" pour obtenir chaque URL de page + la ressource HTTP incriminée.

3. Chrome DevTools en bulk : l'onglet Security de DevTools affiche les mixed content resources pour la page courante. Utile pour le debugging page par page, mais pas pour l'audit global.

Corriger le mixed content

La correction dépend de la source :

URLs en dur dans le contenu CMS : requête SQL pour remplacer http:// par https:// dans le corps des articles. Testez sur un environnement staging d'abord.
Assets servis par un CDN : vérifiez que le CDN supporte HTTPS et mettez à jour les URLs dans vos templates.
Ressources tierces (tracking pixels, widgets, polices) : contactez le fournisseur ou remplacez par une alternative HTTPS. Un script de tracking qui charge en HTTP et se fait bloquer par le navigateur, c'est de la donnée analytics perdue ET un signal de mixed content.

La directive upgrade-insecure-requests dans CSP peut servir de filet de sécurité :

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Cette directive demande au navigateur de réécrire automatiquement les URLs HTTP en HTTPS avant de les charger. Attention : si la ressource n'existe pas en HTTPS, elle échoue. Ce n'est pas un correctif — c'est un pansement temporaire pendant que vous nettoyez les URLs.

Redirections HTTP → HTTPS : le champ de mines SEO

La migration HTTP → HTTPS est techniquement une migration d'URL. Chaque page change d'adresse. Google traite ça comme une migration de site, avec toutes les implications sur le passage de PageRank et la réindexation.

La bonne configuration de redirection

Chaque URL HTTP doit rediriger en 301 (permanente) vers son équivalent HTTPS exact. Pas vers la homepage. Pas vers une URL différente. Le même path, le même query string.

# Bloc serveur HTTP — redirige tout vers HTTPS avec le même URI
server {
    listen 80;
    server_name monsite-ecommerce.fr www.monsite-ecommerce.fr;

    # Redirection 301 qui préserve le path et le query string
    return 301 https://$host$request_uri;
}

Équivalent Apache :

# Dans le .htaccess ou la config du VirtualHost port 80
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Les pièges des chaînes de redirections

Le scénario catastrophe classique, celui qui a fait perdre 34 % de trafic à notre e-commerce de 22 000 pages :

http://monsite-ecommerce.fr/chaussures/running
  → 301 → https://monsite-ecommerce.fr/chaussures/running
    → 301 → https://www.monsite-ecommerce.fr/chaussures/running
      → 301 → https://www.monsite-ecommerce.fr/chaussures/running/

Trois redirections en chaîne. Multipliez par 22 000 pages. Googlebot suit les chaînes de redirections jusqu'à un maximum de 10 sauts, mais chaque saut consomme du crawl budget et dilue le signal de PageRank. Sur un catalogue de 22 000 pages, trois redirections par URL signifient 66 000 requêtes de crawl gaspillées.

La solution : chaque redirection doit pointer directement vers l'URL finale canonique. Décidez en amont : www ou non-www ? Trailing slash ou non ? Puis configurez une seule redirection vers la destination finale.

# Configuration correcte : une seule redirection vers l'URL canonique finale
# Décision : www + HTTPS + pas de trailing slash

# Bloc 1 : HTTP non-www → HTTPS www (direct, pas de chaîne)
server {
    listen 80;
    server_name monsite-ecommerce.fr;
    return 301 https://www.monsite-ecommerce.fr$request_uri;
}

# Bloc 2 : HTTP www → HTTPS www
server {
    listen 80;
    server_name www.monsite-ecommerce.fr;
    return 301 https://www.monsite-ecommerce.fr$request_uri;
}

# Bloc 3 : HTTPS non-www → HTTPS www
server {
    listen 443 ssl http2;
    server_name monsite-ecommerce.fr;
    ssl_certificate /etc/letsencrypt/live/monsite-ecommerce.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monsite-ecommerce.fr/privkey.pem;
    return 301 https://www.monsite-ecommerce.fr$request_uri;
}

# Bloc 4 : HTTPS www — le vrai serveur
server {
    listen 443 ssl http2;
    server_name www.monsite-ecommerce.fr;
    # ... config SSL complète ...
    # ... config applicative ...
}

Quatre blocs serveur, mais chaque chemin ne fait qu'un seul saut de redirection.

Vérification post-migration dans Search Console

Après la migration, soumettez un nouveau sitemap XML contenant uniquement les URLs HTTPS. Dans Google Search Console, ajoutez la propriété HTTPS si elle n'existe pas encore (les propriétés HTTP et HTTPS sont distinctes). Surveillez :

Le rapport "Couverture" sur la propriété HTTPS : les pages doivent passer de "Découverte" à "Indexée" dans les jours/semaines suivants.
Le rapport "Couverture" sur l'ancienne propriété HTTP : les pages doivent afficher "Page avec redirection".
L'API d'inspection d'URL pour vérifier programmatiquement l'état d'indexation des URLs critiques.

Certificats expirés et erreurs TLS : l'impact sur le crawl et l'indexation

Un certificat expiré est un incident SEO critique. Googlebot, comme les navigateurs modernes, refuse les connexions avec un certificat invalide. Pendant toute la durée de l'expiration, vos pages ne sont plus crawlées. Si l'incident dure plus de quelques jours, Google peut commencer à désindexer des pages — et la réindexation après résolution prend du temps.

Le scénario le plus fréquent : un certificat Let's Encrypt qui n'a pas été renouvelé automatiquement parce que le cron certbot a été désactivé lors d'une mise à jour serveur, ou parce que le port 80 est bloqué par un firewall (Let's Encrypt utilise le challenge HTTP-01 sur le port 80 par défaut).

Monitoring proactif des certificats

Ne comptez pas sur une vérification manuelle. Automatisez :

#!/bin/bash
# Script de monitoring d'expiration de certificat
# À exécuter quotidiennement via cron

DOMAIN="www.monsite-ecommerce.fr"
ALERT_DAYS=14
SLACK_WEBHOOK="https://hooks.slack.com/services/XXX/YYY/ZZZ"

EXPIRY_DATE=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null \
  | openssl x509 -noout -enddate 2>/dev/null \
  | cut -d= -f2)

if [ -z "$EXPIRY_DATE" ]; then
  curl -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"🚨 CRITIQUE: Impossible de récupérer le certificat de $DOMAIN\"}" \
    "$SLACK_WEBHOOK"
  exit 1
fi

EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt "$ALERT_DAYS" ]; then
  curl -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"⚠️ Le certificat de $DOMAIN expire dans $DAYS_LEFT jours ($EXPIRY_DATE)\"}" \
    "$SLACK_WEBHOOK"
fi

echo "$DOMAIN: certificat expire dans $DAYS_LEFT jours"

Un outil de monitoring SEO comme Seogard détecte automatiquement les erreurs de certificat lors du crawl de vos pages et vous alerte avant que Googlebot ne rencontre le problème. Ce type de régression technique est invisible dans la Search Console tant que Google n'a pas tenté un crawl — le délai entre l'incident et la notification peut être de plusieurs jours.

Erreurs TLS courantes et leur diagnostic

Au-delà de l'expiration, plusieurs erreurs TLS bloquent le crawl :

ERR_CERT_COMMON_NAME_INVALID : le domaine ne correspond pas au certificat. Fréquent quand vous ajoutez un sous-domaine sans l'inclure dans le SAN (Subject Alternative Name).
ERR_CERT_AUTHORITY_INVALID : certificat auto-signé ou chaîne incomplète. Googlebot refuse la connexion.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH : le serveur ne supporte que des cipher suites obsolètes que le client refuse. Mettez à jour votre configuration SSL (voir la section Nginx ci-dessus).
ERR_SSL_PROTOCOL_ERROR : souvent un problème de configuration SNI (Server Name Indication) sur un serveur hébergeant plusieurs domaines.

Testez chaque scénario depuis la ligne de commande pour isoler le problème :

# Test SNI spécifique
openssl s_client -connect monsite-ecommerce.fr:443 -servername monsite-ecommerce.fr

# Test sans SNI (simule un vieux client)
openssl s_client -connect monsite-ecommerce.fr:443 -noservername

# Test avec TLS 1.3 uniquement
openssl s_client -connect monsite-ecommerce.fr:443 -tls1_3

# Lister les cipher suites supportées
nmap --script ssl-enum-ciphers -p 443 monsite-ecommerce.fr

Canonical, HSTS et signaux contradictoires

Un dernier point souvent négligé : la cohérence entre vos balises canonical, votre sitemap, et votre politique HSTS.

Si votre balise canonical pointe vers http:// alors que vos pages sont servies en HTTPS, vous envoyez un signal contradictoire à Google. Le crawler voit une page HTTPS qui déclare que sa version canonique est en HTTP. Google résoudra probablement cette contradiction correctement — mais "probablement" n'est pas "certainement", et la résolution prend du temps d'indexation.

Checklist de cohérence à vérifier :

Toutes les balises <link rel="canonical"> utilisent https://
Le sitemap XML ne contient que des URLs https://
Les liens internes (navigation, footer, breadcrumb, contenu éditorial) pointent directement vers les URLs https:// — pas vers des URLs HTTP qui redirigent
Les balises hreflang (si applicable) utilisent https://
Les données structurées contiennent des URLs https:// dans les champs url, mainEntityOfPage, etc.

Un crawl Screaming Frog avec le filtre "Protocol" permet de détecter toute URL HTTP résiduelle dans vos liens internes, canonicals et hreflang. Exportez le rapport, corrigez, recrawlez. Sur un site de plus de 10 000 pages, comptez deux à trois itérations avant un nettoyage complet.

Des pages qui renvoient des signaux canoniques incohérents peuvent se retrouver dans la catégorie "Explorée, actuellement non indexée" de la Search Console — un symptôme qui n'oriente pas immédiatement vers un problème HTTPS, ce qui rend le diagnostic d'autant plus difficile.

La configuration SSL/TLS correcte pour le SEO va bien au-delà de l'installation d'un certificat. C'est un ensemble de décisions techniques — versions TLS, HSTS, redirections, mixed content, cohérence des signaux canoniques — qui doivent toutes être correctes simultanément. Une seule erreur dans la chaîne suffit à dégrader le crawl, l'indexation, ou les performances. Automatisez la surveillance de chaque maillon : expiration des certificats, chaînes de redirection, mixed content, cohérence des canonicals. Seogard surveille ces régressions en continu et alerte dès qu'un problème apparaît — avant que votre trafic n'en paie le prix.