Your ChatGPT build deserves a real home: get it live on Wix Headless → You asked ChatGPT for a website and it gave you one. Maybe that's a live link on a chatgpt.site address, maybe it's a wall of HTML sitting in a chat window. Those are two very different starting points, so the answer to "I built a website on ChatGPT, how do I host it?" depends entirely on which one you're holding. Go from ChatGPT build to live site with Wix Headless. Upload or drag in the HTML, CSS and JavaScript files ChatGPT gave you to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: how to host a website you built with ChatGPT ChatGPT can give you a deployed Site, raw code in a chat or a Codex project, and the last two still need a host. Pull clean files out, then upload them or hand them to a coding agent, or start fresh with the Wix plugin for ChatGPT. You'll learn: The three things ChatGPT might have given you What ChatGPT Sites does well and where it stops How to get clean, hostable files out of a chat Three ways to get a ChatGPT build onto Wix What breaks the moment a ChatGPT build gets hosted What building a website on ChatGPT actually means There are three versions of this and they lead to different places. You may have a ChatGPT Site, which is already deployed and sitting on a URL. You may have code that ChatGPT wrote into the chat or into a canvas, which is just text until you put it somewhere. Or you may have a real project built through Codex, which is a folder of files like any other codebase. The middle case is the most common and the most frustrating because the site looks finished on screen and does nothing at all until it's hosted. A block of HTML in a chat window is not a website and its a very different thing from what a website builder produces and knowing which one you have saves a lot of circling. Understand the basics: What is a headless website Before you start: work out which of the three you have before you do anything else. A deployed Site needs a migration decision, chat code needs a host and a Codex project needs a deploy step. Skipping this is why people end up trying to solve the wrong problem. Built in a different tool? There's a companion guide on how to host a website you built with Claude. If your site is already on ChatGPT Sites ChatGPT Sites lets you create, preview, publish and share interactive websites and lightweight apps from a prompt. OpenAI positions it for dashboards, project trackers, launch calendars, prototypes, internal portals and reports, and for that work it does the job with essentially no setup. A few things are worth knowing before you treat it as your permanent home. It's in public beta for workspaces, Plus and Pro accounts, so it isn't on Free or Go and it wasn't available in the EEA, Switzerland or the UK at launch. Usage limits apply across every Site on your account during the beta and reaching one can stop a high-usage Site staying publicly available. Custom domains work, with a catch worth planning around. Sites doesn't register a domain for you, so you need to already own one and be able to edit its DNS records. Custom domains also weren't available in Enterprise workspaces at launch. You can take payments through a third-party payment processor but you're responsible for connecting, configuring and maintaining it, and for fulfillment, refunds, customer support and calculating and remitting tax. Some frameworks, databases and background services aren't supported by the Sites runtime either. Worth being clear on: none of that makes ChatGPT Sites a bad product, it's built for internal tools and prototypes and it's genuinely good at those. A public site that takes orders, manages bookings and holds customer records is a different job and it's the job Wix Headless was built for. Choosing between them is about what the site needs to do next, not which tool is better. Read also: How to make an online store with ChatGPT How to sell from a website built in an LLM Can ChatGPT build a website How to upload a website and make it live How to get your code out of ChatGPT Ask for a single self-contained file Ask ChatGPT to rewrite the site as one self-contained HTML file with the CSS and JavaScript inline. Fewer files means fewer references that can break once the site leaves the chat window, and it sidesteps most of the path problems covered further down. Save everything it references If your site does span several files, save all of them into one folder and keep the structure ChatGPT assumed. A stylesheet that was described in the chat but never saved is the single most common reason a downloaded site renders as unstyled text. Know what the upload accepts Your entry file needs to be an HTML file at the top level, named index.html. HTML files buried only inside subfolders aren't accepted. Accepted file types cover markup, styles, scripts, images, fonts and data files like JSON or XML. Video and WebAssembly are rejected. Size limits are 3MB per file and 20MB in total. Uploads deploy static files only, so an Express server, framework API routes or server-rendered templates won't come along for the ride. If your project has a build step, upload what the build produces rather than your source. Good to know: connecting to Wix Headless requires no server setup and no backend code. But you're still building and owning a frontend, which means some familiarity with your chosen AI tool affects how smooth the process is. The connection itself is handled in one prompt. What you build on the frontend once connected is still entirely up to you. Three ways to get a ChatGPT build onto Wix Drag and drop your files Upload the folder directly and the site goes live on a Wix URL within seconds, with hosting, SSL and the CDN set up for you. For a single self-contained HTML file this is the whole job, start to finish, and it's the fastest route out of a chat window. Use Wix Headless drag and drop here. Hand it to an AI coding agent Wix's AI toolkit works with coding agents including Codex, Cursor and VS Code. Point your agent at the Wix Headless skill file at wix.com/headless/skill.md, tell it to connect your project, and it scaffolds and deploys without you editing a config by hand. This is the natural path if your build already came out of Codex. Deploy from the command line If you'd rather drive it yourself, the Wix CLI previews the project locally and releases it when you're ready. It's the same deployment either way, so this comes down to taste rather than capability. Ran Levi, Developer Advocate, Wix “The hardest part of shipping something real has never been the frontend. Anyone can build a beautiful UI fast now. The wall people hit is always the same: payments, bookings, a CMS that actually works. Wix Headless knocks that wall down. You connect your frontend to the infrastructure millions of businesses already run on, in one prompt. You're not a backend engineer, you're just shipping.” Worth knowing: Wix-managed headless means Wix handles all hosting, CDN, SSL and scaling automatically. Self-managed headless means you host the frontend on your own infrastructure and connect to Wix business data through the API. Both paths connect to the same complete Wix business backend. The choice comes down to how much control you want over your hosting environment, not what backend features you can access. Learn more: How to publish a website What breaks when a ChatGPT build gets hosted File paths cause most of it because a page that points at images or scripts by where they sit on your computer works perfectly in your browser and fails everywhere else. Relative paths fix it and ChatGPT will rewrite them if you say where the site is going to live. Next is anything that quietly assumed a server. API routes, server-side rendering and database calls never run on a static deploy, so the page loads and the interactive parts sit there doing nothing. Assets pulled from outside sources fail the same way if that source blocks hotlinking. Then there's structure, so an entry file not named index.html, or one sitting in a subfolder instead of at the top level. It's a two-second fix that looks like a catastrophic one. Worth knowing: none of this means ChatGPT built it wrong. A file path that works locally is correct locally and telling it where the site will be hosted before you ask for the files is one extra line in your prompt and it removes most of this list. Hosting a ChatGPT website FAQ: Can you run an online store on a ChatGPT Site? You can take payments through a third-party payment processor but you connect, configure and maintain it yourself. You're also responsible for fulfillment, refunds, customer support and calculating and remitting tax. If selling is the point of the site, a headless platform, like Wix, with native commerce removes all of that setup and liability. Do you need to know how to code to move a ChatGPT site to Wix? No, uploading a folder of files is a drag and drop, and if you'd rather not touch it at all, an AI coding agent can do the connection for you from a single prompt. Coding knowledge helps when something breaks, not to get the site live. Does moving to Wix mean rebuilding the site? No. You keep the frontend ChatGPT produced and Wix runs the infrastructure and business tools underneath it. There's no Wix editor in this setup, so design changes still happen in your code or your AI tool of choice.

Your Claude build deserves a real home: get it live on Wix Headless → Claude can put together a working website in roughly the time it takes to describe it. Getting it online is a different job from building a website, and the build doesn't host itself. So the question becomes: I made a site with Claude, now where does it live? Claude gives you a few specific routes out, and the right one depends on what it handed you. Go from Claude build to live site with Wix Headless. Upload or drag in the HTML, CSS and JavaScript files Claude gave you to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: how to host a website you built with Claude To host a site Claude built, first check what you have (an artifact, a folder of code or a Claude Design), then upload clean files, connect from Claude Code or send the design straight to a host. Once it's live, you can keep editing in Claude and republish. You'll learn: What Claude hands you and why an artifact isn't a live site How to prepare Claude's output so it works outside your browser Three ways to get a Claude build onto Wix How to keep editing in Claude once your site is live What Claude gets wrong that breaks a hosted site What Claude actually gives you Claude produces websites in three different shapes and the shape decides your hosting path. An artifact lives on a claude.ai URL. Claude Code writes real files into a folder on your machine. Claude Design produces a design you can send to a host directly. An artifact is great for showing someone an idea but it isn't a website you own. There's no custom domain name, no control over what search engines see, nowhere for a contact form to send anything and no way to edit it outside Claude. That's a different job from what a website builder does and it's worth knowing which one you actually have. To host an artifact you need what sits underneath it. Ask Claude for the HTML, CSS and JavaScript as downloadable files and you're back to an ordinary static site, which is a solved problem. How it actually works: pasting a prompt via wix.com/headless/skill.md into an AI coding tool like Claude Code connects your project to the Wix backend instantly. If you built in a vibe coding platform instead, you start from the Wix Headless page and your project opens with the backend already wired in. The path is fast either way, but which one fits depends on how you're building your frontend. Read more: What is a headless website What is Wix Headless How to sell from a website built in an LLM Can Claude build a website Get your Claude files ready to host Ask Claude for a single HTML file Ask for a single-page site with inline CSS and JavaScript. Fewer files means fewer things that can point at the wrong place once the site leaves your machine. If your design needs several sections, ask for in-page navigation rather than separate pages. Upload your build output, not your source If your project has a build step, upload what the build produces, usually a dist folder. Source files will upload happily and then produce a site that doesn't run, because nothing on the hosting side bundles or compiles them. Know what the upload accepts Your entry file needs to be an HTML file at the top level, named index.html. HTML files buried only inside subfolders aren't accepted. Accepted file types cover markup, styles, scripts, images, fonts and data files like JSON or XML. Video and WebAssembly are rejected. Size limits are 3MB per file and 20MB in total. Uploads deploy static files only, so an Express server, framework API routes or server-rendered templates won't come along for the ride. Good to know: connecting to Wix Headless requires no server setup and no backend code. But you're still building and owning a frontend, which means some familiarity with your chosen AI tool affects how smooth the process is. The connection itself is handled in one prompt. What you build on the frontend once connected is still entirely up to you. Three ways to get a Claude build onto Wix hosting Send a Claude Design straight to Wix Connect the Wix destination once inside Claude Design, under Share and then the Send to tab. After that, Send to Wix publishes the site, generates a wix.config.json file and uploads everything with SSL, CDN and business APIs already configured. A success page gives you the live site, a domain option and a link into your Wix dashboard. Build the design as a single page before you send it. Send to Wix deploys one HTML page, so extra pages are left behind. There's also no Wix editor in this setup by design: you change how the site looks in Claude Design or in the project code, not in a drag-and-drop editor. Learn more: How to host your AI-built site Drag and drop your files If your files came out of Claude Code or you exported them yourself, upload the folder directly and the site goes live on a Wix URL within seconds. Hosting, SSL and the CDN are set up for you. This is the shortest path from a folder on your desktop to a URL you can send someone. Try Wix Headless drag and drop. Connect from Claude Code with one prompt Point Claude Code at the Wix Headless skill file and ask it to connect your project. The agent wires the frontend to the Wix backend without you touching a config by hand. When you want changes live, ask the agent to publish, or run the preview and release commands yourself from the terminal. Itay Shmool, VP, Chairman of Payments, Wix “People using Claude or Cursor to build are moving at a speed that traditional infrastructure just can't match. They'll have a working prototype in an afternoon and then spend weeks trying to bolt on payments. Wix Headless closes that gap. The infrastructure is already there, you're not setting it up, you're connecting to it.” Learn more: can you use Wix without an editor Worth knowing: Wix-managed headless means Wix handles all hosting, CDN, SSL and scaling automatically. Self-managed headless means you host the frontend on your own infrastructure and connect to Wix business data through the API. Both paths connect to the same complete Wix business backend. The choice comes down to how much control you want over your hosting environment, not what backend features you can access. Read more: How to connect Claude Code to a backend Keep editing in Claude after your site is live Sending an updated design from Claude Design refreshes the same live site. That keeps working right up until the moment you publish from a local project or an AI coding agent. After that first publish from your own project, Send to Wix stops updating the live site and starts creating a separate new one instead. To get later Claude Design changes into your project from that point, export the design and hand it to your agent rather than pressing the button again. Content behaves differently from code. Products, bookings, blog posts and form entries you change in the Wix dashboard appear on the live site straight away. You only republish when the design or the code itself changes. Worth being clear on: this is a one-way door worth understanding before you walk through it. Publishing from your own project gives you version control and a real development workflow, and in exchange the Send to Wix button stops being your update path. Most builders want that trade eventually, just not by accident. Read more: How to publish a website: what you need to go live What Claude gets wrong that breaks a hosted site The most common culprit is file paths. A page that references images or scripts by their location on your computer works perfectly in your browser and fails everywhere else. Relative paths fix it and Claude will convert them for you if you ask. The second is anything that quietly expected a server. API routes, server-side rendering and database calls never run on a static deploy, so the page loads and the interactive parts sit there doing nothing. Assets pulled from external sources can fail the same way if that source blocks hotlinking. The third is structural, an entry file that isn't named index.html, or one that sits inside a subfolder instead of at the top level. It's a two-second fix that looks like a catastrophic one. Worth knowing: none of this means Claude built it wrong and a file path that works locally is correct locally. The fix is telling Claude where the site is going to live before you ask for the files, which is one extra line in your prompt rather than a rewrite. Skip the guesswork and upload your files straight to Wix to get a live URL with SSL handled for you. Hosting a Claude website FAQ: Can you host a Claude artifact directly? Not as it stands. An artifact runs on a claude.ai URL, which you don't control and can't point a domain at. To host it properly you need the underlying HTML, CSS and JavaScript, which you can ask Claude to give you as downloadable files. From there it's the same as hosting any static site. Can Send to Wix handle a multi-page Claude design? No, send to Wix deploys a single HTML page, so any extra pages in your design are left behind. Ask Claude for a single-page build with in-page navigation between sections instead. If you genuinely need separate pages, deploy from your project with the CLI rather than the button. Can you keep editing the site in Claude after it's live? Yes, with one caveat. Sending an updated design refreshes the same live site until you publish from a local project or an AI coding agent. After that first publish, Send to Wix creates a separate new site instead, so later changes need to go through your project. What if your Claude site is bigger than the upload limit? The upload caps out at 3MB per file and 20MB total, which large images and video will blow through quickly. Compress your images and host video with a dedicated video service rather than shipping the file itself. If the project is genuinely large, deploy from the command line instead of the upload. Do you need the Wix editor to change a Claude-built site? No and there isn't one in this setup. Design and code changes happen in Claude Design or in your project. Business content like products, bookings and blog posts is managed from the Wix dashboard, which needs no code and no editor.

