Read a URL report without a misleading safety score

How-to Last tested 24 October 2026

Read a URL report as a dated observation with a named source and a defined scope. Keep no match, failed check, unknown coverage and old evidence separate; none of those states certifies the address you are considering.

Establish what the report actually describes

Start with the address or object named in the report. A full URL, a hostname, an IP address and a downloaded file are different subjects. A report can provide useful evidence about one while saying nothing about the others. Do not silently expand its scope because the same organisation’s name appears nearby.

Next, identify the source and observation time. The date when you opened a report page is not necessarily when the service performed its analysis. A result may preserve an earlier scan, a list lookup or a community submission. Keep those dates distinct if the report exposes them.

Finally, read the result’s own definition. VirusTotal’s URL-object documentation distinguishes analysis fields, scanner names, methods, categories and raw results.¹ A normalized category and a provider’s raw wording are related fields, not permission to substitute a new universal meaning for them.

Four states that should remain separate

No match means the stated check did not return a match under its conditions. Request failed means the check did not supply that result. Unknown coverage means a necessary part of the scope is missing. Old evidence describes a previous observation whose relevance must be considered separately from current contents.

This distinction is easiest to see with fictional records. They contain no real addresses and do not imitate an actual service’s report page. Their purpose is to show how a status label changes the conclusion you can draw from otherwise similar-looking output.

A complete report-state reader

The selector presents four fixed teaching records. The component renders source, observation time, scope and state as text², followed by an explanation. It never contacts a provider, accepts a destination or computes a score.

<!doctype html>
<!-- SPDX-License-Identifier: MIT -->
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Separate report states</title>
    <style>
      body { font: 1rem/1.5 system-ui; margin: 2rem; max-width: 44rem; }
      label, textarea, select { display: block; margin-block: .75rem; }
      textarea { width: 100%; min-height: 5rem; }
      button { padding: .5rem 1rem; margin: .5rem .5rem .5rem 0; }
      pre { white-space: pre-wrap; overflow-wrap: anywhere; }
      :focus-visible { outline: 3px solid #16624c; outline-offset: 3px; }
    </style>
  </head>
  <body>
    <h1>Separate report states</h1>
    <p>These are fictional teaching records, not reports about real addresses.</p>
    <label for="case">Choose a report state</label>
    <select id="case">
      <option value="none">No match in the stated list</option>
      <option value="old">A dated match</option>
      <option value="failed">Request failed</option>
      <option value="unknown">Coverage unknown</option>
    </select>
    <button id="reset" type="button">Reset</button>
    <pre id="record" aria-label="Fictional evidence record"></pre>
    <p id="meaning" role="status"></p>
    <script>
      const choice = document.querySelector("#case");
      const record = document.querySelector("#record");
      const meaning = document.querySelector("#meaning");
      const cases = {
        none: ["2026-10-20", "Exact URL", "No match", "No entry was returned by this fictional list at that time."],
        old: ["2024-01-10", "Exact URL", "Match", "The dated match is evidence of that observation, not current page contents."],
        failed: ["Not recorded", "Exact URL", "Request failed", "A failed request supplies no match result."],
        unknown: ["Not recorded", "Not stated", "Unknown", "Missing scope and time cannot be filled by guessing."]
      };
      function show() {
        const item = cases[choice.value];
        record.textContent = [
          "Source: fictional example provider",
          "Observed: " + item[0],
          "Scope: " + item[1],
          "State: " + item[2]
        ].join("\n");
        meaning.textContent = item[3] + " No state certifies the address.";
      }
      choice.addEventListener("change", show);
      document.querySelector("#reset").addEventListener("click", () => {
        choice.value = "none";
        show();
        choice.focus();
      });
      show();
    </script>
  </body>
</html>

Case one: no match

Choose No match in the stated list in the demo. The record names a fictional provider, an exact-URL scope and an observation date. Its explanation says only that no entry was returned by that fictional list at that time.

That is a complete statement of the teaching record’s evidence. Turning it into a positive verdict would add something the record does not contain: knowledge of every threat, every possible response from the destination and the state of the page at a later moment. A limited observation should stay limited.

In a real report, preserve the provider’s vocabulary alongside your interpretation. An engine’s lack of an opinion is not interchangeable with a separately defined benign category. If the service provides a method field or documentation describing how the result is produced, keep that information attached to the record.

Case two: a dated match

Choose A dated match. The fictional record moves the observation date to an earlier period and displays Match. The explanation does not erase the observation because it is old, and it does not claim to know what the page contains now. Both would go beyond the supplied record.

For a site owner, an old result can be useful when reconstructing a timeline. Preserve the source time, the affected path and the reported category alongside the remediation history you can support. A newer screenshot of a report page should not replace the original observation date.

For a reader deciding whether to use a link, a historical record does not require visiting it to settle the uncertainty. You can use an independently known route to the organisation or choose not to continue. The record is evidence to interpret, not an instruction to navigate.

Case three: request failed

Choose Request failed. The component deliberately leaves the observation time as Not recorded. It does not convert the failure into zero detections or a no-match result. The status describes an unsuccessful check and nothing more.

This is an important distinction in aggregated reports. A denominator can be misleading if unavailable engines are treated as completed negative checks. Read the service’s definitions for timeout, error and unavailable states before comparing counts. Where the report does not explain its denominator, write that limitation down rather than supplying your own assumption.

If two reports disagree, first compare their subjects, times and methods. Differences in those fields can explain why the records are not measuring the same thing. A majority count cannot resolve a mismatch between a file report and a URL report, or between an old observation and a recent one.

Case four: unknown coverage

Choose Coverage unknown. Both scope and observation time are missing. The component preserves that absence instead of borrowing values from another case. Reset restores the first fictional record and places focus on the selector; it does not change any provider data.

An unknown field is useful information about the quality of the evidence. It tells you which question remains unanswered. If the report links to documentation, check whether that documentation supplies a general definition or an exact fact about this specific observation. Those are different levels of support.

The example’s fixed cases are deliberately simple. A real report can contain several states at once: one provider’s match, another provider’s lack of an opinion, and a failed request elsewhere. Preserve those records individually before deciding whether any summary is meaningful.

Record evidence without creating a new claim

A practical note contains the provider, the exact subject or a clearly identified redaction, the observation time, the category, the method when stated and the report’s limitations. Keep copied report language separate from your explanation. If a sensitive address must be omitted, say that the subject was reduced rather than presenting the shortened note as the original URL.

For an owner seeking review, the route directory helps locate the organisation responsible for the warning. A request to one organisation does not automatically change every other provider’s data. This article does not submit anything or suggest bypassing a warning while a disagreement is unresolved.

The policy comparison addresses the separate question of what happens when you send an address to a service. Interpreting a report and deciding whether to disclose a URL require different evidence, even when one interface offers both actions.

Not covered on this page

• Live threat detection or provider accuracy rankings.
• Incident response, malware removal or warning bypass.
• Guarantees about current destination contents.
• Automatic resolution of conflicting provider reports.