Erreur 504 Gateway Timeout sur WordPress : comment corriger

504 Gateway Timeout : le serveur a mis trop de temps à répondre

« 504 Gateway Timeout ». Le message est sec, mais son sens est précis : un serveur en attendait un autre, et la réponse n’est jamais arrivée à temps. Contrairement à une page blanche mystérieuse, cette erreur vous dit quelque chose d’utile — quelque part, une opération est trop lente.

Quand vous chargez WordPress, un serveur frontal (Nginx, ou un proxy comme Cloudflare) transmet la requête à PHP, qui interroge la base de données, exécute vos plugins, assemble la page, puis renvoie le tout. Si cette chaîne dépasse le délai maximum autorisé, le frontal cesse d’attendre et renvoie une 504. Le site n’est pas « cassé » au sens d’une erreur 500 : il est simplement trop lent pour répondre dans les temps.

La bonne nouvelle : une 504 est presque toujours un problème de performance, donc traitable. La différence avec une erreur 502 est subtile mais utile — une 502 vient d’une réponse invalide ou d’un service tombé, une 504 vient d’une réponse qui arrive trop tard.

Pourquoi ça arrive : ce qui ralentit la réponse

• Une requête base de données lente — une table lourde, un plugin mal optimisé, une recherche sur des dizaines de milliers de lignes sans index.
• Un script long qui dépasse max_execution_time — import/export volumineux, migration, régénération de miniatures, sauvegarde.
• Un appel à une API externe qui ne répond pas — un plugin attend une réponse d’un service tiers, celui-ci traîne, tout le chargement est bloqué.
• Un hébergement mutualisé saturé — aux heures de pointe, les ressources partagées ne suffisent plus, chaque requête rame.
• Le cron WordPress qui s’empile — des tâches planifiées qui s’accumulent et s’exécutent toutes en même temps sur une visite.

1. Rechargez et vérifiez si c’est ponctuel

Un pic de charge temporaire peut suffire à déclencher une 504. Attendez une minute, rechargez avec le cache vidé (Ctrl+Shift+R), et voyez si l’erreur revient.

Testez plusieurs pages : si seule une page précise déclenche la 504 (le panier, une page de recherche, un export dans l’admin), vous tenez déjà le coupable — c’est cette opération-là qui est trop lente, pas le site entier. Notez laquelle : ça oriente tout le diagnostic.

2. Identifiez l’opération lente

Une 504 ciblée sur une action précise est un cadeau : elle vous montre où chercher.

• Sur une page publique lente → un plugin chargé sur ce type de page fait une requête coûteuse. Désactivez les plugins un par un (via FTP en renommant les dossiers dans wp-content/plugins/) et rechargez à chaque fois.
• Dans l’admin, sur un import/export/sauvegarde → l’opération dépasse simplement le temps alloué. Ce n’est pas un bug, c’est une limite. Passez à l’étape 3 pour l’augmenter, ou fractionnez l’opération (importez par lots plus petits).
• Au chargement de n’importe quelle page → c’est global : base de données, hébergement ou cron. Voir étapes 4 et 5.

Si votre site est lent partout et pas seulement en 504, le guide site WordPress lent détaille le diagnostic de performance complet.

3. Augmentez les timeouts et les directives PHP

Pour les opérations légitimement longues (un gros import, une sauvegarde), la solution est d’accorder plus de temps. Mais attention : ces réglages doivent être cohérents entre PHP et le serveur frontal, sinon vous ne faites que déplacer le point de rupture.

Où régler quoi :

• max_execution_time, max_input_time, memory_limit → dans php.ini, ou via le sélecteur de version PHP du panel hébergeur.
• fastcgi_read_timeout → dans la configuration Nginx du site.
• proxy_read_timeout → côté Cloudflare, la limite du plan gratuit est fixe (100 s) : au-delà, il faut passer l’opération en tâche de fond plutôt qu’espérer allonger le timeout.

Pour le détail de chaque directive et les quatre endroits où les modifier proprement, voir le guide directives PHP WordPress.

4. Traquez la requête base de données coupable

Si la lenteur est globale, la base de données est souvent en cause. Installez un plugin de profilage (Query Monitor) sur un environnement de test : il affiche, pour chaque page, les requêtes SQL les plus lentes et le plugin qui les déclenche.

Les coupables classiques : une table wp_options gonflée par des données autoload inutiles, une table wp_postmeta sans index sur un gros site, ou un plugin qui recharge tout le catalogue à chaque visite. Une fois le coupable identifié, deux options : optimiser (nettoyer les données, ajouter un index) ou remplacer le plugin par une alternative plus légère.

5. Maîtrisez le cron WordPress

Par défaut, WordPress déclenche ses tâches planifiées (wp-cron) à chaque visite. Sur un site à faible trafic, ça passe ; sur un site chargé, ou avec beaucoup de tâches, elles s’empilent et une visite malchanceuse hérite de toute la file — 504.

La solution propre : désactiver le cron « à la visite » et le déclencher via une vraie tâche planifiée serveur. Dans wp-config.php :

define('DISABLE_WP_CRON', true);

Puis créez une tâche cron côté hébergeur qui appelle wp-cron.php toutes les 5 à 15 minutes. Le traitement des tâches est ainsi découplé de l’expérience des visiteurs. Notez que si vos 504 s’accompagnent d’erreurs 429 Too Many Requests, le cron mal réglé peut être la cause commune.

6. Mettez en place du cache

Si le serveur recalcule chaque page à chaque visite, vous multipliez les occasions de 504. Un cache de pages (statique) sert une version pré-générée en quelques millisecondes, sans solliciter PHP ni la base.

Activez un plugin de cache (WP Super Cache, W3 Total Cache, ou le cache intégré de votre hébergeur), et, si possible, un cache objet (Redis) pour les requêtes base répétées. C’est le levier au meilleur rapport effort/gain contre les 504 dues à la charge.

Tableau récapitulatif : cause → solution

Quand passer la main à un pro

Une 504 récurrente après avoir réglé les timeouts, ajouté du cache et vérifié le cron indique un problème de fond : base mal structurée, plugins trop lourds, ou hébergement inadapté à votre trafic. Optimiser durablement demande de profiler, de réécrire ou remplacer les points chauds, et parfois de repenser l’architecture — un travail qu’un prestataire mène en quelques heures là où l’essai-erreur en prend des dizaines. Pour poser vous-même les bases d’un site rapide, le guide complet d’optimisation WordPress rassemble les leviers durables. Une 504, ce n’est pas une fatalité — c’est un site qu’on n’a pas encore mis au bon régime.