PLATFORM
Skuply for Magento
Connected through the REST API of Magento or Adobe Commerce, no extension inside your installation. And above all: we write values as attribute options, because only then does layered navigation do anything.
CONNECTING TAKES ABOUT HALF AN HOUR ON YOUR SIDE
THE PITFALL
The value is there, and navigation does not see it.
In Magento the attribute type decides whether a value is usable. A text field is invisible to layered navigation; only a dropdown or multiselect with real options does anything there.
Text attribute
Free text on the product. It sits on the page, but layered navigation cannot filter on it and the value cannot be normalised across the catalogue.
material = "full-grain leather" (text)
NO LAYERED NAVIGATION
Attribute with options
A dropdown or multiselect with fixed options, in the right attribute set and switched on for layered navigation. This is what filters.
material = option:1042 (select)
FILTERABLE AND FACETABLE
We create the missing options, attach the attribute to the right attribute sets and switch on use in layered navigation. Existing options we reuse, so no duplicate values appear.
THE CONNECTION
An integration token, not an extension.
You create an integration with read access to the catalogue and write access to products and attributes. We install nothing in app/code, so a Magento upgrade does not touch us.
What we read
Products, attributes, attribute sets, categories, media and the existing descriptions.
What we write
Attribute values and options, titles, descriptions, alt text and our own skuply fields.
What we cannot reach
Orders, customers, price rules and system settings. We do not request those permissions.
WHAT FILLS UP INSIDE MAGENTO
material
select, existing option
size
read only, we do not fill size
en_norm
read only, we do not create new options
name
read only, never written
description
read only, never written
media_gallery.label
alt text from the product title and the colour
skuply_meta
source, timestamp and confidence
Which attributes already exist and which attribute sets they hang in, we work out on day one.
TWO MEASUREMENTS THAT LIE
In Magento an empty field looks full.
Measure a Magento catalogue for empty fields and the score comes out far too high. Two things Magento does itself cause that, and we measured both on live shops before writing a rule for either.
Alt text defaults to the filename
Magento fills media_gallery.label automatically with the name of the uploaded file. The field is therefore never empty and counts as filled in any tally, while in practice not one image is described. That is exactly why alt text is the field we fill on Magento: it holds the largest real gap.
Modules park their settings on the product
Third-party extensions store their own configuration as product attributes, with prefixes like activeants_, am_ and amxnotif_. Count those and a catalogue looks rich in data while the fields a customer actually uses are empty. We filter them out before measuring anything.
And a practical one: the GraphQL API returns fifty products per call. Reading a catalogue of 3,346 products took 133 seconds. That is fine in a background pass and impossible inside a web page, so our first full pass over a large catalogue is an overnight job and everything after it is incremental.
EXPLORE ALL CMS
Skuply runs on the other two as well.
WooCommerce
The difference between a global and a custom attribute, and why your filter stands or falls on it.
READ ON
Shopify
Without a definition a metafield does nothing. We create it before the value exists.
READ ON
BigCommerce
No open product list, so the key comes first. And custom fields named differently on every product never become one field.
READ ON
Shopware
The filter runs on properties, not on custom fields. We fill the first, even though the second is easier.
READ ON
Another platform
If your shop runs on something else with an API, that is a conversation and not a no. Tell us what it is.
PUT IT TO US
QUESTIONS ABOUT MAGENTO
What Magento admins always ask.
Will it slow our site down?
No. No extension is added and we write in batches. After writing we trigger only the indexers that genuinely need it.
Will our theme keep working?
Yes. We touch no templates. Where your theme displays a custom attribute, we mirror the value there as well.
We have several store views.
Then we fill per store view. Values on global scope stay global, values on store scope get their own normalised term per view.
We have configurable products.
Attributes that serve as a configurable axis go on the exclusion list. We stay away from those, otherwise your variants break.
Does this work with Adobe Commerce?
Yes, and with Magento Open Source from 2.3 onwards. Below that the REST API is too limited and updating is the first step.