How to audit a Webflow site

Audit a Webflow site by crawling the published domain and checking four design-driven failure points: heading levels chosen for size rather than structure, oversized hero images and background videos, missing alt text on CMS images, and collection template pages with duplicated titles and descriptions. The markup itself is clean, so the problems are almost always authoring decisions.

Last updated 2026-07-28

Why do Webflow pages end up with broken heading order?

Because in the Designer a heading level is a visual choice as much as a structural one, so an H1 gets used for a large statistic and an H4 gets picked because it happened to look right at that size. The result is skipped levels, multiple H1s on a page, and a document outline that describes the layout rather than the content.

The fix is a habit rather than a setting: choose the level for structure first — one H1 that states what the page is about, H2s for its major sections, H3s beneath those — then restyle it in the class system until it looks right. Webflow makes that restyling trivial, which is precisely why the shortcut of picking by appearance is so tempting.

This matters more than it used to. Answer engines lean heavily on heading structure to work out what a page covers and which passage answers which question, so a page whose outline is decorative is harder for them to quote. The heading order and H1 guides cover what a correct hierarchy looks like.

What makes a Webflow site slow when the markup is clean?

Media weight, nearly every time. Webflow's hosting and generated HTML are fast, so when a Webflow site is slow the cause is usually a full-resolution hero image, an autoplaying background video, a heavy Lottie animation or a set of large custom font files — all of them authoring decisions rather than platform limits.

Background images deserve particular attention because they behave differently from image elements: an image placed in the Designer gets responsive variants generated for it, while an image applied as a CSS background does not receive the same treatment. A full-width background photo uploaded at its original resolution is therefore shipped at that resolution to a phone.

• Hero background images are frequently uploaded at full resolution — resize before upload and let Webflow generate responsive variants where it can.
• Background videos are heavy; consider a poster image with click-to-play instead of autoplay on mobile.
• Lottie animations and large custom fonts both delay first render — subset fonts and load only the weights actually used.
• Check that lazy loading is enabled for below-the-fold images, and disabled for the hero.
• Watch for third-party embeds added through custom code, which sit outside anything Webflow optimises for you.

Why do all my Webflow CMS pages have the same title?

Because the collection template's SEO title and meta description fields are still set to static text instead of being bound to CMS fields. Every item page is generated from that one layout, so a hard-coded title propagates to all of them — fifty case studies with identical metadata is a routine finding.

Bind the title field to the item name, the meta description to a summary or excerpt field, and the image alt attribute to a dedicated alt text field on the collection. If the collection has no summary field, adding one is usually less work than writing fifty descriptions by hand, and it gives editors a place to write the description as they publish.

Identical titles repeating down a crawl report are the unmistakable signature of an unbound field, which is why this problem is close to invisible when you check pages individually and obvious the moment you look at the whole site at once. The meta description guide covers what each one should actually say.

Should I audit the webflow.io staging domain or the live site?

Audit the published production domain. Webflow noindexes .webflow.io staging subdomains deliberately, and canonicals, redirects and any custom domain-level configuration resolve differently there, so a staging audit will report problems that do not exist in production and miss ones that do.

The exception is pre-launch work, where production does not exist yet. There, a locally run auditor that drives your own browser can measure a staging build directly — useful for catching image weight and heading structure before launch rather than after — as long as you re-run against production once the domain is live.

Either way, check the site-level SEO settings while you are there: Webflow generates a sitemap automatically and lets you supply a robots.txt, and both are worth confirming rather than assuming.

How do I check every Webflow page at once?

Crawl the published site and read the report column by column, because Webflow's characteristic failures are template failures — one unbound CMS field, one oversized hero in a reused section — and they only reveal themselves as repetition. A page-by-page review of a fifty-item collection is fifty chances to miss the same fact.

Audra crawls the live domain and runs Google Lighthouse, axe-core accessibility checks, broken-link detection and its own HTML SEO and answer-engine checks on each page, rolling them into one Audra Score weighted performance 30%, SEO 30%, accessibility 25%, best practices 15%. Default crawl depth is 100 pages, configurable, with include and exclude globs so a large CMS collection can be sampled rather than exhausted.

It is a desktop app for macOS (Apple Silicon, signed and notarized) or Windows (64-bit) that uses your own installed Chrome and never sends crawl data or reports off the machine, which is what allows it to audit a password-protected pre-launch build as well as a live site. Reports export as self-contained HTML or print-ready PDF — handy for handing a client a document rather than a login. Audra is $19 once with a free 7-day trial, no subscription.

For the design-side checks that a crawl surfaces most often, the image alt text guide is the one to read alongside this.