Fix the “This site may be hacked” warning

This guide is not here to scare you further — a “This site may be hacked” warning is one of the more fixable security problems a website owner can have. It almost always means an attacker got in through a known, patchable weakness (an outdated plugin, a weak password) and left spam or injected code behind, not that your business or your visitors’ devices are permanently at risk. Confirming and cleaning it usually takes a focused day; Google’s review afterward adds a few more.

What does “This site may be hacked” mean? It means Google’s search-quality systems found signs that your site’s content was changed by someone other than you — typically injected spam links, spam pages in a different language, or content that shows differently to Google’s crawler than to a normal visitor. It is a label attached under your listing in search results, separate from Google Safe Browsing’s full-page malware warning, which blocks the page outright before a visitor even sees it.

The distinction matters because the two warnings clear through different processes, and confusing them wastes time.

This guide focuses specifically on the search-result warning. If you are also seeing other signs of compromise — a defaced homepage, unfamiliar admin users, strange outbound traffic — the warning is one symptom among several; our full guide to a hacked website covers the complete picture and response.

Confirm the exact issue before doing anything else — the Security Issues report tells you precisely what pattern Google found and gives example URLs, which turns a vague warning into a concrete todo list.

Open the Security Issues report

In Search Console, select the verified property for your domain (if you have not verified it yet, add it now with a DNS TXT record from your domain registrar or an HTML verification file — either takes a few minutes), then open Security & Manual Actions › Security Issues in the left sidebar.

Read the “Hacked type”

Google names the specific pattern it detected — common ones are Content injection, Code injection, URL injection, Cloaked images, and Cloaked keywords and links (the pattern behind the classic Japanese keyword hack on WordPress). This tells you what to look for once you go digging.

Note the example URLs, and their limits

Google lists one or two URLs where it found the problem. Treat these as a starting point, not the full extent — Google does not recrawl every page every time, so the injection is often on more pages than the report shows. Step 3 below covers how to check the rest of the site.

Removing the visible spam without finding how the attacker got in — the backdoor — is the single most common reason a cleaned site gets hacked again within days. Do both, in this order.

See what Google actually sees

Open the flagged URL and view its page source, not just the rendered page — some injections are cloaked, meaning they show normal content to a visitor and spam content only to search-engine crawlers. To see exactly what Googlebot sees, use URL Inspection › Test Live URL in Search Console and check the rendered HTML. Typical patterns: a block of hidden spam links or keyword text positioned off-screen, a full alternate page of foreign-language or spam content served only to crawlers, or a script-based redirect that sends search visitors elsewhere while regular visitors see nothing unusual.

Find the backdoor, not just the symptom

A backdoor is the file or account an attacker left behind so they can get back in even after you delete the spam. Common places to look:

• Unexpected files in folders that should never contain code — a .php file inside wp-content/uploads is a classic red flag.
• Recently modified files — your host’s file manager or an SSH/SFTP client can sort by modified date; anything touched outside your own recent edits deserves a look.
• Admin or user accounts you do not recognize, in both your CMS user list and your hosting or control-panel account list.
• Unfamiliar scheduled tasks or cron jobs — some backdoors reinstall themselves automatically after cleanup.
• On WordPress specifically: compare core files against the official release. The WP-CLI command wp core verify-checksums flags anything modified, and re-uploading fresh copies of core, your active theme, and your plugins from the original source is the most reliable clean.

Remove it, then lock the door behind you

• Delete the injected code or pages and every unfamiliar file or account you found in the previous step.
• Change every password connected to the site — hosting/control panel, CMS admin, database, and FTP/SFTP, plus any API keys. A weak or reused password is the most common way attackers get in the first time, and skipping this step is the second most common reason a cleaned site gets hacked again.
• Update everything — CMS core, every plugin and theme, and your PHP version if your host allows it. Most hacks start from a known, already-patched vulnerability that simply was not applied yet.
• Delete plugins and themes you are not actively using. An inactive one with a known flaw is still exploitable if its files remain on the server.
• Keep a copy of the infected files somewhere safe before deleting them. If the warning does not clear on the first try, having exactly what was found makes the second pass much faster.

