HTTP/2 et HTTP/3 : impact réel sur le crawl et le SEO

Googlebot crawle en HTTP/2 depuis novembre 2020. Depuis fin 2022, il supporte HTTP/3 via QUIC sur une partie croissante de ses requêtes. Si votre serveur répond encore exclusivement en HTTP/1.1, chaque crawl de Googlebot ouvre une connexion TCP dédiée par ressource — et sur un catalogue de 20 000 produits, la différence de débit de crawl est mesurable.

Pourtant, la majorité des audits SEO techniques s'arrêtent à "le site est en HTTPS, c'est bon". Le protocole de transport sous-jacent est rarement inspecté. C'est une erreur, parce que HTTP/2 et HTTP/3 ne changent pas seulement la vitesse de chargement côté utilisateur — ils modifient la mécanique du crawl lui-même.

Ce que HTTP/2 et HTTP/3 changent pour le crawl de Googlebot

Le multiplexage : la rupture fondamentale avec HTTP/1.1

HTTP/1.1 fonctionne en mode requête-réponse séquentiel. Une connexion TCP ne traite qu'une requête à la fois. Pour paralléliser, le client (ou le crawler) doit ouvrir plusieurs connexions simultanées — en pratique 6 à 8 par hostname pour les navigateurs, un chiffre similaire pour Googlebot.

HTTP/2 change cette mécanique avec le multiplexage : une seule connexion TCP transporte des centaines de requêtes et réponses en parallèle, entrelacées via des streams. Résultat : Googlebot peut demander votre page HTML, ses CSS critiques, ses images et vos fichiers JSON-LD sur la même connexion, sans attendre que chaque réponse précédente soit complète.

HTTP/3 pousse le concept plus loin en remplaçant TCP par QUIC (basé sur UDP). L'avantage clé : la suppression du head-of-line blocking au niveau transport. En HTTP/2, si un seul paquet TCP est perdu, tous les streams de la connexion sont bloqués en attendant la retransmission. En HTTP/3, seul le stream affecté est ralenti — les autres continuent.

Googlebot et le support protocolaire : état des lieux

Google a officiellement annoncé le crawl HTTP/2 en novembre 2020 sur le blog Google Search Central. Le mécanisme est opt-in côté serveur : si votre serveur annonce le support HTTP/2 lors du handshake TLS (via ALPN — Application-Layer Protocol Negotiation), Googlebot l'utilisera. Sinon, il retombe en HTTP/1.1 sans pénalité.

Point important : Googlebot ne crawle pas les ressources d'une page (CSS, JS, images) dans le même flux que le HTML lors de la phase de crawl initiale. Le rendu (Web Rendering Service) est une étape séparée. L'avantage de HTTP/2 pour le crawl se manifeste surtout dans la réduction du overhead de connexion quand Googlebot fetch plusieurs URLs de votre site en séquence rapide.

Pour HTTP/3, Google n'a pas fait d'annonce officielle équivalente, mais les logs serveur de nombreux sites montrent des requêtes Googlebot arrivant via QUIC/HTTP/3 depuis mi-2022. Cloudflare et Fastly confirment cette tendance dans leurs rapports de trafic bot.

Impact concret sur le crawl budget

Le crawl budget est déterminé par deux facteurs : le crawl rate limit (la pression maximale que Googlebot s'autorise sur votre serveur) et la crawl demand (le nombre d'URLs que Google veut explorer). HTTP/2 n'augmente pas directement le crawl demand, mais il réduit le coût par requête côté serveur — ce qui peut amener Googlebot à constater que votre serveur répond plus vite et à augmenter le crawl rate.

Sur un site e-commerce de 18 000 pages produit, le passage de HTTP/1.1 à HTTP/2 a un effet mesurable : le nombre de pages crawlées par jour dans Google Search Console peut augmenter de 15 à 30%, simplement parce que le temps de réponse moyen vu par Googlebot diminue. Chaque milliseconde gagnée sur le TTFB (Time To First Byte) se traduit par plus de pages crawlées dans la même fenêtre de temps.

