Hacked Website Tanking Your Google Rankings? The Recovery Sequence (2026)

Google publishes the wait: "Reviews for sites hacked with spam can require up to several weeks to process," against "a few days" for malware and "about a day" for phishing. That line comes from Google's own guidance on requesting a review after a hack, and it changes how you should think about the whole problem. The review clock only starts when you submit, and you only get one honest submission — if the reviewer finds the site is still dirty, the request is denied and you go to the back of a queue measured in weeks, not hours. Almost all of the recovery time businesses lose to a hack is lost to doing the cleanup in the wrong order and burning a review on a half-clean site.

The good news is that Google documents the right order in public, in detail, and it is not complicated. It is just not intuitive, because the first three steps have nothing to do with deleting spam.

Why the site looks completely fine to you

The most disorienting part of a spam injection is that the owner is usually the last person who can see it. Google's hacked-site material is direct about the reason: attackers use cloaking, which Google describes as showing "different content to different types of users." You load your homepage in Safari on your phone and it is the same site it was yesterday. Googlebot requests the same URL and gets something else entirely.

The most common variants are well catalogued. The Japanese keyword hack, in Google's description, "creates autogenerated Japanese text on your site" at randomly generated paths like /ltjmnjp/341.html, monetised "using affiliate links to stores selling fake brand merchandise." There is a matching gibberish variant that spins up thousands of nonsense-keyword pages, and a cloaked keywords and links variant that quietly rewrites pages you already had. Google also notes something worth checking straight away: with the Japanese keyword hack, the attacker "will typically add themselves as a property owner in Search Console."

So the signs are rarely visual. They look like this instead. Your indexed page count jumps from forty to four thousand. Analytics shows a traffic spike from countries you do not sell to, on queries that have nothing to do with your business. A customer mentions that clicking your listing on their phone bounced them to a betting site, and you cannot reproduce it. A Search Console property owner appears that nobody at the company added. Or the plainest signal of all, the label "This site may be hacked" sitting under your name in the results.

If you want to check right now, Google recommends two things. Open the Security Issues report in Search Console, which shows "example URLs where Google detected that your site has been hacked." Then run a site:yourdomain.com.au search in a normal Google window and page through it. That query returns what Google has indexed rather than what your server shows you, which is exactly the gap cloaking is designed to hide. The URL Inspection tool does the same job for any single page you are suspicious about.

What actually costs you the rankings

There are two separate losses running at once, and they recover on different timelines, which is why the graph often looks confusing later.

The first is visibility on your real pages. When Google's systems flag the site, the "This site may be hacked" notice appears in results. Your position may not have moved at all, but clicks collapse, because almost nobody clicks a result carrying a security warning. In the more serious cases the site picks up a manual action, and the drop stops being cosmetic.

The second is that your index fills with pages you did not write. Thousands of autogenerated URLs get crawled and indexed, and Google's picture of what your site is about stops matching what your business does. A Melbourne accounting practice with a hundred legitimate pages and eight thousand injected affiliate pages is, to a crawler, mostly an affiliate spam site with an accounting section. Cleaning that up is not one delete — it is the delete, plus getting Google to recrawl enough of the site to notice.

The order Google documents, and why it is that order

Google's recovery guide runs as a sequence: build a support team, quarantine your site, use Search Console, assess the damage, fix the specific hack type, identify the vulnerability, clean and maintain the site, then request a review. The temptation is to jump to step seven. Do not.

Quarantine before you clean. Google's instruction is to "take your site offline so that it no longer serves content to users," using a 503 response, with an important caveat: "the response should occur from outside your compromised server or site." A 503 issued by the box that has already been taken over is worth very little. The guidance is equally blunt about the shortcut most people reach for first: "Using a robots.txt disallow is also insufficient because it only blocks search engine crawlers." Robots.txt hides the spam from Google. It keeps serving malware to your customers.

