Framer says published, but your site still shows the old content

First: is it your browser or the site?

Before debugging anything in Framer, rule out the copy of the page your own browser is holding. This takes ten seconds and it is the answer often enough to be worth doing first every time.

• Open the live URL in a private or incognito window. A private window has no cache and no service worker, so it shows what a first-time visitor gets.
• If the private window is correct and your normal window is not, it was your cache. Hard-reload the normal window (Shift and reload) and move on.
• If the private window also shows the old content, the problem is real and on the site. Continue down this page.
• Check from your phone on mobile data as a second opinion. That removes your machine, your browser, and your network from the picture at once.

Cause 1: the publish was blocked by an error in the project

Framer refuses to publish a project that has errors in it, deliberately — the stated reason is to avoid shipping something broken, such as a form with no destination configured, into live traffic (Framer's help on resolving publishing errors).

The things Framer documents as blocking a publish are worth knowing by name, because the error badge does not always land somewhere you are looking:

• A page or smart component that is too large. Framer reports this as a "too large" error and stops updating that page, component or collection. Oversized inline SVGs are the usual culprit.
• A missing component. A component was deleted, or an external one needs updating, while instances of it are still placed on the canvas.
• A missing or invalid code override. An override was deleted while still attached to a layer, or contains an error.
• A missing CMS collection. A collection something on the page depends on was deleted or is itself erroring.
• A form with no destination. A form that has nowhere to send submissions blocks the publish rather than silently dropping entries later.

Look for the error badge in the editor and open it — it names the layer or component at fault and will take you to it. Fix or remove that one thing and publish again. Until it is cleared, every publish you press does nothing, which is exactly what "published but unchanged" looks like from outside.

Cause 2: the publish was accepted, then failed

This is the one that produces the most confusion, because nothing appears to go wrong. Framer accepts a publish request before it knows whether the site actually builds. The request succeeds, the interface tells you the site was published, and the build fails afterwards — leaving the previous version live with no obvious sign that anything is wrong.

If you published through an automation, an API call, or any tool outside the Framer editor, this is the first thing to suspect, because those tools usually report the accepted request rather than the finished deploy.

• Open the Framer editor and publish again manually. A failure will surface there in a way it may not have surfaced wherever you triggered it from.
• Check the project for the blocking errors in Cause 1 — an error introduced since the last good publish is the most common reason a previously fine project starts failing.
• If it keeps failing with nothing obvious in the project, Framer's troubleshooting guide is the right next stop, and Framer support can see build logs you cannot.

Cause 3: you published to preview instead of the live site

Framer can publish to a staging or preview address as well as to your production domain. A publish to preview updates the preview URL and leaves the live site exactly as it was — correctly, and with no warning, because that is what you asked for.

Check which target the last publish used, and check the URL you are testing. A staging address and a custom domain look different enough that this seems impossible to miss, and it gets missed constantly — particularly when a tool or a teammate set the target once and nobody has looked at it since.

Cause 4: the CMS item is still a draft

If the missing change is a blog post, a case study, a team member, or anything else that lives in a CMS collection, the site is probably fine and the item is not published.

Open the collection rather than the live page and check the item's state. This is the usual explanation when one thing is missing and the rest of the site updated perfectly — a whole-site problem does not affect a single row.

It is also the expected behaviour for content arriving through a sync. Most tools that write into Framer CMS create items as drafts on purpose, so that nothing reaches the public site without a person approving it. If your content came from Notion, Airtable, a sheet or a script, check for drafts before you check anything else.

Cause 5: the CDN has not caught up yet

A successful publish still has to propagate. For a short window after a deploy, some requests can be served the previous version from cache. This resolves on its own, usually within a minute or two.

If it has been longer than that and a private window still shows the old page, Framer exposes a cache clear for the site under its domain settings. Use it once and reload. If clearing the cache fixes it every single time you publish, that is not normal and is worth raising with Framer support rather than adopting as a routine.

Cause 6: it published, and the change was never in the project

Worth ruling out before escalating anything. Check the change is actually present in the editor on the page you are looking at — on the right breakpoint, on the right variant, and on the right page rather than a duplicate of it.

Two variations catch people repeatedly. The first is editing a component instance while expecting the master to change, or the reverse. The second is editing the desktop breakpoint and testing on a phone, where a separate mobile layout is still holding the old content.

A quick way to tell them apart

If you only do one thing, do this: open the live URL in a private window and look at one page you know changed.

• Old content in a private window, whole site stale: the publish did not land. Causes 1, 2 or 3.
• Old content in your browser only: your cache. Nothing is wrong with the site.
• Site updated but one CMS item missing: that item is a draft. Cause 4.
• Correct within a minute or two of publishing: propagation. Cause 5, and not a problem.
• Old content everywhere but the editor also looks unchanged: the edit was never made where you think. Cause 6.

If your content comes from Notion

A stale page has one extra possible cause when the content arrives through a sync: the sync may not have run, or may have failed before it reached Framer. That is a different problem from a failed publish, and it is worth confirming which half of the pipeline stopped before debugging the wrong one.

Check the collection in Framer first. If the new content is in the collection and the live site is stale, this is a publish problem and the causes above apply. If the content is not in the collection at all, the sync failed and the Notion sync troubleshooting page is the right place to go instead.

KnotCMS, which is ours, waits for Framer's verdict on a deploy rather than reporting the accepted request, and shows the stage a failed deploy stopped at along with Framer's own reason. That closes Cause 2 specifically and nothing else on this page — every other cause here is ordinary Framer behaviour that no third-party tool changes.

And if you have not settled on how Notion content gets into Framer in the first place, that is a separate decision from any of this. KnotCMS compared with Framer's own Notion plugin and on-page editing covers the three options, including where the free ones are the better choice.

Common questions