A crawl test is easier to interpret when its inputs stay fixed and each outcome has a clear definition. Begin with a small baseline before combining redirects, embedded resources, sitemaps and repeated submissions. The aim is to identify what happened to a known collection of pages, rather than to turn every server request into a success claim.
Write one question and define the cohort
A useful starting question is whether a source page containing ordinary HTML links leads to verified crawler requests for the linked documents during a declared interval. Indexing is a second outcome. Traffic is a third. A page can receive a request without being indexed, and an indexed page may receive no observed clicks during a short review period.
List the target URLs before publication. Twenty documents can be a manageable example cohort, but twenty is a design choice, not a search-engine requirement. Give each document a stable address, useful content and an explicit canonical policy. Record whether the domains or content have appeared in earlier tests; changing a folder name does not erase that history.
Preserve the pages and configuration before exposure
Save a manifest, content fingerprints and the routing configuration. A fixed link graph lets a later reader inspect which documents were available from each source. If the test uses two source articles with ten links each, keep that mapping unchanged throughout the observation window. Do not let another campaign quietly replace older links on the same article.
Check HTTPS, status codes, robots rules, canonical addresses and logging with a labeled test client. A User-Agent that you set to Googlebot remains your own test request. Preserve the quality checks separately so they cannot be mistaken for evidence that Google discovered the cohort.
Keep publication and seeding as different timestamps
Record when pages became available and when the declared discovery action happened. A sitemap submission, a manual indexing request and a link added to an existing article are different exposures. If the design is source-only discovery, do not additionally submit target pages and then attribute their visits solely to the source link.
When a source article must already be receiving crawler visits, keep its preparation interval separate from the moment target links are inserted. Evidence from before the insertion does not show that a crawler saw the new links. If you revise a title, address or article during preparation, create a new version and retain the earlier interval instead of overwriting it.
Measure the path without skipping a boundary
First count verified requests and distinct URLs on the source. Next count verified document requests at the target. If the source returns a redirect, record its destination, but do not assume the client followed it. Without access to target logs, that final request remains unobserved. This distinction also applies to a normal link: returning the HTML establishes an opportunity for discovery, not a guaranteed download of every linked page.
Observe index status separately with the appropriate property access. The URL Inspection API reports Google's indexed version; it is not a live page test or a submission operation. Preserve checked time and canonical information alongside the result. If only part of the cohort has been checked, report the indexed count within that measured subset and its coverage of the full cohort.
Close with the actual observation window
A schedule might include early checks followed by a seven-day review, but those are research checkpoints rather than deadlines for Google. If the operator stops after several hours, label the conclusion as an early result and retain the original schedule. Missing data, a collection outage and a measured negative observation need different labels.
Finish the record with unresolved explanations and the next comparison worth running. A pilot on reused domains can guide implementation while still being a weak causal comparison. For stronger evidence, repeat the question under a declared independent setup and keep both records. A useful baseline makes those limitations visible rather than promising an indexing outcome.