Server-side caching et SEO : Varnish, Redis, CDN

Un site e-commerce de 28 000 produits, hébergé sur un stack PHP/MySQL classique, voit son Time To First Byte (TTFB) moyen grimper à 1,8 seconde sous charge. Googlebot crawle 3 200 pages par jour au lieu des 12 000 que le site expose dans son sitemap. Résultat : 40 % du catalogue reste non indexé pendant des semaines après chaque mise à jour. Le problème n'est pas le contenu, ni le maillage interne — c'est la vitesse à laquelle le serveur répond au crawler.

Le server-side caching est le levier le plus sous-exploité pour améliorer la relation entre votre infrastructure et Googlebot. Pas le caching navigateur (qui ne concerne pas les bots), mais les couches Varnish, Redis et CDN qui déterminent la rapidité avec laquelle votre serveur sert une page à chaque requête.

Comment Googlebot perçoit votre temps de réponse serveur

Googlebot dispose d'un budget de connexion par site. Ce n'est pas un chiffre fixe : il s'ajuste dynamiquement en fonction de la réactivité du serveur. Google l'a documenté dans ses guidelines sur le crawl budget : si le serveur ralentit, Googlebot réduit son rythme de crawl. Si le serveur répond vite, il accélère.

Concrètement, la métrique qui compte est le TTFB perçu par le bot. Pas le Largest Contentful Paint, pas le Speed Index — le temps entre la requête HTTP et le premier octet de la réponse. Un TTFB de 200 ms au lieu de 1 500 ms signifie que Googlebot peut théoriquement crawler 7,5 fois plus de pages dans la même fenêtre temporelle.

Le crawl rate limit dans Search Console

Vous pouvez observer ce comportement dans Google Search Console, section "Paramètres > Exploration". Le graphique "Temps de réponse du serveur" corrèle directement avec le nombre de requêtes de crawl par jour. Si votre TTFB moyen dépasse 1 seconde de manière consistante, attendez-vous à une baisse visible du crawl rate sous 48-72 heures.

Pour aller plus loin sur la mécanique du crawl budget et ses implications réelles, consultez notre analyse détaillée du crawl budget. L'analyse de logs serveur permet de quantifier précisément combien de pages Googlebot crawle par session et comment ce volume corrèle avec vos temps de réponse.

Ce que le cache serveur change à l'équation

Sans cache, chaque requête de Googlebot déclenche la chaîne complète : parsing de la requête, routage applicatif, requêtes SQL, rendu du template, sérialisation de la réponse. Avec un cache correctement configuré, la réponse est servie depuis la mémoire en 5-30 ms, sans toucher l'application.

Le gain n'est pas linéaire. Sur un site de 15 000 pages, passer de 800 ms à 50 ms de TTFB moyen ne multiplie pas le crawl par 16. Googlebot a ses propres limites de concurrence et de politesse. Mais dans la pratique, les gains observés se situent entre x3 et x6 en volume de crawl quotidien — ce qui fait une différence massive pour l'indexation de pages fraîchement créées ou modifiées.

Varnish comme reverse proxy cache : configuration SEO-safe

Varnish est le choix classique pour le full-page cache HTTP. Il s'installe en frontal de votre serveur applicatif (Nginx, Apache, Node.js) et sert les réponses directement depuis la RAM pour les requêtes qui matchent une entrée en cache.

Configuration de base orientée SEO

Le piège le plus courant avec Varnish est de cacher des réponses qui ne devraient pas l'être — ou l'inverse, d'exclure du cache des pages qui en bénéficieraient.

# /etc/varnish/default.vcl

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 3s;
    .first_byte_timeout = 10s;
    .between_bytes_timeout = 5s;
}

