Finding out your website has been hacked is stressful, especially when customers are seeing warnings, redirects, or broken pages. The first few actions matter.
The goal is to contain the damage, preserve enough information to understand what happened, and bring the site back cleanly.
Do not treat the first hour as a race to make the homepage look normal. A rushed cleanup can destroy useful evidence, restore infected files, or leave the original entry point open.
1. Do not blindly restore the newest backup
Restoring a backup can help, but it can also bring the infection back if the backup was made after the compromise.
Before restoring, identify when the problem likely started. Look at file modification dates, suspicious admin logins, hosting alerts, search console warnings, and customer reports.
If you have multiple backups, compare them. A backup from yesterday may already contain the backdoor, while an older backup may be clean but missing recent orders, form submissions, or content updates. The right restore point depends on both security and business data.
2. Put the site in a controlled state
If the website is redirecting visitors, serving malware, or leaking data, temporarily restrict public access while recovery begins. This protects visitors and reduces reputational damage.
For ecommerce or membership websites, be careful with maintenance mode. You may need to preserve orders, form entries, and customer activity before making large changes.
If the site is actively harming visitors, containment comes first. That may mean blocking public access, disabling a compromised plugin, pausing checkout, or taking a clean static holding page live while the real site is investigated.
If the incident may involve customer data, payment data, or regulated information, document the timeline and involve the right legal or compliance support before deleting logs.
3. Change access credentials
Rotate passwords for hosting, CMS administrators, FTP/SFTP, SSH, databases, email accounts connected to the site, and any third-party services used for deployment.
If possible, add multi-factor authentication. Remove unfamiliar administrator accounts immediately.
Credential rotation should happen from a clean device and a trusted network. If the attacker still has access to email, hosting, or password manager accounts, changing only the CMS password may not help.
Also revoke old API keys, deployment tokens, application passwords, OAuth apps, and unused SSH keys. Many reinfections happen because a non-obvious access path stays open.
4. Clean files and database entries
Malware can hide in theme files, plugin files, uploads, cron jobs, database content, mu-plugins, cache folders, and server config files.
A complete cleanup checks all of these places. Removing only the visible defacement often leaves the backdoor behind.
Search for recently modified files, unfamiliar PHP files in upload folders, encoded payloads, unauthorized cron tasks, injected JavaScript, hidden admin users, and suspicious options in the database.
On WordPress, pay special attention to wp-content/uploads, mu-plugins, theme files, plugin folders, wp-config.php, .htaccess, scheduled actions, and unexpected administrator accounts.
5. Patch the entry point
A clean website can be reinfected if the original weakness remains. Common entry points include outdated plugins, weak passwords, exposed admin panels, nulled themes, vulnerable form handlers, and insecure file permissions.
Recovery should always include root cause analysis and hardening.
Root cause does not always mean one perfect answer, but the recovery team should be able to explain the most likely path: vulnerable plugin, weak credential, exposed panel, insecure file permission, abandoned theme, compromised hosting account, or unsafe custom code.
After the likely path is closed, update software, remove unused components, tighten permissions, add MFA, review admin users, and confirm backups are running.
6. Request review after cleanup
If browsers, Google, security vendors, or hosting providers flagged the site, request a review after the site is clean. Submitting too early can delay removal of warnings.
Before requesting review, scan the site again, check important pages manually, clear infected cache layers, and verify that redirects are gone from both desktop and mobile user agents. Search engines and security vendors may cache old results, but they expect the live site to be clean when they re-check.
7. Monitor closely after the site returns
A recovered site should be watched more closely for a while. Reinfection can happen if a hidden backdoor, stolen credential, or missed scheduled task remains.
For the first few weeks, monitor file changes, admin logins, malware scans, search console warnings, uptime, and form behavior. Keep the maintenance log updated so new suspicious activity can be compared against legitimate fixes.
What to prepare before an incident
The best hacked-site response starts before the hack. Keep a list of hosting, DNS, CMS, registrar, email, analytics, and deployment access. Know where backups live. Know who can approve maintenance mode. Know who communicates with customers if warnings appear.
That preparation turns an emergency from guesswork into a checklist. It also makes it much easier for a recovery team to help quickly.
Recovery is more than getting online
The real finish line is not “the homepage loads again.” It is a clean site, patched entry points, verified backups, and monitoring that can catch suspicious behavior early.
If you are dealing with an active compromise, ViWeb’s website recovery service can help clean the site, close the obvious entry points, and set up monitoring so the same issue is less likely to return.