Quick answer
A WordPress 500 error after a hack can be caused by malicious PHP, damaged .htaccess rules, broken cleanup edits, plugin conflicts, exhausted server resources, or host security blocks. Check server and PHP logs first, preserve backups, repair files from clean sources, and continue malware cleanup instead of treating the error as only a normal WordPress bug.
A 500 internal server error is a broad message. It tells you the server failed, but it does not tell visitors whether the cause is a plugin bug, malware, or a security block.
After a known or suspected hack, a 500 error should be investigated with both troubleshooting and security in mind.
Why this problem matters
If the error is caused by malware, simply restoring functionality can leave the harmful code in place. If it is caused by cleanup, putting old files back may restore the infection.
A careful process reduces downtime while preserving evidence needed to find the original compromise path.
Common warning signs
- The 500 error began after suspicious file changes.
- .htaccess contains unfamiliar rewrite rules.
- PHP logs mention encoded or unknown files.
- Hosting reports malware or resource abuse.
- The error returns after temporary fixes.
The log entry closest to the failed request is usually more useful than the browser message itself.
Where the issue usually hides
Causes can hide in .htaccess, wp-config.php, plugin files, theme functions, mu-plugins, server rules, or resource limits.
Some malware intentionally breaks when a remote server is unavailable, causing intermittent 500 errors that look like hosting instability.
How to investigate safely
Check PHP error logs, server logs, and hosting notices. Then compare recently modified files against clean sources.
If .htaccess is involved, preserve a copy before replacing it. Malicious and legitimate rules may be mixed together.
- Review PHP fatal errors and server logs.
- Inspect .htaccess and server rewrite rules.
- Check recently modified plugin and theme files.
- Review hosting resource usage and security blocks.
- Test repairs one change at a time.
Cleanup priorities
Repair broken legitimate code and remove malicious code. If a plugin was compromised, reinstall from a trusted source rather than editing unknown fragments manually.
After the 500 error is resolved, verify that the site is not still redirecting, serving spam, or exposing backdoors.
- Back up the broken state.
- Use logs to identify the failure point.
- Restore clean code or rules.
- Remove malware and persistence mechanisms.
- Clear cache and test important URLs.
What to avoid
Do not disable every plugin and leave the site that way without finding the actual cause. That may hide the issue and break functionality.
Do not overwrite .htaccess without saving the original. It may contain clues or needed site rules.
How to prevent it from returning
Maintain clean backups, update plugins, monitor server errors, and review file changes after every security incident.
Security maintenance helps catch the conditions that lead to repeated 500 errors, such as vulnerable plugins or backdoors.
Helpful internal resources
Related help includes hosting suspension recovery, hidden plugin and theme malware removal, and security maintenance.
External reference
WordPress.org’s troubleshooting documentation is useful for general 500-error diagnosis.
When to get professional help
Get help if the site is down, logs point to suspicious files, or the error returns after temporary fixes.
How to verify the issue is fully fixed
Verification should match the way the problem appeared. For WordPress 500 error after hack, do not rely on a single logged-in desktop check. Test the affected pages as a logged-out visitor, from a private browser window, and from a mobile device when relevant. If search traffic was involved, inspect the page from Search Console or by checking the exact URL that appeared in search results.
Also review cached output. WordPress cache, CDN cache, server cache, and browser cache can continue showing old malicious content even after the source has been removed. Clear each layer, then retest the same URLs that originally showed the problem. A clean homepage is helpful, but the real proof comes from testing the affected paths, templates, and user conditions.
What to document during recovery
Keep a simple incident note while working on WordPress 500 error after hack. Record the first date the issue was noticed, affected URLs, warning screenshots, suspicious file paths, changed users, plugin versions, cleanup actions, and cache purges. This does not need to be a formal report, but it should be detailed enough that another person can understand what changed.
Documentation matters because reinfections are easier to investigate when you know what was removed the first time. It also helps when contacting hosting support, Google, ad platforms, or clients. A clear summary such as scripts removed, vulnerable plugin patched, credentials rotated, and pages retested is much stronger than saying the site was cleaned.
How this affects SEO and visitor trust
Security problems do not only affect files. They affect how visitors and search engines interpret the whole site. A user who sees a warning, redirect, spam snippet, broken checkout, or strange login behavior may not return even after the technical issue is fixed. Search engines may also need time to recrawl cleaned pages and update snippets.
That is why cleanup should be paired with trust recovery. Make sure important pages load cleanly, internal links still point to useful resources, metadata is accurate, and security warnings are resolved before promoting the site again. For high-value pages, inspect the live page, the rendered source, and the search result after recrawling.
Questions to ask before closing the incident
- What was the most likely entry point?
- Was any administrator, hosting, SFTP, database, or API access exposed?
- Were files, database content, users, and cache all reviewed?
- Were vulnerable plugins or themes updated, removed, or replaced?
- Is monitoring active so the same pattern is noticed quickly if it returns?
If any of these questions cannot be answered, the incident may not be fully closed. It is better to leave a cleanup marked as monitoring in progress than to declare the site safe too early and miss a persistence mechanism.
How to verify the issue is fully fixed
Verification should match the way the problem appeared. For WordPress 500 error after hack, do not rely on a single logged-in desktop check. Test the affected pages as a logged-out visitor, from a private browser window, and from a mobile device when relevant. If search traffic was involved, inspect the page from Search Console or by checking the exact URL that appeared in search results.
Also review cached output. WordPress cache, CDN cache, server cache, and browser cache can continue showing old malicious content even after the source has been removed. Clear each layer, then retest the same URLs that originally showed the problem. A clean homepage is helpful, but the real proof comes from testing the affected paths, templates, and user conditions.
What to document during recovery
Keep a simple incident note while working on WordPress 500 error after hack. Record the first date the issue was noticed, affected URLs, warning screenshots, suspicious file paths, changed users, plugin versions, cleanup actions, and cache purges. This does not need to be a formal report, but it should be detailed enough that another person can understand what changed.
Documentation matters because reinfections are easier to investigate when you know what was removed the first time. It also helps when contacting hosting support, Google, ad platforms, or clients. A clear summary such as scripts removed, vulnerable plugin patched, credentials rotated, and pages retested is much stronger than saying the site was cleaned.
FAQ
Can malware cause a 500 error?
Yes. Broken injected PHP, malicious rewrite rules, and resource abuse can all cause 500 errors.
Should I replace .htaccess?
Sometimes, but save a copy first and confirm which rules are legitimate.
Can hosting security cause the error?
Yes. A host firewall or malware scanner may block suspicious execution.
Is disabling plugins safe?
It can be useful for testing, but it should be done methodically with backups and notes.