Erreur 503 WordPress : causes, diagnostic et solutions

En bref

• Symptôme : votre site affiche « Service temporairement indisponible » à la place de la page d’accueil.
• Cause la plus fréquente : un fichier .maintenance resté en place après une mise à jour interrompue.
• Temps de résolution : 5 minutes dans ce cas, 1 heure si le serveur sature.

Ce qu’il vous faut

• Un accès FTP ou le gestionnaire de fichiers de votre hébergeur
• Vos identifiants de panneau d’hébergement
• Compter 45 minutes

Ce n’est peut-être pas votre erreur

Trois pannes se ressemblent à l’écran. Si la page reste blanche, sans le moindre texte, allez à la fiche page blanche après mise à jour. Si vous lisez « Une erreur critique est survenue », passez par la fiche erreur critique. Si le navigateur annonce une erreur 500, c’est une autre panne. Le 503 se reconnaît à une chose : le serveur vous répond. Il vous demande de revenir plus tard.

Ce que le serveur vous dit

Un 503 signifie que la machine tourne. Elle a reçu votre demande, elle a décidé de ne pas la traiter. C’est la différence avec une erreur 500, où le serveur essaie et échoue.

Deux situations produisent ce refus. Soit WordPress a lui-même mis le site en pause, soit l’hébergeur a coupé le robinet parce que votre site consomme trop.

Commencez par la première. Elle se règle en cinq minutes et se vérifie sans rien casser.

Vérification 1 : le fichier .maintenance

Quand WordPress met à jour une extension, il dépose un fichier nommé .maintenance à la racine du site. Le temps de l’opération, chaque visiteur reçoit une page d’attente. À la fin, WordPress supprime le fichier.

Quand la mise à jour s’interrompt, le fichier reste. Le site affiche une maintenance qui ne finit jamais.

1. Connectez-vous en FTP ou ouvrez le gestionnaire de fichiers de votre hébergeur.
2. Placez-vous à la racine du site, le dossier qui contient wp-config.php, wp-content et wp-admin.
3. Activez l’affichage des fichiers cachés. Dans FileZilla, c’est le menu Serveur, puis « Forcer l’affichage des fichiers cachés ». Dans cPanel, c’est Réglages en haut à droite du gestionnaire de fichiers.
4. Cherchez un fichier nommé .maintenance, avec le point devant.
5. S’il existe, supprimez-le. Rechargez votre site.

Note. Ce fichier ne contient rien d’important. Le supprimer ne fait perdre aucune donnée. Si la mise à jour avait commencé à copier des fichiers, l’extension concernée peut se retrouver à moitié installée : vous la réinstallerez depuis wp-admin une fois le site revenu.

Si le site revient, arrêtez-vous là. Ouvrez ensuite Extensions et regardez laquelle affiche un numéro de version étrange ou un message d’erreur. Relancez sa mise à jour seule, sans en lancer d’autres en parallèle.

Vous trouvez le fichier absent ? Passez à la suite.

Vérification 2 : un mode maintenance oublié

Les extensions de type « Coming Soon » ou « Maintenance Mode » servent une page 503 à tous les visiteurs, et laissent passer les administrateurs connectés. D’où le cas classique : le site fonctionne pour vous, vos clients voient une page d’attente.

Testez-le en trente secondes. Ouvrez votre site dans une fenêtre de navigation privée. Si la page d’attente apparaît là et pas dans votre navigateur habituel, une extension pilote ce mode.

Rendez-vous dans Extensions et cherchez WP Maintenance, SeedProd, LightStart ou Coming Soon Page. Désactivez celle que vous trouvez, ou ouvrez ses réglages pour couper le mode.

À vérifier avant. Certains hébergeurs proposent leur propre mode maintenance dans le panneau de gestion. Si aucune extension ne correspond, cherchez du côté de votre hébergeur avant de creuser plus loin.

Vérification 3 : le serveur sature

C’est la cause qui prend du temps. Votre hébergement dispose d’un quota de processus PHP simultanés. Quand ce quota se remplit, le serveur refuse les demandes suivantes et renvoie un 503 jusqu’à ce que la file se vide.

Deux profils se croisent. Le pic de trafic ponctuel, qui se résout seul en quelques minutes. Et la consommation de fond, qui produit des 503 intermittents pendant des semaines.

Réglage ou compteur	Effet quand la limite tombe
Entrées de processus	Le serveur refuse toute nouvelle demande PHP et renvoie un 503. Les visiteurs déjà servis ne voient rien.
Mémoire allouée par processus	Le processus s’arrête en cours de route. Vous obtenez une erreur 500 plus souvent qu’un 503.
Processeur	Les pages se chargent en dizaines de secondes avant de basculer en 503 sous charge.
Connexions à MySQL	Le site répond mais affiche une erreur de connexion à la base, pas un 503.

Les deux dernières lignes servent à écarter des pistes. Si le compteur qui plafonne chez vous est celui des connexions MySQL, votre panne n’est pas celle décrite ici.

Lire la consommation dans votre panneau

Cherchez une section « Utilisation des ressources », « Resource Usage » ou « Statistiques » dans votre panneau d’hébergement. Vous y verrez la mémoire, le nombre d’entrées de processus et le processeur, avec le nombre de fois où votre compte a touché la limite.

