Our early thoughts on URLs
This a post by Calum Shepherd, our Head of Digital Strategy.
In the simplest terms a URL is the location of a web page that you visit in your web browser. Handily, if you ever need to visit that web page again in the future, you can use its URL to go directly to it. You may know them as web addresses, as they are presented within the browser address bar.
URLs are important for a number of reasons. Users, bookmarks and apps such as Pocket use them to remember where pages are located. Searchers on Google, in addition to Google itself, also use them to gauge whether or not the page they are about to visit will be relevant for a given search query.
We thought about what we needed and how that would be reflected in our URLs:
- Clean, clear and easy to understand
- Relevant, but concise length
- Include the task where it exists e.g. “apply-for-council-tax”, as opposed to just “council-tax”
- Use “-” for joining words, as opposed to “_”
- Following a parent / child structure for categorisation
- Avoiding duplication through consistent serving
You can read more on guidance in relation to URLs on Google’s Webmaster Tools Help. If you are interested in how Google Search works, then there is a worthy read on this subject as well. We’ll be publishing more on both search and URLs in the coming months, in the form of guidelines.
Browse, Information Architecture and URLs
We are focused on getting the fundamentals right, ensuring content is presented as clearly as possible within the alpha. We’re also keen to make sure that any move from alpha to beta is as painless as possible as well – with URLs underpinning these ambitions.
We will be in a unique position in terms of how we expect the site to grow in the longer term and needed an approach to reflect this.
We looked at:
- Various modern e-commerce websites
We found a range of examples, with some following a best practice led format – hitting some of our core needs.
However our colleagues at Government Digital Service (GOV.UK) took an approach where content items were disconnected from the browse structure and located at the first possible opportunity e.g. https://www.gov.uk/car-tax.
We took the approach of GOV.UK, with minor variations, for the following reasons:
- We can amend and remove categories and sub-categories within our browse information architecture without having to move content items located under these areas
- We can reduce the need for vanity URLs in many instances. Vanity URLs are short URLs normally used for marketing campaigns, which redirect to longer URLs within a website
We’re going to be reviewing this over time, alongside the implications of the decision. Considerations include not following the parent / child approach and not having site-links available within the search engine results pages.
Guidance for URLs – technical (in addition to our principles for creating them):
- Avoiding the use of special characters
- Serving all URLs with a trailing slash, in lower case and on WWW URLs, redirecting all other requests
- Serve on either HTTPS, or HTTP – not both, redirecting all other requests
- Be designed without the need for parameters (out-with site-search)
- Limit max length to 2,000 Characters
We will see how it works! If our SEO isn’t impacted and users don’t find it confusing, we’ll have an excellent way to adapt and change our browse based information architecture without requiring mass 301 Redirects. Once we have a product reaching early maturity we can then reassess.
We’ll be sharing this post and more on social, so follow the team via @mygovscot on Twitter for more updates. Have a comment? Let us know below!