Skip to main content

Production website integrity

Detect unauthorized website changes while the page still looks “up”

Uptime checks can stay green while a homepage headline, payment instruction, canonical URL, or CTA is altered. OnChange watches the rendered result and gives incident responders a precise text, visual, and metadata diff they can verify quickly.

Text integrityVisual diffsSEO hijack signalsCommit correlation

Integrity change detected

Unexpected homepage modification

www.acme.com · HTTP 200 · checked 02:14 UTC

Unattributed change

Primary CTA

High
Download the desktop appVerify your account to continue

The main action changed outside the approved release window.

Destination URL

High
acme.com/downloadaccount-verify.example/login

The new CTA points to a different registrable domain.

Visual region

Medium
Hero changed by 38%

The current screenshot differs materially from the last known production state.

Response
200 OK
Commit
No match
Alerted
Webhook + Slack

Integrity risk

Availability and integrity are different signals

A healthy response code only proves the server answered. Integrity monitoring asks whether customers received the page, message, and destination your team intended to publish.

Defacement can pass uptime checks

Altered copy, links, or visuals can be served successfully with a 200 response and normal latency.

Small edits can carry high risk

A changed payment address, download link, support number, or login destination may matter more than a full-page outage.

Intent must be verified quickly

Commit correlation helps responders separate a planned release from a production change that has no obvious owner.

High-risk surfaces

Cover the customer-facing integrity surface

Use several independent signals. A single text hash can miss a visual overlay; a screenshot alone can hide a changed destination or metadata field.

Headlines, CTAs, and instructions

Detect changed customer messaging, payment details, support contacts, download instructions, and account actions.

Linked actions and customer journeys

Combine visible CTA copy with rendered and structural diffs to investigate unexpected changes in the actions customers are asked to take.

Rendered visual state

Compare browser-rendered screenshots to catch overlays, replaced assets, layout damage, and injected visible content.

Title, canonical, and robots

Catch search-facing tampering or accidental head-tag changes even when the visible page body remains familiar.

Expected deploy context

Match detected changes against recent repository activity to identify likely planned releases and suspicious gaps.

Incident-channel routing

Send material changes through Slack, Discord, email, or webhooks so the existing response workflow can take over.

Incident response procedure

Add integrity evidence to incident response

OnChange does not remediate an incident. It shortens the time between an altered page and a responder having evidence precise enough to confirm and escalate.

  1. 01

    Prioritize high-consequence pages

    Start with login, checkout, payment, downloads, contact details, and the highest-traffic public entry points.

  2. 02

    Capture stable text and visual baselines

    Target meaningful page regions, remove routine noise, and keep both rendered and structured change signals active.

  3. 03

    Route unexpected or unattributed changes

    Use alert rules and commit context to raise the changes that fall outside normal release activity.

  4. 04

    Verify, contain, and preserve evidence

    Confirm the diff, follow your rollback or incident plan, and share the restricted evidence record with responders or stakeholders.

What the response team gets

  • Detection beyond HTTP uptime and latency
  • Exact changed copy, structure, metadata, and visuals
  • A timestamped production-state comparison
  • Deploy context for faster intent verification
  • Alerts routed into existing incident workflows
  • A revocable evidence link for coordinated review

Website integrity FAQ

Questions incident responders ask before deployment

Can OnChange detect a defaced page that still returns HTTP 200?
Yes. OnChange compares rendered text, page structure, screenshots, and SEO signals, so unexpected content or visual changes can be detected even when uptime monitoring considers the response healthy.
Does OnChange prevent website attacks?
No. OnChange is a detection and evidence layer. It does not block requests, remove malware, patch vulnerabilities, or replace a WAF, endpoint protection, CSP reporting, or a SIEM.
How do I reduce alerts from planned deployments?
Use selectors and ignore rules to remove noisy regions, then connect a Git provider so detected production changes can be correlated with recent commits. Planned releases become easier to confirm; unattributed changes deserve closer review.
Which pages should be monitored first?
Start with the homepage, login, checkout, payment instructions, contact details, download pages, and high-traffic campaign pages. These surfaces carry the highest brand, fraud, and customer-impact risk when altered.

Extend website integrity coverage

Add an integrity check to the pages customers trust

Monitor the rendered content and destinations that carry the most brand, fraud, and customer-impact risk. Start free and route the first unexpected change into your response workflow.

Start with 5 free monitors