Your Monitoring runs once a day. At 9:14 someone on the client’s team edits the pricing page, and the two-column layout quietly turns into one very long column. The next scheduled check is 23 hours away. The first person to notice is the client’s sales lead, halfway through a demo.
Most visual breakage on a WordPress site doesn’t come from a 3 a.m. update. It comes from someone editing a page. Scheduled visual monitoring catches that eventually. WebChange Detector 4.6.0 catches it a few minutes after the save.
This release adds three features and sharpens a fourth. Below is what each one does, and the details that matter when you roll it out across client sites.
Check when a page is saved
With plugin 4.6.0, WordPress visual monitoring no longer has to wait for the schedule. When someone saves a published page or post, WebChange Detector waits until editing is finished and compares it with its last Monitoring screenshot. Same AI verification, same alerts, same webhooks as a scheduled run.
It waits until the editor is done
Nobody saves a page once. The check runs five minutes after the last save. If the editor keeps autosaving unsaved changes in the meantime (e.g. block editor, classic editor, Elementor, Divi 4 and Beaver Builder drafts), WebChange Detector waits until there have been five quiet minutes. A long editing session produces one check, not one per click on “Update”. An autosave on its own never starts a check.
Only real edits count
A check starts when the title, content, excerpt, page-builder layout or featured image of a published page changes. Drafts, imports, WP-CLI and cron saves are ignored. Your nightly product import stays out of your alerts and out of your check balance.
The site reports the save right after it happens, so the check doesn’t depend on someone visiting the site afterwards.
Schedule, page saves, or both
Run it next to your existing schedule, or set the schedule to “Never” and check pages only when they are saved. Pages nobody touches then cost no checks at all. If a scheduled run is about to start within 15 minutes, that run covers the page and nothing is checked twice.
In the dashboard, a group that only checks on save shows “On page save” instead of an interval. A group with both shows “+ on page save” under its interval. Every triggered run is labeled with the page that was saved and the editor who saved it, which answers the first question in every “who broke this?” conversation.
Guard rails
Only pages that are already in the website’s Monitoring group are checked. A new blog post won’t sneak in. To keep a busy editorial team from draining your checks, there is a cap of 60 triggered pages per group per hour, and bulk edits are capped per five-minute window. A page without an earlier Monitoring screenshot gets its first screenshot as the reference, so the comparison starts with the next save.
Switching it on
“Check when a page is saved” is set per Monitoring settings, in the plugin’s settings or in the agency dashboard (group settings, or Bulk Changes for many sites at once). It needs plugin 4.6.0 and WordPress 5.6 or newer. Websites on an older plugin version get a hint in the dashboard, and “Never” is only offered for websites that can actually report page saves. Bulk Changes won’t switch off scheduled checks on a site that can’t replace them.
Run monitoring now, by click or by deploy script
The new “Run monitoring now” button starts a full Monitoring check immediately for every active page in a website’s Monitoring group. You find it on each Monitoring website in the agency dashboard and on the Monitoring Status card in the plugin. The run shows up in your Checks list as “Manual Trigger”.
Before anything starts, the confirmation tells you how many checks the run can use (“up to N checks”). If your remaining checks don’t cover it, nothing starts and you see why. Clicked twice by accident? The second click gets “already running”, not a second bill.
While any Monitoring run of that website is in progress, whether it came from the button, the schedule or a page save, the button turns into a live “Monitoring running…” status in both the dashboard and the plugin. A run you started yourself ends with “Monitoring finished: N changes” and a link to its checks.
Deploys where nothing gets “saved”
Some hosts, WP Engine for example, push staging to production as a full copy. Nothing is saved on the live site, so no page-save check fires. For that case, click “Run monitoring now” right after the push, either in the agency dashboard or in the WordPress plugin. Every monitored page is checked right away instead of waiting for the next scheduled run.
If your deploy purges or warms caches, let that finish first, since the check starts the moment you click. Want it fully automated? The same check can be started with one API call at the end of your deploy script, see the API documentation. Combine it with webhook alerts and the result lands in Slack or your ticket system without anyone opening the dashboard.
Headless mode: hide the plugin from your client
Headless mode hides the entire WebChange Detector interface on a client site: no menu entry, no admin bar item, no plugin styles on other admin or front-end pages. Everything keeps running in the background. URL sync, Auto Update Checks, Monitoring and the new page-save checks work as before, and you manage it all from your agency dashboard.
The point is fewer “what is this plugin?” tickets. Your client gets safe updates and visual checks without an extra tool in their backend.
How it works in practice:
- Switch it per website or in bulk from the agency dashboard. On multisite, the network admin can set it per sub-site and as the default for new sub-sites.
- The change reaches the site within an hour (multisite sub-sites within a day). Changes on the network admin page apply immediately.
- Nothing changes on your existing sites until you switch it on.
- A wp-config setting brings the interface back immediately if you ever need it on a specific site.
- If a hidden site loses its connection, for example after moving to another domain, the interface comes back so the site can be reconnected.
To be clear about what it is: interface hygiene, not a lock. The plugin stays listed under Plugins, and a site administrator can still deactivate it. Headless mode needs plugin 4.6.0; the dashboard shows a hint for sites on older versions.
Even fewer false alarms
WebChange Detector already ignored popups, cookie banners and moving content. Version 4.6.0 makes that more reliable in the cases that still slipped through now and then: modal popups, autoplay background videos, one widely used cookie plugin and WordPress maintenance mode. That means fewer alerts you open only to find nothing.
Popups and modal overlays. A popup that covers the page is hidden together with its dimmed background, including popups that appear after a delay or once the visitor scrolls. The scroll lock many popups add is released too, so the screenshot reaches the bottom of the page instead of stopping at the first screen. Popups are hidden, never clicked, so no form is ever submitted. Sticky headers and side drawers are part of your page and stay in the screenshot.
Background and hero videos. Autoplay videos are frozen on the same frame in every screenshot, including background videos that play through an embedded Vimeo or YouTube player (a common setup for Elementor hero sections). Videos that never started keep their poster image.
“Cookie Notice & Compliance” banner. The banner from this plugin is now dismissed on every site, so it no longer shows up as a change.
Maintenance mode during updates. While WordPress installs updates, the site briefly shows its “Briefly unavailable for scheduled maintenance” page. To a screenshot, that looks like an empty site. WebChange Detector now recognizes this page, waits a moment and retries once. If the site is still in maintenance, the check is reported as failed instead of saving the maintenance page as the new reference. No more “your site is empty” alert in the middle of an update window.
Getting 4.6.0 onto your client sites
Update the WebChange Detector plugin to 4.6.0, either from the Plugins screen or through your usual update tool. Then open the Monitoring settings of each group you want covered and switch on “Check when a page is saved”. For many sites at once, use Bulk Changes in the agency dashboard.
If you are new to scheduled checks, the guide to how website monitoring works explains intervals, quiet times and alerts. Running many installs? Here is how to manage multiple client sites from one dashboard.
Not using WebChange Detector yet? Install the plugin from WordPress.org. Chances are the first broken page save it catches is one you’d rather hear about from us than from your client.
