How to manage multiple WooCommerce stores from one dashboard

The problem with tab-switching

If you run more than one WooCommerce store — a regional storefront, a wholesale site, a white-label shop for a partner, or a completely separate brand — you've probably felt the specific fatigue of maintaining them independently. A new product means logging into store A, uploading images, writing the description, setting variations, then repeating the entire process in store B and store C, hoping you didn't fat-finger a price or forget a size.

This is the core challenge of WooCommerce multistore operations: WooCommerce was built as a single-store platform, and it does that job brilliantly. But nothing in core WordPress or WooCommerce assumes you're the same merchant running five of them. Every "dashboard" is an island. The moment you try to manage multiple WooCommerce stores as a single business, you're stitching together spreadsheets, shared drives and a lot of copy-paste.

The fix isn't to abandon WooCommerce — it's still the most flexible commerce platform on the web — it's to add a coordination layer above your stores that treats them as one catalog and one order book, while still letting each site keep its own theme, domain, currency and checkout experience.

Hub-and-spoke architecture

Almost every successful multistore setup, whether managed by hand or by software, converges on the same shape: one hub store that owns the master catalog, and any number of spoke stores that receive a copy of what the hub decides to send them. This is exactly the model Stillpoint is built around.

The hub is where your merchandising team actually works: writing product copy, uploading photography, setting up variations, organizing categories. Spokes are publish targets, not editing surfaces. You never want two people independently editing the "same" product in two different admin panels — that's how titles drift, prices disagree, and customer support gets confusing answers depending on which store a shopper called about.

• Hub store: single source of truth for product data, the only place products are authored.
• Spoke stores: receive synced products, keep their own theme, domain, tax rules and payment gateways.
• Connections: each spoke is linked to the hub over a signed API connection — see Multisite & Connected Sites for how the pairing works, including plain multi-install setups and WordPress Multisite networks.

Catalog ownership rules

Once you accept a hub-and-spoke model, the next decision is which products go where. Not every store should carry your entire range — an outlet site probably shouldn't inherit your flagship collection, and a wholesale storefront may need SKUs your retail sites never see.

Per-store targeting instead of push-to-all

This is where per-store targeting matters. Rather than a single "sync everything everywhere" switch, you want to tick exactly which connected stores each product belongs to, at the product level, and be able to bulk-manage that for whole categories at once — see Categories & Tags for bulk category pushes. That distinction between "can sync" and "does sync" is what keeps a growing catalog from becoming an unmanageable mess.

Getting this right up front saves you from the classic support ticket: "why is this item on our outlet site at full price?" — usually the answer is that catalog rules were never defined, and everything just got pushed everywhere by default.

Inventory rules across stores

Product data syncing gets you consistent listings; it does not, on its own, stop you from overselling. If the same physical stock is sold from three storefronts, you need WooCommerce inventory sync across stores that updates availability in near real time, not on a nightly cron job.

With shared-stock products, a sale on your UK store should decrement the count that your AU and DE stores see within seconds, not hours. That's the difference between an occasional oversell and a policy of never overselling. See Inventory & Stock Sync for how Stillpoint keeps stock levels aligned the moment an order is placed on any connected store.

• Decide which products share one physical stock pool versus which are store-specific.
• Set safety buffers for fast-moving SKUs so a burst of simultaneous orders can't dip below zero before sync catches up.
• Reconcile manual stock adjustments (damaged goods, returns) back to the hub so every store reflects reality.

Centralized order handling

Catalog and inventory get most of the attention, but orders are where a fragmented setup really hurts. If a customer orders from Store B, someone still has to fulfil it — and if fulfilment staff only ever look at Store A's admin, that order is invisible until someone remembers to check three other dashboards.

Centralized WooCommerce order management means every order, regardless of which store took the sale, lands as a native order in one WooCommerce → Orders screen, tagged with its source store and original order number. We cover this in depth in Centralizing orders from multiple WooCommerce stores, and the mechanics are documented on the Order Pull-Through page.

Team workflow

A hub-and-spoke setup only pays off if your team's actual workflow matches it. In practice that means:

• Merchandisers work exclusively in the hub — new products, pricing changes, seasonal copy updates.
• Fulfilment and support work from the centralized Orders screen, never logging into spoke-store admins for day-to-day tasks.
• Store-specific staff (a regional manager, say) can still log into their spoke for local settings — shipping zones, local payment methods, store hours — without touching product data.
• A background job queue (see Background Sync & Reliability) handles the actual transfer, so nobody is manually clicking "push" for every change.

Common pitfalls

A few mistakes show up again and again in multistore operations, regardless of the tooling behind them:

• Editing spokes directly. Any edit made on a spoke store gets overwritten on the next sync unless it's a deliberately store-specific field. Treat spokes as read targets.
• No idempotency. Re-running a sync should never create duplicate products or duplicate orders. Confirm your tooling matches on stable identifiers, not just names.
• Ignoring variations. Simple products sync easily; variable products with dozens of attribute combinations are where naive scripts fall apart. See Variations & Attributes.
• Forgetting HPOS. If your hub runs WooCommerce's High-Performance Order Storage, your order pull-through needs to be built for it natively — see Security & HPOS Compatibility.
• No visibility into failures. Networks are unreliable; a sync tool without retries and an activity log will quietly leave stores out of date.

If you'd rather not build and maintain this coordination layer yourself, that's exactly what Stillpoint's feature set is designed to replace — connect your stores, define catalog ownership once, and let sync and order pull-through run in the background. Compare plans on the pricing page.