A PWA is an architectural decision with search consequences
Choosing a Progressive Web App is usually justified by user experience: speed after the first load, offline capability, app-like navigation, installability. Those are real benefits and they are not in dispute here.
What often goes unexamined is that the same decision changes the contract between your site and search engines. Content delivery, link discovery, URL identity and metadata all move from the server response into application code.
What changes when you adopt a PWA
- Content may arrive after the initial response instead of within it
- Navigation may be handled by the router rather than by links in the HTML
- URLs may be resolved on the client rather than by the server
- Metadata may be set by components at runtime rather than in the response
- Status codes may no longer reflect whether a page exists
- A service worker may sit between requests and responses
- The same content may be reachable at multiple URL variants
- Rendering behavior may differ between templates within one app
Discovery and evaluation are separate problems
Search engines must first find a URL, then decide whether the content at that URL justifies indexing. A PWA can break either step independently.
Discovery breaks when navigation is not expressed as crawlable links, so entire template groups are unreachable. Evaluation breaks when the URL is reachable but what search engines render contains little of the content users see.
This is why 'the page is in the sitemap' and 'the page is indexed' are so often disconnected in Progressive Web Apps.
None of this makes PWAs unsuitable for SEO
A Progressive Web App can be fully crawlable, renderable and indexable. It requires deciding rendering strategy deliberately, keeping real URLs and real links, and validating the rendered output rather than assuming it.
The implications are manageable when they are treated as requirements up front. They become expensive when they are discovered after launch.