Make any AI project business-ready in one prompt. Try Wix Headless → The limitations of building a website with a vibe coding platform tend to show up right after the demo stage, once a working prototype has to become a secure, scalable business that takes payments. Vibe coding tools are good at turning a plain-language prompt into a first version fast. The harder part is everything a real business needs behind it, which is where a headless solution can help. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: vibe coding limitations Vibe coding platforms turn prompts into working frontend code quickly, but the code can ship with security gaps and many tools come without their own backend, hosting, payments or bookings. Pairing your frontend with a managed backend covers those gaps while keeping the speed that makes vibe coding useful. You'll learn: What goes wrong with AI-generated code Where design, scaling and SEO hit limits Why business features need extra work How to work around each limitation When vibe coding still makes sense What are the limitations of building a website with a vibe coding platform? These seven limitations show up in nearly every vibe-coded project, and each one gets more expensive to fix the later it's caught: Security gaps and vulnerable code No backend or hosting infrastructure of your own Generic, hard-to-personalize design Scaling and long-term maintenance challenges Limited SEO and technical control No built-in payments, bookings or business tools Vendor lock-in and integration friction The best vibe coding tools turn plain-language prompts into working frontend code, but a meaningful share of that code ships with security gaps, since AI models are not yet reliable at defending against common exploits like cross-site scripting or exposed API keys. Most vibe coding tools have no backend of their own: payments, bookings, a CMS and website hosting still have to be sourced, secured and maintained separately, often by someone with backend engineering skills. Design output tends to look generic, because the AI has no awareness of a specific brand system, component library or design tokens. Scaling, SEO control and long-term maintenance get harder as a project grows, since AI-generated code often ignores existing file structure, conventions and architecture. Vendor lock-in and integration friction are common once a project needs to move beyond a single demo into a maintained, growing product. Wix Headless addresses the backend half of this problem directly, connecting any vibe-coded frontend to Wix's ecommerce platform, bookings, CMS and payments infrastructure in one prompt. Just starting out? Learn the basics: What is vibe coding? What is a vibe coding website builder? How to make a website in a vibe coding platform 01. Security gaps and vulnerable code Vibe coding platforms generate code the same way they generate text: by predicting what comes next, not by reasoning through a threat model. That pattern shows up in the output. Independent security research on AI-generated code has repeatedly flagged meaningful rates of common vulnerabilities, from unvalidated inputs to exposed API keys and weak protection against cross-site scripting, especially in code that was never reviewed by someone who understands application security. "One thing people often overlook when choosing a website builder is the strength of the infrastructure behind it: hosting reliability, built-in security and site performance. These may not be the first things on your mind when building a website, but without a strong foundation, scaling later can quickly become complicated.", Rebecca Tomasis, Head of Organic Growth Marketing at Wix Worth knowing: the security risk depends heavily on which type of tool you're using. Platforms that hand you raw code to host yourself put you in charge of the entire security layer; a hosted AI site builder manages that layer for you by default. For a closer look at where responsibility for these gaps actually sits, see vibe coding security to check if your AI-built website actually safe? 02. No backend or hosting infrastructure of your own Most vibe coding platforms stop at the frontend. They'll hand you clean HTML, CSS and JavaScript, or a live preview, but nothing you build there has a public URL, a database or a way to take a payment until you find somewhere to host it and wire up the rest yourself. This shows up clearly with the most popular AI chat tools: see how to host a website you built with ChatGPT and how to host a website you built with Claude for what's actually involved in taking a vibe-coded frontend live. As far as if Claude can build a website? Here's what it can (and can't) do puts it, website hosting, a live database, online payments and long-term maintenance all sit outside what a chat-based tool does on its own. "People using Claude or Cursor to build are moving at a speed that traditional infrastructure just can't match. They'll have a working prototype in an afternoon and then spend weeks trying to bolt on payments. Wix Headless closes that gap. The infrastructure is already there, you're not setting it up, you're connecting to it.", Itay Shmool, VP, Chairman of Payments, Wix Related reading: Limitations of building a website on ChatGPT 03. Generic, hard-to-personalize design Because a vibe coding tool has no knowledge of your brand guidelines, component library or design tokens, it generates layouts from generic patterns. The result is often technically functional but visually interchangeable with thousands of other AI-generated sites: mismatched buttons, off-scale spacing and unfamiliar UI patterns that need manual cleanup before the site feels distinct. "The hybrid approach is what sets Wix Harmony apart. You can rely on AI for efficiency, letting it handle repetitive or technical tasks, and then jump in with drag-and-drop precision whenever you want to craft something truly unique. It's the best of both worlds in one interface.", Yarin Singolda, Product Marketing Manager at Wix 04. Scaling and long-term maintenance challenges Vibe coding tools tend to optimize for a convincing standalone demo, not for a codebase someone will maintain for years. Exported code frequently ignores existing file structure, testing conventions and build configuration, which is manageable for a five-page site and increasingly costly as a project adds features, contributors or traffic. The bigger and more complex a project gets, the more it still needs a person who understands architecture, security and how to give an AI precise instructions. Compare the tradeoffs directly in vibe coding vs no code: compare cost, speed and flexibility. 05. Limited SEO and technical control A self-hosted, vibe-coded frontend has to handle its own metadata, structured data, sitemaps and semantic markup, and that layer is easy to skip when the priority was getting a working preview on screen. Structured, headless content management, by contrast, is built to stay organized and discoverable as it scales, see what is a headless CMS? for how separating content from presentation supports that. 06. No built-in payments, bookings or business tools This is usually where a vibe-coded project stalls. Checkout, secure payment processing, order management, appointment scheduling: none of it comes standard with a code-generation tool, and building it from scratch is a different job than designing a landing page. What is headless commerce and why are builders choosing it in the AI era? walks through why more builders are pairing AI-generated frontends with an existing commerce backend instead, and how to make an online store with Claude: step-by-step guide shows exactly where that handoff happens in practice. 07. Vendor lock-in and integration friction Code exported from a vibe coding tool is built to stand alone, not to plug into whatever backend, CMS or business systems you already use. That makes migration, integration and hand-off harder than it should be, especially for agencies moving a project between tools or clients. Read more: Can you use Wix without an editor? and how to make a website with Wix's LLM both cover ways to keep your existing frontend workflow while still getting a connected backend underneath it. How to work around vibe coding's limitations None of this means the frontend speed of vibe coding has to be thrown out, it means pairing it with backend infrastructure that already exists instead of building and hosting one from scratch. Wix Headless connects any AI-built frontend to Wix's ecommerce, online bookings, events, CMS and payments layer through an API, so the frontend stays exactly as you built it. The Wix Headless stack that launched a production storefront in one day shows what that looks like end to end. "Wix Headless isn't a website builder with some API access added on top. It's a full business backend with commerce, bookings, events and a CMS that you connect to in one prompt. You build and own the frontend however you want, and Wix runs everything underneath it.", Dor Chaouat, Frontend Developer, Wix When vibe coding still makes sense None of these limitations make vibe coding a bad starting point, they just mark where it stops being enough on its own. For a single landing page, a portfolio or a quick concept to react to and refine, a chat-based tool is genuinely useful, since it skips the blank-page problem entirely. The moment the project needs to take a payment, store real customer data or stay online reliably at scale, it needs the backend half of the equation too, which is where connecting to an existing platform such as through how to use Claude with Wix comes in. Ready to move past vibe coding limitations? Keep the frontend you already built and connect it to a full, already-tested business backend: ecommerce, bookings, events, a CMS and secure payments, all managed for you, with no DevOps required. Start with Wix Headless and ship the business, not just the demo. Vibe coding limitations FAQ: What counts as "limitations" when it comes to vibe coding a website? A limitation is anything the platform can't fully hand off to you without a developer stepping in, things like custom backend logic, complex data structures, fine-grained performance tuning or non-standard integrations. Most vibe coding tools are built to get a working site or app live fast, not to handle every edge case a growing business runs into. That gap is normal, not a dealbreaker, it just changes what "done" looks like. Can a vibe-coded website scale as traffic grows? It depends on what's running underneath the generated code. Some platforms output a proper, hostable codebase that scales like any other app, while others lock you into their own runtime with limited control over performance or infrastructure. If scale matters, check what the platform generates and whether you can host, cache and optimize it independently before you build on it. Related reads: How much does Wix Headless cost Does vibe coding replace the need for a developer entirely? No, it shifts where a developer's time goes rather than removing the need for one. Vibe coding handles the repetitive, boilerplate parts of building a site, but debugging generated code, security reviews and complex custom features still benefit from someone who can read and modify the underlying code. Teams that treat it as an accelerator, not a replacement, tend to get the best results. Is content management harder on a vibe-coded site? It can be, since many vibe coding platforms weren't built with a structured CMS in mind. If your site needs a non-technical team member to update pages, blog posts or product listings regularly, check whether the platform supports real content modeling, otherwise every content change routes back through code. Some teams solve this with a drag and drop deploy setup, which keeps the backend developer-managed while non-technical teammates still edit content freely. Related read: Do I need a CMS for my website? How do vibe coding limitations compare to a headless setup? A headless approach separates your content and backend from the frontend, which gives you more control over performance, integrations and how content gets delivered across channels. Vibe coding optimizes for speed of building the frontend itself, so it's solving a different problem, the two aren't direct substitutes, but a vibe-coded frontend can sit on top of a headless backend if you need both speed and flexibility. Related read: Headless CMS vs traditional CMS What are the signs it's time to move beyond a vibe coding platform? Recurring signs include needing custom integrations the platform doesn't support, hitting performance ceilings under real traffic, or spending more time working around the tool than building with it. At that point, exporting to a real codebase or moving to a more flexible architecture is usually less work than continuing to patch around the limitation. Related read: LLM website building limitations

Drag your finished site files in and get a live URL in seconds. Try Wix Headless → You made a website. Maybe you coded it yourself, used an AI tool to create it or downloaded the files from another platform. Now you have a folder of website files, but how do you actually get that website online? You need to put those files somewhere that can make them available on the internet. This is called website hosting. To get your site online, you can take the technical route, using tools such as SFTP or Git, or choose a hosting platform that lets you upload your finished website files directly and takes care of the deployment for you. Go from files to a live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live on a Wix URL, with SSL and a global CDN included. You can add ecommerce, bookings, a CMS, payments and more with a single prompt. TL;DR: how to upload a website Uploading a website means getting the right files or project onto a service that can make your site available online. The easiest method depends on how your site was created and whether you have finished files or a project that still needs to be built. You'll learn: What website files you need and whether they're ready to upload How uploading, publishing and deploying differ Which hosting and upload method to use, including File Manager, SFTP and Git How to upload websites created with AI tools How to upload finished website files to Wix Headless How to connect your domain and troubleshoot common issues How to test and update your live website What does it mean to upload a website? A website is made up of files that work together to create the pages people see. The main types are: HTML creates the structure of a page CSS controls how the page looks JavaScript adds interactive behavior Images, fonts and other files provide the content the site needs When those files are only on your computer, the website is not available for other people to visit. You need to put a copy of the files on a web server, which is a computer connected to the internet that can deliver your website to visitors. Uploading a website means transferring your website files from your computer to a web server through a hosting service. Once the files are uploaded to the right location, the server can send them to a visitor's browser when they open your website address. Upload vs. publish vs. deploy You'll see these three words throughout website tutorials. They can sound like different versions of the same thing, and sometimes they are. Upload means transferring your website files from your computer to your hosting service so the site can be accessed online. Depending on the service, you might upload the files through a File Manager, SFTP or another method. Publish means making a website or your latest changes available for visitors. The term is especially common with a website builder, where you make changes to your site and click "Publish" to put those changes live. Unlike uploading, you don't usually handle the website files yourself. Deploy means taking a website or application and making it live on a server. Uploading files can be one step in deployment, but deployment can also include building the site, setting up its configuration and making sure everything is ready to run. The term is common with coded websites and applications, especially when using Git or automated tools. For a simple website, uploading the files can effectively be the same step as putting the site live. For a more advanced project, there can be several steps between writing the code and making the finished site available to visitors. You don't need to understand all of those differences to upload your first website. Start by finding out what files you have and what your hosting service supports. What website files do you need to upload? Before you upload a website, first check what you actually have. The files you receive from an AI tool or coding tool can be very different, and the right upload method depends on them. If you have finished website files If your folder contains files such as index.html, CSS, JavaScript and images, you likely have a finished website that can be uploaded directly to hosting that supports this type of site. A ZIP file containing these files works too. Many hosting services let you upload the ZIP and extract it on the server. If you have a code project If you see files such as package.json, a src folder or other project files, you may have the files used to create the website rather than the finished website itself. These projects often need to be built first, which turns the code into the files that can be uploaded and served to visitors. Don't upload the whole project folder yet. Check the instructions for the AI tool or coding tool you used to find out how to build the project and where it puts the finished files. The resulting folder may contain files such as index.html, CSS, JavaScript and images that are ready to upload. Does your website need server-side features? Some websites need more than HTML, CSS, JavaScript and images. If your site has features such as user accounts, saved customer information, a database, online payments or code that runs on the server, you'll need hosting that supports those features. These are often called server-side or backend features because part of the website runs on the server rather than in the visitor's browser. Uploading a folder of website files to basic static hosting won't provide a database or run that server-side code. If you're not sure, check the instructions for the tool or coding project that created your site. It should tell you what your website needs to run. What you need before you upload a website Before you upload your website, make sure you have the files that make up the site, a place to host them and a way to transfer them to the server. You may also need a domain name if you want people to visit the site at a custom web address. 01. Your website files This might be a folder on your computer, a ZIP file or the finished files produced by an AI or coding tool. Make sure you have every part the site depends on, including images, CSS, JavaScript and fonts. 02. Web hosting Hosting is the service that keeps your website files available on the internet. Some hosting services are designed for simple websites, while others support applications, databases, server-side code and other requirements. Managed cloud hosting takes care of the underlying servers for you, so you don't have to manage the hardware yourself. The hosting service you choose also affects how you upload your website. For example, many shared hosting plans include a control panel with a File Manager, while other services may have you upload files with SFTP, connect a Git repository or use the provider's own deployment tools. If you are weighing up the options, cloud hosting vs shared hosting is the comparison worth reading first. Read more: What is web hosting? How to host a website Web hosting cost How to publish a website 03. A domain name A domain is the web address people use to visit your site, such as yourbusiness.com. Domain registration is a separate purchase from hosting. You don't always need a domain before uploading your site. Many hosting services give you a temporary web address that you can use for testing. 04. A way to upload the files Depending on your hosting service, you may upload your website using one of these methods: A File Manager in your browser SFTP FTP Git The platform's own upload or deployment tool For a first upload, a File Manager is often the simplest option if your hosting provider offers one. Good to know: You don't need to choose an upload method before you choose your hosting. The options available depend on your hosting service, and you can choose the one that fits your site and how you plan to manage it. You can also connect a domain later. Learn more about Wix headless CMS and what is headless commerce Which upload method should you use? The right method depends on what you have, what your hosting service supports and how often you plan to update your site. For a finished website that does not need a complicated development setup, a direct upload is usually the simplest route. File Manager is the simplest option for a first upload. It lets you select files and folders in your browser and upload them directly to your hosting account, so you don't need to install or learn another program. The drawback is that uploading large sites or frequent updates can become tedious because files usually have to be selected and uploaded manually. SFTP is useful when you need more control over your files. It uses a file transfer program to securely move files between your computer and the server, which can make regular updates easier. The tradeoff is that you need to install a program and enter your server connection details, so it has more setup than a browser-based upload. FTP works in a similar way to SFTP but does not encrypt the connection. It can still be found on older hosting services, but SFTP is generally the better choice when both are available. For a new site, there is little reason to choose traditional FTP over a secure alternative. Git is designed for websites that are managed as code projects. Instead of treating the site as a folder of files, Git keeps track of changes to the project and can work with a deployment process that sends those changes to your hosting. This is useful for developers and teams, but it adds concepts and setup that most people don't need for a simple finished site. Automated deployment removes much of the manual uploading. Once it is set up, a change to your code can trigger a process that builds the site and sends the updated version to your hosting automatically. This saves time for sites that change often, but setting up the workflow can be more work than manually uploading a small site. Some hosting platforms let you upload finished website files directly. This can be a useful middle ground when you have a site created with a coding or AI tool but don't want to configure SFTP, Git or a deployment pipeline. For example, Wix Headless lets you upload or drag in finished website files and handles the deployment to a live URL, so you can go from a completed site folder to a live site without setting up a separate server workflow. Method Best for How it works File Manager Simple websites and first-time uploads Upload files through your browser SFTP Secure file transfers Transfer files securely between your computer and the server FTP Older hosting setups Transfer files between your computer and the server Git Coded websites and development projects Connect a code repository and deploy changes Automated deployment Sites updated through code Automatically sends new site changes to hosting when you update your project Platform upload tool Hosting platforms with their own workflow, like Wix Headless Upload or deploy files using the platform's tools Drag your finished site files into Wix Headless and Wix handles the hosting, SSL and CDN for you. How to upload a website with a File Manager A File Manager is usually the easiest way to upload a simple website because you can do everything from your browser. 01. Log in to your hosting account Open the dashboard or control panel provided by your hosting company. Look for an option related to your website files. 02. Open the File Manager The tool might be called File Manager, Files, Website Files or something similar. The name depends on your hosting provider. 03. Find the folder for your website Your hosting account has a specific folder where your website files need to go. This is sometimes called the document root or web root. On many hosting setups, the main website uses a folder called public_html. Other hosts may use a different name, so check your hosting provider's instructions if you're not sure. 04. Upload your website files Upload the files and folders that make up your website. For a simple site, you might have something like this: index.html css/ js/ images/ Keep the folder structure the same as it is on your computer. If your HTML expects an image at images/logo.png, for example, the images folder needs to be in the correct location on the server too. 05. Upload a ZIP if you have many files If your site contains a lot of files, you don't need to upload every file separately. Many hosting File Managers let you upload one ZIP file and extract it on the server. After extracting it, check the folder structure carefully. A ZIP might contain a top-level folder, which can leave your site one level deeper than expected. For example, you might end up with: public_html/ my-website/ index.html css/ images/ when you actually need: public_html/ index.html css/ images/ If index.html is inside an extra folder, your domain may not show the site you expect. 06. Open your website Visit the temporary URL provided by your hosting service, or your domain if you've already connected it. Check the homepage, images, navigation and other pages. If something looks wrong, the upload may still have worked correctly. A missing CSS file, image or JavaScript file is often caused by a file path or folder structure that doesn't match the original site. Where should index.html go? For many simple websites, the homepage file is named index.html. It needs to be in the folder your hosting service uses as the website's root folder. For example: public_html/ index.html css/ js/ images/ If you put it here instead: public_html/ my-site/ index.html your website may not load at your domain's main address because the homepage is one folder too deep. Not every website uses index.html, so don't rename files automatically if your project uses another setup. Frameworks and some hosting systems have their own rules. Good to know: On many hosting setups, index.html is the default file shown when someone visits the site's root address. File names can be case-sensitive, so Index.html and index.html may be treated as different files. How to upload a website with SFTP SFTP is another way to transfer website files from your computer to your hosting account. Instead of using a browser-based File Manager, you use an SFTP program to connect to your hosting account and transfer files directly. You'll usually need: The server or host address Your username A password or SSH key A port number The connection details provided by your hosting service Your hosting provider should give you these details and tell you which connection settings to use. Once you connect, you'll normally see your computer's files alongside the files on the server. Find your website's root folder and upload your website files there, keeping the same folder structure. SFTP is useful when you have many files to transfer or need to update your site regularly. It also encrypts the connection, which makes it a safer choice than traditional FTP when both options are available. FTP vs. SFTP FTP and SFTP both transfer files between your computer and a server, but they use different types of connections. FTP does not encrypt the connection. SFTP runs over SSH and encrypts the connection. If your hosting provider supports both, SFTP is generally the better choice because the connection is protected. You don't need to use SFTP if your host's File Manager already does everything you need. It's simply another way to transfer files, and it can be more convenient when you manage files regularly. Good to know: An SFTP client usually shows your computer's files on one side and the server's files on the other. The tricky part is knowing which folder on the server is the one your host uses for your website. Find that folder first, and transferring the files is straightforward. How to upload a website with Git Git is a tool for keeping track of changes to a project. If your website already lives in a Git repository, you may not need to manually upload files every time you make a change. Some hosting and deployment services can connect to your repository and automatically deploy the latest version of your site. A typical workflow looks like this: Put your website project in a Git repository. Connect the repository to your hosting or deployment service. Choose the branch and any required build settings. Deploy the site. Connect your domain. After that, updating the site can be as simple as making a change, committing it and pushing it to the repository. The connected service can then detect the change and deploy the updated version. This is useful if you're developing the site regularly. For a small website that you update only occasionally, manually uploading files may be simpler. Worth knowing: Git takes more setup than a simple file upload, but that setup can save time when you update your site often. Once everything is connected, you can update the site without manually selecting and transferring the files each time. Skip the deployment setup completely. Upload your build output to Wix Headless and your site goes live on a Wix URL in seconds. How to upload a website created with an AI tool AI tools can create websites in different ways. Some give you a ready-to-publish site, some give you finished website files and others give you a code project that needs to be built first. What you do next depends on which one you have. 01. The AI tool gives you a live website If the AI tool gives you a website that is already hosted, you don't need to upload the files yourself. Use the tool's publishing settings and connect a domain if you want a custom web address. If you create your site with the Wix Website Builder, the site is already hosted on Wix. You can make changes in the editor and click Publish when you're ready to make them live. 02. The AI tool gives you finished website files If you receive a folder or ZIP containing a finished website, you can upload those files to a hosting service that supports them. This is the simplest case because the website is already built and ready to run. Wix Headless lets you upload or drag in finished website files and deploy them to a live Wix URL. This can be useful if an AI or coding tool created the files but you don't want to set up a separate server or Git workflow. 03. The AI tool gives you a code project If you receive a project with files such as package.json and src/, you may have the source code rather than the finished website. The project may need to be built first, which creates the files that can be put online. The project may also require server-side code, a database or other services. In that case, you'll need a hosting setup that supports those requirements. Wix Headless can work with coded websites, but the exact setup depends on the project and what it needs to run. If the project can be built into finished website files, those files can be uploaded through the Headless workflow. Projects that require server-side features need the appropriate Wix or external services as part of the setup. Paste wix.com/headless/skill.md into Claude Code, Cursor or any AI tool you already use and your project is connected to the full Wix backend instantly. Expert tip from Yoav Cohen, Head of Education for DevRel at Wix: “We're seeing an entirely new kind of builder emerge, people who are highly capable with AI tools, move extremely fast, and have real product vision, but don't want to become infrastructure engineers. Wix Headless was built for them.” How to upload a static website to Wix Headless If you have a finished static website, Wix Headless lets you upload it directly and have Wix host it. This is useful if you created a site with code or an AI tool and have the finished website files but don't want to set up hosting separately. Wix hosts the files on a global CDN with automatic SSL and gives the project access to Wix business APIs. 01. Get the finished website files Make sure you have the finished build output, not the development project. Wix serves the files as they are and does not build them for you. If your project needs server-side code, use the CLI deployment route instead of the static upload. 02. Upload the files Go to the Wix Headless upload page and drag in your build output, or select a folder or ZIP file.Wix creates a new Headless project, hosts the files and publishes the site to a Wix URL. 03. Check the live site Open the URL provided after the upload and test the pages, images, links, navigation and interactive features. 04. Keep developing if you need to The upload is a starting point, not a dead end. After setting up the uploaded project locally, you can keep developing it and deploy updates with the Wix CLI. You can also connect the frontend to Wix services such as the CMS, ecommerce, bookings, events and memberships. If you need a build process or server-side code, use the CLI route instead. Wix Headless can host and run supported existing frontends through that workflow. Good to know: Wix Headless is free to start. Paid plans unlock features such as custom domains and live payments, so you can start building and testing before committing to a paid plan. Do you need a domain and hosting? They do different jobs, and domain hosting vs web hosting covers the distinction in full. Your domain is the web address people use to find your website. Your hosting is where the website files are stored and served to visitors. You can upload a website without having a custom domain. Your hosting provider may give you a temporary web address that you can use to test the site, then connect your own domain later. How to connect your domain to your website Uploading your website and connecting your domain are separate steps. Uploading puts your files on the hosting service, while connecting your domain tells the internet where your website is hosted. If your domain and hosting are with the same provider, you can often connect them from the provider's dashboard. If they're with different providers, your hosting service will give you the DNS settings to add where your domain is registered. Tip: Test your site using the temporary hosting URL first. If the site works there but not on your domain, your website files are probably fine and the issue is with the domain connection. Why isn't my uploaded website showing? If your site doesn't look right after uploading, don't start over immediately. Most problems are caused by one of a few things. 01. You see a blank page Check that your homepage is in the correct website root folder. If you're using a simple static site, check that index.html is there. Then check that your CSS and JavaScript files are in the locations your HTML expects. 02. You see a 404 error A 404 means the server couldn't find the page you requested. Check these. The URL The page's file name The folder structure The website root folder That the page was actually uploaded If the homepage works but another page doesn't, check the path to that specific page. 03. The page loads but the design is broken Your HTML may have uploaded correctly while your CSS or JavaScript did not. Check the paths in your HTML and make sure the corresponding files are on the server. File names can also cause problems. On many servers, style.css and Style.css are treated as different files. 04. Your images aren't loading Check that the image files were uploaded and that their paths match the paths used in your HTML or CSS. For example, if your page refers to this image. then the server needs to have logo.png inside an images folder in the expected location. 05. You uploaded a ZIP and the site doesn't work Check where the ZIP was extracted. You may have accidentally created an extra folder inside your website root. website/ index.html If the site expects index.html directly in the root, move the files up one level. 06. Your domain still shows an old site The domain may still point to your previous hosting service, or DNS changes may not have finished updating. You may also be seeing a cached version of the site. First, open the temporary URL from your hosting service. If the new site works there, the upload itself is probably fine and the issue is more likely related to the domain or DNS. How it actually works: almost every problem on this list traces back to a path that does not match or a file that landed one folder off. Keeping your local folder structure and your server folder structure identical removes a whole category of problem before it happens. How to check that your website is really live Don't stop at seeing the homepage. Go through the site as a visitor would, and check that everything below works. The homepage loads Other pages open Images and videos appear Fonts and styling look correct Navigation and links work Buttons do what they should Forms work Downloads work The site looks good on a phone Your domain opens the correct site HTTPS is working It's also useful to open the site in a private browsing window. That reduces the chance that an old cached version is confusing your test. If HTTPS is not working, check that a free SSL certificate is active on your domain. How to update your website after uploading it You don't usually need to start the entire upload process again every time you change something. How you update the site depends on how you originally put it online. With a File Manager, edit your files and upload the changed files. With SFTP, replace the changed files on the server. With Git, make your changes, commit them and push them to your repository. Your hosting service can then deploy the new version if it is set up for automatic deployment. With a website builder, make your changes in the builder and publish again. For a small site that changes occasionally, manually replacing files is perfectly reasonable. If you're making changes every week, a Git-based or automated workflow can save time because you don't have to keep track of which files need to be uploaded. How to upload a website FAQ: Can I upload a website without hosting? Your website needs somewhere to be served from, so you need a hosting service or a platform that provides hosting. You don't necessarily need to buy traditional hosting separately. Some platforms combine the upload, hosting and publishing steps. Can I upload a website without a domain? Yes. You can often upload and test a website using a temporary URL provided by your hosting service. You can connect a custom domain later. Do I need FTP to upload a website? No. You can often use a hosting File Manager, SFTP, Git or another upload method instead. Some hosting providers still support FTP, and when both FTP and SFTP are available, SFTP is generally preferable because the connection is encrypted. Can I upload a ZIP file instead of individual files? Usually, yes. Many hosting File Managers let you upload a ZIP and extract it on the server. After extracting it, check the folder structure to make sure your homepage and other website files aren't hidden inside an extra folder. How long does it take for an uploaded website to go live? The files can often be available as soon as they're uploaded to the correct location. If you've also connected a new domain, the domain connection can take longer because DNS changes need time to update. Can I upload a website created by an AI tool? Yes, if the AI tool gives you website files that can be hosted by the service you're using. If you receive finished HTML, CSS, JavaScript and assets, you may be able to upload them directly. If you receive a development project that needs to be built first, follow the project's build and deployment instructions instead. Can I upload a website to Wix? Yes. Wix Headless supports uploading a finished static site and hosting it as a Wix-managed Headless project. You can upload a folder or ZIP of the finished build output, and Wix handles hosting, SSL and CDN delivery for that site. For a project that needs a build process or server-side code, Wix also provides a CLI-based deployment path for supported frameworks.

