Wix to Code: The Complete Migration Guide (2026)

The short answer

Wix has no code export of any kind. Wix's own position is that your site must run on Wix's servers. There is no HTML download, no CSS, no project files, and Wix Studio does not change this despite years of requests on Wix's own forum. A Wix migration is never a code transfer. It is a rebuild of the front end, with content recovered channel by channel.

The channel most guides point you at, the blog RSS feed at /blog-feed.xml, does not do what those guides assume. The feed is real and returns HTTP 200. It is also hard capped at 20 items with no pagination, and each item carries a plain-text excerpt of roughly 512 characters instead of the post body. On a 200-post blog that is 20 truncated fragments, about 1.5 percent of the archive, and not one of them is publishable. Treat the feed as a manifest, not as content.

Budget $5,000 to $25,000 for a 50 to 100 page site. The destination, Astro, Next.js or Payload, barely moves the one-time price. It moves the recurring bill and whether you can leave again later.

What Wix actually lets you take

Start by accepting the real inventory, because the gap between what people assume and what exists is where Wix migrations go wrong.

• Code: nothing. No HTML, no CSS, no JavaScript, no project export. Not from the classic Editor, not from Wix Studio.

• Blog posts: no export feature exists. Wix states plainly that it is not possible to export blog posts to other platforms. There is no XML, no JSON, no dump. The RSS feed is the only structured channel, and its limits are covered below.

• CMS collections: CSV. A Wix CMS collection exports to CSV, capped at 1GB or 50,000 items. Not XML.

• Store products: CSV. This one works. Products export to CSV from the dashboard. XML store export is explicitly not supported, so any guide offering you a store XML is describing a feature that does not exist.

• Contacts and form submissions: CSV from the dashboard.

• Media: download from the Media Manager. Do this before you cancel, because Wix CDN URLs stop resolving once the subscription lapses.

• Design, layout, navigation, animations, ADI structure: none of it leaves. This is what gets rebuilt.

The RSS feed is a manifest, not content

This is the single most expensive misunderstanding in Wix migration advice, so here is exactly what the feed contains, verified against live Wix blogs in July 2026.

The two hard limits:

1. 20 items, no pagination. There is no rel="next" link, no offset or page parameter, no cursor. Wix's own documentation says you cannot display more than 20 blog posts in an RSS feed. Post 21 is not reachable through this channel at all.

2. Excerpts only. There is no content:encoded element in the feed. The description field is plain text with a ceiling around 512 characters, and it truncates mid-word. Post body HTML, inline images, internal links and all formatting are absent.

What the feed does carry, and it is genuinely useful:

• title

• link, the full post URL, which means the slug is recoverable. This is the part that matters, because slugs are what your redirect map is built from.

• pubDate

• dc:creator, the author

• category elements, the post's tags

• enclosure, the featured image URL

Note that guid is not the slug. It is an opaque ObjectId, so do not build anything on it. Also absent: SEO descriptions and drafts.

So use it for what it is. Pull the feed first, parse those 20 rows, and you have a clean seed for your redirect map: 20 real URLs with dates, authors, tags and featured images already attached. That is a real head start on the highest-risk part of the migration. It is just not your blog.

Recovering the actual archive: crawl the rendered pages

Be clear-eyed about this: recovering a Wix blog is more work than a feed pull, and anyone who tells you otherwise is describing a job you will discover the truth about after you have committed. The only route that reaches the whole archive is crawling the rendered pages.

1. Enumerate every post URL from `sitemap.xml`, not from the feed. Wix splits sitemaps by section, so follow the sitemap index and collect the blog section in full. This is where posts 21 through 200 come from.

2. Fetch each post page and extract the body from the rendered HTML. Wix renders post content into a consistent container, so one selector usually covers the whole archive, but verify it against the oldest posts as well as the newest. Older posts often predate a Wix editor change and use different markup.

3. Collect every image referenced inside the body, not just the featured image from the feed enclosure. Download them, then rewrite the src attributes to your own paths before import.

4. Rewrite internal links. Body links point at old Wix paths. Map them to new paths during import, because fixing them post-launch means re-editing every post by hand.

5. Capture titles, canonical URLs and meta descriptions from the page head, since the feed does not carry SEO descriptions.

6. Reconcile the crawl against the feed's 20 rows. Where they overlap, the feed gives you authors and tags cheaply. Where they do not, you are reading them off the page.

Budget real time for this step. On a content-heavy site it is often the largest single line item in the migration, and it is the reason a blog-heavy Wix site costs more than a brochure site with the same page count.

ADI: lock-in that has already deleted people's work

Most lock-in arguments are hypothetical. This one is not.

Wix discontinued ADI on 2024-11-10, and unpublished ADI sites that had been inactive for six months or more were deleted. Not archived, not exported, not frozen. Deleted. If your site lived only inside a proprietary builder and you were not looking, the platform's product decision was also a decision about your work.