sub vcl_recv {
    # Ne jamais cacher les requêtes POST (formulaires, API writes)
    if (req.method == "POST") {
        return (pass);
    }

    # Ne pas cacher le back-office ni les previews CMS
    if (req.url ~ "^/(admin|wp-admin|api/preview|_next/data.*preview)") {
        return (pass);
    }

    # Supprimer les cookies pour les assets statiques
    if (req.url ~ "\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|woff2|ico)$") {
        unset req.http.Cookie;
        return (hash);
    }

    # Pour les pages HTML : supprimer les cookies tracking 
    # qui empêchent le cache de fonctionner
    if (req.http.Cookie) {
        set req.http.Cookie = regsuball(req.http.Cookie, 
            "(^|;\s*)(_ga|_gid|_gat|fbp|_fbp|_gcl_au|utm\w+)=[^;]*", "");
        # Si il ne reste plus de cookies significatifs, les supprimer entièrement
        if (req.http.Cookie ~ "^\s*$") {
            unset req.http.Cookie;
        }
    }

    return (hash);
}

sub vcl_backend_response {
    # TTL par défaut : 10 minutes pour les pages HTML
    if (beresp.http.Content-Type ~ "text/html") {
        set beresp.ttl = 600s;
        set beresp.grace = 3600s;  # Servir le stale pendant 1h si backend down
    }

    # TTL long pour les assets statiques
    if (bereq.url ~ "\.(css|js|jpg|jpeg|png|webp|woff2)$") {
        set beresp.ttl = 86400s;
    }

    # Ne pas cacher les réponses avec Set-Cookie
    if (beresp.http.Set-Cookie) {
        set beresp.uncacheable = true;
        return (deliver);
    }

    # Ne pas cacher les erreurs 5xx
    if (beresp.status >= 500) {
        set beresp.uncacheable = true;
        set beresp.ttl = 0s;
        return (deliver);
    }

    return (deliver);
}

Le piège du grace mode et des pages 404/410

La directive beresp.grace est critique pour le SEO. Elle indique à Varnish de continuer à servir une réponse périmée si le backend est lent ou indisponible. C'est excellent pour la disponibilité, mais dangereux si une page passe en 404 ou 410 : Varnish peut continuer à servir la version cachée avec un status 200 pendant toute la durée du grace.

Googlebot recevra un 200 avec du contenu alors que la page est supposée retourner un 404. C'est la définition d'un soft 404, et c'est exactement le type de régression qui passe sous le radar pendant des semaines.

La solution : forcer un pass pour les réponses 404/410 dans vcl_backend_response, ou réduire drastiquement le TTL et le grace pour ces status codes.

Vary header et contenu personnalisé

Si votre site sert du contenu différent selon le user-agent (desktop vs mobile, par exemple), le header Vary est indispensable. Sans lui, Varnish peut servir la version desktop en cache à Googlebot Smartphone — ce qui fausse complètement l'indexation mobile-first.

sub vcl_backend_response {
    if (beresp.http.Content-Type ~ "text/html") {
        set beresp.http.Vary = "Accept-Encoding, User-Agent";
    }
}

Attention : un Vary: User-Agent granulaire fragmente le cache en autant d'entrées qu'il y a de user-agents distincts, ce qui réduit drastiquement le hit ratio. La bonne approche est de normaliser le user-agent en amont dans vcl_recv vers deux ou trois catégories (mobile, desktop, bot), puis d'utiliser un header custom dans le Vary.

Redis comme cache d'objets : accélérer la couche applicative

Varnish agit en amont de l'application. Redis agit à l'intérieur de l'application, en cachant les résultats de requêtes SQL, les fragments de template, ou les réponses d'API internes.

Pourquoi Redis impacte indirectement le SEO

Redis ne sert pas directement les pages à Googlebot. Son impact est indirect mais significatif : il réduit le temps de génération des pages que Varnish ne cache pas (pages personnalisées, résultats de recherche interne, pages de catégories filtrées).

Sur un site e-commerce avec des facettes dynamiques, les URLs de type /chaussures?couleur=rouge&taille=42&marque=nike ne sont généralement pas mises en cache au niveau Varnish (trop de combinaisons, taux de hit trop faible). Mais si la requête SQL qui génère la liste de produits est cachée dans Redis, le TTFB passe de 1,2 seconde (requête SQL complexe avec JOIN sur 6 tables) à 80 ms (lecture Redis).

