[SEO / Structured Data] Define main taxon for usage in breadcrumbs

[fthobe]

Issue

Currently breadcrumbs are not necessarily generated correctly as any of multiple taxons configured with the product can be picked to load them in the store front.

## Desired Behaviour
Breadcrumbs are a keyword ranking factor and therfore a factor in the determination of relevant keywords by search engines. Merchants should have the possibility to enforce one taxon as primary for the generation of breadcrumbs and that taxon should be rendered with ancestors as breadcrumb trail.

Task

• add a column to products to identify one primary breadcrumb (column name: breadcrumb_taxon)
• allow the primary breadcrumb to be selected on the admin panel from the available taxon using identical form fields to current taxons form field (Label: "Breadcrumb Taxon"; Info: "Breadcrumb Taxon", Description: "If you want to use a specific taxon to generate the breadcrumbs you can select it here. This is particularly useful if you use more than one taxon and want to emphasise certain keywords to search engines.")
• Add the field to the API as "breadcrumb_taxon"
• Implement the breadcrumbs on the Starter_Frontend mantaining the existing logic to construct ancestors and add an if validation to use the "breadcrumb_taxon" to generate the breadcrumbs if it is present
• Implement tests
• Follow discussion below if design changes are required.

Related Issues

Concerns also: Starter Frontend Issue #130

Previous Conversations with maintainers

Every shop I worked with has a different understanding of what the main taxonomy (most of the time referred to as "Category") is. Some refer to as the "Storefront" taxonomy, some call it "Navigation", etc. I can see that there is an urge for at least something that is been used as the main product category.

We could make it configurable and default to a taxonomy with a "Category" name or add a flag to the taxonomies table (ie. main_category).

I am open to suggestions.

If introducing a main_taxon is ok for everybody that's fine for me and we could implement that.

[kennyadsl]

What about a flag on the taxonomy, similar to default_for_breadcrumbs. "Main" doesn't have a good semantic IMHO.

[fthobe]

Hi @kennyadsl do you mean that a taxon is flagged as a primary taxon for all products related? Sorry I am trying to understand your approach better as currently the issue is that there are too many taxons possible taxons to reliably render breadcrumbs and I feel we just shift the problem instead of solving it if we don't create a simple 1 product has many taxons but one primary taxing relation to generate the breadcrumbs instead of creating a scenario where multiple primary taxons can be associated to one taxon. I found what @tvdeyen wrote spot on and felt it was a good comment. Can we settle for that approach?

[fthobe]

@kennyadsl default_for_breadcrumbs is a little long, is breadcrumb_taxon fine?

[kennyadsl]

use_for_breadcrumbs or breadcrumbs_source?

[fthobe]

Man, whatever makes you happy and creates something that is merged.

Follow the breadcrumbs to reach the PR... 🍞

@rahulsingh321 use breadcrumbs_source
@kennyadsl what label in the admin interface?

[kennyadsl]

You get this started by complaining for the long column name! 😆
For breadcrumbs_taxon, my point is that you are adding the column to the taxon table, it's useless to repeat that that value refers to a taxon. You'll have taxon.breadcrumb_taxon, which is redundant.

I'm ok with whatever name, just use your common sense.

[fthobe]

You get this started by complaining for the long column name! 😆
For breadcrumbs_taxon, my point is that you are adding the column to the taxon table, it's useless to repeat that that value refers to a taxon. You'll have taxon.breadcrumb_taxon, which is redundant.

I'm ok with whatever name, just use your common sense.

Honestly we went for a selector.

[jarednorman]

We're talking about marking which taxonomy and not taxon should be used for breadcrumbs, right? I think calling the column (on the spree_taxonomies table) breadcrumbs is sufficient.

[tvdeyen]

You get this started by complaining for the long column name! 😆
For breadcrumbs_taxon, my point is that you are adding the column to the taxon table, it's useless to repeat that that value refers to a taxon. You'll have taxon.breadcrumb_taxon, which is redundant.
I'm ok with whatever name, just use your common sense.

