How to Test a Squarespace Static Copy Before a GitHub Pages Cutover

You can move the public, page-based part of a Squarespace campaign site to GitHub Pages without rebuilding its design—but only after you separate static pages from features that require a server. Export the live site, give forms and other server-owned features a deliberate destination, then test the export on a temporary Pages URL before you change DNS.

This guide assumes you own the Squarespace site, have a GitHub repository, and can update DNS when the test is complete. It is a safer next step after assembling a Squarespace rollback kit: the rollback copy is your recovery point; this process proves the replacement can serve visitors.

1. Define the boundary of the static site

A static host serves files. It does not run a Squarespace server. That is ideal for a campaign, brochure, portfolio, or archive, but it changes what happens behind interactive blocks. ExFlow’s Squarespace exporter exports the published site as HTML, CSS, JavaScript, images, and media, and can send the result to Git or provide a ZIP. It does not make Squarespace-only back-end services follow the files.

Make a short inventory before you export. Visit every item as a visitor would, rather than deciding from the page editor alone.

The expected result is one list with an owner for each non-static feature. Do not call a form “tested” just because its fields render. ExFlow’s documentation specifically notes that server-run features such as form submissions, checkout, member areas, scheduling, and site search need their own plan after export.

2. Capture the published Squarespace site

Open the Squarespace export workflow, enter the published URL, and choose the assets you need: CSS, JavaScript, images/media, and all pages. If the public site is frontend-password protected, use the export setting for that password; unpublished private sites are a different problem and should not be treated as a public-site export.

For a campaign site, select all pages even when the navigation looks small. Old landing pages, thank-you pages, PDF links, and image variants can be reached from ads or bookmarks. ExFlow describes this as crawling the site and rewriting links to local files; save the export as a dated ZIP even if you will deploy through Git. That ZIP is a useful comparison point if a later refresh surprises you.

If your concern is not a one-time cutover but preserving a Webflow content set during a redesign, use this separate Webflow CMS content-freeze archive process. The evidence you need is different for a CMS route set.

3. Put the export in a clean GitHub Pages repository

Use a repository that is dedicated to the public static copy, or use a clearly isolated publishing folder in an existing repository. GitHub Pages can publish static files from a repository, and it needs an index.html, index.md, or README.md entry file at the top of the selected publishing source.

A minimal first commit should look like this:

site-export/
  index.html
  about.html
  assets/
  css/
  js/
  images/

Push the untouched export first. Avoid “cleaning up” paths or combining assets before you know the copy works; those changes blur the difference between an export defect and a manual edit. In the repository settings, configure Pages for the branch and folder that contain the entry file, then record the temporary Pages URL. GitHub notes that a Pages update can take up to ten minutes after a push, so wait for the deployment rather than diagnosing a normal build delay as a broken export.

The expected result is a public staging address that does not use your production domain. It gives you a safe place to test without sending real campaign traffic to a half-finished cutover.

4. Replace or neutralize server-owned actions before testing traffic

Now work from the inventory, not from hope. For each visible action, choose exactly one outcome:

1. Replace it. Configure a form service or your own endpoint, then send a real test submission and confirm receipt.
2. Keep it elsewhere. Link to an existing store, scheduler, or member system that remains live, and say where visitors are going.
3. Remove it temporarily. Hide a signup or purchase button if it would silently fail. A clear “contact us at…” path is better than a convincing form that drops leads.

Do not put secret keys into the exported JavaScript to recreate a server integration. GitHub Pages publishes static files, and GitHub explicitly warns that published Pages sites are public; browser-delivered values should be treated as public too.

For a comparable platform-specific boundary check, see how to replace Framer forms and analytics before static hosting. The services differ, but the rule holds: rendering a control is not proof that its destination still exists.

5. Run the five-surface staging test

Test the temporary URL in an incognito window and on a phone. Check these surfaces in order:

1. Routes: open the home page, every navigation item, one deep page, and one old campaign URL. Confirm internal links stay on the staging domain.
2. Assets: refresh with cache disabled; confirm images, fonts, videos, PDFs, CSS, and JavaScript load without blank areas or console errors.
3. Responsive behavior: test the narrow breakpoint, menu, gallery, accordion, and any animation that affects the buying or contact path.
4. Search and sharing: inspect title, description, canonical target, and social preview. A staging canonical should not accidentally instruct search engines to index the test URL.
5. Actions: submit the replacement form, follow external checkout or scheduling links, and verify analytics only after the consent flow you intend to use.

Write down each result as pass, fix, or deliberately excluded. That small receipt makes the DNS decision easy to explain later and avoids confusing a missing feature with an unnoticed regression.

6. Cut over DNS only after the repository is the source of truth

Once the staging test passes, connect the custom domain in GitHub Pages, apply the required DNS records, and keep the Squarespace site available until the new domain resolves and the same five-surface check passes on production. GitHub’s Pages setup documentation is the authority for configuring its publishing source and viewing the deployed site; follow its current domain guidance in your repository settings rather than copying records from an old migration.

Make one final commit that contains only intentional production changes—such as a new canonical target or a replacement form endpoint. Tag or note that commit as the cutover version. If something goes wrong, you can restore the prior DNS target or redeploy the known-good commit without guessing which local folder was used.

A practical next action

Start with a non-revenue landing page and build the inventory before you export. Then use ExFlow’s Squarespace exporter to capture the published copy, deploy it to a temporary GitHub Pages URL, and require one confirmed form submission plus a five-surface staging receipt before DNS changes. ExFlow also has dedicated Webflow and Framer exporters when another builder is the next migration—not a reason to treat those platforms as interchangeable.

A static copy is ready when its public pages work, its server-owned promises are honest, and the exact version you tested is the version you publish.