Kubernetes et SEO : exploration, déploiements et TTFB

Mis à jour le 1er novembre 2026. Article réécrit : règles de Google sur la capacité d’exploration et les codes 5xx/429, valeurs par défaut de l’autoscaler et de l’arrêt des pods d’après la documentation Kubernetes, fin de maintenance d’Ingress NGINX (mars 2026), procédure de test d’un déploiement et tableau de diagnostic.

Google ne classe pas une page selon l’orchestrateur qui la sert. Ce qui compte, c’est ce que Googlebot observe : le délai de réponse, les codes HTTP et la stabilité des URL. Un cluster peut améliorer ces trois points ou les dégrader, selon la configuration des sondes, de l’arrêt des pods, du cache et des redirections. Voici ce qui change réellement, comment le vérifier, et pour quels sites.

Pour qui le sujet compte vraiment

Google précise que son guide sur le budget d’exploration vise surtout les sites d’environ un million de pages modifiées chaque semaine, ceux d’environ 10 000 pages modifiées chaque jour, et ceux dont beaucoup d’URL restent « Détectée, actuellement non indexée ». Ces seuils sont indicatifs ; en dessous, un site qui répond correctement est en général exploré sans difficulté.

Profil	Enjeu SEO de Kubernetes	Priorité
Site vitrine, blog de quelques centaines de pages	Faible : un hébergement mutualisé ou un VPS bien réglé suffit	Disponibilité et TTFB
Boutique de quelques milliers de produits	Moyen : erreurs pendant les mises en production, cache	Déploiements sans 5xx
Catalogue ou média de plusieurs centaines de milliers d’URL	Élevé : capacité d’exploration, pics de trafic	Tout l’article
Plateforme multi-sites ou multi-pays	Élevé : noms d’hôte, environnements, hreflang	Redirections et préproduction

Ce que Googlebot perçoit de l’infrastructure

La capacité d’exploration dépend de la santé du serveur

Google décrit une « limite de capacité d’exploration » : le nombre de connexions parallèles et leur durée. Elle augmente quand les réponses restent rapides et stables, et elle baisse quand le site ralentit ou renvoie des erreurs serveur (5xx) ou des signaux de limitation comme le code 429. Une capacité élevée ne sert à rien sans demande d’exploration : un site rapide, mais peu mis à jour, ne sera pas exploré davantage.

La documentation de Google sur la réduction de l’exploration ajoute deux précisions utiles. Le ralentissement provoqué par des codes 500, 503 ou 429 s’applique à tout le nom d’hôte, y compris aux URL qui fonctionnent. Et si Googlebot observe ces codes sur la même URL pendant plusieurs jours, elle peut être retirée de l’index. Quelques secondes d’erreurs pendant un déploiement n’ont pas cet effet ; des 502 à chaque mise en production quotidienne finissent par peser.

Le TTFB traverse plusieurs couches

Le délai avant le premier octet (TTFB) n’est pas une métrique Core Web Vitals, mais il précède le LCP. web.dev le qualifie de bon en dessous de 0,8 seconde, à titre indicatif. Dans un cluster, une requête traverse l’équilibreur du fournisseur, le contrôleur d’entrée ou la passerelle, le Service, le pod, puis l’application et ses dépendances. Chaque couche peut ajouter du temps.

Mesurez depuis l’extérieur du cluster, sur plusieurs URL représentatives (accueil, catégorie, fiche) :

for u in / /categorie/chaussures/ /produit/12-basket.html; do
  curl -s -o /dev/null -w "%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s $u\n" \
    -H "User-Agent: Mozilla/5.0 (test-ttfb)" "https://www.votresite.fr$u"
done

Répétez la mesure juste après un déploiement, puis à chaud. Un écart important signale un cache local vide ou des connexions ouvertes à la première requête.

Mise à l’échelle : ce que fait réellement l’autoscaler

D’après la documentation Kubernetes, l’autoscaler horizontal (HPA) recalcule toutes les 15 secondes par défaut. À la hausse, il n’applique aucune fenêtre de stabilisation : il peut ajouter jusqu’à 4 pods ou doubler le nombre de réplicas toutes les 15 secondes. À la baisse, il attend une fenêtre de 300 secondes. Les pods pas encore prêts sont mis de côté dans le calcul de l’utilisation du processeur.

