Code http 503 : causes, SEO et Retry-After

Réponse courte

Le code HTTP 503 signale que le serveur est temporairement incapable de traiter une requête pourtant valide. L’URL existe, le contenu aussi : c’est l’infrastructure qui est en pause ou saturée. C’est le seul code d’erreur qu’on sert volontairement, pendant une maintenance, et bien accompagné il protège l’indexation au lieu de la dégrader.

Il peut venir du serveur d’origine comme d’un intermédiaire : proxy inverse, CDN ou répartiteur de charge émettent leurs propres 503 quand l’origine ne répond pas assez vite.

Retry-After

l’en-tête qui distingue une maintenance maîtrisée d’une panne : il dit à Googlebot quand revenir.

24 à 48 h

au-delà, Google cesse de traiter le 503 comme temporaire et commence à retirer les URL de son index.

200

le code à ne surtout pas servir sur une page de maintenance. C’est le piège classique du soft 503.

Schéma d’une indisponibilité : le visiteur voit une page de maintenance, le robot reçoit un code 503, l’infrastructure est en cours de réparation. — Ce que voit chacun pendant une indisponibilité : le visiteur une page de maintenance, Googlebot un code 503, et vous une infrastructure à diagnostiquer.

Comment diagnostiquer une erreur 503 ?

Quatre étapes, du plus fréquent au plus discriminant. La première élimine à elle seule la moitié des cas, parce qu’elle vérifie ce que le serveur répond vraiment plutôt que ce que la page affiche.

01Confirmer le code réellement renvoyé. Une page « nous revenons bientôt » peut très bien être servie en 200. Vérifiez les en-têtes plutôt que l’écran, avec une requête en ligne de commande ou l’inspecteur réseau du navigateur.
02Identifier qui émet le 503. Serveur d’origine, proxy inverse, CDN ou pare-feu applicatif : les quatre en produisent. Un message de type « backend fetch failed » désigne un intermédiaire qui n’a pas obtenu de réponse de l’origine.
03Regarder la charge au moment de l’incident. Processeur, mémoire, nombre de processus disponibles, connexions à la base. Un pic de trafic ou un traitement coûteux suffit à saturer une capacité pourtant correcte le reste du temps.
04Lire les journaux, dans cet ordre. Serveur web, puis processus PHP, puis applicatif, puis base de données. C’est la seule étape qui isole un dépassement de délai d’une saturation, et un composant défaillant d’une surcharge générale.

Le raccourci à éviter. Afficher une page de maintenance en laissant le serveur répondre 200. C’est un « soft 503 » : Google peut indexer cette page à la place de votre contenu, et classer les URL concernées en soft 404. La page de maintenance doit être servie avec un code 503.

À quoi ressemble une réponse 503 correcte ?

Les en-têtes comptent plus que le corps de la page. Voici ce qu’un serveur doit renvoyer pendant une maintenance annoncée d’une heure.

HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=UTF-8
Retry-After: 3600
Cache-Control: no-store

Retry-After accepte une durée en secondes ou une date. Cache-Control: no-store évite qu’un cache intermédiaire continue de servir le 503 après le rétablissement, ce qui prolongerait la panne bien après sa fin.

Quelles sont les causes fréquentes d’une erreur 503 ?

Pour chaque cause, le signe qui la trahit et la correction associée.

Cause	Ce qui la trahit	Correction
Surcharge du serveur	Processus saturés, mémoire pleine, pics de trafic corrélés	Augmenter la capacité, alléger les traitements coûteux
Maintenance planifiée	Aucune anomalie, l’indisponibilité est voulue	Servir un 503 avec Retry-After, jamais un 200
Délai dépassé en amont	« backend fetch failed » émis par le proxy ou le CDN	Réduire le temps de réponse de l’origine
Limitation de débit	503 servis à certaines adresses seulement	Exclure Googlebot des règles de limitation
Attaque par saturation	Volume anormal de requêtes, protection déclenchée	Filtrer en amont, sans bloquer les robots légitimes
Base de données indisponible	Connexions refusées ou épuisées dans les journaux	Vérifier le pool de connexions et les requêtes lentes

Quel est l’impact SEO d’une erreur 503 ?

Le 503 est le seul code d’erreur que Google interprète comme une invitation à revenir. Tant que l’indisponibilité reste brève, il n’a pratiquement aucune conséquence. Ce qui coûte, c’est la durée et la récurrence.

Exploration

