Private page history / evidence over time
Website Change Monitor
Keep a private record of important changes to selected public pages.
Website Change Monitor compares scheduled captures of pages chosen by an authorized site administrator. Review changes to titles, descriptions, canonical declarations, robots directives, headings, response details and normalized page text. Use the history to investigate what changed between comparable observations and decide which follow-up check is needed.
This is an owner-managed workspace. Monitoring targets and history are private. The public page explains the tool; it does not accept visitor monitoring requests or expose stored captures.
Requires this site's administrator permissions. No paid API or monitoring subscription is required by this module.
Private owner workspace · No paid API
Keep an eye on important page changes
Website Change Monitor compares scheduled captures of administrator-selected public pages. It records changes to page titles, descriptions, canonicals, robots directives, headings, response details and normalized page text.
This is an owner-managed tool. Monitoring targets and history are private. Visitors cannot start background checks or view another site owner’s results from this page.
Choose and enable a target
An administrator adds an authorized public page and explicitly enables its schedule. The first successful capture establishes a baseline, not a false change alert.
Review evidence, not guesses
Compatible captures are compared in a private dashboard. Failed requests remain failures. Retained text has a size cap, and coverage notes explain what was captured.
Control history and notifications
Administrators can pause targets, run bounded manual checks, set retention, delete data and optionally enable email. Email is off unless explicitly selected.
What this monitor does—and does not do
Checks use initial HTML and HTTP evidence. They do not render JavaScript, take visual screenshots, confirm Google indexing, edit page content, or archive complete websites. WordPress scheduled checks depend on page traffic or an existing cron runner, so they are not a guaranteed real-time uptime service.
Public-address, redirect, robots and request limits remain in place. No API key or paid monitoring subscription is required by this module.
Start with a page and a reason to watch it
A useful monitoring target has a clear purpose. You might want to notice when an important landing page receives a different canonical, when a template changes headings, or when the returned source no longer contains wording you expect. Write down the question before enabling a schedule.
An administrator adds an authorized public page and explicitly enables its schedule. Selecting a target is separate from deciding that it should receive recurring checks. Keep the initial list focused on pages whose changes someone is ready to review.
For a one-time look at a page's returned HTML, use the SEO Checker. Monitoring adds observations over time; it does not replace understanding the page you select or justify collecting an entire website without a defined need.
02 / Changes with context
Review the fields that answer your question
| Evidence | Useful question |
|---|---|
| Page title | Did the returned title change unexpectedly? |
| Meta description | Does the description still represent the intended page? |
| Canonical declaration | Is the page still pointing to the version you intended? |
| Robots directives | Did a declared indexing or preview instruction change? |
| Headings | Has the returned heading structure or wording changed? |
| Response URL and status | Did the request finish at a different location or return a different status? |
| Normalized main text | Does the captured comparison text differ from the earlier evidence? |
Read these fields together. A changed final URL can explain why the title and body now look different. A canonical change can require review even when the visible wording is unchanged. A text change may be planned editorial work rather than an error.
The monitor records selected evidence. It does not decide whether every change is beneficial, accidental or commercially important. The page owner supplies that context.
03 / A record, not a guess
A baseline is a beginning.
A failed attempt is not a change.
Establish a baseline before looking for changes
The first successful capture establishes a baseline. It is the starting evidence for later comparisons, rather than proof that a change has already occurred.
A later compatible successful capture can be compared with the earlier evidence. If the relevant values differ, review the recorded difference and its context. If the inspected values agree, interpret that agreement within the scope of those captures.
A failed request remains a failure. It should prompt a different question: was a usable observation obtained? It does not establish that all page text was removed or that every metadata field changed. Review the request outcome before drawing a content conclusion.
These distinctions keep a history useful. An initial observation, a comparable change and a check that could not obtain evidence are different situations, even when they happen close together.
- 01BaselineFirst usable evidence
- 02Title differsCompare two observations
- 03Request failsNo new usable capture
- 04Later captureReview evidence and gaps
An example of careful interpretation
Manually authored exampleThis manually authored sequence illustrates the review process. These are explanatory situations, not exact dashboard labels or actual captures.
| Observation | What the reviewer can conclude |
|---|---|
| First successful capture | A baseline now exists for later compatible comparisons. |
| Next compatible capture changes a title | The title differs between those observations; review whether that was intended. |
| A subsequent request fails | The attempt did not establish a new usable page observation. |
| A later compatible capture is obtained | Review its evidence and the gap since the relevant earlier capture. |
The sequence does not tell you the exact moment the title changed or who changed it. It also does not prove a ranking effect. Compare the history with release notes or editorial records when investigating those questions.
04 / Follow a specific signal
Know what changed.
Then ask why it matters.
Investigate canonical and robots changes separately
A canonical declaration is a signal about preferred page versions. If the history shows a different declaration, compare it with the relationship you intended and inspect the relevant page versions. The Canonical Tag Checker provides a focused next step for declared canonical evidence.
Robots directives concern different instructions. A change can deserve attention, but detecting it does not prove that a search engine has processed the new value. Use the Indexability Checker to investigate crawl rules, noindex and related signals.
Keep the observation and its consequence separate in your notes. “The captured declaration changed” is a finding about the supplied evidence. “Google changed its selected canonical” requires information about Google's processing. A monitor capture cannot establish both conclusions by itself.
Follow changes in response location and status
An unexpected destination may be more useful to investigate than the wording difference that follows it. Check whether a deliberate redirect, a migration or a temporary response explains the new capture.
Use the Redirect Checker when you need to inspect redirect hops and their response evidence. This is a separate diagnostic task; a recorded final location is not a complete explanation of every step that led there.
Also distinguish an HTTP response from a request that failed before a usable response was obtained. Avoid turning an empty or unavailable observation into a story about page removal. Retain the available evidence and investigate the request conditions.
Understand what normalized text can show
The comparison uses normalized main text rather than a complete website archive. This helps frame the review around captured wording, but it also sets a boundary on what an unchanged comparison means.
Retained text has a size cap, and coverage notes explain what was captured. Read those notes before relying on a difference or apparent agreement. A portion outside retained coverage cannot be treated as verified unchanged.
Review the surrounding page when wording changes. A short added sentence can be intentional, while an apparently minor deletion can remove a useful instruction. The importance of a change comes from its role on the page, not simply the amount of text that differs.
Keep the original monitoring question nearby. If your objective concerns one important page signal, a large unrelated text difference should not distract you from reviewing that signal directly.
Keep source HTML distinct from the rendered page
Checks use initial HTML and HTTP evidence. They do not run the page's JavaScript or take visual screenshots. Content added after scripts execute can therefore differ from the source-based evidence available to this monitor.
If that distinction matters, use the Rendered HTML Checker to compare original HTML with a rendered DOM snapshot you supply. Keep the two sources and their capture context clearly identified.
Reading a rendered snapshot elsewhere does not add browser rendering to this monitor. It provides another piece of evidence for your investigation. A visual redesign, interactive component or client-side content update needs a method that actually observes the behavior you want to assess.
05 / Deliberate monitoring
Control the schedule.
Keep the uncertainty visible.
Read scheduling as a due time, not a delivery promise
WordPress scheduled work depends on site traffic and server availability, or an existing cron runner. A configured interval does not guarantee that a capture will occur at an exact wall-clock time.
The dashboard shows last attempts, next due times and overdue checks. Read those together. A due time describes when work is expected; a last attempt describes what was actually attempted. A gap between them can matter when judging how current the history is.
If an important period has no successful observation, retain that uncertainty. The monitor cannot reconstruct every intermediate change that may have occurred between captures. A page can change and return to its earlier state while no usable capture is taken.
For background on the underlying timing model, see the WordPress cron documentation. This monitor is not an exact-time uptime service, and its history should not be presented as continuous proof of availability.
Use optional email deliberately
Email alerts are optional and off unless explicitly selected. They use the site's existing mail delivery rather than a required paid monitoring API.
Decide who will review an alert before enabling it. The useful outcome is a person understanding the affected page and taking an appropriate next step. A message without clear ownership can add noise while the underlying finding remains unresolved.
Treat notification delivery separately from capture and comparison. The monitor may record evidence while a mail-delivery problem prevents someone from seeing an alert. Conversely, receiving a notification does not establish that every page or every intervening change was captured.
Review history as well as email. Do not use an empty inbox as proof that pages remained unchanged, schedules ran on time or all checks succeeded.
Control retention and the monitoring lifecycle
Administrators can pause targets, run bounded manual checks and set retention. Private snapshots and history follow administrator-set retention and record limits. They are not stored permanently as a complete archive.
Choose retained history according to the review you need to perform. A short investigation and a longer template review can require different evidence. Retention limits also affect which earlier observations remain available when someone later asks what changed.
Deleting a target removes its stored history. A separate confirmed purge clears all monitor targets and data. Understand the scope of those actions before using them, especially when history is still needed for an investigation.
Pausing checks, changing retention and deleting history serve different purposes. Keep a record of the decision in your own workflow so a future reviewer can understand why observations stop or older evidence is unavailable.
Respect the scope of public-page monitoring
The module retains public-address, redirect, robots and request limits. Monitoring is for authorized public pages. It is not a route into private networks, authenticated pages or restricted information.
Capture history remains private to the authorized owner workspace. That access boundary should remain part of how the tool is described, including when discussing it with a colleague. A link to this public page does not grant access to stored targets or results.
No paid API or paid monitoring subscription is required by this module. That statement describes the module's dependency model, not a promise about every cost or operational requirement of running a website and its existing mail setup.
Before you begin
Questions about Website Change Monitor
Access, evidence and the boundaries of a monitoring history.
Can a visitor start monitoring from this page?
No. The public page provides information and an administrator sign-in route. Authorized administrators manage targets, schedules and private history. There is no public background-monitoring request form here.
Does the first capture generate a change alert?
The first successful capture establishes a baseline. A change comparison needs suitable earlier evidence. Treat baseline creation as the beginning of the record rather than an unexpected content change.
Can it prove when a change happened?
It provides observations from checks, rather than continuous knowledge of the page. A difference can identify a change between comparable captures. It does not establish the exact edit time, editor or every intervening version.
Does it confirm Google indexing or rankings?
No. It records selected page and response evidence. Google's processing and performance need their own evidence. Do not use a changed canonical, title or robots declaration as proof that an indexing or ranking decision has already changed.
What if I only need a different focused check?
Use the SEO and content tools hub to select a utility matching the unresolved question. Keep one-time inspection, recurring history and specialist diagnostics clearly connected to the task you are trying to complete.