Injections that come from a backdoor script often touch every post or page automatically, not only the one URL Google happened to show you — this is exactly how the classic keyword-spam hack generates hundreds of fake pages from a single script. Checking only the flagged URL and calling it done is how sites end up requesting review, failing, and starting over.

• Re-check the exact example URLs from the Security Issues report and confirm the injected content is genuinely gone, not moved.
• Search site:yourdomain.com in Google and scan the results for titles or pages you do not recognize — spam-generated pages usually stand out immediately by language or subject.
• In Search Console’s Pages report (under Indexing), look for a spike in indexed URLs you never created — a common fingerprint of the auto-generated keyword-spam pattern.
• Run URL Inspection › Test Live URL on a handful of pages, not just the flagged one, to confirm Googlebot sees the same clean content a normal visitor does. This catches cloaking a browser check alone would miss.
• Run a second scan with a reputable malware or blocklist checker as a sanity check before you submit for review.

Once you are confident the whole site is clean, go back to the Security Issues report and click Request Review.

What to write

Be specific: which files or pages were affected, exactly what you removed, and what you changed to close the entry point (passwords, software updates, deleted backdoor). Google’s reviewers read this description, and a specific, complete one reduces back-and-forth.

What to expect

Google’s own guidance is that review typically takes a few days, though it can run longer if a reviewer needs a second pass. What resets the clock: if the hack reappears before or during review because the backdoor was not fully closed, the review fails and you are back at Step 2. This is the single biggest reason reviews drag on for weeks instead of days — not the review itself, but a reinfection nobody noticed.

Once approved, the warning is removed from your search listing. Recovering the traffic and rankings lost during the incident can take a little longer, since Google still needs to recrawl and re-rank the affected pages — but for most small sites, the bulk of it returns within days of the label disappearing.

Worth knowing: this is a different process from a Safe Browsing warning (“Deceptive site ahead”), which is a full-page interstitial for active malware or phishing rather than a search-result label. Safe Browsing typically re-checks and lifts that warning automatically within a few days of the threat being gone, with no Request Review button involved — see the comparison above.

For small sites, the cause is almost always one of three things: an outdated CMS core, plugin, or theme with a known, published vulnerability (by far the most common on WordPress); a weak or reused admin password caught by automated password-guessing; or a hosting/FTP credential that leaked in an unrelated breach. Knowing which one applied to you is worth five minutes — it tells you what to actually change.

• Update core, plugins, and themes on a regular schedule instead of waiting for a warning to force it.
• Delete plugins and themes you are not using, rather than leaving them deactivated.
• Use a unique, strong admin password and enable two-factor authentication wherever your CMS or host supports it.
• Keep offsite backups, and actually test restoring one occasionally — a future incident should be a restore, not another forensic project.
• Run a periodic outside-in check on your domain to catch new exposure before Google does. Our free passive check takes seconds, needs no login, and is safe to run monthly.

If this is not the first time your site has been compromised, the pattern usually points to something structural rather than one unlucky plugin — our guide on why a WordPress site keeps getting hacked walks through the recurring causes in more depth.

Doing it yourself

Realistic if you are comfortable in your host’s file manager or SSH and your CMS admin, and the pattern is a well-known one. Budget real time: a careful cleanup on a small WordPress site is usually a focused few hours, not minutes — rushing Step 2 is exactly how a backdoor gets missed and the site gets hacked again a week later. If you want a sense of what professional cleanup typically costs before you decide, see our breakdown of the real cost to fix a hacked website.

Getting it done for you

Bug Circuit’s $49 Circuit audit is a full manual pass by a human engineer over the whole site, which matters here specifically because confirming there is no second backdoor left behind is exactly the check a DIY cleanup is most likely to miss. The $299 Signal plan goes further — we do the fixes with you and keep 3 months of cover afterward, which matters most in the weeks right after a hack, when reinfection risk is highest. Signal is currently discounted by roughly 55% as a launch offer; current pricing is always on the pricing page. Every paid option starts only after you verify domain ownership and sign a recorded Authorization to Test, with a 14-day money-back guarantee before the audit begins. A written report you can keep is also included — see a sample report to see the format.