Attributes vs. categories (WooCommerce)

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Producten - Categorieën
producten - Attributen
producten - Tags - Tot op heden nog niet gebruikt (april 2019)
Ah, dit is de truuk tav. attributen (kenmerken): Het gaat om aspecten die inherent aan het product zijn. Ze komen ook terug op de productpagina's en (hopelijk) ook bij importeren

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:
  • Taxons hebben echte URL's, zonder parameters
  • Additionele content-velden beschikbaar
  • Yoast-velden beschikbaar
Minder geschikt voor SEO:
  • Taxons hebben geen eigen URL, maar zijn geassociëerd met parameters in URL's. Dat scoort slecht in zoekmachines
  • Er zijn additionele content-velden beschikbaar, maar die worden standaard niet getoond op shoppagina's. Lijkt me ingewikkeld om dat te veranderen, omdat shoppagina's ook al bij een catalog-pagina horen
  • Yoast-velden zijn beschikbaar, maar net als voor content-velden, komt het me niet-intuïtief voor, om daar gebruik van te maken.
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
  • Categorie-filters zijn rekenintensief (zie hieronder).
  • Verder vergen Categorieën waarschijnlijk weinig rekenkracht. Een site wordt vermoedelijk niet sneller of langzamer van een grote categorie-taxonomie en hetzelfde geldt voor een taxon-pagina (shoppagina)
  • Attribute-filters zijn rekeninstensief op het moment dat er veel items zijn waarmee de filters gevuld moeten worden. Voor een vergelijkbare situatie zijn attribuut-filters waarschijnlijk minder rekeninstensief dan categorie-filters, omdat bij categorie-filters alle filters van de hiërarchie in één widget zitten en dat maakt het flink zwaarder
  • Zou me niets verbazen als de taxon-pagina's juist wel rekenintensief zijn, omdat er parameters moeten worden verwerkt - Maakt dat uit?
Filter-weergave shoppagina

Categorie-filters:

  • Styling-mogelijkheden lijken beperkt te zijn en alle filters lijken in één widget te zitten, maar je kunt wél hiërarchische filters hebben, en dat is soms onmisbaar
  • Deze filters zijn rekenintensief.

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.

Klinkt intuïtief, maar in de praktijk kan ik hier niets mee.

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.

Zie ook