Java’s SEO blunder: jsessionid

Update: Bryce pointed out a servlet filter you can implement to disable JSESSIONID’s… very nice!

When we started moving GreatSchools from Perl to Java + SpringMVC + Hibernate one of the first things we had to figure out was how to disable jsessionid‘s from getting appended to URL’s when using c:url in a JSP page. Jsessionid is terrible for search engine optimization because crawlers that don’t have cookies enabled will get URL’s from your pages with a jsessionid parameter appended. This makes it virtually impossible for a crawler to match the URL from an inbound link to your site with a page it has already crawled. What’s worse is that you risk having your page rank hurt with Google because it thinks you’re serving duplicate content, ouch!

Take one look on Google and you’ll see millions of results that contain jsessionid in the URL, those pages will have a tougher time ranking well against competitors that have consistent URL’s for users and crawlers.

The intention is good: allow sessions to work for users that don’t have cookies enabled. In reality it never worked that well though because most sites use c:url sporadically to properly encode URL’s and most sites require cookies as a site policy anyhow. The PHP session handling code has the same issue which many folks have battled with, fortunately for PHP users, it’s an option you can disable in your php.ini by setting session.use_only_cookies.

At GreatSchools we wrote our own version of c:url since we couldn’t find any way to disable c:url from writing out jsessionid’s. I think the time is right to make session handling with cookies only the default because it’s the more common scenario and that particular “feature” has caused more problems than the good it was initially intended to do.

This entry was posted in Java, Search Engine Optimization, Web. Bookmark the permalink.

9 Responses to Java’s SEO blunder: jsessionid

  1. Frank says:

    Well, I’m not a servlet Guru, but Resin has a switch in webapp configuration to switch session on/off and to enable cookies and or urls for this. I cannot believe any other servlet container is not having an equivalent.

    Personally I still prefer session ids over cookies, call me oldfashioned.

  2. Todd Huss says:

    Hi Frank, I was never able to find any way in Tomcat to disable session rewriting. This somewhat dated post sums up the problem:

    If the situation has changed and someone knows about it please let me know!

  3. rb says:

    I may be confused regarding the problem here, but aren’t the search engines at fault? I thought that what is behind the ; is a path parameter and does not map to the underlying resource – I could be wrong, the wording in the rfc is not very clear to me.

  4. Todd Huss says:

    Rb, great point, the search engines may be at fault! However, when a good part of your revenue relies on search engine traffic, “their fault” becomes your problem.

  5. Matt Davis says:

    Great article about the jsessionid! I had stumbled on to this article trying to prep my site for launch. I have several c:url tags in my application on my home page. When the browser is first started the links all include the jsessionid, however once I’ve refreshed the page the jsessionids are removed. You mentioned that you had rewritten the c:url tag to disable setting the jsessionid. I know it may be asking too much, but would you be willing to share some of the code ? Thanks!

  6. Ryan says:

    Hey, I have the same request as Matt–any chance of getting you to publish your version of c:url?


  7. This offers a geek-heavy way to solve this problem, by creating a “filter”. It’s a long way from simple. but should work:

  8. Todd Huss says:

    Bryce, I like the solution, it’s easy to implement and will work with servlet containers like Tomcat that (unlike Resin) don’t give you the option to disable JSESSIONID!

  9. Rajender says:

    The link to the filter given by Bryce doesn’t seem to work. Could you please mail me or post again.

Comments are closed.