Why do Webflow interactions break after I publish?

Compare the live page with the Designer

An interaction that plays in the Designer can still be missing, old, or clipped on the published site. Open the live URL in a private window so you are not looking at a cached copy. Note the page, the breakpoint, and what you expected: a heading that should move, a menu that should open, or a section that should fade in.

Webflow's troubleshooting note says that if the published site looks different from the Designer, clear the browser cache and try again. Republishing is the other check. Unpublishing takes the live site down until you publish again, so treat that as a last step when you can accept a short gap, not as the first click.

For example: the homepage hero heading should fly in from the left. On the published homepage it never moves, while preview in the Designer still plays. Work through the checks below before you rebuild the animation.

Publish the interaction to every page that uses it

Interactions are often global. If you changed one since the last full-site publish, and you then publish only one page, the publish summary flags that global change. Only the page you publish receives it. Other pages keep the older live version until you publish those pages or run a full-site publish.

Single-page publishing is limited to Team and Enterprise Platform plans, and the site must already have had a full-site publish. It also leaves out site-wide custom code. If the motion depends on a site-wide script you added after the last full publish, a single-page publish will not put that script on the live site.

When the same hero component is on the homepage and the about page, publish both pages or publish the whole site after the interaction edit. Then retest both URLs. Editing the component in the Designer is not enough.

Check custom code on the published site

Webflow documents that interactions may not work as expected on a published site when the site uses custom code. Custom code can conflict with Webflow, and support does not troubleshoot it.

Two patterns cause trouble often. Newly published Webflow sites include jQuery 3.5.1, and loading another jQuery version can cause unexpected behavior. Scripts that take over DOM events such as click or hover can also fight an interaction trigger.

Custom code appears in preview, but it does not affect the live site until you publish. If a script is only in preview, or if a published script conflicts with the interaction, the live page will not match the Designer. Disable the extra script, publish the full site, and test the interaction on its own. If the motion returns, the script is the conflict. Put the script back only after you know the interaction works without it.

CSS transitions on the same element can make a GSAP animation jumpy. Webflow recommends not combining CSS transitions and interactions on the same element or property. If a class animates opacity or transform with a CSS transition, remove that transition from the property the interaction also animates, then publish and retest.

Test the breakpoint where motion is turned off

Conditional playback can limit an interaction to certain pages or breakpoints. Breakpoint rules cascade downward, the same way styles do. If you set the interaction to no animation on a mobile breakpoint, it stops as soon as the viewport matches that width. A phone test then looks like a broken publish even though desktop still plays.

Resize the published page, or use the device breakpoints, and compare. Also check page scoping. An interaction set to run on one page will not run on another, which is expected, not a failed publish.

Inline text can refuse transform actions. If a heading is display inline, a move or scale action will not move it. Set the element to a layout that can transform, then publish again.

Stop overflow from clipping the animation

Motion that starts off screen often looks broken after publish because a parent hides the overflow. A heading that starts outside the viewport and ends in place can also leave a horizontal gap. The browser still accounts for that starting position.

If the hero div is set to overflow hidden, the fly-in is clipped. Webflow's fix is to set overflow visible on that tight parent, then set overflow hidden on the next parent up, such as the section. The animation can travel inside the section, and the page does not grow sideways. Do not set overflow hidden on the body. That can stop visitors from scrolling the rest of the page.

Publish after the overflow change and check the live page on a phone width as well as desktop. Extra whitespace to the right is a sign the starting position is still outside the section you meant to clip.