Spree Single Product Urls - new extension

[Eliot Sykes]

Hi all,

Just released an extension to reduce duplicate content issues by
giving each product a single URL.

Here's what it does:

- 301 redirects from taxon-aware product URLs, for example:
- Handles Taxons like Amazon: no breadcrumbs at the top of the product
page; they are replaced with a "Look for similar items" section lower
down the page showing all taxons this product belongs to.
- The taxon-aware product URLs are no longer used in the product
listings pages

Available here:

http://github.com/eliotsykes/spree-single-product-urls

Best regards,

Eliot

[Paul Callaghan]

Hi

Just wondering: wouldn't it be more useful (SEO-wise) to retain some
info about categorization in a product's URL?

We could nominate one taxon for a product as the "primary" one
(criteria to be decided) and generate the product's link from that, eg
if p.taxons = [t1,t2,t3] we take t1 as the primary one and so generate
seo_url(t1,p)?

I am facing a similar choice in my revisions of the sitemap extension,
for the case when unique urls are required.

@sean: is the partial "products/products" redundant? can't find
anywhere that calls it - all calls now use "shared/products"

Paul

[Eliot Sykes]

Maybe there are some benefits to putting the categorization in the
product's URL - I wouldn't want to make that call for anyone else.

My own personal opinion on the subject is:

- If you change the taxonomy tree for a product, then the canonical
URL for that product changes. Not a problem if you use the taxon-less
'/product/ruby-on-rails-mug' type URLs.

- If there are benefits for putting the category in the product's URL,
I think they'd be small, plus, I'd be optimizing the product page for
the product name, not the category it belongs to. (When optimizing
the category page, then yes, I think for the URL to contain the
category name is a good idea).

- Main thing about the URL is to get the product name in there. I
wouldn't want to dilute that with the category name.

- When I have a problem like this I wonder how the big boys do it. I
don't think Amazon put the category information in the URL. They
avoid the whole breadcrumb-tracking problem by doing this. Check out
a product page on Amazon - no breadcrumbs and I think it is an easy to
use site. They rely on users knowing how to use a back button or
opening new tabs or using the "Your search history" section in the
footer.

- Simplest solution often works out best

[Sean Schofield]

Eliot,

This is an excellent extension! Steph has been after us for a while
now about the SEO impact of multiple URL's for the same product. I'm
actually strongly considering for the core. I've filed a ticket[1] in
Lighthouse on this.

I'm planning on keeping this ticket open for a week so if you'd like
to weigh in on this going into core then please comment on the ticket
thread.

Sean

[1] http://railsdog.lighthouseapp.com/projects/31096-spree/tickets/586-modify-seo-product-urls-in-favor-of-single-path-to-product

[Stephanie Powell]

Some thoughts:

Eliot Sykes wrote:
> Maybe there are some benefits to putting the categorization in the
> product's URL - I wouldn't want to make that call for anyone else.
>
> My own personal opinion on the subject is:
>
> - If you change the taxonomy tree for a product, then the canonical
> URL for that product changes. Not a problem if you use the taxon-less
> '/product/ruby-on-rails-mug' type URLs.
>
> - If there are benefits for putting the category in the product's URL,
> I think they'd be small, plus, I'd be optimizing the product page for
> the product name, not the category it belongs to. (When optimizing
> the category page, then yes, I think for the URL to contain the
> category name is a good idea).
>
> - Main thing about the URL is to get the product name in there. I
> wouldn't want to dilute that with the category name.
>

> - When I have a problem like this I wonder how the big boys do it. I
> don't think Amazon put the category information in the URL. They
> avoid the whole breadcrumb-tracking problem by doing this. Check out
> a product page on Amazon - no breadcrumbs and I think it is an easy to
> use site. They rely on users knowing how to use a back button or
> opening new tabs or using the "Your search history" section in the
> footer.
>

SEO best practice recommends to include the category in the page title
with a template like *Product Name | Category Name | Store Name*. It's
only acceptable to include the category in the url if products can only
belong in one taxonomy, which is not true for Spree.

I've read some SEO best practice articles that recommend that there only
should be *one* taxonomy and products can only be assigned to one group,
that this taxonomy should be the most meaningful/natural grouping to a
user, but then content and product groups can be created for separate
targeted keywords (landing pages). For example, a single natural
taxonomy to separate gear might would contain bikes / climb / ski /
clothing as the categories where the products do not overlap. A targeted
keyword landing page might be The North Face (a prevalent brand)
clothing or Black Diamond (another brand :)) climb.

