What Should You Check Before You Hit Publish in Webflow?

What Should You Check Before You Hit Publish in Webflow?

Check what else is staged before you check your own page. Webflow's own documentation states that "if multiple individual pages are published to staging, publishing from staging to production publishes all staged changes." One person's publish can carry somebody else's unfinished work live.

Most Webflow publish accidents we have helped untangle are not design mistakes. They are coordination mistakes. Someone pushed a fix, and three half finished pages went with it, and nobody noticed for a day.

Here is the sequence we go through, starting with the part almost nobody checks.

Why Does Publishing Carry Other People's Changes?

Because staging is shared. Webflow's Publish Site endpoint documents that it "publishes a site or an individual page to one or more domains", and that publishing from staging to production takes "all staged changes" with it. Individual page publishing gives you control over what goes to staging, not over what goes live.

That design is sensible. A site is one artefact, and letting arbitrary subsets go live would produce a version nobody had ever seen whole. But it means the question "is my change ready" is the wrong question when you are not the only editor.

The right question is "is everything that is staged ready". On a site with one editor those are the same question. On a site with five they are not, and the difference is where the incidents come from.

How Do You Find Out What Is Staged?

Look at the staging site, not at your own page in the Designer. The webflow.io subdomain is the only place the full staged state exists as a rendered site, and Webflow's publish options include a publishToWebflowSubdomain flag precisely so that state can be inspected separately from production.

Walk the staging site the way a visitor would rather than checking the page you edited. Nav, homepage, the two or three pages that matter commercially, and anything with a form. It takes five minutes and it is the highest value check on this list.

If you find something half finished, the fix is a conversation, not a rollback. Ask the person who staged it whether it is ready. Publishing around somebody's work in progress is how teams end up not trusting the publish button at all.

What Should You Check on the Page Itself?

Start with the things that are invisible in the Designer. Page title and meta description, because the Designer canvas never shows them. The Open Graph image, because nobody sees it until the link is shared. And the slug, because changing it later means a redirect.

Then check the page at three widths, not two. Desktop, tablet, and phone all exist as separate breakpoints in Webflow, and a layout that survives a browser window drag can still break on a real tablet. We wrote about testing on real hardware in our piece on testing on real devices.

Finally, click every link on the page. Not scan, click. Empty links and links still pointing at a placeholder are the single most common thing we find on a page somebody swears is finished.

What About Accessibility?

Do the four checks that catch most problems, and do them every time rather than in a quarterly audit. Alt text on every image that carries meaning. Heading order that goes down one level at a time. Visible focus styles on every interactive element. And colour contrast on text over images, which is where Webflow sites fail most often.

Keyboard is the fastest test of the four. Tab through the page and watch where the focus goes. If you lose it inside a dropdown, a modal, or a slider, a keyboard user is stuck in the same place and has no way out.

None of this is Webflow specific, which is the point. The platform does not stop you shipping an inaccessible page, and the responsibility sits with whoever presses publish. Our guide to Webflow accessibility goes through the rest.

How Do Comments Fit Into a Review Process?

Use them as the record of what was agreed, and clear them before publishing. Webflow supports comment threads on a site, exposed through its Data API as comment threads with replies and a resolve action, so an approval can live on the thing being approved rather than in a chat window.

One detail is worth knowing before you build a process on it. Webflow's documentation notes that "there may be a delay of up to 5 minutes before new comments appear in the system." If you are automating anything against comments, do not expect them instantly.

Our rule is simple. No open comment threads on a page means the page is ready to publish. An unresolved thread is a question somebody asked and nobody answered, and publishing over it is how the same question gets asked again next month.

What Do You Check After Publishing, Not Before?

Forms, first. Webflow's API error codes include forms_require_republish, which tells you plainly that form behaviour is tied to the published state of the site. A form that worked in the Designer preview is not evidence of a form that works in production.

Submit a real test through every form on the page and confirm it arrives where it is supposed to go. Then confirm the success state renders, because a form that submits silently and shows nothing is functionally broken even when the data arrives.

Check the page on production rather than staging afterwards too. It sounds obvious and it is routinely skipped, and it is the only way to catch a custom domain or redirect problem that staging cannot show you.

How Fast Can You Actually Publish?

Less often than you might assume if you are automating. Webflow documents that the publish endpoint "has a specific rate limit of one successful publish queue per minute." That is plenty for people and a real constraint for scripts.

It matters for anyone syncing CMS content from another system. A job that updates fifty items and publishes after each one will hit that limit. Batch the changes and publish once at the end, which is better practice anyway.

The same thinking applies to human workflows. Publishing after every small edit trains everyone to stop reading what they are publishing. A small number of deliberate publishes is safer than a constant trickle.

Who Should Be Allowed to Publish?

Fewer people than can edit. Editing and publishing are different acts with different blast radii, and treating them as one permission is the root of most of the problems above. Someone fixing a typo does not need the ability to push the whole staged site live.

Name the publishers explicitly and make sure they know about the staged changes rule. This is a training problem more than a permissions problem: most people who publish the wrong thing simply did not know that staging was shared.

We covered the permission side properly in our piece on Webflow team roles and permissions. The short version is to give publish rights to the smallest group that can still keep the site moving.

What Does a Good Pre-Publish Routine Look Like?

Write it down as five lines and put it where the publish button is. Check staging as a whole site. Check the page's meta fields and slug. Check three widths and tab through it. Clear comment threads. Publish, then test the forms on production.

Keep it short enough that people actually do it. A twenty item checklist gets skipped entirely, which is worse than a five item one that gets followed. Add items only when something goes wrong that the list would have caught.

If your site has enough editors that publishing has become nervous work, we are happy to help you design a routine that fits your team. Find us at phoenix.studio.

What Is the Single Biggest Improvement Most Teams Can Make?

Separate staging review from page review, and give the first one an owner. Almost every Webflow publishing problem we see comes from everyone checking their own work carefully and nobody checking the whole.

That owner does not need to be senior or technical. They need to be the person who opens the staging site, walks it, and either says it is clear or asks whose work in progress that is. Five minutes, one person, before every production publish.

It is an unglamorous fix, and it removes almost the entire category of accidental publishes. That is a better return than any checklist item further down the page.