URL Has Session ID

Element Code: UR-009

What a session ID in a URL actually is

Some server platforms, particularly older PHP setups with cookies disabled, or certain e-commerce and forum software, track a visitor's session by stapling an identifier onto every URL on the site. You have probably seen it: /products/widget?PHPSESSID=8f3a9c2e1b4d or /catalog;jsessionid=A1B2C3D4E5F6. That string exists so the server can remember who you are across page loads without relying on a cookie.

The problem is that the session ID is generated fresh for basically every visit and every crawl. To a person, /products/widget?PHPSESSID=8f3a9c2e1b4d and /products/widget?PHPSESSID=9a1b8c7d6e5f are the exact same page. To a search engine crawler, they are two different URLs until proven otherwise, and Googlebot does not carry a cookie jar between visits the way a browser does, so it gets handed a brand new session ID nearly every time it requests the page.

Why this matters for SEO

This check flags the issue because session IDs in URLs create three compounding problems:

• Infinite duplicate URLs. Every crawl of the same page can mint a new URL variant. Multiply that across a site with thousands of pages and you get an exploding URL space that all resolves to identical content.
• Wasted crawl budget. Google allocates a finite amount of crawling attention to a site based on its perceived size and server capacity. If Googlebot spends that budget re-crawling session-ID variants of pages it already knows, it has less budget left to find and refresh your actually-new content. On large sites this is the difference between new pages getting indexed in days versus weeks.
• Diluted signals. Links, and any equity or relevance signal attached to a URL, can get split across multiple session-ID variants instead of consolidating on one canonical URL, which weakens that page's ability to rank.

None of this is theoretical. It was common enough in the early 2000s that Google's own webmaster guidance has warned against session IDs in URLs for two decades, and it still shows up today in legacy Java (JSESSIONID), classic ASP, and PHP applications that fall back to URL-based sessions when a client blocks cookies.

How to detect it

Run a full crawl with Screaming Frog and check the URL list for query parameters or path segments matching patterns like sessionid, sid, PHPSESSID, or a semicolon followed by a long alphanumeric string. Screaming Frog's "URL" tab with a custom filter, or its duplicate-content report comparing hash values across near-identical URLs, will surface these fast.

In Google Search Console, check the Page Indexing report for "Duplicate, Google chose different canonical than user" or "Duplicate without user-selected canonical." A pile of near-identical URLs differing only by a trailing parameter is a strong tell. You can also use the URL Inspection tool on a couple of the flagged URLs to see what Google actually indexed.

Pull raw server logs and grep for the session parameter across Googlebot's user agent. If you see the same path hit repeatedly with a different session value attached each time, that confirms the crawler is being handed new sessions rather than being recognized as a repeat visitor.

How to fix it, step by step

1. Move session state to a cookie. This is the real fix. Configure the application (PHP: session.use_only_cookies = 1; Java/Tomcat: disable URL rewriting for sessions) so the session identifier never gets appended to the URL at all, regardless of whether the client accepts cookies.
2. Strip existing session parameters with a 301 redirect. If you cannot fully eliminate URL-based sessions overnight, add server-side logic that detects the session parameter for crawler user agents and known bots, then serves the clean URL instead, or better, redirects any request carrying the parameter to the canonical, parameter-free URL with a 301.
3. Add a self-referencing canonical tag. As a safety net, every page should carry <link rel="canonical" href="https://example.com/products/widget/"> pointing at the clean URL. This tells search engines which version to index even if a session-ID variant gets crawled or linked to accidentally.
4. Exclude the parameter in Search Console's old URL Parameters tool if it is still available for your property, or rely on the canonical tag if not, since Google has been phasing that tool out in favor of canonicalization signals.
5. Audit internal links. Search your templates, navigation, and any server-generated links for anywhere the session ID might be getting hardcoded into an href. Internal links should always point to the clean canonical URL.
6. Re-crawl and confirm. Run Screaming Frog again after deployment and verify zero URLs in the crawl carry a session identifier, and check Search Console over the following weeks for a drop in duplicate-URL reports.

What good looks like

A clean implementation stores the session identifier entirely in an HTTP cookie, the URL for a given page is identical no matter who requests it or how many times, and there is one canonical URL per piece of content with no query-string variants floating around in your crawl, sitemap, or internal links.

After: session in cookie /widget/ /widget/ /widget/ 3 crawls = 1 canonical URL

Session ID formats across platforms

FAQ