Make any AI project business-ready in one prompt. Try Wix Headless → The limitations of LLMs when building a website show up quickly. Tools like ChatGPT and Claude can take you from a blank prompt to a working homepage in minutes, with clean-looking pages and decent copy, without touching code. What you won't get on your own is the backend that turns a page into a business, plus the hosting and upkeep that keep an AI website running. A headless solution can fill that gap while you keep the frontend you built. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: limitations of LLMs when building a website LLMs are good at producing a working page fast, but on their own they stop at the frontend, so the parts that make a site a business are left for you to add. Planning for those gaps early saves rework once you start growing the site. You'll learn: Why LLMs can't give you a real backend for payments, bookings or content Where visual and layout control breaks down Why bigger, more complex sites get less reliable output What's missing on site security, hosting and scale How context and usage limits cut builds short What happens after launch, when you still need to host and maintain the site 7 limitations of building a website with an LLM Here's where LLM-built sites tend to fall short, and what each one means for your project: No built-in backend for payments, bookings or content Limited control over visual design and layout Less reliable output as your site gets more complex No production-grade security, hosting or scalability Context and usage limits cut builds short No easy way to host or hand off what you built No dashboard for managing the site after launch 01. No built-in backend for payments, bookings or content An LLM can write you a homepage, a pricing page and a contact form, but none of that is a business on its own. The moment you want to accept payments online, update copy or schedule appointments online without asking your AI tool to regenerate a whole file, you've hit the edge of what the model can do. That's backend work, and it's a different problem than writing HTML. “The hardest part of shipping something real has never been the frontend. Anyone can build a beautiful UI fast now. The wall people hit is always the same: payments, bookings, a CMS that actually works,” says Ran Levi, Developer Advocate at Wix. Wix Headless connects the frontend your LLM built to that same infrastructure in one prompt, so you're not the one building a database from scratch. If you're not sure what that setup actually looks like, what is a headless CMS breaks down the concept in plain terms. 02. Limited control over visual design and layout LLMs are trained on text, not pixels. Ask one to describe a layout and it can only work in words, which makes fine visual judgment, spacing, hierarchy and how sections should feel next to each other, hard to communicate. You'll often get a page that reads well but looks generic, or one where the polish only holds up on a single screen size. Complex interactions like animated transitions, custom illustrations or a layout with real visual asymmetry usually need more back and forth than a single prompt allows. You end up either accepting a simpler design or hand-coding the details yourself, which erases some of the speed you started with. 03. Less reliable output as your site gets more complex A single landing page is a manageable ask. A multi-page site with a working nav, consistent styling across every template and shared components is a much bigger one, and that's where LLM output tends to get shakier. Generate all the code for a full site at once and there's a real chance parts of it won't work together, or won't work at all. The fix most builders land on is breaking the project into small, specific prompts and testing each piece before moving to the next. That works, but it also means you're doing a lot of the integration and debugging yourself instead of the model doing it for you. Related read: Headless CMS vs traditional CMS, how the two setups actually differ for someone building solo. 04. No production-grade security, hosting or scalability Code an LLM hands you still needs somewhere to live, and that somewhere needs SSL, uptime monitoring, protection against traffic spikes and a plan for scale. None of that comes bundled with the generated code. You're responsible for finding website hosting, configuring it and keeping it patched. “People using Claude or Cursor to build are moving at a speed that traditional infrastructure just can't match. They'll have a working prototype in an afternoon and then spend weeks trying to bolt on payments,” says Itay Shmool, VP and Chairman of Payments at Wix. That gap between a fast build and dependable infrastructure is exactly what closes the case for weighing the pros and cons of a headless CMS before you launch. Need a domain name? Check if the name you want is available using Wix's domain name search. 05. Context and usage limits cut builds short Every LLM conversation runs inside a limited context window, and generating a lot of code, CSS or SVG icons eats through that budget fast. Push a build far enough and the model starts forgetting earlier decisions or truncating output mid-file. Most tools also cap how many prompts you get in a stretch of time, which throttles momentum on a big build. For anyone on a paid Claude or ChatGPT plan, hitting a usage cap mid-session is a common complaint during heavy building days. It's rarely a dealbreaker for a first draft, but it does mean the LLM's do-it-all-in-one-go promise has a ceiling. Related read: What is headless commerce, what changes when the thing you're selling needs real commerce infrastructure behind it. 06. No easy way to host or hand off what you built Once your LLM finishes generating a site, you're holding a folder of files, not a live URL. Getting from there to something visitors can actually reach means picking a host, connecting a domain and setting up deployment, none of which the model handles for you. Wix Headless's drag and drop deploy tool covers that last step, so you're not the one wiring up a server from scratch. “The thing that costs agencies the most isn't building the site, it's everything that comes after. Maintaining plugins, managing integrations, being the permanent help desk because the client can't figure out the backend,” says Moran Shemesh, from Wix's Engineering team. Posts like how to host a website you built with ChatGPT and how to host a website you built with Claude walk through what that step actually looks like. 07. No dashboard for managing the site after launch The LLM that built your site isn't going to be the tool you use to update it every week. Once it's live, you need somewhere to swap out product photos, publish a blog post or edit a price, ideally without opening the code again. Most raw LLM output doesn't come with any kind of editing dashboard. This is usually the point where people ask can ChatGPT build a website they can actually run day to day, or check if they need a CMS for their website to figure out what's missing. A connected CMS is what turns a generated page into something a non-technical teammate can maintain. Learn more about building past an LLM's limits: Can Claude build a website How to sell from a website built in an LLM How to launch your AI project's frontend and backend How much does Wix Headless cost How to make a website with Claude Design How to add an online store to an AI-built site How to make a Wix Headless website None of this means an LLM isn't worth using to start a site. It means the fastest path from prototype to something people can actually buy from usually needs a second piece connected to the first. As Dor Chaouat, Frontend Developer at Wix, puts it: “You build and own the frontend however you want, and Wix runs everything underneath it.” If your LLM already built the frontend you want, connect it to Wix Headless and get the backend, payments and CMS most builds are missing, with no rebuild required. Limitations of building a website with an LLM FAQ: Can an LLM build a fully functional website on its own? An LLM can generate the code and copy for a working page, but a fully functional site usually means more than that. Payments, bookings, a content management system and reliable hosting all sit outside what a text-based model produces on its own. You'll typically need to connect the frontend it builds to a separate backend service to call the project complete. Is a website built with an LLM safe to launch? Not usually without some extra steps. Security basics like SSL, data handling and protection against traffic spikes aren't things a generated codebase comes with automatically. Before launch, it's worth confirming hosting, security and backups are handled, either yourself or through a service built to manage them. Keep reading: How to launch your AI project's frontend and backend How to host an AI built site Can you use Wix without an editor What is a headless CMS Why does ChatGPT or Claude struggle with bigger website builds? Bigger builds mean more code, more files and more decisions to keep consistent, and that runs up against the model's context window. Past a certain point, the model starts losing track of earlier choices or generating pieces that don't line up with the rest of the site. Breaking the build into smaller, specific prompts usually produces steadier results. Do I still need a developer if I use an LLM to build my site? For a simple one-page site, often not. For anything with payments, user accounts, a booking system or multiple templates that need to stay consistent, some technical work is still involved, even if it's mostly connecting existing services instead of writing everything from scratch. Tools built for this handoff cut down how much of that work falls on you.