Googlebot enregistre un échec et reprogramme sa visite. Répétés, ces échecs le poussent à ralentir sa cadence pour ne pas gaspiller de ressources.

Indexation

Au-delà de vingt-quatre à quarante-huit heures, Google cesse de traiter le 503 comme temporaire et retire progressivement les URL touchées.

Soft 503

Une page de maintenance servie en 200 est le vrai danger : elle peut être indexée à la place du contenu, et les URL concernées basculer en soft 404.

Revenus

Sur un tunnel de commande ou de réservation, l’effet est commercial avant d’être organique. Une panne brève suffit à coûter cher.

Comment mettre un site en maintenance sans nuire au référencement ?

C’est le cas d’usage légitime du 503, et il se joue en trois décisions. Google documente explicitement cette procédure : elle n’a rien d’une astuce.

À retenir

01Servir un vrai 503 sur toutes les URL concernées, page d’accueil comprise.
02Ajouter Retry-After avec une durée réaliste, plutôt trop longue que trop courte.
03Empêcher la mise en cache de la réponse, pour que le rétablissement soit immédiat.

Une maintenance de quelques heures traitée ainsi ne laisse aucune trace. La même maintenance servie en 200 peut faire indexer une page vide sur vos requêtes stratégiques, et cette erreur-là se paie en semaines.

Sur votre site

Vos pages de maintenance répondent-elles le bon code ?

Je relève les codes de réponse servis à Googlebot sur trente jours, les soft 503 compris, et je vous dis lesquels traiter en premier. Réponse sous 24 heures ouvrées.

Demander un audit technique →

Les bonnes pratiques à retenir

Six habitudes qui séparent une indisponibilité sans conséquence d’une perte de positions.

Vérifier le code réellement renvoyé après chaque mise en maintenance, jamais l’affichage seul.
Accompagner tout 503 volontaire d’un en-tête Retry-After.
Ne jamais laisser une indisponibilité dépasser vingt-quatre heures sur des pages stratégiques.
Interdire la mise en cache des réponses 503, pour ne pas prolonger la panne après sa fin.
Exclure les robots des règles de limitation de débit qui produisent des 503.
Surveiller la disponibilité en continu, avec une alerte dès la première minute.

Les codes à ne pas confondre avec un 503

500Internal Server Error Erreur interne, sans notion de durée. Là où le 503 annonce un retour, le 500 ne promet rien : c’est le plus coûteux des deux. Lire la fiche → 502Bad Gateway Un intermédiaire a reçu une réponse invalide de l’origine. Le problème est dans la chaîne, pas dans la capacité. Voir la référence → 504Gateway Timeout L’origine n’a pas répondu dans le délai imparti. La cause est un temps de traitement trop long, pas une indisponibilité. Voir la référence → 429Too Many Requests Limitation de débit volontaire, souvent confondue avec une surcharge. Servie à Googlebot, elle fait chuter la cadence d’exploration. Lire la fiche →

Questions fréquentes sur le code 503

Quelle est la différence entre un 503, un 500 et un 504 ?

Le 503 annonce une indisponibilité temporaire, donc un retour. Le 500 signale une erreur interne sans notion de durée. Le 504 indique qu’un intermédiaire n’a pas obtenu de réponse à temps de l’origine. Des trois, le 503 est le seul qu’on serve volontairement.

Combien de temps un 503 peut-il durer sans risque ?

Quelques heures ne laissent pas de trace. Au-delà de vingt-quatre à quarante-huit heures, Google cesse de le traiter comme temporaire et commence à retirer les URL concernées de son index. La remontée prend ensuite plusieurs semaines.

Faut-il vraiment ajouter un en-tête Retry-After ?

Oui pour une indisponibilité voulue. Il indique quand revenir et évite que le moteur interprète une absence de réponse comme durable. Une durée réaliste, plutôt surestimée : un délai trop court fait revenir le robot sur une porte encore fermée.

Pourquoi mon CDN renvoie-t-il un 503 alors que mon serveur va bien ?

Un proxy ou un CDN émet ses propres 503 quand l’origine ne répond pas dans le délai qu’il s’accorde. Le serveur peut donc être fonctionnel mais trop lent de son point de vue. La correction porte sur le temps de réponse, pas sur la disponibilité.

Que faire si le 503 est intermittent ?

Un 503 qui va et vient traduit presque toujours une saturation ponctuelle. Corrélez les horodatages des erreurs avec les pics de trafic et les métriques de charge : c’est ce croisement, et non la lecture des seuls journaux, qui désigne le composant en cause.