Elasticsuite: SEO Improvements to: URL, Canonical URL and Sitemap Format when filters are activated.

[duffner]

This is a feature request that I will think make this extension best of class for Magento.

Issue: Searching "Style - Exercise" & "Activity Gym"
Resulting URL: http://magento2community.test/gear/bags.html?activity=Gym&style_bags=Exercise

Desired URLs
Page: http://magento2community.test/gear/bags/activity/gym/style_bags/exercise.html
Canonical URL: http://magento2community.test/gear/bags/activity/gym/style_bags/exercise.html
SiteMap URL: http://magento2community.test/gear/bags/activity/gym/style_bags/exercise.html

For the Page URL, it would be awesome to use "/" instead of ?attributename=AttributeValue. This would allow crawlers to index a category page as unique when an attribute is used for filtering.

As to the SiteMap and Canonicals, I believe these would be accomplished at the attribute and attribute value level. Ideally, there would be a checkbox in each value whether as to whether or not attribute or attribute value contributes to the canonical URL or SiteMap.

Why is this important: Say for example we are tie store, that sells men's ties of various colors.

Say a user goes to Google and searches Red Men's Ties. Without this feature, the most relative page would be tiestore.com/mens-ties/. While this is close, Google can't index parameters of a site. If for example, we added the above feature. Google would have tiestore.com/mens-ties/color/red indexed as a unique page because there is a unique canonical link and entry into the sitemap. And for the benefit of the merchant and customer Google would likely have this page as the most relevant for Red Men's Ties and the customer would land really close to their desired search result.

There is an extension https://www.manadev.com/seo-layered-navigation-plus-magento-2 here that does the SEO part absolutely amazing, but it modifies to much of Magento's core logic and conflicts all the time with other quality extensions. (Definitely not compatible with Smile :( ) also doesn't work with Magento 2 EE.

Preconditions

Magento Luma Theme
Magento Sample Data installed

Magento Version : 2.2.2 and 2.2.4 CE and EE

ElasticSuite Version : 5

Environment : Developer

Third party modules : None

Steps to reproduce

1. Install Sample Data
2. Go to http://samplestore.com/gear/bags.html
3. Select Searching "Style - Exercise" & "Activity Gym"
4. Resulting URL: http://magento2community.test/gear/bags.html?activity=Gym&style_bags=Exercise
5. Resulting Canonical URL: http://magento2community.test/gear/bags.html
6. Sitemap URL: http://magento2community.test/gear/bags.html

Expected result

1. Go to http://samplestore.com/gear/bags.html
2. Select Searching "Style - Exercise" & "Activity Gym"
3. Page URL: http://magento2community.test/gear/bags/activity/gym/style_bags/exercise.html
4. Canonical URL: http://magento2community.test/gear/bags/activity/gym/style_bags/exercise.html
5. Found in sitemap: http://magento2community.test/gear/bags/activity/gym/style_bags/exercise.html

Actual result

1. Only the category is indexed and present in Canonical and Sitemap URLs
2. Parameters are used instead of "/" .

This would make this the defacto search and SEO extension on the marketplace today. To be honest, these issues are presented by every SEO company as attacks against Magento since it's inception in 2008. I'd for once love to have a final solution that solves SEO, Search, and Layered navigation pain points of Magento

[afoucret]

Hello I add this to the long term roadmap.
We are definitely interested by such a feature.

We already have few SEO feature implemented, like using attribute label instead of option_id but it is true to say it is not enough.

BR,

[djenvert]

You meant _short_ term roadmap, didn't you @afoucret 😀 ?

[afoucret]

Depends your definition of what is a short or long term ?
We have very important things in the short term like Magento 2.3 compat or GDPR for the tracking.

But yes we will have a look at this one.

[adamj88]

@afoucret I _strongly_ disagree with this issue, the expected result would end up creating 100,000's of new URLs (could be millions depending on number of attributes) to be indexed and likely result in an SEO penalty for duplicate and spam content instead of adding any benefit.

We've seen this occur in the past with extensions which did exactly this and the removal of the expected result back to how the extension currently currently works was the solution.