Make any AI project business-ready in one prompt. Try Wix Headless→ Claude Design turns a prompt into a working web page you can shape on a canvas, and the result is real HTML rather than a mockup. Getting that page online and ready for customers is a separate step, and it's the part that trips people up. This guide walks through the full process in six steps, ending with a headless solution that hosts it. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: how to make a website with Claude Design To make a website with Claude Design, describe the site, refine it with chat and canvas edits, add your brand and content, then send it to Wix to publish it on hosting. To take orders or bookings, a coding agent then connects the page to business tools. You'll learn: What Claude Design is and isn't How to build the site in six steps What happens after the first publish How Wix runs a Claude Design site What Claude Design is and what it isn't Claude Design is a conversational design workspace, not a website builder. It has a chat panel on the left and a canvas on the right. You describe what you want, Claude generates a working design on the canvas, and you refine it from there. What lands on that canvas is real HTML and CSS rather than a picture of a layout, which is exactly why Wix can host it directly. It is in beta on the Claude Pro, Max, Team and Enterprise plans, and it runs on the web at claude.ai/design or from the sidebar in the Claude desktop app. On Enterprise plans the capability is off by default, so an admin has to switch it on first. There is no separate Claude Design allowance to track, since design activity draws from the same usage pool as the rest of your plan. What it does not give you is hosting, a domain or a Wix editing experience. Sending a design to Wix creates a Wix-managed headless setup, which means Wix hosts the page you designed and runs the business tools behind it, and you keep changing the design in Claude Design or in code. The Wix Editor and Wix Studio are not part of this route. If editing visually on the Wix side matters to you, the built-in Wix connector is the route that gives you that, and it's worth reading how to make a website with Claude before you commit to a path. Way to build What it gives you Where it goes Who it's for Chat artifact An HTML file inside a conversation You download and host it yourself A quick one-off page Claude Code Code in your own repository You deploy it yourself People who want to own the code Claude Design A designed HTML page Send to Wix, hosted headless, no Wix editor Design-led single-page sites Wix connector in Claude A real Wix site Opens in Wix Harmony, Wix's AI website builder, fully editable People who want to keep editing on Wix Worth being clear on: Wix Headless gives you a complete business backend, and the frontend stays yours to build and own. On the Claude Design route that means your design lives in Claude Design or in your project's code. If you don't have a frontend yet, that is what Claude Design is for, and the handoff to Wix is a button rather than a migration. Read more: Can Claude build a website? How to use Claude with Wix How to make a website with Claude and Wix How to launch your AI project's frontend and backend How to build your Claude Design site in 6 steps You need three things before you start. A paid Claude plan, a Wix account and your content ready to go, meaning the copy for each section plus the images you want to use. Describe the site you want in Claude Design Refine the design with chat, comments and canvas edits Add your brand and real content Add Wix as a destination, one time only Send to Wix and open the live site Finish setup so the site can use business tools What you do What you get 01. Describe the site you want in Claude Design A working first draft on the canvas 02. Refine it with chat, comments and canvas edits A layout that matches your brand 03. Bring in your real copy and images A page that looks like your business, not a template 04. Add Wix as a destination, one time only Send to Wix in your Share menu 05. Hit Send to Wix A live site on Wix hosting with SSL and a CDN 06. Connect the project, set up auth and wire in the business tools A page that can read and write real Wix business data 01. Describe the site you want in Claude Design Write the prompt like a brief. A good one names the goal, the layout, the content and the audience. Claude will ask clarifying questions if something is missing, but starting specific saves a round trip. Ask for one page with in-page navigation between sections. Send to Wix deploys a single HTML page, so anything past the first page of a multi-page design does not come along. A prompt like "a single-page site for a Brooklyn ceramics studio with a hero, a class schedule, a gallery and a booking section, warm neutral palette, in-page nav" gets you much closer than "a nice pottery website." Taylor Ott, a real estate investor with no coding background, started the same way. "I really wanted a video animation as my landing page and I just couldn't figure out the best way to do that. So I sat down with Claude and described what I was trying to build." This surprises most new users, there is no time limit, no credit card required and no sandbox mode on the Wix side. You connect your frontend to the full Wix backend at zero cost, build everything out and test every flow before spending anything. A paid plan is what unlocks live payments, a custom domain, advanced analytics and some other advanced features. Most builders get further than they expect before the upgrade decision comes up. 02. Refine the design with chat, comments and canvas edits Three tools do three different jobs. Use chat for structural changes like rearranging sections or changing the whole color direction. Use inline comments to click a specific element and request a targeted fix, which is faster than describing where something is. Edit directly on the canvas to drag, resize and align things when you just want a quick visual adjustment. If you are unsure about a direction, ask for two or three alternative layouts and compare them instead of guessing. You can also ask Claude to review the design for accessibility, contrast and information hierarchy, which is worth doing once before you publish. One thing worth knowing: inline comments occasionally don't register before Claude reads them. If a comment seems to have been ignored, paste the same feedback into the chat instead. It is a known beta issue with a one-second workaround, not something you need to debug. 03. Add your brand and real content Claude Design builds with a design system, which is the set of colors, typography and components your work should follow. On Team or Enterprise plans, projects use your organization's design system automatically once someone has set one up. Working solo, you bring one in from design files or raw uploads, and the output only gets as good as what you give it. A messy or incomplete source shows up in the result. You can attach reference material at any point. Screenshots of designs you like, existing assets, a slide deck with a style you want matched. This is the step where the site stops looking like generic AI output and starts looking like your business. 04. Add Wix as a destination, one time only You do this once per Claude environment, not once per project. Open Export at the top right, go to the Send to tab, choose Add a destination and pick Wix. After that, Send to Wix is waiting in the same menu for every design you make from then on. 05. Send to Wix and open the live site Hit Send to Wix and your site publishes. Wix creates a wix.config.json file, uploads and hosts your files, and configures SSL and a CDN, and makes the Wix business APIs available to the project. When it finishes, an Open in Wix link appears in the Claude Design chat. That link takes you to a success page where you can visit the live site, connect a custom domain, open your Wix dashboard or start the setup in step 06. Your site is genuinely live at this point. It is not finished. 06. Finish setup so the site can use business tools To complete setup you need the project on your machine, including the generated wix.config.json file that connects your frontend to the Wix APIs, and you need to configure authentication. Wix hosts and runs your site, and it does not handle authentication for you, so you create a Wix client and set that up the same way any self-managed headless project would. If you are not a developer, hand this to an AI coding agent. Telling Claude Code to set up the local project and authentication for your new Wix Headless project is enough to get through it. Authentication is the first half. Each business solution you want live on the page, whether that's Stores, Bookings or the CMS, then has to be wired into your design. Wix gives you a ready-made prompt for it, so expect at least one more round with the agent before the page is reading and writing real data. Taylor took that route too. "Having an AI agent tell me step by step what to do has been really smooth. I showed people my website and they were pretty impressed." Explore more: How a real estate investor built a Wix Headless site without writing a single line of code What happens to your Claude Design site after the first publish Where you make a change depends on what kind of change it is. Design changes go back through Claude Design or into your project's code. Business content, meaning products, booking services, blog posts, forms and members, goes through the Wix dashboard with no code. Dashboard changes appear on the live site on their own, and only design or code changes need a republish. There's more on the hosting side of this in how to host a website you built with Claude. The part worth planning around is what happens the first time you publish from outside Claude Design. Until then, sending an updated design from Claude Design updates the same live site. Once the site has been published from the CLI or an AI coding agent, that link is cut and Send to Wix starts creating separate new sites instead. How it actually works: this is a one-way door, so pick a side early. If Claude Design is going to stay your design tool, keep publishing from Claude Design and let an agent handle only the initial setup. If you expect to iterate in code, publish from the CLI early and treat Claude Design as the starting point rather than the ongoing editor. Getting changes back into the local project after that means exporting the design and handing it to your agent. Expert tip from Tuvit Rubin Kaplan, Head of DevRel at Wix: "Frontend creation became easy almost overnight. But running a business still requires real infrastructure. Wix Headless is where those two things meet." Discover more: The limitations of LLMs when building a website The Wix Headless stack that launched a production storefront in one day How Wix runs a Claude Design site Wix Headless is the business backend sitting behind your design, running on the same infrastructure as the main website builder. It natively includes a CMS, ecommerce, bookings, events and payments in one connected setup, managed from a single Wix Business Manager dashboard, so there is nothing to assemble from separate vendors. Your design owns the experience and Wix runs everything underneath it. If the architecture itself is new to you, start with what is a headless website. The infrastructure you would otherwise build yourself. Your site runs on multi-cloud website hosting and a global CDN across more than 200 servers, with 99.99% uptime, auto-scaling, managed SSL and DNS handled for you. Wix Headless runs on enterprise-grade infrastructure designed to support real businesses at scale, and there is no DevOps work on your side. Business tools your design can call. Turn on an ecommerce website, online scheduling, events, the headless CMS or a blog from the dashboard, then ask your coding agent to wire the matching interface into your page. Orders, inventory, shipping and finances are handled from one place, and payments, checkout and automated sales taxes come with it. For the commerce side specifically, headless commerce covers how the pieces fit together. SEO stays your job on this route. Wix's built-in SEO support, meaning managed meta tags, structured data and an auto-maintained sitemap, comes with the Astro integration rather than with an imported frontend like a Claude Design build. Your page ships with whatever markup Claude wrote for it, so ask for a proper title, a meta description and a sensible heading structure while you are still designing. A domain and a clear upgrade path. Buy or connect a domain name from the dashboard and Wix handles SSL and DNS. Connecting is free and you pay the same prices as any other Wix user, with no developer pricing and no API fees, so the cost starts when you are ready to sell. Learn more: How much does Wix Headless cost Worth knowing: Wix-managed headless means Wix handles all hosting, CDN, SSL and scaling automatically. Self-managed headless means you host the frontend on your own infrastructure and connect to Wix business data via API. Both paths connect to the same complete Wix business backend. The choice comes down to how much control you want over your hosting environment, not what backend features you can access. Expert tip from Dor Chaouat, Frontend Developer at Wix: "Wix Headless isn't a website builder with some API access added on top. It's a full business backend with commerce, bookings, events and a CMS that you connect to in one prompt. You build and own the frontend however you want, and Wix runs everything underneath it." Making a website with Claude Design FAQ: Can Claude Design build a website on its own? It can design one, but it cannot put it online by itself. Claude Design produces the page, and the hosting and business tools behind it come from wherever you send that design. Sending it to Wix publishes the page on Wix hosting and gives the project access to Wix business solutions. Wiring your design's features into those solutions takes one more step with a coding agent, and you add a custom domain separately when you want one. On its own, what you have is a finished design rather than a working website. Do you need to know how to code to use Claude Design? No. Designing the site and sending it to Wix involve no code at all, and running products, bookings and content from the Wix dashboard is fully visual. The one step that touches code is connecting the local project and setting up authentication, and an AI coding agent handles it from a ready-made prompt, though expect a round or two of back and forth. Can you make a multi-page website in Claude Design? You can design one, but Send to Wix deploys a single HTML page, so the extra pages will not transfer. Build one page with in-page navigation between sections and ask for exactly that in your prompt. If you truly need separate routes, add them in the local project after the first publish or start from an AI coding agent instead. What's the difference between Claude Design and the Wix connector in Claude? Claude Design is a design workspace, and what it hands Wix is a page that Wix hosts headless with no Wix editor attached. The built-in Wix connector creates an actual Wix site that opens in Wix Harmony, where you get the full editor and Wix's own AI agent. Pick Claude Design when the design is the point and one page is enough. Pick the connector when you want to keep editing on Wix afterwards. Is Claude Design free? No. It is included with the Claude Pro, Max, Team and Enterprise plans rather than sold separately, and design work draws from the same usage limits as everything else on your plan. On the Wix side, connecting and hosting your design costs nothing, and you upgrade to a Premium plan when you want live payments, a custom domain or other advanced features.

Make any AI project business-ready in one prompt. Try Wix Headless→ Backend as a service (BaaS) is a cloud model that gives your app a ready-made backend, so you connect to authentication, databases, file storage and server-side logic instead of building and running them yourself. Scope varies by provider, from a data and login layer at one end to a full business backend with payments, bookings and a CMS at the other, such as a headless solution. This guide covers what a BaaS includes, how it works and when it fits. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: backend as a service BaaS gives a small team prebuilt backend features through an SDK or API, so it can ship without managing servers. In exchange for faster shipping, you accept less low-level control and possible lock-in, so it suits teams that value speed over custom infrastructure. You'll learn: What a BaaS includes How backend as a service works How BaaS compares with PaaS, IaaS and serverless Benefits and trade-offs When to use a BaaS What is BaaS? BaaS stands for backend as a service, a cloud computing model where a provider runs the server side of your app and exposes it to you through APIs and SDKs. The provider runs the backend services and the infrastructure under them. You still define your data model, your permissions and your product logic. You will see both names used interchangeably in developer docs and on pricing pages. The category grew out of a simple observation. Most apps need the same handful of backend capabilities, and almost none of them win customers by building those capabilities better than anyone else. Worth knowing: BaaS describes a model, not a single product shape. Some providers sell one bundled backend, others sell separate managed pieces that teams assemble into something BaaS-shaped. When you compare options, compare the capabilities you actually need rather than the label on the box. Aspect What it means What it is A cloud model that delivers ready-made backend services behind an SDK or API What it covers Authentication, databases, file storage, real-time sync, push notifications and serverless functions What you still own The frontend, your product logic and your access rules Main upside Ship without building or running backend infrastructure Main trade-off Less low-level control and possible lock-in as you scale What sits inside a BaaS A BaaS typically bundles authentication, a managed database, file storage, real-time data sync, push notifications and serverless functions for custom logic. Those six pieces cover the backend work that almost every web and mobile app repeats. Instead of standing up a user table, hashing passwords, wiring token expiry and then doing the same again for file uploads, you call an SDK method and move on. A booking app, for example, needs accounts, stored appointments, uploaded profile photos and a reminder that fires at the right time. All four arrive as configuration rather than code. Bundles differ in scope. Wix Headless is a headless solution that natively includes CMS, ecommerce, Bookings, Events and Payments in a single connected backend without requiring third-party integrations. Backends built for app developers tend to stop at data and auth, so a business-focused bundle covers more of what a real product ends up needing, from a headless CMS for structured content through to headless commerce for selling. BaaS vs. mBaaS: what's the difference? mBaaS is a backend as a service built specifically for mobile apps, and the difference is scope rather than model. The core offering is the same. Where mBaaS adds value is in the mobile-specific extras like offline data caching, device push notification handling and native SDKs for iOS and Android. A field service app that has to keep working in a basement with no signal needs offline sync. A web dashboard does not, so a general BaaS is usually the better fit there. Learn more: What is a headless website Headless CMS vs traditional CMS Headless CMS pros and cons Do I need a CMS for my website How does backend as a service work? A BaaS works by putting a managed service layer between your frontend and the infrastructure that actually stores and processes data. Your app talks to that layer. The layer handles everything below it, which is a useful way to think about frontend infrastructure more generally. The client SDK or API layer Managed data and authentication Serverless functions for custom logic Scaling and monitoring on the provider side 01. The client SDK or API layer The client connects to a BaaS through an SDK or API rather than communicating with infrastructure directly. The provider ships libraries for common frontend environments, and each one wraps the same underlying endpoints. You call a method like signIn or query, and the SDK handles the request, the auth token and the response shape. The practical effect is that adding user login stops being a backend project and becomes a few lines in the component that renders the form. Learn more: How to connect Claude Code to a backend service 02. Managed data and authentication Data and authentication are stored and enforced by the provider, and you control them through rules rather than through server code. You define collections or tables, then write access rules that say who can read and write what. The provider enforces those rules on every request, which means your security model lives in configuration instead of in middleware you have to maintain. A rule that limits a document to its owner replaces an entire authorization layer. It also means a mistake in that rule is exposed everywhere at once, so rules deserve the same review you would give production code. 03. Serverless functions for custom logic Serverless functions handle the logic that does not fit into simple data reads and writes. They run on the provider's infrastructure, trigger on events like an HTTP request or a database change and shut down when they finish. Anything you would have put in a controller, from payment webhooks to scheduled cleanup jobs, goes here. Sending a confirmation email after an order is written is a typical case. The database write fires the event, the function runs and nothing stays online between orders. The same pattern handles the webhook that fires when you take payments online. 04. Scaling and monitoring on the provider side Scaling, uptime monitoring and patching belong to the provider, not to you. Capacity moves with demand, and the operational work that usually needs an on-call rotation is absorbed into the service. For small teams this is often the deciding factor, because a backend that has to stay up around the clock is hard to staff. Providers differ in how visible this is. Wix Headless provides automatic scaling without any manual intervention or setup. Others expose quotas and concurrency limits you need to watch, so check where the ceilings sit before you plan around them. One thing worth knowing: serverless functions are the part of a BaaS that quietly grows. They start as small pieces of glue and, on a busy product, end up holding real business logic. That is workable, but it is worth treating those functions as code you own and version rather than as configuration you can forget about. BaaS vs other cloud models Cloud service models differ in one thing, which is how much of the stack you still run yourself. BaaS sits near the top of that ladder, where you own the least. Model You manage The provider manages Best fit BaaS Frontend and product logic Auth, data, storage and scaling Frontend-heavy teams shipping fast PaaS Your application code Runtime, OS and servers Teams writing their own backend IaaS OS, runtime and application Virtual hardware Teams that need deep control FaaS Individual functions Everything under the function Event-driven and scheduled tasks BaaS vs. PaaS BaaS vs. IaaS BaaS vs. serverless computing BaaS vs. FaaS 01. BaaS vs. PaaS PaaS, or platform as a service, gives you a managed place to run backend code you write yourself, while BaaS gives you backend functionality you do not write at all. With PaaS you still design the data model, build the API and handle authorization. The platform removes the servers, the operating system and the deployment plumbing. BaaS removes the application layer too, which is why it offers less flexibility and more built-in functionality. A team with backend engineers and an unusual data model usually prefers PaaS. A frontend-heavy team shipping a standard app usually prefers BaaS. 02. BaaS vs. IaaS IaaS, or infrastructure as a service, rents you raw compute, storage and networking, so almost everything above the virtual machine stays your responsibility. You choose the operating system, install the runtime, configure networking and patch all of it. That level of control matters when compliance dictates your architecture or when performance tuning is part of the product itself. The gap in effort is large. A BaaS project can be handling real users the same week it starts. An IaaS project of the same size is often still building its deployment pipeline, which is why managed cloud hosting sits between the two as a middle option. 03. BaaS vs. serverless computing Serverless computing is a broader umbrella that BaaS sits inside, not a competing model. Serverless describes any setup where you do not provision or manage servers and capacity follows demand. A BaaS meets that description for the services it provides. Products differ in the quotas and rate limits they apply, and serverless services have their own concurrency limits too. So the useful question is not which one to pick. It is which parts of your stack you want someone else to operate. 04. BaaS vs. FaaS FaaS, or function as a service, runs a single piece of code in response to an event, while BaaS gives you an assembled backend. Most BaaS platforms include FaaS as a feature, so the two are often used together rather than chosen between. The distinction starts to matter when teams try to build an entire backend out of functions alone. Functions are a good fit for background jobs, webhooks and scheduled tasks. They are a poor fit for logic that needs shared state or transactions across several calls, because you end up rebuilding a service with harder tools. Worth knowing: these labels overlap more in practice than they do in diagrams. Plenty of teams assemble a managed database, a managed auth service and a deploy target and call the result a BaaS, so judge a setup by who operates each piece rather than by the acronym. Benefits and trade-offs of backend as a service The case for BaaS is speed and reduced operational load. The case against it tends to show up later, usually at scale or at the edges of what the provider supports. Benefits of using a BaaS The main benefit of a BaaS is that you ship a working product in the time it would normally take to build the backend for one. The gains stack up across the whole project rather than landing in a single place. Faster development: Auth, data and storage arrive working, so the first usable version of the product exists in days rather than sprints. Less backend boilerplate: The repetitive code that every app needs and no user ever notices is already written and tested. Lower infrastructure and ops burden: Provisioning, patching and uptime move to the provider. Wix Headless eliminates the need for backend engineering, server management or DevOps work. Built-in scaling: Capacity follows demand without a capacity plan or an on-call rotation behind it. Easier access to common backend capabilities: Real-time sync, file handling and push notifications become configuration rather than projects of their own. Expert tip from Ran Levi, Developer Advocate at Wix: “The hardest part of shipping something real has never been the frontend. Anyone can build a beautiful UI fast now. The wall people hit is always the same: payments, bookings, a CMS that actually works. Wix Headless knocks that wall down. You connect your frontend to the infrastructure millions of businesses already run on, in one prompt. You're not a backend engineer, you're just shipping.” Trade-offs to plan for The trade-offs of a BaaS are mostly about control, and they get more expensive to fix the later you meet them. None of them are reasons to avoid the model, but all of them are worth pricing in before you build. Vendor lock-in: Your data model, auth and access rules take the provider's shape, so moving later means rewriting more than the database layer. Costs at scale: Usage-based pricing is cheap when traffic is small and unpredictable when it is not. Limits on customization: You work inside the provider's model. Unusual requirements either bend to fit or need a separate service running alongside. Complex and relational query constraints: Some BaaS products limit complex joins, aggregation or relational query patterns depending on the database and API model underneath. Pricing models vary widely on the second point. Wix Headless is free to connect. There is no upfront cost to wire a frontend to the Wix backend, which keeps the cost of early exploration at zero and moves the spending decision to the moment you start selling. One thing worth knowing: none of these trade-offs apply evenly across providers. Lock-in on a platform built around open standards looks very different from lock-in on a proprietary one, and query limits depend entirely on the database underneath. Weigh each trade-off against the specific provider you are considering rather than against the category as a whole. Explore more: Best headless CMS Limitations of building a website with a vibe coding platform The limitations of LLMs when building a website How to upload a website When to use backend as a service The decision rests on one question, which is how much of your product's value lives in the backend. If the answer is very little, a BaaS is almost always the faster path. When a BaaS tends to fit A BaaS fits best when your team's strength is the frontend and your backend needs are standard. The pattern below shows up in most projects that succeed with the model. Your team is frontend-heavy. Authentication, data and storage are necessary but not differentiators. Speed to market matters more than infrastructure control. Traffic may fluctuate. You do not want a dedicated backend or DevOps team. Rafal is a good example of the pattern. He is a developer who launched a production storefront in one day on Wix Headless, scaffolding the whole thing by the end of day one. “It feels like I don't have any backend to test. I rely a lot on the SDK which makes development a lot smoother.” Since launch his store has processed $25,000 in gross payment volume, logged more than 217,000 API calls and grown sales by roughly 30% month over month, on running costs of about $50 a month. Reliability is the thing worth checking before you commit to any of this, because a managed backend is only as good as the infrastructure under it. Wix Headless runs on enterprise-grade infrastructure designed to support real businesses at scale. The same applies if you build website with AI and need somewhere dependable for it to run. When to consider another approach Another approach makes more sense when the backend is where your product competes or where your constraints are strict. Any one of these is usually enough to change the answer. Your data model requires highly complex relational queries. You need deep infrastructure control. Compliance requires particular deployment architectures. Backend logic itself is your competitive differentiator. Provider-specific pricing becomes unfavorable at your expected scale. None of these rule out managed services completely. They usually point toward running your own backend for the part that matters and using managed services for everything that does not. Worth knowing: choosing a BaaS is not a permanent architectural decision, but it is an expensive one to reverse if you never think about it again. Teams that do well with the model keep their business logic separated from provider-specific calls from the start, which makes a future move a refactor rather than a rebuild. Find out more: What is Wix Headless How much does Wix Headless cost Can you use Wix without an editor How to launch your AI project's frontend and backend Wix Headless vs Shopify Headless Commerce How Wix Headless works as your business backend Wix Headless is a headless solution that lets AI builders, vibe coders and agencies connect any frontend to a full native business backend including payments, bookings, events, CMS and ecommerce without building or managing infrastructure. That puts it in BaaS territory with a different emphasis. Where most managed backends stop at data and auth, this one starts at the point where a project has to behave like a business. The difference shows up the first time a prototype needs to take money. Accounts and a database get you a working app. Checkout, scheduling, ticketing and a content model are what turn it into something people can pay for, and those are the pieces teams usually discover they have to assemble themselves. It runs on the same platform behind the free website builder millions of businesses already use, and it connects just as well to a project started in a vibe coding website builder. Expert tip from Dor Chaouat, Frontend Developer at Wix: “Wix Headless isn't a website builder with some API access added on top. It's a full business backend with commerce, bookings, events and a CMS that you connect to in one prompt. You build and own the frontend however you want, and Wix runs everything underneath it.” How you connect depends on how your frontend is built and where it is hosted. The path generally runs through these five steps. 01. Build or bring your frontend. Start from scratch on the Wix Headless page and describe what you want, or connect a project you already built in an AI coding tool or a vibe coding platform. 02. Connect it to the Wix backend. A single prompt wires your project to the business layer. There is no server setup and no backend code to write at this step. 03. Turn on the capabilities you need. Add ecommerce, bookings, events, a CMS or payments depending on what the product does, all managed from one Wix Business Manager dashboard. Turning a solution on in the dashboard does not build its frontend for you, so ask your AI tool to add the matching pages once it is live. 04. Choose how you host. Let Wix handle hosting, CDN, SSL and scaling, or host the frontend on your own infrastructure and call Wix through its APIs. 05. Upgrade when you are ready to sell. Connecting is free. A Premium plan is what unlocks live payments, a custom domain and in-depth analytics. Either hosting route answers the same practical question, which is how to host an AI-built site once the prototype is finished and real people need to reach it. Worth knowing: Wix-managed headless means Wix handles all hosting, CDN, SSL and scaling automatically. Self-managed headless means you host the frontend on your own infrastructure and connect to Wix business data via API. Both paths connect to the same complete Wix business backend. The choice is about how much control you want over your hosting environment, not about which backend features you can access. Once the backend is connected, the last question is usually commercial rather than technical, which is how to sell from a website built in an LLM or any other AI tool without rebuilding what you already have. Backend as a service FAQ: Is BaaS the same as serverless computing? Not quite. Serverless is the broader infrastructure and execution model, and BaaS is one way of delivering backend capabilities on top of it. The two overlap, so a BaaS is usually serverless in the sense that you never provision a server. Treat BaaS as a product category rather than a synonym. Do you need to know how to code to use a BaaS? Yes, though less of it than you might expect. You still build a frontend, which means writing or generating code and understanding how your app calls the backend. What you skip is server-side development, database administration and infrastructure work. Anyone comfortable with an AI coding tool or a modern frontend framework can usually get a BaaS project running. Can you migrate off a BaaS later? You can, and how hard it is depends on how you built. Exporting data is usually the easy part. The real work sits in the auth model, the access rules and any provider-specific SDK calls scattered through your frontend. Teams that keep business logic separated from provider calls from day one find migration far less painful. Is a BaaS secure enough for a real business? A BaaS can absolutely run production applications, though security works as a shared responsibility. The provider handles password hashing, token management, encryption and patching on the platform itself. What stays yours is access rules, application logic, credentials and anything your compliance requirements demand. Misconfigured access rules are a more common source of problems than the platform itself. How much does a BaaS cost? Pricing is usually tied to usage rather than seats, so you pay by reads, writes, storage, function invocations or active users. Most providers offer a free tier that covers development and early testing. Costs become worth modeling once traffic grows, because a usage-based bill rises with success rather than with team size. Does BaaS work for web apps or only mobile apps? Both. The model started with mobile, which is where the mBaaS label came from, but general BaaS platforms now serve web, mobile and desktop clients through the same APIs. Mobile-specific features like offline sync and device push handling are the main things a mobile-focused product should check for before choosing.

