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
Separate public pages, dashboard and shop
Compare representative URLs, devices, login state and time. A fast public cache says little about the editor or cart. Repeat measurements under matching conditions and record a baseline.
02
Separate server response and rendering
Waiting for the first byte points to different causes from late images or blocking scripts. Use the network waterfall and PageSpeed Insights. Distinguish lab tests from available field data from real visitors.
03
Deliver appropriate images and scripts
Check large above-the-fold images, resolution, compression and reserved dimensions. Do not delay a key introductory image with lazy loading. Investigate external scripts and retain only proven improvements without broken functionality.
04
Match caching to website functions
Check existing hosting and WordPress caches first. Multiple similar cache plugins complicate diagnosis. Cart, checkout, accounts and personal content need correct exceptions. Verify sessions, prices and forms after changes.
05
Investigate plugins, database and hosting
What an extension does matters more than the count alone. Examine slow queries, external connections and overlapping backups or imports. Prefer staging for profiling; do not delete database tables or disable background tasks without evidence.
Core Web Vitals: targets for real visits
LCP concerns the largest visible content, INP interaction response and CLS layout shifts. Targets apply to the 75th percentile of real visits, separately for mobile and desktop. Lab tests and a single score do not replace field data.
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.