What to Do If Your Website Gets Hacked: An Emergency First Response Guide

Contain first, clean second

If your website gets hacked, your first job is containment, not cosmetics. You recover faster when you stop the bleeding early, keep the evidence intact, and then remediate with technical integrity.

The failure pattern we see most is panic work that wipes out the clues you need to find the real entry point. Restoring a backup, updating plugins, or “reinstalling WordPress” can look productive while the attacker still has a foothold via a stolen credential, a rogue admin user, a scheduled task, or a server level backdoor.

Step 1: Confirm the scope without tipping the attacker off

Before you touch anything, work out what’s actually compromised and what’s just a symptom. Defacement is obvious. The harder cases are redirects, SEO spam pages, injected scripts, form skimmers, or intermittent malware that only triggers for certain user agents.

Get clarity first, because clarity drives the right containment. Check three places: what visitors see, what your server is doing, and what Google is reporting. Use a clean device and network to test the site. Inspect the HTML output for unexpected script tags, obfuscated JavaScript, and unfamiliar external domains. Review server access logs around the first known bad time. In Google Search Console, look for manual actions, security issues, and spikes in indexed URLs that don’t belong to you.

If you’re on shared hosting and you don’t have access to proper logs, that’s already a constraint. You can still triage, but your ability to prove root cause drops sharply. This is where “it’s fine, we’ll just restore a backup” turns into a repeat incident.

Step 2: Isolate the site (properly) so the damage stops spreading

Isolation stops data loss and blocks lateral movement. The right move depends on what you run and what you’re seeing.

Protect customers first, because trust is part of your infrastructure. If there’s any chance customer data is being captured (checkout, login, enquiry forms), take the site out of service. A maintenance page is better than silently leaking data. For many small businesses, the cleanest containment is blocking public access at the web server or WAF level, while keeping admin access available from a fixed IP for investigation.

Don’t rely on a “maintenance mode” plugin as your only barrier. If the attacker has code execution, they can bypass whatever your CMS is doing. Block at the edge or server. If you have Cloudflare or another reverse proxy, switch to “I’m Under Attack” mode or restrict access by country/IP while you triage. If you don’t, use .htaccess or server config rules, or ask your host to apply temporary restrictions.

Also isolate accounts, because credentials are often the real blast radius. Immediately rotate passwords for hosting, SFTP/SSH, database, CMS admins, and email accounts tied to password resets. If you reuse passwords anywhere else, assume credential stuffing is next.

Step 3: Preserve evidence before you “fix” anything

Evidence reduces guesswork, because it lets you remove the entry point instead of just cleaning symptoms.

Take a full filesystem copy and a database dump before remediation. If you’re on a VPS or cloud instance, snapshot the disk. Export logs if you can. Record timestamps, indicators of compromise, suspicious users, and any changes you make. If you later need to notify customers, insurers, or regulators, you’ll want a clean timeline you can defend.

If you have a managed host offering “one-click malware cleanup”, ask what they actually do. If it’s just file replacement, you still need root cause analysis or you’ll be back here next week.

Step 4: Identify the entry point (or you’re not really cleaning)

Finding the entry point prevents reinfection, because you’re removing the access path rather than repainting over mould. In practice, entry points cluster into a few categories.

Compromised credentials

Look for new admin users, password reset activity, unfamiliar API keys, and logins from unusual geographies. Check FTP/SFTP users too. In WordPress, don’t just check wp_users. Check for rogue code that re-creates admin users on a schedule.

Vulnerable plugins, themes, or outdated core

Line up the compromise window with your update history, because attackers don’t need to “hack you personally” when they can scan the internet for a known vulnerable version. If you’re running abandoned plugins, treat them as untrusted code.

After containment, verify your foundation

Once the site is isolated and you’ve preserved evidence, the next risk is false confidence. A surface level clean can remove the symptoms while persistence remains in scheduled tasks, rogue users, compromised API keys, or server level changes that quietly undermine technical integrity and future discoverability.

That’s why we treat recovery as an infrastructure audit, not a one-off fix. If you want a structured set of checks to confirm root cause, remove footholds, and restore trust signals that support clean citations, see Post Hack Security Audit Checklist: What to Verify Before You Trust Your Site Again.

Backups matter, but only if they’re built for restore

Containment and evidence preservation only work if your recovery path is reliable. A backup is part of your infrastructure, but without immutability, clear scope, and routine restore testing, it can just reintroduce the same compromise and erase the artefacts you need for root cause.

That’s why we treat backups as restore-first infrastructure, with runbooks that prioritise technical integrity and predictable recovery over guesswork. We break that down in Website Backup Strategies for Small Businesses: Restore-First Infrastructure, including how to reduce downtime without trading away discoverability and citations after the incident.

Server-level issues

Server integrity matters, because a CMS clean up can’t fix a compromised host. On poorly configured servers, attackers land via weak SSH credentials, exposed admin panels, writable directories, or insecure file permissions. If you see strange processes, cron jobs you didn’t create, or modifications outside the web root, you’re likely beyond a simple CMS clean up.

Supply chain and injected scripts

Third-party scripts widen the attack surface, because an attacker can piggyback on what you already load. Tag managers, ad scripts, live chat widgets, and CDN assets can be abused. If your site output includes third party scripts, verify they’re loading from the expected domain and haven’t been swapped. Payment skimmers often hide here because they don’t need to touch your server files much.

