Attributes vs. categories (WooCommerce): verschil tussen versies
| Regel 148: | Regel 148: | ||
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''. | 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 == | == Twee taxomomieën verbinden met een tussen-taxon == | ||
Versie van 4 sep 2023 16:00
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 |
|
|
| 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
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.
Catalog-pagina's & landing pages
Eerder in dit artikel werd gesteld dat catalog-pagina's qua SEO beter zijn dan attribuut-pagina's. Dat klopt. Maar het zijn nog steeds geen bijster goede landing pages.
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
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 aanzienlijk beter geschikt voor SEO dan attribute-pagina's. Waarschijnlijk is dit een additionele reden om veel gebruik te maken van Categorieën.