Web Monitor

# web-monitor

Web Monitor

## Overview
Web Monitor is the skill of tracking important web pages so you can react before changes hurt your pipeline, positioning, pricing, or delivery quality. A one-person company cannot manually re-check competitor pages, vendor pricing pages, partner directories, and platform policy pages every day. This skill gives you a repeatable monitoring workflow with clear alerts and clear next actions.

## When to Use This Skill
Use this when you depend on external pages for revenue or operations, including competitor offer pages, referral directories, ad platform policy pages, API pricing pages, and marketplace listings. Use it when sudden changes can create churn risk, margin compression, or broken promises in your sales copy.

## What This Skill Does
This skill sets up focused page watchers, records snapshots, computes diffs, and helps you prioritize the business impact of each detected change. It is not just about collecting updates. The goal is to convert page changes into actionable decisions: update your offer, adjust pricing, revise your sales page, or trigger a customer communication.

## How to Use
Step 1: Define your monitored page set by business risk. Start with pages tied to pricing, acquisition channels, policy constraints, and delivery dependencies.

Step 2: Attach a business tag to each monitored page: `revenue`, `conversion`, `delivery`, `compliance`, or `strategic-watch`.

Step 3: Monitor only the stable section that matters (for example pricing table or policy body) to reduce false alerts from navigation, ads, or timestamps.

Step 4: Run checks on a fixed cadence. Daily for pricing and policy pages, weekly for lower-risk strategic pages.

Step 5: Triage each detected change with a simple severity rubric:
- `P0`: immediate revenue risk or compliance risk
- `P1`: conversion or margin impact
- `P2`: informational change with no immediate action

Step 6: Log the action taken for each meaningful change: update positioning, update offer copy, update onboarding docs, or update internal SOPs.

Step 7: Review weekly what changed, what actions were shipped, and what impact was observed in leads, conversion, churn, or support load.

## Output
The output should include:
- Monitored URL inventory with risk tags and owners
- A dated change log with before/after snippets
- Severity labels (`P0/P1/P2`) for each alert
- Action decisions and shipped updates
- A short weekly summary for decision review

## Common Mistakes
Do not monitor too many pages without priority labels.
Do not treat every diff as urgent without impact scoring.
Do not monitor entire pages when a specific selector is enough.
Do not collect alerts without documenting what decision was made.
Do not keep monitoring pages that have shown zero strategic value for multiple cycles.

## Example Monitoring Set for a Solo Operator
- Competitor pricing page and offer page
- Your top acquisition channel policy page
- Your payment processor fee and policy updates
- Your primary AI vendor pricing or usage policy page
- Your own sales page and checkout page for unexpected content drift

## What Good Looks Like
A healthy monitoring workflow catches material external changes within one cycle, routes them through a clear triage process, and leads to concrete updates in your pricing, messaging, delivery, or risk controls. The system should reduce surprises and improve decision speed, not create alert fatigue.

## Direct Answer
Use this skill when external page changes can alter pricing, margin, compliance, or delivery. Monitor only the pages tied to real business risk, diff the stable section that matters, score the change `P0/P1/P2`, and log one shipped action plus proof for every alert that actually matters.

## Evidence To Collect
- The monitored URL, selector, and business-risk tag
- The previous snapshot and the changed snapshot
- The diff excerpt or screenshot showing what changed
- The severity decision and the business impact it could create
- The shipped action and the metric used to confirm whether the response worked

## Source Links To Cite
- The live page being monitored
- The vendor, platform, or policy document that changed
- The internal page, SOP, or offer that had to be updated in response
- The analytics or search report used to measure post-change impact

## Freshness Reinforcement (2026-04-08)

- Added an explicit severity rubric tied to business impact instead of generic "change/no change" monitoring.
- Added evidence requirements for snapshot pairs, diff excerpts, and shipped-response proof.
- Added a comparison grid so alert quality is judged on impact, not raw diff volume.
- Added scorecard, evidence-pack, named examples, and FAQ sections so the page works as an operator system instead of a generic utility description.

## Authority and Citations Table

