Progressive web apps (PWA)

A progressive web app is a website that declares application metadata in a manifest and installs a service worker, so a browser can install it to the home screen and run it offline. It is not a framework or a product category — it is two web platform features and a secure origin, added to a site that already exists.

The Web Application Manifest specification, a W3C Working Draft dated 13 August 2026, defines "a JSON-based file format that provides developers with a centralized place to put metadata associated with a web application": the name, links to icons, the preferred URL to open when a user launches it, a default screen orientation, a display mode, and a URL scope that bounds where the manifest applies.

The Service Workers specification, a Candidate Recommendation Draft dated 12 August 2026, supplies the runtime half. Its core is "a worker that wakes to receive events" — most importantly a fetch event, backed by a cache storage mechanism comparable to HTTP caching, which is how a page can be served when the network is not there. The interface is defined as a secure context, so a service worker will not register over plain HTTP.

What a browser demands before it offers to install

Chrome publishes explicit install criteria, and they are narrower than most teams assume:

• Served over HTTPS.
• A manifest containing short_name or name.
• Icons including a 192px and a 512px asset.
• A start_url.
• A display value of fullscreen, standalone, minimal-ui or window-controls-overlay.
• prefer_related_applications absent, or false.

Two of the criteria are about the person, not the code: the user must have clicked or tapped on the page at least once, at any time — including during a previous load — and must have spent at least 30 seconds viewing it. Installability is earned by engagement as well as configuration, which is why a correct manifest alone does not produce a prompt.

The part that matters for being cited

None of the above is read by an agent answering a question about you, and that is the point worth internalising.

A service worker is installed by a browser and controls pages within its scope on subsequent visits. An assistant fetching your URL to answer a live question has no installed worker, no cache and no second visit. It receives exactly what your origin server returns to a cold, one-shot request. If that response is an empty shell that assembles its content in JavaScript, the agent has retrieved a document with nothing in it — and a document with nothing in it cannot be quoted, cited or contradicted.

That is not a hypothetical risk of the PWA pattern; it is the pattern's default shape. The app shell exists precisely to return a minimal HTML skeleton fast and fill it client-side. It is an excellent architecture for a returning, installed user and a poor one for a first, scriptless fetch. See crawling and indexing.

The second structural risk is the URL. An app-like build tends to render views by client-side routing under one path. A retrieval system cites a URL; if the only URL is the front door, the only thing it can cite is the front door, and a specific question about one view has no specific target to land on. Every meaningful view needs a real, server-addressable URL, and each of those needs a correct canonical declaration so the variants a client router produces do not fragment.

Failure modes

• Shipping an empty document to non-browser clients. The most common and the most expensive: perfect in Chrome, blank to a fetcher.
• One URL for everything. Nothing to cite but the home page, and no passage-level landing target.
• Assuming the service worker helps a crawler. It does not run for a one-shot fetch, so any freshness or offline benefit it provides is invisible outside an installed session.
• Serving a stale cached page to a returning human. A cache-first worker without a revalidation path will happily hand back a version of a page you corrected weeks ago.
• Treating installability as an SEO feature. A manifest is metadata for an operating system, not a ranking or retrieval signal. Judge the page by what it returns cold; Core Web Vitals still describe how well it does that.
• Repeating the AMP mistake in reverse. AMP constrained the page to guarantee speed; the app shell abandons the server-rendered document to guarantee app-like transitions. Both trade away something a fetcher needs.

How to keep both properties

Render the substantive content server-side and let the service worker enhance the experience for repeat visitors, rather than being the thing that produces the content in the first place. Give every view its own URL that returns its own HTML to a cold request. Keep the manifest for what it is for — installation on a device — and verify the page the way an agent sees it: one request, no JavaScript, and check that the answer is still in the response.