How to Monitor Website Changes and Capture Evidence of Security Issues
Build a repeatable workflow to spot unexpected website changes, preserve dated captures, and investigate alerts alongside system logs.
To monitor website changes for possible security issues, establish a known-good baseline for important public pages, capture them on a regular schedule, compare each new result with that baseline, and alert a person to review meaningful differences. Preserve dated captures and relevant logs when a change is unexpected. Treat an alert as an investigation lead: a changed page or screenshot alone does not show who made the change or prove that the site was compromised.
A screenshot records what a capture system rendered at a particular time. For an investigation, pair it with the source URL, capture time, relevant application and infrastructure records, and a record of how evidence was collected and handled. CISA recommends collecting relevant evidence and accounting for it in a detailed log; NIST describes webpage-change alerts as one possible indication of an issue and emphasizes the value of properly configured logging. CISA incident response playbooks · NIST SP 800-61 Rev. 2.
1. Define pages, states, and owners
Start with a short inventory of public pages where an unexpected change would matter. The right scope depends on the site; there is no universal page list. Possible candidates include the home page, login page, security or service notices, important product or payment pages, and public pages that communicate incident status.
- Record the canonical URL, page owner, business importance, and expected content or behavior.
- Decide whether to capture the first viewport, a full page, or a specific element. A full-page capture can reveal injected content below the fold; a targeted element can reduce noise when the rest of the page changes routinely.
- Document relevant page states: locale, viewport, logged-in or logged-out state, query parameters, and any consent or interstitial behavior.
- Assign who receives alerts and who can confirm whether a deployment, content edit, campaign, or other authorized change explains them.
Public-page monitoring does not automatically cover authenticated workflows. If a relevant state requires a session, define a safe, approved capture method and account for authentication, session expiry, and sensitive data in your organization’s procedures.
2. Capture and document a known-good baseline
Take the first capture when the page is in a state its owner recognizes as correct. Record enough context to repeat it: URL, time in UTC, viewport and capture settings, redirect or load outcome, and any limitation such as a page requiring authentication. Keep the rendered screenshot; where your collection process supports it, retain relevant HTML, response details, or application records as well.
A baseline is a comparison point, not a statement that the server is safe. If you later discover that the baseline was already altered, preserve it as collected and establish a new baseline only after the responsible owner verifies the page.
3. Schedule repeatable checks
Choose an interval based on the page’s risk, expected update frequency, and the time available to review alerts. Use the same URL, viewport, wait behavior, and capture scope on each run. A change monitor may compare rendered images, text, HTML, availability, or a combination; check what its alerts actually represent. Product schedules, coverage of authenticated pages, retention, exports, and noise filtering vary.
For a small site, a scheduled job can call a browser automation library and save a screenshot. The example below uses Playwright with Node.js. Install it with npm install playwright, then install its browser with npx playwright install chromium. Set MONITOR_URL and run with node capture.mjs. The script saves a timestamped PNG and a JSON sidecar with URL, time, status, and final URL. Store output in a restricted directory and send it to the retention system your organization uses.
// capture.mjs
import { chromium } from 'playwright';
import { mkdir, writeFile } from 'node:fs/promises';
const url = process.env.MONITOR_URL;
if (!url) throw new Error('Set MONITOR_URL to the page to capture');
const now = new Date();
const stamp = now.toISOString().replaceAll(':', '-');
const outDir = process.env.CAPTURE_DIR ?? './captures';
await mkdir(outDir, { recursive: true });
const browser = await chromium.launch({ headless: true });
try {
const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
const response = await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 45000 });
// Allow a brief, fixed settling period for client-rendered content.
await page.waitForTimeout(1500);
const pngPath = `${outDir}/${stamp}.png`;
await page.screenshot({ path: pngPath, fullPage: true });
const metadata = {
captured_at_utc: now.toISOString(),
requested_url: url,
final_url: page.url(),
http_status: response?.status() ?? null,
viewport: { width: 1440, height: 1000 },
full_page: true,
screenshot_file: pngPath,
};
await writeFile(`${outDir}/${stamp}.json`, JSON.stringify(metadata, null, 2));
console.log(JSON.stringify(metadata));
} finally {
await browser.close();
}Run this from a scheduler or CI job at the interval you chose. Avoid overlapping runs if a capture can take longer than the schedule interval. For a first version, preserve every scheduled result; add image or text diffing after you know which routine page changes create noise. A screenshot file is not, by itself, tamper-evident storage. Use access controls, backups, and evidence-handling procedures appropriate to the investigation.
4. Compare changes and triage alerts
Review the changed region or content against the previous known-good capture. Record the comparison result and who reviewed it. Filter predictable noise only after confirming that the filter does not hide content relevant to the security purpose.
| Signal | What it can tell you | What it cannot establish alone |
|---|---|---|
| Rendered screenshot difference | Visible appearance changed between captures. | Which account or process caused the change, or whether the server was compromised. |
| Text or HTML difference | Page content or markup changed, including changes not obvious visually. | Whether the change was authorized or malicious. |
| Availability or load failure | The page could not be retrieved or rendered as expected from the monitor. | Whether the cause is an attack, deployment, network problem, or monitor issue. |
| Application, server, or network logs | Context about activity around the change, when logging is configured and retained. | A complete account of activity if relevant logging was absent or incomplete. |
- Check deployment records, content-management history, and owner notifications for authorized activity.
- Verify the change from a second capture or independent observation when appropriate. Preserve the original alert and result even if it turns out to be routine.
- Compare the capture time with relevant application, audit, perimeter, network, endpoint, transaction, connection, performance, and user-activity records, as applicable.
- Escalate according to your incident response process when authorized activity does not explain the change or other signals support concern.
Do not clear an alert merely because the page looks normal on a later visit. A transient change may still matter; retain the before-and-after records and investigate the time window.
5. Preserve evidence and correlate it with logs
If an incident is suspected, preserve the capture, alert, comparison output, relevant logs, and the context needed to interpret them. CISA’s playbooks advise collecting and preserving evidence under applicable policies and standards and recording its handling in a detailed log. The playbooks are written for federal response contexts; other organizations should follow their own procedures and applicable standards.
- Keep the original capture unchanged; make working copies for annotation or analysis.
- Record who collected, accessed, copied, transferred, or analyzed each item, and when. Include file names, source systems, relevant time zones, and any transformations.
- Record clock assumptions. A capture timestamp is useful only in relation to the monitor clock and the systems being correlated.
- Protect access and retention. Confirm how long the monitor keeps results, what can be exported, and whether those records fit your process; do not assume vendor retention or export behavior.
- Collect supporting records from relevant systems and network boundaries. Page monitoring cannot replace correctly configured application and system logging; NIST notes that disabled or improperly configured logging can leave incidents without useful log evidence.
A capture and handling log can support investigation, but a screenshot does not establish who caused a change, what happened on the server, or legal admissibility. Those conclusions require broader analysis and applicable procedures.
6. Choose a monitoring approach
Compare approaches by what they capture, how repeatable they are, and how useful their records are during review. A do-it-yourself browser job gives control over capture settings and storage but leaves scheduling, comparisons, alerting, retention, and maintenance to you. A monitoring service may bundle those steps; verify its capabilities and terms directly rather than inferring them from a screenshot feature.
| Decision | Questions to answer |
|---|---|
| Captured state | Does it preserve a rendered screenshot, text, HTML, metadata, availability, or several of these? |
| Repeatability | Can it use consistent viewport, page scope, wait behavior, redirects, and authenticated state where needed? |
| Noise handling | Can routine counters, banners, or layout changes be excluded without hiding meaningful page changes? |
| Alert review | Who receives an alert, and does it include old and new states or a link to a dated capture? |
| Retention and export | How long are records kept, how can they be exported, and can they be retained under your organization’s process? |
| Integrity and provenance | What records exist for capture time, source URL, hashes, or replay, and are they suitable for your needs? |
Vendor feature statements are not independent verification, and capture features alone do not guarantee evidence quality. Confirm current coverage, retention, data handling, and export options before relying on a service.
7. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. For a scheduled capture, make a GET request with the page URL; save the response alongside your own timestamp and monitoring metadata. See the ScreenshotNeo API documentation for options such as full-page capture, waiting, selectors, format, custom headers and caching. This captures a page on demand; your scheduler, comparison logic, alert routing, and evidence retention remain part of your workflow.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));Replace the example URL with a page you are authorized to capture. Store the API key outside source control. ScreenshotNeo removes cookie and consent banners, popups, and chat widgets before the shot; each of those cleaning steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. These page captures can help with visual monitoring, but they do not replace system logs or evidence-handling controls.
Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.
8. Troubleshooting scheduled captures
| Symptom | Common cause | What to check or change |
|---|---|---|
| Every run looks different | Dynamic timestamps, rotating content, ads, personalization, or inconsistent viewport and timing. | Keep capture settings consistent; compare text or a stable selector; filter only known routine regions and retain enough context to review them. |
| Capture is blank or incomplete | Client rendering has not finished, a required element is delayed, lazy content has not loaded, or the request failed. | Check final URL and response status, wait for a stable selector or known delay, and record the outcome instead of treating a blank image as a clean baseline. |
| Expected content is missing | The capture is logged out, redirected, in the wrong locale, or blocked by a consent or interstitial state. | Record the intended page state; configure an approved authenticated flow if necessary; verify redirects and consent behavior. |
| Alert appears after a deployment | The page changed as part of authorized work. | Correlate with release and content records, ask the page owner, and document the resolution while retaining the capture. |
| No alert despite a suspected change | Monitoring scope missed the region or state, the schedule failed, or noise filtering suppressed the change. | Check job health and coverage; compare the raw capture; review selectors and filters; confirm that alert delivery works. |
| Different timestamps across records | Systems use different time zones or unsynchronized clocks. | Store timestamps in UTC where possible and document source clock, timezone, and known offsets before correlating. |
| Monitor becomes a source of sensitive data | Captures include account details, private content, or tokens embedded in page state. | Restrict capture scope and access, avoid secrets in URLs, and apply your organization’s retention and access controls. |
9. Performance, reliability, and cost
- Frequency: More frequent checks can surface changes sooner but create more captures and reviews. Choose a schedule the owner can monitor and respond to.
- Page weight: Full-page captures, large images, and long waits can take more time and storage. Capture only the scope needed for the monitoring question.
- Reliability: A capture job can fail independently of the monitored site. Track job success, status codes, final URLs, timeouts, and alert delivery so monitor failures do not look like healthy pages.
- Noise: A visual diff can be sensitive to layout shifts and dynamic elements. Establish repeatability first, then adjust scope or filters with review.
- Cost: Estimate checks per month as pages multiplied by runs per page, then account for retries and extra capture states. Also budget for storage, alerting, and the time needed for triage. Confirm each provider’s billing, retention, and failure handling before deployment.
10. FAQ
Does a changed page mean the website was hacked?
No. It is a signal to investigate. Confirm whether authorized work explains it and correlate the time with relevant logs and other telemetry.
Is a screenshot enough to preserve security evidence?
Usually not by itself. Preserve its context and handling history, and collect relevant system, application, and network records under your incident process.
Can a page monitor replace application logging?
No. It observes selected page states. Properly configured system and application logging provides different context and may be essential to reconstruct activity.
How often should pages be checked?
There is no universal interval. Choose one according to page risk, expected change rate, and the team’s capacity to review alerts.
Should routine visual changes be ignored?
Classify and document known routine changes. Filters can reduce noise, but periodically review them to ensure they do not hide meaningful changes.
Sources
- CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks.
- NIST, SP 800-61 Rev. 2, Computer Security Incident Handling Guide. NIST marks Rev. 2 withdrawn and superseded by Rev. 3; consult the current publication for current guidance.
