Record what a product fits

The goal: stop a reply saying “we don’t sell that” about something you do sell. A product’s title is not a list of what it fits. A shop files a skid plate under KTM 690 MY19-24; the title just says “Skid plate 690”. Search the title for “KTM 690 MY26” and you get nothing, and nothing reads exactly like we don’t stock it.

Tag groups put that fact somewhere a flow can actually read.

What a tag group is

A tag group is a namespace and a value. The namespace is the kind of statement; the value is the statement.

Namespace	Value	Reads as
fits	KTM 690 MY26	this product fits that machine
manufacturer	KTM	this product is made by KTM
model_year	2026	an attribute the shop publishes

Tag groups ride the same tag spine as automation tags, so a plain, un-namespaced tag is just a tag group with an empty namespace. Nothing about existing tags changes.

One value names one whole thing

This is the rule that matters, and it is easy to get wrong.

A machine is make + model + model year, together, in one value — KTM 690 MY26, Husqvarna 701 MY16-24, CFMOTO 450MT-R/X.

The tempting alternative is three separate tag groups: model: 690, year: 2024, year: 2026. Don’t. A product carrying model: 690, model: 701, year: 2018 and year: 2026 says nothing about which combinations actually fit — recombining them invents fitment nobody ever asserted, and the invented rows look exactly like the real ones.

Routario still reads make, model and years back out of the value, for column headings, grouping and “what fits a 2019 KTM?”. Reading is free. Writing a split is lossy.

One product fits many machines

Fitment is many-to-many — one skid plate fits four ranges — which is why it is a tag group and not a category. A category tree gives a product one parent; it cannot express this. A tree is still fine for browsing.

Two layers, and why they never mix

Tag groups come from two places and they are kept in separate rows:

• From a connected shop. A read-only mirror. Every sync replaces it wholesale.
• Set here. The gaps a person fills. A sync never reads or touches these.

What a product carries is the union. Because they are separate rows, a shop sync is safe to run on a schedule and can never eat a correction someone made by hand. That is the whole reason for the split.

The matrix shows which is which, and they are deliberately not the same mark:

Cell	Means
Filled green square	someone here said it applies
Grey outline circle	the shop says it applies
Dash	someone here said it does not apply
Red dot	someone here said it does not apply, and the shop says it does

That last one is a disagreement, and it is never resolved automatically. A silent resolution either way is a reversal nobody notices — worse than a visible disagreement — so it is listed at the top of the page for a person to settle.

Filling the gaps

Open Catalog → Tags.

1. Pick the tag group from the tab strip. The one marked fitment is what “what does this fit?” reads.
2. Click a cell to cycle it: nothing → applies → does not apply → nothing. It saves as you click; there is no Save button.
3. Columns are grouped by make. Collapse a group you are not working on — it shrinks to a single column showing how many of its values each product carries.
4. Use Still to review to see what is left. Mark a row reviewed when you have looked at it — including when the answer is “nothing to add”, which is a real and common answer that no inferred flag can express.

Clicking a cell the shop asserts records a disagreement rather than re-asserting what is already true. Click again to withdraw it.

Pulling the shop’s own filing in

Add a Sync catalogue from shop step to a scheduled flow. It reads every published product and writes its categories — and optionally its attributes — into the shop’s layer.

Namespaces come from the container the term came from upstream: a child of a “Bikes” category becomes bikes, a top-level category becomes product_category, an attribute becomes its own name.

The sync never fills the fitment tag group. Most shops keep one flat category list with machine ranges and merchandising terms side by side — KTM 690 MY26 next to Spare Parts and Navigation — and nothing in that list says which is which. Name-parsing looks like it would sort them and does not: Spare Parts has exactly the shape of CFMOTO 450MT-R/X. So the mirror records only what the shop actually says — this product is filed under this term — and which terms name a machine stays a judgement you make, in the matrix.

In practice: run the sync, then work down the product_category tag group and set the fitment values for the ranges you recognise. That is a one-time pass, and after it the shop keeps its own terms up to date while your fitment stays yours.

Products are matched on the shop’s product id, never the SKU — plenty of real products have no SKU at all. A first run adopts existing rows by an exact, unambiguous SKU match and stamps the id onto them, so a catalogue you built by hand converges instead of doubling.

Read the removals

The step reports what the shop stopped saying, and which linked products the shop no longer returns. Neither is resolved automatically, and neither is archived on that evidence alone. A product quietly losing its fitment because someone reorganised the shop is exactly the change that goes unnoticed — so it is reported, and left for a person.

Attributes are off by default

A shop’s product attributes can be imported as tag groups too, but the switch is off, and that is from measurement rather than caution. On a real shop it added 13 tag groups on top of the one worth having — and four of them (model, model_year, manufacturer, production_year) read exactly like fitment while holding free text: “690 MY19-24 / GASGAS MY22-24”, “702Pro (universal)”, “21-24US”.

They are the split-apart form and cannot say which combination fits. Turn them on when a shop’s attributes are genuinely worth filtering by; they then arrive prefixed attr. — attr.model, not model — so a tag group list never shows them as peers of one you curated.

Fitment answers “does it fit” — not “do you still sell it”

Those are two questions, and a reply usually needs both. A skid plate can fit a customer’s bike perfectly and still be something you stopped making in 2019.

So the shop sync also mirrors an availability tag group — available, temporarily_unavailable or discontinued — and Look up a catalogue item returns it on every match, beside the fitment. It comes from the shop’s own stock state, read through the convention you declare when connecting the shop (see Step 1b).

It sits in the shop layer, not yours, because whether something is still sold is a fact the shop states rather than a judgement you record — so a sync replaces it wholesale, exactly like the shop’s categories, and it never touches the fitment you set by hand.

No tag group at all means the shop never said

Until you declare that convention, no availability value is written — the tag group is simply absent, and the lookup reports unknown.

An absent group is the honest answer, and it is deliberately not the same as available. Writing unknown onto every product would fill the matrix with rows that look curated while saying nothing.

Where it shows up

• Catalog → Tags — the matrix, and the disagreements to settle.
• The fitment tag group is what a reply should quote for “what does this fit?”.
• Look up a catalogue item returns fits, fitment_reviewed and availability together — enough for a reply to say what fits, whether anyone checked, and whether you still sell it.
• List WooCommerce categories answers the same question from the shop’s side; see Answer order and stock questions from your WooCommerce shop.