the whole setup · one sentence per flow · no test code

End-to-end tests for Webflow.

There is no repository to put a test suite in and no build to hang one off, which is why a Webflow site is usually checked by somebody remembering to click the form. Write a sentence instead and have an agent click it after every publish.

the whole setup
$ npx smolanalytics test \
    --url https://yoursite.webflow.io \
    --test "the contact form accepts a name, an email and a message and shows the success state"

Point it at the published site or the webflow.io staging domain. Nothing is added to the project and no custom code is required.

how do I write end-to-end tests for a Webflow app?

A Webflow site has no repository and no build step, so there is nowhere to put a conventional test suite — which is why most of them are checked by somebody remembering to fill in the form. The alternative is one sentence: npx smolanalytics test --url https://yoursite.com --test "the contact form accepts a name, an email and a message and shows the success state". An agent opens a real browser, reads the page through its accessibility tree, fills the form in, and returns passed or failed. Nothing is added to the Webflow project and no custom code is required. It catches the failures that leave the design looking perfect: a success state hidden during a redesign so the form submits and shows nothing, a required field added in the designer but not in the connected integration, an interaction orphaned by a class rename. Because the sentence names no class and no element, the check survives a full redesign. Run it from your terminal after each publish or on a schedule. The tracking half applies too, though on a site with no repository it means a snippet in the custom code panel rather than a pull request. 14-day trial at Pro limits, no card, then $19/month.

Webflow sites break in ways that leave the page looking perfect, because the page is perfect and the thing behind it is not. A form's success and error states are separate elements in the designer, and hiding the wrong one during a redesign gives you a form that submits and then shows nothing. A required field added in the designer and not in the connected integration means submissions arrive without it. An interaction bound to a class that a rename orphaned leaves a button that animates and does nothing. Nobody notices any of it, because the person who publishes is the person who is looking at the design, not filling in the form for the fortieth time.

This is also the case where there is genuinely nowhere else to put a test. There is no repo, no CI, no code. The command runs from your terminal or a scheduled job against the published URL, and the sentence is the only artefact — which means the check survives a full redesign, since it never referred to a class or a div.

The instrumentation half is where a Webflow site is usually thinnest: a page-level script counting views and nothing at all on the form that is the site's only conversion. The same agent that has just submitted the form knows the form exists, so it can write and maintain the tracking call in whichever SDK you already run — PostHog, Mixpanel, Amplitude, Google Analytics, Plausible or Segment. On a site with no repository that means a snippet in the custom code panel rather than a pull request, which is worth knowing before you plan around it. If you run no analytics at all, the same engine can be it: autocapture, funnels, retention and paths are included.

How it works walks the whole loop from the sentence to the comment on the pull request, instrumentation covers the second half — the tracking calls the same walk writes and maintains — and the free tools run without an account. The docs have the flags, the suite format and the CI step.

Pro $19/mo, 100 tested pull requests included, unlimited projects, after a 14-day trial at Pro limits with no card. full pricing, including overage →

One sentence, on your Webflow app, tonight.

Point it at a URL that is already running and describe what should work. The first run uses the agent; once it passes it is recorded, so every run after that replays with no model at all — measured on our own site, 8.0s the first time and 1.4s the second.

questions

There is no repo, so where does the test live and when does it run?
The sentence lives wherever you keep it — a file on your machine, or the --test flag typed straight into the command — and you run it after you publish, or on a schedule from any machine that can reach the site. The pull-request comment is the half that needs a repository, so on a pure Webflow site you get the verdict in your terminal or your scheduler's log instead. That is worth being clear about before you plan around it.
Will a redesign break the test?
Only if the redesign breaks the thing the sentence describes, which is the point. The sentence names no class, no div and no element id, so restructuring the page cannot invalidate it. If a control is renamed, the run comes back as stale rather than failed — a rename and a removal look identical to a recording, so the agent goes back and works out which it was instead of paging you over a copy change.
What do I actually get back after a run on Webflow?
One of four words, and the difference between them is the product. Passed. Failed, which means your app did not do what the test describes, so it is a bug report. Stale, which means a recording no longer fits the page — a rename and a removal look identical to a replay, so this is never worded or coloured as a failure and the agent goes and works out which it was. Errored, which means our runner could not run at all: no browser, no network, no key. That one is our fault and it says so, because telling you your checkout is broken when our own runner fell over is the fastest way to lose you.

keep reading