Download websites that use PWA

About PWA

A website does not buy PWA the way it buys a shopping cart or a support widget. What sits behind the label is a set of browser capabilities the site has chosen to declare: a web app manifest, a registered service worker, an icon set and a start URL that together let a browser install the page onto a phone home screen and serve something useful when the network drops. Any competent front end developer can add the pieces in an afternoon, and plenty of teams add half of them and stop.

Because the capability is declared rather than purchased, the count behaves differently from a vendor count. As of September 2026 we detect PWA signals on 8,064,443 sites, and the population mixes three quite different things. Some sites are deliberate app replacements, built by retailers and publishers who wanted push notifications and offline reading without paying an app store toll. Some are ordinary marketing sites whose CMS or theme emits a manifest by default, so the owner never made a decision at all. The rest sit in between, with a service worker installed for caching and none of the app ambition attached.

Our taxonomy files the entry under Miscellaneous, which is a convenience of the classification rather than a description of the thing. Nothing here is a framework. The practical consequence is that a positive flag tells you about a site's engineering posture instead of its stack. A site that registers a service worker has a build step, a deployment process capable of shipping a versioned asset, and someone on staff who thinks about caching. Attributes like those are uncommon among small business websites, and they correlate with budget more reliably than any single library does.

The standard has been in circulation since 2015, long enough that adoption now splits along platform lines rather than along an early adopter curve. Commerce platforms and headless storefronts ship the manifest as part of the product. Traditional page builders mostly do not. Watching which platforms turn the capability on by default is a cheaper way to track ecosystem maturity than reading release notes.

Geography follows publishing volume rather than regional preference. United States accounts for 4,564,503 of the sites we see, and .com is heavily represented in the domain mix, which is what you would expect from a capability that costs nothing and carries no regional licensing. A distribution like that is a warning against reading the country column as demand.

Detection is inferential and we would rather say so plainly. We look for the manifest and the service worker registration in delivered markup and headers. A worker injected at runtime by a script we do not execute will be missed, and a manifest left in a template by a previous agency will be counted even though the offline behaviour was never finished. Undercount and overcount both exist here, pulling in opposite directions, and a per domain checker resolves neither.

The reason to take the list rather than test domains one at a time is that the interesting question is rarely about a single site. Whether app like behaviour has reached a retail vertical, whether a platform vendor changed its default between releases, whether the accounts in your pipeline are technically ambitious enough to be worth an integration conversation: each of those is a question about a population. The downloadable file supplies the population with its other columns attached, so the capability can be crossed against platform, country and domain suffix in one pass.