The "This site may be hacked" label in Google Search means Google found signs that pages on your domain may have been compromised or altered with unwanted content. The way to remove it is to find and clean the cause first, then request a review in Search Console when the site is genuinely clean. A review request cannot repair malware, spam pages, or a backdoor that remains on the server.

What the warning means

Google may show this label beneath a search result when it detects hacked content, suspicious behavior, or pages that appear to have been added without the site owner's intent. Common causes include injected spam pages, hidden outbound links, hacked redirects, and malware that shows different content to Google than it shows to the owner.

The warning does not identify every affected file or URL. It is a signal to investigate your site and Search Console data, not a diagnosis by itself. The visible page can look normal if the attack is cloaked for crawlers, mobile visitors, or people arriving from a search result.

Start by preserving evidence. Take a complete backup of WordPress files and the database, and record the warning, affected search results, and recent host notices. Do not restore an old backup over the live site unless you understand whether it also contains the weakness or malicious code. A rushed restoration can remove clues while leaving the same entry point open.

Find the cause in Search Console Security Issues

The first place to check is Google Search Console. Select the affected property, then open Security Issues. Read each listed issue and the sample URLs carefully. The report can point to hacked content, deceptive pages, unwanted downloads, or other behavior Google identified. Save the examples and use them to guide testing.

Open affected URLs in URL Inspection. Review the indexing and crawl information, and compare it with what a normal private browser sees. If the page is a spam URL you never created, search your domain with site:yourdomain.com and relevant words from the result title. This can reveal related URL patterns that are not all shown in the report.

Look at the Pages report and sitemap information too. Unexpected paths, submitted sitemaps you do not recognize, and a sudden growth in indexed pages can all point to the scope of the incident. Search Console is useful evidence, but it is not a replacement for checking the WordPress files, database, users, and hosting account.

Review property access in Settings, then Users and permissions. Remove users or owners you did not add after securing the site and its verification methods. Check for unfamiliar verification files, DNS records, HTML tags, or analytics-related verification that could keep an attacker attached to the property.

Clean the site before you request review

The essential work is to remove the compromised code and prevent it from returning. Deleting a result or asking Google to reconsider first does not make the site safe, and it can delay a useful investigation. Use a full cleanup sequence.

  1. Restrict access to trusted administrators and preserve a copy of the existing files, database, and relevant logs.
  2. Reset WordPress, hosting, SFTP or SSH, database, and control-panel credentials. Rotate exposed API keys, and require new passwords for legitimate administrators.
  3. Remove unknown WordPress admin accounts, hosting users, scheduled tasks, deployment keys, and unnecessary access. Check Search Console users and owners as part of the same review.
  4. Replace WordPress core, active themes, and plugins with clean copies from trusted sources. Run wp core verify-checksums to identify core files that differ from the official release.
  5. Remove unused themes and plugins, then update every retained component. Check for abandoned or unofficial extensions that may have been the entry point.
  6. Inspect .htaccess, wp-config.php, index.php, active theme files, mu-plugins, and wp-content/uploads for suspicious code or PHP files. Also inspect wp_options, widgets, post content, and scheduled jobs for injected payloads.
  7. Test the site logged out, in a private browser, from search results, and on a phone. This helps expose the conditional behavior common in WordPress redirect hacks.

Use the evidence to check for the specific infection type. Japanese spam may create large groups of cloaked URLs, while pharmacy spam may inject content or links that only Googlebot sees. Looking only at the visible page can miss either type of issue.

Do not stop after the warning disappears from one browser. Confirm that suspicious URLs return a clean response. Fake pages should return 404 Not Found, or 410 Gone when they are permanently removed. Do not redirect them all to the home page, because that does not tell search engines the spam content is gone.

Request a review after the cleanup

Once you have fixed the issue, return to Security Issues in Search Console and use the available review request process. Describe the cleanup accurately and briefly: what you found, what you removed or replaced, how you changed credentials and access, and how you verified representative URLs. Do not claim an issue is fixed if you only removed a few search results or disabled a page temporarily.

Keep the site accessible to Google during review. Do not block the whole site in robots.txt, require a login for all pages, or use maintenance mode indefinitely. Google needs to recrawl the clean pages to evaluate the request. It is fine to return 404 or 410 for spam URLs that should no longer exist.

If the Security Issues report identifies multiple issue types, address each one before requesting review. A partial cleanup can leave the warning in place. For uncertain or widespread changes, use a structured WordPress malware removal process to account for files, database records, access, and configuration together.

What to expect after a review request

The review outcome is not instantaneous and Google does not set one fixed timeline for every request. Continue monitoring Security Issues, URL Inspection for representative pages, and search results for the warning and residual spam. A successful review does not replace ongoing monitoring because search results and indexing can take time to reflect a clean crawl.

If Google finds the same problem again, revisit the cleanup rather than submitting repeated requests with no change. Look for a missed backdoor, a malicious scheduled task, an altered server rule, compromised hosting credentials, or a vulnerable plugin. Rechecking only the home page is not enough when an infection serves content conditionally.

Use Search Console Removals only for urgent temporary hiding of individual spam URLs or a spam URL prefix. It can reduce visibility while Google recrawls, but it does not remove the underlying infection and does not permanently deindex a page that still serves hacked content.

Know the difference between this label and a red Chrome warning

The search-result text "This site may be hacked" is not the same as Chrome's full-page red "Dangerous site" warning. The red interstitial is generally connected to Google Safe Browsing, which warns visitors before a page known for malware, phishing, unwanted software, or other dangerous content loads.

The distinction matters because you should follow the report that matches the warning. Use Search Console Security Issues and its review workflow for the hacked-site label. For a Safe Browsing warning, clean the dangerous content and use the Safe Browsing-related reporting or review path presented for your property, while also checking Search Console for related issues. A domain can have one warning, the other, or both.

In either case, the technical response is similar: preserve evidence, remove malicious files and database entries, replace compromised components, rotate credentials, and fix the access path. Read signs your WordPress site has been hacked if you need a broader checklist of places to inspect.

Prevent another warning

Regular maintenance lowers the chance that a known weakness is used again. Keep WordPress, themes, and plugins updated. Remove unused and untrusted extensions. Use unique passwords, multi-factor authentication where available, and separate administrator accounts for each person who needs access.

Keep backups outside the live hosting account and test that you can restore them. Review WordPress administrators, Search Console users, file changes, scheduled jobs, and hosting account access. The WordPress hardening checklist is a practical baseline for those recurring checks.

When to get help

Get help when you find cloaked pages, code you cannot identify, customer data exposure, or a warning that returns after cleanup. West Oakbridge can provide WordPress malware removal and WordPress hardening to help find the cause and reduce the risk of recurrence.