To test a Webflow website before going live, start with the pages affected by the update. Check the page you edited, the templates behind it, and any shared components that may have changed across the site.
On those pages, review visual changes, broken links, SEO fields, forms, and key interactions on the live site. For larger updates, start on staging and compare against production when possible.
Webflow makes it easy for web and marketing teams to publish without developer support. Reusable components, shared classes, CMS templates, and built-in SEO fields are part of what makes that possible. But those same systems can also make issues harder to spot when one change affects many pages.
That is why Webflow testing should be a repeatable review step before changes go live. You are not only checking the page you edited. You are checking the related templates, components, links, and live interactions that may have changed with it.
In This Guide
You’ll learn how to check:
- Visual layout changes across components, templates, and mobile breakpoints
- Broken links in navigation, CMS content, CTAs, and redirects
- SEO fields such as titles, descriptions, canonicals, Open Graph fields, and H1s
- Forms, menus, modals, accordions, tabs, and third-party widgets on the published site
- Larger Webflow sites with a no-code Webflow testing tool
What Should You Check Visually After a Webflow Publish?
Start with the parts of the site most likely to change across multiple pages. In Webflow, that usually means shared components, reusable layouts, and CMS templates.
A small edit can spread further than expected. If you update a navigation component, every page using that navigation can change. If you update a CMS collection template, every item in that collection can change. If you adjust a card style, the same change may appear on blog cards, case study cards, or related content sections elsewhere on the site.
After a Webflow publish, look for:
- Layout breaks caused by component, shared class, or style changes
- Missing images or images cropped at the wrong size
- Text overflowing containers, especially with long CMS field values
- Mobile layouts that look fine on desktop but break at smaller breakpoints
- Sections that shifted because spacing, grid, or flex settings changed globally
- CMS cards that look inconsistent because one item has longer text or a missing image
You do not need to inspect every pixel manually. The goal is to catch visible changes that visitors would notice: broken layouts, missing content, awkward spacing, and mobile views that no longer work.
For a small update, check the edited page and a few related pages. For a larger update, check a representative set: homepage, one landing page, one blog post or resource page, one CMS collection page, one page with a form or main CTA, and at least one mobile view.
On sites with more than 50 pages, manual visual review becomes hard to finish consistently. Sitepager captures screenshots across your pages and shows exactly what changed since your last update. Your team can review those changes before they go live.
How Do You Find Broken Links on a Webflow Website?
Broken links on Webflow sites usually come from three places: deleted CMS items, changed page slugs, and external resources that moved or disappeared.
The hardest links to catch are often inside CMS content. A blog post may link to another post whose slug changed. A case study may point to an older service page. A footer link may still reference a page that was renamed months ago. The page can look normal while the link returns a 404.
Check these areas first:
- Navigation links, including links pulled from CMS references
- Footer and legal links, since they rarely get reviewed
- Internal links inside blog posts, case studies, and resource pages
- CTA buttons on landing pages and campaign pages
- Redirects after form submissions
- External links to booking tools, partner pages, social profiles, and documentation
For a small site, you can click through the main navigation, footer, key pages, and primary CTAs manually. Once a Webflow site has a large blog, resource library, or CMS collection, manual link checking breaks down.
The issue is coverage. Teams often check the homepage, pricing page, and latest blog post. Older CMS pages get skipped, even though they may still rank in search, receive referral traffic, or support internal linking across the site.
A more comprehensive Webflow link review checks every published page, not only the pages someone remembers. It includes CMS-generated pages, redirects, and internal links that may break after content cleanups or slug changes.
Broken links are not only an SEO problem. They also hurt trust. If a visitor clicks a demo button, case study link, or resource link and lands on a 404, the page failed at the moment it was supposed to help them move forward.
What SEO Fields Should You Review Before Publishing?
Webflow gives teams direct control over meta titles, meta descriptions, canonical tags, Open Graph fields, and CMS-powered SEO settings. That control is useful, but it also makes it easy for small SEO mistakes to slip through templates and CMS pages.
Most Webflow SEO issues happen when templates are copied, dynamic CMS fields are left blank, or staging settings carry into production.
Common issues include:
- A duplicated page template keeps the wrong title or meta description
- A CMS field powering a dynamic page title is left blank
- A canonical tag points to the staging URL after a domain switch
- Open Graph titles or images are missing on new landing pages
- Alt text for CMS images is missing after items are copied
- Multiple CMS pages end up with the same title or description
These problems are easy to miss because the visible page can look correct. A visitor may not notice that a canonical tag is wrong or that an Open Graph image is missing. Search engines and social platforms may notice later.
Before publishing, check that important pages have:
- Unique meta titles
- Unique meta descriptions
- One clear H1
- Canonical tags pointing to the production URL
- Open Graph title, description, and image where relevant
- CMS fields filled in for new dynamic pages
- No staging URLs left in links or metadata
For Webflow CMS templates, pay special attention to dynamic fields. If a title tag depends on a blank CMS field, new items can inherit a weak or incomplete title. If the same description field is reused across a collection, multiple pages may end up with duplicate metadata.
Google Search Console may surface indexing issues later. But release review should catch clear metadata problems before they reach visitors or search engines.
How Do You Test Webflow Forms on Your Published Site?
Webflow forms can behave differently on staging, preview, and a published site with a custom domain. A form that works in the Designer can still fail in production.
Common causes include email routing, spam filters, reCAPTCHA settings, and third-party integrations. A form can render correctly, accept text, and show a button. It can still fail after submission.
Test forms on the published site, not only in preview. Check that:
- The form submits with realistic test data
- The success message appears
- Notification emails reach the right inbox
- Redirects lead to the correct thank-you page
- Connected tools such as Zapier, Make, CRM webhooks, or marketing automation platforms receive the submission
- Required fields and error states behave correctly
- The form works on mobile, especially inside modals or embedded sections
This matters most on high-intent pages: contact pages, demo pages, pricing pages, webinar pages, event pages, gated content pages, and campaign landing pages.
A form failure is different from a visual issue. If a section is slightly misaligned, someone may still convert. If the form does not submit, the conversion path is broken.
Email delivery and final form submission should still be tested manually. An actual form submission is the only way to confirm notifications arrive where your team expects them.
How Do You Check Interactive Elements After a Webflow Publish?
Webflow interactions and animations can behave differently on the published site than they do in Designer or preview mode. A dropdown may open correctly in preview but fail to close on mobile. A modal may stop firing on the live domain after a new embed or custom code block is added.
Interactive elements matter because they often control navigation, conversion, or content discovery. If they fail, the page may still look fine in a screenshot, but visitors cannot use it properly.
After a publish, test the interactions visitors actually use:
- Navigation dropdowns on desktop and mobile
- Mobile menus that open, close, and link to important pages
- Modal overlays that trigger on the right action and close cleanly
- Hover states on CTAs and buttons
- Accordion or tab sections
- CMS-powered interactions after content changes
- Embedded widgets such as booking tools, chat widgets, calculators, or forms
- Sticky headers or announcement bars on mobile
These checks require using the published site. Preview mode is useful for early review, but it does not replace testing the page visitors will use.
For smaller sites, keep a short list of important interactions to test before major publishes. For larger sites, focus on shared components first. Navigation, footer, modals, reusable CTA sections, accordions, tabs, and CMS templates can all affect many pages at once.
For example, during a redesign review, a CTA button appeared across seven pages but worked correctly on only five of them. The design looked consistent, but two conversion paths were broken. That is why interaction checks should include every page type where shared CTAs, menus, modals, or booking widgets appear.
Which Webflow Templates and Components Should You Test First?
You do not need to treat every Webflow page equally. Start with the areas where one change can affect many pages.
In Webflow, the highest-risk areas are usually:
- CMS collection templates
- Shared navigation components
- Footer components
- Reusable CTA sections
- Blog or resource templates
- Landing page templates
- Pages with embedded forms
- Pages using custom code or third-party embeds
- Components that display CMS text, images, categories, or author fields
- Multi-language or regional page variants
This is where many Webflow reviews fail. Teams check the page they edited. They miss the pages connected to it through components, CMS templates, shared classes, or dynamic fields.
For example, if you update a blog template, do not check only the latest post. Check posts with long titles, different authors, different categories, and several links in the post body. As you review them, look for missing images, broken layouts, and links that no longer work.
If your Webflow site has multiple language or regional versions, apply the same logic there. Test at least one page from each important version. Translated navigation labels, longer CMS text, regional links, and local CTAs can change how the same template behaves.
For more on checking location-specific content, see our guide to geolocation testing for websites.
The goal is to test templates and shared components against real content variations, not just the newest page or the page you edited.
How Can You Run These Checks With a No-Code Webflow Testing Tool?
Manual review breaks down quickly on a 100-page Webflow site. Your team may know what to check, but it is still hard to run the same review the same way after every publish.
That is the real challenge with Webflow QA. It is not that teams do not care. The review process is often informal: open the homepage, click a few links, check the latest page, maybe test the form, then publish.
That works until the site grows. Once you have CMS content, campaign pages, multiple templates, shared components, and frequent updates, one-off review is not enough.
Sitepager gives Webflow teams a repeatable review step without plugins or code. It works as a no-code Webflow testing tool. Enter a URL, run a check, and review screenshots, broken links, SEO fields, and page changes in one place.
For larger Webflow updates, staging versus production comparison is usually the most useful review step. Add your Webflow staging URL and your live production URL to Sitepager before you publish. Then review what changed between them. That review helps surface layout differences, link errors, missing SEO fields, unexpected page changes, and pages that exist in one environment but not the other.
A repeatable workflow gives your team a simple pattern:
- Capture a baseline
- Make website updates
- Re-run the check
- Review what changed
- Fix anything unexpected
- Publish with more confidence
This matters because Webflow sites are often owned by marketing, content, and web teams, not dedicated QA teams. The process has to be simple enough for non-engineers to use. It also has to be consistent enough to catch issues across the full site.
For the full website testing process, see Website Testing: The Complete Guide.
Frequently Asked Questions
How do you test a Webflow site before going live?
Before a Webflow site goes live, test the published staging URL or preview environment. Check the page layout, links, SEO fields, forms, redirects, and key interactions on the pages affected by the update.
For larger updates, compare staging against production. This helps you see what changed before the update goes live.
What breaks when you publish a Webflow update?
A Webflow update can break more than the page you edited. Shared components can change layouts across the site. CMS or slug changes can break links. Blank CMS fields can create missing SEO titles or descriptions. Interactions can behave differently on the live site.
These issues often appear on pages you did not directly edit because Webflow components, classes, and CMS templates are reused across the site.
Can you use a no-code tool to test a Webflow website?
Yes. A no-code Webflow testing tool can help you review a Webflow site without writing scripts or installing test frameworks. Sitepager lets you enter a Webflow URL, run a check, and review visual changes, broken links, SEO fields, and page changes in one place.
What is the difference between testing in Webflow Designer vs. the published website?
Webflow Designer is useful for checking layout and early interactions. It does not fully test what happens on the live site. Forms, redirects, custom domains, and third-party integrations can behave differently after publishing.
Always test forms, redirects, and important interactions on the live URL before treating the update as reviewed.
Why does editing one Webflow component break pages I never touched?
Webflow components, CMS templates, and shared classes can be reused across multiple pages. When you edit a navigation bar, footer, card component, collection template, or global style, every page using it can change at once.
That is why Webflow updates need a sitewide review step, not just a check of the page you edited.
How do I check for broken links on a Webflow site with a large blog?
For a small site, you can check navigation, footer, and main content links manually. For a Webflow site with a large blog or CMS collection, manual checking does not scale.
Links can sit inside hundreds of CMS-generated pages, including older posts that no one reviews often. Use automated link checking to find broken links across CMS content, footer sections, redirects, and older pages.
What causes SEO issues after a Webflow publish?
Webflow SEO issues often come from CMS fields, copied templates, or staging settings. A blank CMS field can create missing meta titles or descriptions. A copied page template can carry over the wrong SEO fields. A canonical tag can also point to staging after a domain change.
These issues are easy to miss because the page can look correct while the metadata is wrong. Review SEO fields as part of the same publish workflow, not as a separate cleanup task later.
How often should I test my Webflow website?
Test your Webflow website before every publish that touches shared components, CMS templates, SEO fields, forms, or interactions. For routine content updates, check the new page and the template it uses. For larger sites, run a full site check regularly. This helps catch stale links, missing fields, and older pages that may not get reviewed manually.