Breadcrumbs are an important & common usability feature that should not
be *thrown out*, IMO. The only justification I could see to throw out
breadcrumbs is if you have a one-level taxonomy and the links to all
these categories is contained on every product page. To track
breadcrumbs and follow best practice SEO, the "big boys" may do one of
the following:
- store navigation information in the session
- store navigation information in the cookies via onclick JS
- append a '#' (relative url) to the url with navigation information
following the '#' (search engines do not index after the '#')
- force one taxonomy group per product
- use session history to generate a breadcrumb

Amazon does have breadcrumbs, but it looks like they only show up on
taxonomy pages when you've gone two levels into navigation and on:
http://www.amazon.com/Photography-Arts-Books/b/ref=bw_ab_1_12?ie=UTF8&node=2020&pf_rd_p=249347001&pf_rd_s=browse&pf_rd_t=101&pf_rd_i=1&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=068PJ6DD7WZ4VD0XWGPQ
http://www.amazon.com/Popular-Characters-Childrens-Books/b/ref=bw_ab_4_14?ie=UTF8&node=184930&pf_rd_p=236965601&pf_rd_s=browse&pf_rd_t=101&pf_rd_i=4&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1C1ZCR05JXYXMJMM3NY8

> - Simplest solution often works out best
>
>
>

Having implemented all of the solutions mentioned above, I wouldn't say
any of them are particularly difficult. Sure the simplest solution would
be to not include breadcrumbs at all, but that's probably not something
I'll ever want to say to a prospective client:
you: "Spree doesn't offer breadcrumb tracking in the core. That will
take me approximately 5-10 hours additional to build out."
client: "That's an essential ecommerce feature. Why doesn't Spree have
breadcrumbs?"
you: "Because Spree moved to SEO friendly urls and opted for the
simplest solution."
client: "Well, customer usability is a priority over SEO. Do other
ecommerce packages have breadcrumb functionality?"
you: "Yes."

~Steph

[Christopher Maujean]

I have recently been forced to deal with zen-cart and I've come to the
conclusion that zen-cart's major failing is complexity. In trying to
be all things to all people it has become incredibly complex and a
major PITA to modify and understand.

The lesson I think is to not try to be all things to all people in the
spree core. We need to remember the original goal for Spree and keep
only truly core ecommerce functionality in spree and have the rest be
in the extensions.

SEO is about Marketing and the base needs for SEO will change as
search engines change, and as fads come and go. Spree should support
the lowest common denominator and push the complex SEO support cases
out to extensions.

--Christopher

[Sean Schofield]

> The lesson I think is to not try to be all things to all people in the
> spree core. We need to remember the original goal for Spree and keep
> only truly core ecommerce functionality in spree and have the rest be
> in the extensions.

I agree. The question is, which behavior (current or proposed) are
you arguing for?
That's not clear to me.

> --Christopher

Sean

[Timothy Johnson]

That said, (which I agree with the premise), I would like to see more of us (who are building custom sites for customers) to take what we have put together with all the extensions, minus the custom business logic and design, and make repos out of them. At least that is what I am planning to do, because it is hard to put a system like this together when some extensions are out of sync with the trunk, or are missing pieces. Some of the extensions that I need are so woefully underdeveloped because they are not as attended to as often as core.

I understand why it is the way it is, but it makes it worse sometimes that just configuring a system out of the box.

Tim

[Timothy Johnson]

I would like to see a spree-core, and a spree-more division where some very routinely-needed extensions get a little more love everytime changes happen to core. Things like (my personal shortlist)

1. ActiveShipping Integration baked in

2. A lightweight (or better) CMS

3. Coupons/Discounts (obviously under development)

4. One fork for Authorize.net, and another for Paypal Website Payments Pro plus Express Checkout (since those 2 usually go together). Paypal express would also not be a bad thing to just integrate as an option across the board I think.

Tim

[scootercab]

> - Main thing about the URL is to get the product name in there.  I
> wouldn't want to dilute that with the category name.

I would want both the category name and product name in the url, thus
giving more keywords.

