Migrate website content to static hosting
Moving away from a builder or CMS starts with separating the pages visitors see from the services behind them. Create a static snapshot of public content, check the files and use this guide to plan the work that remains. A capture is a starting point for migration, not an automatic transfer of your entire website.
Capture a page before you move
Download reachable HTML and assets within your plan’s page and depth limits.
Start free — 2 copies a month
Copy only sites you own or have permission to archive. See permissions.
What moves, and what needs a new home
A migration workflow in three stages
Plan the move before cancelling the old platform
When you migrate website content, begin with an inventory rather than a domain change. Record important URLs, navigation groups, downloadable documents, images, language versions and pages that receive useful search traffic. Separate public information pages from private areas and business transactions. A brochure site may suit static hosting well; a membership service usually needs a separate application migration. Keep your current platform available while you establish which parts can become static files and which parts cannot.
Check whether the old provider offers a native content or database export as well. That export and a front-end snapshot serve different purposes and may both be worth keeping. Record your existing DNS settings and account ownership, but do not put credentials in a capture URL. Plan who will maintain content after the move. If colleagues need visual editing, select and test the replacement workflow before retiring the editor they currently depend on.
Choose the mode for the content you need
HTTP mode collects the HTML delivered by the source server and its available referenced resources without rendering the page in a browser. This is often a sensible first test for traditional blogs and information pages. JavaScript resource discovery is not the same as executing an application. If the useful content appears only after the browser runs JavaScript, an HTTP capture may contain little more than the initial shell, even when the live page looks complete.
JS-rendered mode loads the page in a browser and saves the observed DOM as static HTML. Page scripts are removed and dynamic APIs are not replayed. This can preserve visible client-rendered content, but not the original SPA's interactive behavior. Content behind clicks, logins or late requests can still be absent. Test more than one page type and use the advanced workspace when you need explicit page, depth or path controls; the inline tool uses your effective account defaults.
Separate the static pages from the application
A builder or CMS often hides several systems behind a single page. The text and styling of a newsletter form can be captured while the subscription endpoint remains on the old service. Product descriptions may transfer while inventory, tax calculations and checkout do not. CMS editing, scheduled publishing, server code and databases are not exported. Give each feature a deliberate destination: a replacement service, a new implementation or a clear removal from the migrated pages.
Review scripts and embedded services before publishing the archive. HTTP downloads may retain scripts that contact the original site; the sandboxed app preview does not make those files safe or independent. JS-rendered output removes page scripts, so script-powered menus or widgets may need rebuilding. Update forms, analytics, consent tools and search intentionally. Use non-production test data to verify any replacement integration, and never assume a visually familiar page is connected to the correct service.
Use the report to find gaps before launch
Open report.json alongside the saved-page list and route manifest. Check missing, failed and skipped resources, as well as any page, size or time limit indication. A broken stylesheet or font can affect many pages, so fix shared dependencies before reviewing isolated cosmetic differences. Issue lists are bounded and indicate truncation; a short displayed list is not necessarily the whole set of gaps. Compare the actual exported paths with the URLs in your migration inventory.
Do not use file count as a substitute for page coverage. An archive can contain route aliases, helper files and many assets for a small number of source pages. Partial results have a downloadable ZIP only if they pass delivery checks; failed or cancelled jobs do not provide one. If essential content is absent, adjust scope or mode and run another appropriate capture. The service does not recreate unavailable pages or silently repair every missing resource for you.
Verify the archive on your intended static host
Extract the entire archive and deploy the files to a staging site, keeping their relative layout intact. Test the entry page, navigation, images and fonts, then enter nested URLs directly in a fresh browser tab. A link that works from the homepage may still fail when a visitor loads the nested route directly. Directory indexes, trailing slashes and fallback rules differ between hosts; configure them against the exported paths rather than assuming the old platform's routing will follow you.
Create explicit redirects for old URLs that have changed, and check page titles, descriptions, canonical links and language links in the files you intend to publish. Captured metadata may still name the source address or staging assumptions. Keep your preview environment out of search results where appropriate, then remove staging-only restrictions for launch. Test narrow screens, keyboard navigation and all replacement forms. Deployment and search configuration are your work; downloading an archive does not perform these checks automatically.
Make the DNS cutover reversible
Before switching, add the domain to the new host and follow its verification and certificate instructions. If your DNS provider allows it, lower the relevant record TTL ahead of the move, allowing the old TTL to expire before cutover. Record existing A, AAAA and CNAME values and preserve unrelated mail and verification records. A web-hosting move should not accidentally replace MX records or email authentication settings. Avoid changing nameservers unless that is an intentional, separately checked part of the plan.
At cutover, update only the records required by the new host and verify both the root domain and the www variant over HTTPS. DNS caches do not all update at once; keep the old host available during the transition. Check representative URLs, redirects, forms and missing-file responses from more than one connection. Retain the prior DNS values and archive so you can roll back if necessary, while remembering that rollback also takes time to propagate. Cancel the old platform only after the new site is stable.
Choose a scope that fits your plan
Free: $0 — 2 copies/month, 1 page each, depth 0. PRO: $19.90/month or $99/year — 50 copies/month, up to 200 pages, depth 5. Unlimited: $29.90/month or $149/year — no plan copy, page or depth cap; safety caps apply. All prices are in USD.
Free gives you real files, not just a preview. Monthly quotas reset each UTC calendar month, including on yearly plans.
Unlimited means no plan quota for copies, pages or depth, not an unlimited job. Default safety limits are 1000 pages, depth 20, 200 MiB and up to 24 hours per capture, with 1 active job per account. Server limits may be lower; the capture form shows your effective limits.
Download access is available for 30 days after completion, subject to the delivery result. Download important files promptly. Missing resources and partial captures are reported, not hidden.
Frequently asked questions.
General
You can capture reachable public front-end pages, subject to the source and your limits. This is not a platform-specific project exporter: the original editor, database, server code and private content do not transfer. Test a representative page and plan a separate replacement for the features that need a backend.
No. You download and inspect the files, upload them to your chosen host, configure routes and redirects, and manage your own domain records. Test on staging first, preserve mail-related DNS settings and keep the old host available until the cutover is verified.
Capturing
Not as preserved services. Forms may retain their appearance, but submissions need a configured backend. CMS administration and editing are not included in the static ZIP. Replace these functions or remove their controls before publishing; JS-rendered captures also remove page scripts.
Review report.json, the route manifest and the actual saved pages. Check missing, failed, skipped and truncated issue lists and any budget limit. Adjust scope or mode where appropriate and verify replacement assets yourself. A partial ZIP is available only when delivery checks pass; failed and cancelled jobs have no ZIP.
Privacy & permissions
It depends on your rights and intended use. You can archive your own site or a client's site with authorization. A public page is not automatically free to copy or republish; personal backups must still comply with terms, copyright and applicable law. A capture grants no new rights. See the permissions page linked in the hero and footer for guidance and rights-concern reporting; this is not legal advice.