Distributors and manufacturers: why your online catalogue is unmanageable
If your online catalogue is never up to date, your website is not the cause. The truth about your products lives in your management system and in spreadsheets, not on your website. Until that data is structured, no redesign will fix the problem.
- The blocker is almost never the platform. It is in the product data: its attributes, units and variants.
- Five maturity levels separate the shared spreadsheet from the single source of truth. Each level allows certain things and blocks others.
- Google will not serve any ad or free listing for a product missing its variant attribute, the characteristic such as colour or size that distinguishes a variant from the parent product. Missing data directly costs you paid visibility.
- Manually maintaining a catalogue of 3,000 SKUs takes about 200 hours a year, or $7,600 of time that never appears on an invoice.
- A redesign ordered before the product data is fixed gets paid for twice: once now, once again in three years.
On this page
What is product data maturity
Product data maturity is the degree of structure and centralization in the information describing your items: attributes, units, variants, prices, availability, technical documents. It is measured on five levels, from the shared spreadsheet to the single source of truth that feeds the website, ad feeds and quotes simultaneously. It is this, not the platform chosen, that determines what an online catalogue can do and what it costs to maintain.
The website is never the cause
This piece is written for distributors, manufacturers and companies whose catalogue exceeds a few hundred SKUs and lives first in an internal management system. If you sell twelve products, the question does not apply to you.
The pattern repeats. A company puts its catalogue online, finds eighteen months later that half the listings are outdated, concludes the platform is bad, and orders a redesign. Three years later, same finding, different platform, same conclusion.
The platform was never the problem. The problem is that nobody ever decided where a product's truth lives. The price sits in the management system, the description in a spreadsheet, the spec sheet in a PDF the manufacturer sent, the photo in a shared folder, and availability in the shipping clerk's head. A website cannot stay up to date when no source exists for it to synchronize with.
A redesign ordered before the product data is fixed gets paid for twice. The first time now, the second in three years when the same finding comes back. It is the most frequent, and most avoidable, expense in business-to-business ecommerce.
The five maturity levels
| Level | Where the data lives | What it allows | What it blocks |
|---|---|---|---|
| 1. The spreadsheet | One or more files, updated by hand | A static catalogue of a few hundred SKUs | Any automation, any reliable ad feed |
| 2. The one-off export | The management system exports, someone imports | A periodic update of prices and availability | Real time, and customer trust in the availability shown |
| 3. One-way synchronization | The system feeds the website automatically | Accurate prices and stock, a catalogue that is alive | Fine-grained filtering, search by characteristic, a complete Shopping feed |
| 4. The structured single source | Normalized attributes, units, variants, one single record | Filters, search by characteristic, ad feed, structured data | Nothing significant for most companies |
| 5. Activatable data | The same source feeds the website, feeds, quotes and spec sheets | Generated sales documents, listings answer engines can read | Nothing, but the level demands a discipline few organizations sustain |
Most Quebec distribution companies sit between level 1 and level 2, while buying projects that assume level 4. That gap between the actual level and the targeted level explains most failed projects.
Where your catalogue's truth actually lives
The question to ask in a meeting is not "which platform should we choose," but "for each piece of information, which system is authoritative." Take eight lines and answer them.
List price and account-specific pricing. Almost always the management system. It is the one point where the answer is clear for most companies.
Availability. Theoretically the management system, in practice often corrected by hand because nobody trusts the number.
Technical characteristics. Generally nowhere, or in a PDF from the manufacturer. It is the most costly gap.
Units and conversions. Rarely normalized. The same attribute exists in inches and in millimetres depending on the original supplier.
Variants and their relationship to the parent product. Almost never modelled, which blocks both filtering and ad delivery.
Cross-references to competitors' SKUs. In the sales reps' heads, which makes it an asset the company loses with every departure.
A serious project starts with these six answers, not with a mockup. They are gathered in two or three meetings with sales, estimating and shipping, and they determine the real budget far more than the choice of platform.
What manual upkeep costs
The cost already exists, it simply never appears on an invoice. Put a number on it once and the discussion changes.
Take a catalogue of 3,000 SKUs. Four minutes of handling per SKU for one annual review of prices, descriptions and availability adds up to 200 hours. At $38 an hour, that is $7,600 a year, assuming a single review. Two reviews double the amount.
This figure is an explicit scenario, to be redone with your own volumes. Compare that amount, repeated every year, against a one-time investment in structuring the data. Over three years, the trade-off is rarely close.
On top of that direct cost sits a visibility cost. Google states that no ad or free listing can be served for a product whose variant attribute is missing. In other words, missing data pulls products off the shelf you are also paying to advertise.
Why a redesign fixes nothing
A redesign changes the display. It changes neither the source of the data, nor its structure, nor the person who updates it. If those three things stay the same, the new website will degrade exactly like the old one, at the same pace.
The question asked in an RFP reveals the real project, without detour. A company that asks "how much does a new website for our catalogue cost" will buy a display. A company that asks "how much does it cost to keep our catalogue accurate without manual intervention" will buy a solution to its real problem. The two projects carry the same name and do not carry the same price, because they do not do the same work.
That does not mean everything must be structured before touching the website. It means the budget must be split between the two, and the share devoted to the data is almost always underestimated in the proposals you receive.
Where to start without redoing everything
The progression that works moves from one level to the next, never straight from 1 to 4.
Start with one product family, the most profitable or the most viewed. Normalize its attributes and units, model its variants, and have it fed by a single source. Then measure three things on that family: update time, the outdated-listing rate, and the volume of inquiries received.
This approach has a political advantage worth as much as its technical one. It produces a measured result in three months, which secures the budget for the rollout far better than a three-year plan presented in a meeting.
Two mistakes to avoid along the way. Buying a product information management tool before deciding who enters what, which reproduces the problem in more expensive software. And handing attribute normalization to an outside vendor without an internal person owning it, which guarantees drift as soon as the engagement ends.
The most immediate effect of complete product data shows up in internal search, where an engine can only filter what is structured.
What to settle before ordering a catalogue website
These questions determine the project's real budget, often by a factor of two or three. Answering them after signing means discovering the cost once you are already committed.
- For each of your six product data points, which system is authoritative today?
- How many hours a year do you spend on manual catalogue upkeep, and at what rate?
- How many of your SKUs have no technical characteristic structured anywhere but in a PDF?
- Who, internally, will own product data after the project?
- If the outdated-listing rate has not dropped in twelve months, what gets stopped, and who makes that call?
The answer that holds up names one system per data point and one accountable person. A weak answer talks about migration and synchronization. A vendor who proposes a platform without having asked where your data lives is selling a display, not a catalogue.
Establishing your actual level and putting a number on the gap with what you want to do is exactly what a paid audit delivers.
What stays with you: the decision on which system is authoritative for each data point, the person responsible for the data after the project, and the cross-references to competitors' SKUs that only your reps know. What gets delegated: normalizing attributes and units, modelling variants, building the feeds and tracking the outdated-listing rate. A company that names an internal owner holds its level. A company that names none drops a level every year, regardless of how much it invested at the start.
The overall view of website design is in the architecture choice behind a site.
Turning a catalogue into an asset that sells rather than a display case to maintain is at the heart of the Improve your site's conversion goal.
Your catalogue is heavy and the question plays out across tens of thousands of SKUs? See our work in ecommerce.
Frequently asked questions about product data
Should you buy a product information management tool?
Not before deciding who enters what and which system is authoritative. A tool bought before that decision reproduces the disorder in more expensive software, and many sit empty. For a catalogue under 5,000 SKUs, a structured database inside your existing management system is often enough to reach level 4.
My management system is old, is that a blocker?
Rarely as much as feared. Most systems already in place can export reliably, and that is most of the work. What actually blocks you is the absence of structured attributes, not the age of the software. Replacing the system before normalizing the data just means moving a mess.
How long does structuring a catalogue take?
The timeline depends on the number of attributes to normalize and the state of your sources, not the number of SKUs. Three thousand products sharing twenty well-defined attributes get handled faster than three hundred products each with their own fields. Start by counting your attributes, not your SKUs.
Can you sell online at level 2?
Yes, with limits you need to accept upfront. Customers will see accurate prices and approximate availability, without fine-grained filtering or search by characteristic. That is viable on a small catalogue and with a customer base that already knows your products. It is not viable for acquiring new customers on a large catalogue.
Who should own product data at our company?
One person, named, with time set aside. The most common department is product marketing or purchasing, rarely IT, because product data is a business decision before it is a technical issue. A project with no named owner loses one maturity level a year.
What about cross-references to competitors' SKUs?
It is the most valuable and least protected asset you have. It lives in your reps' memory and leaves with them. Structuring it is a long job, but every cross-reference entered becomes a page a buyer finds while searching for a competitor's part number. Few Quebec catalogues have done it.
- Google Merchant Center, help centre, Product data specification, official documentation, accessed July 2026. Source for the requirement on the variant attribute.
- Google Merchant Center, help centre, Supported attributes and values for structured data, official documentation, accessed July 2026.
- Falia working framework, arithmetic for the cost of manually maintaining a catalogue. The amounts are explicit scenarios, to be redone with your own volumes and rates.
Geneviève puts the strategy for your engagement into action. She leads all our web development projects: Shopify, WordPress and the new ways of building a site with AI. She manages our team of developers and translates your business needs into technical language. She runs your organic search (SEO), your visibility in AI answers (GEO) and your site's conversion rate optimization (CRO). Her work is at the heart of three goals: Attract customers with SEO and AI, Improve your site's conversion, and Strengthen your visibility in AI answers. With Gabriel, she also builds the landing pages for your advertising campaigns. She writes mainly about SEO, AI visibility and web design.
About Falia →
SEO
Paid advertising
Conversion
AI visibility
Web design