A page for every part, without a content team

A parts catalogue is a relationship between products, machines and information from suppliers. Writing a longer description for every record does not solve that relationship. The useful work is making the underlying data dependable enough that a customer can choose with confidence.

That changes the content brief. Begin with identifiers, sources and review decisions, then design pages around them. The same record may need to support a product page, a fitment result and a shopping feed. A correction should reach all of those places without someone pasting it repeatedly.

Make the source traceable

Keep the supplier’s product identifier alongside your own. Record which import supplied a value and when it arrived. A price or fitment change is easier to investigate when the team can identify its origin rather than compare two screenshots and guess which one is newer.

Decide which source owns each field. A supplier might own stock status, while your team owns editorial descriptions or photography. Define what happens when a new import arrives. It should update the fields it owns and preserve deliberate human changes elsewhere.

Do not start with the cleanest sample alone. Include variants, duplicate identifiers, discontinued items and missing values. A small set of difficult records is more revealing than a large file that happens to load. It shows whether the system can stop and explain a problem.

Treat fitment as evidence

A buyer usually starts with a machine and a job. They need to know whether a part applies to their model, year and relevant variant. Give them a route from that information to suitable records, while showing the assumptions or exclusions that matter to the choice.

Keep fitment relationships separate from sales copy. A generated paragraph must not expand compatibility beyond the source. If a supplier gives a limited range, retain that boundary. If two records conflict, flag the conflict instead of asking a language model to choose the more convincing answer.

Useful pages can bring together diagrams, part numbers and the customer’s selected bike. The Iron Stable case describes OEM diagram lookup, VIN decoding and saved bikes. Those are features of that project; another store needs its own data and feature scope.

Build page types around customer questions

A product page answers “What is this, does it fit, and can I buy it?” A model page helps someone find the relevant family of parts. A category page helps compare choices. A brand or size page can be useful where it matches the catalogue and a real shopping task.

Avoid producing combinations merely because the database allows them. An empty page or a page with no distinct information adds work for the reader and the editor. Decide which combinations should exist, which should point elsewhere and which should remain out of public navigation.

Use a consistent product identity across the website and external product data. Google explains the roles of structured data and Merchant Center feeds in its product data guidance. These are ways to describe an offer, not substitutes for maintaining accurate price and availability.

Give generated content a narrow job

Provide the generator with approved fields and a clear task: explain the supplied product without inventing fitment, performance, certification or availability. Missing information should stay missing until a person resolves it. A fluent sentence cannot repair an absent specification.

Review the output in the context of the page. Does it repeat the title without helping? Does it turn a manufacturer’s qualified statement into an absolute promise? Does it confuse a pack quantity with a unit price? These are editorial checks as much as technical ones.

Keep the draft, reviewer decision and published version distinguishable. That makes it possible to correct a faulty instruction across affected pages. Google’s guidance on generative content puts usefulness and accuracy ahead of producing volume. Treat generation as one stage in a publishing process.

Protect the commercial data

Define pricing rules explicitly, including the inputs they use and who can change them. A suspicious supplier value should pause an update or raise an alert according to an agreed rule. Describe that behaviour in the specification rather than relying on a reassuring label such as “automated pricing”.

Test changes in currency, quantity and availability using sample records. Check the displayed price, basket and any outgoing feed together. The important question is whether they represent the same offer after an update, including when the import is incomplete or late.

This is also where ownership matters. Someone needs to know about a rejected feed and be able to inspect it. Automation that quietly stops can become stale stock; automation that always continues can publish bad data. The operating team should understand which behaviour has been chosen.

Scale the process after proving it

Begin with a representative part of the catalogue and run more than the initial import. Make changes, review drafts, remove records and inspect the customer journey. Confirm that corrections survive the next update. Record how the team restores the last known good version.

Then expand by a meaningful slice, such as a supplier or category. Watch the number and type of exceptions, not just the number of pages created. A growing queue of unresolved fitment issues is a sign to improve the inputs before adding more output.

Our parts ecommerce offer connects catalogue work with the storefront. The content service covers the editorial side. The starting question for both is the same: what reliable information do you already have, and what decisions still need a person?

Questions

Should every supplier record become a page?

No. Publish records that describe a real, supported offer. Hold incomplete or contradictory records for review, and decide how discontinued products should be handled.

Can AI decide whether a part fits?

Fitment should come from an identified data source. AI can help explain that data, but a plausible sentence is not evidence of compatibility.

Where should a catalogue project begin?

Start with a representative sample covering normal products, variants, missing fields and awkward fitment. Prove the import, review and update process before expanding it.