Honestly we went for a selector.

What is "a selector" in this context?

[fthobe]

I do not think having this value in the taxonomy is a smart move. It's a value of a product, if we have to breadcrumb taxonomies associated to a product we are again at the beginning of the Problem of having to many taxons. Could we please make this a column on the product and not a taxon issue, because it just isn't.

The solution taken for Brands was already allowing multiple Brands on one product which i do not think was smart but the Risk here to make mistakes in data entry is Little to none. With this topic I feel much much stronger.

[tvdeyen]

I do not think having this value in the taxonomy is a smart move. It's a value of a product, if we have to breadcrumb taxonomies associated to a product we are again at the beginning of the Problem of having to many taxons. Could we please make this a column on the product and not a taxon issue, because it just isn't.

The solution taken for Brands was already allowing multiple Brands on one product which i do not think was smart but the Risk here to make mistakes in data entry is Little to none. With this topic I feel much much stronger.

Can you give an example of how you would imagine this implementation on the product level? Since taxonomies are the way to "categorize" products in any categorization (brands, categories, navigations) it feels more natural to implement it on that level.

[fthobe]

Sure, I sometimes struggle to align my language with yours and I apologies for that.

So what Kenny and Jared suggest is to my understanding add a "is main breadcrumb" flag to a taxon and automatically define this taxon as breadcrumb if it's present on a product.

I understand that this solution might seem tempting for the simplicity.

The issue with that is that it doesn't solve the problem:

• If we add two of them to a product we are at the starting point
• (sub-)taxons might be many and not distinct enough to keep track of which I have added

This could of course be mitigated by some logic to check if multiple breadcrumb taxons are present, but it seems to me we create a lot of logic to mitigate a problem when we could just create another column of the product to be linked of any of the taxons in a matter that belongs to one.

I feel that having brand taxons in the manor we did was bending logic, here we are really breaking the purpose of the implementation by shifting distinct product features into taxons.

If I misunderstood please correct me and we can have this out of the door by Friday.

[jarednorman]

If someone erroneously put a product in two different taxons in their breadcrumbs taxonomy, you'd just take the first one. It's really not a serious problem.

[fthobe]

It's confusing, is there any particular reason why it's better having a column on the taxon rather than a column on the product?

I already found the brands in taxonomies hard but still manageable, here you are really loosing me on logic.

[kennyadsl]

@fthobe can you explain your proposal better? Is it adding a different taxon on each product? How is the process to add them? Manual or automatic?

[fthobe]

Generally you want the longest level of taxon for primary breadcrumb trail.

TL;DR (long version with examples, recommendation and sources below)

Google encourages ONE breadcrumb
I know of some iterations of Bing (Bing / Yahoo have different versions of the engine per language space, English is usually up to date, others are trailing usually by 1-2 major versions), dropping everything but the first.
Yandex drops breadcrumbs if the page is of insufficient size (by pages) and does not define that.

Example 1: three shoes, two primary breadcrumb taxon overlap

To give you a good example where your suggestion might be problematic:

Imagine you sell All Star Sneakers (the basketball shoe of the 80ies), the newest and latest Nike Basket Ball shoe and a Pair of Adidas Stan Smith Tennis Shoes (Sneaker as well as tennis shoe). These three among all other 40.000 men's shoes you have in stock.

Nike Air Jordan would clearly go in the Basket Ball category and here we go, primary breadcrumb.
But what about the All Star (Breadcrumb Taxon Sneaker) and the Stan Smith (Breadcrumb Taxon Sneaker) but also a Tennis Shoe (which you need as Breadcrumb for the other 50 pairs of 250USD a pair high end tennis shoes you sell).

Nobody who ever threw a ball will buy All Star sneakers for Basketball (but it still goes in that category), the Air Jordan goes safe there (with basketball as breadcrumb taxon).

