Erreur 504 Gateway Timeout sur WordPress : trouver ce qui bloque le serveur ⏱️

Votre page tourne dans le vide pendant une minute, puis le navigateur affiche « 504 Gateway Time-out », parfois avec la mention « nginx » en dessous, ou une page Cloudflare « 524 A timeout occurred ». Le site n’est pas forcément en panne : il est trop lent pour le délai que lui accorde le serveur, et augmenter ce délai masque le symptôme sans le soigner. Si vous préférez nous confier le diagnostic, notre équipe intervient sur toutes les erreurs WordPress, à distance et partout en France.

Que veut dire « 504 Gateway Timeout » sur un site WordPress ?

L’erreur 504 veut dire qu’un serveur intermédiaire a attendu la réponse de WordPress plus longtemps que prévu et a renoncé. Un serveur web frontal (nginx, ou Apache en proxy) transmet la demande à PHP, le langage de WordPress, et attend la page. Si rien ne revient au bout du délai fixé, il coupe et affiche 504.

Les délais à connaître :

• nginx : les directives fastcgi_read_timeout (PHP-FPM) et proxy_read_timeout (proxy) valent 60 secondes par défaut.
• PHP : max_execution_time vaut 30 secondes par défaut. Au-delà, PHP arrête lui-même le script avec l’erreur « Maximum execution time of 30 seconds exceeded », qui est un autre symptôme du même problème.
• Cloudflare : si votre serveur ne répond pas en 100 secondes, Cloudflare affiche une erreur 524. Une page Cloudflare « 504 » indique plutôt que le serveur d’origine ou un relais a lui-même renvoyé 504.

À ne pas confondre avec la 502 Bad Gateway, où le relais reçoit une réponse invalide ou une coupure nette au lieu d’un silence trop long. Nous avons détaillé ce cas dans notre guide sur l’erreur 502 Bad Gateway sur WordPress, et le décodeur d’erreurs résume la 504 en quelques lignes.

Pourquoi WordPress dépasse-t-il le délai du serveur ?

WordPress dépasse le délai quand une requête lui demande plus de travail que le serveur ne peut en faire en une minute. Voici les causes que nous rencontrons, de la plus fréquente à la plus rare, avec la façon de les reconnaître :

• Une action lourde lancée depuis l’administration : import de produits ou d’articles, export CSV, sauvegarde, régénération des miniatures, mise à jour d’une grosse extension. Signe : seule cette action échoue.
• Une extension qui attend un service extérieur : licence, API de transporteur, flux social. Si le service distant ne répond pas, PHP attend avec lui. Signe : l’erreur commence sans que vous ayez rien modifié.
• Des tâches planifiées qui s’empilent : WP-Cron, le planificateur interne de WordPress, et l’Action Scheduler de WooCommerce exécutent leurs tâches pendant les visites. Signe : lenteurs aléatoires.
• Une base de données encombrée : options chargées automatiquement trop volumineuses, tables de journaux énormes. Signe : même les pages simples sont lentes.
• Un serveur saturé : trop peu de processus PHP, robots agressifs, mutualisé à bout de ressources. Signe : erreurs aux heures de pointe.
• Des délais réglés trop court : plus rare, mais un hébergeur peut fixer max_execution_time ou le délai de nginx bien en dessous des valeurs habituelles.

Comment réparer une erreur 504 sur WordPress, étape par étape ?

On répare une 504 en mesurant d’abord le temps de réponse, puis en trouvant ce qui consomme ce temps avant de toucher à un délai. Avant toute manipulation, faites une sauvegarde complète des fichiers et de la base de données, et notez chaque changement pour pouvoir revenir en arrière.

1. Noter l’action qui déclenche l’erreur et mesurer le temps de réponse

Relevez l’adresse exacte de la page, l’heure, et ce que vous faisiez au moment de l’erreur. Mesurez ensuite le temps de réponse avec curl, un outil en ligne de commande présent sur Mac, Linux et Windows récents :

curl -s -o /dev/null -w "HTTP %{http_code} en %{time_total} s\n" https://www.votresite.fr/page-concernee/

Un résultat autour de 60 secondes confirme un délai nginx atteint, autour de 100 secondes un délai Cloudflare. Si l’accueil répond en moins d’une seconde et qu’une seule page dépasse, le problème est localisé.

2. Lire le journal d’erreurs du serveur

Le journal d’erreurs indique quel serveur a coupé et sur quelle adresse. Il se trouve dans le panneau de l’hébergeur (rubrique « Logs » ou « Journaux »). Sur nginx, une 504 ressemble à ceci :

upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.0.113.10, server: www.votresite.fr, request: "POST /wp-admin/admin-ajax.php HTTP/2.0"

La partie request montre l’adresse qui a traîné. Une adresse /wp-admin/admin-ajax.php ou /wp-json/… désigne presque toujours une extension, /wp-cron.php désigne les tâches planifiées, et une page publique ordinaire oriente vers le thème, le constructeur de pages ou la base de données.

3. Activer le journal de débogage de WordPress

Le mode débogage enregistre les erreurs PHP dans un fichier, sans les afficher aux visiteurs. Ouvrez wp-config.php à la racine du site (par FTP ou par le gestionnaire de fichiers de l’hébergeur) et placez ces lignes au-dessus de « C’est tout, ne touchez pas à ce qui suit » :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduisez l’erreur, puis ouvrez wp-content/debug.log. Cherchez « Maximum execution time », « cURL error 28 » (un appel vers un service extérieur qui a expiré) ou une extension citée de façon répétée dans les chemins wp-content/plugins/…. Repassez ensuite WP_DEBUG à false. Notre article pour voir les erreurs d’un site WordPress détaille cette étape.

4. Repérer l’extension ou la requête lente avec Query Monitor

