All coursesPrepare to publish your site
Monitoring published changes

Monitoring published changes

See what changed, who changed it, and how to respond when something doesn’t go as planned.

Monitoring published changes

See what changed, who changed it, and how to respond when something doesn’t go as planned.

Use the Site Activity log to trace changes

When something changes on a busy site, the first question is usually: What happened?

The Site Activity log gives you a running record of major activity across your site, including who made a change and when it happened.

Use it to investigate recent changes, understand publishing activity, and see what different teammates have been working on.

Webflow Site activity panel showing who published to staging, modified page settings, and changed classes, with timestamps.

Platform plan required. The Site Activity log is available on Platform plans.

What can I find in the Site Activity log?

The Site Activity log tracks activity across many parts of your site, including design updates, CMS activity, page settings, publishing events, and other site-level changes.

Each entry gives you context about the activity, including when it happened and who initiated it.

That makes the log useful for answering questions like:

  • What changed recently?
  • Who made the change?
  • Was something published?
  • Where should I start looking if something seems wrong?

If your team uses AI or MCP-connected tools, source information can also help you understand where activity came from.

Webflow Site activity panel with a highlighted user tooltip identifying a change as generated by AI through MCP.
Warning

Important:

One thing to keep in mind:

The Site Activity log records that an activity happened, but it won’t always show the exact before-and-after value of every change.

If a class was modified, for example, you may see that the class changed without seeing every individual property value that changed.

Use it to narrow down what happened and where to investigate next.

Use filters to narrow things down

On a busy Enterprise site, the full activity stream can get noisy.

Filters help you get from “something changed” to the activity you actually care about. You can filter by things like:

  • Location — focus on the page you currently have open
  • Changes — see unpublished changes, changes published to staging, or changes published to production
  • Activity type — narrow the log to CMS, classes, components, variables, custom code, backups, branches, publishing, and other activity
  • Author — see activity from a specific teammate
  • Source — distinguish activity from sources such as Webflow AI or Webflow MCP
Webflow Site activity filter menu open with options to filter by current page, publishing status, and activity type.

That makes the log useful both before and after a publish.

Before publishing, it can help you understand what work is still pending.

After publishing, it gives you a place to start if something unexpected appears in production.

The Site Activity log isn’t version control

The Site Activity log helps you understand what happened. It doesn’t replace the tools you use to review or restore work.

Site Activity log

Use it to investigate activity and understand the sequence of events.

Backups

Use them when you need to return the site to a previous state.

For work that still needs feedback or approval, use comments and design approvals before it reaches production.

That distinction matters when you’re troubleshooting: first understand what happened, then choose the right response.

What if something shouldn’t have gone live?

The right recovery option depends on what was published. Start with the smallest recovery action that solves the problem.

Fix it and republish

For many issues, the simplest option is to correct the change and publish again.

Use the Site Activity log to help narrow down what happened, make the fix, test it if needed, and republish.

Unpublish new content

If a newly published CMS item shouldn’t be live yet, unpublish it, make the necessary changes, and publish it again when it’s ready.

If a published page shouldn’t remain live, move it back to draft and use the appropriate publishing workflow to remove it from production.

Restore from a backup

For larger problems, a backup gives you another recovery option.

Backups aren’t only useful before launch. Consider creating a named backup before major changes such as a large redesign, a navigation overhaul, or a high-impact site update.

Webflow Backups settings highlighting “2026 rebrand | Pre-launch backup,” with options to preview or restore saved versions.

Restoring a backup affects more of the site than fixing one isolated issue, so first check whether a smaller correction will solve the problem.

If you do need to restore, choose the backup that represents the site state you want to return to, then review and republish as needed.

Learn how to save and restore backups →

A simple recovery flow

1. Trace

Use the Site Activity log to understand what happened.

2. Assess

Decide whether the problem is isolated content, a page-level issue, or something broader.

3. Recover

Fix and republish, unpublish content, or restore from a backup based on the scope of the problem.

When something goes wrong, don’t start by guessing — and don’t jump straight to a full restore.

Use the Site Activity log to understand what happened, then choose the smallest recovery action that solves the problem.

Sometimes that means fixing and republishing, or sometimes it means unpublishing content. And for larger issues, a backup gives your team a previous site state to return to.

Ready to wrap up?

Next, you’ll wrap up the course with a simple framework for choosing the right publishing workflow and resources to explore next.

1

Intro

Coming soon

1

Welcome & overview
1:30
Welcome & overview
Coming soon

1

Publishing options in Webflow
2:30
Publishing options in Webflow
Coming soon

1

Publishing permissions across your team
3:00
Publishing permissions across your team
Coming soon

2

Preparing to publish

Coming soon

2

Staging your changes before production
3:00
Staging your changes before production
Coming soon

2

Branching and approvals
6:52
Branching and approvals
Coming soon

2

Controlling what gets published
3:00
Controlling what gets published
Coming soon

3

Publishing to production

Coming soon

3

Enterprise publishing workflow
3:52
Enterprise publishing workflow
Coming soon

3

Key details: Single-page publishing
3:30
Key details: Single-page publishing
Coming soon

3

CMS single-item publishing
4:30
CMS single-item publishing
Coming soon

3

Publishing with agents
3:00
Publishing with agents
Coming soon

4

Best practices

Coming soon

4

Pre-launch best practices & checklist
2:30
Pre-launch best practices & checklist
Coming soon

4

Ongoing publishing habits
3:00
Ongoing publishing habits
Coming soon

4

Monitoring published changes
4:30
Monitoring published changes
Coming soon

5

Wrap-up

Coming soon

5

Recap & additional resources
1:30
Recap & additional resources
Coming soon

Course progress

0%

Assessment

Up next

Recap & additional resources

Review the key publishing decisions from this course and find resources to go deeper.
Continue to next lesson
→
Complete course
✓