Search engine friendly RESTful urls in web pages

Version 10.1 of the CMS supports the creation of search engine friendly URLs based on existing dynamically generated pages. This provides more appealing URLs whilst also allowing users to seed keywords into their links. So for example a URL such as this:

http://<domain>/pages/port-details.htm?portid=22 could be replaced with this:

http://<domain>/ferry-ports/scotland/south/ardrossan/22

Such URLs are fully configurable in the ‘advanced’ tab. This page gives details on how these are created and applied.

Example 1

The following example relates to a system using the new posts pages. We have configured an example training system based on date based posts. One of the outputs from this populated system is a  course list page called ‘course-list.htm' and we want to be able to reference this using more SE friendly RESTful URLs. The ‘normal’ URL is this:

http://demo2-gt.nhs.beta2.sitekit.net/Training/course-list.htm

Which displays this:

The click through to the course details page would have been this prior to the RESTful changes:

http://demo2-gt.nhs.beta2.sitekit.net/Training/course-list.htm

The courses page is a post list page based on pre-configured courses as seen in the initial posts example. A RESTful URL is configured by clicking on the page properties of the pages and then on the advanced tab. RESTful URL are created by specifying a fixed stem or prefix, followed by a set of parameters. Multiple RESTful formats can be configured for the one page provided they don’t contradict each other.

Firstly the following stem and parameter are added.

With the above stem option it means that the same page can now be served by http://demo2-gt.nhs.beta2.sitekit.net/courses/  equally the stem could be extended to add additional keywords so it could display http://demo2-gt.nhs.beta2.sitekit.net/full-time/courses/

Similarly the new stem parameter combination could be added as shown below

The click through to the course details page would have been this prior to the restful changes:

http://demo2-gt.nhs.beta2.sitekit.net/Training/course-list.htm?postid=33

But with the above addition it is now:

http://demo2-gt.nhs.beta2.sitekit.net/courses/astronomy-phd/33/

When a request comes in for a page on the server, e.g. /courses/astronomy-phd/33/, this is what happens in Sitekit:

1. If an asset is found in the asset tree at that path it is served.
2. If no asset is found at that path, we check if there is a RESTful stem that matches the request.
3. If there is a matching REST stem then we serve that page, passing the corresponding values from the parameter template to it as querystring parameters so, in this example, /courses/astronomy-phd/33 causes the page 'course-list.htm?postid=33' to be served. The astronomy-phd is ignored and not passed through to the query string however it is a good string to retain in the URL for SE purposes.

The 'fixed parameters' field allows a set of fixed querystring parameters to be passed to the page, together with those derived from the REST URL. This allows REST Controller Pages to be used with XML Data Islands that use web-services where every parameter is mandatory. It also allows a RESTful URL to be used to replace a fixed URL with constant querystring parameters. So if for example there was a requirement to pass in some fixed parameters governing access such as a username or access control key these could be added here, concatenating the string with ampersands eg ‘access=external&username=bob’ or ‘siteid=1707’.

The other Parameter template added to that list is /course-by-name/. Using this pattern would result in resolution of URLs like http://demo2-gt.nhs.beta2.sitekit.net/courses-by-name/astronomy-phd/ however to make these work you’d need to modify the standard post list XSLs in use such as  http://yourdomain/Admin/Post/PostListPage.xsl . These are automatically configured to respond to the ‘ignore/postid’ parameter with no modification. As well as that modification you’d also need to consider whether there could be issue with duplicate naming with ‘posts by name’ whereas the postID option removes that problem.

The final RESTful table would look like below:

Example 2

The examples above all relate to the new posts URL but it is important to point out that the RESTful stuff is sitewide and can improve URLs on any data driven legacy pages.

Taking for example the following page where the ID is used to call a web service that extracts the relevant Holidays details from a bespoke database

www.balesworldswide.com/destinations/holiday-detail.htm?id=3687

Now resolves on:

www.balesworldwide.com/holiday/egypt/the-pyramids-to-the-rose-red-city/3687