Search the head, body, or filtered content

Choose the HTML or rendered text region that should contain the value.

Last checked 21 August 2026

Choose Head, Body, or Content for a rendered HTML page. The same value can match one target and not another.

Head searches rendered head markup

Head searches the HTML markup inside the rendered document's <head> element. Use it for markup rather than visible page copy, such as a script URL, analytics ID, verification meta tag, link attribute, or JSON-LD fragment.

You do not need to enter the complete element. A stable identifying substring is usually safer than copying a full tag whose attribute order or spacing may change. For example, an Is found rule for G-ABC123 can verify that an expected analytics ID occurs in head markup without depending on the entire script element.

Head is a literal HTML search. It does not parse tags, execute a selector, or prove that a referenced script loaded or ran successfully.

Body searches rendered body markup

Body searches the HTML markup inside the rendered document's <body> element. It includes element names, attributes, script text, hidden elements, and other markup that may not appear to a visitor as visible text.

Use Body for a script, embedded configuration, component attribute, form action, asset path, application marker, or forbidden staging hostname in body markup.

Because hidden and non-text markup is included, Body can match values that are not displayed as text. If the requirement concerns text rather than markup, Content is the narrower target, subject to the visibility limitations below.

Content searches filtered rendered body text

Content searches filtered text extracted from the rendered body. Use it when tags and attributes should not count, such as checking for a legal statement, support message, product phrase, or required disclosure.

This target is not a complete test of what a visitor can see. The extraction skips certain non-content tags and excludes text when its immediate parent has display: none or visibility: hidden. It does not reliably exclude text hidden by an ancestor, opacity, offscreen positioning, aria-hidden, or other visual and accessibility techniques. It also does not judge visual prominence, font size, or whether text is inside the viewport.

Client-side code has already had an opportunity to render the page before the snapshot is evaluated, so Content can differ from the original server HTML. However, late-loading widgets, consent choices, personalization, blocked resources, or an interrupted page load can still affect the text captured by TechDash.

Choose the narrowest accurate target

Choose Head for head markup, Body for body markup or embedded values, and Content for extracted body text when its filtering limitations are acceptable. For titles, H1 text, and HTTP response headers, use the more precise Title, H1, or Headers target.

Matching is case-insensitive literal substring matching. It is not regex or selector matching. Internal whitespace and HTML structure can prevent a copied phrase from matching markup exactly. Prefer a stable identifying portion, but make it long enough to avoid unrelated occurrences.

Verify an unexpected result

Run the monitored page again and compare the selected target with the current rendered response. Confirm the page URL, authentication, user agent, redirect destination, HTTP status, and consent state. Your everyday browser can have different state or identity. Visually hidden text can still be present in Content because its filter is not a complete visibility calculation.

Worked example: protect a returns disclosure

Suppose the checkout page must tell customers Returns accepted within 30 days. The text is important because customers need the policy before purchasing, and markup elsewhere should not satisfy the requirement.

Configure:

  • Look in: Content
  • Scope: This page
  • Page: the monitored checkout URL
  • Match: Is found
  • Value: Returns accepted within 30 days
  • Incident level: Warning
  • Notify: Send a notification

A pass means the case-insensitive literal substring appears in TechDash's filtered rendered body text. It is stronger evidence for customer-facing copy than a Body match, which could find the phrase in a script or attribute. It still does not prove true visibility because of the filtering limitations above.

For a deliberate failure, temporarily change Look in to Head while keeping the same value, save, and select Run now for the checkout page. The rule should fail if the disclosure exists only in body content. Restore Content after the test. A real failure occurs when a template deployment removes or changes the disclosure.

The failed result appears with the checkout page's latest checks, and TechDash opens Custom check failed at Warning level. With Notify set to Send a notification, the transition is eligible for enabled desktop and webhook channels. The incident evidence identifies the rule and affected page, but it does not provide a visual proof of placement.

A benign failure can result from consent state, personalization, a late-loading widget, authentication, or an interrupted render. A benign pass is also possible if matching text remains hidden by an ancestor or offscreen. Verify the final URL and captured rendered response, then inspect the page as a customer would before deciding whether the disclosure is genuinely available.

Restore the correct target or page copy, then select Run now. A fresh Good result recovers the incident. Confirm the current page visually as a separate verification step when visibility itself is the business requirement.

Related articles