How PyPI's 2M Pages Earn Only 154K Visits

PyPI publishes 2M pages and earns 154K search visits a month.

That is one visit per 13 pages. GeeksforGeeks earns 20x the traffic from a fraction of the URLs.

I ran pypi.org through 4 of our tools expecting the usual programmatic SEO story and found the opposite: the largest page count in this batch attached to the smallest traffic. It also has the cleanest technical audit I have ever measured. Here are the 8 lessons, and most of them are about what you should not do.

Never count pages as an input

An earlier crawl of PyPI's own sitemap counted 2M URLs. The Organic Traffic Checker puts the site at 154K estimated monthly visits, and the Domain Overview at a quarter of a million ranking keywords.

Free, and it makes the ratio obvious. Before you generate a page type, check the search volume on 20 real entity names in Semrush or SE Ranking. It is an afternoon, and it decides whether the whole project is worth starting.

Healthline produces 60x as many keywords from a fraction of the pages.

Page count is not an input to traffic. It is an input to eligibility for traffic, and eligibility is worthless if nobody is searching for the thing on the page.

Hold that against any plan of yours that starts with "we'll generate a page for every…". The plan is not wrong because it is programmatic; it is wrong when nobody has checked that the entities are searched, and that check takes an afternoon while the build takes a quarter.

Name the query each page type wins

The same crawl split the estate by shape: more than half of PyPI's published pages are user profiles, and the rest are project pages.

A user profile on a package index lists somebody's packages and nothing else — no description, no documentation, no question you could plausibly be searching for.

Nobody searches for it. It cannot rank for anything except the username, and the username is already served by the packages themselves.

The lesson is direct: publishing a page type that answers no query does not build a content library, it builds a crawl budget problem.

So before you generate a page per entity, name the search that page could plausibly win. If your honest answer is "none", set it to noindex and keep it out of the sitemap — you can still serve it to the humans who arrive by link.

Check whether your tail has demand

Now look at where the traffic that does arrive goes.

/project/pip/ takes nearly 29% of everything, ranking first for "pip". The homepage is a distant second, then certifi, requests and pandas.

One page out of 2M carries almost a third of the site.

Set that against Healthline, where no page reaches 1%. Same idea — a very large library — and completely opposite concentration, because Healthline's pages answer questions people ask and PyPI's mostly do not.

The long tail only exists if the tail has demand in it. Run the same report on yourself: if your traffic collapses onto 2 or 3 pages, you do not have a library, you have a few good pages and a lot of hosting.

Test 20 entity names before you build

Here is the underlying reason, and it is worth being blunt about.

A developer who needs a Python package does not google it. You already know the name from documentation, a tutorial or a colleague, and you type pip install thing. The package page is somewhere you arrive by URL, not a search result you discover.

Your own catalogue may work exactly the same way, and if it does, no amount of on-page work will change it.

The exceptions prove it: the pages that do rank are pip, requests, pandas and certifi — the handful of package names that have become generic terms people genuinely search for. Your equivalent is whichever of your entities somebody would name to a colleague who had never heard of you.

So before you build a programmatic page type, run 20 sample entity names through Keyword Research. Pick them at random from the middle of your list, not from the head — the head will always look encouraging.

If 18 come back with nothing, you do not have a content opportunity. You have a database with a web interface, which is a perfectly good thing to have as long as nobody is measuring it on organic traffic.

Put your link inside somebody's template

The link profile tells the same story from the other side. Our Backlink Analyzer reports 100K referring domains at Domain Trust 96.

"PyPI" leads at a quarter of the profile. Then "Python Package", "Python PyPI", "Python SDK" and "API Client (Python)" — 4 near-identical generic phrases carrying almost exactly the same number of links each.

That clustering is the fingerprint of generated documentation. Package authors publish README badges and doc templates that link back with whatever phrase the template used, and the same phrase repeats across thousands of projects.

It works, and it is the same mechanism Eventbrite and itch.io use. The difference is that PyPI's version was never designed by anyone — it emerged from a packaging convention nobody wrote down as a marketing decision.

You can design yours on purpose. Whatever you give your users to embed — a badge, a widget, an export — carries a link and an anchor you choose once, and it will still be working long after the people who shipped it have left.