That is the concrete version of the argument. A site you cannot export is a site whose continued existence is somebody else's roadmap item. Wix Studio is the current answer and it still has no project or source-code export, so the structural situation has not changed.

AI editing: what is true and what is not

The common claim that AI coding tools cannot edit a Wix site is no longer true, and repeating it will cost you credibility with anyone who has checked. Wix ships an official MCP server at `mcp.wix.com/mcp`. An agent can connect to it and work against your Wix content through Wix's API surface.

The honest distinction is different and sharper. An agent connected to Wix reaches your content through a hosted, partial, versionless interface. There is no source code underneath, because Wix never produces any. So there is no repository, no branch, no diff to review before it lands, no git revert when a bulk edit goes wrong, and no build or test to prove the change works.

In a code repository the agent gets the whole artifact. It can read every file, change several at once, run the build, see the failure, and fix it. You review a diff before it ships and you can undo it in one command. That is the actual gap, and it survives the existence of an MCP server.

Where to land

The migration work is nearly identical whichever you pick. Choose on how content gets edited after launch.

Astro, for content and marketing sites

HTML-first, ships almost no JavaScript by default, and typed content collections map neatly onto a recovered blog archive. For a Wix site that is brochure pages plus a blog, this is usually the landing spot.

Next.js, when the site is really an app

Choose Next.js when you need React: gated areas, dashboards, search, serious commerce, genuinely interactive features. It ships more JavaScript than Astro, which is the right trade only when you need the interactivity.

Payload CMS, when editors need an admin UI

If non-technical people edit daily, pair the front end with Payload. Posts and products become Payload Collections with typed fields and rich text, and editors get drafts, autosave and live preview, which is the closest replacement for the Wix dashboard habit.

Two things a technical buyer should know first. Payload was acquired by Figma in June 2025. And Payload Cloud has paused new deployments, so there is no first-party hosting product to sign up for. The software is MIT licensed and free. Hosting and a database are a separate bill, realistically $8 to $30 per month for a client-grade database.

Storyblok or Sanity, when you do not want to self-host

Both give you a hosted, block-based editor with live preview. Check the seat counts before you commit: Storyblok's free tier is a single seat, which is a real constraint the moment you hand the site to a client team.

What it costs, before and after

Wix plan pricing, annual billing, as of July 2026: Light $17, Core $29, Business $39, Business Elite $159 per month. Selling requires Core or above. Wix does not publish monthly rates on the same footing, so compare annual to annual.

After migrating, expect $0 to $20 per month on a static-first stack with Cloudflare Pages, or roughly $20 to $50 per month on Vercel with a managed database.

One warning, because it catches agencies and freelancers regularly. Vercel's Hobby tier is non-commercial only, and Vercel's own definition of commercial usage covers a paid employee or consultant writing the code, and receiving payment to create, update or host the site. A client site built on Hobby violates the terms. Vercel Pro at $20 per user per month is the floor for client work.

The playbook

1. Inventory from the sitemap, not from memory. Pull sitemap.xml and follow the sitemap index into every section. Wix generates utility and member pages people forget exist, and a missed page is a missed redirect.

2. Pull the RSS feed as a manifest. Parse the 20 items for URLs, slugs, dates, authors, tags and featured images, and seed your redirect map with them. Then stop expecting content from it.

3. Crawl the rendered post pages for the actual bodies, driven by the sitemap URL list. Extract body HTML, download inline images, rewrite links and image paths. This is the long step.

4. Export what genuinely exports: store products to CSV, CMS collections to CSV, contacts and form submissions to CSV, and every asset from the Media Manager. Do the media download while the subscription is still active.

5. Rebuild the front end as components in Astro or Next.js, using the live Wix pages as the reference. This is the part Wix never lets you take, so it is rebuilt rather than migrated.

6. Map 301 redirects for every old URL and launch on a verified map. Test the redirects before DNS moves, not after. Resubmit the sitemap, watch Search Console, and keep Wix live and paid for a few weeks as a rollback path.

When you should stay on Wix

If your site is a handful of pages, nobody is asking for anything the templates cannot do, you have no developer relationship, and your blog is short enough that the 20-post feed cap is not a constraint, stay. Wix is a competent product and the export limits only bite on the day you leave. If that day is not visible from here, a migration is a cost with no return.

The calculation changes when the archive gets long. The bigger your blog, the larger the share of it that has no supported export path at all, and the more expensive leaving becomes every year you wait.

Get a plan for your specific site

Every range here is a starting point, not a quote. A free migration review looks at your live Wix site, counts what is actually in the sitemap, tells you what can be pulled versus what has to be crawled, recommends a destination, and gives you a fixed-price quote and a realistic timeline before you commit to anything.