A 504 Gateway Timeout means the browser asked for a page and the server did not answer in time. On WordPress that almost always means the hosting has run out of resources. If the site runs through Cloudflare, the same problem shows up as a 524 error. The cause is usually on a short list, and this is the order we work through it.

Table of Contents

Why WordPress runs out of PHP workers

WordPress runs on PHP, and your hosting gives the site a fixed number of PHP workers: processes that each build one page at a time. Each worker can only use one CPU core, so 10 workers on five cores is two workers per core. Around 10 to 20 workers on five cores is a sensible range. Go much beyond two or three workers per core and you start running into memory errors instead.

A cached page costs almost nothing to serve. An uncached page ties up a worker while PHP and the database build it. When every worker is busy, new requests queue, and when they wait too long the visitor gets a 504.

What usually causes it

Aggressive crawlers. Pinterest is a genuine crawler that can be too aggressive, and SEO tools such as Semrush and Ahrefs can hammer a site. Crawlers requesting URLs with query strings are worse, because those URLs are usually not cached. On WooCommerce, bots adding and removing cart items can tie up every worker.
Brute force attacks. A typical WordPress site sees thousands of login attempts a day, often in short bursts, and each one is handled by PHP.
A plugin or database using excessive resources, through an error or a bloated database.
Genuine high traffic.
No page caching, or caching that has quietly stopped working. This is one of the most common causes.
Lots of 404 errors. If the theme references a missing file on every page, each 404 is often generated by PHP.
A PHP timeout set far too high, so stuck workers run for minutes instead of being stopped.

Step 1: Confirm page caching is working

Start here because it is quick. We use and recommend WP Rocket, and almost every caching plugin writes rules into the site’s .htaccess file when it is active (on Apache and LiteSpeed servers). Open .htaccess: if all you see is the default WordPress block, the caching rules are missing.

If the plugin is not enabled, enable it. If it is enabled but the rules are gone, open its settings and click save to rewrite them, or deactivate and reactivate it. Reload .htaccess and the plugin’s block should now be there.

Step 2: Read the server logs

Logs usually sit in a logs folder in your hosting account, split into access logs, error logs and often a separate PHP error log. Names vary by host, and servers that run both Apache and Nginx keep two sets of access logs. Large logs are easier to download and open in a text editor.

In the access log, scan the timestamps and user agents for patterns:

one bot making several requests per second,
aggressive crawlers such as PetalBot, or SEO tool bots from Semrush, Ahrefs, Moz and DotBot,
requests for URLs that do not exist, strange query strings, or repeated add-to-cart and remove-from-cart requests,
repeated hits on the login page.

Googlebot and your uptime monitor will appear too. That is normal.

Step 3: Block or filter the traffic in Cloudflare

Once you know what is hitting the site, Cloudflare is where we usually stop it, before it ever reaches the server.

SEO crawlers: a custom rule blocking the Semrush, Ahrefs, Moz and DotBot user agents.
Brute force: a rule that challenges requests for wp-login from outside your home country. For an Australian site, anyone outside Australia trying to reach the login page gets a challenge first.
Traffic outside your target market: a rule that challenges visitors from outside your main countries, with exceptions for known bots, the path used for SSL certificate validation and uptime monitor user agents.

Filter (challenge) countries rather than blocking them outright. Some genuine visitors will always come from overseas, and blocking legitimate bots such as Googlebot will damage your SEO.

Step 4: Tighten the rest

robots.txt: a WooCommerce robots.txt that disallows add-to-cart and other query string URLs stops well-behaved crawlers wasting workers on them.
Wordfence: we recommend the free version. It filters WordPress-specific attacks and odd traffic patterns, and the load it removes more than offsets the small load it adds.
404 errors: run a site crawler or SEO audit tool, find the broken references and fix them at the source.
Cache what should be cached: if heavily used filter or search URLs are generated fresh every time, add those query strings to your caching plugin.

Step 5: Find the plugin or setting responsible

If the traffic looks normal, the problem is inside the site. Turn on WordPress debug logging by adding these lines to wp-config.php:

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

Errors are then written to wp-content/debug.log without being shown on the page. Alongside that, install the free Query Monitor plugin. It adds a toolbar item showing PHP errors, warnings and page generation time. Lots of warnings, or a very high generation time, point to the plugin causing the load.

Then check the PHP settings max_execution_time and max_input_time. We often find them at 300 seconds, and occasionally at 3,000. At that level a runaway worker keeps going, then another, until none are left. We set them to 30 or 60 seconds, 120 at most, so the host stops a stuck worker and starts a fresh one. Large imports may need a higher limit temporarily.

Step 6: Check how Google is crawling

In Google Search Console, open Settings, then Crawl stats, to see what Google requests and which responses it gets. A few dozen 404s is nothing; thousands is worth fixing. The Pages report can also reveal Google crawling URLs it should not, such as odd parameter variations. Block those in robots.txt.

Step 7: Put a CDN in front

Cloudflare with its APO service moves much of the work off the hosting and onto Cloudflare’s network, leaving the server to handle only what it has to. On a site that keeps hitting its worker limit, APO can reduce the load dramatically.

If 504s keep coming back and you would rather we found the cause, request a free site audit from the WP Speed Fix homepage or run the free Core Web Vitals report.