> - When I have a problem like this I wonder how the big boys do it.  I
> don't think Amazon put the category information in the URL.  They
> avoid the whole breadcrumb-tracking problem by doing this.  Check out
> a product page on Amazon - no breadcrumbs and I think it is an easy to
> use site.  They rely on users knowing how to use a back button or
> opening new tabs or using the "Your search history" section in the
> footer.

I think its good to keep an eye on Amazon, but there is a lot of other
eCommerce big boys to watch too!

Every book I have read on SEO advocates the use
of breadcrumbs (the robots love them apparently, showing you have a
good site structure which
is easy for humans to navigate)

John

[Stephanie Powell]

I'm in full support of having a simple + elegant solution for product
urls. I think that there are many opportunities to find a simple and
elegant solution that meet the criteria of best practice usability, SEO,
performance, etc.

By my definition of core ecommerce functionality and the goal of Spree,
SEO is important - how do you expect to explain to potential clients
that Spree meets your definition of core ecommerce functionality but
doesn't meet theirs which includes usability and SEO? Would you feel
comfortable telling a client that even though Spree doesn't offer best
practice SEO, it's search engine performance will be ok? From my
experience, I find that it's best to design a system with known SEO best
practice implemented -- otherwise, you cause a lot of problems that
require time & money to fix and could damage your search engine traffic
performance.

SEO is not just marketing, it includes technical aspects such as
minimizing duplicate content, page performance, and building a system
that allows the client to create and organize content that compels a
user to link to and buy from the site. Sure, search engines change. This
year alone, the rel="canonical" tag has been introduced and the nofollow
practices were changed by google. But less trendy SEO best practices
have stuck around for quite a while.

At the very least, Spree should not appear as SEO-ignorant & it doesn't
have to be SEO-*trendy*. Spree is acceptable the way it is, but my
frustration is that we shouldn't force canonical urls on products and
remove breadcrumbs. This is an example of sacrificing usability for SEO.

I also support the notion to keep *extension* functionality out of the
core, but I just don't understand why SEO best practices would be
categorized as extension functionality.

~Steph

[Paul Callaghan]

Tim,

The "spree-more" idea is a good one. Sean's also talking about putting
together a more impressive demo for Spree which will use some of the
top extensions. This "spree-more" could effectively be the set of
extensions being used for this new demo, and so provide extra
motivation for us to keep the exts up to date!

Paul

[Christopher Maujean]

I apologize for being unclear..

SEO support should be included in the core, the technical aspects are
important; SEO as a whole is important. My experience is that the
majority of time proven SEO best practices are also about usability
and therefore important anyway, so I don't consider them as being
about SEO, but about best practices in general.

Given the fluid and very specific needs of any given customer, one
cannot predict (beyond those core, time proven aspects) just what this
or that particular customer is going to want. If I have to tell my
customer that it'll take 5-10 hours to remove breadcrumbs from the
url, it's the same as if I have to tell them it'll take that time to
add breadcrumbs.

I would rather see a system that allows me to quickly add or remove
breadcrumbs (or any other SEO functionality) as my client's needs
require. I see our extensions system as being the key to this. In
order to keep the core simple, I feel we should take the standard base
set of SEO best practices as core functionality, and make sure it is
extremely simple to override those parts, as our needs force us. I am
by no means an SEO expert, and thus won't voice my opinion on whether
breadcrumbs are better than direct product links. My concern is for
the architecture, and keeping spree a good base with which to start my
e-commerce solutions.

--Christopher

[Sean Schofield]

>> - Main thing about the URL is to get the product name in there.  I
>> wouldn't want to dilute that with the category name.
>
> I would want both the category name and product name in the url, thus
> giving more keywords.

I think this illustrates the problem that what some people find
reasonable, others will not. Based on some of the feedback we're
getting here I might be inclined to say that we make the category
based URL and the breadcrumbs optional, if we include them in the core
at all.

> Every book I have read on SEO advocates the use
> of breadcrumbs (the robots love them apparently, showing you have a
> good site structure which
> is easy for humans to navigate)

Keep in mind the original proposal was similar to breadcrumbs. I
actually think of it as showing multiple bread crumb paths instead of
limiting you to the path you chose. Lets see what other think.

> John

Sean

[Sean Schofield]

> I'm in full support of having a simple + elegant solution for product
> urls. I think that there are many opportunities to find a simple and
> elegant solution that meet the criteria of best practice usability, SEO,
> performance, etc.

