WordPress erreur 503 signifie que le serveur ne peut pas traiter la requête pour le moment. La cause est généralement une surcharge, une maintenance, une limite PHP atteinte, un plugin défaillant ou un serveur d’origine indisponible. Commencez par vérifier les en-têtes HTTP et les journaux, puis désactivez temporairement la cause la plus probable. Ne réinstallez pas WordPress avant d’avoir identifié le composant qui refuse les requêtes.

Que signifie exactement une erreur 503 dans WordPress

Le code HTTP 503, nommé Service Unavailable, décrit un état temporaire. Le serveur répond, mais il n’est pas prêt à servir la page demandée. La documentation HTTP de MDN cite deux cas classiques, la maintenance et la surcharge. Une application peut aussi renvoyer ce code quand ses seuils de mémoire, de processeurs ou de connexions sont atteints.

Cette nuance le distingue de l’erreur 500, qui indique plutôt une erreur interne non prévue, et de l’erreur 502, qui signale une réponse invalide ou absente entre un proxy et son serveur amont. Le navigateur ne permet pas toujours de faire cette différence. Vérifiez le code avec curl depuis un terminal, puis comparez le résultat avec une requête sans cache.

curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null -H 'Cache-Control: no-cache' https://example.com/

Un en-tête Retry-After peut préciser quand réessayer. Son absence ne prouve toutefois pas que l’incident vient de WordPress. Le code peut être produit par Apache, Nginx, PHP-FPM, un hébergeur ou un CDN.

Les contrôles immédiats avant toute modification

Notez l’heure exacte, l’URL touchée, le code reçu et le contenu de la page d’erreur. Testez la page d’accueil, une page statique et /wp-admin/. Si une seule action échoue, par exemple l’envoi d’un formulaire, le problème est probablement local à une extension ou à une limite de requête. Si toutes les URLs renvoient 503, cherchez d’abord une surcharge, une maintenance ou un incident d’hébergement.

Regardez aussi les en-têtes Server, Via, CF-Ray et Retry-After. Une page contenant cloudflare ou cloudflare-nginx n’a pas la même origine qu’une page générée par PHP. Les instructions Cloudflare sur l’erreur 503 recommandent de distinguer le serveur d’origine du réseau Cloudflare avant de corriger la configuration.

curl -sS -D - https://example.com/ -o /tmp/page-503.html
grep -iE 'cloudflare|retry-after|server|via' /tmp/page-503.html

Si le site revient tout seul après quelques minutes, ne concluez pas que le problème est réglé. Une saturation récurrente peut faire perdre des conversions, des sessions d’administration et des passages de robots. Conservez les journaux avant leur rotation.

Vérifier une maintenance WordPress ou un mode hors ligne

Une mise à jour interrompue peut laisser WordPress dans un état incohérent. Après une mise à jour normale, le fichier .maintenance placé à la racine est supprimé. S’il reste présent, le supprimer via FTP ou SSH peut rétablir l’accès, à condition d’avoir vérifié qu’aucune mise à jour n’est encore en cours.

cd /chemin/vers/wordpress
ls -la .maintenance
rm .maintenance

Ne lancez pas cette commande pendant une mise à jour active. Contrôlez ensuite les fichiers modifiés récemment et la version de PHP. Certains hébergeurs affichent aussi une page 503 pendant une opération planifiée. Le panneau de contrôle, les messages de l’hébergeur et le statut de la plateforme sont alors plus utiles qu’une modification du thème.

Pour une maintenance volontaire, préférez une réponse temporaire cohérente avec une page explicative et un en-tête Retry-After. Le moteur de recherche doit comprendre qu’il s’agit d’une indisponibilité passagère, pas d’une page supprimée.

Tester les extensions et le thème sans accès à wp-admin

Un plugin peut saturer PHP après une mise à jour, une requête externe lente ou une boucle d’action. Le test le plus rapide consiste à renommer le dossier de toutes les extensions. WordPress les désactive parce qu’il ne retrouve plus leur chemin. Si le site revient, renommez le dossier à son nom initial puis désactivez les extensions une par une.

