DEV Community

RSS Atlas
RSS Atlas

Posted on • Originally published at rssatlas.com

How the rankings work — and what we refuse to count

Positions in RSS Atlas are not for sale. There are ad slots, but they are separate, labelled "Ad", and take no part in the ranking calculation.

Anyone can write that sentence, so here is what is actually counted — and, more importantly, what is deliberately not.

The three signals

Signal What it represents
Favorites Someone decided they wanted to come back to it
Page views The feed's detail page was opened
AI fetches An AI tool retrieved the feed over MCP

These are combined with time decay, so recent interest counts for more. A feed read heavily last year sits below one being read this week.

The ordering is public: favorites weigh most, then views, then AI fetches. The coefficients and thresholds are not. Publishing the exact numbers would amount to publishing which signal is cheapest to inflate.

Why count AI fetches at all

This is the axis other directories do not have.

Search traffic is falling while assistants increasingly compose the answer, which makes what the AI reads a separate fact from what humans open. Feeds exist — reference documentation is the obvious case — that people rarely click through to but agents pull repeatedly.

What is deliberately excluded

This half matters more.

  • Ads and sponsor slots. Inserted at the render layer only; they touch neither the score nor the ordering
  • Payment. There is no way to pay for a position. Slots may be sold later, but a slot is not a rank
  • Article volume. A site publishing ten posts a day has no claim over a good weekly one
  • Age. Having existed since 2005 says nothing about being worth reading now
  • Unreviewed feeds. Submissions that have not passed review stay out of rankings entirely

Making the numbers hard to inflate

Publishing what you count invites people to manufacture it. AI fetches are the exposed surface, since there is an unauthenticated demo path, so:

  1. Deduplicated per client per day. The same client pulling the same feed a thousand times counts once
  2. Contribution scales logarithmically in the number of distinct clients, so spinning up more of them does not pay linearly
  3. Day-over-day outliers are held back. A sudden spike has that day's increment withheld pending a look

None of that is airtight, which is why AI fetches carry the smallest weight of the three.

No ads in MCP responses

When an AI tool calls get_rankings, what comes back is purely organic. The sponsored-placement data is not consulted by that query at all.

The website shows ads. MCP responses, search results, OPML exports and badges never will. Mixing advertising into the data an agent reads would remove the reason for this directory to exist.

Checking it yourself

The rankings table shows position, feed count, favorites, AI fetches and score as columns. You can follow why something sits where it does without taking our word for it.

Category and tag rankings work the same way, ordered by the summed score of the feeds they contain.


The transparency is not altruism. A directory whose ordering cannot be trusted has no value left — the moment positions become purchasable, it is a list of adverts, not a directory.

Top comments (1)

Collapse
 
reidmarlow profile image
Reid Marlow

I like the choice to keep AI fetches low-weighted. Once agents can hit the same unauthenticated path over and over, treating that signal as interesting but cheap-to-inflate feels safer than pretending it is a clean demand metric. Favorites first, views second, AI fetches last is a decent honesty gradient.