Make any AI project business-ready in one prompt. Try Wix Headless → You can add an online store to an AI-built site without rebuilding it, by connecting the design you already have to a system that handles selling. That's the job an online store builder does end to end, and a headless solution can do it behind a custom design without backend engineering, server management or DevOps work. Below are the options and how to pick one. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: adding an online store to an AI-built site An online store is four systems: a product catalog, a cart, checkout and everything that happens after the sale. You can embed a buy button, use a CMS plugin, connect a payment processor or plug in a headless commerce backend, depending on how much of that you want handled. You'll learn: What adding a store actually involves Why an AI-built frontend still needs a commerce backend Four ways to add a store How to pick the right approach What to check before your first order What adding a store to an AI-built site actually involves Most people picture a button. You drop in a cart icon, point it at a payment link and you are selling. That works for one product and stops working almost immediately after that. Piece of the store What it does Hardest part to get right on your own Product catalog Holds products, prices, images, variants and stock levels Variants and inventory that stay accurate everywhere they appear Cart Lets shoppers collect items and keeps them between sessions Holding the cart reliably across a refresh, a new tab or a switch to mobile Checkout and payments Takes the money and confirms the order Failed payments, refunds, fraud checks and the payment methods people expect Orders, inventory and tax Runs everything that happens after the sale Sales tax rules, shipping rates, fulfillment status and stock going out of sync 01. The catalog layer The catalog is the part everyone underestimates. It holds every product with its price, images, description, stock count and any variants like size or color. On an AI-built site that product data usually lives wherever the AI generated it, which is often hardcoded straight into the page. Moving it somewhere you can update without editing code is the first real step. 02. The cart and checkout layer An online shopping cart holds what a shopper picked and has to survive a refresh, a new tab and a switch from phone to laptop. Checkout is where the money moves, and it carries the most rules by far. Card validation, saved payment methods, address collection, currency handling and what happens when a payment fails all live in this layer. It looks like the simplest part from the outside and has the most edge cases inside. 03. What happens after the sale Once an order lands you need somewhere to see it, mark it fulfilled and pull stock out of inventory. Refunds and chargebacks need a path. Sales tax needs to be calculated for the buyer location and reported somewhere. Shipping rates need to match what you actually charge. None of this is visible on the site, which is exactly why it gets skipped until the first order arrives. This is exactly what a commerce backend is for. Wix Headless centralizes business logic, data and permissions in a single Wix Business Manager dashboard. One thing worth knowing: if your catalog includes variants across more than two or three attributes such as size, color and material, plan for extra setup time to structure those correctly. Most catalogs are live in a few hours. Variant-heavy ones are closer to a day. Learn more: What is a headless website Frontend infrastructure for beginners Do I need a CMS for my website Why an AI-built frontend still needs a commerce backend The frontend is what a visitor sees. The commerce backend is everything that remembers, calculates and settles. AI coding tools and vibe coding platforms have become very good at the first one, and so has every AI generated website that comes out of them. Ask for a product grid, a cart drawer and a checkout page and you will get all three, looking right, in minutes. What you get is the interface, not the system behind it. A generated checkout page can collect a card number without being a payment processor. It can show a total without knowing the sales tax rules where your buyer lives. It can confirm an order without recording it anywhere you can act on later. That gap is where most AI-built projects stall. The build was fast, the launch is not, and the missing piece is never the design. Closing that gap does not mean giving up the part you built. Wix Headless lets builders own and control their frontend, built on any AI tool or code stack, while Wix handles the backend. Expert tip from Guy Ofeck, API Infrastructure at Wix: "The question we kept hearing from AI builders was: 'I've built something great, now how do I accept payments?' Wix Headless is the answer to that question. Payments, secure checkout, order management, it's already built and battle-tested. You just connect." Good to know: connecting to Wix Headless requires no server setup and no backend code. But you are still building and owning a frontend, which means some familiarity with your chosen AI tool or framework affects how smooth the process is. The connection itself is handled in one prompt. What you build on the frontend once connected is still entirely up to you. Read more: The limitations of LLMs when building a website Vibe coding limitations How to launch your AI project's frontend and backend Four ways to add an online store to a site you already built Four routes cover almost every case, and they look much the same on a hand-coded site as they do on anything made with a website builder. They differ less in difficulty than in how much of the system you end up owning. Approach Best for What you get Main limitation Embed a cart or buy button Selling one or a few products A basic cart and a hosted purchase flow Small catalog and little control over the buying experience CMS plugin Sites already running on a content management system Commerce built into the admin you already use Tied to that system and its update cycle Payment processor Custom payment flows you want to design yourself Payments only, you build the rest Catalog, orders, inventory and tax stay your job Headless commerce backend An existing custom or AI-built frontend you want to keep Catalog, checkout, orders, inventory and business management Needs an integration step before it runs Embed a cart or buy button Use a plugin if the site runs on a CMS Connect a payment processor directly Plug in a headless commerce backend 01. Embed a cart or buy button An embedded cart is a snippet you paste into your page. The products, the payment and the order records live with the provider and your site just renders their widget. Setup is the fastest of the four and you can be taking payments the same day. The tradeoff is that the buying experience belongs to the provider, and your catalog is limited to what the widget supports. 02. Use a plugin if the site runs on a CMS If your site sits on a content management system, a commerce plugin is usually the path of least resistance. Products, checkout and orders all land inside the admin you already log into, the same way a full ecommerce platform keeps them together. This route only applies if your AI-built site was generated onto a CMS rather than as standalone code, so check that before you plan around it. 03. Connect a payment processor directly Connecting a payment processor to your own code gives you complete control over the checkout. It is also the option most often mistaken for a finished store. A payment processor moves money. It does not give you a product catalog, a stock count, an order dashboard, a fulfillment status or a place to issue refunds from. You build and maintain those yourself, along with any sales tax obligations that apply where you sell. 04. Plug in a headless commerce backend Headless commerce splits the system in two. Your frontend stays exactly as it is and a backend runs products, cart, checkout, payments, orders and inventory behind it, reached through APIs. Wix Headless can be connected to an existing AI-built frontend using a single prompt. For a site you already built and like, this is the route that adds the missing system without asking you to rebuild the part that already works. Embedded carts hand you a checkout but not a catalog. CMS plugins give you both but only if your site runs on a CMS. Payment processors move the money and leave the store to you. A headless commerce backend is the one route that covers the catalog, the checkout and the order records in a single connection. Worth being clear on: Wix Headless gives you a complete business backend with ecommerce, bookings, events, a CMS and payments, all natively connected. The frontend is yours to build and own, but if you do not have one yet, Wix Headless gives you the tools to create one too. Describe what you want on the Wix Headless page and it opens in your chosen vibe coding platform with the backend already wired in, or use wix.com/headless/skill.md with any AI coding tool to build and connect in one step. Explore more: What is a headless CMS Headless CMS vs traditional CMS What is abandoned cart recovery How to pick the right approach for your setup The right route depends on four things. Work through them in order and the answer is usually obvious by the third. Catalog size: if you are selling one or two products, an embedded button is enough. Anything with variants, categories or stock that changes regularly needs a real catalog. Where the site lives: if it was generated onto a content management system, check that system first. If it is standalone code, plugins are not an option. Who maintains it: if nobody on your side wants to own payment logic, refunds and tax rules, pick a route where someone else already does. What you want to keep: if the frontend is the reason the project exists, do not choose anything that asks you to rebuild it. Cost belongs on the same list. Embedded widgets and plugins usually charge per transaction or per month. Payment processors charge per transaction and leave the rest to you. Wix Headless uses the same pricing model as any other Wix user, with no developer pricing or API fees. For an AI-built site where you want to keep the frontend and need a full commerce system behind it, a headless commerce backend is usually the closest fit. It is the only one of the four that covers the catalog, the checkout and the order records without asking you to assemble them from separate services. This surprises most new users: there is no time limit, no credit card required and no sandbox mode. You connect your frontend to the full Wix backend at zero cost, build everything out and test every flow before spending anything. The only things that require a paid plan are accepting live payments, connecting a custom domain and accessing advanced analytics. Most builders get further than they expect before the upgrade decision comes up. How to add an online store to an AI-built site with Wix Headless Wix Headless is a headless solution that lets AI builders, vibe coders and agencies connect any frontend to a full native business backend including payments, bookings, events, CMS and ecommerce without building or managing infrastructure. In practice that means your site keeps its design and its code, and the store runs underneath it. 01. Connect your existing frontend to Wix Headless How you connect depends on how you build. If you work in an AI coding tool, pointing it at the Wix Headless skill wires your project to the backend in one step. If you would rather do it by hand, the JavaScript SDK and the REST API let you call Wix business APIs from any framework while you keep control of configuration, authentication and hosting. 02. Add Wix Stores, products and payments Products go into the Wix dashboard rather than into your code. You add items, prices, images, variants and stock levels, and your frontend reads them through the API. On the money side, Wix Headless ecommerce includes secure payments, optimized checkouts and automated sales taxes. Once orders start arriving they land in the same place, since Wix Headless ecommerce enables managing orders, inventory, shipping and finances from one dashboard. Expert tip from Ran Levi, Developer Advocate at Wix: "The hardest part of shipping something real has never been the frontend. Anyone can build a beautiful UI fast now. The wall people hit is always the same: payments, bookings, a CMS that actually works. Wix Headless knocks that wall down. You connect your frontend to the infrastructure millions of businesses already run on, in one prompt. You're not a backend engineer, you're just shipping." 03. Keep building in the AI tool or framework you already use Nothing has to move into a Wix editor. Wix Headless allows AI builders to keep using their preferred tools and workflows without rebuilding inside a Wix editor. You keep prompting, committing and deploying the way you already do, and the backend keeps serving the same data underneath. 04. Choose your hosting setup and go live Hosting is a real decision here rather than a formality. If you want the infrastructure handled for you, managed online store hosting covers the CDN, the SSL certificate and the scaling. If you already have a deployment setup you like, you can host the frontend yourself and call Wix business data through the API. Once that is settled, connect a domain, turn on payments and take your first order. Worth knowing: Wix-managed headless means Wix handles all hosting, CDN, SSL and scaling automatically. Self-managed headless means you host the frontend on your own infrastructure and connect to Wix business data via API. Both paths connect to the same complete Wix business backend. The choice depends on how much control you want over your hosting environment, not on which backend features you can reach. Find out more: How much does Wix Headless cost Can you use Wix without an editor How to create a website from scratch Best headless commerce platforms compared What to check before you take your first order Run a real transaction end to end before you announce anything. Buy something from your own site with a live card, then refund it. That single pass catches payment account verification problems, missing confirmation emails and a checkout that breaks on a phone. Check the money settings next. Sales tax needs to be configured for the places you sell into, shipping rates need to match what you actually charge and your payout account needs to be verified before anything reaches you. Then check the quiet things. Stock counts should move when an order goes through. Order notifications should reach a mailbox someone actually reads. Analytics should be recording sessions and purchases so you can tell later which pages are doing the work. Worth knowing: the first order is usually the one that surfaces the gaps, so it helps to make that order your own. A test purchase on a live card tells you more in five minutes than a checklist does in an hour, and refunding it afterward tests the other half of the flow. Discover more: How to sell from a website built in an LLM How to host an AI-built site How to upload a website and make it live Wix Headless vs Shopify Headless Commerce Online store on an AI-built site FAQ: Can I add a store to a website I built with AI without rebuilding it? Yes, in most cases. If your site is standalone code, connecting a commerce backend through an API leaves the frontend untouched. If it was generated onto a content management system, a commerce plugin does the same job inside that system. A rebuild is usually unnecessary as long as your frontend can call external APIs and render the data it gets back. Do I need to code to add a cart and checkout? Not for the simplest routes. An embedded cart or a buy button is a paste-in snippet, and a commerce plugin is a few clicks inside an admin panel. Connecting a headless backend to a custom frontend does involve code, though an AI coding tool can do most of that work from a prompt. The more control you want over the buying experience, the more code is involved. What is the cheapest way to add an online store to an existing site? Embedded carts and buy buttons tend to have the lowest upfront cost, while plugins, payment processors and headless backends mix subscription and per-transaction pricing in different ways. Pricing varies by provider, so compare the two numbers that matter, what you pay monthly and what you pay per order. At low order volume the per-transaction options usually win and at higher volume a flat plan usually does. Can I sell digital and physical products from the same site? Yes. Most commerce systems handle both, though the two behave differently after checkout. Physical products need shipping rates, stock counts and fulfillment status. Digital products need secure delivery of the file or the access, and they are taxed differently in many places. Check that the route you pick supports both before you build around it. Who handles sales tax when I sell from an AI-built site? That depends entirely on the route. If you connect a payment processor directly, tax calculation, collection and reporting are your responsibility everywhere you have an obligation. If you use a commerce platform, tax is usually calculated automatically at checkout based on the buyer location, though registration and filing normally stay with you. Confirm which parts are automated before your first sale, because fixing tax after the fact is much harder than setting it up. How long does it take to add a store to a site that already exists? It varies by approach far more than by site. An embedded button or a plugin can be live the same day. Connecting a headless backend to a custom frontend is usually a matter of hours for the connection itself and longer for catalog setup, product photography and testing. Variant-heavy catalogs and anything involving shipping rules take the longest, and that part is the same on any platform.

