Yes, it sounds like it's a session ID, and creates duplicate-content issues. Make sure that you suppress these for search engines. Although one or more of the major search engines is now introducing technology to "learn" which query string parameters are sessions IDs and to ignore them, it's a good idea to suppress them for the time being.

Jim

If the ID is for tracking only, you might want to consider cookies instead. Also, there's a canonical tag [webmasterworld.com] now available to avoid dup content issues.

so implementing the canonical tag will help with my multiple generated ?id= variables

For those search engines that support the tag, yes. But as with other problems for which specific-search-engine-proprietary and semi-proprietary "band-aid" fixes are available, a correctly-implemented server-side solution helps with *all* search engines.

IMHO, it's less productive and more "risky" to rely on back-end processing by the various search engines than it is to put your server in order from the outset. For example, I haven't even considered using the new canonical-URL tag, because it is impossible to fetch content from a non-canonical URL of any kind from any of my servers; From the moment a new site goes on-line, any non-canonical request gets redirected to the canonical URL with one single 301 redirect. So, I simply don't have to worry about whether the various search engines "get it right" when processing these proprietary fix-ups -- ever. YMMV.

Jim

From the moment a new site goes on-line, any non-canonical request gets redirected to the canonical URL with one single 301 redirect

Sure, and cookies would allow you to do that, because only 1 URL would serve that content.

But if you want to use SessionIDs, there is multiple URLs live on the site, all serving the same content.

The canonical tag would be the simplest implementation with least scope to go wrong. You could even dynamically serve it, using a script to stip the sessionID on-the-fly.

The 'correct' way would be your original suggestion, using user-agent detection to serve different URL forms to bots and non-bots, but that has far more opportunity to go wrong if badly implemented.

The canonical tag was designed from situation just like this.

so on every page should I include the tag with the homepage URL in it?

NOOOOOOOO!

The canonical tag need s to contain the URL without the SessionID, so it is clear that the SessionID is an irrelevant parameter WRT the content being served.

I mean do I include this in the header for all of my pages?

<link rel="canonical" href="http://www.example.com/" />

Thats fine for the homepage, but not any other pages.

On a URL that looks like this:
http://www.example.com/subdir/page1?id=00000000001

you need
<link rel="canonical" href="http://www.example.com/subdir/page1" />

It might get a bit complicated if you have content-adjusting variable such as
http://www.example.com/subdir/page1?ContentModifier=1&id=00000000001

You would then need
<link rel="canonical" href="http://www.example.com/subdir/page1?ContentModifier=1" />

You might be best implementing a script that dynamically inserts the tag (minus the ID= string) into the header as the page is served.

[edited by: Shaddows at 3:03 pm (utc) on Mar. 9, 2009]

ah gotcha!

understand this totally now. will defo produce a script to take the leg work out of this for me.

While you're at at it, you need to strip any other non-modifying variables as well.

And if you are implementing query strings, introducing some logic to force a "preferred order" would save you some long-term hassle.

The Canonical tag is useful in defining original content but I don't see it as canonicalizing URLs to concentrate PR.

Thoughts?

You've very precisely missed the point of the canonical tag.

Say you have
www.example.com/page

It serves the same content as
www.example.com/page?ReferTrack=a01a

And the same content but different order to
www.example.com/page?ReferTrack=b01b&ListOrder=1

Which is in turn PRECISELY identical to
www.example.com/page?ListOrder=1&ReferTrack=b01b

All these will have different backlinks, all with split PR. There are better ways of dealing with the problem, but if you use the canonical tag, each would contain
<link rel="canonical" href="http://www.example.com/page" />

For blog software that will accept infinite "keyword" subdirectories, you can also insert a tag for the preferred "friendly" one.

What you really don't want to be doing is serving the same content at different URLs and saying "look, this was here first"

Thanks Shaddows. And, no, I didn't misunderstand that point. What I didn't see when I first read about the tag when it was announced on Google's blog was that they would make attempts to pass PR to the Canonical content referenced in the tag. I reread their post as well as some others and it appears that they will make attempts to do so. Not quite as solid as a 301 redirect but, based upon what I see, the tag will likely become more solid and useful in time.

From my perspective I would implement the tag but if a given page is important, I'd still look to use redirects. Currently the impression I'm getting is that the SEs are treat the tag like the robots.txt file rather than a command.

Yeah, they say its a "strong indicator"- which I take to mean there will be some tolerance of webmaster incompetance which would break a site using the "proper" techniques such as 301s (infinite loops for example).

This tolerance is paid for by ceding the final decision to SEs.