What to do when Google flags your website as unsafe

Free editable handover sheet

A blank incident worksheet covering warning details, affected URLs, investigation scope, repairs, verification and the three parts of a review request. Keep completed evidence with your authorised incident team. No signup or upload is needed; downloading this file does not submit a Google review or certify a site as clean.

• Download the Safe Browsing repair and review worksheet (CSV)

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.

Prepare a review request using completed evidence

Google asks for the issue, the repair and the outcome. Use the worksheet to collect those three parts before requesting review in Search Console. Replace every bracket below with verified facts; do not send an unfinished template or claim that a homepage check proves the whole site is clean. The example is a writing aid, not evidence that a repair happened.

Issue: [warning category, affected URLs and investigation scope]
Repair: [cause identified, changes completed and access secured]
Verification: [tests, affected paths, date and observed results]
Remaining limitations: [anything not yet verified]

1. Check every issue listed in Security Issues, including affected paths beyond the example URLs.
2. If you cannot reproduce a warning, use the report details to continue investigating; warnings can depend on browsing context.
3. After submitting a completed request, wait for the decision before resubmitting. Keep the submission date and result in the incident record.

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

Turn website findings into an action plan

Create an account to start a Full Audit of your website, with supporting evidence and a prioritised action plan.