Where to submit your PWA — and which directories a machine can still read

Q: How do I check a directory is readable before submitting?

Request its homepage without a browser — `curl -sL https://example.com | wc -c` — and look at the byte count. A server-rendered catalogue returns tens or hundreds of kilobytes containing anchors. A client-rendered one returns a few hundred bytes and no links. Then fetch `/sitemap.xml` and count the ` ` entries; if it is a sitemap index, follow one level down.

Short answer

Submit to store.app, pwastore.io and pwa.directory. Those three serve an inventory a crawler can read without running JavaScript: roughly 1,350, 818 and 550 entries respectively. The fourth, findpwa.com, still answers with HTTP 200 but returns 33 bytes and zero links — its catalogue exists only after JavaScript runs, and the one machine-readable feed it publishes is blocked in its own robots.txt. Submitting there costs you nothing but buys you nothing either.

What we measured, and how

On 17 August 2026 we requested each directory the way a crawler does: a plain HTTP GET, no JavaScript executed. We then read the sitemap it declares, following one level down when the sitemap is an index, and counted the entries. Where a site publishes its catalogue as an HTML page rather than XML, we counted the links on that page instead.

This is a narrow test and it is worth saying what it does not measure. It says nothing about the quality of a directory's listings, its traffic, or whether a human editor reads submissions. It measures one thing only: whether a machine arriving without a browser can see that your app is listed. That is the thing that decides whether the listing works for you in a search engine or an AI assistant.

Mentioned here: ✏️ Excalidraw, 🖼️ Photopea, 🌀 Wormhole

The four directories, measured

**store.app** publishes its catalogue as an HTML sitemap: 1,350 app links, served in the response, no JavaScript needed. It is the largest of the four by some distance. We could not find a submission path from the homepage, so getting listed there appears to go through another route.

**pwastore.io** declares 818 URLs in an XML sitemap, last modified 16 August 2026, and links a /submit page from its homepage. It is the closest peer to this directory and, on inventory alone, the larger of the two.

**pwa.directory** — this site — declares 550 URLs, last modified 17 August 2026, with /submit linked from the homepage. We are the smallest of the three readable ones. We state that plainly because you can verify it in about a minute, and a comparison that puts its author first is worth nothing to you.

**findpwa.com** answers HTTP 200 and redirects to www, where it serves 33 bytes: an opening <!DOCTYPE html> and an <html> tag. Zero anchors. Its sitemap returns no URLs. It does publish an RSS feed of new apps — which its own robots.txt disallows.

Why "still online" is not the same as "still readable"

A directory built entirely on client-side rendering looks perfectly healthy in a browser. You visit it, the apps appear, everything works. The failure is invisible from where you are standing, because your browser runs the JavaScript that a crawler does not.

Google executes JavaScript, eventually and unevenly. Most other readers do not. The crawlers behind AI assistants generally take what the server sends and move on. So an app listed on a site that serves 33 bytes is, for those readers, not listed at all — the page exists, the entry exists, and nothing that reads the web without a browser will ever know.

This is the same failure we measured inside the apps themselves: 39% of installable web apps survive with the network off, and the ones that fail look fine to the developer who built them online. Same shape, one layer up.

What to do if you are choosing where to submit

Submit to all three readable ones. They are free to submit to, they do not compete with each other for your listing, and the marginal cost of a second and third submission is a few minutes.

Before you submit anywhere else, run the same test yourself: request the directory's homepage with curl and look at what comes back. If the response is a few hundred bytes with no links in it, the catalogue is not being read by anything that does not run a browser. That single check takes ten seconds and it is the whole method of this article.

And check what the directory does with your entry afterwards. A listing that is a name and a URL is a row in a database. A listing that describes what the app does, in prose, is a page that can be quoted — which is the difference between being indexed and being cited.

Frequently asked

Does submitting to several directories hurt my SEO?

No. Directory listings are ordinary inbound links from third-party pages. There is no duplicate-content issue because you are not publishing the same page twice — each directory writes its own entry. The only thing to avoid is submitting the same app repeatedly to the same directory, which wastes a reviewer's time and nothing else.

How do I check a directory is readable before submitting?

Request its homepage without a browser — curl -sL https://example.com | wc -c — and look at the byte count. A server-rendered catalogue returns tens or hundreds of kilobytes containing anchors. A client-rendered one returns a few hundred bytes and no links. Then fetch /sitemap.xml and count the <loc> entries; if it is a sitemap index, follow one level down.

Is a paid listing worth it?

It depends entirely on what the payment buys. Paying to be reviewed sooner buys you time and nothing else. Paying for an editorial listing that stays — a page describing what your app does, in prose — buys an asset that can be quoted by a search engine or an assistant long after the placement window closes. Ask which one you are buying before you pay.