Lock the doors while you are down. Google's quarantine step includes checking "whether the hacker created a new user account" and deleting any that appear, then changing passwords for everything — "logins for FTP, database access, system administrators, and content management system (CMS) accounts." Also check the Search Console property owner list, given how routinely attackers add themselves there.

Find the hole before you scrub the mess. This is the step that separates a two-week recovery from a six-month one, because a site cleaned without the vulnerability closed simply gets reinfected, and the second infection is the one that gets your review denied. Google's advice is to keep looking after you find the first problem: "even if you're able to find and fix one vulnerability, we recommend continuing to search for others," because "there may be multiple, independent hacks in place." The documented checks are unglamorous. Run reputable antivirus scanners on every computer an administrator has used to sign into the site, because the compromise often starts on a laptop rather than a server. Read the server logs, keeping in mind Google's warning that "the hacker might have altered log files." Look in the database for "otherwise ordinary text fields that now show iframes or scripts."

Rebuild rather than patch. Where you have a clean, current backup, restore it, patch everything, remove software you are not using, and change passwords again. Where you do not, Google's instruction for the server itself is unambiguous: "Perform a clean installation, not just an upgrade."

Be careful with the Removals tool. It is genuinely useful for burying hacker-created URLs while you work, but Google is explicit that it is temporary — a removal lasts about six months, and "blocking a URL does not prevent Google from crawling your page, only from showing it in Search results." Permanent removal means the URL returns a 404 or a 410. If you rely on the Removals tool alone, the spam pages come back on their own six months later.

Then request the review, and describe the fixes. Google asks for detail on what was actually corrected, not a one-line "fixed it." If the request is denied, the Security Issues report returns more sample URLs, which is a hint about where you missed something rather than a punishment.

When the rankings actually come back

Two clocks, and it helps to keep them separate.

The first is the warning. Once a review is approved, Google states that "warnings from browsers and search results will be removed within 72 hours." Combined with the review times at the top of this piece, a spam-hacked site is realistically looking at several weeks from submission to a clean listing, and a malware-flagged site at a few days. Those are Google's published numbers, not an estimate.

The second clock is recrawling, and Google does not publish a timeline for it, because there is not one to publish. Your legitimate pages have to be recrawled before their signals settle back, and however many thousand spam URLs have to be crawled again and found gone before they leave the index. That is weeks of drift, not days, and it is normal for the traffic graph to recover in an ugly staircase rather than a clean line. Requesting indexing for your most important pages in Search Console speeds up the handful that matter most.

One thing worth ruling in or out before you assume the hack explains everything. If the numbers were already sliding before the injection, you may be looking at two problems stacked on top of each other, and the general diagnostic for a ranking drop is the better starting point. If pages have not come back weeks after a clean review, the question shifts to whether they are being indexed at all, which is a different investigation again.

The hole is almost always boring

Google's own list of how sites get compromised by spammers reads as an argument for a smaller site, not a more fortified one: compromised passwords, missed security updates, insecure themes and plugins, social engineering, security policy holes, and data leaks. Nothing exotic. An unpatched plugin someone installed in 2021 to add a testimonial slider and forgot about.

Attack surface is a design decision that gets made long before anyone thinks about security. A site assembled from thirty third-party plugins carries thirty ongoing update obligations and thirty separate parties whose code quality you cannot see. That is the main reason we build without a plugin stack — not because hand-written code cannot have bugs, but because you can only be breached through code that exists. Fewer moving parts, fewer doors.

If you have finished a cleanup and want a sanity check on the platform underneath, run the free audit. To be clear about what it does and does not do: it will not tell you whether you have been hacked, and it does not check indexing — Search Console's Security Issues report is the only tool that answers that question. What it does check is the TLS certificate, your DNS and email records, HTML structure, robots.txt and sitemap crawl readiness, page weight and Core Web Vitals. It takes about a minute, and it is a reasonable way to confirm that the restore put everything back the way it was meant to be.