Triage & containment
Severity classification, credential resets, removal of rogue users, and isolation of infected files before they spread.
SOSemergency website support
Emergency website support for your server and your search results.
Site down, hacked or flagged by Google? Our emergency website support runs two recoveries at once. We contain, clean and patch the site, and we clear what the attack left behind in Google, from spam URLs in the index to Security Issues in Search Console.
- site + search recovery
- forensic backup first
- written incident report
- alert: hacked-content warning in Search Console
- site track: triage, forensic backup, contain, clean and patch
- search track: Security Issues, spam URLs to 410, owner and sitemap audit, review request
two tracks, one incidentevidence keptgoogle sets review timing
is this an emergency?
Pick what you're seeing. Get the first three moves.
Panic makes incidents worse. Most damage after a hack comes from rushed restores and deleted evidence. Start here, then bring us in.
critical
The site is down or showing errors
// do this now
- Check whether it's down for everyone: try mobile data or another network.
- Write down the exact error message or code, and when it started.
- Don't reinstall or restore anything yet. Changes can erase the evidence of what failed.
// what we check
- Server, DNS and SSL certificate status
- Recent deploys, updates and config changes
- Error logs and resource limits
- Whether Googlebot is receiving 5xx errors
critical
Google or Chrome warns it's hacked or deceptive
// do this now
- Don't delete files at random. Note what you see and when you first saw it.
- Change hosting, CMS and email admin passwords from a clean device.
- Open Search Console and check Security Issues and Manual Actions.
// what we check
- Malware, backdoors and rogue admin users
- Injected pages and malicious redirects
- Search Console owners you didn't add
- Safe Browsing status once the site is clean
high
Strange pages in Google
// do this now
- Search site:yourdomain and screenshot the pages you don't recognise.
- Don't block the spam URLs in robots.txt. Google then can't see that they're gone.
- Look in Search Console for sitemaps and verified owners you don't know.
// what we check
- Where the pages come from: files, database or cloaking
- A full inventory of injected URLs
- 404 or 410 responses for every spam URL
- Rogue sitemaps and verified owners
high
Organic traffic fell off a cliff
// do this now
- Line the drop date up against releases, plugin updates or hosting changes.
- In Search Console › Pages, look for a jump in "Excluded by noindex" or "Blocked by robots.txt".
- Check Manual Actions and Security Issues.
// what we check
- Robots.txt, meta robots and canonical changes
- Rendering: is the content still in the HTML?
- Redirects and status codes on money pages
- Manual actions and security flags
high
Forms or checkout stopped working
// do this now
- Place a test enquiry or order and note the step where it fails.
- Check whether form or order notifications are still arriving.
- Pause paid campaigns that send traffic to the broken step.
// what we check
- Recent plugin, theme or payment-gateway updates
- JavaScript and server errors on the failing step
- Email delivery and connected integrations
- Tracking and conversion events
Seeing more than one of these? Treat it as one incident: they usually share a cause.
Get emergency help →definition
What is emergency website support?
Emergency website support is rapid, hands-on help when a website is down, hacked, infected with malware or suddenly losing its search visibility. Good emergency work does four things in order: preserve the evidence, stop the damage, close the way in, and restore trust. For any business that depends on organic traffic, that last step includes Google: removing injected spam pages from the index, resolving Search Console security issues and requesting a review once the site is clean.
- Covers
- Outages, hacks, malware, malicious redirects, deindexing and broken checkouts
- Runs as
- Two tracks in parallel: site recovery and search recovery
- First step
- A forensic backup, taken before anything is changed
- Ends with
- A written incident report: cause, fix, evidence and prevention
warning signs
Signs a hack has already reached Google.
Tap any that match. They go straight into your incident brief, so you can describe the problem once.
Tap anything that sounds familiar.
Send these to our team →what we do
Hacked website repair, start to sign-off.
Every incident gets the same disciplined sequence, scaled to what we find.
Malware & backdoor removal
Infected files, database injections and hidden backdoors removed, or a clean restore from a verified backup.
Root cause & patching
We find the way in, whether a plugin, theme, core version, credential or server component, and close it.
Search cleanup
An inventory of injected URLs, 404 or 410 responses for every spam page, and an audit of sitemaps and Search Console owners.
Review requests
Once the site is verifiably clean, we request a review for Security Issues or manual actions and track them until they clear.
Incident report
What happened, what we changed, the evidence, and a prevention plan your team can act on, or that we can run for you.
search recovery
Most cleanups stop at the server. The damage doesn't.
A clean server can still have hundreds of spam pages indexed under your name. Here's where a search-aware recovery goes further.
search footprint: left behind
ScopeThe server and the files on itThe server, the files and everything Google indexed while you were compromised
Spam URLsLeft in the index, still ranking for junk termsInventoried from crawls, logs and site: searches, then served 404 or 410
Search ConsoleNot checkedSecurity Issues, Manual Actions, verified owners and sitemaps all audited
BackupsRestored straight over the evidenceForensic copy first, then a restore only from a verified clean point
Root causeUnknown, so reinfection is likelyEntry point found, patched and documented
AfterwardsAn invoiceAn incident report and a prevention plan
incident playbook
Five steps, in this order.
Order matters in an incident. Restore before you understand the cause and you'll likely be back here next month.
- 01
Triage
Confirm the symptoms, the severity and the access we need, then take a forensic backup before touching anything.
→ severity and plan agreed - 02
Contain & restore
Stop the damage: lock out the attacker, remove the infection or restore a verified clean copy, and get a safe site serving.
→ clean site live - 03
Root cause & patch
Trace the entry point through logs and file changes, then patch or replace the vulnerable component.
→ the way in, closed - 04
Search recovery
Clear the index footprint, fix Search Console issues and request a review. Google sets the timing from there.
→ review submitted - 05
Monitor & report
Watch for reinfection and for warnings clearing, then hand over the incident report and prevention plan.
→ incident report
tooling
What we work with in an incident.
// search
Search Console Security IssuesManual ActionsURL InspectionSafe Browsing statusScreaming Frog
// detection
Server-side malware scannersSucuri SiteCheckWordfenceFile integrity diffs
// forensics
Access & error logsDatabase auditsWP-CLIGit history
// hardening
Cloudflare / WAF2FALeast-privilege accessUptime monitoring
what drives the cost
What does emergency repair cost?
Four things decide the size of the job. Set them to see what kind of recovery you're facing.
after the fire
Make sure it doesn't happen twice.
SUP
Website support & management
Ongoing monitoring of uptime, security and search health in one plan.
Explore → WPMWordPress maintenance
Staged updates and plugin audits that close the most common way in.
Explore → HSTManaged hosting
If the server was the weak point, move to an environment that's watched.
Explore → ENTEnterprise development support
For complex platforms that need a standing team and release guardrails.
Explore →faq
Emergency support questions.
It depends on coverage hours, whether you're already on a support plan, and how quickly we can get access. Having hosting, CMS, DNS and Search Console logins ready makes the biggest difference. Agree response targets in writing before work starts, not from a sales page.
Only after the site is verifiably clean and a review has been requested in Search Console. Google controls the review timing, which varies by issue type. Our job is to make sure the request succeeds the first time.
It can. Spam pages dilute the site, browser warnings cut clicks, and a hacked-content manual action can demote pages. A fast cleanup that also removes injected URLs from the index limits the lasting damage.
Only if the backup predates the infection and the vulnerability is patched too; otherwise reinfection is likely. A restore also does nothing about spam URLs Google has already indexed. That's why we take a forensic copy first and run search recovery alongside.
It depends on the severity, the size of the site, how many sites on the server are affected and whether clean backups exist. One-off incidents usually cost more per hour than planned support, and ongoing plans can include incident handling.
Most incidents we handle involve WordPress and other common CMSs on mainstream hosts, but the method of evidence, containment, patching and search recovery applies to any stack. We'll tell you up front if a platform needs a specialist.
Keep everything updated, remove unused plugins and accounts, enforce two-factor authentication, use a web application firewall and keep tested off-site backups. Ongoing monitoring then catches problems before Google or your customers do.
incident open?
Tell us what's broken. We'll start with the evidence.
Send the affected domain. We'll confirm severity, the access we need and the first steps, before anyone touches a file.
forensic backup first · site and search recovery · written incident report