The short answer: treat discovery, indexing and ranking as three different questions with three different kinds of evidence. Discovery asks whether a crawler or a submission channel was told a URL exists. Indexing asks whether the URL was retained and is eligible to appear. Ranking asks where, and whether, that URL is surfaced for a query. Collapsing them into one metric makes an ambiguous result look like a finding. Before you design anything, write down which of the three your question actually concerns, then choose a check that can only be satisfied at that stage.
This is a design guide, not a results report. Host Notes publishes no host scores, no benchmarks and no measured outcomes until a protocol has been run and its evidence recorded. The examples below are labelled hypothetical and are not observations of any real site.
Why the stages get mixed together
Bing's Webmaster Guidelines state that its guidance covers how Bing "discovers, crawls, indexes, evaluates, and surfaces content" across Bing, Copilot and grounding API results, and that failure to follow the guidance may result in reduced visibility, reduced eligibility for grounding experiences, or delisting from the index (Bing Webmaster Guidelines). That sentence already implies separate machinery. The same document separates crawl control from retention: it states that robots.txt controls crawl access, not indexing, and that NOINDEX should be used when a URL should not appear in Bing search, Copilot experiences or grounding API results.
That distinction alone kills a common inference. If a URL is blocked by robots.txt, a later absence from results tells you almost nothing about ranking or quality; the URL was disallowed at the crawl stage. Conversely, a crawlable URL that never appears in an index-status check has not reached a ranking comparison at all. Record the stage before you interpret anything.
Assign one check per stage
Discovery checks are about notification and reachability. Candidates include whether a URL was submitted through a notification protocol, listed in a sitemap, or linked crawlably from another page. Bing describes IndexNow as a capability for notifying search engines about content changes as they happen, and discusses timing for additions, updates and removals (IndexNow: When and How Websites Should Notify Search Engines). That post also notes that regular crawlers operate on their own schedule, which is exactly why a submission event is a discovery fact and not an indexing fact.
Indexing checks are about retention and eligibility. A status check that reports whether a specific URL is present in an index, plus any recorded exclusion reason, belongs here. The guidelines also recommend consolidating duplicate URLs, warning that duplicates dilute signals and reduce confidence in selecting a URL for grounding results or citations. If a hypothetical test page exists in two variants, an indexing check on one variant answers a question about consolidation, not about how well the page would compete for a query.
Ranking checks are query-specific and comparative. They require a defined query, a defined moment, and a defined baseline such as a control URL or a pre-change observation. Bing states that SEO does not guarantee rankings or traffic, and that GEO does not guarantee grounding or citations, so a ranking observation must always be phrased as an observation within stated conditions rather than a general property of the page or host.
Worked hypothetical: three stage readings
Suppose a researcher wants to know whether adding a new page to a sitemap and submitting it through a change-notification protocol affects its later visibility for a query. The hypothetical setup could be a new URL on a host, a control URL on the same host with no submission, a four-week observation window, and a single primary query.
Stage one reading: was the submitted URL present in the sitemap, linked internally, and notified? Stage two reading: was the submitted URL retained in the index during the window, and was the control URL also retained? Stage three reading: for the defined query, did either URL appear, and did either appear before submission?
Interpretation rules should be written before measurement. If the submitted URL is never indexed, the ranking comparison has no value and the result is a discovery or indexing finding only. If both URLs are indexed but neither appears for the query, the observation is about that query at that time, not about the host in general. If the control URL changes while the submitted URL does not, the protocol has a confounder it did not control. None of these are findings about parasite SEO labels; they are findings about stages, and each must be recorded as such.
Measurement limitations you should state up front
Every stage has known blind spots. Bing states that a decline in clicks does not always indicate a loss of visibility and advises monitoring impressions, indexing status and grounding or citation eligibility (Bing Webmaster Guidelines). A click-based outcome is therefore a poor single indicator; it mixes visibility, query volume and user behaviour.
Third-party scores are not a substitute for any stage reading. Google states that some third-party services provide "reputation" or "authority" scores for sites, and that these do not correspond to any of Google's own signals nor come from Google (What web creators should know about our March 2024 core update and new spam policies). Treating such a score as a measurement of anything in this framework would be a category error, and recording one as a finding would misrepresent what was measured.
Structured data is also not a stage reading. Bing states that structured data may support clearer grounding but does not guarantee visibility or grounding traffic, and that markup must accurately reflect visible content. A validation pass confirms markup syntax and nothing about ranking.
Finally, platform documentation is policy and technical guidance, not measurement. Google's March 2024 post announces policies and a core update; it reports no prevalence data, effect sizes or typical outcomes. Bing's guidelines are condensed and state no ranking weights. Any protocol built from these documents can describe what a platform says it does; it cannot infer how much any factor matters.
Write the protocol so the stages cannot blur
A workable protocol records, for each stage: the exact URL checked, the check used, the moment of the check, and the observed status verbatim. Then it records the research question in one sentence, the comparison or control, the intervention description, and the confounders listed before data collection begins. Confounders worth naming include a concurrent ranking-system update, changes to the page while the window is open, near-identical content on other URLs, and the possibility that the control URL differs from the test URL in more than one way.
Google's announcement illustrates why confounder discipline matters. It describes the March 2024 core update as involving changes to multiple core systems, with a rollout that could take up to a month and a warning of more ranking fluctuations than a regular core update (Google Search Central). A window overlapping such a rollout cannot support a clean before-and-after interpretation of a ranking comparison, and the protocol should say so rather than absorbing the fluctuation into a conclusion.
The same announcement sets out three spam policies introduced in March 2024: expired domain abuse, scaled content abuse, and site reputation abuse, with the site reputation abuse policy taking effect from May 5, 2024. The definitions are framed around purpose, not mechanism: scaled content abuse covers generating many pages primarily to manipulate Search rankings rather than help users, whether produced by automation, humans or a combination. A protocol that measured whether content was automated would not test that policy's stated condition. This is a further argument for precise operational definitions before measurement.
Google also states that its core ranking systems are primarily designed to work at the page level, with some site-wide signals also considered. If your question is about a host, note that a page-level observation cannot establish a property of the host, and mark the difference explicitly in the protocol.
Keep the record in one place
The study design tool provides fields for the research question, host and page, observation window, comparison or control, intervention description, confounders and an evidence URL, and exports the protocol as JSON. Nothing is scored and no findings appear until you have measured. Pair it with the companion guides on designing a comparison you can interpret and keeping a reproducible evidence log, and read what the parasite SEO label hides for the policy framing.
A stage-separated protocol is modest by design. It will not tell you how a host ranks; it will tell you what you observed, at which stage, under which conditions, with which sources. That is the difference between a notebook and an advertisement.