Seeing a 500 internal server error wordpress can feel overwhelming. Take a breath. Almost every case has a clear cause and a safe fix. This calm, practical guide walks you through the 50 most common reasons step by step.
You will learn what triggers the problem, how to spot it, which logs to check, and exactly how to solve it without making things worse. The steps work on Apache, Nginx, LiteSpeed and plain Linux servers. Keywords such as http error 500 wordpress, server error 500 wordpress elementor, error 500 wordpress and wordpress error 500 appear naturally where they help.
eCommerce and WooCommerce sites feel downtime the most. The same is true for busy Elementor pages. Move slowly, keep backups, and you will restore your site safely.
1. Corrupted .htaccess file
A single invalid line in the .htaccess file can stop Apache or LiteSpeed from working. Plugins or manual edits often insert bad rewrite rules. This remains one of the most frequent causes of a 500 internal server error wordpress.
Symptoms: The whole site returns a 500 error. The admin area also fails. The problem often appears right after changing permalinks or installing a new plugin.
How to confirm: Rename the file via FTP or File Manager. If the site loads, the file was the cause. Check the Apache error log for messages such as “Invalid command” or “RewriteEngine not allowed”.
Safe fix: Rename it to .htaccess_old. Then visit Settings → Permalinks and click Save Changes. WordPress will create a clean file. Always keep a backup of the original.
Verify: Both the front-end and admin load without error. Precaution: Never delete the file until you are sure the new one works.
2. Plugin conflict
One poorly coded or outdated plugin can throw a fatal PHP error that the server turns into a 500. Heavy plugins such as page builders or security tools are common sources.
Symptoms: The error starts immediately after activating or updating a plugin. The site works again when all plugins are disabled.
How to confirm: Rename the plugins folder to plugins_disabled via FTP. Reload the site. If it recovers, reactivate plugins one by one until the error returns.
Safe fix: Remove or replace the faulty plugin. Update the remaining ones. Clear every cache afterward.
Logs to watch: wp-content/debug.log and the server error log. Look for a “Fatal error” that includes a plugin path. Verify by confirming the site stays stable after the good plugins are active again.
3. Theme conflict
Broken code inside a theme’s functions.php or template files can crash PHP. Custom or neglected themes cause this regularly.
Symptoms: The error appears after switching themes or updating the current one. The front-end fails while the admin area may still respond.
How to confirm: Rename the active theme folder inside wp-content/themes. WordPress falls back to a default theme. Test the site.
Safe fix: Activate a default theme such as Twenty Twenty-Four. Contact the theme developer or replace the theme. Always make custom changes in a child theme.
Verify: The site loads cleanly with the default theme. Precaution: Never edit parent theme files directly.
4. PHP fatal error
A syntax mistake, missing function or undefined class stops PHP. WordPress hides the detailed message and the server simply returns a 500.
Symptoms: A white screen or 500 appears after any code change. Turning on debugging reveals the real error.
How to confirm: Add the following lines to wp-config.php:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
Then open wp-content/debug.log. Look for “Fatal error” or “Parse error”. Official guidance is available in the WordPress debugging documentation.
Safe fix: Correct the code or disable the responsible plugin or theme. Use only a plain-text editor. Verify by clearing the log and confirming no new fatal messages appear.
5. Incompatible PHP version
Code written for older PHP versions can break on PHP 8.0 and newer. Deprecated functions become fatal errors overnight.
Symptoms: The error begins right after a PHP version change. The site worked on the previous version.
How to confirm: Create a temporary file containing <?php phpinfo(); ?> or run php -v on the server.
Safe fix: Switch back to a compatible version in the hosting panel or ask your host. Then update all plugins and themes so they support the newer PHP.
Verify: The site loads on the chosen PHP version. Precaution: Always test major PHP upgrades on a staging site first.
6. PHP memory limit exceeded
A script tries to use more memory than the server allows. PHP stops and the server returns a 500. This happens often with WooCommerce and page builders.
Symptoms: The error appears on heavy pages or during imports. The log shows “Allowed memory size of … exhausted”.
How to confirm: Add these lines to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Also check the memory_limit value in php.ini. Safe fix: Raise the limit, then restart PHP-FPM if needed. Long-term, optimize the heavy plugin. Verify that the memory message disappears from the logs and the same action succeeds.
7. Low PHP execution limits
When max_execution_time or max_input_time is too low, long-running scripts time out and produce a 500.
Symptoms: The error occurs during imports, backups or large product updates. The log shows “Maximum execution time exceeded”.
How to confirm: Check php.ini or a phpinfo page. Common defaults are 30 or 60 seconds.
Safe fix: Raise both values to 300. Restart PHP-FPM or Apache. Verify that the long process now completes and no timeout messages remain. Precaution: Avoid unlimited values on shared hosting.
8. Incorrect file permissions
Files set to 777 or folders set to 644 prevent the web server from reading or writing correctly and trigger a 500.
Symptoms: The site fails after moving files or restoring a backup. Permissions look wrong in FTP.
How to confirm: Files should be 644 and folders 755. Use ls -la on Linux or check inside the File Manager.
Safe fix from the WordPress root:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
Verify that the site loads and can write to the uploads folder. Precaution: Never use 777 on a live server.
9. Incorrect file ownership
Files owned by the wrong user (often root instead of www-data or nginx) block the web server even when the permission numbers look correct.
Symptoms: “Permission denied” messages appear in the logs.
How to confirm: Run ls -la. The owner should match the PHP-FPM or Apache user.
Safe fix (adjust user and path as needed):
chown -R www-data:www-data /var/www/html
Verify that permission-denied lines stop appearing and the site functions normally. Precaution: Run chown only inside the site directory.
10. Corrupted WordPress core files
Core files inside wp-admin or wp-includes can become damaged during uploads or attacks.
Symptoms: The admin area shows a 500 while the front-end may still work. Random core functions fail.
How to confirm: Compare file sizes or checksums with a fresh WordPress download.
Safe fix: Download the latest WordPress package. Replace only the wp-admin and wp-includes folders. Leave wp-content and wp-config.php untouched. Verify that both admin and front-end load. Precaution: Always back up before replacing files.
11. Failed WordPress update
An interrupted update leaves core files half-written and the site unstable.
Symptoms: The error appears right after clicking “Update WordPress”. Some admin pages work, others fail.
How to confirm: Look for an incomplete set of files or a lingering .maintenance file in the root.
Safe fix: Delete the .maintenance file if present. Re-upload fresh core files or use WP-CLI: wp core download –force. Verify that the update screen shows the current version and no 500 remains. Precaution: Update during low-traffic periods and keep a recent backup.
12. Server configuration errors
Wrong directives in the main server configuration (nginx.conf, httpd.conf or LiteSpeed) can break every site on the server.
Symptoms: Every site returns a 500. The problem starts after a configuration change.
How to confirm: Run nginx -t or apachectl configtest. Read the output carefully.
Safe fix: Correct the syntax error or restore the previous working configuration. Reload the service. The main error log will show the exact line number. Verify with a successful config test and a normal site load.
13. PHP-FPM problems
The PHP-FPM pool may crash, run out of workers, or point to the wrong socket. Nginx or LiteSpeed then cannot reach PHP and returns a 500.
Symptoms: 500 or 502 errors. The Nginx log shows “connect() to unix:… failed”.
How to confirm: Run systemctl status php8.2-fpm (adjust the version). Check /var/log/php*-fpm.log. Confirm the socket path matches the web-server configuration.
Safe fix: Restart the pool. Increase pm.max_children if needed. Correct the listen path. Verify that the service status is active and the site processes PHP pages. Precaution: Change only one setting at a time.
14. Nginx configuration errors
A missing try_files directive, incorrect fastcgi_pass, or rewrite loop easily produces a 500 on Nginx.
Symptoms: The error appears only on Nginx servers. Apache sites on the same host continue to work.
How to confirm: Run nginx -t. Examine the server block. Ensure it contains:
location / {
try_files $uri $uri/ /index.php?$args;
}
Safe fix: Correct the location blocks and reload with nginx -s reload. Full reference material is available in the official Nginx documentation. After the fix you may also want to review our guide on optimizing performance with Nginx.
Verify: The configuration test passes and the site loads normally.
15. Apache configuration errors
Missing modules, incorrect AllowOverride settings, or syntax errors in VirtualHost blocks break Apache.
Symptoms: The error begins after editing httpd.conf or a virtual-host file. Other servers remain fine.
How to confirm: Run apachectl configtest. Enable mod_rewrite if needed and confirm AllowOverride All for the site directory.
Safe fix: Correct the directive and restart Apache. Verify that the config test succeeds and the site responds with a normal 200 status. Precaution: Test changes on a spare virtual host first.
16. MySQL/MariaDB server is down
When the database service has stopped, WordPress cannot connect and many hosts simply return a 500.
Symptoms: An “Error establishing a database connection” message may appear, but often the server shows only a 500.
How to confirm: Run systemctl status mysql or systemctl status mariadb. Try mysqladmin ping.
Safe fix: Start the service with systemctl start mysql. Investigate why it stopped (disk full or crash). Enable it to start on boot. Check /var/log/mysql/error.log for the reason. Verify that the status shows active and WordPress loads.
17. MySQL/MariaDB connection problems
A wrong host, port or socket path prevents WordPress from reaching the database.
Symptoms: Intermittent or constant 500 errors. The debug log shows connection refused or timeout.
How to confirm: Review DB_HOST in wp-config.php. Test manually with mysql -h hostname -u user -p.
Safe fix: Correct the host value (localhost, 127.0.0.1 or the proper socket). Restart the database if necessary. Verify that a manual connection succeeds and the site loads. Precaution: Never expose the database port to the public internet.
18. Too many MySQL connections
When the max_connections limit is reached, new requests fail and appear as 500 errors.
Symptoms: The error occurs under traffic spikes. The log shows “Too many connections”.
How to confirm: Run SHOW VARIABLES LIKE ‘max_connections’; and SHOW STATUS LIKE ‘Threads_connected’;.
Safe fix: Raise max_connections carefully and optimize slow queries. Verify that Threads_connected stays below the new limit and the site handles traffic. Precaution: Monitor the value after the change.
19. Corrupted database tables
Tables can become corrupted after crashes or disk problems. Queries then fail with a 500.
Symptoms: Specific pages or admin sections fail. The log shows “Table is marked as crashed”.
How to confirm: In phpMyAdmin or with WP-CLI run CHECK TABLE table_name; or wp db check.
Safe fix: Run REPAIR TABLE table_name; or wp db repair. Always back up first. Verify that the check returns OK and the affected pages load. Precaution: Never repair without a recent backup.
20. Database user permission problems
The database user may lack SELECT, INSERT or other necessary rights. Queries fail and the server returns a 500.
Symptoms: Some operations work while others return a 500. The error log may show “Access denied”.
How to confirm: Log in as the WordPress user and run SHOW GRANTS;.
Safe fix: Grant the required privileges and flush them. Verify that every admin and front-end action succeeds. Precaution: Grant only the privileges that are actually needed.
21. Incorrect database credentials
Wrong values for DB_NAME, DB_USER, DB_PASSWORD or DB_HOST in wp-config.php prevent any connection.
Symptoms: An immediate 500 or database-connection error appears after a migration or password change.
How to confirm: Open wp-config.php and compare the four constants with the real details in the hosting panel.
Safe fix: Correct the values and save the file. No service restart is required. Verify that the site loads and can create a new post. Precaution: Keep a working backup of wp-config.php.
22. MySQL/MariaDB server overload
High load or too many slow queries make the database unresponsive and produce intermittent 500 errors.
Symptoms: The error appears under load. Server load is high even when CPU still has capacity.
How to confirm: Check uptime, run SHOW FULL PROCESSLIST;, and inspect the slow-query log.
Safe fix: Kill clearly stuck queries, add indexes, or raise resources. Verify that the process list stays short and the site responds quickly. Precaution: Never kill a query without understanding its purpose.
23. Expensive or inefficient database queries
A plugin or theme may run unoptimized queries that lock tables or exhaust resources.
Symptoms: Specific pages always time out with a 500. The slow-query log fills with the same statement.
How to confirm: Enable the slow-query log and use a tool such as Query Monitor on a staging site.
Safe fix: Optimize the query or replace the plugin. Add proper indexes. Verify that page-load time drops and no new 500s appear. Precaution: Test every query change on staging first.
24. Database disk space problems
When the partition that holds MySQL data becomes full, new writes fail and the site returns a 500.
Symptoms: A sudden 500. Database logs show “No space left on device”.
How to confirm: Run df -h and locate the partition containing /var/lib/mysql.
Safe fix: Free space by removing old binary logs, general logs or unused databases, then restart MySQL. Verify that disk usage drops below 90 % and the site works. Precaution: Set up disk-space monitoring alerts.
25. InnoDB corruption or errors
InnoDB tables or the redo log can become corrupted after an unclean shutdown.
Symptoms: The error log shows “InnoDB: Database page corruption” or similar messages. Certain tables fail.
How to confirm: Inspect /var/log/mysql/error.log for InnoDB messages.
Safe fix: Follow the official recovery procedure carefully (starting with innodb_force_recovery). Restore from backup whenever possible. Verify that no further InnoDB errors appear and the tables open cleanly. Precaution: This is advanced work — always take a full backup first.
26. Server running out of RAM
When the server has no free memory, the OOM killer terminates PHP processes and the result is a 500.
Symptoms: Random 500s under traffic. free -h shows almost no available RAM. dmesg contains OOM killer messages.
How to confirm: Run free -h, top and dmesg | grep -i kill.
Safe fix: Add swap space, raise PHP memory carefully, or upgrade the server. Optimize heavy plugins. Verify that available memory stays healthy and no new OOM messages appear. Precaution: Monitor with tools such as htop.
27. Server CPU overload
When the CPU stays at 100 % for long periods, requests time out and appear as 500 errors.
Symptoms: High load average. The site becomes slow and then returns a 500. top shows one process consuming all cores.
How to confirm: Use top, uptime and mpstat.
Safe fix: Identify the process (PHP, MySQL or malware), optimize or stop it, and scale the server if necessary. Verify that the load average drops and the site responds normally. Precaution: Investigate before killing any process.
28. Disk space exhausted
Any partition that reaches 100 % stops logs, sessions and temporary files, resulting in a 500.
Symptoms: Sudden failure. df -h shows 100 % on the root or /tmp partition.
How to confirm: Run df -h and du -sh /* to locate large folders.
Safe fix: Delete old logs, backups and cache files. Clear /tmp. Restart the affected services. Verify that free space appears and the site works. Precaution: Set monitoring so usage never reaches 100 %.
29. Inode limit reached
Too many small files can exhaust the inode quota even when disk space remains available.
Symptoms: New files cannot be created. The error log may show “No space left on device” while df -h still reports free space.
How to confirm: Run df -i.
Safe fix: Delete unnecessary files (old sessions, caches, leftover backup fragments). Verify that inode usage drops and new files can be created. Precaution: Clean caches on a regular schedule.
30. Security or firewall rules
A firewall or security plugin may block legitimate requests and the server returns a 500.
Symptoms: The error occurs only from certain IP addresses or after a firewall was enabled.
How to confirm: Temporarily disable the firewall or security plugin and examine its log for blocked requests.
Safe fix: Whitelist the required paths or IP addresses. Adjust rules carefully. Verify that the previously blocked actions now succeed. Precaution: Never leave all security disabled on a live site for long.
31. ModSecurity blocking requests
ModSecurity rules can falsely flag normal WordPress or WooCommerce requests.
Symptoms: A 500 or 403 appears on form submissions or admin actions. The audit log shows the rule ID.
How to confirm: Inspect /var/log/modsec_audit.log or the host’s ModSecurity log.
Safe fix: Disable the specific rule or add an exception for the false positive, then restart the web server. Verify that the previously blocked action works. Precaution: Prefer narrow exceptions over turning ModSecurity off completely.
32. Malware or hacked files
Malicious code can inject fatal errors or exhaust resources, producing a 500.
Symptoms: Strange files appear. The site redirects unexpectedly or fails at random. Security scanners report infections.
How to confirm: Run a reputable malware scanner and compare core files with the original WordPress package.
Safe fix: Remove infected files, replace core and plugin files from clean sources, and change all passwords. Verify that the scanner reports a clean state and the site behaves normally. Precaution: Keep everything updated and use strong, unique passwords.
33. Missing PHP extensions
A required extension such as mysqli, curl, gd or mbstring may be missing. Functions then fail with fatal errors.
Symptoms: The error appears after moving hosts or changing the PHP version. The log shows “Call to undefined function”.
How to confirm: Run php -m or examine a phpinfo page.
Safe fix: Install the missing extension through the hosting panel or package manager, then restart PHP-FPM. Verify that the function exists and the site works. Precaution: Install only the extensions that are actually needed.
34. Third-party API failures
A plugin that waits indefinitely for an external API that is down or slow can time out and return a 500.
Symptoms: The error occurs only on pages that call the API. Other pages continue to work.
How to confirm: Temporarily disable the plugin that uses the API and check the external service’s status page.
Safe fix: Add proper short timeouts in the code or replace the plugin. Contact the API provider if necessary. Verify that the page loads even when the API is slow. Precaution: Always set reasonable HTTP timeouts.
35. WooCommerce conflicts
WooCommerce or one of its extensions can conflict with another plugin or the theme and produce fatal errors.
Symptoms: The error appears on cart, checkout or product pages. Disabling WooCommerce stops the 500.
How to confirm: Switch to a default theme and disable other plugins, then test the checkout flow.
Safe fix: Update WooCommerce and its extensions, replace conflicting plugins, and raise memory and execution limits if needed. Verify that a complete purchase flow succeeds. For the latest WooCommerce features you can also read about WooExpress. Precaution: Always test updates on a staging site.
36. Broken WP-Cron jobs
A stuck or looping cron job can consume resources until the server returns a 500.
Symptoms: High CPU usage from PHP processes. The site slows and then fails. wp-cron.php is called constantly.
How to confirm: Use WP-CLI wp cron event list and look for overlapping or past-due events.
Safe fix: Delete the problematic event. Consider disabling WP-Cron and using a real server cron instead. Verify that CPU usage drops and no overlapping events remain. Precaution: Avoid plugins that schedule heavy tasks too frequently.
37. Custom PHP code errors
Code added to functions.php, a must-use plugin or a custom plugin can contain a fatal error.
Symptoms: The error starts immediately after the code is added. The debug log points to the exact file and line.
How to confirm: Enable debugging and read the latest fatal error in debug.log.
Safe fix: Remove or correct the code. Prefer a proper plugin structure over direct edits. Verify that no new fatals appear and the site works. Precaution: Always test custom code on staging first.
38. Child theme code errors
A syntax error or missing function inside a child theme’s functions.php can crash the site.
Symptoms: The error appears after editing the child theme. The parent theme still works when activated.
How to confirm: Rename the child-theme folder. The site falls back to the parent or a default theme.
Safe fix: Correct the PHP, using proper hooks and escaping. Verify that the child theme can be activated again without a 500. Precaution: Keep a backup of the child theme before any edit.
39. Plugin or theme update incompatibility
A newly released plugin or theme version may be incompatible with the current WordPress or PHP version.
Symptoms: The error appears immediately after clicking “Update”. The site worked before the update.
How to confirm: Roll back using a backup or WP-CLI and read the changelog for known issues.
Safe fix: Stay on the previous version until a fixed release appears, or switch to an alternative. Verify that the site is stable on the older version. Precaution: Always test updates on a staging site first.
40. Object cache problems
A corrupted or misconfigured object cache (Redis, Memcached or file-based) can return bad data or crash.
Symptoms: Random 500 errors. Disabling the object-cache plugin stops the problem.
How to confirm: Disable the cache plugin, flush the cache store, and examine Redis or Memcached logs.
Safe fix: Flush the cache, restart the cache service, and reconfigure the connection. Verify that the site remains stable after the cache is re-enabled. Precaution: Monitor cache hit rates regularly.
41. Redis/Memcached connection issues
WordPress may be unable to connect to the Redis or Memcached server. The object-cache drop-in then causes a fatal error.
Symptoms: The error begins after object caching is enabled. The log shows “connection refused” to the cache host.
How to confirm: Test with redis-cli ping or telnet and verify the host and port in the configuration.
Safe fix: Start the cache service, correct the host/port/password, and restart PHP-FPM. Verify that the cache plugin reports a successful connection and the site works. Precaution: Protect Redis with a strong password.
42. PHP OPcache problems
OPcache can serve stale or corrupted bytecode after a code change, leading to fatal errors.
Symptoms: The error continues after plugin or theme files have been updated correctly.
How to confirm: Restart PHP-FPM (this clears OPcache) or temporarily call opcache_reset().
Safe fix: Restart the PHP service after every deployment. Adjust opcache.validate_timestamps if necessary. Verify that the new code runs correctly. Precaution: On production keep validate_timestamps off for better performance.
43. PHP-FPM process limit reached
When pm.max_children is set too low, new requests are refused and appear as 500 errors.
Symptoms: The error occurs under concurrent traffic. The PHP-FPM log shows “seems busy” or “max_children”.
How to confirm: Inspect the pool configuration and the PHP-FPM log. Watch active processes with ps.
Safe fix: Raise pm.max_children according to available RAM and restart the pool. Verify that the max_children messages stop and the site handles peak traffic. Precaution: Calculate the new value from real memory usage.
44. Too many simultaneous requests
The web server or PHP-FPM may be unable to handle the current number of concurrent connections.
Symptoms: 500 or 503 errors during traffic spikes. The access log shows many simultaneous hits.
How to confirm: Monitor connections with ss -s or netstat and watch the PHP-FPM status page if enabled.
Safe fix: Raise worker limits, add a cache layer or CDN, and optimize slow pages. Verify that the site stays up under similar load. Precaution: Load-test after any change.
45. Server timeout or upstream failure
Nginx or Apache may wait too long for PHP-FPM or the database and then return a 500.
Symptoms: The error appears on slow pages. The Nginx log shows “upstream timed out”.
How to confirm: Increase fastcgi_read_timeout or the equivalent Apache timeout and check the health of the upstream service.
Safe fix: Raise the timeout values only as a temporary measure, then fix the slow backend process and restart the web server. Verify that slow pages complete successfully. Precaution: Prefer solving the root cause over raising timeouts indefinitely.
46. Bad custom rewrite rules
Custom rules added to .htaccess or the Nginx configuration can create loops or invalid redirects.
Symptoms: The error appears after adding redirects or custom post-type rules. Removing the rules stops the 500.
How to confirm: Temporarily remove the custom rules and test with a default WordPress configuration.
Safe fix: Correct the syntax. Prefer the WordPress rewrite API over hard-coded rules whenever possible. Verify that the custom URLs work without producing a 500. Precaution: Test every new rule immediately after adding it.
47. Incorrect environment variables
Missing or wrong environment variables (in a .env file or server configuration) can break plugins that rely on them.
Symptoms: The error occurs only when a specific plugin runs. Debugging shows undefined environment values.
How to confirm: Print the environment from a temporary PHP file or inspect the hosting panel.
Safe fix: Set the correct variables in the server configuration, .env or wp-config.php, then restart PHP. Verify that the plugin functions. Precaution: Never commit real secrets to a public repository.
48. Incorrect server environment configuration
Wrong timezone, locale or path settings can cause subtle failures that surface as a 500.
Symptoms: Rare errors related to dates, file paths or character encoding.
How to confirm: Examine a phpinfo page for timezone and path values and compare them with the expected settings.
Safe fix: Set date.timezone in php.ini, correct any path-related constants, and restart the services. Verify that date- and path-dependent features work. Precaution: Keep the environment consistent between staging and production.
49. Large or corrupted wp_options table
Autoloaded options can grow huge or become corrupted. Every page load then consumes excessive memory and eventually fails with a 500.
Symptoms: High memory usage on every request. Debug tools show large autoloaded data.
How to confirm: Run a query that lists the largest autoloaded options ordered by size.
Safe fix: Clean unused options, change the autoload flag to “no” for large rows, and optimize the table. Verify that page memory usage drops and the site becomes faster and more stable. Precaution: Clean the options table regularly with a trusted tool.
50. Long-running or locked database queries
A query that holds a lock for too long forces other queries to wait and eventually time out, producing a 500.
Symptoms: Intermittent 500 errors. SHOW FULL PROCESSLIST; shows queries in a “Locked” or “Waiting” state.
How to confirm: Examine the process list and the slow-query log.
Safe fix: Kill the blocking query only if it is safe to do so, add missing indexes, and rewrite the expensive query. Verify that no further locked queries appear and the site stays responsive. Precaution: Identify the source of the query before killing anything on a production database.
Final Calm Advice for Safe Troubleshooting
Always make a complete backup before changing anything. Prefer a staging site for experiments. Enable debugging only while you investigate and turn it off when finished.
Start with the most relevant log files: wp-content/debug.log, the web-server error log, the PHP-FPM log and the MySQL error log. The newest entries almost always point to the exact cause.
After every fix, clear all caches, test both the front-end and the admin area, and watch the logs for a few quiet minutes. If the 500 returns, simply move to the next most likely cause on the list.
Helpful tools that speed the process include the WP Server Toolkit. For a clean modern stack you can also follow the Nginx + PageSpeed + MariaDB + PHP installation guide.
More technical reading is available in the tech and statistics blogs. After a long troubleshooting session, a smile from some of the best useless websites is always welcome.
You now have a complete, practical and calm map of the fifty most common causes of the 500 internal server error wordpress. Work through the list methodically, keep backups, and your site will be back online safely and soon.
