Let’s talk about URLs today and how they affect CouchCommerce shops.
It’s been not too long ago that the URLs in our web app looked like this.
http://m.your-shop.de/#/cat/a-unique-category-identifier (For category listings)
http://m.your-shop.de/#/cat/a-unique-category-identifier/products (For product listings)
http://m.your-shop.de/#/cat/a-unique-category-identifier/product/a-unique-product-identifier (For product pages)
There are a couple of problems related to such URLs and there has been a steady demand from customers to improve on them. Let’s first outline what the problems are.
Search Crawler Visibility
This is an anchor:
Notice the hash before foo? This has been used for ages to direct the browser to jump to an element on the current page with the id foo. It is not part of the server side resource and therefore if you go from http://example.com to http://example.com/#foo the browser won’t hit the server because the actual resource did not change. Everything on the right hand side of the # character is only relevant for the local web page and changes do not trigger a HTTP request.
WebApps “abused” (and continue to “abuse”) this fact and used such anchors for client side routing. A WebApp can react to changes to the right hand side of the hash to perform client side actions such as navigating to a different view. This is why a product page in the CouchCommerce WebApp was accessed as http://m.your-shop.de/#/cat/a-unique-category-identifier/product/a-unique-product-identifier until recently. It’s really nothing more than a good old local anchor though.
What’s not to like?
The problem with such URLs is that they lie to you. The content is just not there. The content is entirely constructed on the client side. In the browser. Search engine crawlers, however, don’t see the web as a browser sees it. They only see resources on a server. Unfortunately we don’t have them. Just like a native web written in Java or Objective-C views are entirely created on the client.
Pushstate API to the rescue
The outlined problems lead browser vendors to agree on an API to address the issue. A new API called `pushState` lets us change the URL of the browser without causing the browser to hit the server. Remember that any change to the URL previously caused the browser to hit the server to fetch a new HTML document.
We changed our app to make use of the `pushState` if available so that the URLs from above transformed into:
Are we crawlable yet?
Unfortunately, that alone does not address the search crawler concerns. It may assist on the bigger mission depending on which way to address the problem one decides to go. In our case though, we address the problem differently. We give hints to search crawlers where to find snapshots of the html. Each time a search engine wants to crawl a page of a CouchCommerce shop, we point it to another direction where it can request a previously created and cached snapshot. That’s a recommended technique by Google and deserves a blog post on it’s own.
URLs for human beings
Notice the bold parts of the URLs? Computers love such parts. They are great to deconstruct a URL and map it to an actual view. It’s easy for a machine to understand that the first URL is a category view, the second one is a product listing and the last one is a product page. Unfortunately humans unlike machines don’t care about such special identifiers. What people care most about is that URLs don’t change between desktop and mobile view.
A product page in the desktop shop accessed at http://your-shop.de/some-category/some-product should just transform into http://m.your-shop.de/some-category/some-product for the mobile shop. Just an extra `m.` to get from the desktop to the mobile view.
We implemented exactly that so that any valid desktop shop URL is automatically a valid CouchCommerce shop URL just served from a different subdomain.
You can see the URLs in action on our demo shop but we will soon roll that out to all our shops.
 Let’s not nitpick on caching here
 For older browser that don’t support the pushState API the URLs continue to use the hash based routing.
 That’s actually changing rapidly
 Albeit in a completely different fashion. Typically without HTML
 Or any other subdomain for mobile use. That’s up to the merchant.
 Well, not any. So far, it only works for category/product listings and product pages