Powerful WooCommerce Product Feeds – Managing 17,000 Products on a WooCommerce Website

Managing WooCommerce Product Feeds at Scale

When you first hear the phrase WooCommerce product feeds, it usually means one of two things: sending product data out to platforms like Google Shopping, or pulling product data in from a supplier or distributor. On a small store, either job is almost trivial. On a busy VPS handling two separate WooCommerce installations and around 34,000 live products, it is anything but trivial.

In my case, both stores import products from a large Australian IT distributor via their partner API. A custom plugin handles the heavy lifting: it talks to the API using cURL, keeps prices and stock in sync, creates new products when needed, and automatically retires discontinued items. That sounds neat and tidy on paper. In reality, every decision you make about WooCommerce product feeds has consequences for database size, query performance, image storage, caching, and even server security.

At this scale, you are not “just installing another plugin”. You are effectively wiring WooCommerce directly into someone else’s live catalogue, then asking your VPS to keep up with constant changes in price, stock, and product lifecycle. If you get it wrong, the result isn’t just a messy product list – it’s a slow, unstable site, a bloated database, gigabytes of unnecessary images, and a server being hammered by bots that have discovered you are indexing thousands of SKUs.

This article walks through how I approach managing WooCommerce product feeds at scale for API-driven catalogues: how the importer is designed, how we protect performance on a VPS, how we stop discontinued products from clogging the catalog, and how we keep images, cache, and security under control. The goal is simple: let WooCommerce handle tens of thousands of products smoothly, without burning your server to the ground in the process.

What We Really Mean by “WooCommerce Product Feeds”

Before we get into VPS tuning and database surgery, it’s worth being clear about what I mean by WooCommerce product feeds. The term gets used rather loosely, and that confusion can lead to very bad decisions at scale.

Broadly speaking, there are two very different worlds:

• Outbound feeds – You take your existing WooCommerce catalogue and push it out to other platforms: Google Shopping, Facebook, marketplaces and comparison engines. The store is the “source of truth”; the feeds are essentially exports.
• Inbound feeds – You pull product data in from one or more suppliers, distributors or ERPs. In this case, WooCommerce is not the original source of truth; it is a consumer of someone else’s live catalogue.

Outbound WooCommerce product feeds can be demanding in their own way, but they are usually predictable. Your catalogue already exists, and you are transforming that data into whatever format Google or another platform demands.

Inbound feeds from a large distributor are an entirely different animal. You are asking WooCommerce to track tens of thousands of SKUs, honour the supplier’s status and lifecycle flags, react to constant price and stock changes, and gracefully retire discontinued products – all without letting the database, media library or server performance collapse under the load.

The rest of this article focuses on that second world: inbound, API-driven WooCommerce product feeds at scale, where your store is tightly coupled to a live external catalogue and every inefficiency shows up as CPU load, disk usage or a slow checkout.

Building WooCommerce Around a Single Source of Truth

At the heart of any serious strategy for managing WooCommerce product feeds is a boring but vital idea: there can only be one source of truth. In my case, both WooCommerce sites take their marching orders from a major Australian IT distributor’s partner API. If the distributor says a product exists, is active, has a certain price and a certain stock level, that is the truth. WooCommerce’s job is to reflect it accurately and efficiently – nothing more, nothing less.

That sounds obvious, but it has design consequences. The most important is this: everything hangs off the SKU. The SKU from the distributor must be copied into WooCommerce and never “improved”, padded or decorated. Every sync operation starts by asking a simple question: “What is the current status of SKU X in the supplier’s catalogue, and what do we need to do in WooCommerce to match it?”

From that, the feed architecture falls into place:

• The importer talks to the supplier’s API exclusively via cURL, using endpoints for full catalogues, modified products, and a lightweight price/stock feed.
• Each incoming record is mapped to a clean internal structure: SKU, name, brand, price, stock on hand, status, lifecycle, and a few booleans for availability.
• WooCommerce is then updated by SKU: create the product if it doesn’t exist, update it if it does, and gracefully retire it if the feed says it is effectively dead.

