Quick answer
After a hack, WordPress errors such as 500 errors, white screens, login failures, and database connection problems can be caused by damaged files, malicious code, broken cleanup attempts, overloaded hosting, changed credentials, or security blocks. Start by taking a backup, checking error logs, reviewing recent file changes, and fixing the malware source before treating the error as an ordinary technical bug.
Not every hacked WordPress site shows spam or redirects. Sometimes the first visible problem is that the site breaks. A homepage shows a 500 internal server error. The admin area turns white. The login page redirects. The database connection fails. A host suspends the account because of resource usage. These errors can be frightening because they combine a security problem with downtime.
This guide explains the common WordPress errors that appear during or after a hack, what they may mean, and how to recover without making the damage worse.
500 internal server error after a hack
A 500 error means the server encountered a fatal problem. After a compromise, common causes include broken injected PHP, damaged .htaccess rules, plugin files modified by malware, exhausted memory, missing files, or security tools blocking suspicious execution.
Start with logs. PHP error logs, server logs, and hosting notices can point to the file or rule causing the failure. Then review recently modified files, wp-config.php, .htaccess, active plugins, and the current theme. If the host restricted the account or disabled scripts, check the notice carefully before making changes.
If the outage is connected to hosting enforcement, the hosting suspension recovery service may be relevant. If the domain itself was flagged or suspended, see the domain suspension recovery service.
White screen of death
The WordPress white screen of death usually comes from a fatal PHP error. Malware can cause it when injected code is incomplete, incompatible with the server’s PHP version, or placed in a file that loads on every request. Cleanup attempts can also cause it when legitimate code is deleted along with malicious code.
Do not start by randomly deleting folders. Put the site into a controlled recovery process. Take a file and database backup, check logs, disable suspect plugins methodically, compare WordPress core files with clean originals, and inspect the active theme. If the white screen began immediately after deleting a file, restore from a backup and review the file more carefully.
Login problems and admin lockouts
Login problems after a hack can have several causes. Passwords may have been changed, admin accounts may have been removed, security plugins may have locked users out, the login page may be redirecting, or database user records may have been modified. Attackers may also create their own administrator account and reduce access for legitimate users.
If you regain access, review all administrator accounts immediately. Remove unknown accounts, rotate passwords, and check usermeta records for privilege changes. If suspicious users keep returning, the hidden admin user removal service addresses that pattern.
Database connection errors
Error establishing a database connection can happen when credentials in wp-config.php are changed, the database server is down, the database user is removed, or the server is overloaded. After a hack, also consider whether malware created heavy queries, filled tables with spam, or changed database-related configuration.
Confirm database credentials, check whether the database service is available, and review table sizes. Large spam tables, excessive transients, or suspicious autoloaded options can slow the site or break requests. Do not repair or drop tables without a backup.
Redirect loops and mixed login behavior
Some hacked sites enter redirect loops because of malicious .htaccess rules, forced HTTPS mistakes, changed siteurl values, security plugin conflicts, or injected scripts. If wp-admin redirects to another domain or a fake verification page, treat it as a security issue rather than a normal configuration problem.
Check siteurl and home values, .htaccess, server redirects, cache rules, and plugin-level redirects. Also test with cache disabled where possible. If malicious scripts are involved, see the malicious JavaScript removal service.
How to recover without making things worse
- Take a full backup before editing files or database rows.
- Collect PHP error logs, server logs, hosting notices, and screenshots.
- Identify whether the error began before or after a cleanup attempt.
- Restore clean WordPress core files if core files were modified.
- Disable suspect plugins carefully rather than deleting randomly.
- Review files, database, users, and server rules for malware.
- Patch the vulnerability and rotate credentials after the site is stable.
The official WordPress documentation on troubleshooting WordPress is useful for ordinary errors, but after a hack you also need a security review. Fixing the error without removing the malware can leave visitors and rankings at risk.
When restoring a backup helps
A clean backup can be the fastest way to recover from broken files, but it is not always enough. If the backup already contains the malware, restoring it simply restores the infection. If the vulnerable plugin remains active, the site can be hacked again. If stolen credentials are still valid, attackers can return even after a restore.
Use backups as part of recovery, not as the only recovery step. Restore the cleanest known copy, compare it with current files, patch the entry point, rotate credentials, and monitor for reinfection.
How to separate a normal WordPress error from a hack symptom
A normal plugin conflict usually has a clear trigger, such as an update, new plugin installation, or PHP version change. A hack-related error often appears alongside other signals: unknown files, security warnings, redirects, spam search results, changed users, or hosting abuse notices. The context matters more than the error message alone.
If the error began after a cleanup attempt, review exactly what was changed. Removing malicious code from a file is good, but deleting a required closing bracket or legitimate function can break the site. In that case, restore the affected file from a clean source and repeat the cleanup more carefully.
When in doubt, preserve the broken state in a backup before repairing it. That gives you a fallback and keeps useful evidence available if the same error or infection returns later.
Prevention after errors are fixed
Once the site is back online, remove unused plugins and themes, update everything, enable two-factor authentication, disable direct file editing, review file permissions, and keep offsite backups. Set up monitoring for uptime, file changes, blacklist warnings, and admin account changes.
Those notes also make future troubleshooting faster.
A stable site is not automatically a clean site. If a 500 error disappears after disabling a plugin, still inspect for malware and backdoors. The error may have been only one symptom of a larger compromise.
FAQ
Can malware cause a WordPress 500 error?
Yes. Broken injected PHP, damaged .htaccess rules, overloaded resources, and security blocks can all trigger 500 errors.
Is the white screen of death always malware?
No. It can also be caused by plugin conflicts or PHP errors, but after a known hack it should be investigated as part of cleanup.
Should I restore a backup to fix errors?
A clean backup can help, but you still need to patch the entry point and confirm the backup does not contain the same infection.
Why can I log in sometimes but not always?
Conditional redirects, cache, security plugin lockouts, changed cookies, or database changes can create inconsistent login behavior.