The Three-Layer Monitor That Watches My Clients' Webflow CMS

Webflow's backups are good at what they do, and what they do is restore a whole site. A restore point is created automatically on every 50th auto-save, you can preview any of them, and paid Site plans keep an unlimited history. But the unit of restore is the site. Rolling back means taking the entire site to an earlier moment, and Webflow's own documentation lists the side effects: "Published on" dates on Collection items reset to the moment of the restore, reCAPTCHA keys have to be re-added, and bot protection is switched off. There is no per-field history and no per-item rollback.

That gap is fine until a single field is damaged and nothing else is. Then you find out by audit, if you find out at all, and you restore from whatever copy the outside world happened to keep. I learned that on a client blog where a bulk rename had regenerated 21 articles instead of editing them, most losing 30 to 50 percent of their content, and they stayed live that way for almost three months. Nothing looked broken; truncated articles do not throw errors, they just end early. This is the system that came out of it, in enough detail to build your own.

Layer One: A Baseline Of Every Text Field

The first layer watches the CMS itself. A script pulls every content-bearing collection through the Webflow API and records, for every text field longer than 40 characters, three things: its character count, its word count, and a hash of its content. The result is one JSON file per site, keyed by collection and item slug, committed to the project's git repository. That file is the baseline.

A check pulls the same collections fresh and diffs them against the baseline. It alarms on exactly three conditions: a field that shrank by more than 15 percent and by more than 120 characters, a field that was emptied or removed, and an item that disappeared. Growth, small edits and new items are logged as information, never as alarms. Both halves of the shrink rule matter. Fifteen percent of a 200-character excerpt is a normal edit; 15 percent of a 6,000-character article is a missing section. Requiring both a proportion and an absolute size keeps the check quiet on editorial work and loud on loss.

Before trusting it, I tested the detector against a simulated truncation of a real dump and confirmed it fired. A monitor that has never been seen to alarm is a hope, not a control.

Layer Two: What Visitors And Crawlers Actually Receive

The CMS can be intact while the page is not. A template regression, a lost embed, a redirect edited by hand, a robots setting flipped during a launch: none of these touch a field, and all of them change what a visitor or a crawler gets. So the second layer needs no API at all. It fetches every URL in the sitemap over plain HTTPS, plus a configured list of pages that are published but deliberately noindexed, and baselines what it finds.

It alarms on a status, canonical or robots change in either direction, an emptied title or meta description, a main-content word count that collapses by more than 20 percent and more than 150 words, a change in the number of h1 elements, forms dropping to zero, a tag manager container disappearing, structured data that stops parsing or vanishes, and pages that go missing. It also holds a short list of invariants: the apex domain must 301 to www, one sample legacy URL must still hit its wildcard redirect, and on sites that publish an llms.txt, the live file must be byte-identical to the copy in the repository.

Two rules came out of setting this up on five sites in one day. Every invariant is verified live with a real request, status code and Location header, before it is written into the config; a redirect remembered from a document is not evidence. And a wildcard redirect gets one sample URL as an invariant, because a single edit in the redirects panel can lose the whole rule and nothing else will notice.

The llms.txt invariant has a side benefit I did not plan. On Webflow, that file is edited in Site Settings and only propagates on a full publish, so a repo-side update that never got pasted used to drift silently. Now it trips a weekly alarm.

Layer Three: The Copy You Restore From

The first two layers tell you something was lost. They cannot give it back; a hash proves a field changed, it does not contain the field. So on the first of every month, a third job pulls the full content of the same collections and writes it, parsed, into a dated directory in the repository. Across the five sites that is between about 120 kilobytes and 2.4 megabytes a month. Only the new month's directory is committed. Past months are never edited or deleted. Before committing, the job compares item counts with the previous month and flags an unexplained drop instead of archiving it.

In the incident that started all this, 18 of the 21 damaged articles could be rebuilt because the Wayback Machine happened to have crawled them before the damage. The other three could not. An archive in git turns that from luck into a property of the project.

The Operating Rules Are The Hard Part

The scripts took an afternoon. The rules around them are what make the system trustworthy, and every one of them was written after something almost went wrong.

• The scheduled check is read-only. It runs weekly, on Monday mornings, staggered a few minutes apart per client. It never writes to the CMS and never refreshes a baseline on its own. It reports one line if everything matches, or every alarm verbatim.
• A manual check follows every bulk content pass. The weekly cadence is the floor, not the trigger. A pass that touches 40 items gets a check the same afternoon, before anyone publishes.
• A baseline is refreshed only after intended changes are verified live, and never over an unexplained alarm. When six new case studies launched on one site, the item count went from 73 to 79, the check reported the growth, and the baseline was refreshed that day. That is the right order: ship, verify, then move the reference point. An alarm you cannot explain is investigated first, and the git history of the baseline file is the reference for the investigation.
• A relaunch alarms on purpose. When a rebuilt site replaces the live one, the page monitor fires on nearly every URL. That is not noise to be suppressed; it is the moment to verify the redirect map and then consciously re-baseline. The same goes for a page that goes from 404 to 200: an improvement is still a change, and the baseline should record that someone meant it.
• On alarm, nobody publishes. A site publish ships everything staged, so publishing over a damaged item makes the damage live. Recovery sources are tried in order of fidelity: the repository's own history of baselines and archives, then the Wayback Machine, then Webflow's backup preview, which opens a read-only Designer at the snapshot with the CMS panel fully browsable. Opening a preview is safe, and Webflow saves the current state before any restore, but the restore button itself replaces the whole site and is not the tool for one field.

What It Has Caught, And What It Cannot

Honest accounting. The system has run on five client sites since the end of August, ranging from 44 to 321 CMS items and from 61 to 269 rendered pages each, and the scheduled runs so far have come back clean. Zero alarms after two weeks is a small result. It is also the false-positive rate, which is the number that decides whether a monitor survives contact with a busy week.

The known blind spot is structural. A baseline captures the site as it is, faults included. On one site, two pages sat in the production sitemap while returning 404. They were baselined as 404, so they will never alarm; they were found by eye at baseline time and tracked as an open item. A monitor detects change, not wrongness. The first snapshot still has to be read by a person.

The second limit is the flip side of the design. Hashes and counts do not know whether a shorter field is damage or a deliberate rewrite, so a legitimate trim past the thresholds alarms too. That is the correct behaviour. The failure mode this system exists for is silence, and a false alarm costs two minutes to explain and refresh. A missed truncation cost three months.

None of this needs a service, a token budget or a dashboard. It is a few hundred lines of Python, plain HTTPS, the Webflow API for the field layer, and git as the database. If you run Webflow sites for clients and AI tools are anywhere in your content workflow, the question is not whether a field will one day be regenerated instead of edited. It is whether you will hear about it the same week.