A hacked website is not only a cleanup task. It is an incident that can affect customer trust, search visibility, email reputation and business continuity. The first goal is to contain the problem without destroying evidence or making recovery harder.
Confirm the symptoms before changing anything
Record the affected URLs, time, device, browser and whether the issue appears for logged-in users, visitors or search-engine traffic. Malicious redirects are often conditional, so a single clean visit does not prove the site is safe.
Capture screenshots and preserve recent server, access and security logs. Avoid installing several security plugins at once because each change can overwrite timestamps and make the original entry point harder to identify.
Contain access and protect customer data
Reset administrator, hosting, database, FTP and control-panel credentials from a clean device. Remove unknown administrator accounts and revoke unused API keys, application passwords and deployment tokens.
If checkout, customer accounts or personal data may be affected, temporarily disable the risky function while keeping a clear status page available. The business should know which services are paused and why.
Create a forensic backup before cleanup
Take a full copy of files and the database before deleting anything. This backup is not for restoring the infected site; it is evidence that allows later comparison and identification of altered files.
Store the copy outside the compromised server. Include configuration files, cron jobs, web-server rules, database users and any unusual files in upload or cache directories.
Identify the entry point, not only the visible payload
Compare core, theme and plugin files with trusted versions. Check recently modified PHP files, hidden administrator users, injected database options, scheduled tasks, writable directories and modified .htaccess or server configuration.
The visible redirect may be only the payload. Common entry points include abandoned plugins, leaked credentials, vulnerable themes, exposed staging sites and weak hosting accounts. Removing the payload without closing the entry point usually leads to reinfection.
Rebuild from trusted components
Replace core files and extensions with clean packages from trusted sources. Restore only verified uploads and content, then scan the database for injected scripts, unfamiliar domains and hidden links.
Do not simply restore the newest backup unless its date is known to be before the compromise. A clean rebuild with selective content restoration is often safer than copying the same unknown state back online.
Test the repaired website like a customer
Check desktop and mobile pages, forms, login, checkout, payment callbacks, order emails, redirects and search-result landing pages. Test with a logged-out browser and from more than one network.
Monitor logs and file changes for several days after restoration. A recurring file or outbound request is evidence that persistence remains.
Document the incident and prevent recurrence
Record the timeline, entry point, affected components, credentials changed, files replaced and tests completed. This becomes the reference for future maintenance and client communication.
Add least-privilege access, staged updates, off-server backups, login protection, vulnerability monitoring and a clear incident contact. Security is a process, not a one-time scan.