Make any AI project business-ready in one prompt. Try Wix Headless Building a custom website doesn't have to mean building everything from scratch. With Wix Headless, you can create a frontend that looks and works exactly the way you want while Wix runs the backend that powers it. I'm Ran, Wix's Global Developer Advocate, and I've made many Headless sites with AI tools designing the frontend. If you're a business owner, an entrepreneur or just curious about how this works in practice, this is the fastest way to find out. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: how to build a Wix Headless website To build a Wix Headless website, give an AI coding assistant a prompt pointing to Wix's skill.md file, and it scaffolds the site and connects it to the Wix Headless CMS, payments and forms. Testing is free, and you need a Premium plan only to accept payments. You'll learn: What headless means How to write the first prompt How to build, customize and test the site How to finalize and launch it How to upload a site you already built with AI Back to basics: what is Headless? Imagine a power drill. It has the body, where the motor resides and the drill bit attached to the front. If every drill came with a fixed, single-size drill bit, that would be pretty inconvenient, wouldn’t it? If you wanted to drill a hole of a different size, you’d have to take apart or replace the entire drill. That’s why drills come with detachable bits, allowing you to change the head to suit your needs (without modifying the drill’s body). Headless works the same way for both websites and web apps. The drill’s “body” is the website’s backend: the payment system, the databases, the form-processing logic and the Content Management System (CMS), basically all the hidden machinery needed to power an ecommerce website. The head is the website’s frontend, the part users see and interact with: buttons, headers, images, forms, checkout carts and the like. And just like in our drill analogy, Wix Headless allows you to create an infinite variety of frontends and connect them to the same backend, taking advantage of Wix’s rich ecosystem of business solutions and third-party apps. But why would you do that? After all, Wix already offers a great solution for frontend design: Wix’s drag-and-drop Editor, which connects seamlessly and automatically to the Wix backend. Building websites used to be hard work. You needed a professional developer or designer just to get something polished online. Wix changed that with its editor, which made it possible for even on-technical people to build a great site. Today, AI coding assistants have leveled the playing field even further with tools like Claude Code, OpenAI’s Codex, Cursor and similar platforms. But “can” doesn’t always mean “should.” Letting an AI assistant generate a button or submission form isn’t the same as asking it to build a full, end-to-end payment system, a database or a CMS. Those backend systems are much more complex to design and build because they must meet demanding requirements: reliability, security, regulatory compliance and performance under load. Asking an AI agent to write a complete backend infrastructure is like asking your handy neighbor, the one who fixes his Honda on weekends, to build a Formula 1 engine for a race. It might turn on, but you’re far more likely to end up in the ditch. A smarter approach is to let the AI assistant design the frontend portion of your website, which is lighter and less risky and connect that frontend to Wix’s existing backend infrastructure. Thousands of engineers have spent nearly two decades ensuring that exact infrastructure can handle whatever demands millions of ecommerce websites throw at it. You’ll sleep much better at night knowing that critical machinery is handled by battle-tested professionals. The bottom line: let the AI assistant build the frontend, and connect it to the Wix backend. That way, you get the best of both worlds, a website tailored to your business’s exact needs, running on a reliable and finely tuned backend infrastructure. New to Wix Headless? Start here: Can you use Wix without an editor? What is a headless website? What is headless commerce? How much does Wix Headless cost? Wix Headless gives you access to the full Wix business stack through a single connected backend: stores, bookings, events, a CMS and payments, all managed from one Wix Business Manager dashboard. There’s no separate charge per feature, no API fees and no enterprise tier to unlock. Connect for free today. You can build and test for free. You only need a Premium plan when you're ready to accept payments and take your site live. You get Wix's backend without being locked into a Wix-designed frontend. That means you can build the experience you want while using Wix for products, content, forms and member data. Learn more: Frontend infrastructure for beginners Do I need a CMS for my website? Let’s build a Wix Headless website together In this guide, we’ll work with an AI assistant to create a custom website, then connect that frontend to several Wix business solutions. Our AI assistant will do most of the heavy lifting, but we’ll take a look “under the hood” to understand what it’s doing so you can make better decisions as you build. Everything we cover here is completely free to try (no credit card required), so fire up your computer, create a project folder, open your preferred AI coding tool and follow along. You’ll only need a paid Premium account if you decide to launch your website and start accepting live payments. For this demo, I’m creating “Ran’s Wacky Portraits,” an online store selling funny caricatures of some of my Wix colleagues! The store will include a product catalog, a payment integration, submission forms, a members area, a CMS and a blog, basically everything a small business needs to start selling right away. First prompt Building the website Customizing and testing the site Finalizing the website 01. First prompt Head over to the Wix Headless site, where you’ll find the following prompt: build a [Your website’s description] using https://wix.com/headless/skill.md This prompt consists of two parts. The second part tells our AI assistant where to find a file called skill.md, which contains all the instructions the agent needs to communicate with Wix’s backend services. The first part, in brackets, is where we define how we want our website to look and behave. Building a website is an iterative process, so you’ll have plenty of opportunities to refine things along the way. However, a clear initial description helps point the AI assistant in the right direction from the start. For my store, I described the basic premise: a store selling funny portraits and listed key features like a product catalog and a members area. For the design portion, I took a shortcut. Since my design skills leave a bit to be desired, I browsed the web for existing AI-generated sites and looked for the exact prompts used to build them. There are plenty of great online prompt libraries; I ended up choosing a clean design style from designprompts.dev. I copied the prompt and asked my AI assistant to adapt it for my site’s needs. The tool suggested a few helpful adjustments, like tweaking the color palette to improve contrast and readability, giving us a solid design blueprint. With the initial prompt ready, I let the AI assistant go to work. First, it prompted me to log in to my Wix account by displaying a link and an 8-digit authorization code. I clicked the link, authenticated with Wix, entered the code and the tool took over from there. Want to get better at writing prompts? Explore these guides for tips on writing effective AI prompts, refining your instructions and getting better results from AI tools: AI prompts for website building Why prompt a website? How to make a website with a prompt Prompt engineering for website builders 02. Building the website Much of the AI assistant’s work happens automatically, but under the hood, it executes command-line interface (CLI) commands in the background. Each command invokes a tool to modify local project files or configure remote Wix settings. For example, the first command the agent ran looks like this: node "/Users/ranl/.codex/plugins/cache/openai-curated-remote/wix/6.0.0/skills/wix-headless/scripts/init-site-json.mjs" \ "$(pwd)" \ "Ran's Wacky Portraits" \ "Playful handmade comic-studio" \ "stores,ecom,cms,gift-cards,blog,forms" \ --frontend astro It might look a bit intimidating at first glance, but you don’t need to memorize any of it to use Wix Headless. In this example, Node executes a script called init-site-json.mjs, passing configuration parameters like the site name (“Ran’s Wacky Portraits”), site description, requested business features and the selected frontend framework (Astro). This command creates a configuration file that saves these choices for future build steps. For anyone learning how to make a website with a modern development setup, the important part is what happens next. Over the next few minutes, the AI assistant ran a series of commands to generate a basic starter template (a scaffold), connect it to Wix services and construct our customized frontend layout, complete with pages, image placeholders and interactive forms. At this point, the website files live locally on your computer, making it easy to test and refine everything in a local sandbox before publishing. Even though the frontend is running locally, it's connected to live Wix backend services, allowing you to test backend workflows in real time. Learn more: Wix Headless vs Shopify Headless Commerce 03. Customizing and testing the website To enable such local testing, the agent spins up what’s known as a “development server”: a simple, lightweight web server running on our computer, which serves the website's pages much like a real web server would. The agent provides us with a link to open in our browser; note the URL in the address bar, “https://localhost:[xxxx],” that’s a clear sign telling us we’re interacting with a local, undeployed site. As you can see from the above screenshots, the agent’s initial design is a solid starting point: it followed the design guidelines accurately, and the website already has a shop, a shopping cart (“bag”), a FAQ section and even a blog journal with six demo articles. The shop is even pre-populated with demo products. For a closer look at the principles behind creating a site like this, see our guide to web design. This is the point where we step in. Agents are powerful, but they’re far from perfect: we now need to test every piece of functionality on the website to make sure the AI wired it correctly to Wix’s backend. And indeed, the first time I tried submitting a contact form, I got an error message. Fixing such errors is, in almost all cases, as simple as asking the agent to take a look, but we can make the agent’s life easier (who knows, maybe it will pay off if they take over the world someday) by providing it with detailed error messages emitted by the browser. If you’re still working out the basics of how to design a website, this testing stage is worth paying attention to: good design isn’t just about how the pages look. Every form, button and interactive element needs to work as intended. To do that, right-click on any part of the website’s page and select “Inspect”. A sidebar will open in the browser with a tab called “Console”, where error messages will appear in red. Right-click on the console, select “Copy console” and paste the selection into the agent’s chat. It took several iterations of the agent trying various fixes and me copying and pasting errors from the console until the problem was resolved. I tried submitting another form and received a confirmation message, but that wasn’t enough. The agent provided me with another link, this time to the Wix Dashboard: the backend control panel where you can view and manage all the information flowing to and from your website. Browsing the dashboard, you can view our store’s catalog with the demo products, set basic options like currency and location and read the simple blog posts created by the agent. What we’re interested in right now is the form submission page: you’ll find it under Customers & Leads → Forms and Submissions. Click the Submissions tab, and voilà, our test message is stored safely in Wix’s database. I also received an email notification about the message. Next, I tried shopping: clicking a product, adding it to the cart and opening the checkout page. That didn’t work right out of the box either, but again, it took the agent only a few minutes to figure out the kinks in the connection to Wix’s backend. Note that since we’re using a free account, we can’t test the full purchase flow because a free account can’t process real payments. That’s something we’d need to test again fully if we decided to upgrade to Premium. Finally, I tested the Members area: I created a test member using a different email address, and as expected, the test account appeared in the dashboard. Learn more: How to make a website with Claude design 04. Finalizing the website With all the major functionality tried and tested, it was time to populate my website with actual products. Naturally, since I can’t even draw a stick figure, I used ChatGPT to transform a few nice shots of my office friends into wacky caricatures. I asked the agent to remove all the demo products and replace them with my generated images. Once it did, I used the Dashboard product catalog interface to set the prices and descriptions. I did one final check of all the pages on my demo site, verified that everything was as it should be, and then asked the agent to deploy the site to Wix’s servers. “Deploying” simply means uploading our local website to Wix’s servers so it becomes accessible to visitors across the web. Here’s the live site, check it out! Even though I’m quite enamored with these wacky and cute caricatures, my main goal with this guide was to demonstrate how quickly and easily you can create a fully functioning ecommerce website using Wix Headless. By letting the AI assistant build the front end in minutes and connecting it to Wix’s existing business solutions, you get remarkable speed without sacrificing the site’s reliability or security - which are backed by Wix’s battle-tested infrastructure. Plus, an added benefit of Headless is that you can design and tailor your website’s front end to fit your exact needs in any way you like. Already built your site with AI? Upload it to Wix Headless Ran's walkthrough starts from a blank folder, but you may be further along than that. Plenty of people open Claude or ChatGPT, describe a site and end up with a folder of working files on their laptop. Then they hit the part nobody warned them about: the site works on localhost and nowhere else. So can Claude build a website? Yes, and so can ChatGPT. Both will write you a frontend that looks good, usually in a single sitting. What they can't give you is a place for that site to live, a database behind it or a way to take a payment. That's the gap Wix Headless fills. If you already have an AI-built site, you can upload your AI built website here and skip the rebuild. Wix hosts it with free website hosting, and you can connect it to the backend tools you actually need. Wondering how to host an AI built site in general? You have two jobs: put the files on a server and keep the business logic somewhere reliable. Most people solve the first with a hosting service and then lose a weekend wiring up the second. With Wix Headless both sit under one login, so deploying and managing your store happen in the same place. That also covers the question of how to upload a website: you push your project to Wix instead of configuring a server yourself. Ready to make your own Wix Headless website? Ran's demo was a portrait shop, but the same setup fits a bakery, a course business or a small apparel brand. The pattern doesn't change. Your AI assistant designs the frontend and Wix runs everything that has to keep working when you're asleep. Here's what that backend gives you, with nothing extra to install: A CMS. Products, blog posts and page content live in the Wix dashboard, and your frontend reads from it. If you're still asking yourself do I need a CMS for my website, the short version is that you do the moment someone other than a developer needs to change the content. Payments. Wix Payments is Wix's built-in payment solution. It lets your store accept credit and debit cards and other local payment methods, with the checkout and compliance work already handled. It's available in select countries, so check that yours is covered. Testing is free, and you only need a Premium plan when you're ready to take real orders. Learn more: what is Wix payments? Forms, members and a blog. All of it was in Ran's build, and all of it shows up in the same dashboard. On the question of the best headless CMS, there isn't one answer, because it depends on who's editing and what you're selling. The honest pros and cons of a headless CMS go like this. You get total freedom over the frontend, your content can feed a website and an app at once and you're never stuck with someone else's layout. The cost is that you take on more setup, and with a pure CMS you still have to find your own checkout, forms and hosting. Wix Headless trims that last part because the CMS comes bundled with the commerce and hosting you'd otherwise assemble yourself. If you're wondering how to add an online store to an AI-built site, this is the shortest route. Name the store features in your first prompt, as Ran did with products, cart and members area. The assistant connects each one to Wix, and you set prices and descriptions in the dashboard like any other Wix store. Next steps: Open the Wix Headless page and copy the starter prompt. Describe your business, your key features and the look you want. Test every form and checkout step locally before you deploy. Upgrade to Premium when you're ready to accept payments and go live. Got a site idea and an AI assistant? That's all you need. Build the frontend your way and let Wix run the payments, CMS and hosting behind it. Try Wix Headless free. How to build a Wix Headless website FAQ: How do I make a Wix Headless website? Give an AI coding assistant like Claude Code, Codex or Cursor the prompt from the Wix Headless page, which points it to Wix's skill.md file. The assistant builds a frontend, connects it to your Wix account and lets you test it locally. When it all works, you deploy to Wix's servers. Learn more: Can Claude build a website? Can ChatGPT build a website? How do I host an AI built site? Your AI-built files need a server to run on. You can deploy to Wix's servers from your project, or upload your AI built website if you've already built one elsewhere. Either way you get hosting and backend services under one account. Learn: how to host an AI built site Is Wix Headless free? Wix Headless is free to build and test, and Wix Headless does not require a credit card to start. You can create a custom frontend with an AI coding assistant, connect it to Wix backend services and test forms, members and the CMS end to end at no cost. Wix Headless requires a Premium plan only when you're ready to accept live payments with Wix Payments and launch your site.