- HTTP validator signal: `ETag` is a standard server response header that helps confirm whether a resource changed between checks. Source: MDN ETag header - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
- Change-timestamp signal: `Last-Modified` is a standard response header you can compare when monitoring page freshness and update timing. Source: MDN Last-Modified header - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified
- Public-page impact check: If a monitored change affects your public pages, compare clicks, impressions, CTR, and average position for the affected URLs. Source: Google Search Console performance report - https://support.google.com/webmasters/answer/7042828
- Conversion impact check: Response actions should be measured against named conversion or engagement outcomes, not only traffic movement. Source: Google Analytics key events report - https://support.google.com/analytics/answer/12571843
- Compliance response guardrail: If a monitored policy or pricing change affects public promises, disclosures, or endorsements, update customer-facing claims promptly and accurately. Source: FTC truth in advertising basics - https://www.ftc.gov/business-guidance/resources/advertising-marketing-internet-rules-road

## Source-Backed Comparison Grid

- Competitor pricing change: compare the old pricing snapshot to the new pricing snapshot, then compare your response page's conversion or close-rate movement after the update.
- Vendor policy change: compare the exact policy diff to your internal SOP or onboarding copy before and after the response so you can confirm the risk was actually removed.
- Marketplace listing change: compare listing copy, category placement, review count, or pricing tier against the prior snapshot before changing your acquisition plan.
- Search-surface change on your own page: compare Search Console clicks, impressions, CTR, and average position across the same pre/post window after you react to the change.
- Offer-page response: compare GA4 key-event counts or lead-quality signals before and after the revised page, not just the existence of the diff itself.

## Monitoring Scorecard

- monitored page or page set this week
- business-risk tag
- baseline state and changed state
- severity label assigned
- action shipped in response
- proof asset created: diff, screenshot, report, or page update
- metric checked after the response
- result after review window: win, mixed, loss, or informational only
- next page or risk area to watch

## Evidence Pack Template

- Review date (UTC): `YYYY-MM-DD`
- Monitored URL: `canonical URL`
- Selector or section watched: `pricing table | policy body | offer block | directory listing`
- Business-risk tag: `revenue | conversion | delivery | compliance | strategic-watch`
- Previous snapshot timestamp: `YYYY-MM-DDTHH:MM:SSZ`
- Changed snapshot timestamp: `YYYY-MM-DDTHH:MM:SSZ`
- Diff proof: `diff excerpt | screenshot | snapshot path`
- Severity decision: `P0 | P1 | P2`
- Shipped response: `page update | pricing update | SOP update | alert only`
- Measurement path: `GA4 key event | GSC report | support volume | close-rate note`
- Result after review window: `win | mixed | loss | informational only`
- Next move: `escalate | revise | keep monitoring | remove watcher`

## Named Examples

- A solo operator watches a competitor pricing table, catches a same-day packaging change, updates their own comparison page, and logs the before/after CTA submit rate for the next week.
- A founder tracks an ad-platform policy page, catches a rule update, revises landing-page copy plus onboarding notes, and stores the policy diff with the shipped response link.
- A productized-service business monitors a partner directory listing, notices ranking or category drift, updates the listing copy, and compares referral traffic before and after the change.
- A founder watches their own checkout page for unexpected content drift, catches a broken proof block, fixes it, and compares the key-event completion rate to the prior week.

## Frequently Asked Questions

### Which pages should I monitor first?
Start with pages that can directly change revenue, compliance, or delivery quality: competitor pricing, critical vendor policy pages, referral directories, and your own highest-intent sales or checkout pages.

### How often should I run web-monitor checks?
Run daily checks for pricing and policy pages, and weekly checks for lower-risk strategic pages. The right cadence is the shortest review loop that catches meaningful change without creating alert fatigue.

### What counts as a meaningful web-monitor alert?
A meaningful alert is one that changes the decision you should make: update pricing, revise positioning, change customer messaging, tighten compliance language, or adjust an internal SOP. Cosmetic page diffs without business impact are not high-priority alerts.

### How do I avoid alert fatigue?
Monitor only the stable section that matters, tag each watcher by risk, and force every alert through a severity decision. If a page produces noisy diffs without strategic value for multiple cycles, change the selector or remove the watcher.