We may be able to come up with something. Lets give everyone a chance
to weigh in and see if we can't also find some common ground. If I
understand your position correctly, you are in favor of unique URL
without category information but also keeping breadcrumbs using
cookies or some other mechanism other then URL to generate it. That
right?

> By my definition of core ecommerce functionality and the goal of Spree,
> SEO is important - how do you expect to explain to potential clients
> that Spree meets your definition of core ecommerce functionality but
> doesn't meet theirs which includes usability and SEO? Would you feel
> comfortable telling a client that even though Spree doesn't offer best
> practice SEO, it's search engine performance will be ok? From my
> experience, I find that it's best to design a system with known SEO best
> practice implemented -- otherwise, you cause a lot of problems that
> require time & money to fix and could damage your search engine traffic
> performance.

Some potential clients/users will make a knee-jerk reaction based on
what is or is not included in Spree and there's not much we can do
about that. The best feature of Spree (according to the feedback I
get) is that its lightweight. Developers are tired of dealing with a
bunch of crap that they don't need.

Now, I'm not saying SEO is crap of course. On the contrary, I think
we should make Spree as SEO friendly as possible wherever it makes
sense.

> SEO is not just marketing, it includes technical aspects such as
> minimizing duplicate content, page performance, and building a system
> that allows the client to create and organize content that compels a
> user to link to and buy from the site. Sure, search engines change. This
> year alone, the rel="canonical" tag has been introduced and the nofollow
> practices were changed by google. But less trendy SEO best practices
> have stuck around for quite a while.
>
> At the very least, Spree should not appear as SEO-ignorant & it doesn't
> have to be SEO-*trendy*. Spree is acceptable the way it is, but my
> frustration is that we shouldn't force canonical urls on products and
> remove breadcrumbs. This is an example of sacrificing usability for SEO.

We have to be careful about what we include and don't include in Spree
(which is why I'm encouraging discussion on this instead of just doing
it.) Including something that a developer doesn't want is just as
potentially damaging as not including something they do. In both
cases, effort must be expended to get things the right way.

> I also support the notion to keep *extension* functionality out of the
> core, but I just don't understand why SEO best practices would be
> categorized as extension functionality.

I agree that SEO should not be automatically considered extension. We
already have the permalink URL and category URL (which some people
like for SEO) in the core. I think most of us are in agreement that
the categories in the URL may cause more harm (reduced spider
efficiency) then good (extra keywords in URL.)

We could probably make the category-based URL a preference setting and
warn users (both in the Admin and SEO guide) about enabling this when
they have anything beyond a single category hierarchy.

The breadcrumbs is trickier. I'm all for breadcrumbs in general (I'm
the one who added them to the code) but if we can't use the URL to
generate them (and I accept the reasons for why this is the case),
then I'm not so sure I want them. I'd hate to rely on some non REST
way of implementing this like cookie/session data. That said, I'm
willing to listen to the alternatives.

I'm pretty sure we can build an e-commerce platform with unparalleled
SEO consideration compared to those before it. Will it be perfect
from an SEO perspective with every best practice? No. But I don't
think that will diminish what it does have to offer.

> ~Steph

Sean

[Sean Schofield]

> I would rather see a system that allows me to quickly add or remove
> breadcrumbs (or any other  SEO functionality) as my client's needs
> require. I see our extensions system as being the key to this. In
> order to keep the core simple, I feel we should take the standard base
> set of SEO best practices as core functionality, and make sure it is
> extremely simple to override those parts, as our needs force us. I am
> by no means an SEO expert, and thus won't voice my opinion on whether
> breadcrumbs are better than direct product links. My concern is for
> the architecture, and keeping spree a good base with which to start my
> e-commerce solutions.

The flexible nature of Spree is what sets it apart IMO. We just need
to be careful that the core is not so "bare-bones" because we've been
too conservative about things which are difficult to add. I'm not
saying breadcrumbs go in or out on this basis, just making the general
point.

The spree-more (see other thread) will be a useful alternative but
we're still going to have to make decisions there as well. With a
spree-core, spree-more and dozens of extensions I think that's about
as flexible as we want to make things.

