If you built your site with a Wix editor, you can take its frontend off Wix and host it yourself, and keep managing your business from the same dashboard. Your data and business logic stay exactly the same.
The result is a self-managed headless project, made up of your own frontend and the same backend as your editor-built site. That backend, including its dashboard, becomes the backend for your headless project.
You build, host, and maintain the frontend, and it reads and writes your project's data through Wix APIs. For flows such as checkout, login, and member accounts, you can redirect visitors to Wix-hosted pages instead of building them yourself against Wix APIs.
This article explains how the pieces fit together, so that the steps in Migrate a Wix Site to a Self-Managed Headless Project make sense.
Note: If you want to keep your editor-built site as your public website and only ever use your new frontend as an additional frontend, such as a mobile app, you don't need to migrate.
The migration changes what serves your public website, not the backend behind it.
After migration:
checkout.example.com. Visitors only reach it during those flows, such as checkout or login, not while browsing your public website.The migration doesn't affect any of the following:
A and CNAME records that route visitors to your project, not the separate MX, SPF, DKIM, and DMARC records that route email.Your frontend calls Wix APIs directly to read and write your project's data. It authenticates these calls through your headless client, which tells Wix which project to connect to.
This connection doesn't depend on domains. It works the same whether your frontend runs on a preview address or your public website, which is why you can build and test it against your project before you migrate.
Add a Frontend to an Existing Wix Site covers building this frontend, since the build process is the same whether you plan to migrate afterward or keep the frontend as an additional frontend indefinitely. Follow that guide first, while your editor-built site keeps serving as your public website. Migrating is the separate, later step where you switch that frontend to become your public website instead.
Any backend you built, such as HTTP functions, scheduled jobs, service plugins, or automations, keeps running on your project. The migration doesn't touch your code.
If you use Wix-hosted pages and part of your backend, such as an HTTP function, is reachable by URL, check whether that URL changes along with your project's domain. If it does, update any hardcoded URLs in your frontend or external services to match.
Migrating involves 2 kinds of things: your domains, and the Wix settings that reference them.
You have 2 domains:
www.example.com: the address visitors already use for your public website.checkout.example.com: the address you dedicate to your project's Wix-hosted pages.Wix has 2 settings that determine which domain plays which role, and the domain switch reassigns both of them at once:
| Setting | What it does | Before migration | After migration |
|---|---|---|---|
| Primary domain | The one domain that serves your Wix-hosted pages and backend. | Your main domain. | Your Wix subdomain. |
| Wix pages domain | The address visitors see while on a Wix-hosted page. | Not set. | Your Wix subdomain. |
Wix also has a 3rd setting, frontend link, that doesn't change during the switch. You set it to your main domain before the switch happens, and Wix uses it in emails and notifications, and as a return address after a Wix-hosted flow.
Primary domain and Wix pages domain end up pointing at the same Wix subdomain, which is what makes them easy to confuse. They have to match, because a secondary domain redirects to the primary domain instead of serving pages, so Wix-hosted pages only load at your Wix pages domain if that domain is also your project's primary domain.
They stay 2 separate settings because primary domain is a general Wix setting, while Wix pages domain is specific to configuring your Wix-hosted pages.
Visitors reach the Wix pages domain through a short-lived redirect session, and return to your frontend when the flow finishes.
In addition to setting your Wix pages domain, you update your headless client's redirect settings, so that Wix can send visitors back to your frontend after login and checkout. For details, see Allow Redirect URIs and Domains.
Most of the work happens safely before you migrate. Only the domain switch changes your live site, and it happens in a single coordinated step.
Every Wix site, including your project, serves its own pages on exactly 1 domain at a time, called its primary domain. Any other domain connected to the project redirects to the primary domain instead of serving pages of its own. Right now, that's your main domain, since it's the domain currently serving your editor-built pages.
The following table shows what changes:
| Domain | Before migration | After migration |
|---|---|---|
Main domain, such as www.example.com | Your project's primary domain. Serves your editor-built pages. | Points to your external host. Serves your frontend. |
Wix subdomain, such as checkout.example.com | Not connected to your project. | Your project's new primary domain. Serves your Wix-hosted pages and backend. |
Migrating doesn't add a second primary domain. It reassigns that role from your main domain to your Wix subdomain, so your main domain has to give up the role at the same moment your Wix subdomain takes it on. That's why the reassignment happens in a single step. You point your main domain at your external host and disconnect it from your project, while your Wix subdomain becomes the project's new primary domain.
Everything else, such as building and testing your frontend or updating your headless client's redirect settings, is safe to prepare ahead of time, without affecting your live site.
On a self-managed headless project, you're responsible for your public website's SEO, including metadata, redirects, and canonical tags, which tell search engines which version of an address is official.
Plan for a few kinds of redirects:
http:// to https://, and example.com to www.example.com.Last updated: 20 August 2026