Stan Smith is really problematic, it's a (more or less valid) tennis shoe but it sells as a fashion accessory and vintage shoe (actually much much more than in any other category), so you want the all star and the Stan smith rank as (vintage-)sneaker. So what now?

A flag for a taxon does not make sense and in addition it's as much work as another column to give one taxon a special relation to one product on the product, with the added benefit that it is a sane default.

Desired Outcome

	Sneaker	Basketball	Tennis
All Star Sneaker	Breadcrumb & Taxon	Taxon	N/A
Adidas Stan Smith	Breadcrumb & Taxon	N/A	Taxon
Nike Basketball Ultra Mega Shoe	N/A	Breadcrumb & Taxon	N/A
Best Generic Tennis Shoe	Taxon	N/A	Breadcrumb & Taxon

Example 2 Car Parts

Another example would be car parts:
Same piece, multiple cars, multiple breadcrumb categories, probably you want the brand -+ component taxon (Blinkers) as primary breadcrumb, but you have another blinker that is much more vehicle specific.

Below an extreme example of one blinker two cars:

What google recommends

In fact what google ENCOURAGES is having one primary breadcrumb trail and (optional) alternative ones according to where you desire structurally allocate your product.

what bing / yahoo says

Multiple breadcrumbs are better help our (sub performing) crawler understand which pages we missed.

what yandex says

Give us 1 breadcrumb and we (might pick it up)

What all say

Breadcrumbs are a ranking factor in understanding keywords your page is relevant for.

What we should do

Basic Implementation
ONE DEFINITIVE primary breadcrumb set on the product, but somewhere in the backend we need to fetch the decision which one to pick and a second product to pick one distinct taxon would help here.

Extra Mile
All other taxons (that are not the primary breadcrumb) below the content section of the product above the footer as configurable frontend feature in the starter (and we have to do that there as far as I understood).

Sources backing me

For who wants to read it:
https://www.searchenginejournal.com/matt-cutts-explains-can-use-multiple-breadcrumbs-page-without-confusing-googlebot/95333/

Deep dive google documentation:
Implementation

[fthobe]

Regarding editing them:

How is the process to add them? Manual or automatic?

Well, AI is on the horizon, but actually most SEO is excel and tool based. I would go for admin interface + api here.

[kennyadsl]

Ok but what’s the UX for the admin here?

The problem is clear but I struggle to understand your proposal in terms of what’s the experience for the admin user managing the breadcrumbs with the product level field.

Maybe you can try to build some rough mockup quickly to let us understand your idea?

[fthobe]

Current interface

The current interface for taxons is absolutely great, as it gives a more profound understanding of the taxon currently selected.
It is amazing because it displays the taxon and ancestors in a concise and easy to understand way that allows to comprehend the location of the individual taxon without actualy beeing in the taxon menu.
Many systems did not find such an elegant solution. I do though wonder what to do if we have multiple stores.
Just to give you an idea what we have to work with on BC:

What should be done in Backend

For breadcrumbs
Given that the current interface is actually awesome, let's reuse it limited to one taxon.

And as we are good citizens, with help notice:

What should be done in Frontend

In a perfect world I would always set the breadcrumb taxon separately, to guarantee backwards compatibility what I'd do is:

1. if a breadcrumb taxon is present render that
2. if not render the first taxon you find
3. Render up to 5 additional taxons above the footer.

If we are extra sneaky, we could also restore from session or referral when a user lands on a product page via taxon, but I am shaky on that as the Google crawler might often hit the page via html sitemaps or category pages, so it might render the wrong outcome (I never had the change to really really test that and I don't feel confident on it yet.

[fthobe]

Do we want to use this chance to also clean up the form order a bit?

We could concentrate all rarely changed data in one block:

Block 1: Basic Catalogue Data

1. Name
2. Taxons
3. Description
4. Option Types

Block 2: Search Engine Optimization

1. Meta Title
2. Slug
3. Breadcrumb Taxon
4. Meta Keywords
5. Meta Description

Visual Proposal