Stable, unique URLs: Sessions in URLs

What is a session?

Sessions are a method for identifying visitors. In principle, visitors to websites are anonymous. When a browser sends a download request to a site, the web server approached is not told who the visitor is. This makes it difficult, for example, to track the surfing behaviour of a visitor or recognise a returning visitor. This is why sessions were invented.

When visiting a site, each visitor is given a unique identity number that is kept in his or her browser (as a cookie). This identifying number is sent to the web server upon each visit to a subsequent page. After a certain period, the identifying number lapses (for instance, when the visitor leaves the site), and (s)he has to identify himself or herself again.

In exceptional cases, and sometimes as a result of a deliberate action on the part of the web developer, this identifying number is added to the URL of the page in question.

The problem

If the site can only function thanks to this form of identification, a returning visitor following the link from his or her Favourites will not be able to find the page back, as this identity is no longer valid. For the same reason, other sites and search engines won't be able to link to this page either. Because of such problems, many search spiders will not even index URLs containing sessions.

Avoid using sessions in URLs.

Guideline R-pd.4.3

If the developer decides to use sessions, (s)he must take the following points into account:

  • Session support should not be a condition for the site to function. This may mean that some visitors cannot be identified. In spite of possible functionality restrictions, there is no reason to deny them the information on the page.
  • Set up the server to not create sessions in URLs, but simply to make use of sessions using cookies.

In exceptional cases, a system will depend on visitor identification, for example, in order to remain logged onto a CMS. Failure to require identification may constitute threat to the system security. Please note that alternatives can be devised to allow access to secure sites, for instance HTTP authentication.


Web Guidelines version 1.3, November 2007.