This guide is for owners of self-hosted WordPress websites. Changes require appropriate access and a safe rollback path. If files, databases and hosting are unfamiliar, coordinate the investigation with your host or maintenance provider.
Record the evidence
Record the affected URL, exact message, first observed time with timezone and latest change. Compare home page, another page and login. Keep a record of previous tests; one failed request does not prove the entire website is down.
Backup and rollback
Before making changes, preserve the current files and database where possible, and retain older backups. Check dates and restoration options. A broken or infected snapshot can matter for investigation; protect it separately and never treat it as a verified clean backup.
Change one thing at a time and repeat the same request. Prefer staging for extensive plugin, theme and configuration tests. Deactivation is not deletion: shop, form and security functions may be affected. Document the starting state, change and rollback.
Focused diagnosis
01
Identify the failing request
Test home page, another page, login and the exact action. Record whether saving, uploading or submitting triggers the error. Before repeating a form or order, check whether it was already processed.
02
Read the relevant error log
HTTP 500 does not identify the cause. Give the host URL, time, timezone and request ID if available. PHP file and line, memory errors and invalid server directives suggest different investigations. Missing entries may mean the wrong log or an upstream service.
03
Review plugin, theme and PHP changes
Compare onset with updates, custom code and PHP changes. Test a clearly suspected component on a copy. Raising a memory limit alone does not explain increasing consumption; investigate the cause and allowed resources.
04
Do not replace server rules indiscriminately
Invalid .htaccess directives can affect Apache. A pure Nginx setup does not read this file. Blind replacement can remove access controls and redirects. Ask the host to identify and examine the specific offending rule.
05
Check permissions and resources properly
Owners, permissions, storage and PHP handling must fit the hosting setup. Applying 777 everywhere is not a repair strategy. After a targeted correction, repeat the original request and then verify other business processes.
Consider restoration carefully
A backup may help but does not replace finding the cause. Examine it in isolation first where possible. Restoring can lose newer orders, enquiries and content. Agree what will be restored; after an attack, do not copy current files into a clean installation without checking them.
Test after the fix
Test the originally affected URL, home page, other pages and login. Check important forms and shop functions in an appropriate test environment without unintended live orders. Clear only relevant cache layers after a targeted fix. Record the result and cause.
When to get support
Stop making changes when the cause remains unclear, rollback is unreliable or business-critical functions are affected. Malware indicators require a security investigation. Full logs, recovery links, passwords and keys do not belong in public forums or unencrypted emails.
Agree scope and costs →Maintenance after repair
WordPress core, plugins and themes are updated weekly, so essential updates do not get left behind in a busy working day. Monthly, daily or hourly: the backup interval depends on your plan. Backups are stored on EU servers.
Repairs and cleaning already hacked websites are separate services. Paid plugin licences are not included.