Make any AI project business-ready in one prompt. Try Wix Headless → You can migrate from WordPress to Wix Headless in less than a day by letting an AI agent move your content for you. On Wix there are no plugins, PHP versions or servers for you to keep updated. Wix handles security patches, hosting and scaling around the clock, and your store, blog and customer tools come built in. Move your WordPress content to Wix Headless. Use an AI agent to map and import supported content, then manage your business from one Wix dashboard. Wix handles the infrastructure, with built-in tools for ecommerce, bookings, CMS, payments and more. TL;DR: how to migrate from WordPress to Wix Headless Migrating from WordPress to Wix Headless starts with telling an AI agent what you want, like keeping your design, creating a new one or moving private data. The agent asks questions, presents a plan for your approval and imports supported content, then you finish a few setup tasks before launch. You'll learn: How to migrate from WordPress to Wix Headless in 5 steps What moves over and what doesn't Tips for a smooth migration Why move from WordPress to Wix Headless? Real WordPress migration, start to finish How to migrate from WordPress to Wix Headless in 5 steps The move runs on the Wix migration skill, a ready-made set of instructions your AI agent follows. The agent discovers your WordPress content, maps it to Wix equivalents and imports supported data into a new Wix project, with your approval at key stages. These steps follow the official Wix migration guide. 01. Get your tools ready Before you start, make sure you have these four things: A Wix account: Create a Wix account if you don't have one yet. Your migrated content and business tools will live here. An AI coding agent: Use a tool like Claude Code, Cursor or Codex to run the migration. The Wix plugin (recommended): Install the Wix plugin to help your AI agent work with Wix. Node.js and Git: Ask your AI agent to check that Node.js (version 24.22.1 or higher) and Git are installed and configured, and help you set them up if needed. 02. Set up the migration and tell your agent what you want Ask your AI agent to install the Wix migration skill. The skill guides the agent through discovering your WordPress content, mapping it to Wix and importing it. Then tell the agent which site to migrate and what you want from the move. For example, you might want to keep your existing design, create a new one, migrate public content only or include private data such as drafts, customers and orders. Be as specific as you like. The agent will guide you through the process and ask questions as needed. Example prompt: Use the wix-replatform skill: https://www.wix.com/skills/wix-replatform to migrate https://YOURSITE.com into a brand-new Wix site. Ask me anything you need. Build the site as an exact replica of the original, covering every page and every feature. Compare each page to the original on desktop and mobile, click every link, and fix any differences. Release it and send me the live link. The most important part is pointing the agent to the skill. Change the rest of the instructions to match what you expect from your migration, like a new design instead of an exact replica. If you want the agent to build and host a new frontend on Wix, also ask it to install the Wix Headless skill. Alternatively, you can install the Wix plugin for your agent. If your migration includes private data, have your WordPress username and an application password ready. You'll need these to authorize access to that data. 03. Follow the agent's migration flow The agent guides you through the migration based on your site and instructions. It may ask you to choose a frontend or backend-only setup, specify which data to migrate or decide how to handle comments, member emails and WordPress pages. 04. Review the content map and migration plan If you want to review and approve the migration before anything is imported, ask your agent to include these checkpoints in your initial prompt. The content map shows where each type of WordPress content will go in Wix, how many records will move and any known mapping gaps. The execution plan outlines setup tasks, import order and limitations. Review both carefully and ask for changes before approving the plan. This gives you a chance to address potential issues before the import begins. 05. Review your site and prepare for launch When the migration finishes, the agent provides a final report with any tasks that need manual setup. Migration time depends on your site's size and complexity, so it may take minutes or several hours. You'll get a link to your migrated site as well as access to its Wix dashboard. Review the content and test the site, asking the agent questions or requesting changes as needed. Complete any remaining setup, such as configuring payment methods and shipping, re-enabling member emails if you turned them off and setting up redirects from your old WordPress URLs. Once everything works as expected, connect your existing domain to the new site. Learn more: Frontend vs backend: key differences explained Headless CMS vs traditional CMS What moves over and what doesn't The migration skill scans your WordPress setup and maps supported content to Wix equivalents. Exact results depend on your content, your installed plugins and the data scope you choose, so review the mapping before you approve the import. Migrated content These are the most common content types and where they land. WordPress content Where it goes in Wix Products, categories, tags and attributes Wix Stores Product reviews Wix CMS Orders Wix ecommerce orders Customers Wix Members and Wix CRM Coupons Wix Coupons Blog posts, categories, tags and comments Wix Blog Pages like About and Contact Wix CMS (optional) Images and videos Wix Media Manager Plugin content like events and podcasts Wix CMS collections Customer records move over, but integrations and account behavior from your old site aren't recreated automatically. Not migrated Payment configuration, historical analytics and URL redirects stay behind. You set up payments and redirects yourself after the import. Limitations Nested blog categories become flat. Products with many options, like size and color, may come in as a single version at the base price. Subscription products with missing details may need manual setup. Member passwords aren't transferred, so members must reset their passwords to access their accounts. Keep in mind: the skill may migrate additional plugin content depending on your setup, but not every plugin or integration will carry over. Check the content map closely for anything your site depends on. Tips for a smooth migration Start with a dry run. Ask your agent to run in dry run mode first. It previews the migration without writing any data to Wix. Try public content first. A public-only run shows what the migration produces before you commit to a full import with customer and order data. Keep your WordPress site live until you're done testing. Real visitors keep using the old site while you check the new one behind the scenes. Don't worry if it stops halfway. The migration is resumable, so running it again picks up where it left off. A setup decision worth making early: WordPress application passwords expire. If your migration spans several sessions, generate a new one each time you resume. After launch, you or your team manage supported content and business data from the Wix dashboard without code. Expert tip from Jonathan Cantillo, founder of Samprand: "We taught her how to use the CMS, and I think that's one of the biggest benefits of Wix. You don't have to be super tech-savvy to upload things to the CMS or change categories. She's completely self-service." Why move from WordPress to Wix Headless? Managed infrastructure and security With Wix-managed headless, Wix manages hosting, infrastructure maintenance and platform security. That cuts down the routine server and platform upkeep that comes with a self-hosted WordPress site, though third-party integrations and custom code can still need your attention. Wix has a dedicated security team that monitors the platform around the clock, and it holds certifications including SOC 2 Type 2, ISO 27001 and PCI DSS Level 1. You can read the details in the Wix Trust Center. Worth being clear on: no platform is immune to security issues. The difference is who is responsible for finding and fixing them. Built-in business tools Instead of maintaining a separate plugin or system for each business function, you manage supported business data like products, orders, blog posts and customers through one Wix backend. Connecting to the Wix backend is free. A paid Premium plan is needed for certain capabilities, like accepting payments, connecting a custom domain and accessing advanced analytics. Expert tip from Anat Fennig, UX Lead at Wix: "There's no developer pricing, no fees for API calls, no enterprise tier you have to unlock. You connect for free and upgrade when you're actually ready to launch. We built the pricing to match how AI builders actually work, fast iteration first, monetization when the product is ready." Real WordPress migration, start to finish Happy Woof is an example WooCommerce store that sells dog products. Compare the WordPress version with the Wix Headless version, which was migrated with the migration skill and given a refreshed design. The products moved into Wix Stores with their names and prices and the blog posts moved into Wix Blog with their original titles and publish dates. What is Wix Headless? Think of a website like a restaurant. The dining room is the frontend, the design and pages visitors see. The kitchen is the backend, where orders, payments, customer accounts and content are handled. A headless setup keeps the two separate, so you're free to design the frontend however you like. Wix Headless is the kitchen. It's a business backend with a headless CMS, Stores, Blog, CRM, payments, bookings and events, all managed from one dashboard. Worth knowing: you get two hosting paths. With Wix-managed headless, Wix hosts your frontend and handles security certificates and scaling. With backend only or self-managed headless, you arrange hosting for your own frontend and connect it to the same Wix backend. Read more: What is Wix Headless? How much does Wix Headless cost? WordPress to Wix Headless FAQ: Do I need to know how to code to migrate from WordPress to Wix Headless? No. The AI agent handles the technical migration work. You still need to install the required tools, like Node.js and Git, answer the setup questions and approve the plan before anything is imported. How long does a WordPress to Wix migration take? A WordPress migration with an AI agent can take anywhere from a few minutes to several hours, depending on your site's size, complexity and the amount of content being moved. Extra work, such as rebuilding the design or configuring features manually, can extend the timeline. Will I lose my search rankings when I move from WordPress? You can migrate from WordPress without losing your search rankings, but careful planning is important. Map each existing URL to its new destination and set up permanent (301) redirects for URLs that change. Preserve important page content and metadata, update internal links and make sure search engines can access your new pages. After the migration, monitor Google Search Console for indexing issues and ranking changes. These steps help preserve your SEO value, though rankings may still fluctuate after a migration. Can I keep my domain name? Yes. The migration doesn't handle your domain, so you connect your existing domain to the new Wix site through your domain registrar after testing. You don't need to transfer the domain's registration to Wix just to connect it. Connecting a custom domain requires a Premium plan. Will my members need new passwords? Yes. WordPress member passwords aren't imported, so members must reset their passwords using the forgot-password option to access their accounts. Let them know before launch. If you kept welcome emails off during the import, turn them back on before you go live.

