If your content requires a session or cookie state to render, Google may not see it.
A lot of modern sites assume the visitor arrives carrying state. A logged-in cookie. A region preference set on first visit. A consent flag. A session token. The page renders different content based on what the server or the browser already knows. That is reasonable for human visitors. It is a problem for Googlebot, because Googlebot does not arrive with any of that.
Google said this directly in its 31 March 2026 crawler blog post:
“However, remember that the WRS can only execute the code that the crawler actually retrieved. Furthermore, the WRS operates statelessly, it clears local storage and session data between requests. This may have particular implications for how dynamic, JavaScript-dependent elements are interpreted by our systems.”
Source: https://developers.google.com/search/blog/2026/03/crawler-blog-post
The phrase that matters is “operates statelessly.” Every fetch starts from zero.
What stateless actually means
Local storage is empty. Session storage is empty. Cookies from any earlier visit are gone. Every URL is fetched as though by a visitor who has never been on your site before.
So if your page says “show product details only after the user accepts cookies,” Googlebot does not accept cookies, and the product details never appear. If your page says “render regional pricing once we read the user’s geo cookie,” Googlebot has no geo cookie, and you render either a default state or, often, an empty one.
I have seen both of these on real sites during audits. The page looked fine in a browser. The same URL fetched as Googlebot was very different.
Patterns that break under stateless crawling
The cookie consent banner is the most common. The body content is held back until the user clicks “accept.” Googlebot never clicks. The body never renders.
Personalisation modules are the next. Recommendation feeds, “recently viewed,” “for you” rails. They draw on session data that does not exist for a stateless crawler. If those modules carry your main internal links, you have an indexing problem you may not have noticed.
Region-specific content keyed off a stored preference is the third. With no preference set, the crawler either falls into a default branch you forgot to design, or gets pushed to a generic page that is not the canonical version of the content.
What to do instead
Render the full content in the initial HTML, and use cookies only to layer personalisation on top.
Where state matters, detect it server-side and serve a complete default version when none is present.
Keep critical parts (primary text, internal links, structured data, meta tags) outside any state-dependent rendering path.
Personalisation is fine. Personalisation as a precondition for content is not.