Search response headers, title tags, or H1 headings

Target concise SEO and HTTP signals with a Custom Check.

Last checked 21 August 2026

Use Headers, Title, or H1 for one concise page signal. These targets are more precise than searching all rendered HTML.

Search response headers

Headers searches formatted HTTP response headers. Each captured header is a name: value line, searched across that text as a case-insensitive literal substring.

Use Headers for a site-specific requirement such as:

A required header name and token, such as x-robots-tag: noindex.
A cache policy fragment.
A content-security-policy source that must be present or absent.
A deployment marker returned by the website or hosting service.

Include the header name when the value alone could occur in another header. For example, x-environment: production is more specific than production.

This is text matching, not policy validation. Repeated or normalized headers may differ from another network tool. Matching is case-insensitive.

Search the page title

Title searches the rendered page's title signal for a mandatory phrase, product name, or forbidden fallback.

For example:

Is found with Support can require that phrase in a support page title.
Isn’t found with Untitled can detect a known fallback.

Short substrings can produce accidental matches, so use enough of the expected phrase. Built-in title checks detect an empty rendered title, per-page changes, and duplicates across monitored pages. Product documentation opportunities for title length are not current incidents. Use a custom check for required or forbidden phrases.

Search the primary H1

H1 searches the primary H1 captured in the page snapshot for a site-specific phrase or forbidden fallback.

This target does not search every heading or all visible text. For customer-facing copy anywhere on the page, use Content. Built-in H1 checks track primary-H1 changes and duplicates across monitored pages. They do not emit dedicated missing-H1 or multiple-H1 incidents, so use a custom check for a required or forbidden phrase.

Availability and document type matter

Page custom checks use the normal page-check pipeline. HTTP error and redirect availability gates run first. For an unusable response, optional checks can be skipped instead of reporting every expected value missing.

HTML-only checks are skipped for non-HTML responses. A PDF, image, XML response, or other document does not provide normal Title or H1 signals. Use dedicated robots.txt and sitemap.xml targets for those supported files rather than adding them as ordinary monitored pages.

Test the exact signal

Before enabling a high-impact alert:

Select the narrowest Look in target.
Enter a stable literal value, not a regex or selector.
Start with Incident only if you are unsure how the response is formatted.
Run the page and inspect the first result.

If TechDash does not match a browser-visible value, check the monitored URL, final redirect, authentication, user agent, security response, rendered page, and selected signal. A phrase in Body does not satisfy Title, and a meta element with name="h1" does not satisfy H1.

Worked example: prevent a fallback title

Suppose the pricing page must never ship with the fallback title Untitled page. This matters because a poor title can confuse customers, browser tabs, and search results.

Configure the rule:

Look in: Title
Scope: This page
Page: the monitored pricing URL
Match: Isn’t found
Value: Untitled page
Incident level: Warning
Notify: Send a notification

A pass means the case-insensitive literal substring is absent from the title signal extracted from TechDash's rendered page. It does not prove that the remaining title is unique, well written, or the ideal length. Use built-in title checks for those broader quality conditions.

For a deliberate failure, temporarily change Value to a phrase that is known to occur in the current title while keeping Isn’t found, save, and select Run now on the pricing page. Restore Untitled page after confirming the workflow. A real failure occurs when a deployment replaces the intended title with the fallback.

The failed assertion appears with the pricing page's check results and opens Custom check failed at Warning level. A fallback title normally needs prompt investigation but does not by itself prove immediate access, compliance, or sitewide business failure. Use Critical only when your specific title requirement has that demonstrated impact. With Notify set to Send a notification, the transition is eligible for enabled desktop and webhook channels. The incident evidence shows the affected page and failed literal assertion; it does not rewrite the page.

A benign failure can occur if the fallback phrase is deliberately part of a longer valid title, because substring matching does not understand title meaning. A result can also differ because of a redirect, authentication response, personalization, or rendered page state. Verify the final URL, HTTP result, and actual extracted title before changing the rule.

Correct the title or restore the production rule, then select Run now. A fresh Good result means the forbidden substring is absent and recovers the custom incident. If the request returns an unusable error page, the optional title check may be skipped, so resolve the availability incident and run again for direct title evidence.