--- title: Page Integrity & Defacement Monitoring description: Defacement and tampering monitoring: alerts when a page loads a script from a new host, vendor script code changes, a form posts elsewhere or a header weakens. canonical: https://watchfor.io/page-integrity-monitoring --- New # Page Integrity Monitoring: Catch Tampering, Not Every Deploy A card skimmer is one added script, and the page still returns 200 OK. WatchFor compares each page with a baseline you accepted and alerts on the change. Accept a release as the new baseline from your deploy pipeline Copy curl -X POST https://watchfor.io/api/v1/monitors//baseline -H 'Authorization: Bearer ' Run it as the last step of a deploy, once a check has seen the release (call check-now first, the docs have the full script): what that check saw becomes the baseline, so an intended change never alerts. The key needs write access (Settings, API keys). [Start watching your pages](/auth/sign-up)[See plans and page limits](/pricing) [Page integrity documentation](/docs/monitors/integrity)[Public API](/docs/api) ## What a Page Integrity Check Compares Every check against the baseline you accepted, never just the previous check, so a change cannot quietly become the new normal ### Script Sources, by Origin A script from a host your pages never loaded before is the classic sign of an injected skimmer. Scripts from your own site are expected to change names with every build and never count as a new source; a new third-party origin is a critical alert until you accept it or trust that source. ### Script Code, Not Just the URL The same script URL serving different code is how a compromised vendor or CDN file looks. Each script body is fingerprinted and compared with the accepted one; a change in third-party code is critical, in your own code a warning. Vendor tags that rotate their code every few minutes are recognized and compared by origin only. ### Forms, Frames and Redirects A login or checkout form that starts posting to another site, a new embedded frame, or a page that now redirects to a different host. Each is compared with the baseline and reported with the exact destination. ### Security Headers Content-Security-Policy, Strict-Transport-Security, X-Frame-Options and X-Content-Type-Options removed or weakened (an unsafe-inline added, a shorter HSTS max-age) is critical; other security header changes are a warning. Per-request CSP nonces are ignored. ### Spam Links and Tamper Words Five or more new external link domains on a page is how hidden SEO spam shows up. Built-in tamper phrases such as 'hacked by' plus your own words alert as soon as they appear in the visible text. ### Visible Text, With a Word Diff How much of a page's visible text differs from the baseline, with Low, Normal and High sensitivity (50, 25 or 10 percent) and a per-page override. CSS selectors leave out cookie banners, prices and feeds that change on their own. The page view shows the change word by word. ### A Real Browser When It Matters Browser mode renders each page like a visitor's browser, so scripts injected at runtime by a tag manager or another script are caught too, along with new places the page sends data to (beacons, fetch, WebSockets). It takes a screenshot of the baseline and of any check that finds a difference. ### Evidence in the Incident An incident names the page, the finding and the new host or header. In browser mode its root cause shows the screenshot of the check that opened it, and the page view puts Baseline and Now side by side, scrolling together. ## A closer look Each finding names the page and the change; the table shows text change. Baseline and current screenshots from a real browser, side by side. Nine rules, from a new script source or hijacked form to weakened headers. ## Why Compare Against an Accepted Baseline A naive HTML diff alerts on every deploy, every rotated build hash and every A/B test until nobody reads the alerts, which is exactly when a real injection gets through. Page integrity looks at what an attacker has to change to hurt your visitors: where scripts come from and what they contain, where forms send data, which headers protect the page, and what the page says. You decide what normal is. Accept a page, accept them all, trust a vendor's origin, or let your deploy pipeline accept each release, and everything else keeps alerting until someone looks. [Start monitoring now](/auth/sign-up) New third-party scripts, changed vendor code, form targets, headers, redirects and tamper words are critical Renamed first-party build files are ignored; new third-party origins and changed vendor code are not One click to accept a change, accept all pages, or trust a source A deploy-hook API call accepts each release automatically Optional auto-accept of unreviewed content changes after 1, 3, 6 or 24 hours; security findings wait for a person unless you include them Up to 50 pages per monitor, imported from your sitemap if you like Security incidents close only after three clean checks in a row Integrity incidents are never published to your status page on their own ## How Page Integrity Monitoring Works Pick the pages, let the first check record the baseline, get told what changed 1 ### Pick the Pages an Attacker Would Pick Create a Page integrity monitor for your site and list the pages that matter: home, login, sign-up, checkout, pricing. Import them from your sitemap if you prefer. Choose a sensitivity and, on Pro and above, whether to check them in a real browser. 2 ### The First Check Becomes the Baseline The first successful check of each page is recorded as its baseline: script sources and their code, forms, frames, links, headers and text. From then on every check is compared with it, not with the check before. 3 ### A Difference Opens an Incident A new script source, changed third-party code, a form pointing elsewhere, a removed security header, a redirect or a tamper word opens a critical incident on your usual channels and on-call. Text changes past your sensitivity, your own changed scripts and five or more new external link domains open a warning. 4 ### Accept, Trust or Fix Open the page to see exactly what differs, with a word diff and, in browser mode, screenshots. Accept it as the new baseline, trust a vendor's source for good, or fix the page. Your deploy pipeline can accept each release through the API, so your own changes never page anyone. ## Who Watches Their Pages Anyone whose pages are worth tampering with ### Online Stores and Checkout Pages E-skimming works by adding or changing a script on the payment page. A browser-mode monitor on checkout alerts on a new script source or changed script code within one check interval and keeps screenshots of what visitors were shown. PCI DSS v4.0.1 requirement 11.6.1 asks for change and tamper detection on payment pages, covering security-impacting headers and script contents as the browser receives them; this is the kind of mechanism it describes, and your assessor decides what counts for your scope. ### WordPress and Other CMS Sites A vulnerable plugin is the usual way in, and the payload is usually a script tag, a redirect for mobile visitors or hidden spam links. Page integrity catches all three without an agent or a plugin on the site, from the outside, the way visitors and search engines see it. ### Login and Sign-Up Pages A form whose action now points to another host is credential theft in one line of HTML. Form targets are compared with the baseline on every check, and a new third-party destination is critical. ### Agencies Watching Client Sites Dozens of client sites, each with its own plugins and release rhythm. One monitor per site, the pages that matter, the vendors you trust per client, and incidents routed to the same on-call schedules and channels as your uptime checks. ### Security Teams Watching Third Parties Analytics, chat, A/B testing and tag managers all run code on your pages that you do not control. Page integrity tells you when a vendor's code changes or a new vendor appears, so a supply-chain change is a reviewed decision rather than a surprise. ## Frequently asked questions What people ask before they point it at production pages [All questions→](/faq)[Ask us directly](/contact) What is page integrity monitoring? Page integrity monitoring checks that a web page still is what you published. WatchFor records a baseline of each watched page, its script sources and script code, forms, frames, links, security headers and visible text, and compares every check with it. A difference that matters for security, such as a new script source or a form sending data to another site, opens an incident. It is also known as defacement monitoring or tamper detection. How is it different from a keyword check or a change monitor? Will it alert on every deploy? What does browser mode add? What happens to third-party scripts that change all the time? When does an integrity incident close? How is it different from a Playwright browser check? Does an integrity incident show on my status page? Which plans include page integrity? Do I need to install anything on my site? ## From our blog Guides, deep-dives, and best practices from the WatchFor team [Security ### Magecart and injected scripts: how to catch a tampered page Oct 03, 2026·13 min readRead article](/blog/magecart-injected-scripts)[Security ### Security headers checklist (and how to keep them from silently disappearing) Oct 03, 2026·14 min readRead article](/blog/security-headers-checklist)[Security ### Content Security Policy Explained: what CSP actually stops Sep 08, 2026·6 min readRead article](/blog/content-security-policy-explained) ## Know When Your Pages Change Without You Create a Page integrity monitor, list the pages that matter, and the first check records the baseline. From then on a new script source, changed script code, a hijacked form or a weakened security header opens an incident. Page integrity is available from the Starter plan; the account takes a minute to create and no credit card is needed to start. [Watch your first pages](/auth/sign-up)[View documentation](/docs/monitors/integrity) --- Canonical page: https://watchfor.io/page-integrity-monitoring · Site guide: https://watchfor.io/llms.txt