Somewhere right now a developer is finishing a small Python library. They will type one command to publish it, close the laptop, and think no more about it.
A page appears on PyPI. Then a second page, about them.
Neither page was written by anybody at PyPI. Nobody reviewed it, chose a headline for it, or decided it was worth having. It exists because the product worked.
Do that a couple of million times and you have one of the largest catalogues on the internet, run by a team that employs no writers at all.
Results at a glance
PyPI publishes about 1.1 million pages about people and 870,000 about packages.
The layer nobody thinks of is the bigger one.
Nobody here writes a page
Open the page for requests, the library almost every Python developer has installed at some point.
Everything on it arrived in a single upload. The description is the project's own readme. The install command is generated from the name. The maintainer list, the release dates, the licence and the links all come out of a metadata file the developer never thought of as content.
That is the entire mechanic, and it is worth saying plainly because it sounds too easy: PyPI's catalogue is a rendering of its database. The editorial budget is zero because there is no editorial.
More about people than packages
We counted every one of the 257 sitemap shards, and the split was not what we expected.
Most teams building something like this would count the packages and stop. The profiles are the byproduct of the byproduct, and they are the larger half.
There is a general lesson in that. When your content comes out of your database, every table you already keep is a page type you have not built yet — and the join table is often bigger than the thing it joins.
The same template, twice
Here is the bill for doing it this way.
Same template, same fields, same quality of scaffolding. The difference is entirely what the developer happened to upload, and here they uploaded a readme whose headings never rendered and a summary that begins "A easy to setup".
PyPI cannot fix that page, because fixing it would mean editing somebody's package metadata. So it does the only sane thing and publishes it exactly as given.
This is the honest trade. When your pages come from your data, the quality of your pages is the quality of your data, and you have given up the right to improve it.
What two million pages earned
We ran our Backlink Analyzer over the domain, expecting the ratio to be poor at this scale.
It is poor, and it is also the wrong way to read the number. PyPI earns roughly one referring domain for every twelve pages — below GeeksforGeeks, well below Healthline.
But look at the concentration. Sixteen million backlinks from 161,672 domains means the average linking site links about a hundred times. Those are not editorial links. They are install instructions, dependency lists, badges and generated documentation — machines linking to machines.
Which is the real finding here: the same automation that built the pages also built the links. PyPI has domain rank 96 not because people write about it, but because being the place packages live means every project that uses one points at it forever.
The cleanest audit we have measured
One more number, and it is the one that surprised us most.
Our Website Audit gave pypi.org 91 out of 100 — the highest of any site in this series, with zero critical issues and 118 checks passed. Healthline scored 74. Levels.fyi scored 83.
The reason is structural, not diligent. A page assembled by a template cannot forget its title tag, cannot ship a missing meta description, and cannot drift out of pattern on a Friday afternoon. Consistency is free when nobody is typing.
Copy this in an afternoon
This is the most portable mechanic in the series, and you probably already have the raw material.
1. List the tables you already keep. Products, users, orders, locations, categories, integrations. Each is a page type. You are not creating content, you are exposing records you already own.
2. Build the people layer too. PyPI's larger half is profiles. Whoever supplies, makes, sells or maintains the thing usually deserves a page, and nobody thinks to build it.
3. Make the template carry the quality. If the data is thin, the page must still be well-formed. Get the title, description, headings and internal links right once and every record inherits them.
4. Decide what happens when a record is bad. PyPI publishes broken readmes because it will not edit user data. That is a defensible choice. Publishing thin pages without making that choice on purpose is not.
What you cannot copy
Being infrastructure. PyPI's links come from being the place a command points at, not from anybody choosing to recommend it. If your records are not something other software has to reference, you will get the pages without the links, and the pages alone will not carry you.
And here is what we could not check:
We did not measure PyPI's AI visibility. Our checker sits behind a bot challenge that has been unreliable all week, and we would rather report nothing than a number from a run that did not complete.
We did not publish a keyword figure. The tool returned an implausible volume on the previous case study, including a negative one, and that defect is still open.
Declared pages are not indexed pages. 1,968,436 is what the sitemaps list. How many Google keeps is a different number that only PyPI can see.
We were heavy-handed measuring this one. Counting every shard twice meant fetching roughly four million URLs from a service run on donated money, and PyPI started serving our crawler a bot challenge shortly afterwards, which is entirely fair. If you repeat this census, sample it.
No traffic or revenue data. None was available and none is claimed.
The Backlink Analyzer returns the referring domain count for any site in about a minute, alongside the total link count. Compare the two: if one domain is sending you a hundred links, those links are automated, and that changes what they are worth.
- The same check that returned 161,672 referring domains for PyPI
- Referring domains, anchors and the follow split, counted separately
- 3 checks a day, no signup, no card
Frequently asked questions
How many pages does PyPI have?
1,968,436 URLs, counted on 25 August 2026 by fetching all 257 sitemap shards rather than sampling, with no fetch errors. Of those, 1,098,314 are maintainer profiles under /user/ and 870,122 are package pages under /project/. Those are the only two page types the sitemaps contain.
Why does the total differ between your two counts?
We ran the census twice, minutes apart, and got 1,968,427 then 1,968,436. Nine pages appeared in between. That is the mechanic working: somebody published a package while we were counting.
How are the sitemaps organised?
By a two-character hexadecimal shard of the URL, from 00.sitemap.xml to ff.sitemap.xml, plus one extra. The distribution is very even — a median of 7,687 URLs per shard and a maximum of 7,934 — which is what you would expect from hashing rather than from any editorial grouping. One shard is the exception, holding a single URL.
What is its backlink profile?
Our Backlink Analyzer returned Domain Rank 96 out of 100, 16,182,395 total backlinks, 161,672 referring domains, 14,138,619 dofollow and 2,996,106 nofollow links, 53,170 referring IPs and 27,302 referring subnets. That works out at roughly 100 backlinks per referring domain, and 87% of the links are dofollow.
How does that compare with others in this series?
Referring domains per page: calculator.net 143 across 222 pages, Healthline 14.4 across 42,567, GeeksforGeeks 0.6 across roughly 183,000, PyPI 0.082 across 1,968,436, and Levels.fyi 0.026 across 528,363. The ratio falls as page count rises in every site measured, so it is only worth reading when the gap is large.
What did the website audit find?
91 out of 100, the highest score in this series: 0 critical issues, 1 warning, 3 notices and 118 checks passed. On-page SEO 24 of 25, technical SEO 66 of 67, speed 27 of 29, mobile 2 of 2. The warning was images missing alt text. The title tag is 31 characters, the meta description 96, and the page has one clear H1.
Does this work if my database is small?
It works better than most people expect, because the point is coverage of a defined set rather than volume. If you have 400 products and nobody else has a page for each, 400 pages is a complete catalogue of that market. Calculator.net, earlier in this series, out-earns every large site here from 222 pages.
What stops this becoming a thin-content problem?
Mostly whether each record answers a question somebody actually asks. PyPI gets away with abandoned packages because a developer searching an exact package name wants that page to exist, however thin it is. Generating pages for combinations nobody searches for is where the same technique turns into a liability.
The uncomfortable part of this case study is how little PyPI does. There is no content strategy, no editorial calendar and no writers. There is a database, a template, and a decision to publish everything in it.
Most companies have the database already. What they do not have is the nerve to treat it as the product's front page.
Run the check on your own domain, then look at your database and count the tables nobody has turned into a page yet.
Measured on 25 August 2026. Page counts come from pypi.org's own sitemap files; all 257 shards were fetched and counted rather than sampled, with no errors, but declared URLs are not indexed pages.
Link and audit figures are free runs of our own tools, and the comparisons use the same tool earlier in this series. No traffic or revenue data was available to us and none is claimed here.