WordPress erreur 503 Service Unavailable : diagnostic et solutions

Une erreur 503 « Service Unavailable » sur WordPress signifie que le serveur n’est pas en état de traiter la requête : il est surchargé, en maintenance, ou le moteur PHP qui exécute WordPress ne répond plus. Les causes les plus fréquentes sont un fichier .maintenance oublié après une mise à jour, des processus PHP saturés ou plantés, une extension trop gourmande et un pic de trafic ou de robots. On la diagnostique en lisant les journaux du serveur, et on la règle souvent en redémarrant ou en redimensionnant PHP, puis en supprimant la cause.

Contrairement à l’erreur critique WordPress, qui vient d’un plantage du code PHP de votre site, l’erreur 503 se situe souvent un cran plus bas, au niveau du serveur. Voici comment la reconnaître, la diagnostiquer et la corriger, avec un cas réel vécu sur notre propre site.

• Que veut dire une erreur 503 ?
• Quelles sont les causes sur un site WordPress ?
• Comment diagnostiquer une erreur 503, étape par étape ?
• Quelles solutions selon la cause ?
• Retour d’expérience : la 503 d’osmova.com
• Une erreur 503 nuit-elle au référencement ?
• Les erreurs à éviter
• Questions fréquentes
• Sources

Que veut dire une erreur 503 ?

Le code HTTP 503 indique, selon la documentation MDN, que le serveur n’est pas prêt à traiter la requête. Les raisons classiques sont une maintenance ou une surcharge (mémoire, processeur, nombre de connexions). C’est par nature un code d’erreur temporaire : il peut être accompagné d’un en-tête Retry-After qui indique au navigateur ou au robot quand revenir.

Sur un site WordPress, le message prend plusieurs formes selon l’élément qui le produit :

Identifier qui affiche le message est la première étape du diagnostic : cela vous dit à quel étage chercher.

Quelles sont les causes sur un site WordPress ?

1. Le mode maintenance est resté actif

Pendant une mise à jour, WordPress crée un fichier .maintenance à la racine du site et renvoie une 503 avec l’en-tête Retry-After: 600. Normalement, le fichier disparaît à la fin de la mise à jour. Si la mise à jour est interrompue, le fichier reste. Le code de WordPress ignore toutefois un fichier .maintenance vieux de plus de 10 minutes : si la 503 persiste bien au-delà, la cause est probablement ailleurs.

2. PHP-FPM est saturé ou planté

Sur la plupart des serveurs modernes, WordPress est exécuté par PHP-FPM, un gestionnaire qui maintient un « pool » de processus PHP. Le nombre maximal de processus est fixé par la directive pm.max_children, qui limite donc le nombre de requêtes PHP traitées en même temps. Quand tous les processus sont occupés (pages lentes, requêtes bloquées) ou quand ils plantent, le serveur web n’obtient plus de réponse et renvoie une 503.

3. Une extension ou un traitement trop lourd

Une extension qui lance des requêtes interminables, un import, une tâche planifiée (WP-Cron) mal conçue ou un appel à une API externe qui ne répond pas peuvent monopoliser les processus PHP. Quelques visiteurs suffisent alors à saturer le pool.

4. Un pic de trafic ou de robots

Une campagne publicitaire, un passage en télévision, mais aussi des robots agressifs (aspirateurs de contenu, tentatives de connexion en masse sur wp-login.php ou xmlrpc.php) peuvent dépasser la capacité du serveur. Sans mise en cache, chaque visite exécute PHP et interroge la base de données, ce qui accélère la saturation.

5. Les limites de l’hébergement

Sur un hébergement mutualisé, chaque site dispose d’un quota de processeur, de mémoire et de processus. Dépasser ce quota peut déclencher une 503 imposée par l’hébergeur. Une maintenance ou une panne côté hébergeur ou CDN produit le même symptôme.

Comment diagnostiquer une erreur 503, étape par étape ?

1. Vérifiez que le problème est général. Testez depuis un autre réseau (4G) et en navigation privée. Consultez la page d’état de votre hébergeur ou de votre CDN.
2. Regardez la racine du site. Par FTP ou SFTP, cherchez un fichier .maintenance (fichier caché : activez l’affichage des fichiers cachés dans votre client).
3. Lisez le journal d’erreurs du serveur web. Sur Apache, un message du type AH01067: Failed to read FastCGI header ou une erreur de connexion au socket PHP indique que PHP-FPM ne répond pas correctement.
4. Lisez le journal de PHP-FPM. Deux messages sont particulièrement parlants : un avertissement signalant que le pool a atteint pm.max_children (saturation) et des lignes indiquant qu’un processus fils s’est arrêté sur un signal, comme SIGSEGV (plantage).
5. Consultez le journal lent si la directive request_slowlog_timeout est activée : PHP-FPM y écrit la pile d’appels des requêtes trop longues, ce qui désigne souvent l’extension responsable.
6. Mettez en regard l’heure de début. Une mise à jour automatique, une tâche planifiée, un envoi de newsletter ou un pic de trafic dans les journaux d’accès au même moment sont des suspects sérieux.

Sur un serveur Debian ou Ubuntu avec Apache, les emplacements courants sont les suivants (ils varient selon la version de PHP et le panneau d’administration) :

