ZoomEye scan counts 8.16M WordPress installations and 541,960 Let's Encrypt certificates

Two write-ups published on dev.to on 21 October 2026 analyse the results of an internet-wide scanning session run the previous evening, and together they attach hard numbers to parts of the web usually discussed only in generalities. The queries, directed at the ZoomEye search engine between roughly 22:32 and 22:37 UTC on 20 October 2026, returned 8,156,602 identifiable WordPress installations and 541,960 assets presenting a Let's Encrypt certificate, alongside web server counts running into the hundreds of millions.

What the queries returned

According to the dev.to posts, which used sub_type="all" and a page size of one record to read match totals, the session produced the following figures:

Query	Matched assets
app="Apache httpd"	599,482,423
app="nginx"	313,028,543
http.header.server="nginx"	284,114,163
app="WordPress"	8,156,602
app="WordPress" && country="US"	5,155,170
ssl.cert.issuer.cn="Let's Encrypt"	541,960

The two pieces agree on the shared nginx figure of 313,028,543.

Reading the WordPress number

The WordPress count sits far below the web server totals, which the dev.to analysis attributes to how fingerprinting works: a web server fingerprint matches every host running that software, while a CMS fingerprint requires the scanner to recognise the application sitting on top of it.

The US figure is the more striking one. 5,155,170 of 8,156,602 — about 63% — resolve to the United States, but the analysis is explicit that this reflects hosting geography rather than ownership. Cloud providers with large US footprints dominate internet-facing infrastructure, so a German company running its site in a US cloud region appears in the US count. The country filter is therefore good for finding where infrastructure is hosted and poor for working out who owns it.

The security reading is similarly cautious. WordPress core is patched routinely; the persistent risk sits in plugins and themes, where third-party maintainers set the update pace and installed versions are generally invisible to an external scanner. That produces an asymmetry: scanners can only count installations whose core is identifiable, while the installations exposed to a given plugin flaw cannot be measured from outside at all. Estimates derived from plugin download counts, the post notes, gauge how widely a plugin was adopted, not how many live sites are exposed.

The Apache and nginx figures serve mainly as calibration. They are consistent with the two servers' respective positions in hosting and enterprise deployments, and a patched, correctly configured server behind a CDN is not an exposure problem even though it gets counted.

What 541,960 certificates means

The Let's Encrypt figure is not the number of Let's Encrypt certificates in existence, nor the number of encrypted web services. It counts assets whose observed TLS certificate carried that exact issuer common name at collection time. Let's Encrypt issues through several intermediate authorities, the issuer field can be recorded differently depending on how the chain is parsed, and a certificate served through a CDN may belong to the CDN rather than the origin. The query also counts assets rather than certificates or domains, so one multi-name certificate may correspond to many assets or to one.

The certificate post argues three uses are genuinely reliable: expiry tracking, since a certificate's not-after date is authoritative; issuer concentration, where an issuer an organisation did not expect on its assets usually points to an unmanaged proxy, a CDN or an acquired domain; and unexpected subject alternative names, which reveal internal hostnames, staging environments and forgotten subdomains precisely because certificates must list every name a service answers to, in the clear, to anyone who connects. Names placed in publicly trusted certificates are published to certificate transparency logs permanently.

It also flags three common misreadings: an issuer is not evidence of encryption in transit, since self-signed certificates encrypt too and simply fail validation; an issuer carries no information about what runs behind the endpoint; and a valid certificate does not imply a maintained system, because ACME automation has driven issuance and renewal costs close to zero while leaving application patching an entirely separate process.

Guidance for operators

The posts pair the measurements with practical advice. On the WordPress side: inventory by installation rather than domain, track plugin and theme versions centrally, remember that a managed host patching core does not patch plugins, and treat external scans as a cross-check that can surface installations nobody documented. On certificates: compare observed names against DNS inventory, group by issuer, track expiry separately from patching, and verify that internal services are not presenting publicly trusted certificates. Both posts also recommend recording the exact query and timestamp, since a count without its definition cannot be reproduced.

Why it matters

These measurements quantify the web's backbone, but their real value lies in the measurement literacy around them. Eight million WordPress installations sounds like an exposure headline; the dev.to analyses frame it as context — a stable baseline to measure change against, and a reminder that the countable population is not the at-risk population. Plugin versions and application maintenance, where the actual risk concentrates, are invisible to the scans most often quoted. For defenders, the actionable output is the gap: installations and certificate-covered hostnames that show up in external data but not in internal inventories.