Fix: Server errors (5xx) — 500, 502, 503, 504

The Server errors (5xx) issue lists pages that failed during the crawl. It is marked as an error because Google slows down crawling, and can drop pages from its index, when a site keeps returning 5xx errors.

Find the affected pages in the app

1. Open Site crawl, pick the client and open the latest crawl.
2. Go to the Issues tab and click Server errors (5xx). It lists the affected URLs (the first 20).
3. Go to the Pages tab and click the 5xx chip to see all of them with their exact status code.
4. Pages shown as No response are in this issue too: fix those with Fix: No response — timeouts, DNS, SSL/TLS and connection errors.
5. Use Export to download the full list.

Tip: if every page fails, it’s a site-wide problem (server down, firewall or maintenance mode). If only some pages fail (cart, search, account, heavy pages), it’s a slow-page or plugin problem on those templates.

500 Internal Server Error

How we detect it

The page returned status 500. The crawl lists it under Server errors (5xx); audits show The page returned HTTP 500. (GEO and Local) or fail.

Why it matters

A 500 page shows visitors an error instead of content, and Google drops pages that keep returning 500.

Common causes

• If WordPress shows “There has been a critical error on this website” → a PHP fatal error in a plugin or theme.
• If the error log says Allowed memory size of 134217728 bytes exhausted → PHP ran out of memory.
• If the error log says Maximum execution time of 30 seconds exceeded → the page takes too long to build.
• If every page fails right after an .htaccess change → a syntax error in .htaccess.
• If it started after a PHP version change → a plugin or theme isn’t compatible with that PHP version.
• If the log says Permission denied → wrong file permissions (files should be 644, folders 755).

Fix: basic

Check the WordPress recovery email

1. WordPress emails the admin address “Your Site is Experiencing a Technical Issue” with the plugin or theme name and a recovery-mode link.
2. Open the link, sign in, and deactivate or update the plugin named in the email.

Deactivate plugins without admin access

1. In the hosting panel open File Manager (cPanel: Files › File Manager; Plesk: Websites & Domains › File Manager; hPanel: Websites › Manage › Files › File Manager).
2. Go to wp-content/ and rename the plugins folder to plugins-off.
3. Open the site. If it works, rename the folder back to plugins.
4. Then rename single plugin folders inside it one by one (for example elementor to elementor-off) until the error stops. That plugin is the cause: update it, replace it or contact its author with the error line.

Raise the PHP memory limit

1. cPanel: Software › MultiPHP INI Editor, choose the domain, set memory_limit to 256M, click Apply.
2. Plesk: Websites & Domains › (domain) › PHP Settings, set memory_limit to 256M, click OK.
3. hPanel: Websites › Manage › Advanced › PHP Configuration › PHP options, set memoryLimit to 256M, click Save.

Fix: expert

Turn on the WordPress debug log. Add above the line /* That's all, stop editing! */ in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_MEMORY_LIMIT', '256M' );

Open the failing URL, then read the log:

tail -n 50 wp-content/debug.log | grep -E "Fatal|memory|Maximum execution"

Set WP_DEBUG back to false when you’re done.

With WP-CLI over SSH:

wp plugin deactivate --all          # test with all plugins off
wp plugin activate woocommerce      # turn them back on one by one
wp theme activate twentytwentyfive  # test with a default theme

PHP limits in php.ini or .user.ini (in the site root):

memory_limit = 256M
max_execution_time = 120
max_input_vars = 3000

Check .htaccess for errors on Apache:

apachectl configtest
tail -n 30 /var/log/apache2/error.log   # or /usr/local/apache/logs/error_log on cPanel

If .htaccess is broken, rename it to .htaccess-old and, in WordPress, re-save Settings › Permalinks to write a clean one:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Platform steps

WordPress

Tools › Site Health › Info › Server shows the PHP version and memory limit in use.

cPanel

Metrics › Errors shows the last web server errors for the account.

Plesk

Websites & Domains › (domain) › Logs (filter by Error).

Verify the fix