Pour le SEO, le risque ne vient pas de l’autoscaler, mais des pods neufs déclarés prêts trop tôt. Un pod qui reçoit du trafic avant d’avoir rempli ses caches répond lentement, et Googlebot peut tomber dessus comme n’importe quel visiteur. La documentation recommande une startupProbe qui ne réussit qu’une fois le pic de démarrage passé, ou une readinessProbe qui ne passe au vert qu’à ce moment. Le réglage complet du HPA est détaillé dans notre guide de surveillance serveur.

Déploiements : éviter les 5xx

Pourquoi des erreurs apparaissent pendant un déploiement

Deux moments sont sensibles. Au démarrage, un pod peut recevoir des requêtes avant d’être capable d’y répondre si la sonde de disponibilité est absente ou trop permissive. À l’arrêt, la documentation Kubernetes indique que le retrait du pod des EndpointSlices se fait en même temps que le début de son arrêt, et non avant : quelques requêtes peuvent encore lui parvenir. Le délai de grâce est de 30 secondes par défaut, et le hook preStop s’exécute avant l’envoi du signal TERM.

Une configuration de départ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: boutique-web
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: boutique-web
  template:
    metadata:
      labels:
        app: boutique-web
    spec:
      terminationGracePeriodSeconds: 40
      containers:
      - name: web
        image: registry.example.com/boutique-web:2.3.1
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 5
          failureThreshold: 24
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 5
          failureThreshold: 2
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 20
          timeoutSeconds: 3
          failureThreshold: 3
        lifecycle:
          preStop:
            sleep:
              seconds: 10
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: boutique-web
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: boutique-web

Les points à retenir :

maxUnavailable: 0 impose qu’un nouveau pod soit prêt avant qu’un ancien soit retiré ;
la startupProbe laisse jusqu’à deux minutes (24 × 5 s) au démarrage, pendant lesquelles la liveness ne s’applique pas ;
la liveness vérifie seulement que le processus répond. Si elle interroge la base de données, une panne de celle-ci redémarre tous les pods en cascade ;
la pause preStop laisse le temps au retrait du trafic de se propager. L’action sleep est exécutée par le kubelet et ne demande aucun binaire dans l’image ; sur un cluster ancien qui ne la reconnaît pas, utilisez exec avec sleep, ce qui suppose un shell dans l’image. Vérifiez avec kubectl explain pod.spec.containers.lifecycle.preStop ;
le PodDisruptionBudget couvre les interruptions volontaires (maintenance des nœuds).

Tester un déploiement avant de le croire sans coupure

Lancez une boucle de requêtes pendant un déploiement, en préproduction puis à une heure creuse :

kubectl rollout restart deployment/boutique-web
until kubectl rollout status deployment/boutique-web --timeout=1s >/dev/null 2>&1; do
  curl -s -o /dev/null -w "%{http_code}\n" "https://www.votresite.fr/"
done | sort | uniq -c

Seuls des 200 sont attendus. Un seul 502 ou 503 justifie de revoir les sondes, la pause d’arrêt ou le délai de grâce.

Cache, sitemaps et robots.txt

Un cache en mémoire propre à chaque pod n’est pas partagé : deux réplicas peuvent servir deux versions d’une page, avec un titre ou une canonical différents. Un cache partagé (Redis, Valkey, Memcached) ou un cache de CDN supprime ces écarts, à condition de prévoir l’invalidation.

Le sitemap doit être identique quel que soit le pod : générez-le depuis la base ou un stockage partagé, pas dans un volume éphémère, avec le nom d’hôte canonique en HTTPS. Une ConfigMap commune peut aussi faire passer en production le Disallow: / de la préproduction : contrôlez le robots.txt servi après chaque déploiement.

Noms d’hôte, redirections et préproduction

