To import WooCommerce inventory into an AI-built site with a Supabase backend, you move the catalog through a structured export, not a live connection. Export your products to clean CSV or JSON, model them as tables in Supabase, then have the AI-built front end read from Supabase to render the product pages. Two things make or break it: the export has to be complete, and the old product URLs have to be redirected. Miss the first and product pages are thin; miss the second and they lose their rankings. WPBuildAI exports the catalog, sets up the Supabase data, and maps every product URL to a 301.

Pin your Postgres version before the first import run, because Supabase logged self-hosted deployments moving from Postgres 15 to 17 as a breaking change on 18 May 2026, and inventory tables full of decimals and timestamps are exactly where a major version difference shows up.

What to export

A product page is more than a name and a price, so the export has to be thorough. Per product, capture: title, description, price, SKU, stock status, categories, images with alt text, variants and their attributes, and the current URL. The URL field is as important as the commercial data, because it is what you redirect. Ahrefs found in its search traffic study that a small share of pages carries most organic traffic, and in a store those are often the best-selling products and the categories above them, so a complete export protects exactly the pages you cannot afford to lose. An export that grabs titles and prices but skips descriptions, alt text, or URLs produces thin product pages with no way to redirect, which is why completeness is the first requirement, not an afterthought.

The instinct is to look for a live connection between WooCommerce and the new front end, but that is not how this works, and the structured export is better anyway. WooCommerce stores its data inside WordPress’s database in its own schema, entangled with the platform, so there is no clean live feed to point an AI front end at. A structured export, CSV or JSON shaped to match your new tables, gives you a clean, inspectable snapshot of the catalogue that loads directly into Supabase. It also forces the useful discipline of deciding your data model up front. So rather than a fragile live link to a platform you are leaving, you get a portable, reviewable dataset, which is the same reasoning behind exporting WordPress data for a Supabase backend generally.

Modeling it in Supabase

Supabase gives the AI front end a fast, structured database to read from, so you get a lean store without running WordPress and WooCommerce underneath. Model the catalogue as related tables: a products table keyed by slug or SKU, with columns for title, description, price, and stock; a variants table linked to it for sizes, colours, and their attributes; and a categories table with the relationships between them. The front end then renders product and category pages from queries against these tables. Keep the slug in the products table so the new URLs can map to the old ones. Designing the schema to mirror your export, so each exported field lands in a column, makes the import a direct load rather than a reshape, and gives you a clean, queryable catalogue you can edit and scale.

The checkout question

The one part to plan deliberately is checkout, because moving off WooCommerce means leaving its built-in cart and payment flow. Outside that flow, you wire payments and the cart yourself, and this is where caution pays off: a clunky or improvised checkout directly costs sales. Baymard’s cart abandonment research attributes much of the roughly seven-in-ten abandonment rate to friction in the checkout flow, so this is not the place to experiment. Use an established payment provider and a proven checkout pattern rather than building one from scratch, and keep the flow short and standard. The storefront, the catalogue, the product pages, the browsing, is where the AI build shines; the checkout is where you stay on well-trodden rails. Treating those two parts differently is what keeps an AI-built store from leaking sales at the final step.

A worked example: 1,200 products into Supabase

Picture a store with 1,200 products, including variable products with multiple sizes and colours. The export produces a products CSV with one row per product, a variants CSV linking each size and colour to its parent, and a categories CSV with the hierarchy, every row carrying its slug and original URL. These load into matching Supabase tables, and the AI front end renders product pages from queries, with variant selectors driven by the variants table. Checkout is wired to an established payment provider, not hand-built. Every old product and category URL is mapped to a 301. The result is a fast, lean store reading from a clean database, with the full catalogue intact and the rankings preserved. The migration succeeded because the export was complete, the schema mirrored it, and the redirects and checkout were handled deliberately rather than assumed.

Variable products and variants

Variable products are where a catalogue export most often goes wrong, so they deserve specific care. In WooCommerce a variable product has a parent and several variations, each potentially with its own SKU, price, stock, and sometimes its own URL. The export has to capture the parent and every variation with its attributes, and the Supabase model has to relate them, typically a variants table keyed to the parent product. If the export flattens variants into a single row, you lose per-variant pricing and stock; if it drops variant URLs that were indexed, you lose redirects. So treat variants as first-class rows, not an afterthought on the product. Getting this relationship right is what makes the new store’s product pages function correctly and keeps any variant URLs that earned traffic redirectable, which a naive title-and-price export would quietly lose.

Protecting product and category rankings

The database move handles the content; the rankings need their own step. Map every old product and category URL to a 301 before launch, and carry over titles, descriptions, and alt text, per Google’s site move guidance and redirects guidance. Products and categories rank and get linked individually, so each needs its own redirect, the detail in mapping product URLs and whether product pages lose rankings. Keeping the slug in the export is what makes these redirects straightforward, since the new URL can mirror the old path. The full store move, beyond the catalogue, is in migrating a WooCommerce store without losing sales. The catalogue loading cleanly into Supabase is necessary but not sufficient; the redirect map is what keeps the traffic.

Images and media

Product images are easy to under-plan and quick to break. WooCommerce stores images in the WordPress media library, so the export has to list every product image and its alt text, and the migration has to re-host those images on the new platform or a CDN rather than leaving them referenced on the old WordPress site. If the new Supabase-backed store points its image URLs at the old domain, the images vanish the moment you decommission WordPress, often weeks after launch when it is hardest to trace. Carry the alt text too, both for accessibility and for image search, which can be a real traffic source for a store. So treat media as part of the catalogue export, listed, moved, and re-referenced, not as something that will sort itself out, because hotlinked images are a delayed failure waiting for the old site to go away.

Common mistakes importing a catalog to Supabase

The recurring errors all reduce to an incomplete export or a skipped step. Exporting titles and prices but dropping descriptions, alt text, or URLs produces thin pages and makes redirects impossible. Flattening variable products loses per-variant data and variant URLs. Improvising a checkout instead of using a proven provider leaks sales at the final step. Leaving images referenced on the old WordPress domain breaks them when it is retired. And treating the database load as the whole job, skipping the 301s, drops the product and category rankings. Each is avoided by a complete, schema-matched export, first-class variant handling, a proven checkout, re-hosted media, and a full redirect map, which together move the catalogue without losing data, sales, or traffic.

Key points to remember

Import WooCommerce inventory into an AI builder with Supabase by exporting the catalogue to clean CSV or JSON, complete with descriptions, SKUs, variants, images, alt text, and URLs, then modelling it as related Supabase tables the AI front end queries. Handle variable products as first-class variant rows, keep slugs so URLs map, re-host images rather than hotlinking the old site, and wire checkout to a proven payment provider rather than building one, since checkout friction drives abandonment. The database move is only half the job; map every product and category URL to a 301 so rankings hold. WPBuildAI exports the catalogue, builds the Supabase backend, and maps the redirects, so the store moves without losing data, sales, or traffic; send your store URL for a fixed quote.

Not affiliated with WooCommerce, Supabase, WordPress, or Lovable.