Choose a per-URL or sitewide scope

Apply a rule to one page, all monitored pages, or supported site files.

Last checked 21 August 2026

Scope controls which monitored pages run a custom check. Choose it after selecting a page target under Look in.

Choose This page for one monitored URL

Select This page when the requirement belongs to one specific URL. Then use Page to choose from the website's monitored URLs.

Examples include:

  • A conversion tag that should appear only on a confirmation page.
  • Legal wording required on a specific terms page.
  • A campaign title that must remain on one landing page.
  • A response header enabled only for a sensitive route.

Saving a new or edited This page check queues that URL immediately. The result is part of that page's check. The page must already be monitored.

If you later remove that monitored page, TechDash removes custom checks attached specifically to it. If the table ever shows Removed page, review the rule because its original page association is no longer available.

Choose Sitewide for every monitored URL

Select Sitewide when every monitored page should meet the same requirement. Good candidates are shared template signals such as an analytics ID, a production-only marker, a common security header, or a forbidden staging hostname.

Sitewide means every monitored URL in TechDash, not every URL that exists on the website. A URL is evaluated when its own scheduled or manual page check runs. Saving a sitewide page check does not immediately queue every monitored URL, so the initial results can arrive over time according to page schedules.

New monitored pages automatically become subject to applicable sitewide rules when their checks run. A disabled page does not run its normal scheduled checks until monitoring is enabled again.

Use sitewide scope carefully when the website has several templates. A value appropriate on product pages may be irrelevant on legal pages, documents, or utility routes. A broad rule can open separate failure evidence for many monitored URLs. In that situation, create one or more This page checks for representative pages, or choose a value that is genuinely shared by every monitored page.

Resource targets are always sitewide

robots.txt and sitemap.xml are website resources, not page targets. When either is selected under Look in, the dialog states that it always runs sitewide and hides the page scope controls.

A robots rule runs during robots.txt processing. A sitemap rule runs during daily sitemap resource processing. Saving either resource rule queues Site Resources for the website. The rule cannot be assigned to one monitored URL because the fetched file belongs to the website-level resource check.

Choose the narrowest accurate scope

Start from the actual ownership of the requirement:

  1. If one monitored URL owns it, choose This page.
  2. If all monitored URLs should have it, choose Sitewide.
  3. If it belongs to robots.txt or the fetched sitemap file, select that resource under Look in.

Scope does not change the matching method. TechDash still performs a case-insensitive literal substring search in the selected target. It also does not crawl unmonitored pages merely because a rule is sitewide.

After saving, run or review representative URLs from each relevant template. If a sitewide rule creates expected failures on pages where the value does not belong, narrow the scope instead of ignoring repeated incidents.

Worked example: require a checkout policy on one page

Suppose https://example.com/checkout must show 30-day returns, but product, legal, and account pages do not need that phrase. The statement matters because it reassures customers at the purchase decision.

Configure the custom check as follows:

  • Look in: Content
  • Scope: This page
  • Page: https://example.com/checkout
  • Match: Is found
  • Value: 30-day returns
  • Incident level: Warning
  • Notify: Send a notification

A pass means the case-insensitive literal substring appears in the filtered rendered body text captured for that monitored URL. It does not prove that every checkout variant shows the statement, or that it is visually prominent.

To test the consequence deliberately, temporarily change Scope to Sitewide and save. Select Run now on a monitored page that correctly does not contain the checkout statement. That page should fail, demonstrating why sitewide is too broad. Restore This page immediately. A real failure is the phrase disappearing from the checkout page after a template deployment.

The failed custom result appears with the affected monitored page's check results. TechDash opens Custom check failed at Warning level for that evidence. Because Notify is Send a notification, the transition is eligible for enabled desktop and webhook channels. With an incorrect sitewide scope, the repercussion can be several unnecessary incidents as different monitored URLs run.

Some failures are benign evidence of a scope mistake rather than a website defect. A checkout phrase missing from a privacy page is expected. Other apparent differences can come from consent, location, authentication, or a redirect. Verify that the rule is attached to the intended monitored URL, then compare TechDash's final URL and rendered content with the business requirement.

After restoring This page or repairing the checkout template, select Run now for the checkout URL. A fresh Good result verifies the rule against the current snapshot and recovers its incident. If the requirement truly applies to every template, use Sitewide, run representative pages manually, and allow scheduled checks to verify the remainder.

Related articles