Go to platform

A Change Stopped Applying

Sometimes, on a running visual experiment, you will see a banner on the results page that says something like:

Your page changed: "Sign-up button" hasn't applied for visitors since <date>.

This means A vs B is still running your experiment, but one specific change inside it is no longer showing up for real visitors. Those visitors are seeing your original page instead of the variation for that change. This page explains why that happens and how to fix it.

  • The banner names the exact change that stopped reaching visitors, and when it was last seen working.
  • Select Open the editor on your site to jump straight to re-pointing or rebuilding it.

What the warning means

Every visual change you make points at a specific spot on your page: a button, a headline, an image, a section. When A vs B tries to apply the change, it looks for that spot. If it can find it, the change is applied and the visitor sees your variation. If it cannot find it, A vs B leaves the page untouched rather than guessing, and the visitor sees the original.

The banner appears once at least 5 different visitors hit this "can't find the spot" situation for the same change within a day, which rules out a one-off glitch. A single slow page load will never trigger it.

One exception: changes that remove an element. For a removal, "the spot can't be found" is the change working, not failing: the element is gone, which is exactly what you asked for. A removal that has already succeeded never counts toward this warning.

Your experiment is still running

Only the one change named in the banner is affected. The rest of your experiment (bucketing visitors, tracking results, and applying every change that still fits) keeps working normally.

Why it happens

The most common cause is simple: your website changed after you built the experiment.

  • A redeploy, a theme update, or a new page layout moved or renamed the element the change was pointing at.
  • A section was rebuilt, so the original element no longer exists.
  • The element only appears after an action (opening a menu, loading more content) and that flow changed.

When the spot a change was built on is gone or has moved, the change has nowhere to land, so it quietly stops applying, and this banner is how A vs B tells you instead of letting it fail silently.

How to fix it

1

Open the visual editor on your live site

From the experiment, open the visual editor on the page where the change should appear. The editor loads your site as it is right now, so you will see the current layout.

2

Find the change named in the banner

The banner names each affected change (for example, "Sign-up button" or "Style change on the hero"). Locate that change in the editor's change list.

3

Re-point or rebuild the change

If the element simply moved or was renamed, re-select it so the change points at its new location. If the whole section was redesigned and the original element is gone, rebuild the change on the new layout.

4

Save: the fix goes live on the next visit

Save your changes. A vs B ships the update, and the change starts applying again for visitors on their next page load. The banner clears once visitors stop hitting the problem.

Changes built by the AI copilot

Changes the AI copilot builds for you are designed to be more resilient: it anchors them so they keep working even when the surrounding page shifts around a bit. That means a copilot-built change is less likely to show up here after a small layout tweak.

This includes removals: when the copilot removes an element for you and your site later re-creates it (app-style sites re-render sections all the time), A vs B notices and removes it again automatically. The element stays gone for the visitor without you doing anything.

However, no anchor can survive an element being deleted from your site. If the specific thing a copilot change was built on is removed entirely from your own code, that change will also stop applying, and the fix is the same: open the editor and rebuild it on the current page.

Prevent it in the first place

  • Re-check your key experiments after a site redeploy or theme change. A quick look in the visual editor confirms your changes still land where you expect.
  • Target stable elements. Where you have the choice, build changes on elements that are unlikely to be renamed or moved on every deploy.
  • Watch the results page. This banner is your early warning: the sooner you re-target a change, the fewer visitors see the original instead of your variation.
Was this helpful?