[Meta Issue][SEO] old slugs are not redirected correctly

[fthobe]

@shahmayur001

Eliminate the risk that a Taxon, Product, Page or Taxonomy are available on more than one URL

Desired Outcome

Currently if a resource changes slug, the old slug remains available with identical information.
The desired outcome is the following:

1. Removed slugs redirect to the new slug of the same resource it was previously associated to via a 301 redirect as defined here;
2. If the removed slug is reoccupied again by a new or preexisting resource the 301 needs to be removed in favor of the (new) resource and return to a standard 200 response rendering the page.
3. Deleted resources produce no redirect and return 404.

Considerations

• It was discussed in slack to use a polymorphic table
• this solution does not leverage rack but provides within the rails app legacy urls for resources
• the benefit is that it does not require additional gems (eg solidus_redirector or rack_redirect) to be loaded
• this solution can be overtaken to other gem imported resources such as a blog
• the solution has already been used by the maintainers in the past and was deemed acceptable by the maintainers of solidus
• the solution can be replicated within other content gems without requiring additional gems
• the current solution does not manage reoccupation of legacy slugs
• a management interface needs to be defined on product (and maybe variant) level to remove redirects that are not needed anymore

Mockup Management Interface

Expected behavior
A 301 redirect from old slugs to new slug.

Conversation with maintainers:

Additional conversation with the maintainers:
Fabian:

Some additional thoughts would be to throw it into a polymorphic table to render the high level functionality also accessible to other ressources such as pages and blog articles. Would that work for you?
5:28

Thomas:

If a new product is made with the same slug as an old product it should win over the old product. It has most likely been replaced by it and shops can explain this in ie. the product description. Everything else is too complex and should be handled by cusotm business logic (product life cycles, etc.)
An interface would be nice but is optional (same for API)
Polymorphic is fine, as we already need it for products and taxons

[seandawes]

@fthobe If you are deleting products and using redirector and solidus_redirector what would the issue be as you can just define old > new . The destination for not only product but other pages is going to vary depending on why the url was deleted.

[fthobe]

@seandawes I feel this should go into core and automatically happen in case of slug changes or deletions. Current state is the product remains online no matter what in the core version.

We just checked and saw that you end up with two product pages in case of a slug change and that deleted products are not removed.

[fthobe]

@jarednorman it's surely not correct behavior to leave the old url alive, do you want to move this to discussion and make a wider Feature Request out of it or should we just fix the redirect of lapsed urls?

[fthobe]

@seandawes look if this makes sense to you: #6098
If you ask me it can be build up to eliminate the need for the redirector.

[jarednorman]

It looks like you've fixed this for products in solidusio/solidus_starter_frontend#413. Should we close this issue, as the remaining slugged things can be fixed in that project, or is there an admin side that needs discussion?

---

Misc notes:

the benefit is that it does not require additional gems (eg solidus_redirector or rack) to be loaded

There is no such thing as a Solidus store that doesn't have Rack loaded. Rack is the thing that sits between your web server and your application in every web-based Ruby application.

a management interface needs to be defined on product (and maybe variant) level to remove redirects that are not needed anymore

Variants do not have unique URLs. Preselection is normally done via a parameter which doesn't affect canonical URLs.

[fthobe]

@jarednorman no, it's not closed.

• Taxons should receive friendlyid and behave like products url wise if urls are changed, right now the url is dropped > see PR Add permalink history for taxon on friendly-id #6100
• canonicals remain a weak implementation (but that should go into another ticket), the default configuration for canonicals is simply prone to create unexpected behaviours
• the trailing slash inserted into frontend, while admittedly following conventions, should be removed given the implications
• I would consider replacing friendlyid with an internal solution also covering generic redirections (mayur could take a look late April / may if that's of interest to have in core), also considering that friendlyid has some open tickets regarding duplications that I find worrying

Misc notes

Variants do not have unique URLs. Preselection is normally done via a parameter which doesn't affect canonical URLs.

Variants can have url, it's enough if you visit Amazon, it became common enough, that there are even the properties for structured data now to create relationships between products across multiple urls. I would at least offer the possibility.

the benefit is that it does not require additional gems (eg solidus_redirector or rack) to be loaded

I meant rack redirect, sorry for the imprecision.

I don't know how others do redirect, this is what I would do:

• a ressource agnostic polymorphic table for redirects that also extensions can hook into is feature that in my oppinion is really missing as the need for redirects is universal enough.

[jarednorman]

canonicals remain a weak implementation [...]

Canonical URLs is an issue for the starter frontend, not core.

the trailing slash inserted into frontend [...]

Same.

Variants can have url [...]

Variants do not have unique URLs in Solidus currently. You can customize your store to add support them in multiple different ways. It's easy enough for stores to choose their preferred approach and implement it. Even if we did support this, it would be a starter frontend thing, not core.

[fthobe]

@jarednorman so we reduce that issue on taxons and agree fixing slashes and canonicals in starter_frontend?
Taxons and friendlyID belong here.

[jarednorman]

I have not looked at what the trailing slash issue is, but the taxon permalinks stuff would need changes here, yes.

[fthobe]

Ok, we fixed that on. do you see any breaking issues here, I feel tremendously wary on this one: #6100

[fthobe]

Closed by #6100