A WordPress 500 error means the server couldn’t complete your request. Fixing it involves finding the underlying fault, which could involve a plugin, theme, PHP configuration or server problem.
For a small business, that outage can interrupt lead generation and leave clients unable to book or enquire. Start with a recoverable backup, then make one controlled change at a time.
The safest starting point is protecting your data before investigating what changed.
Key takeaways
- Back up both WordPress files and the database before editing anything, and use staging where possible.
- Match errors to server logs rather than assuming a plugin, memory limit or configuration file is responsible.
- After recovery, test forms, bookings and payments, then disable temporary debugging on the live site.
1. Protect the site before making changes
Take a fresh copy of the database and WordPress files, including uploads, plugins, themes and wp-config.php. Keep a copy outside the live hosting account.
Even a broken site’s current backup matters. It preserves recent enquiries, orders and appointments that an older restore point might lack.
Before restoring anything, identify which records arrived after that backup. Replacing an active shop’s database with yesterday’s copy can remove today’s orders.
Where possible, reproduce the problem on a private clone. Our WordPress staging and testing guide covers separating that environment from production.
Protect staging with hosting-level access controls. A separate address or search-engine visibility setting doesn’t protect copied customer information.
Also disable live payments, customer emails and outgoing webhooks on the clone. Pause email marketing connections and automated follow-ups so testing doesn’t contact real customers.
Record each change and its result. If file access or configuration editing is unfamiliar, use hosting support rather than improvising.
A staging copy can contain production credentials and customer records. Isolate its outgoing connections before testing integrations.
2. Find evidence for the WordPress 500 error
Establish the scope and recent changes
Open an affected page and the WordPress administration area separately. Note whether the error affects every request, one landing page or a particular action, such as submitting a form.
Record the failing URL, exact time and time zone. Then review recent plugin updates, theme changes, deployments and PHP changes.
A failure immediately after an update makes that change worth investigating, but timing alone doesn’t establish the cause. Also review scheduled tasks if failures recur at similar times.
Check whether a cached page is masking the problem. A working homepage doesn’t prove that uncached requests or checkout are healthy.
Read logs without exposing errors publicly
Start with the hosting control panel’s PHP and web-server error logs. Match entries to your recorded failure time rather than chasing unrelated warnings.
If needed, temporarily enable WordPress debugging through wp-config.php: set WP_DEBUG and WP_DEBUG_LOG to true, whilst keeping WP_DEBUG_DISPLAY set to false. Edit existing definitions rather than adding duplicates.
Keep logs access-restricted because they can expose server paths and sensitive information. WordPress’s Site Health documentation explains debug logging and its security implications.
After troubleshooting, set WP_DEBUG back to false, remove temporary logging settings and securely remove diagnostic files you no longer need.
3. Isolate plugin and theme failures
Test plugins without deleting their data
If administration access works, deactivate the plugin identified by the logs or the most recent change. Retest the exact failing action.
When there’s no clear suspect, deactivate ordinary plugins on staging, then reactivate them individually. Test after each activation. This helps identify conflicts involving more than one component.
Without dashboard access, use SFTP or the host’s file manager to temporarily rename the suspected plugin’s folder inside wp-content/plugins. Record its original name first.
Don’t delete plugin folders or run uninstall routines. These can remove settings or stored information.
If the failure persists, restore the original folder name before investigating another component. Must-use plugins and hosting drop-ins need separate investigation.
Test the active theme separately
Switch to an installed, compatible default WordPress theme on staging, then repeat the failed request.
If that resolves the error, investigate the active theme, its child theme and associated custom code. A theme may also depend on a plugin, so this result doesn’t automatically identify a single faulty file.
Switching themes can alter navigation, page-builder output and digital branding. Avoid changing a live theme casually during an outage.
For a fault introduced by custom web development, roll back the relevant code change through the established deployment process. Then reproduce the original error before treating the rollback as successful.
4. Review rewrite rules and damaged files
Handle .htaccess only on relevant servers
WordPress uses .htaccess with Apache’s rewrite module for permalinks, as described in the WordPress glossary. Nginx doesn’t use this file, so this troubleshooting route isn’t universal.
Back up .htaccess before changing it. Then have hosting support inspect recent edits for invalid directives or unsupported settings.
When the fault involves WordPress rewrite rules and the dashboard remains available, saving Settings > Permalinks can regenerate the WordPress rules on a writable Apache setup.
Preserve custom redirects and security directives. Replacing the entire file with generic rules can remove protections or break existing URLs.
Investigate interrupted updates and file changes
An interrupted update, incomplete upload or syntax error can also prevent WordPress from running. Review deployment records alongside the logs.
If a specific file changed immediately before the failure, restore its known-good version from your backup or version-control system. Retest before making another change.
For damaged WordPress core files, use a controlled core repair through hosting support or a developer. Keep site content and configuration intact.
Also investigate unexpected changes to file ownership or permissions. Don’t make everything writable or apply broad permission changes as a shortcut.
5. Check hosting resources and PHP compatibility
A resource problem needs evidence. PHP’s memory_limit setting controls how much memory a script can allocate, but increasing it isn’t a universal repair.
If the logs report exhausted memory, identify the request and component involved. Then review the configured limit and available hosting capacity with technical support.
Also inspect storage usage, PHP worker availability and server-side failures. Full storage or overloaded services can interrupt requests even when WordPress files are unchanged.
If the problem followed a PHP version change, test compatibility with the installed WordPress version, plugins and theme. A temporary rollback may restore service, but don’t leave the site dependent on an unsupported PHP release.
Repeated dashboard lag and campaign-related failures justify a broader hosting review. Our managed and shared WordPress hosting comparison explains the differences in infrastructure and support responsibilities.
Send support the affected URL, timestamp, log excerpt and changes already attempted. This gives them a concrete incident to investigate.
6. Restore service and test the customer journey
If diagnosis is taking too long, a known-good restore may be the safest recovery route. However, preserve newer orders, bookings and customer records before replacing the database.
Our website backup testing guide explains testing recovery without overwriting production. A completed backup notification alone doesn’t prove that the site can recover.
After applying the fix, clear relevant WordPress, server and CDN caches. Then test as a logged-out visitor on desktop and mobile.
Look beyond whether the web design appears intact. Submit an enquiry, follow a booking route and use a payment gateway’s supported test process where relevant. Confirm that notifications reach the intended mailbox.
A successful form submission and successful email delivery are separate checkpoints. Also test CRM connections and other systems and automation affected by the outage.
Finally, revisit landing pages linked from your Google Business Profile, social media and digital marketing campaigns. Mobile-responsive layouts and working enquiry routes matter more than a healthy-looking homepage.
Record the cause and repair in your ongoing website support plan. Include update ownership, rollback arrangements and escalation responsibilities.
Frequently asked questions
Can I fix a 500 error without dashboard access?
Yes, some faults can be investigated through hosting logs, SFTP and the hosting file manager. Start with a backup, then use the evidence to isolate the affected component.
If WordPress has sent a Recovery Mode email, its protected link may provide access for investigating a fatal plugin or theme error.
However, server configuration failures may prevent WordPress from running at all. Those require hosting-level investigation rather than changes inside the dashboard. Avoid repeated speculative file edits when the logs don’t identify a clear direction.
Will a WordPress 500 error damage SEO?
A brief outage doesn’t automatically remove your pages from search results. However, repeated or prolonged server errors can disrupt crawling and eventually affect indexing.
Fix the availability problem before changing SEO settings, redirects or page addresses. Those changes won’t repair a server failure and can introduce additional faults.
After recovery, review affected URLs and relevant Search Console reports. Also resume paused campaigns only after their landing pages and enquiry routes work. This protects both advertising spend and conversion optimisation measurements.
Keep recovery controlled and repeatable
A WordPress 500 error needs evidence-led troubleshooting because several different faults can produce the same response. Protect your data, isolate changes and test the complete customer journey.
Routine website care and maintenance should include tested recovery, controlled updates and clear technical ownership.
See how we collaborate with creative agencies when you need technical support across client websites.