Open each URL from the issue: status 200. Then, in Site crawl, click Crawl again and use Compare: Server errors (5xx) moves to fixed issues.

Automation

Assisted: needs hosting panel or server SSH (logs, PHP settings) plus WordPress admin.

502 Bad Gateway

How we detect it

The page returned status 502. It often appears on several pages in a row during the crawl.

Why it matters

A 502 means the web server got no valid answer from PHP or the app behind it, so visitors see an error page.

Common causes

• If the PHP-FPM log says server reached pm.max_children setting → all PHP workers were busy; extra requests failed.
• If PHP-FPM keeps restarting or is stopped → a crash or out-of-memory kill (dmesg | grep -i oom).
• If the nginx log says upstream sent too big header → large cookies or headers (common with some plugins) overflow the buffers.
• If Cloudflare shows 502, or 520–526 → the origin server failed: 520 unknown error, 521 server down, 522 connection timed out, 523 origin unreachable, 524 timeout over 100 seconds, 525 SSL handshake failed, 526 invalid origin certificate.

Fix: basic

1. In the hosting panel, restart PHP (Plesk: PHP Settings, change nothing and click OK to reload; hPanel and cPanel: changing the PHP version and back restarts it).
2. Turn on page caching so fewer requests need PHP (WordPress: LiteSpeed Cache, WP Rocket or W3 Total Cache).
3. On shared hosting, check the resource usage page (cPanel: Metrics › Resource Usage). If you hit limits, upgrade the hosting plan or reduce heavy plugins.
4. Click Crawl again in Site crawl.

Fix: expert

Raise PHP-FPM workers (for example /etc/php/8.3/fpm/pool.d/www.conf). Rule of thumb: pm.max_children = RAM for PHP ÷ average PHP process size (often 60–100 MB).

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500

grep -i "max_children" /var/log/php8.3-fpm.log | tail -n 5
systemctl restart php8.3-fpm

Fix “upstream sent too big header” in nginx:

# PHP via FastCGI
fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;

# Reverse proxy to an app server (Node, Python, another server)
proxy_buffer_size 32k;
proxy_buffers 16 16k;
proxy_busy_buffers_size 64k;

Platform steps

Cloudflare

For 521/522, make sure the origin server is up and that its firewall allows Cloudflare’s IP ranges. For 525/526, fix the origin certificate or, in the Cloudflare dashboard › your site, set SSL/TLS › Overview to match it (SSL/TLS modes).

Plesk

Websites & Domains › (domain) › PHP Settings › Performance settings: raise pm.max_children.

Verify the fix

The PHP-FPM log has no new max_children warnings during Crawl again, and the Pages tab has no 502 rows.

Automation

Assisted: needs server SSH (root) or Plesk admin to change PHP-FPM settings.

503 Service Unavailable

How we detect it

The page returned status 503, sometimes with “Briefly unavailable for scheduled maintenance. Check back in a minute.” or a host’s “Resource Limit Is Reached” page (that one is sometimes 508).

Why it matters

A 503 tells Google the site is temporarily down. Short outages are fine; a 503 that lasts days leads to pages dropping from the index.

Common causes

• If the page says “Briefly unavailable for scheduled maintenance” → a WordPress update failed and left the .maintenance file.
• If a maintenance or launch-page plugin is active → it serves 503 to everyone not signed in.
• If the page says “Resource Limit Is Reached” → CloudLinux LVE limits on shared hosting (CPU, entry processes).
• If it comes with server: cloudflare and a challenge → it’s a bot challenge, not a real outage: see the Cloudflare guide.
• If Wordfence is installed and pages fail after a few requests → Wordfence rate limiting returns 503 (Wordfence rate limiting docs): see the WordPress plugin guide.

Fix: basic

Stuck maintenance mode

1. Open File Manager in the hosting panel.
2. In the site root (public_html or httpdocs), find the file .maintenance (turn on Show Hidden Files).
3. Delete it.
4. Re-run the update that failed in Dashboard › Updates.

Maintenance plugin

