500 Internal Server Error

What this error means & how to recognize it

• The browser shows a blank, generic, or branded 500 Internal Server Error page.
• A previously working page fails after a code edit, plugin or theme installation, update, deployment, or configuration change.
• Only certain URLs, forms, admin screens, or site features fail while the rest of the site remains available.
• A PHP, application, or web-server log records a fatal error, syntax error, permission problem, missing dependency, or resource-limit failure at the same time.
• Repeating the request produces the same 500 response, although intermittent failures can occur when a resource limit or application dependency is involved.

Root causes, ordered by likelihood

1. Application code, plugin, theme, or module failure — A syntax error, fatal error, incompatible update, or unhandled condition can prevent the request from completing.
2. Invalid Apache configuration — A malformed or unsupported directive in .htaccess, or a rule requiring a disabled module, can trigger a 500 response. .htaccess applies to Apache-based setups, not all web servers.
3. Incorrect file or directory permissions or ownership — Manual uploads, migrations, and deployments can leave the web process unable to read required files.
4. PHP memory or execution-time exhaustion — Large imports, expensive queries, or resource-heavy extensions can exceed configured limits; some environments return 500 when this happens.
5. Missing deployment configuration or dependencies — A changed database credential, absent environment variable, unavailable package, or incompatible runtime can break the application.
6. Incomplete or corrupted application or CMS files — An interrupted update can leave required core files missing or damaged.

How to fix it

1. Confirm the scope and timing

Reload the exact URL that returns 500 and record the time, including the timezone. Check whether the whole site fails or only one route, form, admin screen, plugin feature, or request type. A feature-specific failure makes its recent code and dependencies more likely; a site-wide failure points more strongly toward server configuration, deployment, or core files.

2. Check the relevant logs first

Review the PHP error_log, web-server error log, and application or CMS log available on the host. Common locations include /var/log/apache2/error.log for Apache and /var/log/nginx/error.log for Nginx, but hosting layouts vary. Match entries to the failure time and record the file, line number, exception, upstream message, or configuration directive. The generic browser page alone is not enough to identify the cause.

3. Isolate a recent code or extension change

If the log identifies a file, plugin, theme, module, or deployment change, revert that change or disable the named component in a testable environment. On a CMS, use the administration area when it is available. If the admin area is inaccessible, SFTP or the hosting file manager may allow you to rename the relevant component directory. Change one component at a time, then retest the failed URL. If the error disappears, investigate compatibility, configuration, and available updates before re-enabling it.

4. Test .htaccess only on Apache

If the log points to an .htaccess parse error or the failure began after an Apache rule change, make a backup and temporarily rename .htaccess to .htaccess.bak through SFTP or the hosting file manager. Retest the page. If it works, restore or recreate the file carefully and add custom directives incrementally. An unsupported directive or missing Apache module may be the underlying issue. Do not apply this step to an Nginx-only setup, where .htaccess is not used for request configuration.

5. Correct permissions and ownership carefully

When the log reports a permission or ownership failure, compare the affected path with a working file or the hosting provider’s documented settings. 644 for files and 755 for directories are common settings, but the correct values depend on the host and deployment model. Fix the affected path through SFTP, SSH, or the hosting file manager, and do not make files or directories globally writable as a shortcut.

6. Investigate PHP and application resource limits

If the log mentions memory exhaustion, maximum execution time, or a similar limit, identify the operation consuming the resource, such as a large import or expensive plugin task. Adjust memory_limit or max_execution_time in the applicable php.ini, .user.ini, hosting setting, or deployment configuration only if your host permits it. Also reduce the workload or fix the inefficient operation; raising a limit alone may only postpone the failure.

7. Compare deployment settings and required files

For failures that began after a deployment or migration, compare environment variables, database credentials, runtime versions, installed dependencies, file paths, and generated configuration with the working environment. Confirm that required files are present and that the application can reach its configured database or service. Use the log’s named missing variable, package, or connection error as the starting point rather than changing unrelated settings.

8. Restore damaged files only after preserving evidence

If an incomplete update or corrupted core file is indicated, save the relevant log and a copy of the current files before making repairs. Then restore known-good files or rerun the platform’s supported update process, using a backup when available. Retest the original URL and check that no new matching error is being written to the log.

Prevention & how to verify the fix

• Back up both files and the database before installing or updating a plugin, theme, module, or CMS component.
• Test code and .htaccess changes on a staging copy when possible, and retain a known-good configuration for rollback.
• Deploy configuration variables and dependencies consistently between environments, and verify required files after migrations.
• Monitor PHP, application, and web-server error logs rather than relying only on external availability checks.
• Make one change at a time, record what changed, and retest the exact URL that failed.
• Keep detailed diagnostics in server-side logs instead of displaying them to visitors on a production site.

Frequently asked questions