If it's a must I'd recommend it going into a standalone Elasticsuite module instead as implementing this would be catastrophic to our SEO.

[romainruaud]

@adamj88 , I agree what you are saying, but there is 2 different topics here :

• rewriting the layer filtering url into a nice url
• letting all of these filter urls being indexed by search engines.

Imho, a nice feature for SEO would be to be able to configure the noindex/nofollow for each attribute :

• it can make sense to have some filtered url indexed (Eg : imho, this can be nice for "brand" attribute on a clothes store)
• you may not want to have all your filtered urls indexed/followed as you were saying above (duplicate content and so on).

Taking this into account, the matter of using nice urls for filters or not will not have any influence since you'll be able to specify the noindex/nofollow rules.

Regards

[adamj88]

@romainruaud agree noindex/nofollow can be used.

Would the creation of these URLs flood the URL rewrite table as well and impact performance there?

Just on your point:

it can make sense to have some filtered url indexed (Eg : imho, this can be nice for "brand" attribute on a clothes store)

In this instance would it not be better to create virtual categories for these attributes which can managed at a store level instead? As an example, what if I only wanted certain values of the brand attributes to show and not others?

In my opinion, this would be better split out into a separate module rather than enforcing these decisions in the core of the extension but interested to hear more about how a solution for it would work.

[duffner]

@adamj88, I'd like to follow up. While I agree that an improper implementation may cause 100's of thousands of URL rewrite records and duplicate content. I also agree that this should be a separate module as should any functionality that exists outside of SOLID practices.

However, listing excuses as to why it shouldn't happen such as performance or more URL rewrites shouldn't be reasons not to implement the functionality. These reasons should be stated as risks and brought into the success criteria of new development. There are many ways to implement the recommended functionality without ever touching the core URL rewrite table.

@romainruaud, I agree with your two points as they summarize my feature request quite simply and I like the NO INDEX, NO FOLLOW by attribute! 👍

As to @adamj88's point about Brand being a virtual category. Keep in mind, the term brand can mean different things to different businesses. In the context of a large clothing retailer, Brand is typically a filter. e.g. You're a user looking for red pants, and you heard about Nike, so you select the color swatch "Red" and then the filter of "Nike", and you see what's available. In this case/example, users are not "brand" loyal or dependent which aligns with Magento's attribute filtering logic. Now from the SEO point of view, since a user may search in Google. "Nike Red Pants" you'd likely want a page that Google can crawl with "Nike" specific content, that show's user's pants that are red. Now you could create two nested virtual categories, one for "Nike" with a child of "Pants" . which is already an awesome ability of the Smile suite and pro, however, there is no way to solve for the color "Red".

When does "Brand" make sense as a Smile virtual category or category vs an attribute even in Magento's core logic? When "Brand" is a requirement of a user journey to a product. For example, XBOX/Microsoft and at a video game store. As a user and an Xbox One owner looking for video games or accessories, you have no interest in seeing anything PlayStation related as the product is incompatible with what you own.

Let's make Magento better and not let there be excuses to not do something absolutely necessary for an enterprise level E-commerce store.

[duffner]

@romainruaud and @afoucret,

Do we think this is something that will be added to Smile?

[Kershrew]

Has there been any movement on this? :)

[afoucret]

Hy @duffner, @Kershrew

I have added the issue in the 2.7.x roadmap but the core team is very busy with other issues that were flagged with an higher priority. So we don't know how and when we will address this one and proposals are welcome and may speed up the delivery of a solution (both functionnal design and code).

[Kershrew]

Thanks for the response @afoucret unfortunately our client requires these sort of URL's and coming to discover that no other extension will play nice with smile has resulted in me needing to pull it out of the project. This in itself appears to have broken our build of Magento so now having to rebuild from the ground up :(

[rioux602]

Would it be possible to get an ETA on this feature?

Thanks!

[subbu1993]

Is there an ETA on this feature ?

[igorwulff]

We are looking for a similar feature and see this RFP open for some time. It would be great to get an update on this.