1. Go to Plugins in WordPress.
2. Turn off maintenance mode in the plugin’s settings (for example SeedProd, WP Maintenance Mode or LightStart) or deactivate the plugin.

Resource limits

1. cPanel: open Metrics › Resource Usage and look for faults at the crawl time.
2. Turn on page caching and remove heavy plugins, or move to a hosting plan with higher limits.

Fix: expert

ls -la .maintenance && rm .maintenance
wp maintenance-mode status
wp maintenance-mode deactivate

Platform steps

WordPress

Tools › Site Health lists failed updates and critical issues.

Verify the fix

The home page and the URLs from the issue return 200. Crawl again in Site crawl shows no 503 rows.

Automation

Automatable for a stuck .maintenance file (needs file access or WP-CLI over SSH); assisted for resource limits.

504 Gateway Timeout

How we detect it

The page returned status 504 (Cloudflare shows its own 524 for timeouts over 100 seconds). It usually affects slow pages: search, filters, large category pages, reports.

Why it matters

If a page takes longer than the server’s timeout to build, nobody can see it, including Google.

Common causes

• If nginx’s error log says upstream timed out (110: Connection timed out) while reading response header → PHP or the app took longer than fastcgi_read_timeout / proxy_read_timeout (60 seconds by default).
• If PHP’s log says Maximum execution time exceeded → the PHP limit is hit first.
• If Query Monitor shows slow database queries → missing indexes or a heavy plugin.
• If a page calls an external API (shipping, reviews, maps) → the external service is slow.

Fix: basic

1. Install Query Monitor (WordPress), open the slow page while signed in, and check Queries by Component and HTTP API Calls for the slowest plugin.
2. Update, replace or reconfigure that plugin.
3. Turn on page caching and object caching (Redis or Memcached if the host offers it: hPanel Websites › Manage › Advanced › Object Cache; cPanel varies by host).
4. Raise max_execution_time to 120 in the PHP settings (paths in the 500 section).
5. Click Crawl again in Site crawl.

Fix: expert

nginx with PHP-FPM:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_read_timeout 120s;
    fastcgi_send_timeout 120s;
}

nginx as a reverse proxy:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 10s;
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;
}

Apache:

Timeout 120
ProxyTimeout 120

PHP-FPM pool (must be at least as long as the nginx timeout):

request_terminate_timeout = 120s

Find slow MySQL queries:

# /etc/mysql/conf.d/slow.cnf
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

Raising timeouts only hides slowness. Our crawler waits 25 seconds for data, so a page that needs 60 seconds will still show No response for us: make the page faster with caching and query fixes.

Platform steps

Plesk

Websites & Domains › (domain) › Apache & nginx Settings › Additional nginx directives: add fastcgi_read_timeout 120s; and proxy_read_timeout 120s;.

Cloudflare

In the Cloudflare dashboard you can’t change this: Cloudflare waits 100 seconds for the origin on most plans (524 error after that). Fix the origin speed; the limit can’t be raised on non-Enterprise plans.

Verify the fix

curl -sS -o /dev/null -w "%{http_code} first byte %{time_starttransfer}s\n" https://example.com/slow-page/

Status 200 with a first byte under 5 seconds. Then Crawl again in Site crawl. For more speed fixes see Fix: Page speed › Time to First Byte.

Automation

Assisted: needs server SSH or Plesk admin for timeouts; WordPress admin for plugin changes.

Common questions

Related articles

• Fix: Site can't be crawled (server errors, blocks and timeouts)
• Fix: No response — timeouts, DNS, SSL/TLS and connection errors
• Fix: 403 and 429 from the server, host firewall or ModSecurity (nginx, Apache, cPanel, Plesk, hPanel)
• Fix: WordPress security plugins block the crawl (Wordfence, Solid Security, Sucuri, LiteSpeed)
• Fix: page speed — slow pages, TTFB, page size, requests, compression and caching
• Crawl a whole website

Still need help?

Ask in the chat inside the app, or send us a message on the contact page. You can also browse all help topics.