Attributes vs. categories (WooCommerce)
WooCommerce kent drie taxonomische systemen: Categories, attributes en tags. In dit artikel worden deze eerste twee taxonomische systemen met elkaar vergeleken. Tags worden hier niet verder behandeld.
Categories staat ook bekend onder de namen:
- Categorieën
- product_cat
en Attributes staat ook bekend onder de namen
- Attributen
- Kenmerken.
Inhoudelijke verschillen
| Categorieën | Attributen | |
|---|---|---|
| Taxon-pagina | Taxons hebben eigen pagina's, dus met eigen URL's. Dit is cruciaal voor SEO | Taxons hebben geen eigen pagina's: taxons wordt gecodeerd als parameters in de URL. Dat is killing voor SEO - Waar relevant (het is niet altijd relevant!) |
| Meerdere taxonomieën | Niet mogelijk. Je hebt altijd maar één taxonomie. Er zijn truken om deze beperking te omzeilen, maar het is daadwerkelijk een beperking waar ik vaak mee te maken heb | Geen probleem: Zoveel taxonomieën als je maar wilt. Ze kunnen alleen niet hiërarchisch zijn. |
| SEO | Geschikt voor SEO:
|
Niet geschikt voor SEO |
| Additionele content | Omdat taxons hun eigen pagina hebben, is het geen probleem om daar additionele content aan te voegen, bv. middels maatwerkvelden en aanpassingen in thema's | Beschikbaar, maar het lijkt me ingewikkeld om daar gebruik van te maken, omdat shoppagina's al geassocieerd zijn met catalog-taxons. Dus wat te doen met deze additionele filter-content? |
| Hiërarchie | Geen probleem. Er kan echter maar één catalog-taxonomie zijn, en dat ervaar ik vaak als een onhandige beperking | Zijn niet-hiërarchisch. Je kunt meerdere hoofdtaxons defineren (bv. lengte, breedte & hoogte) en per hoofdtaxon meerdere taxons defineren. Maar geen additionele lagen. In de praktijk is dit zelden een probleem: Ik heb zelden met een hiërarchie te maken met meer dan 1 of 2 lagen. |
| Rekenkracht - Laadtijd shoppagina |
|
|
| Filter-weergave shoppagina |
Categorie-filters:
|
Attribute-filters: Styling is flexibel. Je kunt elk filter als een aparte widget plaatsen |
Analogie van een warenhuis
Dit voorbeeld benadert het verschil tussen attributes en categorieen als volgt aan de hand van een voorbeeld van het kopen van een spijkerbroek bij (in mijn geval) C&A:
- Categorieen: Herenkleding » Vrije tijd » Spijkerbroeken
- Attributes: merk, maat, stijl, etc.
Ik kan er niets mee
Klinkt intuïtief, maar in de praktijk kan ik hier niets mee.
Het wordt nog erger
Sterker nog (2023.09 - twee jaar later): Deze analogie zuigt: product_cat-taxonomieën zijn niet flexibel, vanwege de hiërarchie. Daarom zou je product_cat bij voorkeur alleen moeten toepassen op eigenschappen die er altijd zijn, die altijd bekend zijn, en die niet veranderen. Bv. leverancier (kan veranderen!) of materiaal.
Een taxonomische hiërarchie zoals hierboven genoemd, wordt dan snel problematisch, c.q., arbitrair. Bv.:
- Zijn er ook zakelijke spijkerbroeken? Is er overlap tussen vrije tijd » spijkerbroeken en zakelijk » spijkerbroeken?
- Is het überhaupt gewenst dat om een spijkerbroek te kiezen, je eerst moet bepalen of deze voor vrije tijd of voor werk is bedoeld? - Dat is het echte probleem waar ik tegenaanloop als een hiërarchische taxonomie niet werkt: Je kunt de eerste laag niet overslaan
- Vermoedelijk een klassiek probleem: witte t-shirts: Ze zijn zowel voor mannen als vrouwen geschikt en zowel voor vrije tijd, werk, sporten feestelijk
- Dit probleem valt nog mee, omdat het hier om maar een paar vaste categorieën gaat. In de praktijk kan het veel complexer worden, omdat je niet weet wat voor taxons er allemaal op de eerste laag zijn. Als je daar bv. merk moet kiezen en pas op de tweede laag soort apparaat, en je hebt geen idee wat je merk is, dan zit je vast.
* Herenkleding
* Vrije tijd
* Spijkerbroeken
* Pantalons?
* Sokken?
* Onderbroeken?
* Werk
* Spijkerbroeken?
* Pantalons
* Sokken?
* Sport
* Sokken?
* Feestelijk
* Dameskleding
* Vrije tijd
* Werk
* Kinderkleding
Voorbeeld warenhuis-taxonomie
Het probleem met hiërarchie
Catalog-taxonomieën zijn hiërarchisch en dat kan een onoverkomelijk probleem zijn. Althans, onoverkomelijk met alleen de catalog-taxonomieën.
Voorbeeld (2021-2023):
- Een bedrijf verkoopt onderdelen voor boegschroeven
- product_cat-taxonomie: Merk » Apparaat
- Voor deze boegschroeven is er geen merk bekend - En dat maakt dit probleem veel lastiger dan het stomme eerdere voorbeeld van een warenhuis: Bezoekers weten niet wat ze moeten 'gokken' als eerste taxon. Dan maar 'alle' merken boekschroeven invoeren? Misschien is dit wel een markt, waar het niet om merk gaat, omdat alles maatwerk is?
Meerdere catalog-taxonomieën?
Een WooCommerce-site kent maar één Categorie-taxonomie. Dat kan knap onhandig zijn, bijvoorbeeld als meer dan één manier is om door een hiërarchie te lopen. Er zijn echter manieren om deze beperking te omzeilen. In de volgende hoofdstukken worden deze manieren besproken.
Voorbeeld-taxonomie
Deze taxonomie met 12 taxons is het uitgangspunt:
product_cat / | \ B G R /|\ /|\ /|\ N D L N D L N D L
Het is een simpele hiërarchische taxonomie, voor het indelen van fietsen naar kleur en land:
- In de eerst stap kies je een kleur (blauw, groen of rood)
- In de tweede stap kies je een land.
Het verschil tussen taxons en elementen vind ik vaak verwarrend. Daarom voor de volledigheid een paar elementen die middels deze taxonomie zouden kunnen worden ingedeeld:
- Gz-tB: Gazelle tourfiets, blauw
- Gz-tR: Gazelle tourfiets, rood
- Gz-rB: Gazelle racefiets, blauw
- Gz-rR: Gazelle racefiets, rood
- Gz-rG: Gazelle racefiets, groen
- Lx-cB: LuxBike Crossbike, blauw
- Lx-cG: LuxBike Crossbike, groen
- Lx-mB: LuxBike mountain bike, blauw
- Lx-mR: LuxBike mountain bike, rood
- Kh-RB: Kalkhoff Racebike, blauw
- Kh-RG: Kalkhoff Racebike, groen
- Kh-CB: Kalkhoff City bike, blauw
- Kh-CG: Kalkhoff City bike, groen
- Kh-CR: Kalkhoff City bike, rood
Beperking: Eén richting
Deze taxonomie heeft precies de beperking die aan het begin van dit hoofdstuk genoemd wordt: Je kunt maar in één richting zoeken. Namelijk eerst kleur en daarna land. Als blijkt dat bezoekers ook andersom willen zoeken (dus eerst land en daarna kleur), heb je een probleem. Tot op heden (half 2021) loste ik dat meestal op door attribuut-taxons te defineren voor land.
Twee taxomomieën verbinden met een tussen-taxon
Dit is de eerste manier om de beperking van één catalog-taxonomie te omzeilen: Twee taxonomieën verbinden met een tussentaxon. Dit heb ik nog nooit toegepast.
Dit is een voorbeeld waarbij een hiërarchie in 'beide richtingen' is geïmplementeerd middels een tussentaxon:
product_cat
/ \
/ \
kleur Land ← Tussentaxon-laag
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
B G R NL DE LX
/|\ /|\ /|\ /|\ /|\ /|\
N D L N D L N D L B G R B G R B G R
Voorbeelden van URL's:
- example.com/k/blauw
- example.com/k/geel
- example.com/l/nl
- example.com/l/nl/blauw
- example.com/k/blauw/nl
Nadelen:
- Tussentaxons maken URL's langer
- Redundantie: Bij elkaar zijn er nu 26 taxons
- Verwarring: Alle taxons (muv. de tussentaxons) komen twee keer voor. Dat is verwarrend. In de taxonomie van Linnaeus heeft elke taxon een unieke naam, zodat je altijd weet waar je bent in de boom. Hier is dat niet het geval: Taxon Blauw komt op twee plekken voor, en heeft steeds dezelfde naam. Gelukkig zijn de URL's wel verschillend, en dat kan helpen om ze te onderscheiden.
Heterogene taxonomie
Dit is de tweede manier om de beperking van één categorie-taxonomie te omzeilen: Plak ze over elkaar heen.
Voorbeeld:
p r o d u c t _ c a t
/ / | | \ \
/ / | | \ \
/ / | | \ \
/ / | | \ \
/ / | | \ \
Blauw Geel Rood NL DE LX
/ | \ / | \ / | \ /|\ /|\ /|\
NL DE LX NL DE LX NL DE LX B G R B G R B G R
Intuïtief misschien vreemd, maar in de praktijk mogelijk goed te doen. In aug. 2021 kwam ik dit tegen bij KNL: Merken en device_kind door elkaar.
Voordeel: Paden zijn niet onnodig lang, itt. gebruik tussen-taxon.
Nadelen:
- Redundantie: Er zijn nu 24 taxons
- Verwarring: Net als in de situatie hiervoor, komen alle taxon-namen twee keer voor.
Heterogene taxonomie met redirects
Het staat me bij, dat je in product_cat-taxonomieën, zoiets als redirects, synoniemen, thesurus of pointers hebt, waarmee je taxons kunt laten verwijzen naar andere taxons.
p r o d u c t _ c a t
/ / | | \ \
/ / | | \ \
/ / | | \ \
/ / | | \ \
Blauw Geel Rood NL DE LX
/ | \ / | \ / | \ / | \ / | \ / | \
NL DE LX NL DE LX NL DE LX B* G* R* B* G* R* B* G* R*
Maw.: Blauw → NL is hetzelfde als NL → Blauw. Vandaar dat in de tweede situatie, je eindigt in de eerste boom.
Helaas heb ik deze functionaliteit tot op heden (aug. 2021) niet kunnen terugvinden.
Zware shoppagina's, landing pages & alternatieven
- Rondom werken met Categories en Attributes, is de essentie misschien wel: Vermijd zware shoppagina's. In de webwinkels waaraan ik werk sinds ca. 2019, is dit een terugkerend probleem
- Taxonpagina's zijn niet alleen relevant voor ontsluiting van data, maar tevens als landing pages. In dat opzicht schieten catalog-pagina's enigszins tekort
- Er is een additionele manier om content & landing pages te verzorgen: Doorverwijspagina's of voor mij in de praktijk: buttonbar-pagina's (ze maken gebruik van een maatwerk-widget genaamd buttonbar waarmee we grafische wizards bouwen.
Evaluatie: Attributes vs. categories - 2021.08
Tot half 2020 dacht ik dat Categorieën veelzijd en zwaar waren, en Attributes licht en beperkt waren. Dat blijkt tegen te vallen:
- Op het moment dat je Categorieën gebruikt voor shoppagina's (dus dat er URL's zijn zoais example.com/shop/merk-a, example.com/shop/merk-b, etc.), vormen ze geen enkele belasting voor een server
- Op het moment dat je Categorieën gebruikt voor filter-dropdown-boxes, krijg je verbazend snel een performance-probleem
- Op het moment dat je Attributes gebruikt voor filter-dropdown-boxes, krijg je ook verbazend snel een performance-probleem.
Aanbevelingen:
- Gebruik als het even kan, geen categorie-filters op shoppagina's
- Waarschijnlijk handig om een zo uitgebreide catalog-taxonomie te gebruiken, zodat gebruikers uiteindelijk op shoppagina's belanden met maar weinig keuze en dus weinig attribuut-filters.
- Gebruik zo min mogelijk Attribute-filters, en vooral niet met veel content (dus geen dropdown-boxes met honderden waardes)
- Categorie-pagina's zijn vermoedelijk onmisbaar voor SEO.
Voorbeeld: Laadtijd & product_cat
Tests https://koolborstels.nl/shop - 2023.09:
| Configuratie | Laadtijd |
|---|---|
| product_cat: Niet-hiërarchisch | 59,2s; 12,3s; 22,4s; 9,83s |
| product_cat: Hiërarchisch | 13,5s; 8,39s; 11,9s |
| Zonder product_cat-widget | 8,10s; 9,31s; 9,46s; 12,3s |
Conclusie: Dit kan ik niet meten op deze manier (met een Chrome extension). Ik kan het helaas niet meten met Google PageSpeed, want daar krijg ik timeout-foutmeldingen.
Hogere lagen van product_cat worden altijd gedupliceerd in attributes
Het probleem met product_cat-taxons wordt nog vervelender. Voorbeeld:
- Het eerdere voorbeeld van onderdelen voor machines
- product_cat:
Merk » Apparaat - Op de website wil je faciliteren dat bezoekers ook kunnen zoeken op alleen Apparaat
- Dat is onmogelijk mbv. product_cat → Alle apparaten moeten dus ook als attribute-taxons geïmplementeerd worden
Niet alleen heb je nu een complete taxonomie van één laag gedupliceerd, maar tevens een eindeloze verwarring gecreëerd, wat nu de 'juiste' pagina is.
Waarom überhaupt product_cat gebruiken? - 2023.09
Con
product_cat heeft een paar serieuse problemen:
- Laadtijd widget op shoppagina
- Inflexibiliteit tav. producten die niet in de hiërarchie passen → Klonen van alle taxons na de eerste laag
- URL's bevatten redundantie, want de URL van elke taxon moet uniek zijn, terwijl de URL van een pad dat ook al is. Dit is niet verder hiet behandeld, maar je krijg al snel URL's zoals
CandA/CandA-broeken/CandA-broeken-spijkerbroeken - product_cat-taxonomieën zijn verrekte lastige materie - Voor mij één van de moeilijkste onderwerpen rondom WordPress.
Pro
Waarom dan überhaupt nog gebruiken?
- SEO: product_cat-pagina's zijn geschikt voor SEO
- Hiärchie: Dit kan handig zijn om grip te krijgen op een groot assortiment - Maar dit wordt compleet teniet gedaan door de noodzaak om alle lagen behalve de eerste laag, te dupliceren als attribute-taxonomieën.
Create all possible first-layer taxons in product_cat - Not a solution
Would it be an idea to 'abuse' product_cat for creating all the first layer taxons. E.g., all brands and all devices in the example before?
The problem with this approach: You can't device a widget for filtering accurately: You would have one filter for all these brands and devices combined → You would still need attribute taxonomies, in order to have appropriate filters.
Upgrade Attributes?
By now we figured out that product_cat has some serious limitations. How about solving this issue the other way around: Upgrading attributes so that they equal the positive aspects of product_cat? That would be:
- Create SEF URLs for selected attributes - See before: Futile to try to do this for all parameters
- Enable buttonbars & product showcases
- Enable SEO texts.
Create SEF attribute URLs?
Would it be possible to create SEF (Search Engine Friendly) URLs for attribute taxonomies? See URL Rewriting Rules (Apache) for some details.
Examples
example.nl/shop/?filter_apparaat=boormachine&filter_automatische_stop=zonder-automatische-stop → example.nl/shop/filter_apparaat=boormachine/filter_automatische_stop=zonder-automatische-stop → example.nl/shop/apparaat-boormachine/automatische_stop example.nl/shop/?filter_automatische_stop=zonder-automatische-stop&filter_apparaat=boormachine → as before
Yes and no
As you can see in the examples above:
- It's surely possible to remove the question marks, and maybe even the
filter_xxxportion - However, filters have to to flexible, so in the end you can't always predict how they will look like
- It's important to avoid canonical URLs, like the second example above. You can have rewrite rules for a bunch of 'default' situations, but not indefinately - And that's ok: Just carefully select what pages you want to target on.