Type 4 – Positional Parameters with Encoded Parsing Hints

At this point, we really have to look at the SEO part in greater detail as I am presenting some rules for SEO which this encoding type should satisfy. Going through the SEO checklist in presented in the previous page:

  1. Offer maximum keyword density.
  2. Have ‘more relevant1‘ keywords closer to the hostname part of the URL – i.e. at the beginning of the URL.
  3. Be as short as possible2.
  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.

This encoding method ticks all of the above boxes with, what I think is a relatively ingenious and elegant encoding solution. The trade-off of this is that the implementation details are more complex, although I will try and explain them to give a deeper understanding of what is involved and hopefully by the end you will agree with the encoding type.

All of the previous encoding types are in use in the wild, however, I am not aware that this encoding method is in use. Always there are going to be caveats – that I have worked with a sizable number of commercial and open source SSAs, have been involved in optimising search results pages, however I am obviously not aware of all encoding methods that are in use. Suffice it to say that some of the leaders of the commercial SSA, with their brains-trust of highly talented architects and programmers have not yet implemented this method.

The goals

To provide an encoding method that allows

  • Maximum flexibility in the way in which the URL is constructed
  • Definable positions for high density keyword encoding
  • ‘Relatively’ easy to understand and implement
  • Has minimal redundancy in the URL – in this case the redundancy occurs at the end of the URL which has the least weighting on the SEO.

The implementation

For almost the last time, take our original ‘Type 0’ search query.


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

for each of the parameter keys, assign a one letter lookup for it.


  query -> q
  cat -> c
  edition -> e
  num -> n

  sort -> s

I have highlighted the sort lookup key as a special instance which we will look at soon.

Now that we have the lookup keys, we can remove them from the URL, translate them to path segments based on value thusly:


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

Note that I have left the sort parameter out of it.

The question now becomes:
“How will the SSA be able to recognise which part of the path segment is which?” and
“Is this some sort of throwback to ‘Type 3’ encoding?”

So we obviously need to tell the SSA which parameter belongs to which path segment, and we do this by appending to the end of the URL the list, in corresponding order of the path segments, the lookup keys.

So our URL now becomes:


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

The implementation for this method is to take the final part of the URL path segment, iterate through each character and assign the lookup key to the path segment. As a nice side effect of this, you can also re-arrange the URL as long as you re-arrange the last path segment encoding (LPSE).

The exact same query, returning the same results could be re-written thusly:


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

This has given us utmost flexibility in an easy to understand form.

The parameter type implementation

This, on the surface is a relatively good way to encode any URL in an SEO friendly matter. There are problems here, thankfully there also exists solutions. As a broad generalisation, there are three parameter types:

  1. The keyword (or query) parameter
  2. The category (or facet parameter)
  3. The search results metadata parameters

The keyword (or query) parameter is a little bit different from the facets and metadata as this is entered directly by the user and could be almost any value.

The facet parameters are pre-defined values which would come from some sort of datasource (e.g. database, text file). The idea here is that there is a fixed number of possible values available for every facet.

The metadata part encapsulates the sorting, number of results per page, the start page, basically anything that effects how the results are presented, not what results are returned.

The query parameter

The query parameter is user defined and could be of almost infinite permutations. There is no additional data needed to help the SSA parse this parameter. Consequently the encoded lookup key will always be one character long so when the SSA tries to decode the URL, once the query lookup key is seen, no further processing needs to be done on the corresponding path segment.

The facet parameters

The facet parameters are a little more involved, in some cases it may be necessary to have some sort of boolean operation that occurs within the facet type. For example, let us say that you want to search for DVDs that are in the action OR drama category. This sort of usage would require a facet lookup key modifier.

http://example.com/search/action/drama/cc|/

Form the above, the SSA would decode the LPSE as action drama OR – i.e. action OR drama.

similarly:

http://example.com/search/action/drama/cc+/

would be decoded as action drama AND – i.e. action and drama

You may wish to get more complex and have a query such as “I am in the mood for a DVD which is an action AND western OR is a comedy”. I.e. (action AND drama) OR comedy.

Assuming that the search interface allowed such a query, this could be encoded as:

http://example.com/search/action/drama/comedy/cc+c|/

The bottom line here is that a facet lookup key may also have a modifier.

Metadata parameters

Remember that the metadata parameters modify how the search results are presented. Now that we are in a position to come back to the sorting lookup key. It should be obvious that the sorting lookup key also requires some modifier – except that the modifier is the facet lookup key to sort by. So to sort by price (assuming that the price lookup key is ‘p‘) would be encoded as follows:

http://example.com/search/action/csp/

Of note here is that the metadata parameters do not always have a corresponding path segment to work with. Of course the path segment could be used as in:

http://example.com/search/action/price/cs/

Some metadata parameters also have modifiers – with sort we would want to either have them ascending or descending:

http://example.com/search/action/price/csA/
http://example.com/search/action/price/csD/

or

http://example.com/search/action/cspA/
http://example.com/search/action/cspD/

As another example, the number of results per page. Once again this could either be encoded all within the last path segment http://example.com/search/action/cn25/ or with a corresponding path segment http://example.com/search/action/25/cn/.

Parameter roundup

The LPSE implementation obviously requires greater depth of though than any previous encoding method. Added to this will be some more considerations in the next section, however before we get to this point we will look at another elegant use of this encoding method when writing snippets.

Searchable navigation

The real SEO power of this encoding occurs on the search results page and any search result snippets that occur throughout the site. When a user enters a keyword into a search box, or uses an advanced search form with other faceted information, upon pressing the submit button, the ‘Type 0’ request parameters are always used. It is when the user then click on any of the listed refinement facets that the URL is converted into a Type 4 encoded URL.

Writing snippets

Remember that the search result snippets from The Site Search Appliance page are used quite frequently and offer a browsable interface without any query string from the user. With this encoding method, a browsable navigation may be easily built that gives the user live results3. So if you wanted to present a browsable list of DVD categories to the user easily, it is just a simple matter of enumerating the category values (I assume generated from a fixed list straight out of a database) and encoding the URL to link to a live search.


http://example.com/search/action/c/
http://example.com/search/drama/c/
http://example.com/search/romance/c/
http://example.com/search/thriller/c/
http://example.com/search/horror/c/

This live search is incredibly useful to the user and also provides a lot of links that an SEP can spider which links directly to search results. The link looks like a regular path expression with no URL parameters so that the SEP doesn’t have to try and parse anything. Furthermore, the presented search results at the end of this link will also have the same encoding for all other facets that help the user further refine their search.

We can go one step further and offer a nice usability function for the user. By running a blank search on the SSA and only asking for the specific facet to be returned, a list of all of the categories and the number of results within the category can be easily generated.

Following on from this, a webmaster may wish to give a link to the most requested search queries, which once again can be easily generated:


http://example.com/search/superman/q/
http://example.com/search/james+bond/q/
http://example.com/search/romantic+comedy/q/
http://example.com/search/television+shows/q/

Note that the ‘query’ lookup key is used here as an arbitrary query string, but the SSA will not see any difference with the search results returned, seeing this just as a standard query. However, generating a static list which also presents the number of results that would be returned may be an expensive operation.

Up next

Now that we have covered LPSE in detail, this should in fact be useful in most cases for maximum SEO friendly URLs. We still have one more area to cover which is entitled (and rather a mouthful at that) Type 5 – Extra Information 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. 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
  2. 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
  3. Don’t forget that I mentioned pre-building these and caching them for later use.

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