The order that saves you a month
Almost everyone treats this as a security job that finishes when the malware is gone. That instinct is correct for about the first six hours and wrong after that. Your developer restores a backup, the site loads clean, everyone exhales — and three weeks later you are still ranking for cheap-tramadol in Google's index, because nothing ever told Google those pages were gone.
Four stages. Do them in sequence, because each one depends on the last being finished.
- Contain. Take the site offline or behind maintenance mode if the malware is serving to users. Rotate everything: hosting panel, FTP and SFTP, database user, CMS admins, and every API key stored in a config file. Delete admin accounts you do not recognise. Then open Search Console and remove any verified owner you did not add.
- Clean. Reinstall the CMS core and every plugin and theme from source rather than patching files by hand. Diff the uploads directory against a known-good backup. Search the database for injected rows — options tables and post content are the usual homes. Patch the vulnerability that let them in, or you are scheduling a repeat.
- De-index. Enumerate every injected URL and serve it a
410(or a404), then submit a temporary removal for the directories involved. This is the stage that gets skipped and it is the one that decides how long the damage lasts. - Request review. Only when the Security Issues or Manual Actions report in Search Console shows an issue, and only once stages one to three are genuinely complete across the whole site. A review requested too early is a fortnight lost.
Finding the full extent, including the pages you cannot see
You cannot de-index a list you do not have, and the list is always longer than the one your developer produces from the file system. Injected pages are frequently generated on the fly from a database table or a single PHP file, so there is no folder of spam to find.
Five sources, in the order they are useful:
- A
site:query on your domain, paged through properly rather than glanced at. Add likely spam terms — pharmaceutical names, gambling terms, replica goods, Japanese or Cyrillic characters — to surface clusters fast. - The Pages report in Search Console. Sort by newest indexed. A hacked site usually shows a step change in indexed URLs on a specific date, which also dates the breach for you.
- The Sitemaps report. Attackers often submit their own sitemap to get thousands of URLs indexed within days. An unfamiliar sitemap file is both a finding and a ready-made list of everything to remove.
- Server access logs. Filter Googlebot hits for 200 responses on paths that were never in your sitemap. This is the most complete list you will get, and it catches URLs no
site:query surfaces. - The URL Inspection tool, on a sample. It shows the rendered page as Google fetched it, which is the only reliable way to see through cloaking.
Why the spam pages keep ranking after the malware is gone
This is the part that surprises founders, and it is not complicated once you see it. Google's index is a copy. When your developer deletes the injected files at 2am, Google's copy of those 4,000 URLs does not change. It changes when Googlebot next crawls them and finds something different.
For a site Google visits often, that is days. For 4,000 URLs on a small business site it visits weekly, it can be a month or more — and crawl is spent in rough proportion to a page's perceived importance, so the spam URLs are frequently at the back of the queue. Meanwhile they keep collecting impressions, keep serving the warning label, and keep counting against you in the review Google eventually runs.
There is a second-order effect worth naming. A few thousand junk URLs indexed under your domain is index bloat with a malicious origin: it spends crawl attention that should be going to your real pages, and it makes your site harder to characterise. Recovery of your own rankings often lags the cleanup by weeks for that reason alone.
So the job is not to delete the pages. It is to tell Google, as loudly and as quickly as the tooling permits, that they are gone.
De-indexing properly: 410, noindex, and what the removals tool is for
Three mechanisms, three jobs, and they are not interchangeable. Getting the combination right is most of the recovery.
The one thing to avoid is blocking the injected paths in robots.txt. It feels decisive and it is exactly wrong: a blocked URL cannot be crawled, so Google never sees the 404, never sees the noindex, and the URL can persist in the index for far longer than if you had done nothing.
- Temporary removals last about six months. They are a blindfold, not a cure. If the
410is not in place when the removal lapses, the URLs can come back. - Remove the attacker's sitemap and resubmit your own. A sitemap listing spam URLs is an invitation to recrawl them, which is occasionally useful and usually not.
- Do not bulk-disavow the links pointing at injected pages. Those links point at URLs that no longer exist. Disavowing them solves nothing and complicates any later conversation about your backlink profile.
| The URL | Serve this | Why |
|---|---|---|
| Injected page that never existed on your site | 410 Gone | A deliberate removal signal. Tends to drop out of the index a little faster than a 404, and both are far better than a redirect. |
| Thousands of injected URLs under one path | 410, plus a temporary removal for the whole directory prefix | The removal hides them from results within about a day while the 410 does the permanent work. |
| A real page of yours with injected content in it | Clean it and leave it live | It has history and links. Removing it throws away the thing you are trying to recover. |
| A real page you cannot clean today | noindex, temporarily | See noindex. Keeps it out of results without discarding the URL. |
| An injected URL you are tempted to redirect home | Do not | An irrelevant redirect is commonly treated as a soft 404, so you gain nothing and you have told Google your homepage relates to the spam. |
The review request that succeeds first time
If Search Console shows a security issue or a manual action, you request a review from that report. Google states plainly that most reconsideration reviews take several days or weeks, and that you should not resubmit while one is outstanding — so a rejected request is not a small setback. It is the difference between recovering this month and recovering next quarter.
Rejections almost always come from the same three causes: one infected file left behind on a subdomain nobody remembered, a staging copy that shares the hosting account, or a request submitted before the cleanup finished because someone wanted the warning gone before a sales meeting.
Write the request as a factual account, not an apology. Four things, in order:
- What the issue was, in one sentence, in Google's own vocabulary — injected pages, injected content, malicious redirect.
- How they got in, named specifically. "An outdated file-manager plugin allowed arbitrary file upload" is a real answer. "We were hacked" is not.
- What you did, listed: core and plugins reinstalled from source, database rows removed, credentials rotated, unknown Search Console owners removed, 4,112 injected URLs now returning 410.
- How you verified it, and what stops it recurring: a clean scan on a stated date, the vulnerability patched, automatic updates enabled, admin access reduced to two people.
The Indian root cause nobody enjoys naming
We have opened enough of these to say it plainly. On Indian shared hosting the cause is nearly always one of two things, and often both at once.
The first is nulled software: a premium theme or plugin downloaded free from a "GPL" reseller or a torrent, with a payload added. It is not a licensing argument, it is a supply-chain compromise, and it arrives already inside your admin folder with permission to write files. The second is an unpatched CMS on a shared cPanel account, where a compromise of any one site under the same user can reach the others.
Neither is exotic and neither is a reflection on your developer's ability. They are the predictable result of a market where hosting is sold at ₹200 a month and a ₹6,000 plugin licence feels avoidable. The maths does not survive one incident: a fortnight of lost rankings on a site that generates leads costs more than a decade of licences.
If you are rebuilding after this, the fixes are unglamorous — licensed plugins, a current PHP version, automatic core updates, a separate hosting account per site, two-factor on the admin, and file-integrity monitoring that emails someone who reads email. And when the site goes back up, treat it as a launch: our pre-launch SEO checklist covers what to verify before the crawler returns.
What recovery actually looks like on the chart
Expect three phases, and expect the middle one to feel like failure.
First, impressions fall further after you de-index — that is the spam URLs leaving the index, and it is the intended outcome even though the graph disagrees. Second, a flat stretch of two to six weeks while Google recrawls your real pages and re-establishes what the site is about. Third, recovery towards the pre-incident baseline, which is usually gradual rather than a step back up.
Full recovery to previous levels is common but not guaranteed, and the honest reason is that nobody outside Google can separate the hack's residual effect from everything else that changed in the interim — a core update, a competitor's new page, seasonality. Anyone quoting you a certain timeline for a certain outcome is quoting a feeling.
One thing worth saying about who pays for this. If the breach traces to unlicensed software an agency installed, or to a hosting account they set up and never patched, that is a conversation about responsibility, not just about invoices — who is liable if an agency gets you penalised sets out how we think that argument should run. And if you are unsure whether what you have is a hack, a manual action or an ordinary core update, diagnosing that correctly is the entire first hour of our penalty recovery work.