Cet écran a un défaut : il échantillonne. Chez la plupart des hébergeurs mutualisés, la mesure tombe toutes les minutes ou toutes les cinq minutes. Un pic de dix secondes n’y apparaît pas, alors qu’il a suffi à couper le site. Un tableau vert ne prouve donc rien. Un tableau rouge, lui, prouve quelque chose.

Si le compteur d’entrées de processus touche le plafond plusieurs fois par jour, vous tenez votre cause.

Trouver ce qui consomme

Sans accès à wp-admin, la seule méthode fiable passe par le FTP.

1. Ouvrez wp-content/plugins/.
2. Renommez le dossier plugins en plugins-off. WordPress ne trouve plus aucune extension et les désactive toutes.
3. Rechargez le site.

Avertissement. Cette manip coupe toutes les fonctionnalités apportées par vos extensions pendant le test : formulaires, cache, boutique, tunnel de paiement. Faites-la en dehors de vos heures de trafic. Si vous gérez une boutique WooCommerce avec des commandes en cours, ne la faites pas du tout et allez directement au dernier chapitre.

Le site revient ? Une extension est en cause. Remettez le nom plugins, puis renommez les dossiers un par un, en commençant par les gros consommateurs connus : les extensions de statistiques en temps réel, les moteurs de recherche interne, les sauvegardes programmées, les imports de flux produits.

Le site reste en 503 ? Les extensions sont hors de cause. Regardez du côté du thème, en renommant son dossier dans wp-content/themes/. WordPress basculera sur un thème par défaut s’il en trouve un.

Note. Les tâches planifiées de WordPress, le fameux cron, se déclenchent à la visite. Un site qui reçoit une vague de trafic après plusieurs heures de calme lance parfois vingt tâches d’un coup. C’est une cause fréquente de 503 matinaux à heure fixe.

Vérification 4 : une attaque sur wp-login.php

Un 503 qui revient chaque jour à la même heure, sans rapport avec votre trafic réel, ressemble à du bourrage de mots de passe. Des robots tapent wp-login.php ou xmlrpc.php plusieurs fois par seconde. Chaque tentative charge WordPress en entier et remplit votre quota de processus.

Vos journaux d’accès le montrent. Dans cPanel, ouvrez Métriques puis « Accès brut », téléchargez le journal du jour et cherchez les lignes contenant wp-login.php. Des centaines d’occurrences en quelques minutes signent l’attaque.

Installez SecuPress, qui limite les tentatives de connexion et bloque xmlrpc.php en deux réglages. Wordfence et Sucuri Security font le même travail, avec une consommation de ressources plus élevée sur les petits hébergements.

Vérifier que c’est réglé

Trois contrôles, dans cet ordre :

1. Ouvrez le site en navigation privée. La page d’accueil s’affiche.
2. Ouvrez une page interne, une fiche produit ou un article. Le 503 frappe parfois une seule partie du site.
3. Revenez sur l’écran d’utilisation des ressources de votre hébergeur une heure plus tard. Le compteur de dépassements ne bouge plus.

Sans ce troisième contrôle, vous saurez que le site répond. Vous ne saurez pas que la cause a disparu.

Les limites de cette méthode

Cette fiche suppose que vous avez la main sur vos fichiers et sur votre panneau d’hébergement. Trois configurations la mettent en échec.

L’hébergement WordPress managé, chez WP Engine ou Kinsta, bloque l’accès FTP à certains dossiers et gère le mode maintenance à son niveau. Le fichier .maintenance peut exister sans être la cause.

Le multisite change la donne sur la vérification 3. Renommer le dossier plugins coupe le réseau entier, y compris les sites qui fonctionnent.

Un 503 servi par un CDN ou un pare-feu applicatif, Cloudflare compris, ne vient pas de votre serveur. Votre site tourne, la couche intermédiaire refuse de le montrer. Aucune manip décrite ici n’y change quoi que ce soit : il faut passer par le tableau de bord du service concerné.

Quand nous faire intervenir

Faites appel à nous si votre site remplit une de ces conditions :

• une boutique WooCommerce avec des commandes en cours, où couper les extensions coûte des ventes
• aucune sauvegarde de moins d’une semaine
• un thème modifié à la main dans ses fichiers, sans thème enfant
• des 503 qui reviennent alors que vous avez déjà désactivé toutes les extensions

Dans ces cas, chaque manipulation supplémentaire coûte plus cher qu’elle ne rapporte.

Ce que nous prenons en charge : la lecture des journaux serveur, l’identification du processus qui sature, la remise en ligne et le contrôle de charge dans les jours qui suivent. Voir notre service de dépannage WordPress.

Pour aller plus loin

• Mise à jour WordPress ratée : si le 503 est apparu pendant une mise à jour et que le site reste cassé après suppression du fichier .maintenance.
• Page blanche après mise à jour : si le message d’indisponibilité a laissé place à une page vide.
• Erreur 500 WordPress : si le code d’erreur change en cours de diagnostic.

Publié par L’Agence Oueb le 18 août 2026, testé sur WordPress 7.03 et PHP 8.3.