State of SEO on Solidus (Meta Discussion)

[fthobe]

I have two fears in life: bad SEO and @jarednorman banning me from writing solidus issues for life so upon popular request this is a discussion :)

schema.org and the google desired reference implementation became over the years an important factor on search rankings the most notable case being free google shopping ads upon implementation.

Before I write anymore issues for the bucket list:

• is what's considered SEO best practice is considered desirable for the core?
• is what's considered SEO best practice desirable for the starter template?

In my personal opinion a baseline of fields required by schema.org and google shopping should at least be out of the box possible and it's low hanging fruit:

• 5-7 fields on products
• a couple of fields on taxons
• schema.org for the front end

[kennyadsl]

Not sure about its state, but this has been the go-to solution for adding some SEO enhancement in Solidus: https://github.com/karmakatahdin/solidus_seo. It's probably worth refreshing the extension and it should be good to go for what's needed here.

[jarednorman]

Haha, I won't ban you @fthobe! I will however ban @freelancedigitalmarketer for posting LLM-generated garbage.

[fthobe]

Edits

Fixed two references with correct names, fixed some typos, added 301 redirects and URL structure in what's missing

Basic technical Information

Currently best practice would be to transport structured data via json, it's the most wildly accepted format.
There are alternatives, but there some problems:

• google does officially support json via jscript injection, others don't (support varies largely here), json is the by Google recommended format (which indicates that itemprop will go EOL).
• itemprop has good results on most pages but seen the above I wouldn't use it, none of the search engines do officially support itemprop injection
• RDFa I list only as a courtesy, never seen it, never used it, I hardly know it and it hasn't seen a large adoption

What fields do we have to play with

• description fields on taxons and products do accept and render HTML correctly
• we do have prices for products and variants
• we have product names
• titles
• meta description

What's missing:

• brands ( @jarednorman suggested in Google Analytics 4 GA4 #4621 Spree::Product#brand which has the great aspect that it's guaranteed backwards compatibility, but it opens doors to wrong configuration), Introducing product brand using taxon_brand_selector #5989 PR made
• Price Ranges especially on category pages to model aggregatedoffer > it will be deprecated for SEO in favor of option groups and structured data carousels (right now every does a personal flavour implementation of itemcarousel mostly abusing the carousel (currently supported for Course list, Movie Recipe, Restaurant) which is while not documented mostly gracefully accepted by Google for offers (though not documented), but I think it has an immensely strong case on Front-End usability. Given the varying success of json injection I wouldn't want to do that via jscript.
• Reviews: 1-5 stars scale with endpoints to return a count of reviews and an average value, given the varying success of json injection I wouldn't want to do that via jscript.
• Variant URLs: Google expects for google shopping that a variant has an URL that upon page load is preselected (this can be done in front-end) and rendering a canonical link to the parent item, an approach that validates is a link to the product with the variant sku as parameter (eg BigCommerce does that). The best case would be a slug per variant, but that is hard to maintain from a content perspective (it's a lot of work to create tons of variants with different content such as description, meta title,...). A middle ground would be: one slug per variant with a canonical link on the primary product.
• 301 Redirects
• Discussion about shortening slug moving "/products/" and "/t/categories/" to root

What's cool and nice to have:

• date published
• date updated > crawling rhythm will be impacted

What should be deprecated

Nothing right now

What should be deprecated

• Excessive usage of heading tags
• itemprops (as things are going it will be deprecated by Google)

What could be deprecated for Europe and US but might be needed on other markets

• html keywords in head section: Quoting here "Meta keywords are largely outdated for major search engines like Google, Yahoo, and Bing, but some engines, such as Yandex and Baidu, may still factor them into their ranking algorithms" and this is current best practice.

What could be achieved afterwards relatively easily purely with front-end out of the box with the starter front-end

• Full Google Analytics compliance through having the information available for events
• Full Structured Data Compliance through structured data json
• Full Google Merchant Center Compliance (Google Shopping without Feed) through structured data json
• Facebook Catalogue will work

What will mostly work

• Bing / Yahoo is working on implementing variant groups, the issue here is that all countries work with the same underlying bing version so success could vary, they are usually trailing in the us by 12-18 months and in Europe by up to 36 months;
• Yandex works relatively reliable with some shorter or longer delay according to Google's standards, newer and experimental stuff like variantitemlists might not work yet, pages will work relatively well;
• Baidoo I have too little experience and the documentation is only in Chinese and requires login, back then when I worked in China we had good results just following european practices, but we surely left some stones unturned.

What other features have shown good / great results

• a sitemap should be there, it became universal standard and I would go with any sitemap is better than no sitemap, shooting for the moon I would also do an HTML sitemap (we will surely do it), an example is the booking.com html sitemap.
• a xml sitemap
• content control for the home page including opening hours and regions

[tvdeyen]

So your point is structured data yes, google analytics no, is that correct and would that mean you support the idea of integrating reviews to core?

structured data yes, google analytics no related code in an extension.

you support the idea of integrating reviews to core?

I think this makes sense. Maybe we (@solidusio/core-team) could start thinking about feature flags instead of fine grained extensions for basic features like this. Maintaining so many extensions is a lot for a small team like ours. And unmaintained extensions do not shed a lot of good light on our ecosystem.

Also there's the discussion open regarding the integration of GA4 where it seemed to agreeable to implement GA4 in the starter frontend.

From @jarednorman's comment:

I would like the starter frontend to ship with this as an option.

I assume he means that this should be an installer option. If not I will ban him 😆

[fthobe]

I assume he means that this should be an installer option. If not I will ban him 😆

Hey, we all have been there wanting to ban Jared.

But on this rare occasion I would like to cheer him:
It makes sense to build out the starter template to what it is, a reference implementation (also for us to prepare a custom template later on), while I share your flavour of thought on everything google maybe it's wise if the starter-frontend is this reference to include what's the industry standard, despite me and you sharing the same sentiment here.

Regarding the burden of maintenance
Honestly we haven't found one extension that works trouble free right now, I can see how multi domain is an edge case, just review and brands taxons are not (it would be in my opinion a very difficult case to make to say otherwise) and in my opinion having subscriptions easily running from the start has a very strong business case as it has the potential to dominate a (not that small) nieche with the current offering on the market especially considering that the barrier between products and services become ever more fluent.

To return to GA and looking at the various default templates out there on the various platforms GA and structured data is a feature and not technological debt and it belongs in my opinion in the starter template bucket. #banmeaswell

[jarednorman]

@tvdeyen is correct. I indeed meant that it would be an option.

Reviews are something that the vast majority of our stores depend on third parties for. It's not a candidate for inclusion in core in my mind, but I would love if the extension were fixed up to provide good support for the starter frontend.

[fthobe]

What is the mechanism to verify the presence of an extension or the activation of a feature? I can see how we can easily override behavior with a config file, what mechanism do you have in mind to verify extensions available?

[jarednorman]

The Solidus installer already does this for things like payment methods. You can take a look at how that works.

[jarednorman]

@fthobe I don't want to sidetrack the conversation, so I'm posting this outside the thread, but you've used the word "depreciate" and "depreciated" throughout your comments above. You mean "deprecate" and "deprecated". English is a terrible language.

[fthobe]

@jarednorman Sorry Jared, I know you are right, I have to converse in 5 languages and macOS / iOS does not handle that very graceful. Please accept my apologies, I will be more careful in the future. I actually do profoundly love English.

[jarednorman]

No need for apologizing! It's a very common mistake that native English speakers make too. I wouldn't have even pointed it out except that the word appears in the code itself, so I thought it would be helpful for you to know the correct one.