I Added a Tiny Smoke Test After Every Static Site Export

I used to think a successful static site export was the finish line. The files appeared, the home page opened, and I moved on. Then I would find out later that a deep link returned a 404, a font was loading from the wrong place, or the archive was only useful on the machine that created it.\n\n\n\nThe fix was not a bigger deployment system. I added a tiny smoke test after every export. It takes a few minutes, catches most of the unglamorous failures, and gives me a useful answer when someone asks whether the exported site is actually portable.\n\nI use ExFlow to export published Webflow sites into static HTML, CSS, JavaScript, fonts, and media. The export itself is useful, but the habit that made it trustworthy was treating the result as a build artifact that needed a short acceptance test.\n\n## What the home page check misses\n\nOpening index.html tells you almost nothing about paths, direct navigation, or deployment behavior. Browsers can be generous when local files are opened directly. A static host is not always so forgiving.\n\nI learned to test four things:\n\n1. The home page loads.\n2. A deep URL loads directly.\n3. The main assets load from their deployed paths.\n4. The primary navigation still reaches the expected pages.\n\n\n\nThat list is intentionally modest. I am not trying to recreate a full end-to-end test suite for an archive. I am checking whether the exported site behaves like a site rather than a folder of files.\n\n## I start a real static server\n\nThe first change was to stop testing exports by double-clicking files. I run a local static server from the exported directory instead. Any server works; the important part is accessing pages through HTTP.\n\n~sh\nnpx serve .\n~\n\nThen I open the home page and paste a deep path into the address bar. I do not navigate there from the home page first. Direct navigation is the check that reveals whether a path only works because the previous page happened to be open.\n\nFor a production-like check, I deploy the export to a temporary static host or a simple branch preview. That is where relative asset paths, redirects, and host-specific routing rules become visible.\n\n## I keep one page inventory next to the export\n\nBefore I export, I make a small text file with the pages that matter: home page, contact page, main collection or product guide pages, an important campaign page, and one deep article or resource page.\n\nIt is not a sitemap. It is a risk list. These are the pages that would create confusion if they disappeared during a redesign or handoff.\n\nI picked up this idea while creating a Webflow redesign backup checklist. The useful part is not collecting every URL. It is making sure the high-value paths have a named place in the verification step.\n\n## The curl check is boring on purpose\n\nOnce the export is on a preview URL, I use a compact status check. It does not replace looking at the page, but it makes obvious failures hard to ignore.\n\n~sh\nfor path in / /guides /contact; do\n curl -L -s -o /dev/null -w '%{http_code} %{url_effective}\n' https://preview.example.com$path\ndone\n~\n\nI expect a success response for each path. If a page returns a redirect, I want to see the final destination. If it returns a 404, I fix the path or hosting rule before I call the archive ready.\n\n\n\nI also open developer tools for one pass and look for missing assets. Fonts and images are the most common quiet failure. A page can look almost right while using a fallback font or missing the one product image that was supposed to carry the page.\n\n## I write down the live dependencies\n\nAn exported static site can preserve the public layout while some features remain connected to live services. Forms, commerce, account pages, analytics, embeds, and search integrations do not automatically become standalone just because their surrounding page exported.\n\nI keep a short README beside the export with three sections: what was tested, what is static, and what requires a service. This turns a handoff from “here is a ZIP” into something another person can understand without guessing.\n\nFor Squarespace sites, I use the same approach: make the public copy, then document the pieces that need separate handling. That is the practical core of this Squarespace storefront archive workflow.\n\n## The test I would automate next\n\nIf I had many exports to check, I would put the page inventory in a small JSON file and have a script fetch each URL, assert a success response, and flag missing image or stylesheet requests. I would still keep a visual pass for key pages, because a 200 response cannot tell me whether the wrong font has shifted every headline.\n\n\n\nBut even without automation, this little ritual has changed the quality of my exports. I now know whether a static copy is usable before a redesign makes the old site difficult to inspect.\n\n*TL;DR:* export the site, serve it over HTTP, test a few direct URLs, check the assets, and record the live dependencies. The result is not just a backup. It is a reference site you can actually hand to someone. What is the one deep link you would hate to discover is missing after a redesign?