Pattern de cache-aside pour les pages SEO critiques

// cache-service.ts — Pattern cache-aside avec Redis pour les pages catégories

import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });

interface CategoryPageData {
  products: Product[];
  facets: Facet[];
  seoMeta: { title: string; description: string; canonical: string };
  breadcrumbs: Breadcrumb[];
  totalCount: number;
}

async function getCategoryPage(
  slug: string, 
  filters: Record<string, string>
): Promise<CategoryPageData> {
  // Construire une clé de cache déterministe
  const sortedFilters = Object.entries(filters)
    .sort(([a], [b]) => a.localeCompare(b))
    .map(([k, v]) => `${k}=${v}`)
    .join('&');
  const cacheKey = `cat:${slug}:${sortedFilters || 'default'}`;

  // Tenter la lecture Redis
  const cached = await redis.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
  }

  // Cache miss : requête DB complète
  const data = await buildCategoryPageFromDB(slug, filters);

  // Écriture asynchrone dans Redis
  // TTL de 5 minutes pour les catégories, 30s pour les recherches filtrées
  const ttl = sortedFilters ? 30 : 300;
  await redis.setEx(cacheKey, ttl, JSON.stringify(data));

  return data;
}

// Invalidation ciblée quand un produit change de stock/prix
async function invalidateCategoryCache(categorySlug: string): Promise<void> {
  const keys = await redis.keys(`cat:${categorySlug}:*`);
  if (keys.length > 0) {
    await redis.del(keys);
  }
}

Le piège de l'invalidation stale et du contenu SEO

Le cache Redis pose un problème spécifique au SEO : si vous modifiez une meta description, un canonical, ou un titre dans le CMS, et que l'invalidation Redis ne se déclenche pas, Googlebot va continuer à voir l'ancienne version.

Ce scénario se produit régulièrement quand l'invalidation est basée sur des événements (webhook CMS, événement de sauvegarde) plutôt que sur un TTL. Un événement perdu = un cache stale indéfiniment. La combinaison TTL court + invalidation événementielle est la seule approche robuste : le TTL agit comme filet de sécurité.

CDN : la couche de cache la plus proche de Googlebot

Le CDN (Cloudflare, Fastly, AWS CloudFront, Akamai) ajoute un cache géographiquement distribué en frontal de votre infrastructure. Pour le SEO, c'est la couche qui a le plus d'impact direct sur le TTFB perçu par Googlebot, car elle élimine la latence réseau.

Points de présence et Googlebot

Googlebot crawle principalement depuis les États-Unis (data centers Google aux US). Si votre serveur d'origine est en Europe et que vous n'avez pas de CDN, chaque requête de crawl ajoute 80-120 ms de latence réseau pure. Un CDN avec un PoP aux US élimine cette latence pour les requêtes cachées.

Pour la configuration CDN spécifique à Cloudflare et ses implications SEO, nous avons un guide dédié qui couvre les règles de page, le mode rocket loader et les pièges courants.

Cache-Control headers : le contrat entre votre origin et le CDN

La configuration cache-control est le point de contrôle le plus critique. Un header mal configuré peut soit empêcher tout caching CDN, soit cacher des pages dynamiques trop longtemps.

# Configuration Nginx pour les headers cache-control orientés SEO
# /etc/nginx/conf.d/cache-headers.conf

# Pages HTML — cachées au CDN 5 min, pas en cache navigateur
location ~* \.html$ {
    add_header Cache-Control "public, s-maxage=300, max-age=0, must-revalidate";
    add_header X-Cache-Status $upstream_cache_status;
}

# Pages dynamiques servies par l'application
location / {
    proxy_pass http://app_backend;
    
    # Laisser l'application définir ses propres headers Cache-Control
    # mais forcer un s-maxage si l'application ne le fait pas
    proxy_hide_header Cache-Control;
    
    # Header conditionnel via map (défini dans http block)
    add_header Cache-Control $cache_control_header;
    
    # Stale-while-revalidate : sert le stale pendant que le CDN 
    # récupère une version fraîche en arrière-plan
    add_header Cache-Control "public, s-maxage=300, stale-while-revalidate=60" always;
}

