Defacement Monitoring: Detect a Change and Verify Its Cause

A page-change monitor can flag a difference from a saved baseline. It cannot determine from a checksum alone whether the cause is an attack, an authorized release or ordinary dynamic content. Treat the alert as a prompt to verify evidence.

Choose a meaningful baseline

Select public URLs representing important templates and record the expected title, canonical, robots directives and content. Note planned deployments and dynamic elements that may change frequently. SearchBastion Site Monitor performs scheduled checks of configured URLs; it is not a continuous browser session, source-code integrity scanner or automatic incident-response system.

Triage a detected difference

1. Confirm that the response belongs to the intended page, rather than a login or error screen.
2. Compare the changed fields with the previous snapshot.
3. Check the release history and authorized content changes.
4. Reproduce the issue safely and escalate confirmed unauthorized changes to the responsible team.
5. Preserve evidence without publicly exposing credentials or customer records.

Worked example: an unexpected homepage title

Suppose a scheduled check observes an unfamiliar title. Verify the live response and determine whether a planned campaign explains it. If the page is genuinely modified without authorization, follow the incident process, review access and dependencies, and restore a known-good state through controlled deployment. A monitor alert alone neither identifies an attacker nor prevents subsequent changes. This case is illustrative.

Test the monitoring process

Perform an authorized harmless change on a test page, verify the next scheduled observation and confirm that the assigned owner receives the configured notification. Measure the actual detection and response times instead of promising instant discovery. Test the rollback and escalation procedure as carefully as the alert.

For suspected compromise, use Google's hacked-content guidance alongside application incident procedures. A public header check is supplementary configuration evidence, not proof of remediation.