Ajouter un nom d’hôte est facile : www et domaine nu servis en parallèle, HTTP non redirigé, ancien domaine encore routé deviennent autant d’URL explorables. Choisissez une version canonique et redirigez les autres en 301, en un seul endroit par règle (application, passerelle ou CDN). Avec la Gateway API :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: redirection-www
spec:
  parentRefs:
  - name: passerelle-publique
  hostnames:
  - "www.votresite.fr"
  rules:
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https
        hostname: "votresite.fr"
        statusCode: 301

Si vos règles reposent encore sur Ingress NGINX, notez que le projet Kubernetes a annoncé le 11 novembre 2025 l’arrêt de sa maintenance en mars 2026. Les installations existantes continuent de fonctionner, mais ne reçoivent plus de correctifs, y compris de sécurité. La migration vers la Gateway API ou un autre contrôleur est recommandée ; profitez-en pour relire chaque redirection.

Les environnements temporaires (une URL par branche, par exemple) doivent être protégés par authentification ou restriction d’adresse, plutôt que par un simple noindex qu’on oublie lors de la bascule.

Ce que Kubernetes ne change pas

Les titres, descriptions, balises canonical et données structurées produits par l’application.
Le maillage interne et l’arborescence des URL, tant qu’elles restent identiques.
Le rendu : une page vide remplie en JavaScript reste plus lente à traiter pour Google, qui met les pages en file d’attente de rendu.
L’INP et le CLS. Les seuils sont de 2,5 s pour le LCP, 200 ms pour l’INP (Core Web Vital depuis le 12 mars 2024) et 0,1 pour le CLS. L’infrastructure agit sur le LCP via le TTFB et la distance ; l’INP dépend du JavaScript exécuté dans le navigateur, le CLS de la réservation d’espace pour les images et les blocs insérés. Pour une boutique, voir les Core Web Vitals sous PrestaShop 9.

Diagnostiquer après une migration

Symptôme	Cause probable	Vérification
Pic de 5xx dans les Statistiques sur l’exploration aux heures de mise en production	Sondes absentes, arrêt sans pause	Boucle de test pendant un `rollout restart`
TTFB élevé juste après un déploiement ou une montée en charge	Cache local vide, pod déclaré prêt trop tôt	Mesure à froid et à chaud, sonde de démarrage
Pages explorées sous `www` et sans `www`	Redirection absente ou en double	`curl -sI` sur chaque variante
Contenu ou balises différents d’une requête à l’autre	Cache non partagé, réplicas de versions différentes	Comparer plusieurs réponses, vérifier l’image de chaque pod
Pods qui redémarrent en boucle lors d’une panne de base	Liveness qui teste les dépendances	Événements du cluster, définition des sondes

Les journaux de la passerelle isolent Googlebot et ses codes de réponse ; vérifiez par DNS inverse qu’un client qui se dit Googlebot vient bien de Google. Notre guide d’analyse des logs pour le SEO détaille l’extraction, celui sur les logs Nginx la lecture des 5xx. Les données terrain des Core Web Vitals, agrégées sur 28 jours, ne détectent pas un incident de déploiement. Pour le réglage serveur, voir la performance serveur des CMS.

Questions fréquentes

Kubernetes améliore-t-il le classement dans Google ?

Non, pas directement. Il peut améliorer la disponibilité et le temps de réponse, ce qui compte si l’infrastructure était le problème. Pour un site de quelques centaines de pages qui répond déjà vite, l’effet SEO est nul.

Une erreur 503 pendant un déploiement est-elle grave ?

Isolée, non : Google la traite comme une indisponibilité temporaire. Répétée chaque jour, elle réduit la capacité d’exploration de tout le nom d’hôte, et une URL qui renvoie ce code plusieurs jours de suite peut sortir de l’index.

Faut-il revoir sa stratégie SEO avant une migration vers Kubernetes ?

Pas si les URL restent identiques. Préparez la liste des URL et des redirections, le nom d’hôte canonique, le sitemap et le robots.txt de chaque environnement, puis testez un déploiement avec la boucle de requêtes.

Un CDN suffit-il pour améliorer les Core Web Vitals ?

Non. Il réduit le temps de chargement des ressources et peut réduire le TTFB des pages mises en cache, donc une partie du LCP. L’INP et le CLS se corrigent dans le code front-end.

Sources

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →