Why should every modal have its own URL to be indexed?

What does "application state" mean in this context?

An application state refers to any variation of the user interface that presents distinct content. This includes modals (overlaid windows), tabs, filters, variant product views, or dynamically loaded detail pages via JavaScript.

The problem arises when these states do not change the URL in the address bar. The user sees new content, but Googlebot cannot discover it because there is no separate URL to crawl. The bot does not click buttons – it follows links and URLs.

Why does Google emphasize the URL as the entry point so much?

The very architecture of the web relies on the concept of addressability: every resource must have a unique identifier accessible via HTTP. Googlebot has always operated under this paradigm. It retrieves a URL, renders the HTML, executes the JS, extracts the links, and moves on to the next URL.

If a modal opens without changing the URL (for example, using a simple onclick in JavaScript), Googlebot sees just one page. The modal's content remains technically present in the DOM after rendering, but it has no distinct address. The result: it cannot be indexed as a separate entity, making it impossible to rank for specific queries.

What types of content are most impacted?

All content that deserves to be independently discoverable via search. A modal presenting terms and conditions? Probably not critical. A modal displaying a detailed product sheet, a high-resolution image gallery, or a full article? Absolutely critical.

E-commerce sites with quick view product options, portfolios with project modals, SaaS platforms with overlay tutorials – all are affected. If a user could legitimately want to share or bookmark this state, then it must have a URL.

• Each relevant state = unique and stable URL
• Modals, tabs, filters: addressable via URL parameters or fragments
• Non-addressable content remains invisible to Googlebot, even if technically present in the DOM
• The URL remains the only reliable entry point for the crawler – no bot "clicks" on buttons
• Prioritize SEO high-value content: product sheets, articles, downloadable resources

Is this statement consistent with observed practices?

Absolutely. We regularly observe websites losing visibility because their main content is trapped in non-addressable modals. A classic example: a real estate site where each property opens in a modal without a dedicated URL. Google indexes the listing page but never the individual listings. The result: zero traffic from long-tail queries specific to properties.

What Martin Splitt does not specify here is that Googlebot can technically see the content of a modal if it is already present in the initial HTML or loaded via JavaScript upon rendering. However, it will never be able to index it as a separate page without a URL. The nuance matters: visible ≠ indexable as a separate entity.

When does this rule become blurry or debatable?

URL fragments (#) present a historical ambiguity. On the client side, #modal-product-123 changes the visible state of the page. On the server side and for traditional crawlers, this is ignored – the fragment is never sent to the server. Modern Googlebot handles fragments via JavaScript rendering, but their indexing remains less reliable than a true URL with parameters or distinct paths.

[To be verified] Google has never published clear documentation on the differentiated treatment of fragments vs parameters for indexing application states. Empirically, we observe that URLs with parameters (?product=123) or distinct paths (/products/123) perform better for indexing than fragments (#). But no official numerical confirmation exists.

What common misinterpretation should be avoided?

Do not confuse "Googlebot can see the content" with "Googlebot can index it as a distinct page." A site can have a perfect Lighthouse score, flawless JS rendering, and yet zero indexing of its modals – simply because they do not have a URL.

Another trap: thinking that adding data- attributes or JSON-LD in a modal compensates for the lack of a URL. No. Structured data helps enrich an indexed page but does not create a new indexable page. Without a URL, there is no entry in the index – end of story.

How to quickly audit if my modals are addressable?

Open your developer console, activate a modal, and check the address bar. Has the URL changed? If not, there's a problem. Then test by copying this URL into a new tab: does the modal reopen directly? If yes, that’s a good sign. Otherwise, the state is not truly addressable.

Also use the URL inspection tool in Search Console on a page containing a modal. Look at the HTML rendering: do you see the content of the modal? Probably yes. But now search for this modal as a distinct indexed page using site:yoursite.com "exact modal title". If nothing comes up, Google is not indexing it as a separate entity.

What technical strategy should be adopted to make modals addressable?

The most robust method: generate a unique URL with a parameter or path (/products/design-chair or ?view=product&id=123). On click, modify the URL using the JavaScript History API (history.pushState()) without reloading the page. The user sees the modal open instantly, but the URL changes. Googlebot can crawl this URL directly and index the content.

A less reliable but quick alternative: use URL fragments with JS handling (#modal-123). Upon loading, your script detects the fragment and opens the corresponding modal. Googlebot renders the JS, detects the fragment, and can index the state. But indexing remains more unpredictable than with a real URL. Reserve this approach for secondary content.

What if a complete overhaul isn’t feasible immediately?

Prioritize. Identify the modals that generate potential traffic (product sheets, articles, resources). Migrate these first to distinct URLs. For purely UI modals (confirmations, alerts, forms), keep the current system – they hold no SEO value.

Implement an automatic detection system: a script that identifies modals containing more than X words or certain types of content (h1, images, prices) and alerts the dev team. This avoids repeating the mistake with every new feature. These technical optimizations often involve profound changes to the front-end architecture and can lead to regressions if executed poorly – support from a specialized SEO agency can help secure these projects and avoid costly mistakes.

• Audit all current modals: which contain SEO valuable content?
• Implement history.pushState() to change the URL when opening a modal without reloading
• Test each generated URL in direct navigation: does the modal open correctly?
• Check indexing via Search Console and targeted site: searches
• Document technical patterns so that every new modal adheres to the rule
• Monitor Core Web Vitals: URL changes should not degrade CLS or LCP