Because I’m running around 17,000 SKUs per site, the importer also has to be respectful of the server. That means using delta feeds (only modified products) wherever possible, falling back to a limited walk of the full catalogue when needed, and separating heavy product updates from the lighter price/stock synchronisation. The end result is a WooCommerce catalogue that behaves as if it were native and hand-curated, while in reality it is being driven continuously by live WooCommerce product feeds from an external system.

Designing the Importer: New, Updated and Discontinued Products

Once you accept that the supplier’s catalogue is the source of truth, the logic for handling WooCommerce product feeds becomes much clearer. Every incoming record falls into one of three buckets: a new product that should be created, an existing product that needs updating, or a discontinued product that should quietly disappear from the public catalogue without breaking anything.

On each run, the importer walks the distributor’s “modified products” feed first. This is a delta feed: only items that have changed since the last run. For each record, the plugin:

• Extracts key fields from the API: SKU, name, brand, price, stock, status, lifecycle, and availability flags.
• Looks up the product in WooCommerce by SKU (which is why the SKU must remain pristine).
• Decides whether this product should be created, updated, or treated as discontinued.

If the record is active and saleable, the plugin either creates the product or updates the existing one. It sets the product title, brand meta, regular price, effective price, stock quantity and WooCommerce stock status, and records the last sync time. From the merchant’s perspective, the store simply “knows” about new products and keeps existing ones accurate – the mechanics of the WooCommerce product feeds stay invisible.

Discontinued products are trickier. Not every distributor provides a clean “expired products” feed, and sometimes the only signals you get are lifecycle flags, mixed status fields and stock dropping to zero. In my case, the importer uses a cautious heuristic: a combination of status text, lifecycle codes, activity booleans and stock level. If the record looks genuinely end-of-life, the matching product is moved to the trash rather than being hard-deleted. That keeps the public catalogue clean while preserving data and avoiding nasty surprises with links, orders or reporting.

To keep the server load under control, the importer also has a safety net. If the modified-products feed is empty for some reason, it performs a limited walk of the full catalogue instead – just enough pages to catch obvious changes without trying to re-import all 17,000 products in one go. The goal is always the same: handle new, updated and discontinued items reliably, while staying within the performance envelope of a realistic VPS.

Splitting Heavy Imports from Lightweight Price and Stock Syncs

One of the easiest ways to kill a VPS is to treat all WooCommerce product feeds as equal. Creating or updating full products is heavy work: titles, meta, taxonomies, prices, stock, lookups, and cache invalidation all fire at once. Doing that for thousands of products on every run is a great way to turn a fast WooCommerce store into a sluggish mess.

The cure is to split the job in two:

• Full product syncs – Handle structure: create new products, update names, brands and any other “shape of the catalogue” data. This is the heavier operation and should be run on a sensible schedule.
• Price and stock syncs – Use a dedicated endpoint that only reports current price, stock on hand and basic status flags. This is dramatically lighter and can safely run more often.

In practice, the importer on my two sites runs a combined “new/updated/discontinued” sync and a separate price/stock sync. Both can be triggered manually from the WooCommerce admin, and both also run on an automated schedule. The heavy syncs rely on delta feeds and capped catalogue walks; the price/stock sync marches through a slim endpoint that only carries the fields needed to keep offers accurate.

This separation has three big benefits:

1. Performance – Most of the time, WooCommerce only needs fresh pricing and stock levels, not a full rebuild of every product. Moving that into a dedicated, efficient process keeps the load down.
2. Stability – If the supplier briefly misbehaves or returns odd data, the impact is limited. You are not trying to recreate the entire catalogue on every blip; you are just updating what matters.
3. Control – You can tune schedules separately. For example, run full catalogue syncs every few hours, but run price/stock updates more frequently if trading conditions demand it.

