If your website is hacked, contain it immediately: put the site behind a holding page or take it offline, secure every credential you still control, and contact your host. Make a complete off-server backup before you delete or change anything, so you preserve evidence for cleaning, support tickets, or regulator notification.
TL;DR:
- Before cleaning, export the full file system and database separately, save access and error logs, then store labeled copies offline without overwriting earlier backups.
- Choose a rebuild when a backdoor is possible, hosting is shared or ageing, or the entry point remains unknown; restore scanned content only.
- Rotate passwords and API keys, regenerate CMS secret keys and salts to end active sessions, and enable multifactor authentication before bringing the site back online.
- After cleaning every flagged page, request a Search Console review; manual checks can take days to weeks, while some warnings clear on a later crawl.
- If personal information may have been accessed, POPIA requires prompt notice to the regulator and affected people; businesses handling payments also face separate reporting duties.
Table of Contents
- How to confirm you've been hacked: signs to document
- Immediate containment: the first ordered steps to limit damage
- Back up and preserve evidence before you start cleaning
- Wipe and rebuild versus manual cleaning: choosing a path
- Rotate credentials and harden the site to stop reinfection
- How to get Google and browsers to remove hacked warnings
- How a professional team approaches recovery and ongoing care
- Contain first, earn again second
- GridLock Digital emergency cleanup and GridLock Care
- FAQ
- Sources
How to confirm you've been hacked: signs to document
A slow site or a broken plugin is not the same as a breach, so it pays to check before you panic or start deleting files. True compromise usually leaves a trail that visitors, admins, and server logs all show in different ways.
Start with what your visitors see, then move to what only an administrator would notice.
- Browser warnings, unexpected redirects to other domains, or spammy pages appearing in search results.
- Unknown admin users, altered page content, or a changed
.htaccessfile you did not touch. - New scheduled tasks, unfamiliar processes, or files with timestamps that do not match any update you made.
- Flags from Google Safe Browsing or a Security Issues report inside Search Console.
- A
site:yourdomain.comsearch returning pages you never created.
Server and access logs matter here because they tell you when the intrusion started and roughly how, which shapes everything that follows. The Search Console security issues report will often show sample affected URLs, which gives you a starting list of pages to inspect and, later, to prove you have fixed. Screenshot everything as you find it. Once you overwrite a file or restart a process, that evidence is gone.
Immediate containment: the first ordered steps to limit damage
Containment comes before cleaning, every time. The goal in the first hour is to stop the bleeding, protect your visitors, and avoid tipping off an attacker that you are watching.
- Put up a maintenance page or route traffic through a CDN challenge so visitors are not served malware or redirected while you work.
- Change every password you can still access safely: hosting control panel, SFTP, CMS admin, and database.
- If you are locked out of any of these, contact your host immediately. Most hosts have an emergency escalation path for compromised accounts.
- Disconnect payment gateways, APIs, or third-party integrations that could be exposed, and notify those providers that a breach is suspected.
- Suspend any automated email or marketing tools connected to the site so an attacker cannot use them to send spam under your name.
- Record what you find: timestamps, screenshots, suspicious filenames, and any new user accounts.
Pro Tip: Change passwords from a device you know is clean, never from the computer you suspect was used to access the compromised account.
Resist the urge to start deleting suspicious files immediately. A file that looks like malware might also be the only clue to how the attacker got in, and removing it before you have documented it makes a later forensic review far harder. If your site handles customer data, this containment phase is also where you start thinking about notification obligations, which we cover further down.
Speed matters, but order matters more. A site taken offline cleanly and brought back a day later beats a half-cleaned site that gets reinfected within hours because the entry point was never closed.
Back up and preserve evidence before you start cleaning
Before any destructive step, make a complete, labelled copy of the site exactly as it is now. This is not the backup you will restore from. It is the record you will need if a host, a security consultant, or a regulator asks what happened.
- Export the full file system and the database as separate archives, not just the files you think are affected.
- Pull server access logs and error logs covering the period before and after you noticed the problem.
- Store these copies off the server, somewhere read-only, so nothing on the compromised server can touch them.
- Label clearly which backup is the compromised snapshot and which, if any, is a known-clean version from before the attack.
- Never overwrite an existing backup with a new one; keep both until the incident is closed.
According to WordPress's own hacked-site guidance, backing up before you touch anything is a standard first step, precisely because cleaning or restoring too early can destroy the evidence needed to find the actual entry point. Skipping this step is one of the most common reasons sites get reinfected days after a seemingly successful clean.
Wipe and rebuild versus manual cleaning: choosing a path
Once you have contained the damage and preserved a forensic copy, you face a choice: clean the existing installation in place, or wipe the server and rebuild from known-clean sources. Both can work, but they suit different situations.
Wiping and rebuilding is usually the safer route when you suspect a server-level backdoor, when the hosting environment is shared or ageing, or when you simply do not know how the attacker got in. WordPress's guidance explicitly recommends recreating configuration files such as wp-config.php from scratch rather than reusing anything from the compromised install, and restoring only content and media after they have been scanned, never executable files unless they are confirmed clean.
Recovery speed depends heavily on preparation. Sites with recent, automated off-site backups can be restored far faster than those relying on manual, infrequent copies, which is one of the strongest arguments for continuous backups as a standing habit rather than an afterthought.
If you choose to clean manually instead:
- Scan with more than one trusted tool, since no single scanner catches every backdoor.
- Search the database for injected scripts or spam content, not just the file system.
- Remove every unfamiliar file and user account, and verify the integrity of core CMS files against a known-good copy.
- Bring the cleaned site up offline first, test thoroughly, and only then restore content selectively.
- Watch logs closely for several days after going live, since a missed entry point will usually show up again quickly.
Whichever path you take, do not go fully live again until monitoring is in place and you have confirmed the fix holds under normal traffic.
Rotate credentials and harden the site to stop reinfection
A clean file system means nothing if the attacker still has valid credentials or an active session. This is the step most DIY cleanups skip, and it is the reason sites get reinfected within days of a seemingly successful fix.
- Rotate every password: hosting, SFTP, database, CMS admin, and any API keys connected to the site.
- Regenerate CMS secret keys and salts in your configuration files. This forces every active session to log out, including the attacker's.
- Enable multi-factor authentication on all admin accounts and remove any accounts you do not recognise or no longer need.
- Apply the principle of least privilege: give each user only the access their role actually requires.
- Remove unused plugins and themes, apply all pending updates, and set correct file permissions so scripts cannot write where they should not.
- Disable file editing from within the CMS dashboard and put continuous backups and a firewall in place going forward.
Pro Tip: Rotating passwords without regenerating secret keys often leaves an attacker's session valid, so do both in the same sitting rather than one after the other.
Patching the entry vector matters as much as removing the malware itself. A scanner will tell you what is on the site now. It will not tell you how it got there, and without closing that gap, hardening is incomplete.
How to get Google and browsers to remove hacked warnings
Once your site is genuinely clean, you still need to clear any warning that Google or browsers have attached to it, or visitors will keep bouncing off a "dangerous site" message even though the threat is gone.
- Check both the Security Issues and Manual Actions reports in Search Console for the exact URLs Google flagged.
- Fix every affected page, not just the ones listed as examples, since the sample is rarely exhaustive.
- Use the Request Review box to describe what was wrong and what you did to fix it, and be specific and accurate.
- Avoid submitting repeated reviews before you are certain every URL is clean. Repeated false submissions slow things down.
Google's own guidance notes that manual reviews can take days to weeks depending on the issue, while some flags clear automatically on the next crawl once the underlying problem is gone. Keep monitoring Search Console after submitting, rather than assuming silence means success.
How a professional team approaches recovery and ongoing care
We aim to treat a hacked site the same way every time: contain first, then take a full forensic backup, then rebuild from known-clean sources rather than patching around unknown damage. That order protects the evidence you might need and avoids the common trap of cleaning visible malware while leaving the actual entry point open.
- Our approach prioritises containment and a complete backup before touching a single file.
- We generally rebuild from clean, known-good files rather than reusing anything from a compromised install.
- Ongoing care can include patching, monitoring, automated backups, and a response plan for exactly this kind of emergency.
- The focus of hardening includes the conversion paths that matter, forms, booking flows, and contact details, to help ensure recovery does not break the parts of the site that bring in enquiries.
Contain first, earn again second
Recovering a hacked site is not really a technical problem first. It is a triage problem. The instinct to immediately understand everything, every file, every log line, before acting is understandable but costly, because every hour your site sits compromised is an hour of lost trust and lost enquiries.
Contain the damage, then investigate. If you have cleaned a site twice and it keeps coming back, that is the signal to stop and get a proper forensic assessment rather than running a third scan. And if customer data might be involved, keep any public statement factual and limited until you actually know the scope.
— Dylan
GridLock Digital emergency cleanup and GridLock Care
Getting a hacked site back online fast matters, but getting it back online clean matters more, because a half-fixed site just gets hit again. We handle containment, forensic backup, and a clean rebuild as one process, then put GridLock Care in place so the same thing does not happen twice.
- We typically assess, contain, and back up a site before any cleaning begins.
- We rebuild from known-clean sources rather than patching around hidden damage.
- GridLock Care offers services including patching, monitoring, automated backups, and emergency response through a subscription plan.
If your site is down right now or you are not sure where to start, get in touch through GridLock Digital for a rapid assessment and a clear next step.
FAQ
What is the first thing you do when you get hacked?
Contain the site immediately with a maintenance page or offline mode, then change any passwords you can still access safely. Contact your host straight away if you are locked out, before doing anything else.
Why is my website being redirected?
A redirect usually means injected code, often in a theme file, plugin, or the database, is sending visitors to another domain. This is a common sign of compromise and should trigger the containment steps above, including checking Search Console's security issues report.
Can hackers see your screen?
Not through a website compromise alone. A hacked website typically gives an attacker access to files, databases, or admin accounts on the server, not to your personal device, unless separate malware has also infected your computer.
Who is the number one hacker?
There is no verified, agreed ranking of hackers, since the term covers everything from criminal groups to security researchers working legitimately. For a hacked website, who did it matters far less than closing the entry point and rotating every credential.
Do I need to tell customers if my site was hacked?
If personal information may have been accessed by an unauthorised person, POPIA requires notifying the regulator and affected individuals as soon as reasonably possible, with enough detail for them to protect themselves. Payment-related businesses also face separate incident reporting duties under the SARB cybersecurity directive.