Since the PHP2Shell news broke, the question I keep hearing from business owners is: “If my site got hacked, are my Google rankings gone for good?” Many people believe a hack is a permanent black mark, that Google remembers it forever and the site never ranks again. That is not how it works.
In most cases, rankings come back once the site is properly cleaned, the hole is closed and Google has checked your work. What slows recovery down is a half-finished cleanup: spam pages left in the index, a backdoor nobody found, or a review request sent too early. Let me explain the whole process in plain words, in the order I would do it.
In brief: contain, patch, clean, de-index, request review, then rebuild. This guide walks through each step with the exact tools Google gives you, the status codes to use, realistic timelines and a worked example. If you are not sure yet whether you were hacked at all, start with my checklist of 12 SEO warning signs of a hacked site and come back here.
Why a hacked site loses rankings, and why most of them come back
A hack hurts SEO in a few different ways at the same time. Attackers add spam pages (often thousands of them), slip hidden links into your real pages, or redirect visitors to scam sites. Google then does what it is supposed to do: protect searchers. It may show a “This site may be hacked” label next to your results, show a red Safe Browsing warning in Chrome, or list a problem in the Security issues report in Search Console. I covered those warnings in detail in what PHP2Shell can cost you in Google.
Google’s own definition is simple:
“Hacked content is any content placed on a site without permission, due to vulnerabilities in a site’s security.”
— Google Search Central, Spam policies for Google web search
Notice the wording. Google treats hacked content as something done to you, not by you. That is why the path back is mostly technical: remove what the attacker added, prove it is gone, and give Google time to recrawl. Your real pages, your backlinks and your history are still there, waiting.
The ranking loss usually comes from three places:
- Warnings that scare clicks away. Even if your position holds, fewer people click a result labeled as hacked.
- Index pollution. Thousands of spam URLs eat crawl attention and can push your real pages out of view for your own brand name.
- Damaged pages. Injected links, cloaked text or redirects make your best pages look spammy or unsafe.
Fix all three and you remove the reasons for the drop. If your site was also caught up in a Google spam update at the same time, that adds another layer, which I explain in recovering when a hacked site gets caught in a spam update.
The first 24 hours: contain the damage without hurting SEO further
When you first discover a hack, the instinct is to start deleting files. Please don’t, not yet. The first job is to stop the harm to visitors and to stop the attacker from doing more.
Google’s guide on quarantining a hacked site recommends taking the site offline and serving a 503 status code (which means “temporarily unavailable”) from a clean place outside the infected files. It also explains why a quick fix inside the hacked site is not enough:
“Having your site return a 4xx or 5xx HTTP status code isn't enough to protect your users.”
— web.dev (Google), Quarantine your site
The same page says that taking a site offline for a short time is unlikely to hurt future rankings. That matches Google’s crawling documentation: server errors make Googlebot slow down, and indexed pages are only dropped if errors continue for a long time. So a planned 503 for a day or two is a much smaller risk than leaving a malware page live.
Here is the order I suggest for day one:
- Put the site in maintenance mode from outside the hacked files. Ask your host to serve a 503 page at the server or CDN level. A maintenance plugin running inside a hacked WordPress install is not a safe wall.
- Tell your host. On shared hosting, the attacker may have reached other accounts, and the host may already be seeing the same pattern.
- Make a copy of the infected site before changing anything. Files plus a database dump, clearly labeled “infected.” You will need it to compare against later.
- Change every password. Hosting panel, FTP/SFTP, database, CMS admin users, email accounts tied to the site, and API keys. With PHP2Shell, Wiz says memory disclosure can leak secrets, so treat stored keys as exposed.
- Remove users you didn’t create. Check CMS admin users and the list of owners in Search Console.
- Check for personal data exposure. If customer data may have leaked, Google’s cleanup guide suggests reviewing your legal and business obligations before you delete evidence.
Do not use robots.txt as an emergency brake. Google points out that a robots.txt block only stops search crawlers, while real visitors can still reach the harmful pages.
Closing the hole: patch PHP first, then everything that runs on it
If you clean a site without fixing how the attacker got in, you are just tidying up for the next visit. Google’s “This site may be hacked” help page says it directly: fix the vulnerability, or the site is likely to be reinfected.
For PHP2Shell, the fix is a PHP update. As of October 23, 2026, here is what is confirmed. The PHP project released security updates on October 21, 2026 that fix two critical issues, CVE-2026-109618 and CVE-2026-109619. The PHP announcement says both can “allow unauthenticated remote code execution,” which means an attacker could run their own code on your server without logging in. Wiz Research, which reported the bugs, is clear about what counts as a fix:
“Applying the PHP security update remains the only complete remediation.”
— Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
| PHP branch | Patched version (Oct 21, 2026) | Notes |
|---|---|---|
| 8.5 | 8.5.12 | Current branch |
| 8.4 | 8.4.27 | Supported |
| 8.3 | 8.3.36 | Supported |
| 8.2 | 8.2.35 | Reaches end of life on December 31, 2026 |
| 8.1 and older | No official release | Ask your host or Linux vendor about backported fixes, or upgrade |
Source: php.net 2026 news archive. Check it again before acting, as versions can change quickly during an incident.
How to apply this depends on your hosting:
- Shared or managed hosting: open a ticket and ask, in writing, “Which PHP version is my site running, and does it include the October 21, 2026 security fix?” Don’t accept “we are looking into it” as an answer.
- VPS or your own server: update PHP through your package manager or vendor, then restart PHP-FPM or your web server so the new version is actually in use.
- Can’t patch today: Wiz lists web application firewall (WAF) mitigations from vendors such as Cloudflare, Fastly, Google and AWS. A WAF filters bad requests before they reach your site. Treat it as a bridge, not a fix.
Then update the rest of the stack: CMS core, every plugin and theme, and any custom code. Google’s guide on identifying the vulnerability lists outdated software, weak or reused passwords, infected admin computers, open redirects and SQL injection as the usual suspects. A site can have more than one, so keep checking even after you find the first.
Cleaning injected pages, code and redirects
Now you clean. The best option depends on your backups. Google’s cleanup guide describes three situations:
- Clean, recent backup: restore it, update everything, fix the vulnerability, change passwords again.
- Clean but old backup: restore it, then compare it with your “infected” copy and carefully move across only real content added since (new blog posts, orders, form entries).
- No clean backup: work on a copy, not the live server. Remove or repair modified files, fix loose file permissions, clean hacked database records, and make hacker-created URLs return 404.
One step people skip: Google suggests a fresh install of the CMS, plugins and themes rather than an in-place upgrade, because upgrades can leave infected files behind. On WordPress, that means downloading clean copies and replacing the core folders, not just clicking “update.”
Spam hacks also hide. Google’s guide on the Japanese keyword hack warns:
“Hackers will try to trick you into thinking the page is gone or fixed when it's still hacked.”
— web.dev (Google), Fix the Japanese keyword hack
This is called cloaking: the hacked code shows spam to Googlebot but a normal page to you. So always check pages with the URL Inspection tool in Search Console, which shows what Google sees. Here is where each type of hack tends to hide:
| Search Console label | What it looks like | Where to look | Cleanup action |
|---|---|---|---|
| Hacked: URL injection | New spam pages, often in Japanese, pharma or casino niches | Database posts, new folders, rogue sitemaps, rewrite rules in .htaccess | Delete the pages, return 404/410, remove rogue sitemaps |
| Hacked: Content injection | Hidden links or text added to your real pages | Theme files, post content, widgets, footer code | Clean the page, keep the URL live with status 200 |
| Hacked: Code injection | Redirects, crypto miners or scripts on your pages | JavaScript files, header/footer code, database options, .htaccess | Replace files with clean copies, remove the scripts |
| Hacked: Malware | Pages that try to install harmful software | Uploaded files, plugin folders, unexpected PHP files in upload directories | Remove files, reinstall from clean sources, scan again |
A few specific checks I would not skip:
- Look at every .htaccess file, not just the main one. Replace each with a clean default.
- Search the uploads folder for
.phpfiles. Image folders normally shouldn’t contain PHP. - In Search Console, under Settings, then Users and permissions, remove owners you don’t recognize, and remove their verification file or tag so they can’t come back.
- Open your sitemaps and delete any you didn’t create. Attackers often submit their own sitemap full of spam URLs. My guide to XML sitemaps explains what a clean one should contain.
- Test as a mobile visitor arriving from Google. Some hacks only redirect phones, or only visitors coming from search results.
Getting spam URLs out of Google’s index
Once the files are clean, the spam pages may still sit in Google’s index for weeks. This is the part that most affects how quickly your real rankings recover, so it is worth doing carefully.
The key decision is per URL type. Pages the attacker created should disappear. Your real pages that were damaged should stay live and be recrawled. Mixing these up is a common way to lose good traffic.
| Method | What it does | Use it for | Watch out for |
|---|---|---|---|
| 404 or 410 status | Google removes previously indexed URLs when it recrawls them | All hacker-created pages | Google treats all 4xx codes (except 429) the same, so 410 is not a magic speed boost |
| Removals tool (temporary) | Hides URLs from Google results for about six months | Visible, embarrassing spam pages and URL prefixes | Does not remove anything permanently; pair it with a 404/410 |
| noindex tag | Keeps a reachable page out of the index | Rarely needed after a hack | Spam pages should not exist at all, so a 404 is cleaner |
| robots.txt disallow | Stops crawling, not indexing | Not recommended for spam removal | Google can’t see the 404 if it can’t crawl the URL, so spam can linger |
| URL Inspection, Request indexing | Asks Google to recrawl a single URL | Your cleaned important pages | Daily quota; use it for key pages only |
The Removals tool is useful, but Google’s cleanup guide is firm about its limits:
“URL Removal is only for pages you'll never want to appear in results.”
— web.dev (Google), Clean and maintain your site
If the spam lives in one folder or pattern, the Removals tool’s “Remove all URLs with this prefix” option can hide them in one request. Google’s help page notes this covers both http and https and both www and non-www versions, but not subdomains. Be careful: a prefix like /p would also hide /pricing/.
A practical routine I suggest:
- Export a list of spam URLs from the Performance report (filter by odd queries or pages), the Page indexing report and your server logs.
- Check a sample with a crawler or a header checker to confirm they now return 404 or 410, for Googlebot too.
- Submit prefix removals for any clear spam patterns.
- Submit a clean sitemap with only your real URLs, and use URL Inspection to request indexing of your most important cleaned pages.
- Watch the count of indexed pages fall back toward your real number over the following weeks.
Don’t worry if Search Console shows a big jump in “Not found (404)” URLs. That is exactly what you want here. My guide on finding and fixing 404 errors explains when 404s are harmless and when they are a problem.
Asking Google to review your cleaned-up site
Warnings like “This site may be hacked” don’t disappear on their own. You remove them by requesting a review once the whole site is clean. Google’s Security issues help says the sample URLs it shows are not a complete list, and fixing only some pages won’t restore your visibility.
Which button you press depends on where the problem appears:
| Where you see the problem | Where to request review | Typical processing time (per Google) |
|---|---|---|
| Security issues report: hacked with spam | Security issues report, “Request review” | Up to several weeks |
| Security issues report: malware | Security issues report | A few days |
| Security issues report: phishing / deceptive pages | Security issues report (optionally the Safe Browsing error report) | About a day |
| Manual actions report (for example, site abused with third-party spam) | Manual actions report, “Request review” | Several days or weeks |
Times come from Google’s Request a review guide and Manual actions report help. Google’s review guide adds that once a site is found clean, browser and search warnings are removed within 72 hours.
A good review request does three things: it names the problem, explains what you did, and shows the result. Keep it factual. For example:
- The problem: “Attackers used an outdated PHP version to create about 3,000 spam pages under /shop-jp/ and add a redirect script to our theme.”
- What we did: “Updated PHP to a patched version, reinstalled WordPress core, plugins and theme from clean sources, removed the script, deleted the spam pages, removed an unknown Search Console owner and rogue sitemap, and reset all passwords.”
- The result: “All spam URLs now return 404. Homepage and sample pages checked with URL Inspection show clean HTML.”
Before you submit, test your homepage and a few formerly hacked URLs with URL Inspection, and make sure none of them is blocked by robots.txt or noindex. And then wait. Google’s help page asks owners not to resubmit while a request is pending, as repeat requests can slow things down.
A worked example: a 120-page clinic site hit by URL injection
Let me make this concrete with a hypothetical example. The numbers are illustrative, not from a real client.
A dental clinic runs WordPress on shared hosting with an unpatched PHP version. It normally has 120 indexed pages and gets about 2,400 organic clicks a month, mostly from local and brand searches. After an attack, the Page indexing report shows 3,100 indexed pages, the Performance report shows impressions for Japanese brand-name queries, and a “This site may be hacked” label appears under the brand result. Clicks fall to around 900 a month.
Here is how the recovery could run:
- Day 1: host serves a 503 page; PHP is upgraded to the patched release on its branch; all passwords and API keys are changed; an unknown Search Console owner is removed.
- Days 2 to 3: the site is restored from a clean backup from before the attack; two new blog posts written since are copied across by hand; core, plugins and theme are freshly installed; a rogue sitemap and two altered .htaccess files are removed.
- Day 4: the 2,980 spam URLs, all under one folder, return 404; one prefix removal request hides them; a clean sitemap with 120 URLs is submitted; the 20 most important pages are requested for indexing.
- Day 5: review request sent from the Security issues report.
- Weeks 2 to 4: the review is approved, the label disappears, and the indexed count slowly drops toward 120.
In a case like this, I would expect brand traffic to return first, as soon as the warning goes, and non-brand rankings to follow as Google recrawls the clean pages. I treat that as a direction, not a promise. Every site and every hack is different, and Google doesn’t publish a recovery formula.
How long ranking recovery takes, stage by stage
This is the question everyone asks, and the honest answer is: it depends on how fast you clean and how big the mess was. What I can give you is the timing Google publishes for each piece, plus what usually controls the rest.
| Stage | What controls the timing | Published guidance |
|---|---|---|
| Containment and patching | You and your host | Hours to a couple of days |
| Cleanup | Backup quality and size of the site | Google calls damage assessment one of the longer parts of recovery |
| Security review | About a day (phishing), a few days (malware), up to several weeks (spam) | |
| Warnings removed | Within 72 hours of a site being found clean | |
| Spam URLs dropping out | How often Google recrawls them | Removed when recrawled with a 4xx; Removals tool hides them for about six months meanwhile |
| Rankings returning | Recrawl of clean pages, links, competition | No fixed timeline published |
Things that make recovery slower:
- A backdoor left behind, which leads to reinfection and a second review.
- Spam URLs still returning 200 (often a “soft 404” that looks like an error page but isn’t).
- Deleting good pages by mistake during cleanup.
- Months of delay before anyone noticed the hack.
If a broad Google update lands during your recovery, read the drop with care. My guide on diagnosing a core update drop in Search Console helps you tell the two apart.
Hardening your site so the cleanup sticks
PHP2Shell is a reminder that you can do everything right on your website and still be exposed through the software underneath it. Fortune reported on October 21, 2026 that Palo Alto Networks counted 22.6 million potentially vulnerable instances, and that Cloudflare saw tens of thousands of exploit attempts within 45 minutes of the news. Those are reported figures, but they show how quickly attackers move now.
Here is a short hardening plan, based on Google’s maintenance advice:
- Know your PHP version and who is responsible for updating it. Put it in writing with your host.
- Automate backups and keep some copies off the server, with at least a few weeks of history. A backup from yesterday may already be infected.
- Delete unused plugins and themes. Deactivated code can still be attacked.
- Use strong, unique passwords and two-factor login for hosting, CMS and Search Console.
- Keep admin computers clean. Google lists an infected admin device as a common way in.
- Turn on Search Console email alerts and check the Security issues report monthly.
- Consider a WAF in front of your site for faster protection during the next emergency.
HTTPS alone won’t stop a hack, but it is part of the same trust picture. My guide on HTTPS and SEO covers that side, and the beginner lesson on HTTPS and website security for SEO explains the basics if you are new to this.
Questions owners ask about recovering rankings after a hack
Will Google penalize my site forever because it was hacked?
No. Google treats hacked content as something placed on your site without permission. Once the site is clean and reviewed, warnings are removed. Rankings usually return as Google recrawls your clean pages, though there is no published timeline.
Should I use 404 or 410 for spam pages?
Either works. Google’s documentation says all 4xx errors except 429 are treated the same, and previously indexed URLs are removed when recrawled. Pick one and apply it consistently.
Will taking my site offline for a day hurt my rankings?
Google’s quarantine guide says a temporary offline period is unlikely to hurt future rankings. Use a 503 status served from outside the hacked files, and keep the downtime short.
How long does a Search Console security review take?
Per Google, phishing reviews take about a day, malware reviews a few days, and hacked-with-spam reviews up to several weeks. Don’t resubmit while a request is pending.
Is updating WordPress plugins enough to fix PHP2Shell?
No. PHP2Shell is a flaw in PHP itself. As of October 23, 2026, the fix is a patched PHP release (for example 8.5.12 or 8.4.27). Plugin updates are still important, but they don’t close this hole.
Where to start on your hacked-site recovery this week
If you only do three things this week, make them these: confirm your PHP version is patched, check the Security issues report in Search Console, and make sure you have a clean backup stored somewhere other than your server. If something looks wrong, contain first, clean second, and ask Google for a review only when the whole site is clean.
Recovery takes patience, but it is very achievable. If you would rather have someone handle the cleanup and the SEO side with you, from de-indexing spam to rebuilding visibility, our SEO team can help, and our technical SEO guide covers the foundations. Just get in touch for a free quote and tell us what you are seeing.
Further reading on recover rankings after hack
- PHP2Shell and Your Rankings: What a Hacked PHP Site Can Cost You in Google
- Has Your Site Been Hacked? 12 SEO Warning Signs to Check Right Now
Sources for this hacked-site ranking recovery guide
- Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Oct 21, 2026)
- PHP.net: 2026 news archive and security releases
- Fortune: AI tools discovered the PHP vulnerability (Oct 21, 2026)
- web.dev: Quarantine your site
- web.dev: Identify the vulnerability
- web.dev: Clean and maintain your site
- web.dev: Fix the Japanese keyword hack
- web.dev: Request a review
- Search Console Help: Security issues report
- Search Console Help: Manual actions report
- Search Console Help: Removals tool
- Google Search Central: How HTTP status codes and network errors affect Google Search
