Investigate a deceptive-site warning as the owner

How-to Last checked 25 October 2026

A deceptive-site warning calls for an owner investigation of the reported behavior, not a certificate renewal or a request that visitors ignore it. Identify the warning provider and affected object, then compare the report with your own release records, server logs and embedded-resource inventory. Keep the warning in place while you establish what happened and what evidence supports a correction.

Record what the warning actually says

Start with information already available: the warning text, its provider, the time it was observed and the address or file it names. Preserve an existing screenshot or owner-console message with sensitive details removed from any shareable copy. Do not ask someone to continue past the warning, repeat a download or reproduce the incident in an everyday browser. The investigation can begin without loading the affected content.

A browser name is useful context, but it is not a complete classification. Separate a page warning, a download warning and a connection error. Microsoft documents website protection and download screening as distinct SmartScreen activities; a download may also be flagged because it lacks an established reputation, rather than because its hosting page received a phishing classification¹. Record the actual wording instead of translating every warning into “the domain is malicious.”

A certificate error needs its own connection investigation. Mozilla documents expired certificates, unknown issuers and name mismatches among different error classes². The HTTPS explainer explains why correcting one does not establish that a site’s content is honest. If two warnings were reported, keep two records rather than choosing the easier one to resolve.

Begin in the provider’s owner evidence

For a Google-related issue, the Search Console Security Issues report identifies Google’s issue categories and may provide sample affected addresses. Google warns that those samples are not a complete inventory; a missing example is not evidence that nothing is affected. Its guidance also says warnings can depend on browsing context³. Read the report through an independently reached, authorized owner account, rather than following an unexpected “appeal” message.

Record the provider’s statement separately from your conclusion. “Provider reports deceptive embedded resources” is a documented claim. “The shared advertising component caused it” is a hypothesis until your evidence connects that component to the affected scope. This distinction prevents a plausible explanation from becoming the accepted incident history before it has been checked.

If you cannot access the relevant owner report, put that limitation in the worksheet. Do not fill the gap with another service’s result or a clean-looking homepage. An authorization problem, an absent report and a report with no listed issue are different states. The result-state reference and report-reading guide help keep those meanings separate.

Preserve a useful record before changing the deployment

Download the owner evidence worksheet, or use its JSON template. Both are empty, original templates. They contain no incident, account credentials or submission mechanism. Keep a completed copy in your controlled incident records; do not place it in a public website folder merely because the blank template came from one.

Give each observation an evidence reference and UTC time. Identify whether it came from the provider report, a release manifest, an existing log, a configuration export or a file comparison. Record what was checked, what was found and what remains unknown. A reference should let an authorized colleague find the underlying material without copying a sensitive log into every summary.

NIST’s April 2025 incident-response guidance calls for preserving the integrity and provenance of investigation records and restricting access to sensitive response information⁴. For this worksheet, keep the original evidence and a separate redacted sharing copy. Note any transformation, such as removing a session token. A hash can identify a preserved file’s bytes; it cannot establish that the file was legitimate or that a log contains every relevant event.

Preservation and containment are separate decisions. Do not leave a harmful component active solely to keep collecting examples. The responsible incident lead can preserve existing evidence and arrange containment under the site’s response process. If the available team cannot interpret server changes or safely handle suspect files, the unresolved task belongs with a qualified responder, not with visitors asked to test the page.

Compare the deployed content with a known release

Use your deployment inventory to identify the templates, application code, configuration, uploaded content and administrative changes relevant to the reported addresses. Compare retained versions against an approved release. Record both unexpected additions and unexpected modifications. A clean application repository does not account for content supplied from a database or a configuration changed outside that repository.

Choose the comparison baseline deliberately. A recent backup may already contain the unwanted change. Write down why the selected release is trusted: its approval record, recorded artifact hash or independently retained build output. Keep “matches the chosen baseline” distinct from “the baseline has been reviewed.” Otherwise a precise file comparison can give false confidence about the wrong reference.

Where existing server logs cover the affected period, align requests with deployment and configuration events. Use the narrowest fields needed to answer the question. A redirect response, an upload event or a changed template reference can support a finding; an ordinary successful response code does not describe all of the content a visitor received. Record log retention gaps and missing fields rather than converting silence into evidence of absence.

Treat the endpoint named in a report as the start of a scope question. A shared template can affect several routes. An uploaded file may be reachable through more than one link. Trace those relationships using owned configurations and inventories, without opening the flagged pages or following their outgoing destinations. The result should be an affected-scope list with evidence, not a guess based on the first example.

Include resources supplied by someone else

Google’s social-engineering guidance explicitly includes deceptive embedded resources, including advertising and third-party components, in the host page’s policy scope. It also describes redirection to deceptive content and variation in the advertising shown to visitors⁵. Owning the surrounding page therefore does not make a third-party resource irrelevant to the investigation.

Build a resource list from templates, tag configuration, release records and existing delivery logs. For each resource, identify which pages include it, who controls its configuration, whether the bytes are versioned, and what evidence covers the period in question. A familiar supplier name is not evidence that every resource it delivered was the same. Conversely, the presence of an unfamiliar name alone does not prove it caused the warning.

Distinguish an ordinary outgoing link from an embedded component or automatic redirect. Record what the site’s own configuration actually does. This guide does not assume that every external link transfers another site’s reputation to yours. A provider’s reported category and evidence of the behavior matter more than a general rule invented from the existence of a hyperlink.

A useful finding names the relevant component and relationship: “This shared template includes the resource on these routes,” followed by its evidence reference. It does not need to reproduce a suspect script or expose an active destination in the shareable worksheet. If examination of untrusted content is required, retain that as a responder task with an appropriate isolated process; do not turn the worksheet into an executable collection of incident links.

Account for visitors seeing different content

A report that only some visitors saw the problem deserves a context record. The worksheet includes browser family, language, visit state, approximate region when relevant, and the route by which the page was reached. Use information already present in reports or authorized logs. Do not collect extra personal information merely to make the record look complete.

Compare those contexts with owned rules: redirects, content variants, advertising configuration and authentication-dependent templates. Separate a rule you found from a variation you actually observed. If a logged redirect affected one language setting, that supports a statement about that recorded condition; it does not establish the outcome for every language or every visitor.

Do not create a new browsing campaign to fill every combination. Mark combinations without evidence as unknown. Our redirect observation example shows why request context belongs with a result, using controlled examples rather than this site’s incident. An owner investigation needs its own authorized evidence before adopting any such explanation.

Turn findings into checkable actions

For each finding, record the affected scope, proposed correction, responsible role, retained evidence and how the correction will be checked. Separate removing the visible content from addressing the access or configuration change that introduced it. An unexplained recurrence is an open issue even when the original reported address no longer appears in the current release.

The worksheet’s final section separates a remediation check from a provider review outcome. For example, an approved configuration comparison can establish that a particular component was removed from the inspected templates. It cannot establish that a browser provider has reconsidered its warning. Write the narrow result you can support and retain the uncertainty that the result does not resolve.

When the evidence is ready, the warning-review guide uses this same worksheet to organize the provider-specific review record. Keep one incident history with dated revisions. That makes a later provider response understandable without rewriting the original finding to match a desired outcome.

Not covered on this page

• Visiting flagged pages or executing suspect downloads.
• A live scan, browser-warning reproduction or provider submission.
• Forensic handling of an actual compromised environment.
• A guarantee that remediation removes any provider’s warning.