When you are managing WooCommerce product feeds for around 34,000 products, this kind of separation is not an academic optimisation. It is the difference between a VPS that quietly handles its workload and one that spends its days hovering near 100% CPU every time a cron job fires.

What 34,000 Products Do to Your Database and VPS

On paper, 17,000 products per site doesn’t sound outrageous. In MySQL, it is not just 17,000 rows; it is tens or hundreds of thousands of rows spread across multiple tables. Every time your WooCommerce product feeds run, you are not only touching wp_posts, you are also hitting wp_postmeta, wp_wc_product_meta_lookup, term relationships, transients and whatever your theme and plugins have decided to stash away “for convenience”.

If you import carelessly, you pay for it forever. Duplicate SKUs, orphaned variations, abandoned images and half-updated meta entries all translate into extra work for the database on every page load. On a modest VPS, that shows up as slow queries, high CPU, creeping swap usage and, eventually, a site that “feels heavy” even when traffic is low.

The importer I use is deliberately conservative. Each record coming from the distributor’s API is mapped to a clean internal structure, and everything is keyed off the SKU. Before creating anything, the plugin asks MySQL one simple question: “Does this SKU already exist?” If it does, the code updates it in place instead of creating yet another product that just happens to have the same title. That single discipline – treating SKU as the absolute key – keeps the catalogue tight, the lookup table sane and the index usage efficient.

For around 34,000 products, that discipline is supported by a few practical rules:

• No uncontrolled growth – The feed is not allowed to create endless duplicates. Each SKU corresponds to one product, full stop.
• Discontinued means removed – When the feed tells us a product is effectively end-of-life, it is moved to the trash. Leaving thousands of dead items “just in case” is how catalogues quietly double in size.
• Sync runs are bounded – Delta feeds are used wherever possible, and full catalogue walks are capped. The code explicitly avoids trying to refresh every single product on every pass.

This is where engineering discipline matters more than shiny dashboards. Managing WooCommerce product feeds for 34,000 products is not about fancy marketing features; it is about keeping the database lean enough that normal WooCommerce queries still complete in milliseconds. Every careless decision made in the importer – from how you look up products, to when you delete them, to how often you run the cron – eventually shows up as VPS resource graphs you would rather not see.

When you get it right, something interesting happens: even with two large catalogues on the same VPS, CPU usage stays reasonable, swap barely moves, and front-end customers have no idea they are browsing a store that is being driven by heavy inbound feeds. They just see a fast, accurate catalogue. All the hard work happens in the background, quietly, every time the WooCommerce product feeds wake up and do their job.

Image Management: When Product Feeds Blow Up Your Disk

If the database is one side of the problem with large WooCommerce product feeds, the media library is the other. Distributors love high–resolution imagery, multiple angles and huge originals. WooCommerce, in turn, happily generates a set of thumbnails for every single one. Do that for tens of thousands of products and you suddenly discover that your “modest” VPS is storing tens of gigabytes of product photos you never truly needed.

I have seen this first-hand. On one site, the uploads folder was sitting at around 18 GB; on the other, about 24 GB. After a systematic ShortPixel run, those numbers dropped to roughly 8 GB and 11 GB respectively – a reduction of nearly half, purely from compressing and optimising images that arrived via inbound product feeds. No theme change. No content rewrite. Just cleaning up the visual fallout from years of automated imports.

At scale, image management stops being “nice to have” and becomes infrastructure. A sensible strategy for API-driven WooCommerce product feeds includes:

• Compression by default – Every product image is run through a serious optimiser such as ShortPixel. Originals are either compressed aggressively or, where safe, discarded after conversion to modern formats.
• Reasonable image sizes – WooCommerce thumbnail and catalogue sizes are set deliberately. There is no point generating 20 different sizes for every image if the theme only uses three.
• Pruning the junk – Old, unused or orphaned images from long-vanished products are identified and removed. Otherwise, your disk becomes an archaeological record of every SKU that ever briefly appeared in a feed.

