Crawling and indexing are two different gates
A URL has to be found before it can be evaluated, and evaluated before it can be indexed. Progressive Web Apps can fail at either gate, and the fixes are unrelated.
Reading a coverage report without knowing which gate failed is how teams end up shipping the wrong fix — adding sitemap entries for pages that were already discovered, or improving content on pages crawlers cannot reach.
What blocks crawling in a PWA
- Navigation implemented as interactions instead of links
- Pagination, filters and facets that exist only in client-side state
- Views reachable only after a user action such as a click or search
- Blocked scripts or resources needed to produce links
- Service worker behavior that alters responses to non-browser clients
- Infinite scroll with no crawlable paginated equivalent
What prevents indexing after discovery
- Rendered output containing little or no unique content
- Near-identical app-shell output across many URLs
- Canonical tags pointing away from the page itself
- Missing pages returning 200 instead of 404
- Metadata absent from the rendered output
- Content that requires interaction before it appears
Reading the pattern
The distribution of the problem usually identifies the cause. If one template group is missing entirely, discovery is the likely gate. If URLs across the app are discovered but not indexed, the rendered output is the likely gate.
If only the homepage performs, both are typically failing: crawlers cannot reach deep templates through links, and the templates they do reach carry too little unique content to justify indexing.