# État du service PHP-FPM
sudo systemctl status php8.3-fpm

# Dernières lignes du journal PHP-FPM
sudo tail -n 100 /var/log/php8.3-fpm.log

# Erreurs Apache
sudo tail -n 100 /var/log/apache2/error.log

Sur un hébergement mutualisé, vous n’avez pas ces accès : les journaux sont parfois disponibles dans l’espace client, sinon il faut les demander au support en donnant l’heure précise de l’incident.

Quelles solutions selon la cause ?

Un mot sur pm.max_children : l’augmenter à l’aveugle est une fausse bonne idée. Chaque processus PHP consomme de la mémoire ; si vous en autorisez plus que la mémoire du serveur ne peut en porter, vous remplacez une 503 par un serveur qui s’effondre. La bonne valeur dépend de la mémoire consommée par un processus sur votre site et de la mémoire disponible.

Autre point : si la 503 est devenue fréquente sur un hébergement d’entrée de gamme, le problème est peut-être tout simplement l’hébergement. Nous comparons les options dans notre article sur les meilleurs hébergeurs web.

Retour d’expérience : la 503 d’osmova.com

Pourquoi OPcache ? Cette extension de PHP garde en mémoire partagée le code PHP déjà compilé, pour éviter de le recompiler à chaque requête. Par défaut, PHP vérifie périodiquement si les fichiers ont changé (opcache.validate_timestamps). Quand ce cache se retrouve dans un état incohérent, par exemple après le remplacement de nombreux fichiers lors d’une mise à jour, les processus qui s’en servent peuvent planter. La documentation PHP indique que le cache se vide avec opcache_reset() ou par un redémarrage du serveur, ce qui explique que le redémarrage de PHP-FPM ait suffi.

Une erreur 503 nuit-elle au référencement ?

À court terme, peu. Google explique que les erreurs serveur 5xx conduisent ses robots à ralentir temporairement l’exploration, proportionnellement au nombre d’URL en erreur, et que les pages déjà indexées sont conservées. Mais il précise aussi qu’elles finissent par être retirées de l’index si l’erreur persiste. Une 503 de quelques heures n’est donc pas grave ; une 503 qui dure plusieurs jours l’est.

C’est aussi pour cela que le code 503 est le bon code pour une maintenance programmée : il signale un problème temporaire. À l’inverse, une page de maintenance qui renvoie un code 200 risque d’être indexée à la place de vos vraies pages.

Les erreurs à éviter

• Redémarrer et oublier. Le redémarrage remet le site en ligne, pas la cause à zéro. Notez l’heure, conservez les journaux et cherchez pourquoi.
• Augmenter toutes les limites. Plus de processus, plus de mémoire, plus de temps d’exécution : sans diagnostic, vous déplacez le problème.
• Désactiver les mises à jour automatiques. Elles apportent des correctifs de sécurité. La réponse est la surveillance, pas l’abandon des mises à jour.
• Ignorer les robots. Une part importante du trafic de certains sites vient de robots. Les journaux d’accès le montrent en quelques minutes.
• Découvrir la panne par un client. Une surveillance externe (voir notre sélection d’outils de monitoring) vous alerte en quelques minutes.

Si vous n’avez ni le temps ni l’accès pour lire des journaux PHP-FPM à 7 heures du matin, c’est précisément ce que couvre notre offre d’hébergement et maintenance WordPress : mises à jour, surveillance et intervention en cas d’incident. Pour optimiser un site lent ou trop gourmand, notre agence WordPress peut auditer les extensions et le code.

Questions fréquentes

Combien de temps dure une erreur 503 ?

Pendant une mise à jour normale de WordPress, quelques secondes. Si elle dure plus de quelques minutes, c’est qu’un problème empêche le serveur de répondre et il faut intervenir.

Quelle différence entre une erreur 500 et une erreur 503 ?

La 500 signale une erreur interne, souvent un plantage du code. La 503 signale un service temporairement indisponible : maintenance, surcharge, ou moteur PHP qui ne répond pas.

Je suis sur un hébergement mutualisé, que puis-je faire ?

Vérifier le fichier .maintenance, désactiver les extensions par FTP, puis contacter le support avec l’heure de l’incident. Si les 503 se répètent, votre site a probablement dépassé les ressources de l’offre.

Un cache de pages peut-il éviter les 503 ?

Il réduit fortement le risque de saturation, car les pages en cache sont servies sans exécuter PHP. Il ne protège pas contre un PHP-FPM planté pour les pages non mises en cache ni pour l’administration.

Comment savoir si la 503 vient d’une mise à jour automatique ?

Comparez l’heure de début de l’erreur avec l’heure de la mise à jour : WordPress envoie en général un e-mail à l’administrateur après une mise à jour automatique du cœur, et les journaux du serveur gardent la trace des fichiers modifiés.

Sources

• MDN : 503 Service Unavailable
• Référence WordPress : wp_maintenance()
• Référence WordPress : wp_is_maintenance_mode()
• PHP.net : configuration de PHP-FPM (pm.max_children, request_slowlog_timeout)
• PHP.net : configuration d’OPcache
• Apache HTTP Server : mod_proxy_fcgi
• Google : effet des codes HTTP et des erreurs serveur sur l’exploration
• Editing wp-config.php (mises à jour automatiques du cœur)