In the case of the actual URL, I think we can easily accommodate the
two styles (category info vs. no category info.) So that's probably a
good starting point. I do think the "related product" links in
Eliot's extension is quite nice. That's a bit marginal for core
perhaps (based on what I'm hearing) but everyone should install this
and see it if for themselves if they haven't already.

Anyways, nothing wrong with a lively discussion. We'll come up with a
good compromise. Spree is ultimately about choices so we'll try to
continue that tradition.

> --Christopher

Sean

[Stephanie Powell]

Hi,

> I apologize for being unclear..
>
> SEO support should be included in the core, the technical aspects are
> important; SEO as a whole is important. My experience is that the
> majority of time proven SEO best practices are also about usability
> and therefore important anyway, so I don't consider them as being
> about SEO, but about best practices in general.
>

Cool. I agree :)

> Given the fluid and very specific needs of any given customer, one
> cannot predict (beyond those core, time proven aspects) just what this
> or that particular customer is going to want. If I have to tell my
> customer that it'll take 5-10 hours to remove breadcrumbs from the
> url, it's the same as if I have to tell them it'll take that time to
> add breadcrumbs.
>

Yes, I agree. I would hope to come up with a solution that doesn't take
5-10 hours to remove breadcrumbs -- perhaps a configuration setting as
previously suggested. I suppose I'm just used to dealing with an
ecommerce system that has a lot of stuff floating around that's unused
-- which has never been an issue IMO.

> I would rather see a system that allows me to quickly add or remove
> breadcrumbs (or any other SEO functionality) as my client's needs
> require. I see our extensions system as being the key to this. In
> order to keep the core simple, I feel we should take the standard base
> set of SEO best practices as core functionality, and make sure it is
> extremely simple to override those parts, as our needs force us. I am
> by no means an SEO expert, and thus won't voice my opinion on whether
> breadcrumbs are better than direct product links. My concern is for
> the architecture, and keeping spree a good base with which to start my
> e-commerce solutions.
>

Again, I agree that Spree must have decent architecture to serve as a
strong base. However, I suppose I'm a bit against the grain of the Spree
community in that I think that Spree should contain more ecommerce
features like user reviews, user account functionality (wishlists),
landing pages, more CMS functionality, etc. etc. and have an easy way to
disable or build upon this architecture. Wordpress serves as an example
-- a simple wordpress theme contains ~10 views. The views can be edited
to use existing functionality that comes with an out of the box
wordpress install.

I think Spree could succeed similarly -- the set of rails views are
always going to be overridden for a client and would require snippets to
be added for the existing out of the box functionality (reviews,
wishlist, etc). A Spree theme could also contain a set of views that
correspond to user account or landing page functionality and these views
can be included or excluded from the client theme. So, out of the box
Spree functionality could be impressive, but the themes that use the out
of the box functionality may range from simple to extensive.

I like our extension system too, but the ease at which multiple
extensions can be integrated together remains untested and relatively
undocumented. I'm currently working on a client that requires about 8
customization points -- rather than use several existing extensions &
based on the limited budget, it's going to be easier for me to build one
extension with the customization rather than figure out how all the
extensions can play nice.

>
> --Christopher
>
>

I'd rather see the Spree core contain the spree-more functionality, but
by default it's turned off & excluded from the views. Introducing the
idea of a spree-core and spree-more to me simply means maintaining two
sets of code base and managing all the opinions of which functionality
should go in which spree repository.

Why not consider building a system that is more easily configurable with
a full set of ecommerce features than maintaining two separate code
bases? I realize this goes against the "convention over configuration"
rails notion that Spree was originally based on, but IMO, Spree is going
to more successful as a configurable, feature rich platform rather than
an opinionated minimal-decisions-required software. I don't "want to go
all Chuck Norris" on Spree, but an ecommerce platform audience of
product marketing + business folks is very different from the Rails
audience of developers. It serves me as a developer to have a platform
that appeals to those other folks', at the end of the day I just want to
code.

~Steph

[Timothy Johnson]

I agree with Steph on one level, but with Sean some other places, let me attempt to elaborate:

From the early days of Spree, it was intended to be a no-fluff kind of ecommerce system. We all could build web stores (or so we thought) originally by following Agile Web Development for Rails from beginning to end and get some basic store functionality. I haven't evaluated Spree before now because it didn't do enough for me "out of the box" to warrant me familiarizing myself with it, when I could use what I had build on in the past.