Stop expecting a green audit to pay

The Website Audit scores the homepage 91/100, with nothing critical and a single warning.

That is the highest score and the highest passing-check count of the 10 sites measured across these 2 batches. Healthline scored 74 with 40x the traffic value.

Which is the honest conclusion of this whole article: PyPI is the best-built site here and the worst-performing one. Technical quality is necessary and nowhere near sufficient.

Site Speed and the Meta Tag Generator will close most of what an audit flags, and neither will move a page nobody searches for.

So if your audit is green and your traffic is flat, stop working the audit. It was never the problem, and another quarter of fixes will produce another quarter of the same result.

Plan the retirement, not just the launch

It loses more keywords than it gains, and declines on more than it improves.

Packages are abandoned constantly. Every dead project keeps its page, stops being mentioned anywhere, and slowly falls out of the index. The estate grows while its search surface shrinks, which is the same pattern GOV.UK shows for an entirely different reason.

So if you publish a page per entity and your entities have a lifecycle, plan the retirement as deliberately as the creation. Decide now what happens to a page when the thing it describes dies — redirect, merge, noindex, or leave it — because deciding later means never.

And keep the surviving terms in the Rank Tracker so you see the decline while it is still a handful of pages rather than a year of them.

Do not index what answers nothing

The single action to take from all of this.

PyPI's user profiles are not hurting it much — its audit is immaculate and its trust score is high — but they are more than half its published surface producing approximately none of its traffic. On a smaller site that ratio is actively damaging: thin pages dilute the crawl, and the pages that could rank compete with a million that cannot.

Go and count your own page types this week. For each one, name the query it wins, out loud, to somebody else.

Any type where you cannot name a query should be noindexed, removed from the sitemap, or merged into something that can. The XML Sitemap Generator will show you what you are currently submitting against what you meant to, and the gap is usually larger than you expect.

What you cannot copy

And here is what I could not measure, or had to qualify. A couple of the tools I name below are partners of ours — if you buy through those links we earn a commission, and you do not pay a cent more.

Our traffic figures are United States only and modelled from ranking positions and search volume rather than counted. PyPI's audience is global and heavily non-US, so its worldwide traffic is larger than 154K — though the page-count-to-traffic ratio that this article turns on would survive any reasonable multiplier. The keyword and backlink data underneath comes from SE Ranking, and the $220K is an ad-spend equivalent, not revenue. PyPI sells nothing.

The backlink figures here were captured through the app rather than the marketing tool, which was rate-limited at the time. The report's own BACKLINKS tile read 350K, which is wrong — the page header and the dofollow/nofollow split both put the total at 16M, and those reconcile exactly, so that is the figure used above. The tile is a known defect on our side and I am not going to quote it.

The page count and the profile-versus-project split come from a full crawl of PyPI's own sitemap on 25 August 2026, not from this run. I did not run Keyword Research: it has an open defect returning implausible volumes.

And what you cannot copy: being infrastructure. PyPI does not need search traffic, because every Python installation on earth talks to it directly. Judging it on organic visits is a category error — I have done it here to make a point about page counts, not because PyPI is failing at anything.

Frequently asked questions

The one number to take away

13.

That is how many PyPI pages it takes to produce one search visit a month — 2M pages, 154K visits.

Nobody set out to build that ratio. It is what happens when a page type gets generated because the data exists, rather than because a query does. And the site around it is exemplary: 91 out of 100, 118 checks passed, Domain Trust 96, 16M backlinks. None of it helps, because the pages are eligible for searches that were never going to happen.

So next time somebody proposes generating a page per record, do not ask how many pages it will produce. Ask which query the tenth-most-typical page will win, and go and check the volume for it before anyone writes a line of code.

Found something in your own report that surprised you, or measure this differently? I would genuinely like to know — the tools used are all free, so you can check every figure yourself. Measured 4 September 2026 unless stated. Domain Overview, Organic Traffic Checker, Website Audit and Backlink Analyzer figures are free runs of our own tools, all United States scope, and all modelled rather than counted where the tool says so. The page count comes from PyPI's own sitemap, crawled 25 August 2026. No revenue figure applies.