# Sitemap XML — TTL court, Googlebot le recrawle fréquemment
location ~* sitemap.*\.xml$ {
    add_header Cache-Control "public, s-maxage=600, max-age=0";
}

# Robots.txt — même logique
location = /robots.txt {
    add_header Cache-Control "public, s-maxage=3600, max-age=0";
}

# Assets statiques — TTL long avec immutable
location ~* \.(css|js|woff2|png|jpg|webp|avif|svg)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

La distinction s-maxage vs max-age est essentielle : s-maxage contrôle le cache des proxies et CDN, max-age contrôle le cache navigateur. Vous voulez un s-maxage généreux (le CDN peut être purgé) et un max-age court ou nul pour les pages HTML (pour que les utilisateurs voient toujours le contenu frais).

Le piège stale-while-revalidate et les déploiements

stale-while-revalidate est une directive puissante : elle permet au CDN de servir immédiatement une réponse stale tout en récupérant une version fraîche en arrière-plan. Le premier visiteur après expiration reçoit la version périmée, mais tous les suivants reçoivent la version fraîche.

Le problème survient lors d'un déploiement avec changement de contenu SEO critique (redirections, canonicals, meta). Pendant la fenêtre stale-while-revalidate, Googlebot peut recevoir l'ancienne version. Sur un site à fort volume de crawl, cela signifie potentiellement des centaines de pages crawlées avec les anciennes metas après un déploiement.

La solution : purger le cache CDN dans votre pipeline de déploiement.

#!/bin/bash
# deploy.sh — Purge CDN post-deploy (exemple Cloudflare)

CLOUDFLARE_ZONE_ID="your-zone-id"
CLOUDFLARE_API_TOKEN="your-api-token"

# Déployer l'application
echo "Deploying application..."
npm run build && pm2 restart app

# Attendre que l'app soit healthy
sleep 5
curl -sf http://localhost:3000/health || exit 1

# Purge sélective : uniquement les pages modifiées
# Plus rapide et plus safe qu'un purge_everything
CHANGED_URLS=$(git diff HEAD~1 --name-only | grep -E '\.(tsx|vue|html)$' | \
  node scripts/url-from-file.js)

if [ -n "$CHANGED_URLS" ]; then
  echo "Purging ${#CHANGED_URLS[@]} URLs from Cloudflare cache..."
  curl -s -X POST \
    "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/purge_cache" \
    -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
    -H "Content-Type: application/json" \
    --data "{\"files\": $(echo "$CHANGED_URLS" | jq -R -s 'split("\n") | map(select(. != ""))')}"
else
  echo "No content changes detected, skipping CDN purge."
fi

# Invalider aussi le cache Varnish local
echo "Purging Varnish cache..."
varnishadm "ban req.url ~ ."

Scénario concret : migration d'un catalogue de 22 000 pages

Un retailer mode avec 22 000 pages produit et 450 pages catégories, hébergé sur Magento 2 avec un serveur origin unique à Paris. Avant optimisation du cache :