cd wp-content
mv plugins plugins.pause
# Tester le site
mv plugins.pause plugins

Si le problème persiste, testez le thème actif. Vous pouvez renommer son dossier et laisser WordPress basculer vers un thème par défaut déjà installé. Cette méthode ne supprime rien et reste réversible. Elle est plus sûre qu’une suppression directe.

Consultez ensuite le journal PHP de l’hébergeur et le fichier wp-content/debug.log. Pour activer une trace sans afficher d’informations sensibles, utilisez une configuration de diagnostic comparable à celle décrite dans la documentation officielle du débogage WordPress.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Activez le journal le temps du diagnostic, reproduisez l’erreur une fois, puis désactivez le mode debug en production. Un fichier de log accessible publiquement peut divulguer des chemins, des requêtes SQL et des secrets.

Contrôler PHP, PHP-FPM et les limites de ressources

Une erreur 503 fréquente sur un hébergement mutualisé vient d’une limite de processus PHP atteinte. Une extension lourde, une importation ou plusieurs requêtes lentes occupent les travailleurs disponibles. Le serveur peut alors refuser les nouvelles demandes même si le processeur semble peu chargé.

Relevez dans le panneau d’hébergement la consommation de CPU, la mémoire, le nombre de processus et les erreurs de type max children. Sur un serveur que vous administrez, cherchez les événements PHP-FPM et la saturation du socket. Sur un mutualisé, transmettez à l’hébergeur l’heure, l’URL et l’identifiant de requête.

PHP indique que max_execution_time vaut souvent 30 secondes par défaut et précise que le serveur web peut appliquer d’autres délais. Consultez la documentation PHP sur la configuration d’exécution avant d’augmenter une limite. Augmenter la mémoire sans retirer la requête coûteuse peut déplacer la panne et aggraver la saturation.

php -i | grep -E 'memory_limit|max_execution_time|max_input_time'
wp core version
wp plugin list --status=active

Pour un import exceptionnel, préférez une commande WP-CLI fractionnée, une tâche planifiée ou une extension qui traite les lots. Ne mettez pas max_execution_time à zéro par réflexe sur un site public. Une requête sans limite peut monopoliser un processus jusqu’à l’intervention du serveur.

Écarter la base de données, le cache et les appels externes

Une base MySQL lente ne produit pas toujours une erreur 503 directement. Elle peut cependant bloquer plusieurs processus PHP jusqu’à l’expiration d’un délai. Vérifiez les erreurs de connexion, les requêtes lentes et l’espace disque. Si le message parle de MySQL server has gone away, suivez un diagnostic spécifique plutôt que de modifier le cache au hasard.

Purgez ensuite le cache de page, mais seulement après avoir confirmé que l’origine répond. Un cache peut prolonger l’affichage d’une page 503, tandis qu’un cache applicatif endommagé peut provoquer une boucle de régénération. Purgez le CDN, le plugin de cache et le cache objet dans cet ordre, avec une requête de contrôle entre chaque étape.

Les appels vers une API externe, un flux RSS ou un service de paiement sont une autre source. Un plugin qui attend une réponse distante pendant chaque chargement peut épuiser les processus. Désactivez temporairement l’intégration, mesurez le temps de réponse et ajoutez un délai limité avec une solution de repli. Les appels externes doivent rarement bloquer le rendu complet d’une page.

Si votre administration est déjà lente, notre guide sur le back office WordPress lent détaille les requêtes et extensions à isoler. Pour une erreur PHP plus franche, consultez aussi notre méthode de diagnostic d’une erreur 500 WordPress.

Différencier l’origine, le proxy et le CDN

Un reverse proxy peut renvoyer 503 parce que son serveur amont ne répond plus. Faites un test direct de l’origine si votre hébergeur fournit une adresse de contrôle, ou comparez une requête passant par le CDN avec une requête locale. N’exposez pas durablement une adresse d’origine sans filtrage et sans certificat valide.