Fast-forward to today, Spree core already has a lot of functionality that I don't need (most things about variants, and the "every inventory is a unique record" methods) and is missing a good bit of functionality that I do need (some of which are found in extensions, others not). While I do like the method of extending Spree to get it to do what I want, I find that looking for well-working extensions is much worse in practice than using your average Rails plugin.

Thus my idea for Spree-more is this:

1. Spree-core is developed as a lightweight cart with what most people consider the minimum-needed to begin with.

2. Spree-more is spree-core plus extensions that many in the community find useful.

3. Tests are written at the integration points, and when Spree-core has some modifications, then we can run all the spree-core tests, and then run the tests that verify breakage in functionality in any of those select "more" extensions. This way you can cover at least most of your bases as you are updating core. The purpose of this is that we "must" keep core and more in sync with each other instead of trailing off behind with various popular extensions not being able to work out of the box.

IMO, saying that leaving features out of core is as important as what to put in is very sketchy logic (please don't take that wrong, I don't mean to be rude here). We all make decisions about what is right and wrong SEO-wise, design-wise, else-wise and definitely all come to different conclusions all the time, based mostly upon our clients' needs. Convention over configuration can only go so far when starting out a project, ultimately the whole Rails community is now excited over "templates" which everyone needs to create when doing apps over and over again gets repetitive. 

This is my first foray into Spree, and I do appreciate all the work that has gone into it thus far. I already have 3 extensions that I plan to release back into the community when I am done, and these aren't even the things I would like to see in core, but I would really love to see the starting point of Spree installation to be a bit more interesting, and full of pizazz than it is.

Timothy

[Sean Schofield]

These are all good comments but I think we should separate the "what
goes into spree-core" discussions on their own thread[1] and keep this
one to the specifics of the single product URL.

Getting back to the single product URL, I had lunch with a colleague
today and discussed the problem with him. He had an interesting
solution.

1.) Keep the category based URL's for browsing and use single product
URL for the actual "show" action. (So far nothing too controversial)

2.) Use the HTTP Referral information on the product page (which
contains the browsing hierarchy in the URL still) to render the
breadcrumbs.

3.) For caching purposes possibly generate the breadcrumbs using
javascript (progressive caching.)

#3 needs a little bit of testing and exploration. We're not doing a
lot with page caching in Spree right now but we need to start thinking
about that. IMO this solution works very nicely if you ignore caching
impact and possibly works with caching if we can get the referral
information in JS.

Thoughts?

Sean

[1] http://groups.google.com/group/spree-user/browse_thread/thread/44bbd387d85233c7#

[Michael Lang]

> 1.) Keep the category based URL's for browsing and use single product
> URL for the actual "show" action.  (So far nothing too controversial)
>

This is the best way to ensure single product URLs, IMHO.

> 2.) Use the HTTP Referral information on the product page (which
> contains the browsing hierarchy in the URL still) to render the
> breadcrumbs.
>

+1

> 3.) For caching purposes possibly generate the breadcrumbs using
> javascript (progressive caching.)
>

Not needed and unnecessarily introduces JS dependencies. Being able
to walk the taxon tree from any given child node up to top parent
should be simple enough. Perhaps consider acts_as_nested_set over
acts_as_adjacency_list?

Michael
--
http://codeconnoisseur.org

[Timothy Johnson]

I like this, but wonder about the issue following...

What if we implement search and get to a product page from search results?

What if the user bookmarks it, or is coming from a link in another website directly to the product show page?

Those 2 issues illustrate why it "may" be a good idea to have a "primary" taxonomy for each product. Just a boolean field in the join model maybe that flags it as "primary categorization"?

timothy

[Stephanie Powell]

When I've implemented this for a client before, we used javascript
cookies to track the navigation. If a user came directly to the site or
by some other means, the product had a primary taxonomy that was used
for the breadcrumb display if the cookie was undefined. The javascript
was simple and unobtrusive.

For another client, I used a single session variable to track the
navigation history to generate breadcrumbs in taxonomy + search plus
search refinement. The tracker variable will be used on the product page
to generate the breadcrumb that will include either the taxonomy history
or the search + refinement history to enable the user to navigate back
to browse taxonomies or their search history.

I know one of the comments was to not be dependent on javascript. For
the latter client mentioned above, javascript was not required and a
single session variable contained all the relevant breadcrumb
information. As I said before, another potential solution is to use the
'#' to append breadcrumb / navigation information. This is more visible
to a user, but not visible to search engines.

~Steph