The first rule of recovering a hacked site is not cleaning it: it is preserving the evidence before you clean. Files deleted in haste may be the only proof of how the attacker got in — and without that proof, they come back the same way.
Short answer: what do I do if my site is hacked?
The order is: (1) isolate the site and preserve logs, (2) change every credential, (3) restore from a clean backup or remove the malicious code, (4) close the entry route, (5) request a review if a search engine warning is showing. The most common mistake is skipping steps two and four and going straight to cleaning; the site is then re-compromised within days. The lasting fix is not the cleanup but closing the way in.
The first 60 minutes: isolation and evidence
- Put the site into maintenance mode. It stops visitors encountering malicious content and prevents search engines crawling more infected pages. Showing a maintenance page is preferable to taking the site fully offline.
- Copy the logs immediately. Take access and error logs off the server. They can rotate during cleanup or be altered by the attacker.
- Take a full backup of the current state — even infected. It is the only way to investigate later.
- Note file modification times. Recently changed files reveal the timeframe and scope of the attack.
- Delete nothing. At this stage the goal is not cleaning but taking a photograph.
These five steps take about half an hour and determine the quality of everything that follows. Skipped, the question "how did they get in" usually stays unanswered.
Change every credential
- Hosting panel and server credentials — including SSH keys.
- Content management system administrator accounts — delete unknown users, reset known ones.
- Database user password and its counterpart in the configuration file.
- FTP/SFTP accounts — remove unused ones entirely.
- Domain panel — also verify DNS records were not altered.
- E-mail accounts — the administrator address especially, since resets run through it.
- API keys and integration access.
Terminate all sessions too: changing a password may not close one already open.
Cleanup steps
| Step | What is done | Watch out |
|---|---|---|
| 1. Determine scope | Which files changed, which tables were affected | Files alone are not enough; check the database too |
| 2. Restore a clean backup | Return to a verified pre-incident backup | A post-attack backup brings the malicious code back |
| 3. Manual cleanup | Remove malicious code where no backup exists | The riskiest route; one leftover file suffices |
| 4. Refresh core files | Replace system, theme and plugins with clean versions | Customised files need separate review |
| 5. Audit users | Delete administrator accounts added without authorisation | Users may have been inserted directly into the database |
| 6. Audit scheduled tasks | Check cron entries on the server | This is usually how malicious code restores itself |
The sixth row is the most commonly skipped. If a site is cleaned and reinfected the next day, the problem usually lies not in the cleanup but in a leftover scheduled task.
Closing the entry route
- An unpatched component. The most common cause; update the system, theme and every plugin, and remove abandoned ones.
- A weak or leaked administrator password. New passwords must be unique, with two-factor authentication added.
- A file upload flaw. Ensure uploaded files cannot be executed.
- Overly broad file permissions. Writable directories should be as few as possible.
- Another site on the same server. In shared environments infection can spread from a neighbouring account; check them all.
Removing the search engine warning
- Check the security issues section in Search Console. The detected problem type is listed there.
- Complete and verify the cleanup. Check every reported example, not just one sample page.
- Submit a reconsideration request and explain briefly what happened: what was infected, how it was cleaned, how the entry route was closed.
- Wait for the outcome. Review usually takes a few days. A new problem during that time restarts the process.
- If any malicious redirect or spam page remains, the request is refused — which is why completeness matters.
Netişlem expert view: the costliest error is cleaning and moving on
The scenario we see most: the site is cleaned, works again, everyone relaxes, and two weeks later the same thing happens. The cause is almost always identical — the entry route was never closed. Cleaning removes the visible symptom while the vulnerable component or stolen password remains in place. An incident should not be closed until "how did they get in" has an answer.
Our second observation is that backups often turn out useless. A backup exists but its date is unclear; nobody knows when it was last clean. Restoring without establishing when the attack began can reinstate the malicious code. Noting file modification times in the first hours also helps you choose the right backup.
Third, the incident goes untold to customers. If visitor data was affected, a notification duty may arise — covered in our breach notification article. Silence also produces far greater loss of trust if it emerges later.
Preventing recurrence
- Entry route identified and recorded in writing.
- All components updated; unused ones removed.
- All credentials changed and sessions terminated.
- Two-factor authentication enabled on administrator accounts.
- Scheduled tasks audited.
- File permissions reviewed.
- A backup of the clean state taken and a restore tested.
- Monitoring and file change alerting configured — see our monitoring article.
- Search engine warning removed and verified.
- An incident report written (what happened, how they got in, what was done, what changed).
Frequently asked questions
Should I take the site fully offline?
A maintenance page is usually better than full removal: visitors see no malicious content, and search engines read the site as temporarily unavailable rather than gone. Extended full removal can create additional indexing problems.
Is restoring a backup always the answer?
Yes if the backup predates the attack and the data loss since then is acceptable. But where the backup date is unclear or the compromise is long-standing, restoring can reinstate the malicious code. Establish when the attack began first.
Can I remove the malicious code myself?
Possible in simple cases, but risky: a single remaining file or database entry invalidates the cleanup. Restoring a clean backup and refreshing core files is both faster and more reliable than manual removal.
Should I tell my customers?
If personal data was affected, a notification duty may arise. Even where it was not, visitors may have been shown malicious content, so transparent communication is usually the right choice. Silence carries far heavier consequences when it emerges later.
Are my other sites on the same server affected?
In a shared setup, they can be. After an incident, check every site in the account rather than only the compromised one. In isolated setups that risk falls markedly.
Conclusion
Being hacked is not a technical catastrophe but an incident to be managed. Preserving evidence, cutting access and closing the entry route within the first 24 hours makes it a one-off. Skip those three and cleaning becomes a recurring task.
For post-incident investigation and hardening, get in touch. You can review our secure hosting, corporate backup and WordPress hosting solutions.