Connect any frontend to a full business backend with Wix Headless → AI coding tools like Claude Code and Cursor can now produce a custom shop frontend in an afternoon. What they can't produce is the proven backend that takes care of carts, payments and orders. This guide compares 12 options side by side, from an all-in-one headless solution to open-source and enterprise tools, so you can match the system to how you build. Connect your project to Wix Headless for free. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL, then come back to compare the rest of the field. TL;DR: best headless commerce platforms The best headless commerce platforms for 2026 are Wix Headless, Shopify, BigCommerce, commercetools and Medusa, and the right pick depends on how much backend you want to run yourself. Wix Headless leads because it combines an ecommerce platform, a headless CMS, payments, online scheduling and events in one backend. You'll learn: What a headless commerce platform is and when it makes sense Seven criteria that separate the best platforms from the rest How platforms compare on hosting, pricing and ideal use case Who each platform is best for and where each one has trade-offs How headless differs from composable commerce Which platform fits your team, budget and AI workflow What is a headless commerce platform? A headless commerce platform splits the part customers see, like product pages and checkout screens, from the backend that runs carts, inventory, payments and orders. The two sides talk through APIs, so your frontend can be a Next.js site, a mobile app or anything else you can code. If you want the full definition, start with what is headless commerce. The timing is good. Americans spent $1.23 trillion online in 2025, and ecommerce keeps taking a bigger share of retail, according to the US Census Bureau. There has never been a better time to sell online. Headless gives you speed and design control, but it also hands you a new job. You need a production frontend, and you need a backend you can live with for years. A traditional ecommerce platform bundles both together, while headless lets you choose each side on purpose. Best headless commerce platforms at a glance Here's how the 12 platforms line up on type, hosting, best use and pricing basis. Platform Type Hosting Best for Pricing basis Wix Headless Full business backend Wix-managed or self-hosted AI builders, agencies and one native backend Free to connect, Premium plan to sell Shopify (Hydrogen) SaaS with headless APIs Oxygen or self-hosted Brands already on Shopify Shopify plan, Oxygen included on paid plans BigCommerce (Catalyst) SaaS with headless APIs External host such as Vercel Mid-market SaaS plus custom frontend BigCommerce plan, Catalyst has no extra cost commercetools API-first SaaS SaaS backend, you host the frontend Large composable enterprises Quote-based Medusa Open-source framework Self-hosted JavaScript teams who want code ownership Open source (MIT) Saleor Open-source GraphQL platform Self-hosted or Saleor Cloud GraphQL-first teams Open source (BSD-3) plus cloud plans Vendure Open-core framework Self-hosted or Vendure Cloud (beta) TypeScript teams building B2B and omnichannel Open core (GPLv3) plus commercial tiers Commerce Layer API-first commerce engine SaaS, you host the frontend Multi-market checkout Free developer plan, enterprise by quote Elastic Path Composable commerce suite SaaS or self-managed Complex B2B and catalogs Quote-based Adobe Commerce Enterprise suite with APIs Adobe cloud or self-managed Adobe ecosystem enterprises Open-source edition or paid Adobe tiers Salesforce Commerce Cloud Enterprise suite with APIs Managed Runtime (serverless) Salesforce ecosystem enterprises Quote-based Shopware Open-source API-first platform Self-hosted, PaaS or SaaS Open-source PHP teams Open-source Community Edition plus paid options 12 best headless commerce platforms Wix Headless Shopify (Hydrogen) BigCommerce (Catalyst) commercetools Medusa Saleor Vendure Commerce Layer Elastic Path Adobe Commerce Salesforce Commerce Cloud Shopware 01. Wix Headless: best for AI builders, agencies and teams that want one native business backend Wix Headless is a headless solution that connects any frontend to a full native business backend, including ecommerce, a CMS, payments, bookings and events. You build and own the frontend on any AI coding tool or code stack, and Wix handles the backend. It is designed for AI builders, vibe coders and agencies who want full creative freedom on the front without building or managing infrastructure. How Wix Headless works Wix Headless connects frontends built with AI coding tools such as Claude Code, Cursor, Codex and Gemini CLI, plus platforms like Base44, to Wix business solutions. For a new project, you paste the wix-headless.dev/skill.md prompt into your AI tool and your project is wired to the Wix backend in one step. Prefer more control? The Wix CLI creates a locally developed, Wix-hosted project, and a code library covers a fully self-managed setup. Our guide on how to make a Wix Headless website walks through each path. Already built something in an AI tool? You can connect Claude Code to a backend and keep working in the same workflow. Wix Headless does not ask you to rebuild inside a Wix editor. What Wix Headless includes for commerce Wix Headless ecommerce lets developers manage orders, inventory, shipping and finances through Wix business solutions. It includes secure payments, optimized checkouts and automated sales taxes, and it syncs product data to Facebook and Instagram catalogs from the Wix dashboard. Every Wix Headless project runs on the same payments infrastructure that powers live Wix stores, so you can accept payments without a separate setup. According to Itay Shmool, VP and Chairman of Payments at Wix: "People using Claude or Cursor to build are moving at a speed that traditional infrastructure just can't match. They'll have a working prototype in an afternoon and then spend weeks trying to bolt on payments. Wix Headless closes that gap. The infrastructure is already there, you're not setting it up, you're connecting to it." Commerce is only part of the backend. Wix Headless includes a headless CMS that organizes content into collections connected directly to your frontend, which pairs well with a shop that also needs a blog or editorial pages. If you are weighing options for content, see the best headless CMS options for a wider comparison. Wix Headless Bookings handles online scheduling end to end, so clients can book, pay and receive reminders automatically. Wix Headless Events covers tickets, RSVPs and guest management for any event website. Worth being clear on: Wix Headless gives you a complete business backend with ecommerce, bookings, events, a CMS and payments, all natively connected. The frontend is yours to build and own, but if you don't have one yet, Wix Headless gives you the tools to create one too. Describe what you want on the Wix Headless page and it opens in your chosen vibe coding platform with the backend already wired in, or use wix.com/headless/skill.md with any AI coding tool to build and connect in one step. Hosting, SEO and pricing Wix Headless offers two hosting options. Wix-managed headless means Wix handles hosting, CDN, SSL and scaling for you. Self-managed headless means you host on Vercel, Netlify, AWS or any other platform and connect to Wix through its APIs and JavaScript SDK. Wix-managed projects use Astro and support React, Vue, Svelte and Solid frontends, and the whole setup runs on multi-cloud ecommerce hosting with a global CDN, automatic scaling and uptime monitoring. Search visibility is covered too. Wix Headless provides Wix SEO controls for custom meta tags, editable URLs and structured data, plus an automatically maintained XML sitemap. If you already have a finished static site, drag and drop deploy takes HTML, CSS and JavaScript files up to 20 MB in total and gives you a live site on a shareable Wix URL. This surprises most new users: there is no time limit, no credit card required and no sandbox mode when you connect. Wix Headless is free to connect, with no developer pricing, no API fees and no enterprise tiers. You build everything out and test every flow before spending anything, and the only things that need a paid Premium plan are accepting live payments, connecting a custom domain and unlocking advanced analytics. For the full breakdown, see how much does Wix Headless cost. Worth knowing: Wix-managed headless and self-managed headless both connect to the same complete Wix business backend. The choice comes down to how much control you want over your hosting environment, not what backend features you can access. Build your frontend your way and let Wix run everything behind it with Wix Headless → Who Wix Headless is best for Wix Headless suits AI builders, vibe coders, agencies and freelancers who want to own the frontend and skip backend engineering. Strugbits, a web and mobile development agency of about 150 people, now builds its own site and client sites on Wix Headless with Next.js frontends, and roughly 90 out of every 100 of its sites use the Wix CMS. Samprand built a Flutter app for iOS, Android and web on Wix Headless for a fitness creator, and she now manages her own content through the Wix CMS and Wix Automations. Solo builders get results too. Developer Rafal Koziarz rebuilt his partner's online fashion store on Wix Headless using Claude Code for the build and Google Stitch for the design, then deployed it on Vercel. His partner now manages products and content from the Wix admin, so neither of them blocks the other. Rafal Koziarz, developer of Solitairec, put the speed this way: "The first version only took a day, because the checkout and login are still Wix, and the front end was already described to the LLM." Wix Headless is also a practical path if you want to sell from a website built in an LLM or if you are ready to migrate from WordPress to Wix Headless. It is a lighter fit for large enterprises that need deep ERP-driven B2B workflows or a fully composable stack of specialist services. Those teams will find strong options further down this list. 02. Shopify (Hydrogen) Shopify's headless route centers on Hydrogen, its React Router based framework, and Oxygen, its global edge hosting platform. Hydrogen includes pre-wired components and a CLI, and it connects to Shopify's headless APIs, which are versioned quarterly. Oxygen is included at no extra charge on paid Shopify plans, and you can also self-host Hydrogen or use the Headless sales channel to host a custom frontend anywhere. The big strength is a proven checkout and a huge app ecosystem, so brands already on Shopify can get a fully custom frontend without moving their operations. Hydrogen versions track Shopify's API versions, which means breaking changes arrive on Shopify's schedule rather than yours. The backend stays a managed Shopify system tied to your Shopify plan. Choose Shopify when your catalog and operations already live there and your goal is a faster, more custom frontend. If you also want bookings or event ticketing in the same backend, check how Shopify handles them before you commit. Learn more: Wix Headless vs Shopify Headless Commerce Wix vs Shopify Wix Studio vs Shopify Shopify alternatives 03. BigCommerce (Catalyst) BigCommerce is a SaaS ecommerce platform, and Catalyst is its open-source headless framework. Catalyst is built with Next.js, React and BigCommerce's GraphQL API, and it is released under the MIT license. BigCommerce says Catalyst is free to use for any merchant with an available channel, including trial stores, at no additional cost from BigCommerce. Catalyst gives you a production-ready B2C shopping flow out of the box, with product pages, a cart, customer accounts and a secure redirected checkout. That hosted checkout keeps payment data off your frontend, which simplifies PCI compliance. You still host the Next.js frontend yourself on Vercel or any host that supports Node.js or Docker. BigCommerce asks for some development experience, so it suits teams with developers or a certified agency. It is a sensible middle option for mid-market brands that want SaaS convenience without running their own commerce backend, though deep customization stays inside BigCommerce's model. Learn more: Wix vs BigCommerce 04. commercetools commercetools is an API-first commerce platform built on MACH principles, which stand for microservices, API-first, cloud-native and headless. It helped define composable commerce and runs as a SaaS backend, so you build and host your own frontend and any custom middleware. Large organizations with several brands, regions and channels use it to model complex catalogs and pricing. Its flexibility is also its cost. You assemble a great deal yourself, so commercetools works best with a dedicated platform team and a real composable strategy. Add-ons for areas like B2B come as paid modules. commercetools prices by quote, so you will need to talk to sales for numbers. It is a strong choice for global enterprises that want maximum architectural freedom and have the engineers to use it. Smaller teams usually find it more platform than the project needs. 05. Medusa Medusa is an open-source commerce platform with a built-in framework for custom commerce applications, released under the MIT license. Its commerce modules are freely available on npm, and the codebase is mostly TypeScript. Teams use it to build B2B or direct-to-consumer stores, marketplaces, distributor platforms and point-of-sale systems. The appeal is control and zero license fees. You can read, fork and extend the code, and the module system keeps customizations tidy. If your team already works in JavaScript or TypeScript, Medusa will feel familiar from day one. Open source means you own the operations too. Expect to assemble more yourself, and check that the advanced B2B or enterprise features you need are mature before you commit. Medusa is a strong pick for developer-led teams that want a flexible, fully owned starting point. 06. Saleor Saleor is an open-source, GraphQL-only commerce platform built on Python and Django, released under the BSD-3 license. It offers native multichannel control, with per-channel pricing, currencies and stock, plus webhooks, apps and metadata for extensibility. Saleor also provides a dashboard and an open-source React and Next.js frontend starter. You can self-host Saleor with Docker or start faster on Saleor Cloud, which offers developer accounts. The API design is clean because everything runs through GraphQL, and that makes mobile and multi-frontend builds easier to reason about. The main consideration is the backend stack. Saleor runs on Python, so it fits teams comfortable there, or teams that only touch the API from a JavaScript frontend. Pick Saleor when GraphQL-first design and multichannel selling matter more than a built-in frontend. 07. Vendure Vendure is a headless commerce platform built with TypeScript, NestJS and GraphQL. Its pitch is a single coherent commerce core that you extend with plugins and expose through one GraphQL API. It targets B2B and omnichannel needs such as multiple sales channels, customer-specific pricing and company account hierarchies. Vendure is open core. The commerce core is open source under the GPLv3 license and free to self-host, while advanced enterprise capabilities live in a commercial layer. You can run it yourself or use Vendure Cloud, which the team has opened as a beta with general availability planned for Q1 2027. Vendure also offers an open-source Next.js frontend starter. Self-hosting means you carry the operations unless you use Vendure Cloud, and the platform assumes a team comfortable with a modern TypeScript codebase. Choose Vendure when you sell into B2B or across many channels and want one extensible backend. 08. Commerce Layer Commerce Layer is an API-first, headless commerce platform built for globally distributed, multi-market selling. It provides checkout, orders, pricing and inventory through a large API surface of more than 400 resources, and it keeps content and commerce decoupled so you can pair it with your preferred CMS and frontend. Its multi-market design is the standout. Each market can have its own price lists, currencies and localized catalogs without duplicating data. Commerce Layer offers a free developer plan, and enterprise plans are priced through sales. It also publishes documentation on how AI agents interact with its APIs through MCP. Commerce Layer is infrastructure, not a ready-made shop, so you build the frontend and the surrounding stack yourself. It rewards engineering-led teams that want checkout and orders as clean building blocks across many channels. 09. Elastic Path Elastic Path is a composable commerce provider built on MACH principles. Its product family includes Product Experience Manager for catalogs, Composer for integrations and orchestration, and a self-managed commerce option for enterprises with specific infrastructure needs. The team says it pioneered headless commerce in 2011. Elastic Path leans into hard problems such as contract-based pricing, reseller hierarchies and multiple catalogs, which are common in B2B. Its catalog tooling is designed so product data, price books and category hierarchies stay separate, giving merchandisers more flexibility without custom development. Pricing is custom, and the platform expects real integration work. Elastic Path pays off when your requirements go beyond what a more packaged platform can express. Mid-market teams often find it heavier than they need. 10. Adobe Commerce Adobe Commerce builds on Magento and offers a large extension ecosystem plus GraphQL and REST APIs for headless delivery. Adobe's current guidance for new headless projects centers on Edge Delivery Services, where a frontend is composed from drop-in commerce components and hosted on Adobe's global content delivery network. That setup gives teams document-based content authoring and performance-focused delivery, and it connects naturally to the wider Adobe stack. Adobe Commerce also comes in an open-source edition for self-hosting, with paid Adobe tiers that add managed cloud and enterprise features. The trade-off is weight. Adobe Commerce is a large application to run, upgrade and extend, and the Edge Delivery path requires specific commerce services to be configured on the backend. It makes the most sense when your team already lives in Adobe. 11. Salesforce Commerce Cloud Salesforce Commerce Cloud pairs its B2C Commerce backend with a headless option built on the PWA Kit. That option combines the PWA Kit, an open-source React framework licensed under BSD-3, with Managed Runtime, a serverless hosting environment for your frontend. Your frontend talks to the commerce backend through Salesforce Commerce APIs. Managed Runtime scales with traffic and includes 100 environments out of the box at no additional cost, so teams can spin up test and staging copies easily. The real draw is tight integration with the wider Salesforce ecosystem across CRM, marketing and service. Commerce Cloud is a proprietary platform priced through sales, and it gives developers less low-level control than open or API-only options. It is more of an ecosystem decision than a pure commerce one, and it fits enterprises already standardized on Salesforce. 12. Shopware Shopware 6 is an open-source commerce platform built on the Symfony PHP framework with a Vue.js administration. It was built API-first, with a Store API for customer-facing apps and an Admin API for back-office work. Its Community Edition is free to use, and the Shopware PaaS and SaaS offerings are built on top of it. For headless projects, Shopware offers Composable Frontends, a set of platform-independent packages for building a custom frontend with Vue, React or another framework. Its API client is an independent TypeScript library, so you are not tied to one framework. You will need PHP and Symfony skills for backend customization, and you take on hosting unless you choose a managed Shopware option. Shopware is a good fit for teams that want open-source control with a mature, API-first design. Editor’s note: We build Wix Headless, so we ranked it first. Every platform here was judged on the same criteria and described using public vendor documentation as of October 2026. How to choose a headless commerce platform Wix Headless is our product, so we put it first and judged every platform on the same criteria below. Each section also names where a platform is not the best fit, including ours. Start with ownership. Open-source platforms like Medusa let you read and fork the code, while SaaS platforms run the backend for you. Then look at hosting, because some platforms are managed, some are self-hosted and some are both. Hosting decides how much operations work lands on your team. Next, count what you have to assemble. A single backend with commerce built in is one thing to run, while a fully composable stack of separate services is an ongoing integration project. Check how much of the frontend you must build from scratch, since that is the most underestimated cost of any headless project. Finally, compare pricing and total cost of ownership, and ask how well the platform fits your pace of building. That last point matters more every month. McKinsey projects that agentic commerce, where AI agents research, compare and buy on behalf of consumers, could drive up to $1 trillion in US B2C retail revenue by 2030, with global potential reaching $3–5 trillion, marking the next frontier beyond social and mobile commerce. Pick a backend your AI tools can connect to without piles of glue code. Worth knowing: a platform's license price is rarely your biggest cost. Frontend build time, integrations and the people who maintain them usually add up to more, so compare total cost of ownership rather than sticker price. Learn more: What is an AI workflow? Headless vs composable commerce Headless and composable are related but not the same. Headless decouples the frontend from the backend. Composable commerce goes further and splits the backend itself into separately chosen and separately operated services, such as search here and pricing there. Platforms like commercetools, Elastic Path and Commerce Layer sit firmly on the composable side. Composable promises plug-and-play best-of-breed vendors, but it can also mean managing many contracts and integrating many APIs that change on their own schedules. Wix Headless takes the other route with a decoupled frontend over one native backend that includes ecommerce, a CMS, payments, bookings and events. For background on how the two sides relate, read about headless CMS vs traditional CMS and what a backend as a service actually provides. Worth knowing: you can go headless without going fully composable. A decoupled frontend over one coherent backend gives you design freedom without a dozen separate vendor relationships to manage. Which headless commerce platform is right for you? The platforms above sort cleanly once you match them to your situation instead of a ranking. Use this quick guide to narrow your shortlist. AI builders and agencies: Wix Headless gives you one native backend for commerce, content, bookings and events, with frontend freedom on any AI tool or framework. Brands already on Shopify: Shopify with Hydrogen is the fastest path to a custom frontend without leaving a platform that already works. Mid-market teams that want SaaS plus a custom frontend: BigCommerce with Catalyst keeps the backend managed while you build your own frontend. Developer-led teams that want code ownership: Medusa for a JavaScript-first base, Saleor for a GraphQL-first Python stack or Vendure for a TypeScript core with strong B2B features. Global enterprises with platform teams: commercetools, Elastic Path or Commerce Layer for composable, multi-market commerce. Enterprises tied to a major suite: Adobe Commerce if you live in Adobe and Salesforce Commerce Cloud if you live in Salesforce. Open-source PHP teams: Shopware for an API-first core you can host and extend. One thing worth knowing: the best platform is the one your team can actually build and run. More features do not help if nobody has time to assemble them, so match your pick to the engineering time you really have. Small teams are proving how far the right backend can go. Freelance agency builder Shahkam Abdul Aziz pairs the Wix CLI with Cursor and has built every client project on Wix Headless since February 2026. Shahkam Abdul Aziz, freelance agency builder, describes the impact: "Wix Headless cut my dev time by at least 70 to 75 percent. Projects that used to take me months now take weeks, and sometimes less than two." See how one native backend feels for yourself with Wix Headless → Best headless commerce platform FAQ: Which headless commerce platform is easiest to start with? Wix Headless is one of the easiest to start with because it is free to connect and a single prompt that wires your AI-built project to the backend. What's the difference between headless and composable commerce? Headless commerce separates the frontend from the backend and connects them through APIs. Composable commerce also splits the backend into separate services that you choose and connect yourself. You can be headless without being fully composable by using one coherent backend behind a custom frontend.

Make any AI project business-ready in one prompt. Try Wix Headless → Taylor Ott is a real estate investment professional based in New York City. He's a trained architect with an MBA, and before this project, he wrote zero lines of code. Explore how Taylor vibe coded his website on a headless CMS with Claude Code and what he built along the way. Go from code to live site with Wix Headless. Upload or drag in your HTML, CSS and JavaScript files to get your site live with a shareable URL. Wix handles the hosting and infrastructure, and you can add ecommerce, bookings, CMS, payments and more with a single prompt. TL;DR: Wix Headless success story Taylor Ott had never written software, yet a few evenings with Claude and Wix Headless gave his firm a live landing page. He got a custom frontend, managed infrastructure with no servers to set up and a dashboard he updates without a developer. You'll learn: Why a headless solution fit the project How the prompts turned into a live site What a practical vibe coding flow looks like How he keeps the site updated on his own Takeaways for vibe coding builders Why Wix's headless solution was the right tool "I really wanted a video animation as my landing page and I just couldn't figure out the best way to do that. So I sat down with Claude and described what I was trying to build." - Taylor Ott Wix Headless User Taylor needed something specific: a clean, semi-mysterious landing page for Chestnut Ridge Ventures, his new real estate investment company. His video needed to be front and center, and he wanted just enough information that if someone saw his name on a letter of intent and looked him up, his website would represent his brand. He had his domain name. Now it was time to build. He turned to Claude to figure out how, and Claude directed him to Wix Headless. Learn more: What is a headless website Headless CMS vs traditional CMS From prompt to reality "Claude was the genesis behind me investigating the headless platform. Through Claude, I got a step-by-step process to create my website framework." Taylor described what he wanted to build and iterated until Claude directed him to the solution most relevant to his use case: Wix Headless. He added the Wix MCP integration and turned his first prompt into a first version of his website: frontend as he imagined, business manager ready to go. No bootcamp. Instead: a two-week blitz of evenings learning NPM commands, integrating MCPs and experimenting. Framework, frontend, publish, domain. Milestone by milestone, learned along the way. What a practical vibe coding flow looks like "I guess I am a developer." Here's the workflow Taylor landed on: 1. Describe the vision in plain language. Taylor told Claude what he wanted. Claude scoped the build and recommended the headless approach. As he went, he learned to engineer his prompts to be more precise and run through iterations to get exactly what he needed. 2. Chain the right tools. For the video animation, Claude pointed Taylor toward Google Stitch to generate the visual asset, then bring it back into the build. Stitch for assets. Wix for the backend. Claude Code to build. That's the stack. 3. Iterate with screenshots. Taylor sent Claude screenshots of what he was building to plan, build and navigate his next step in the Wix dashboard. Claude came back with the next three steps, clear and implementable. Every time. 4. Let the agent handle the infrastructure. DNS setup, website hosting, deployment - Taylor handled all of it. Not by learning networking, but by following Claude's guidance precisely. 5. Test it on real people. Taylor runs npm run build and Wix release from his terminal. But the real test was always what impression the site made. "Having an AI agent tell me step by step what to do has been really smooth. I showed people my website and they were pretty impressed." Taylor's vibe coding stack: Layer Tool AI Coding Agent Claude Code Visual Assets Google Stitch Backend Connection Wix MCP Infrastructure Wix Headless Content Updates Wix Business Manager Learn how to prompt like a pro: AI prompts for website building How to make a website with a prompt How to prompt a website with Wix Why Wix Headless specifically The alternative: a static site generator, a separate CMS, CDN, hosting provider is a difficult stack to manage even if you know what you're doing. For a solo non-technical founder, it's the kind of complexity that ends projects. Wix Headless is the best headless solution that natively combines a CMS, ecommerce, payments, bookings and events in one place. Taylor got a fully custom frontend backed by managed infrastructure. No separate hosting. No auth layer. No CMS to wire up. The backend was already there, and by pairing it with Claude Code and Google Stitch, he got to a result that looked exactly like what he'd imagined. Wix handled the hosting, site security and scaling. Taylor handled the vision. Learn more about Wix Headless: What is a headless CMS? How much does Wix Headless cost? What is Wix Headless? Ongoing updates without a developer New case study to add? Open the Wix Dashboard, add a row. New project to showcase? Same thing. No terminal. No Claude session. No deployment. The headless build was a one-time investment. The maintenance runs from an intuitive dashboard, or from Wix's mobile app. Takeaways for vibe coding builders Taylor had the instinct to take his AI agent's recommendations and learn along the way. The result wasn't just a website, it was a process others can learn from: Maintain control. Prompt your agent, but be critical of its suggestions. Experiment and test your outcomes. The builders who ship are the ones who push back and iterate, not the ones who always accept the first output. Research your stack. No tool can do everything alone. Taylor's combination of Wix Headless, Google Stitch and Claude Code got him to the finish line. The stack matters. Be ready to learn. Making mistakes costs less than avoiding them. You'll burn some tokens on dead ends. That's the job. Taylor's site came out well because he was willing to try, fail and try again. The distance between an idea and a live website is shrinking. Whether you're a developer looking to move faster or a vibe coder looking to break your own glass ceiling, what matters is using the best vibe coding tools to get to your goal, without compromising on design, security or quality. And if your next build is a full web app rather than a website, the Base44 vibe coding platform, also part of the Wix family, works the same way. Describe what you want in plain language and the app, backend and database are generated for you. With Wix Headless, flexibility meets robustness for more people than ever before. Taylor wanted a landing page that actually looked like his company. So he built it. Read more: Headless CMS Pros and Cons Start building with Wix Headless Paste http://wix.com/skills/headless into Claude Code, Cursor or any AI tool you already use, and your project is connected to the full Wix backend instantly. No servers, no backend engineering, no slowing down. Build your project on any AI tool, run it on Wix. Try Wix Headless now. Learn more about the best Headless CMS to choose from. Real estate investor Wix Headless story FAQ: Can a non-developer build a site with Wix Headless? Of course. Wix Headless is designed so that AI builders and vibe coders can connect any frontend to a full native business backend without building or managing infrastructure. With an AI coding agent like Claude Code and the Wix MCP, a non-technical builder can handle scaffolding, DNS setup, hosting and deployment through natural language guidance, no coding background required. See how businesses are building with Wix Headless: Wix Headless developer agency case study Wix Headless inherited project story From Instagram to app store with Wix Headless Wix Headless storefront in one day What is Wix Headless? Wix Headless is the only headless solution that natively combines a CMS, advanced ecommerce platform, payments, online scheduling and events in one place. You build your frontend on any AI coding tool or code stack, connect it to the full Wix business backend in one prompt, and manage everything from a single Wix Business Manager dashboard. No servers to run, no backend to engineer, no third-party tools to stitch together. What is vibe coding and how does it work with Wix Headless? Vibe coding is building software by describing what you want in plain language and letting an AI agent generate and implement it. With Wix Headless, vibe coders describe their project to an AI tool like Claude Code, which scaffolds the frontend and connects it to the Wix backend: Wix payments, CMS, hosting and more through a single prompt using wix.com/headless/skill.md.