Type 3 – Hard-coded Positional Parameters

Hopefully it should be obvious now that we are gradually building on encoding methods looking at ways to increase the SEO friendliness of URLs. In this encoding type, we are looking at removing some of the redundant information of the previous “Type 2” encoding whilst increasing the keyword density of the URL.

Building upon our previous method of encoding:


http://example.com/search/
  query/super/
  cat/action/
  cat/drama/
  edition/special/
  num/25/
  sort/price/

In the above encoded URL, the facet category has been removed from the query URL leaving us with the following:


http://example.com/search/
  super/
  action/
  drama/
  special/
  25/
  price/

This is a much more compact format, however it does present a few problems. The algorithm for decoding the parameters is as follows:

  • The first path segment super is always the query parameter
  • The second path segment action is always a DVD category type
  • The third path segment drama is also always a DVD category type
  • The fourth path segment special is always the edition
  • The fifth path segment 25 is always the number of results to display per page
  • The sixth and final path segment price is always the sort order

These hard-coded positional parameters can present problems, we will first look at what happens when we remove one of the parameters.


http://example.com/search/
  super/
  action/
  -/
  special/
  25/
  price/

Note that we have removed the drama DVD category and replaced it with a hyphen (or some other arbitrary character) which is then interpreted by the SSA as being a ‘null’ or empty parameter. SO it is easily done to remove parameters from the search. What is a little more difficult is adding more parameters.

What happens if we want to add some additional categories – let us say for example – the user is allowed to choose up to four DVD category facets. Our original query URL simply changes to:


http://example.com/search/
  super/
  action/
  drama/
  -/
  -/
  special/
  25/
  price/

With the extra parameters encoded as path segments of ‘null’. As mentioned in the Type 2 encoding previously, this would not present a problem, with the ‘cat’ path segment added before each parameter that needed to be encoded.

However, when using this type of encoding, at the expense of flexibility of being able to encode arbitrary numbers of search parameters, the URL is shorter and is more keyword rich for SEO purposes. It may be possible to use this encoding – and once again it IS used in the wild by some commercial SSAs – if the following two considerations factored into any implementation:

  1. The facets that need to be encoded are of a known quantity and this quantity can be pre-determined before implementation
  2. The facets do not need to be re-ordered, as the current ordering is the most SEO friendly1

The URL will always be a fixed number of path segments, no matter what the query. For example, let us say that the user can select four categories, two editions and may sort by up to two criteria. For a blank search, the encoded URL would look as follows:

http://example.com/search/-/-/-/-/-/-/-/-/-/-/
                          | \_____/ \_/ | \_/
            The query string   |     |  |  |
                               |     |  | The 2 sort orders
                 The 4 categories    |  |
                                     |  The #results/page
                    The 2 edition types

It would still be possible to remove some of the last path segments provided that the default values would suffice. They could then be re-added if the user wished to customise their particular search experience. For example, both the sort and num path segments could be removed. This will shorten the URL and remove some of the path segments.

About the ordering

I have internally debated over the ordering of the encoding types, especially with Type 3 and Type 2 encoding methods.

On one hand, type 2 encoding allows multiple facets to be encoded within the URL, and placed in any order at the expense of adding increasing amounts of redundant information.

On the other hand, type 3 encoding only allows a fixed number of parameters to be encoded within the URL. This, however contains a constant amount of redundant information, although this sacrifices customisation and extensibility.

The reason that I chose the ordering is that this encoding removes information from the URL and shifts it to an implicit understanding within the SSA implementation. That is, rather than encoding the URL with the parameter keys (e.g. cat, edition, sort, etc) followed by the values, we have just left the values in the URL. I admit it is a little bit unfair, as I ‘arbitrarily’ ordered the encoding types to move towards my preferred encoding, rather than presenting all methods and letting you, the reader come to a conclusion. Hopefully your patience and trust will be rewarded in the next section.

So what are we looking for?

When evaluating encoding methods for a URL, some sort of framework needs to be placed around the investigation so that there is a baseline for comparison. In this series of documentation, i have attempted to move towards a reasonable implementation which is based upon the following checklist.

The SEO checklist

I will once again reiterate that SEO is a complex and dark art, of which I am only going to scratch the surface in this series of articles (and at that only the URL encoding, not even the content side of it). For the maximum benefit, the following points should be taken into account.

The URL should:

  1. Offer maximum keyword density.
  2. Have ‘more relevant2‘ keywords closer to the hostname part of the URL – i.e. at the beginning of the URL.
  3. Be as short as possible3.
  4. Allow facets and queries to be re-arranged depending on specific needs of search result snippet pages.
  5. Reduce the redundant information within the URL to the absolute minimum
  6. Allow the encoding to be decoded easily into parameters that the SSA can easily understand.

Up next

We finally get to a point which I believe offers the best of all encodings4 and fulfills all of the points on the SEO checklist. Type 4 – Positional Parameters with Encoded Parsing Hints »

Navigation:

Use the following links to skip straight to a page, or browse through the pages one by one.

  1. The Site Search Appliance
  2. Type 0 – Request Parameters
  3. Segue into URL binding
  4. Type 1 – Throwaway URLs with Request Parameters
  5. Type 2 – Parsing Hint Positional URLs
  6. Type 3 – Hard-coded Positional Parameters
  7. Type 4 – Positional Parameters with Encoded Parsing Hints
  8. Type 5 – Extra Information Positional Parameters with Encoded Parsing Hints
  9. Encoding Type Showdown
  10. Final Note

Footnotes:

  1. I have touched on this before – the exact ordering that would give the most SEO friendly URLs would need to be determined by an industry specific SEO expert.
  2. What the meaning of ‘relevant’ is is hard to define and should be looked at in conjunction with some SEO experts within the industry that the site targets
  3. Taking both this and the point above into account, it is generally considered to be more SEO friendly to have a shorter URL as some SEPs have a fixed length of URL they will parse, with a greater weighting applied to the beginning of the URL path segment
  4. Type 6 encoding offers something a little more and is useful in the case where an SEO expert is on hand to help.

Like my footnotes?
Want to add footnotes to your blog?
They can be added easily to your WordPress installation