What to do when Google flags your website as unsafe

Confirm the exact warning and affected property

Record the warning text, the URL, the time and the browser. An HTTPS certificate error and a deceptive-site or malware warning are different problems. An authorised Search Console owner should inspect the Security Issues report for the affected property. Google may provide example URLs; use them as investigation leads rather than assuming they are a complete inventory.

Build an incident record before changing files

Identify who can access the site, hosting, DNS and Search Console. Keep a short record of known changes and affected delivery paths. Work from your own administration tools and evidence instead of browsing through a security interstitial. If a third party manages the site, send a consolidated brief containing the exact warning and the evidence needed to investigate.

1. Record the affected hostname, URL and warning category.
2. Preserve relevant logs and a recoverable snapshot before repairs.
3. Check recent application, account, plugin and advertising changes.
4. Assign one incident owner and record each verified repair.

Repair the cause, not just the visible page

Investigate the components involved in the flagged behaviour. These may include altered content, injected scripts, compromised accounts, redirects or third-party resources. A familiar-looking homepage is not enough to clear the issue. Have the responsible administrator repair the cause, review the access that enabled it, and check other affected pages. Keep the incident evidence private, particularly credentials and customer information.

Verify the repaired delivery path

Test the known affected URLs and representative pages through the normal production delivery path. Compare what the application serves with the observed warning and Search Console issue details. Check applicable caches and external resources as part of the investigation. Record the exact evidence that changed so the review request explains a completed repair.

1. Confirm the identified malicious or deceptive behaviour is removed.
2. Retest the sample URLs and additional pages implicated by the investigation.
3. Check that the repaired site still provides its intended user journeys.
4. Prepare a summary of the issue, the remediation and the verification.

Request review and check the resulting status

When the issue is fixed across the site, the authorised owner can request a security review through Search Console. Google assesses the request; submission alone is not clearance. Monitor the report and the actual warning status. Avoid promising a 24-hour or 72-hour recovery because the review and warning propagation are outside your control.

Separate incident recovery from traffic recovery

After clearance, compare search clicks, landing-page visits and important user actions with an appropriate baseline. A removed warning does not establish that rankings, trust or conversions immediately returned. A public audit observation is a starting signal; it cannot certify malware removal. Keep the repair record and arrange the deeper review the incident requires.

Frequently asked questions

See where your website stands

Start with a public-signal screening report in about 60 seconds. No signup or card. Quick Scan samples the website; it does not test every topic in this guide.