Diagnostic : vérifier quel protocole utilise votre serveur

Avant d'optimiser, il faut savoir où vous en êtes. Plusieurs méthodes complémentaires.

Via curl en ligne de commande

La méthode la plus fiable pour vérifier le protocole négocié :

# Vérifier le support HTTP/2
curl -sI --http2 -o /dev/null -w "HTTP version: %{http_version}\nTTFB: %{time_starttransfer}s\n" https://www.boutique-outdoor.fr/

# Vérifier le support HTTP/3 (nécessite curl 7.66+ compilé avec quiche ou ngtcp2)
curl -sI --http3 -o /dev/null -w "HTTP version: %{http_version}\nTTFB: %{time_starttransfer}s\n" https://www.boutique-outdoor.fr/

# Tester en batch sur vos URLs critiques
cat urls-critiques.txt | xargs -I {} curl -sI --http2 -o /dev/null -w "{} -> HTTP/%{http_version} TTFB:%{time_starttransfer}s\n" {}

Si http_version renvoie 2 ou 3, le protocole est correctement négocié. Si vous obtenez 1.1 alors que vous pensiez avoir HTTP/2, le problème est dans la config TLS/ALPN de votre serveur ou de votre CDN.

Via Chrome DevTools

Dans l'onglet Network de Chrome DevTools, ajoutez la colonne "Protocol" (clic droit sur les en-têtes de colonnes). Vous verrez h2 pour HTTP/2 et h3 pour HTTP/3 en face de chaque requête. C'est utile pour vérifier que toutes les ressources (pas seulement le document HTML) sont servies en HTTP/2 — un CDN peut servir les assets en h2 alors que votre origin server est encore en HTTP/1.1, ou inversement.

Via les logs serveur

Pour identifier ce que Googlebot utilise réellement sur votre site, analysez vos access logs. Nginx enregistre le protocole dans la variable $server_protocol :

# Filtrer les requêtes Googlebot et compter par protocole
grep "Googlebot" /var/log/nginx/access.log | awk '{print $NF}' | sort | uniq -c | sort -rn

# Résultat typique :
#  4521 HTTP/2.0
#   312 HTTP/1.1
#    87 HTTP/3

Si vous voyez une majorité de requêtes Googlebot en HTTP/1.1 alors que votre serveur supporte HTTP/2, vérifiez que l'ALPN est correctement annoncé pendant le handshake TLS. Un certificat mal configuré ou un reverse proxy intermédiaire qui strip le support h2 sont les causes les plus fréquentes.

Configuration serveur : activer HTTP/2 et HTTP/3

Nginx : HTTP/2

HTTP/2 dans Nginx est activé au niveau du bloc listen. Depuis Nginx 1.25.1, la directive http2 est séparée de listen :

server {
    listen 443 ssl;
    http2 on;

    server_name www.boutique-outdoor.fr;

    ssl_certificate     /etc/ssl/certs/boutique-outdoor.fr.pem;
    ssl_certificate_key /etc/ssl/private/boutique-outdoor.fr.key;

    # Protocoles TLS — HTTP/2 requiert TLS 1.2 minimum
    ssl_protocols TLSv1.2 TLSv1.3;

    # Ciphers compatibles HTTP/2 (exclure les blacklistés par la RFC 7540)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # Optimisation HTTP/2 : augmenter la taille de la fenêtre de concurrence
    http2_max_concurrent_streams 128;

    # Server Push — utile pour pousser le CSS critique au crawler
    location / {
        # Attention : Server Push est deprecated dans Chrome depuis 2022
        # mais reste utile pour d'autres clients HTTP/2
        proxy_pass http://backend;
    }
}

Un piège classique : sur les versions Nginx antérieures à 1.25.1, la syntaxe est listen 443 ssl http2;. Si vous upgradez Nginx sans adapter la config, HTTP/2 peut silencieusement se désactiver.

HTTP/3 avec QUIC