Query Monitor est une extension gratuite de diagnostic qui affiche, pour chaque page, la durée de génération, les requêtes SQL lentes et les appels HTTP vers l’extérieur. Installez-la depuis sa page officielle, ouvrez la page lente et regardez les panneaux des requêtes par composant, des requêtes lentes et des appels HTTP : un appel de plusieurs secondes ou une extension qui génère la majorité des requêtes désigne le coupable.

Si vous avez un accès SSH, la commande wp profile de WP-CLI (l’outil officiel de gestion de WordPress en ligne de commande) mesure le temps passé à chaque étape du chargement, puis dans chaque crochet (hook) :

wp package install wp-cli/profile-command:@stable
wp profile stage --all --spotlight --url=https://www.votresite.fr/page-concernee/
wp profile hook --all --spotlight --url=https://www.votresite.fr/page-concernee/

La colonne time révèle l’étape anormale, et la sortie de wp profile hook nomme les fonctions, donc l’extension qui les fournit.

5. Désactiver les extensions pour confirmer le coupable

Désactiver toutes les extensions puis les réactiver une à une confirme le diagnostic. Si l’administration ne répond plus, renommez par FTP le dossier wp-content/plugins en plugins-off : WordPress désactive alors toutes les extensions. Avec WP-CLI, la manipulation est réversible en une ligne :

wp plugin list --status=active --field=name > extensions-actives.txt
wp plugin deactivate --all
# test de la page, puis réactivation une par une :
wp plugin activate nom-de-l-extension
# pour tout réactiver :
wp plugin activate $(cat extensions-actives.txt)

Laissez l’extension fautive désactivée le temps de la mettre à jour ou de contacter son éditeur.

6. Vider la file des tâches planifiées (WP-Cron et WooCommerce)

Des tâches planifiées en retard s’exécutent pendant les visites et allongent chaque chargement. Listez-les et lancez celles qui sont dues :

wp cron test
wp cron event list --fields=hook,next_run_relative,recurrence
wp cron event run --due-now

Sur une boutique, ouvrez aussi WooCommerce > État, onglet des actions planifiées (Scheduled Actions), et filtrez les actions en attente et échouées : des milliers d’actions sur le même crochet trahissent une extension en boucle. La commande wp action-scheduler run traite la file depuis le terminal, sans délai web. Pour éviter que WP-Cron ne se déclenche à chaque visite, désactivez-le dans wp-config.php et remplacez-le par une vraie tâche cron du serveur, comme le recommande la documentation WordPress :

// dans wp-config.php
define( 'DISABLE_WP_CRON', true );

# dans la crontab du serveur (toutes les 5 minutes)
*/5 * * * * cd /chemin/vers/le/site && wp cron event run --due-now --quiet

7. Alléger la base de données

Une table wp_options trop chargée ralentit toutes les pages, car WordPress lit à chaque chargement toutes les options marquées en chargement automatique. Depuis WordPress 6.6, Outils > Santé du site signale un problème quand ces options dépassent 800 Ko. Pour voir les plus lourdes, lancez cette requête (remplacez le préfixe wp_ par celui indiqué dans $table_prefix de votre wp-config.php) :

wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024) AS ko FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY LENGTH(option_value) DESC LIMIT 20;"

Une grosse option laissée par une extension supprimée peut être effacée après sauvegarde, avec wp option delete nom_de_l_option. Supprimez aussi les transients expirés (des données temporaires mises en cache par les extensions) avec wp transient delete --expired. Ne supprimez jamais une option dont vous ignorez l’origine.

8. Ajuster les délais, en dernier recours

Augmentez les délais seulement pour une tâche longue et légitime, une fois la cause identifiée. Sur un hébergement mutualisé, créez ou modifiez le fichier .user.ini à la racine du site (la prise en compte peut demander quelques minutes) :

max_execution_time = 120

Sur un serveur nginx que vous administrez, alignez le délai de nginx sur celui de PHP dans le bloc qui transmet à PHP-FPM, puis rechargez nginx :

location ~ \.php$ {
    # ... configuration existante ...
    fastcgi_read_timeout 120s;
}

# vérification et rechargement
sudo nginx -t && sudo systemctl reload nginx

Pour savoir quel script traîne à l’avenir, activez aussi le journal des scripts lents de PHP-FPM dans le fichier du pool (souvent www.conf), qui enregistre la pile d’appels de tout script dépassant le seuil :

request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log

Comment éviter que l’erreur 504 revienne ?

On évite le retour de la 504 en surveillant le temps de réponse et en gardant les tâches lourdes hors des pages vues par les visiteurs.

• Remplacez WP-Cron par une tâche cron du serveur, comme à l’étape 6.
• Contrôlez chaque mois Outils > Santé du site et la file des actions programmées de WooCommerce.
• Mettez un cache de pages en place pour que les visiteurs ne sollicitent pas PHP à chaque page.
• Gardez extensions et thème à jour, et supprimez celles qui ne servent plus : c’est le cœur d’une bonne maintenance WordPress.
• Si le site entier rame, lisez aussi nos conseils sur l’administration WordPress lente et, pour une boutique, sur WooCommerce lent.

Quand faut-il faire appel à un professionnel ?

Faites appel à un professionnel quand la 504 touche tout le site, que vous n’avez accès ni aux journaux ni à SSH, ou que la cause pointe vers la configuration du serveur. Un site à l’arrêt peut être pris en charge en dépannage WordPress urgent. Nous travaillons à distance, du lundi au vendredi, à 70 € TTC de l’heure (dès 35 € TTC la demi-heure), avec un audit gratuit et la garantie satisfait ou remboursé : le détail est sur notre page de tarification. Pour d’autres pannes, notre page Résoudre une panne rassemble tous nos guides.