November 9, 2026
I Test a Webflow Collection Export With a 12-URL Receipt
A practical Webflow CMS export check: choose 12 representative URLs, deploy a static copy, and record what passes before changing hosting.
I Test a Webflow Collection Export With a 12-URL Receipt
When a Webflow store has CMS-driven category and product pages, I do not call a static export ready because its homepage looks right. I pick 12 URLs that represent real shopper paths, deploy the export somewhere disposable, and record what each route does. That small receipt catches missing collection pages, bad asset paths, and silent form failures before a hosting change becomes a customer problem.
For the export itself, I use ExFlow’s Webflow exporter because it captures the published site as static HTML, CSS, JavaScript, media, and individual CMS pages. It can also crawl the sitemap and internal links when Export all pages is enabled. The important boundary: a static copy preserves browser-facing pages; services that need a platform at request time still need a decision.

Why I use a receipt instead of a giant site crawl
A full crawl is useful, but it is a poor first answer to “can we safely put this catalog on static hosting?” A collection has a few route shapes that carry most of the risk: the shop landing page, a collection, a paginated or filtered view, an individual product, and a content page linked from merchandising.
My receipt is intentionally small enough to review in one sitting. It is not proof that every URL is perfect; it is a release gate that tells me whether I need a broader crawl or a different migration plan. I also keep it next to the exported ZIP or Git commit, so the next export has a known baseline.
The 12 URLs I choose for a Webflow catalog
Pick real URLs from the live, published site—not guessed patterns. Replace any row that your store does not have.
| Route type | Count | What I check |
|---|---|---|
| Homepage | 1 | Hero assets, primary navigation, top collection link |
| Collection landing pages | 2 | Product cards, images, prices or labels, collection navigation |
| Individual CMS product pages | 3 | Main media, variant-independent copy, related links, page title |
| Editorial or buying-guide CMS pages | 2 | Rich-text images, internal product links, canonical metadata |
| Policy / shipping / contact pages | 2 | Footer links and any embedded widget or form |
| Intentional 404 / redirect check | 2 | Unknown path response and an old campaign URL, if one exists |
The product pages are not chosen at random. I include one ordinary bestseller, one product with unusually large media, and one awkward item with a long title or lots of linked content. Those are the pages most likely to expose a layout or path problem that a pretty homepage hides.
Export the published site, then isolate the static boundary
Start from the public Webflow URL. ExFlow documents that it downloads public pages and assets, rewrites links to local paths, and can export CMS collection item pages as individual static pages. I enable CSS, JavaScript, images/media, and all pages, then save a dated export.
Before deployment, make a short dependency note. Here is the version I use:
| Feature | Static export result | Decision before cutover |
|---|---|---|
| Product and collection content | Browser-rendered HTML and assets | Check representative CMS routes |
| Webflow interactions | Client-side runtime and data attributes can ship | Exercise the actual slider, tab, or menu |
| Contact form | Needs a receiving endpoint | Reconnect, replace, or remove it |
| Ecommerce checkout | Needs the commerce service | Keep the service path or use another checkout |
| Search, member area, Editor | Need server-side or platform support | Choose a replacement or keep them out of scope |
That distinction matters. A static export is a portability tool, not a promise that every hosted workflow has become static. If your storefront depends on a native contact flow, read my notes on reconnecting a Framer contact form after a static move for the same underlying question: where will the submission go now?

Deploy to a throwaway URL before changing DNS
I deploy the output to a preview URL or separate static host first. ExFlow can download a ZIP or sync an export to Git, S3, FTP, or its own hosting; the choice matters less than having a public environment that behaves like the intended destination.
Then I fill the receipt one row at a time:
- Open the live URL and the preview URL in separate tabs.
- Confirm the preview returns a successful page, not a soft redirect to the old host.
- Check the page title, main heading, hero or product media, and one internal link.
- Use a narrow viewport once on every route shape.
- Trigger one interactive element where it exists.
- Record pass, replace, or out of scope—not “looks fine.”
A “replace” result is useful. It tells the team exactly which implementation is missing: a form endpoint, a redirect rule, an analytics snippet, or a search alternative. “Out of scope” is also legitimate, but only if the owner agrees not to ship it as a surprise.
For catalog content specifically, I borrow the discipline from my five-record Shopify bulk-edit receipt: sample normal records, edge records, and one thing that should not change. A small, defensible sample beats a vague visual sweep.
Three failures this check catches early
A collection card loads, but its image does not. This usually points to an asset path or a CSS-referenced image that was not included as expected. Do not fix it only on the preview; re-export or correct the asset handling, then repeat the receipt.
A CMS product page exists, but its internal links land on old-domain URLs. Verify links from the product body, related-items modules, navigation, and footer separately. The route itself can be present while its shopper path is still broken.
The static page looks complete, but the conversion action is dead. A form, checkout, search, membership gate, or analytics event can require a replacement. Treat it as a product decision, not a cosmetic defect. The same discipline is why I run a broken-link drill before trusting an automated Webflow publishing flow.

What I save with the export
The deliverable is not just a folder. I save the export date, source URL, destination or commit, the 12-URL receipt, and the explicit dependency decisions. That gives a future operator enough context to re-run the test after a collection refresh.
If the receipt passes, I can use the static copy for a backup, a handoff, or a controlled hosting change. If it does not, I have a short, concrete repair list instead of a heroic migration project. For a broader recovery mindset, see how I put a Webflow site in Git before a high-risk launch.
ExFlow also has dedicated exporters for Squarespace and Framer, but keep the test tied to the platform you are actually moving. The reliable next step is simple: choose your twelve live Webflow URLs, run one export to a preview destination, and make every row earn a pass.