How to Use Full Page Hash

What is it?

Full Page Hash is the simplest extraction method to set up. Instead of targeting specific elements, Verid:

1. Downloads the full page HTML
2. Strips out noise that changes on every load (scripts, styles, CSRF tokens, nonces, comments)
3. Computes a SHA-256 hash of the normalized content
4. Stores the hash and content length as two fields

On the next run, if the hash is different, something on the page has changed - and you get a notification.

When to use it

• You want to be alerted to any change on a page and don't need to know exactly what changed
• The page has no predictable element structure (dynamically generated, heavily templated)
• You're monitoring a simple status page, an announcement page, or a static document
• You want to set up monitoring in seconds without inspecting the DOM

When to pick something else

Full Page Hash doesn't tell you what changed - just that something did. For that reason it's less useful when:

• The page has banner ads, rotating content, or session-specific data that changes constantly (use CSS/XPath/Regex to target only the stable part)
• You want the actual value of what changed (e.g., the new price), not just that it changed

---

How to configure it

No fields to configure. Just select Full Page Hash as your method:

{
  "method": "full_page"
}

That's it.

What gets normalized before hashing:

Verid removes the following before computing the hash so that cosmetic page noise doesn't trigger false alerts:

• <script> tags and their contents
• <style> tags and their contents
• <noscript>, <iframe>, and <svg> tags
• data-csrftoken and data-nonce attributes
• HTML comments (<!-- … -->)
• Collapses consecutive whitespace into single spaces

Output fields:

{
  "page_hash": "a3f5b2c1d4e6f7890abc...",
  "content_length": "42381"
}

• page_hash - SHA-256 hex digest of the normalized HTML body
• content_length - byte length of the normalized content

A change in either field triggers an alert.

---

Example 1 - Monitor a status page

Goal: Get notified whenever a service's status page is updated (incident posted, resolved, etc.).

URL: https://status.example.com

Configuration:

{
  "method": "full_page"
}

Most status pages update their content when an incident occurs or is resolved. Full Page Hash will catch any such change immediately.

---

Example 2 - Watch a government or regulatory document

Goal: Know when a regulatory document or policy page is updated.

URL: https://regulations.example.gov/policy/data-retention

Configuration:

{
  "method": "full_page"
}

These pages change infrequently but importantly. You don't need to know which paragraph changed - just that the page is different from the last time Verid checked.

---

Example 3 - Monitor a terms of service page

Goal: Track when a service updates its Terms of Service or Privacy Policy.

URL: https://example.com/terms

Configuration:

{
  "method": "full_page"
}

When the page content changes, your alert fires. You can then review the diff manually.

---

Example 4 - Landing page launch detection

Goal: Know when a "coming soon" page goes live with real content.

URL: https://newproduct.example.com

Configuration:

{
  "method": "full_page"
}

A "coming soon" page usually has very little text. When the real landing page goes live, the content length and hash both change drastically - a clear signal.

---

Tips

• Pair with a short check interval for time-sensitive monitoring. If you're watching a flash sale page or a breaking news section, set the monitor to run every few minutes.
• It's false-alert-resistant by design. Scripts, styles, tokens, and comments are all stripped before hashing, so the normal "noise" of a page reload won't trigger alerts.
• Use it as a first pass. Set up a Full Page Hash monitor first to confirm the page changes, then refine with CSS/XPath/Regex to extract the specific field that matters.
• Content length is a secondary signal. If page_hash stays the same but content_length changes, that means the normalized text changed slightly in a way that still produced the same hash - extremely rare, but content_length acts as a backup check.

Common issues

Problem	Fix
Too many false alerts	The page has rotating ads or session-specific banners - switch to CSS/XPath to target only the stable content area
No alerts when you expected one	The change was only in a script or style tag that gets stripped - this is expected behavior; use a different method to capture that specific value