• TTFB moyen : 1 400 ms (mesuré via Screaming Frog, crawl de 5 000 pages)
• Crawl Googlebot : 2 800 pages/jour (mesuré via les logs d'accès serveur avec GoAccess)
• Taux d'indexation : 68 % du catalogue dans l'index Google (vérifié via site: et Search Console)
• Temps pour indexer un nouveau produit : 8-14 jours en moyenne

Stack de cache déployé

1. Redis (ElastiCache, r6g.large) : cache des blocs CMS, résultats de requêtes catalogue, sessions
2. Varnish 7.x : full-page cache sur le serveur origin, TTL 10 minutes pour les pages produit, 5 minutes pour les catégories
3. Cloudflare Pro : CDN avec cache HTML activé via Page Rules, TTL s-maxage=300

Résultats après 3 semaines

• TTFB moyen : 45 ms pour les cache hits CDN, 180 ms pour les cache hits Varnish, 400 ms pour les cache miss (Redis absorbe la charge SQL)
• Crawl Googlebot : 9 200 pages/jour — multiplication par 3,3
• Taux d'indexation : 94 % après 3 semaines (vs 68 % avant)
• Temps pour indexer un nouveau produit : 1-3 jours

Le gain le plus significatif ne venait pas du TTFB seul, mais de la stabilité : avant le cache, les pics de trafic utilisateur dégradaient le TTFB vers 3-4 secondes, et Googlebot ralentissait son crawl en conséquence. Avec le cache, le TTFB reste stable même sous charge.

Ce qui a failli mal tourner

Pendant le déploiement, les pages de redirection 301 gérées par Magento étaient cachées par Varnish avec le même TTL que les pages normales. Quand l'équipe a corrigé des erreurs de redirections, les anciennes redirections continuaient d'être servies depuis le cache. Il a fallu ajouter une règle spécifique dans Varnish pour ne jamais cacher les réponses 301/302, ou les cacher avec un TTL de 60 secondes maximum.

Un second problème est apparu avec les canonicals : le cache CDN servait des pages avec trailing slash et sans trailing slash comme deux entrées de cache distinctes, mais le canonical pointait vers une seule version. Résultat : du contenu dupliqué en cache avec le bon canonical — pas de problème SEO direct, mais un gaspillage de cache et un hit ratio dégradé. La normalisation des URLs en amont (redirection Nginx vers la version canonique avant le cache) a résolu le problème.

Diagnostiquer les problèmes de cache en production

Déployer un cache ne suffit pas. Il faut monitorer en continu que le cache fonctionne correctement, en particulier pour les requêtes de Googlebot.

Vérifier les headers de cache avec curl

# Vérifier ce que Googlebot reçoit réellement
curl -sI -H "User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://www.votresite.com/chaussures/running-homme" | \
  grep -iE "^(cache-control|x-cache|x-varnish|cf-cache-status|age|vary|x-served-by):"

# Sortie attendue :
# cache-control: public, s-maxage=300, stale-while-revalidate=60
# x-cache: HIT
# cf-cache-status: HIT
# age: 142
# vary: Accept-Encoding
# x-varnish: 393218 393012

Si vous voyez cf-cache-status: DYNAMIC ou x-cache: MISS de manière persistante sur des pages qui devraient être cachées, le problème vient généralement d'un header Set-Cookie ou Cache-Control: private émis par l'application.

Screaming Frog pour un audit de masse

Screaming Frog permet de crawler votre site et de capturer les headers de réponse. Configurez un custom extraction pour les headers X-Cache, CF-Cache-Status, Age et Cache-Control. Exportez les résultats et filtrez :

• Pages avec Cache-Control: private ou no-store → devraient-elles être cachées ?
• Pages avec Age: 0 systématique → le cache ne fonctionne pas pour ces URLs
• Pages avec un Vary trop granulaire → fragmentation de cache

Logs serveur pour tracer le comportement de Googlebot

L'analyse des logs serveur reste la méthode la plus fiable pour vérifier que Googlebot bénéficie effectivement du cache. Ajoutez le status de cache dans votre format de log Nginx :

# Format de log avec cache status
log_format seo_cache '$remote_addr - $http_user_agent [$time_local] '
                     '"$request" $status $body_bytes_sent '
                     '"$upstream_cache_status" $request_time';

# Log séparé pour les bots
map $http_user_agent $is_bot {
    ~*googlebot  1;
    ~*bingbot    1;
    default      0;
}

access_log /var/log/nginx/bot_access.log seo_cache if=$is_bot;

Avec ce format, vous pouvez extraire le taux de cache hit spécifiquement pour Googlebot :

# Taux de cache hit pour Googlebot sur les dernières 24h
grep "Googlebot" /var/log/nginx/bot_access.log | \
  awk '{print $NF}' | sort | uniq -c | sort -rn

# Résultat typique attendu :
#   8432 HIT
#   1203 MISS
#    341 EXPIRED
#     28 BYPASS

Un ratio HIT/(HIT+MISS) inférieur à 70 % pour Googlebot indique un problème de configuration — probablement des cookies ou des query strings qui fragmentent le cache.

Edge cases et trade-offs à connaître

Pages avec personnalisation partielle

Si vos pages affichent un élément personnalisé (nom de l'utilisateur, panier, wishlist), vous ne pouvez pas cacher la page entière. Deux approches :

ESI (Edge Side Includes) : Varnish supporte ESI nativement. Vous cachez le body de la page et injectez les fragments personnalisés via des includes serveur. Complexe à mettre en œuvre mais optimal pour le crawl, car Googlebot reçoit le contenu statique sans les fragments personnalisés (qui ne le concernent pas).

Client-side hydration : servez la page complète depuis le cache, et chargez les éléments personnalisés en JavaScript côté client. Googlebot ignore le JavaScript de personnalisation (il n'a pas de session), et indexe le contenu statique. C'est l'approche la plus simple et la plus courante.

Cache et pages paginées

Les pages paginées (/categorie?page=2, /categorie?page=3) doivent être cachées avec le query string dans la clé de cache. Si votre configuration Varnish ou CDN strip les query strings pour normaliser les URLs, vous servirez la page 1 à toutes les requêtes — un désastre pour l'indexation des pages profondes du catalogue. Consultez notre guide sur la pagination SEO pour les implications côté indexation.

Cache et hreflang / contenu multilingue

Sur un site multilingue, le contenu varie selon la locale mais l'URL peut être la même (si vous utilisez la détection par header Accept-Language). Le cache doit inclure la locale dans sa clé, sinon la version française sera servie à un utilisateur anglophone — et potentiellement à Googlebot qui crawle avec des headers anglais.

La recommandation forte : utilisez des URLs distinctes par langue (/fr/, /en/) plutôt que la détection par header. Cela simplifie radicalement la configuration du cache et élimine une classe entière de bugs SEO.

Quand le cache fait plus de mal que de bien

Le cache n'est pas toujours la bonne réponse. Si votre site a moins de 500 pages et un TTFB déjà sous les 300 ms, ajouter Varnish crée de la complexité sans bénéfice mesurable. Le crawl budget n'est pas un problème pour les petits sites — Googlebot a largement la capacité de tout crawler, même lentement.

De même, si votre contenu change en temps réel (fil d'actualité, prix dynamiques, stock en temps réel), un TTL trop long signifie que Googlebot indexe du contenu obsolète. Pour ces cas, un TTL de 30-60 secondes avec stale-while-revalidate est un bon compromis entre performance et fraîcheur.

Maintenir la cohérence cache/SEO dans la durée

Le vrai risque du server-side caching n'est pas la mise en place initiale — c'est la dérive. Un développeur ajoute un header Set-Cookie sur une route publique, et soudain 30 % des pages ne sont plus cachées. Un changement de CDN perd la configuration de cache HTML. Une migration de CMS change la structure des headers Cache-Control.

Ces régressions sont silencieuses. Votre trafic organique baisse trois semaines plus tard, et personne ne fait le lien avec le commit qui a ajouté un cookie analytics côté serveur.

Un monitoring automatisé des headers HTTP — qui vérifie que Cache-Control, X-Cache, et les status codes restent conformes à ce qui est attendu — est le seul moyen fiable de détecter ces régressions avant qu'elles n'impactent le crawl. Seogard détecte ce type de changement en continu, en comparant les headers de réponse entre chaque crawl et en alertant dès qu'un écart apparaît sur les pages stratégiques.

Le server-side caching bien configuré est le multiplicateur de force le plus efficace entre votre infrastructure et Googlebot. Varnish pour le full-page, Redis pour la couche applicative, CDN pour la distribution géographique — chaque couche a son rôle. Mais sans monitoring des headers et des temps de réponse, vous opérez à l'aveugle sur la métrique qui détermine combien de vos pages Google voit chaque jour.