AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.
Short answer
An attractive AI-generated website preview is not the same as a portable website. Before committing to a platform, ask for the files, disconnect the network, and test what survives. A useful handoff should state exactly what can run locally, what requires a server, and what remains tied to the original provider.
What ownership means in practice
There are at least four different assets to consider: the content you wrote, the images and their licences, the code and templates that render the site, and the operational services behind it. Exporting one does not automatically export the others. A page may work as static HTML while its contact form, customer login or live product catalogue still depends on a hosted backend.
For example, WordPress supports a WXR content export, but the WP-CLI documentation explicitly says WXR does not include site configuration or the attachment files themselves. Treat it as a content migration tool, not a complete operational backup.
A five-part portability test
- Request the deliverable: obtain a ZIP with HTML, CSS, JavaScript and required media, or a documented source project if the site needs a build process.
- Check the inventory: inspect the archive for a landing page, relative links, images, fonts, licence notes and readable project metadata. A screenshot inside a ZIP is not an export of a website.
- Disconnect: extract the files, turn networking off and visit every intended local page. Inspect images, navigation, layout and browser errors.
- Re-import: change a title, export, import the same ZIP into a fresh project and check that text, configuration and media survive.
- Document the boundary: list features that require a server, credentials, licences or a provider-specific runtime before promising migration.
Why an index.html file may not be enough
Browsers frequently treat file:// pages as opaque origins. As MDN explains, JavaScript fetch() requests to nearby local files may encounter CORS restrictions even when those files sit in the same folder. A static site built from ordinary relative links and packaged assets may work locally, but an app that expects to fetch JSON modules at runtime may need a local HTTP server. This is a browser security behavior, not proof that the ZIP is corrupt.
The right promise is therefore specific: “the six linked static pages were opened offline in tested browsers” is verifiable; “every modern app works by double-clicking index.html” is not.
Export is not re-import
A usable handoff has two directions. Export gives you an archive; re-import proves the archive retains information the editor needs. A polished static export may omit the editable design model entirely. If the editor cannot recreate layouts, colors, text and images from the archive, you have a deliverable for hosting but not necessarily a recoverable design project.
Keep a machine-readable project manifest alongside the rendered pages. It should document the export version, page list, design settings, asset references, and a compatibility policy for older archives. Import should reject unsupported or suspicious content instead of silently losing fields.
What a good free starter can offer
A free website starter can provide a genuinely useful result without promising production infrastructure: editable pages, a downloadable archive, simple offline navigation, an implementation brief and clear next steps. Paid implementation should be optional and clearly separated from access to the export. Forms, analytics, payments, membership and live integrations need separate configuration and validation before deployment.
Field notes from our own offline ZIP project
In Ebizapple’s UX-Arkitekten development log dated 23 October 2026, we recorded 288 passing automated ZIP tests after correcting a legacy HTML attribute scanning issue. The same log records two isolated studio servers returning HTTP 200, while the new Chromium browser test was blocked by an unavailable runtime. That distinction matters: passing archive-integrity, import-security, lint and build checks does not prove that an end user has successfully downloaded and opened the site in a browser.
Our practice is to keep separate evidence for archive structure, editable project re-import, local images and links, browser execution, and public hosting. We do not describe unfinished browser verification as production-ready. Our dated internal development record keeps the test counts, constraints and next checks for every round. This is project engineering evidence, not a claim of an independently certified export.
Decision checklist
Before choosing an AI website tool, ask: Can I download a functioning project? Can I open it without its builder? Can I import it back without losing edits or media? Which features stop working offline? Can I audit third-party rights? Who controls my domain and hosting? What concrete tests prove these answers?
Choose the platform whose limitations are documented and whose handoff you can independently verify—not simply the one with the most impressive preview.
What MDN, Python and WordPress documentation say about running and moving a site
The portability test above rests on a few technical facts that are documented in plain language by the projects themselves. They are worth reading before you judge whether an export is complete.
MDN has a whole guide on How do you set up a local testing server? It explains that Some examples won't run if you open them directly in the browser using a file:// URL. It lists three common causes. Pages may use asynchronous requests, which some browsers will not run from a local file because of security restrictions. Pages may use a server-side language, and Server-side languages (such as PHP or Python) require a special server. And pages may include other files, since browsers treat requests to load resources using the file:// scheme as cross-origin requests.
The same MDN guide shows the usual workaround. Running python3 -m http.server in the site folder hosts all files in the current directory on localhost:8000. The Python documentation adds an important limit to that tool: http.server is not recommended for production, because it only implements basic security checks. It is a way to test an archive, not a way to host it.
Relative links matter too. MDN's reference for the <base> element says it specifies the base URL to use for all relative URLs in a document. An exported page that still carries a base URL pointing at the original provider can quietly send every relative link back to that provider.
For content, the WordPress Tools Export Screen documentation calls the export file a WordPress eXtended RSS or WXR file, and lists what it holds: posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users. That is a useful content package. It matches the point made earlier that WXR is a content migration tool, not a full copy of a working site.
How these sources fit the portability test
The article already makes the key distinction: a static site built from ordinary relative links and packaged assets may work locally, while an app that fetches JSON at runtime may need a local HTTP server. The MDN guide gives the reason and the fix in one place. A failure when double-clicking index.html is a browser security behavior, not proof that the ZIP is corrupt.
The "Disconnect" step in the five-part test is where these facts show up. If a page only works through a local server, the handoff should say so, and the "Document the boundary" step should list it next to forms, logins and live catalogues that need a backend.
The field notes also connect here. The development log records 288 passing automated ZIP tests and two isolated studio servers returning HTTP 200, while the Chromium browser test was blocked. Archive checks and a server answering are both different from a person opening the pages in a browser. The sources above explain why those are separate questions, and why each one needs its own evidence before anyone calls an export portable or ready for production.
Checklist for testing an exported site yourself
- Unzip the archive into an empty folder and open
index.htmldirectly from disk. - Note every page, image or script that fails, and check the browser console for blocked requests.
- Start a local server with
python3 -m http.serverin the same folder and test again onlocalhost:8000. - Write down which features work only through a server. That list is part of the handoff, not a bug report.
- Search the HTML for a
<base>element or absolute links to the builder's domain. - If the site came from WordPress, confirm that media files are exported separately from the WXR content file.
- Do not use the test server as hosting. Choose a real host before going live.
More questions
My exported site works on localhost but not when I double-click it. Is the export broken?
Not necessarily. MDN explains that browsers treat local file:// resources as cross-origin and may block asynchronous requests from local files. If it works on a local server, the files are probably fine and the site simply needs to be served over HTTP.
Can I host the site with Python's built-in server?
Not for a public site. The Python documentation states that http.server is not recommended for production and only implements basic security checks. Use it for testing the archive, and use a proper web host for the live site.
Sources and verification scope
WordPress Developer Resources: WP-CLI export — scope of WXR and excluded files. MDN: Same-origin policy and MDN: CORS request not HTTP — browser restrictions on file URLs. The five-part test is an editorial evaluation framework, not a certification standard. No results from Ebizapple UX-Arkitekten's pending browser test are claimed here.