WORDPRESS & PHP TROUBLESHOOTING
How to Fix WordPress 500 Internal Server Error
HTTP 500 means the server encountered an unexpected condition that prevented it from completing the request. Browsers may show “500 Internal Server Error,” “HTTP ERROR 500,” “The server encountered an internal error,” or simply “Internal Server Error.” The message alone does not identify the cause.
A PHP fatal error, plugin or theme problem, invalid server directive, permissions issue, or resource limit can be involved. Some failures occur before WordPress loads, so troubleshooting needs both application and hosting evidence.
Use logs to choose the next step
Record the affected request and recent changes, preserve backups, and review the matching error logs. Test the component the evidence points to, one change at a time. Check PHP compatibility, applicable server rules, permissions, and hosting resources; retest and remove temporary diagnostics after the cause is addressed.
Need Help With Your WordPress Website?
If you prefer professional assistance, Hostingcone offers support for eligible WordPress troubleshooting and website repair issues.
What Causes a 500 Internal Server Error in WordPress?
Common causes include PHP fatal errors, incompatible plugins, broken themes or custom functions, invalid server configuration, and unsupported .htaccess directives on applicable Apache-compatible setups. PHP memory exhaustion, file access problems, incomplete updates, and hosting resource limits can also contribute.
Check whether every page fails or only a particular URL, login, checkout, or action. A working homepage does not rule out a failing PHP endpoint; cached pages can also hide an application failure. Compare the failing request with the corresponding logs.
500 vs 502, 503, and 504
500 is a general unexpected server failure. 502 means a gateway received an invalid upstream response. 503 indicates temporary unavailability, often overload or maintenance. 504 means a gateway timed out waiting for an upstream response. The same underlying outage can be reported differently by a proxy or hosting platform, so use the actual status and logs.
Not every 500 originates inside WordPress. Web-server rules, PHP handlers, reverse proxies, or provider incidents may fail before the application runs. A database or DNS problem has its own diagnostic path, even if a particular failure is accompanied by a server error.
Before Troubleshooting: Protect Your Website
Prepare a rollback before making changes
Production troubleshooting can change functionality or add downtime. Preserve available backups, use staging where practical, and make one documented change at a time. Restoring a backup can overwrite orders, submissions, content, or other changes made after it was created.
1. Back up the database and website files when possible; check existing backups are usable.
2. Review recent plugin, theme, PHP, and WordPress changes.
3. Record the exact error, timestamp, URL, and action that fails.
4. Check whether the WordPress admin dashboard still opens.
5. Use an isolated staging environment for uncertain tests.
6. Avoid making several changes simultaneously.
7. Keep credentials, configuration files, and sensitive logs private.
If a fresh backup cannot be completed, preserve existing copies and ask the hosting provider about recovery options before risky changes. Keep backup files outside public download locations. A backup is a recovery aid rather than a guarantee against data loss.
Check the WordPress Error Logs
Logs often provide the fastest useful evidence. Check the hosting account’s Errors interface where available, the web-server error log, and the applicable PHP error log. Match the failing URL and timestamp, allowing for the server’s time zone; an old warning may be unrelated to the current failure.
For an authorized WordPress diagnostic session, this illustrative wp-config.php snippet enables logging while keeping WordPress debug messages off the page:
define('WP_DEBUG', true);define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Update existing definitions rather than adding duplicates. Place the settings before WordPress loads, generally before the comment indicating that editing should stop. Preserve the current configuration and rollback plan; do not post the full file or its secrets publicly.
With the default content directory, WP_DEBUG_LOG set to true may write to wp-content/debug.log when WP_DEBUG is enabled and an error occurs. The path can differ in customized installations. Creation depends on permissions, configuration, and WordPress reaching its logging setup; a failure before bootstrap may appear only in hosting or PHP logs.
Look for recent PHP fatal errors, uncaught exceptions, memory exhaustion, and the file/line or component involved. A stack trace naming a plugin is useful evidence, but the surrounding frames and recent changes matter. Do not assume every notice or deprecation warning caused the 500.
Keep diagnostic logs private
Debug logs can contain filesystem paths, queries, customer information, or credentials. Use restricted access or an approved log path outside public serving locations; protection must suit the actual web server. Do not enable public on-screen PHP error display on a production website.
After diagnosis, restore the intended production debug settings, restrict or disable temporary logging, and handle collected logs under the site’s retention/security policy. WP_DEBUG_DISPLAY false controls WordPress debug display; review the provider’s PHP display policy too rather than assuming the snippet overrides every startup error.
Disable WordPress Plugins Safely
Method A — WordPress dashboard
If wp-admin works, record the active plugin list and use Plugins to deactivate the component identified by the logs. Retest the original failing action. If the cause is unclear, a controlled deactivation test can isolate it, but checkout, forms, security, and other features may stop working while dependencies are disabled.
Reactivate verified components one at a time, retesting after each. Reproduce the interaction in staging when possible; a conflict may involve two plugins rather than one individually faulty plugin. Keep the failing component inactive until a compatible update, rollback, or supported fix is ready.
Method B — File manager or SFTP
With authorized access and a backup, locate the actual plugin directory; its standard location is wp-content/plugins, but some installations customize it. For a targeted test, temporarily rename the suspected plugin’s folder. If necessary, a controlled rename of the entire plugins directory can test whether ordinary plugins are involved.
Record original names and restore the standard directory name after the test. Renaming is not always a persistent deactivation: restoring a folder can load previously active plugins again, while visiting the dashboard with files missing may change their activation state. Preserve the active list and use dashboard controls to isolate and reactivate components deliberately.
Must-use plugins and drop-ins such as object-cache.php load separately and are not disabled by renaming the ordinary plugins directory. Managed hosting components may be required. Ask the provider before changing them; do not delete plugin files or assume a folder rename preserves every service dependency.
WP-CLI is another option for authorized administrators working in the correct installation. It can deactivate plugins and, with appropriate skip options, avoid loading ordinary plugins or themes during some diagnostics. Must-use plugins and failures earlier in bootstrap can still prevent it from running. Do not run commands against an unverified production path.
Check for Theme Problems
A recent theme update, child-theme change, or custom function can cause a PHP fatal error. Look for matching theme paths and exceptions in the logs, then compare the last known working version and supported PHP requirements.
In staging, or during an approved production test, switch to another installed, compatible theme using the dashboard or authorized administration tools. Record the original theme and configuration first. Retest the affected request rather than relying only on the homepage.
A theme switch can alter layouts, menus, widgets, template behavior, and theme-dependent functionality. Do not delete the active theme or rely on an automatic fallback without knowing a suitable replacement is installed. Preserve the parent/child relationship and use a reviewed rollback for custom code.
Check the .htaccess File
.htaccess applies to Apache and compatible configurations where overrides are enabled. Nginx does not read it directly, and managed platforms can use different routing controls. Check the actual server before treating it as a universal WordPress fix.
An unsupported directive, invalid syntax, a disallowed override, or a PHP setting incompatible with the configured handler can trigger a server error before WordPress runs. Review the web-server log for the exact directive and file.
1. Preserve a secure copy of the existing .htaccess outside public download locations.
2. Where appropriate, temporarily rename it during a controlled staging or provider-assisted test.
3. Retest the same request and note whether the error changes.
4. Restore the original file or regenerate the intended WordPress rewrite block after correcting the failing rule.
Renaming can remove redirects, access restrictions, and security controls as well as rewrite rules. Keep suitable protection in place during the test and avoid exposing a production site just to bypass a directive. Restore or merge necessary custom rules rather than discarding them.
Saving the current Permalinks settings may regenerate the WordPress rewrite block when the platform supports it and the file is writable. Multisite, subdirectory installations, and custom routing can require different rules. Do not paste a generic replacement over the entire file or change the site’s permalink structure as a diagnostic shortcut.
Investigate PHP Memory and Version Issues
A log entry such as “Allowed memory size of … bytes exhausted” is evidence of PHP memory exhaustion. Review the effective limit and the request or component consuming memory. Heavy queries, large imports, or a faulty plugin can require investigation beyond increasing a setting.
WP_MEMORY_LIMIT requests a WordPress memory allowance but does not override every hosting-level restriction or capacity limit. The effective PHP configuration and provider policy matter. Do not treat an arbitrary number as a guaranteed fix or assume unlimited memory is appropriate.
Compare the site’s PHP version with the requirements of WordPress, plugins, themes, and custom code. A PHP change can expose incompatible functions or missing extensions. Test a supported version in staging and use the provider’s approved controls, rather than repeatedly switching production versions.
The command-line PHP runtime can differ from the web/PHP-FPM runtime. Check the failing web application’s configuration and extensions, not just a CLI version result. On shared or managed hosting, ask the provider when limits or handlers are outside your account’s control.
Check File Permissions and Ownership
Incorrect ownership, permissions, ACLs, or server access policies can prevent PHP from reading code, writing required files, or accessing a configured path. Directories commonly use 755 and files commonly use 644, but these are examples rather than universal requirements.
Correct access depends on the owner/group, PHP execution model, hosting security policy, and intended use of each path. Sensitive configuration may use more restrictive permissions where supported; some handlers reject overly writable files. Compare the affected path with the provider’s documented model.
Do not use 777 as a shortcut
Broadly writable permissions can expose the site and may not solve an ownership or policy problem. Avoid recursive permission changes across the installation. Ask hosting support to investigate the specific path, account ownership, and access denial shown in the logs.
WordPress 500 Error After an Update
Record which plugin, theme, PHP version, WordPress core release, or custom code changed. Check the associated logs before restoring or replacing files. A partial update, incompatible requirement, or missing file can cause a fatal error; an interrupted update can also leave maintenance messages or other symptoms besides HTTP 500.
Use a reviewed component rollback or verified backup when appropriate. Restoring the entire site can overwrite newer orders, submissions, and content. If core files require replacement, use the platform’s supported recovery process and preserve configuration and site data; do not delete directories blindly.
A browser, hosting cache, or reverse proxy may retain a previous error response. After the underlying problem is fixed, verify the intended endpoint and clear the relevant cache through approved controls if needed. Cache clearing alone does not correct a PHP fatal error or invalid server rule.
Retest the original failing action and important dependent features. A working admin page does not prove checkout or forms are restored. Document the resolved cause and the compatibility requirement before repeating the update.
WordPress 500 Error After Website Migration
A new environment may use a different PHP version or handler, lack a required extension, reject an old directive, or have different file ownership and permissions. Incomplete transfers and plugin incompatibilities can also prevent requests from completing.
Check the exact response and logs. DNS determines which server is reached, while HTTP 500 is a response from a server or application in that request path. A database connection message calls for its own credential, endpoint, service, and permission checks; do not assume every post-migration failure has the same cause.
Diagnose WordPress database connection errors after migration
Review Hostingcone Website Migration scope and current purchase steps
The published service is $149 one-time for one standard WordPress website migration. Additional work requires approval and may incur additional charges. Destination compatibility and access requirements affect the agreed work; no uninterrupted-transfer outcome is promised.
How to Fix a WordPress 500 Error in cPanel
1. Open the hosting account’s cPanel, if it is available.
2. Review the Errors interface and relevant PHP/web-server logs.
3. Use File Manager to inspect recent changes in the correct installation.
4. Review effective PHP settings through the provided hosting tools.
5. Test plugin or theme components when logs identify them.
6. Check permissions and applicable server rules without broad resets.
7. Retest the affected URL or action and restore temporary diagnostic changes.
Layouts and features vary by provider. Tools may include MultiPHP Manager, MultiPHP INI Editor, or another PHP selector, but they are not available on every account. Hostingcone customers should use the controls actually supplied for their service, not assume a particular panel or feature exists.
A limited Errors view may not contain the full PHP-FPM or upstream log. Ask hosting support for the matching records when the account interface cannot explain the failure. Keep credentials and private logs out of public screenshots.
When the Problem Is Server-Side
Hosting administrator assistance may be needed for PHP-FPM faults, web-server misconfiguration, resource exhaustion, ownership errors, missing PHP extensions, crashes, or platform incidents. Gateway failures can return 502, 503, or 504 instead of 500 depending on the configuration.
Shared or managed-hosting customers should report the timestamp, hostname, affected request, recent changes, and redacted evidence to the provider. Authorized VPS administrators should review service and system logs under their operating procedures. Do not restart shared infrastructure or change global settings without authority.
Visitors cannot repair a server failure by clearing their browser cache alone. A separate browser or network can help rule out a cached response or local condition, but the responsible operator still needs to correct the underlying service problem.
How to Prevent Future WordPress 500 Errors
Maintain verified backups and a recovery plan. Test updates in staging where practical, review PHP requirements, and keep plugins, themes, and custom code compatible. Remove unnecessary plugins through a planned change process instead of adding overlapping functionality.
Monitor availability, review error logs, and document meaningful configuration changes and rollback steps. Choose hosting suitable for the site’s requirements and keep a clear escalation route for service incidents.
Explore WordPress Maintenance for ongoing upkeep
Review Website Care for ongoing maintenance and support
Maintenance and monitoring can reduce avoidable problems and improve response readiness, but they do not eliminate every error or guarantee uninterrupted service. Backups help recovery and do not guarantee that every recent change can be restored.
When to Get Professional WordPress Support
Ask for help when the site remains unavailable, the logs are unclear, a rollback is risky, you lack server access, or failures involve hosting configuration and third-party dependencies. Provide the original failing action and redacted evidence rather than repeatedly changing unrelated settings.
Hostingcone’s published WordPress Troubleshooting service is $79 one-time: diagnosis and up to 1 hour of troubleshooting for one WordPress website. Additional work requires approval and may incur additional charges. The included time is not a guarantee that every issue will be resolved.
Get WordPress Support for supported troubleshooting
Website Repair starts at $99. Final pricing depends on complexity, urgency, and the amount of work required. Its published page leads to the existing service-request workflow so the issue and scope can be reviewed.
Review Website Repair scope and request assistance
Explore Web Hosting for your website’s operating environment
Use the linked Maintenance and Migration pages where ongoing upkeep or a hosting move is relevant. Review each current service page for approved scope, exclusions, pricing, and purchase steps. Customer cooperation and secure access may be required; repair outcomes and turnaround times are not guaranteed.
Frequently Asked Questions
What does HTTP 500 mean in WordPress?
The server encountered an unexpected condition and could not complete the request. It does not identify the cause by itself; PHP/application errors and hosting configuration can both be involved.
Can a plugin cause a WordPress 500 error?
Yes. A fatal error, incompatible dependency, or resource-intensive operation can contribute. Match logs and recent changes, then test the suspected component with a rollback plan instead of assuming every plugin is faulty.
How do I fix a 500 error without wp-admin access?
Use authorized hosting logs and File Manager or SFTP to investigate the affected installation. A controlled plugin-folder test or provider assistance may help. Preserve backups and original names; renaming can disable features and restoring a folder can reload previously active code.
Can .htaccess cause an Internal Server Error?
Yes, on Apache-compatible configurations that read it. Invalid or unsupported directives can fail before WordPress loads. Back up the rules and use a controlled test; Nginx does not directly read .htaccess.
Does increasing PHP memory fix WordPress 500 errors?
Only when a relevant memory limit is part of the cause and the effective hosting configuration permits the change. It will not correct incompatible code, permissions, or a failed service. Use logs rather than an arbitrary guaranteed memory value.
Why did WordPress show a 500 error after an update?
A plugin, theme, PHP change, partial core update, or custom code incompatibility may have caused a fatal error. Review the update and matching logs before rolling back. Cached responses can persist after the underlying issue is corrected.
Can I fix a WordPress 500 error through cPanel?
Sometimes, using the available logs, File Manager, and PHP controls for an authorized targeted fix. Features vary, and service-level issues may still require the provider. Do not assume every hosting account includes cPanel.
Is a WordPress 500 error caused by my hosting provider?
It can be a hosting incident or configuration problem, but application code and resource usage can also contribute. The status alone does not assign responsibility. Use logs and affected-request evidence to identify the failing layer.
Will fixing a 500 error delete my website data?
A targeted configuration or compatibility fix does not inherently require data deletion. Restores, replacements, or careless recovery steps can overwrite or damage data, so preserve verified backups and agree on a rollback/recovery plan first.
When should I contact WordPress support?
Contact support when the site stays offline, logs are unclear, recovery needs expertise or access you lack, or important features fail after a change. Share redacted evidence and recent changes; use a secure process if credentials are required.
Need Help Fixing a WordPress 500 Error?
If your WordPress website is displaying an Internal Server Error, Hostingcone offers troubleshooting and repair services to help investigate supported WordPress, PHP, and hosting configuration problems.
Explore more solutions in our WordPress Troubleshooting Hub, including guides for database errors, failed updates, and website migrations.