HTTP/3 est plus complexe à déployer en self-hosted. Nginx a un support expérimental depuis la branche nginx-quic. En pratique, le chemin le plus fiable pour HTTP/3 est de passer par un CDN qui le supporte nativement : Cloudflare (activé par défaut), Fastly, Akamai, ou AWS CloudFront.

Si vous tenez au self-hosted, voici la config Nginx avec le module QUIC :

server {
    # HTTP/3 utilise UDP sur le port 443
    listen 443 quic reuseport;
    listen 443 ssl;
    http2 on;

    server_name www.boutique-outdoor.fr;

    ssl_certificate     /etc/ssl/certs/boutique-outdoor.fr.pem;
    ssl_certificate_key /etc/ssl/private/boutique-outdoor.fr.key;

    # TLS 1.3 obligatoire pour HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;

    # Header Alt-Svc pour annoncer le support HTTP/3 aux clients
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # Paramètres QUIC
    quic_retry on;
    ssl_early_data on;

    location / {
        proxy_pass http://backend;
        # Propager le header Alt-Svc à travers le proxy
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Le header Alt-Svc est le mécanisme par lequel le serveur signale au client (navigateur ou crawler) qu'il peut upgrader vers HTTP/3 lors de la prochaine requête. Sans ce header, aucun client ne tentera HTTP/3 — c'est le point de défaillance le plus fréquent dans les déploiements manuels.

Apache : HTTP/2

Pour Apache, le module mod_http2 est nécessaire :

# Activer le module
LoadModule http2_module modules/mod_http2.so

<VirtualHost *:443>
    ServerName www.boutique-outdoor.fr

    # Activer HTTP/2
    Protocols h2 h2c http/1.1

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/boutique-outdoor.fr.pem
    SSLCertificateKeyFile /etc/ssl/private/boutique-outdoor.fr.key

    # HTTP/2 fonctionne mal avec mpm_prefork — utilisez mpm_event
    # Vérifiez avec : apachectl -V | grep MPM
</VirtualHost>

Point critique : Apache avec mpm_prefork (le MPM par défaut sur beaucoup de distributions) est incompatible avec HTTP/2. Il faut passer à mpm_event ou mpm_worker, ce qui peut casser les modules PHP basés sur mod_php. La solution standard est php-fpm en FastCGI.

Scénario concret : migration HTTP/1.1 → HTTP/2 sur un catalogue e-commerce

Contexte

Un site e-commerce spécialisé dans l'équipement outdoor, hébergé sur une stack Nginx + Node.js (Next.js SSR). 18 200 pages indexées : 14 000 fiches produit, 800 pages catégorie, 3 400 pages de contenu éditorial. Serveur dédié chez OVH, pas de CDN. Trafic organique : 45 000 sessions/mois.

L'audit initial via Screaming Frog révèle un TTFB moyen de 420ms sur les fiches produit et 680ms sur les pages catégorie (qui agrègent des données de plusieurs collections MongoDB). Google Search Console montre un crawl moyen de 1 200 pages/jour, avec des pics à 2 800 et des creux à 400.

Problème identifié : les logs Nginx montrent 100% des requêtes Googlebot en HTTP/1.1. La directive http2 était absente de la config — le serveur avait été provisionné en 2019 et jamais mis à jour sur ce point.

Actions

Activation HTTP/2 sur Nginx avec la config décrite plus haut.
Passage à TLS 1.3 (le serveur était encore en TLS 1.2 only, ce qui fonctionne pour HTTP/2 mais bloque HTTP/3 futur).
Ajout du header Alt-Svc pour préparer HTTP/3.
Ajout de Cloudflare en proxy pour le CDN des assets statiques (images produit, CSS, JS bundles) avec HTTP/3 activé.

Résultats après 6 semaines

Dans Google Search Console, les métriques d'exploration ont évolué :

Pages crawlées par jour : de 1 200 (moyenne) à 1 750 — une augmentation de ~45%.
Temps de réponse moyen vu par Googlebot : de 380ms à 210ms (combinaison de HTTP/2 + mise en cache Cloudflare des assets).
Pages découvertes non indexées ("crawled but not indexed") : réduction de 2 400 à 1 100 en 6 semaines. Plus de pages crawlées = plus de chances que Google juge le contenu digne d'indexation lors du passage.

L'impact trafic organique direct est difficile à isoler (d'autres optimisations étaient en cours), mais les données de couverture d'index montrent clairement que Googlebot parcourt le site plus efficacement. Les nouvelles fiches produit sont indexées en 48-72h au lieu de 7-10 jours.

Trade-offs et limites

HTTP/2 seul n'a pas résolu le problème de TTFB sur les pages catégorie (680ms → 520ms). Le goulot d'étranglement était les requêtes MongoDB qui agrègent les données produit — un problème applicatif, pas protocolaire. La leçon : HTTP/2 améliore le transport, pas le temps de génération côté serveur. Si votre SSR prend 800ms à produire le HTML, HTTP/2 ne comprimera pas ce délai.

Pour les sites qui utilisent des frameworks JavaScript avec SSR, le protocole de transport interagit avec la phase de rendu côté serveur. Un site React avec des problèmes de SSR ou une SPA mal configurée ne sera pas sauvée par HTTP/2 — le problème est en amont.

Interactions entre protocole HTTP, chaînes de redirections et HTTPS

HTTP/2 réduit le coût de chaque requête individuelle, mais il n'élimine pas le coût des redirections. Chaque redirect 301/302 reste un aller-retour complet. Sur une chaîne de redirections de 3 sauts (http → https → www → URL finale), HTTP/2 multiplex ne vous sauve pas : ce sont 3 requêtes séquentielles, chacune avec son propre handshake TLS si les hostnames diffèrent.

Un cas fréquent post-migration : vous passez en HTTP/2, mais vos anciennes URLs redirigent encore via une chaîne. Googlebot suit ces redirections en HTTP/2, certes, mais le temps cumulé consomme du crawl budget. La combinaison optimale :

HTTP/2 ou HTTP/3 activé
HTTPS everywhere (prérequis technique de HTTP/2 de toute façon, comme détaillé dans cet article sur HTTPS et SEO)
Zéro chaîne de redirection — chaque 301 pointe directement vers l'URL finale
Trailing slashes cohérents pour éviter les redirections inutiles

Le cas spécifique des migrations

Lors d'une migration de site, le volume de redirections explose temporairement. HTTP/2 réduit le coût unitaire de chaque redirect grâce à la réutilisation de connexion (connection coalescing), mais uniquement si l'ancien et le nouveau hostname partagent le même certificat TLS et la même IP. C'est rarement le cas lors d'un changement de domaine.

Monitoring et détection des régressions protocolaires

Un des risques sous-estimés : la régression silencieuse vers HTTP/1.1. Ça arrive plus souvent qu'on ne le pense :

Un renouvellement de certificat TLS qui change la configuration ALPN
Un upgrade Nginx qui modifie la syntaxe de la directive http2
Un changement de CDN ou de reverse proxy qui ne forward pas le support h2
Une mise à jour de l'infrastructure cloud (load balancer AWS, GCP) qui reset les paramètres

Vous ne recevez aucune erreur. Le site fonctionne. Mais Googlebot retombe en HTTP/1.1, le crawl ralentit progressivement, et vous ne comprenez pas pourquoi les nouvelles pages mettent 2 semaines à être indexées.

Script de monitoring avec alerting

import https from 'node:https';
import http2 from 'node:http2';

interface ProtocolCheckResult {
  url: string;
  protocol: string;
  ttfb: number;
  statusCode: number;
  altSvc: string | null;
}

async function checkHTTP2Support(url: string): Promise<ProtocolCheckResult> {
  return new Promise((resolve, reject) => {
    const startTime = performance.now();
    const client = http2.connect(url);
    
    client.on('error', (err) => {
      reject(new Error(`HTTP/2 connection failed for ${url}: ${err.message}`));
    });

    const req = client.request({ 
      ':path': '/',
      ':method': 'HEAD',
      'user-agent': 'SEO-Protocol-Monitor/1.0'
    });

    req.on('response', (headers) => {
      const ttfb = performance.now() - startTime;
      resolve({
        url,
        protocol: 'h2',
        ttfb: Math.round(ttfb),
        statusCode: headers[':status'] as number,
        altSvc: (headers['alt-svc'] as string) || null
      });
      client.close();
    });

    req.on('error', () => {
      // Fallback : HTTP/2 non supporté, le serveur a probablement refusé
      resolve({
        url,
        protocol: 'h1.1',
        ttfb: Math.round(performance.now() - startTime),
        statusCode: 0,
        altSvc: null
      });
      client.close();
    });

    req.end();
  });
}

// Vérification batch des URLs critiques
async function monitorProtocols(urls: string[]): Promise<void> {
  const results = await Promise.allSettled(
    urls.map(url => checkHTTP2Support(url))
  );

  for (const result of results) {
    if (result.status === 'fulfilled') {
      const { url, protocol, ttfb, altSvc } = result.value;
      
      if (protocol === 'h1.1') {
        console.error(`[ALERT] ${url} → HTTP/1.1 détecté (régression ?)`);
        // Ici : envoyer une alerte Slack/email
      }
      
      if (!altSvc) {
        console.warn(`[WARN] ${url} → Header Alt-Svc absent (HTTP/3 non annoncé)`);
      }
      
      console.log(`${url} → ${protocol} | TTFB: ${ttfb}ms | Alt-Svc: ${altSvc || 'none'}`);
    }
  }
}

// URLs à monitorer quotidiennement
const criticalUrls = [
  'https://www.boutique-outdoor.fr',
  'https://www.boutique-outdoor.fr/categorie/vestes-randonnee',
  'https://www.boutique-outdoor.fr/produit/gore-tex-pro-shell-3l'
];

monitorProtocols(criticalUrls);

Ce type de vérification devrait tourner quotidiennement. Un outil de monitoring comme Seogard détecte automatiquement ce type de régression protocolaire lors de ses crawls réguliers — sans avoir à maintenir un script custom.

HTTP/2 Server Push, priorités et préchargement : ce qui marche vraiment pour le SEO

Server Push : une fausse bonne idée

HTTP/2 Server Push permettait au serveur d'envoyer proactivement des ressources au client avant même qu'il les demande. En théorie, idéal pour pousser le CSS critique ou le fichier JSON-LD au crawler. En pratique, Chrome a retiré le support de Server Push en 2022, et les autres navigateurs suivent.

Pour le SEO, Server Push n'a jamais eu d'impact mesurable sur le crawl de Googlebot. Le Web Rendering Service de Google fetch les sous-ressources de manière asynchrone, dans une phase séparée du crawl HTML initial. Push n'accélérait pas ce processus.

L'alternative qui fonctionne : les headers 103 Early Hints, supportés depuis Chrome 103. Le serveur envoie une réponse préliminaire avec des headers Link: rel=preload pendant qu'il génère la réponse finale. C'est plus simple que Push, sans les problèmes de cache invalidation, et supporté par Cloudflare nativement.

Priorités de streams HTTP/2

HTTP/2 permet au client de signaler la priorité relative des requêtes via un arbre de dépendances et des poids. En pratique, l'implémentation varie énormément entre les serveurs. Nginx, par exemple, a historiquement mal géré la priorisation HTTP/2 — un problème documenté par les ingénieurs de Cloudflare.

HTTP/3 simplifie le modèle avec les Extensible Priorities (RFC 9218), qui remplacent l'arbre de dépendances par un système de groupes d'urgence plus prévisible.

Pour le SEO, l'implication est indirecte : si votre serveur priorise mal les streams HTTP/2, le CSS critique peut arriver après les images décoratives. Le Web Rendering Service de Google attend toutes les ressources critiques avant de rendre la page. Un stream mal priorisé peut ralentir le rendu, ce qui retarde l'indexation effective du contenu visible.

Infrastructure et interactions avec le stack technique

Le protocole HTTP ne fonctionne pas en isolation. Son impact SEO dépend de l'ensemble de la chaîne, ce qui crée les problèmes documentés dans l'article sur les gates d'infrastructure du crawl.

CDN et terminaison protocolaire

Architecture classique : le CDN (Cloudflare, Fastly, Akamai) termine la connexion HTTP/2 ou HTTP/3 côté client/crawler, puis communique avec votre origin server en HTTP/1.1. C'est parfaitement valide — le bénéfice du multiplexage est côté client. Mais cela signifie que vos logs origin ne montrent que du HTTP/1.1, même si Googlebot a utilisé h2. Vérifiez toujours les logs du CDN, pas de l'origin, pour connaître le protocole réel vu par le crawler.

Load balancers et ALPN

Les load balancers AWS (ALB) supportent HTTP/2 côté client depuis 2016. Mais un piège classique : si vous configurez un target group en HTTP/1.1 vers vos instances EC2, et que le ALB ne forward pas correctement le header Alt-Svc, HTTP/3 ne sera jamais annoncé. La configuration correcte nécessite que le ALB lui-même annonce le support gRPC/HTTP/2 et que vos security groups autorisent le trafic UDP 443 pour QUIC.

Impact sur les crawlers tiers

Googlebot supporte HTTP/2. Bingbot aussi. Mais Screaming Frog, l'outil d'audit le plus utilisé par les SEO, ne crawle en HTTP/2 que depuis la version 19.0 (2023). Si vous testez votre site avec une version antérieure, vous mesurez la performance HTTP/1.1 — pas ce que Googlebot voit réellement. De même, l'URL Inspection API ne vous indique pas le protocole utilisé lors du dernier crawl, ce qui est une limitation pour le diagnostic.

Quand HTTP/2 et HTTP/3 ne changent rien

Soyons clairs sur les limites :

Sites de moins de 500 pages : le crawl budget n'est pas un facteur limitant. Google crawle la totalité du site en quelques heures, quel que soit le protocole. L'investissement dans HTTP/2 est pertinent pour la performance utilisateur, pas pour le crawl.

TTFB applicatif supérieur à 1 seconde : si votre serveur met 1.2s à générer le HTML (requêtes SQL lentes, SSR non optimisé, absence de cache), HTTP/2 n'améliorera pas ce temps. Le protocole optimise le transport, pas la génération. Réglez le problème applicatif d'abord.

Contenu majoritairement statique : un blog de 200 articles servis via un générateur statique (Hugo, Astro) a des TTFB de 20-50ms. Le gain marginal de HTTP/2 sur le crawl est négligeable.

Sites derrière un CDN performant : si Cloudflare ou Fastly gère déjà tout votre trafic avec HTTP/2 et HTTP/3 activés par défaut, il n'y a rien à configurer côté serveur pour le crawl. Le CDN s'en charge.

L'investissement dans HTTP/2/HTTP/3 se justifie surtout pour les sites volumineux (5 000+ pages), avec du contenu dynamique, qui gèrent leur propre infrastructure ou un CDN custom — typiquement l'e-commerce, les marketplaces, les sites média avec un flux éditorial intense.

HTTP/2 et HTTP/3 ne sont pas des "facteurs de ranking" au sens où Google ne boost pas les sites qui les utilisent. Leur impact est mécanique : ils réduisent le coût de chaque interaction entre Googlebot et votre serveur, ce qui augmente le volume de pages crawlées à crawl rate constant. Sur un catalogue volumineux, c'est la différence entre des fiches produit indexées en 3 jours et en 3 semaines. Vérifiez vos logs, auditez votre config ALPN, et surtout, monitorez en continu — une régression vers HTTP/1.1 passe inaperçue pendant des semaines si personne ne la surveille. Des outils comme Seogard automatisent cette détection pour que la régression ne devienne pas une hémorragie silencieuse de crawl budget.