Sur Nginx, cherchez dans le journal les mots upstream, connect() failed, no live upstreams et worker_connections. Sur Apache, regardez les erreurs du proxy et le journal PHP. Sur Cloudflare, le contenu de la page et les en-têtes permettent souvent d’attribuer le code. Demandez à l’hébergeur de confirmer un éventuel rate limit ou une limite de connexions.

sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u php-fpm --since '15 minutes ago'
ss -s

Ne copiez pas une configuration Nginx trouvée pour un autre environnement. Les réglages de délai, de buffer et de processus dépendent de PHP, du trafic et de la mémoire disponibles. Une modification mal testée peut transformer une 503 occasionnelle en panne permanente.

Remettre le site en ligne et vérifier qu’il répond vraiment

Après chaque correction, contrôlez plusieurs URLs avec un cache buster raisonnable. Vérifiez la page d’accueil, un article, une page de connexion et une ressource statique. Une réponse 200 sur l’accueil ne suffit pas si les appels à l’API ou l’administration restent indisponibles.

for url in / /wp-login.php /wp-json/; do
  printf '%s ' "$url"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}sn' "https://example.com${url}"
done

Observez la stabilité sur plusieurs minutes, puis consultez les journaux pour vérifier que la correction ne crée pas une nouvelle erreur. Purgez les caches seulement quand l’origine est saine. Si la 503 revient sous charge, mettez en place une mesure du temps de réponse et une alerte. Un contrôle externe toutes les cinq minutes suffit souvent pour repérer le début d’une saturation.

Documentez la cause, le correctif, l’heure et la preuve HTTP. Cette fiche accélère le support et évite de répéter des changements dangereux. Elle permet aussi de distinguer un incident isolé d’une capacité d’hébergement devenue insuffisante.

Quand contacter l’hébergeur

Contactez le support si le site renvoie 503 sans modification récente, si plusieurs comptes du même hébergement sont touchés, si les limites de processus sont invisibles ou si PHP-FPM est indisponible. Fournissez l’URL, le fuseau horaire, trois horaires précis, le code HTTP, les en-têtes non sensibles et un extrait de journal. Demandez explicitement la cause côté serveur et la limite atteinte.

Ne transmettez jamais un mot de passe, une clé API ou l’intégralité de wp-config.php. Si le support demande une copie de configuration, masquez les secrets. L’équipe d’hébergement peut confirmer une maintenance, une restriction de sécurité, un dépassement de ressources ou une panne réseau qu’un simple accès FTP ne permet pas de voir.

Enfin, si l’incident suit une mise à jour, restaurez une sauvegarde récente seulement après avoir conservé les journaux et vérifié la compatibilité PHP. Notre guide sur la sauvegarde WordPress avant une mise à jour explique le contrôle préalable qui limite ce type de retour arrière.

FAQ sur WordPress erreur 503

Une erreur 503 WordPress est-elle permanente

Non. Le code 503 décrit normalement une indisponibilité temporaire. Si elle revient, cherchez une surcharge, une limite PHP, une extension lente ou un incident d’hébergement au lieu de vous contenter de recharger la page.

Comment corriger une erreur 503 sans accès à wp-admin

Utilisez FTP ou SSH pour renommer temporairement wp-content/plugins, vérifier le fichier .maintenance et consulter les journaux. Ces actions sont réversibles et permettent d’isoler une extension ou une mise à jour interrompue.

Faut-il augmenter la mémoire PHP

Seulement si le journal confirme une limite mémoire et si l’hébergement autorise cette modification. Une mémoire plus élevée ne corrige pas une boucle, une requête lente ou un nombre de processus PHP insuffisant.

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

Une courte interruption peut être tolérée. Des réponses 503 répétées ou prolongées empêchent l’exploration et dégradent l’expérience. Rétablissez rapidement le site, évitez de mettre en cache la page d’erreur et surveillez les robots après l’incident.

Comment savoir si Cloudflare produit la 503

Examinez le corps HTML et les en-têtes. La présence de références Cloudflare oriente vers le CDN. Sans ces références, la cause est généralement l’origine ou l’hébergeur. Les journaux Cloudflare et ceux du serveur doivent être comparés à la même heure.

Sources vérifiées

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.