How a session ID in the URL works
A website needs some way to recognise a returning visitor between clicks — to keep a basket filled, or a login alive. Cookies do that job now. Before cookies could be relied on, many platforms carried the identifier in the address instead, appending something like a session token to every internal link the page produced. Older PHP, classic ASP and some Java systems all did this, and a few booking and ticketing engines still do.
The result is that no two visitors ever see the same address. Open a category page in one browser and it carries one token; open it in another and it carries a different one. The page is identical, the address is not, and a crawler arriving through those links collects a fresh URL on every visit.
Why session IDs in URLs matter
They create duplication with no upper limit. Every crawl produces new addresses for pages that already exist, so crawling effort is spent re-reading the same content under new names while genuinely new pages wait. Links and rankings scatter across versions that will never be seen again, and analytics reports a long tail of one-visit URLs instead of one page with real traffic.
There is a security side as well, and it is the more urgent one. Anyone who copies the address out of the bar and pastes it into a message, a support ticket or a public forum is handing over a live session. Whoever opens that link may land inside the original visitor’s account. Identifiers in the address also end up in server logs, in referrer headers sent to other sites, and in any tool that records page paths.
Where it goes wrong
The usual mistake is treating it as a tidiness problem and reaching for a canonical tag. A canonical helps search engines, but it does nothing about the token still being handed to real people, still leaking into logs and still appearing in shared links. The identifier has to stop being generated, not simply be explained away.
The second mistake is blocking the pattern in robots.txt. That stops crawling but leaves every link into those URLs stranded, and the underlying platform carries on minting them for visitors. The third is fixing the front end while a sitemap, an email template or a printed campaign URL still carries an old token.
What to do about it
Turn off URL-based sessions at the platform level so the identifier is only ever carried in a cookie or an authorisation header. In most PHP stacks that is a configuration switch; in older frameworks it may mean changing how links are written. Once the site stops producing them, redirect any address that still carries a token to the clean version of the same page with a permanent redirect, and give every page a self-referencing canonical.
Then verify. Crawl the site twice from a clean browser profile and compare the two URL lists — if they differ, tokens are still being generated somewhere. Check that internal search, pagination and the basket flow all produce stable addresses. This is the kind of thing worth catching during a technical SEO review, alongside the wider question of parameter handling and whether your canonical tags point where they should.