Step 5: Clean with a “known good” baseline, not patchwork

A known good baseline restores trust, because you’re rebuilding from verified components instead of guessing what’s safe. Once contained and backed up, clean in a way you can validate. That usually means replacing core CMS files with pristine versions, reinstalling themes and plugins from verified sources, and manually reviewing anything custom.

Don’t keep unknown PHP files “because the site still works”. Attackers hide in places that look routine: mu-plugins, cache directories, image folders with .php files, or files with near identical names to legitimate ones. Search for common indicators like eval, base64_decode, gzinflate, preg_replace with /e, long obfuscated strings, and unexpected outbound connections.

Database infections are easy to miss, because the site can look fine while the payload lives in content. Check for injected JavaScript in posts, options tables, widgets, header/footer fields, and SEO plugin settings. If you’re seeing redirects only on mobile, check for conditional logic based on user agent or referrer.

If you’re deciding whether to repair or rebuild, the deciding factor is trust in the foundation. When the compromise touches core server integrity, a rebuild is frequently faster and safer than trying to disinfect a system you can’t verify. This is the same judgement call we outline in when to rebuild instead of repair your website.

Step 6: Restore service in a controlled way

A controlled restore reduces risk, because you’re watching for repeat behaviour instead of assuming it’s gone. Bringing the site back online is not a single switch. It’s a rollout with monitoring.

Before you remove restrictions, verify file integrity, confirm no unexpected admin users exist, and ensure outbound traffic looks normal. If you can, run the site in a staging environment first and compare behaviour. Then re-enable public access and watch logs in real time for repeated exploit attempts, 404 scanning, and suspicious POST requests.

After a hack, your discoverability can take a hit because search engines may flag the site, deindex spam URLs, or cache malicious content. Clean-up includes getting your citations back on track by removing injected pages and confirming canonical URLs are correct. If you want the broader infrastructure view of how machines interpret your site, Designing a Website Ecosystem (Not Just Pages): Infrastructure for Discoverability is the right mental model.

Step 7: Close the doors that were left open

Closing the doors prevents a second incident, because attackers come back when the original access path still works. This is where most “clean up” jobs quietly fail.

Rotate all secrets again after cleaning, not just before. Enable MFA on hosting, email, and CMS admin accounts. Remove unused plugins, themes, users, and API keys. Lock down file permissions so the web server can’t write where it shouldn’t. Disable XML-RPC if you don’t need it. Add rate limiting and bot protection at the edge.

Backups are part of your security foundation, because a backup you can’t restore is just stored risk. Test restores. Keep offsite copies. If you’ve never validated a restore under pressure, you don’t really have a backup plan. The operational side of this is covered in Backup Security: Why Restores Matter More Than Backups.

Step 8: Handle notifications and compliance like an adult system

Compliance protects the business, because obligations don’t disappear just because the incident is messy. If personal information may have been accessed, you have obligations. In Australia, the Notifiable Data Breaches scheme can apply depending on the type of data and harm risk. Even when it’s not legally notifiable, you still need to make sensible calls about customer communication, password resets, and fraud monitoring.

Don’t guess. Document what happened, what data was involved, and what you’ve done to prevent recurrence. If you take payments, talk to your payment provider about required steps. If email accounts were compromised, assume password resets and invoices could be targeted next.

What “wrong fixes” look like in the real world

Restoring a backup from last week while leaving the same admin password in place. Cleaning visible malware while ignoring a rogue cron job that reinfects every hour. Paying for a scanner report that lists symptoms but never identifies the entry point. Leaving the site online because “we can’t afford downtime”, then discovering later that enquiries were being silently forwarded to a third party.

The consistent theme is poor algorithmic alignment between what you think is happening and what the system is actually doing. A hacked site is an infrastructure problem first. Treat it like one and the rest becomes a lot less chaotic.

When you should escalate

Escalation restores system trust, because some compromises are bigger than a basic clean up. If you see signs of payment skimming, unauthorised admin creation, server level compromise, or repeated reinfection after cleaning, escalate to a proper incident response approach. That means deeper log analysis, integrity checking, and sometimes rebuilding onto a clean foundation with hardened controls. The goal is not to get the homepage looking normal. The goal is to restore trust in the system.

About the Author

Nicholas McIntosh

Nicholas McIntosh is a digital strategist driven by one core belief: growth should be engineered, not improvised. 

As the founder of Tozamas Creatives, he works at the intersection of artificial intelligence, structured content, technical SEO, and performance marketing, helping businesses move beyond scattered tactics and into integrated, scalable digital systems. 

Nicholas approaches AI as leverage, not novelty. He designs content architectures that compound over time, implements technical frameworks that support sustainable visibility, and builds online infrastructures designed to evolve alongside emerging technologies. 

His work extends across the full marketing ecosystem: organic search builds authority, funnels create direction, email nurtures trust, social expands reach, and paid acquisition accelerates growth. Rather than treating these channels as isolated efforts, he engineers them to function as coordinated systems, attracting, converting, and retaining with precision. 

His approach is grounded in clarity, structure, and measurable performance, because in a rapidly shifting digital landscape, durable systems outperform short-term spikes. 


Nicholas is not trying to ride the AI wave. He builds architectured systems that form the shoreline, and shorelines outlast waves.

Connect On LinkedIn →