Those ShortPixel reductions – from 18 GB to 8 GB on one store, and from 24 GB to 11 GB on another – are not just feel-good numbers. They translate directly into faster backups, quicker restores, less I/O, and more breathing room on the VPS. When you are running two large catalogues driven by inbound WooCommerce product feeds, that breathing room is precisely what keeps everything else stable.

Security and Bot Control on a Feed-Driven WooCommerce Store

The day you put a large catalogue online, you discover a new hobby: watching bots hammer your server. A store running serious WooCommerce product feeds is a magnet for scrapers, price comparison crawlers, half–broken SEO tools and outright junk traffic. Every one of those “visitors” costs CPU, memory and I/O. On a VPS that is also busy importing products, that cost matters.

There are two unpleasant truths here. First, most of this traffic is pointless: it will never become a customer. Second, it tends to hit exactly the parts of your site that are most expensive to generate – product archives, complex filters, search results and large category pages. Left alone, a handful of noisy bots can do more damage to performance than a busy day of real human customers.

For stores driven by inbound WooCommerce product feeds, security and performance blend into one job. A practical approach includes:

• Rate limiting and blocking – At the firewall or WAF level, limit how many requests a single IP can make in a short window. When an address or subnet hammers product URLs at inhuman speed, it is blocked, not indulged.
• Respecting good crawlers only – Known search engine bots are allowed through (and even whitelisted where appropriate), but anonymous scrapers, “SEO tools” and generic data centres are treated with suspicion until they prove otherwise.
• Watching logs, not dashboards – Regular reviews of access logs reveal patterns no plugin report will show you: repeat offenders, odd user agents, and sudden spikes on specific endpoints.

This is not paranoia; it is resource management. When you are synchronising 34,000 products via WooCommerce product feeds, you want your CPU time and database capacity going into legitimate customers and feed processing – not into serving the same category page to the same scraper 500 times an hour. Every bad bot you stop at the perimeter is one less process competing with your importer for resources.

The side effect is better resilience. If a supplier’s API runs slowly for a few minutes or a sync job takes longer than usual, the VPS has enough headroom to cope. You are not operating on the edge of collapse because half your CPUs are tied up answering pointless requests from servers that will never place an order. In that sense, good security is not a separate project from feed management; it is one of the reasons the feeds can run reliably at all.

Putting It All Together: Engineering WooCommerce Product Feeds

By this point, it should be clear that running serious WooCommerce product feeds is not a case of “install a feed plugin and hope for the best”. When your catalogue is being driven by a live distributor API and you are carrying something like 34,000 products across two sites, you are doing systems engineering as much as e-commerce.

The ingredients are straightforward enough on paper: one source of truth, SKUs treated as sacred, a clear split between heavy product syncs and lightweight price/stock updates, disciplined handling of discontinued items, real database hygiene, aggressive but sensible image optimisation, caching that understands WooCommerce, and firm bot control at the edge of the network. None of these ideas is spectacular on its own. The value comes from applying all of them, consistently, over time.

The reward is a store that behaves like a normal WooCommerce site from the customer’s point of view, even though under the hood it is being driven by large inbound WooCommerce product feeds. Pages load quickly. Prices and stock levels are accurate. Discontinued products quietly vanish instead of cluttering the catalogue. The VPS runs comfortably within its limits rather than bouncing off them every time a cron job fires.

If you are already wrestling with supplier integrations, or you are thinking about wiring WooCommerce into a large external catalogue, you do not have to learn all of this the hard way. This is exactly the ground I work on every day: designing and running WooCommerce product feeds that scale, without sacrificing speed or stability. If you would like your store to benefit from the same level of care, this is the point where you get in touch and we talk about your catalogue, your server, and what “fast and sane” would look like for you.