You can buy the fastest, deepest Usenet provider on earth and still find nothing, because Usenet has no built-in search. Providers store articles; they don’t catalogue them in a way you can browse. Finding the specific binaries you want is the job of an indexer — and choosing the right one is often the difference between a setup that “just works” and one that’s forever missing files.

This guide explains how indexers actually work, why paid and free ones differ by a mile, and — in the NZB quality and PAR2 section below — how the indexer’s output quietly decides whether your downloads repair cleanly or fail. If you’re brand new, read what is Usenet first, then come back.

What an Indexer Actually Is

An indexer is a service that crawls Usenet, reads the article headers, and builds a searchable database of what’s available — turning into a catalogue what would otherwise be a fire hose of unsearchable binary posts. When it finds a post, it generates an NZB file: a small pointer that lists exactly which articles make up that binary and which newsgroups hold them.

Your downloader (SABnzbd) opens that NZB and pulls those articles straight from your provider. So the flow is:

Indexer ──searches──> finds post
   │
   └───── NZB ──────> SABnzbd ──articles──> Provider

No indexer, nothing to search, no NZBs, no downloads. It’s a mandatory piece of the stack.

The Two Big Differences: Free vs Paid

The quality gap between free and paid indexers is enormous and directly affects your completion.

Free indexers

  • Cover a limited slice of Usenet.
  • Index slowly — new content shows up late, if at all.
  • Often local to one backbone’s feed or missing the full global picture.
  • Generally lower-quality NZBs with more dead or incomplete references.

They’re fine for dabbling and for testing your pipeline before you spend money. Don’t build your permanent setup on them.

Paid/private indexers

  • Pull (typically) from richer, faster feeds and index new content more or less instantly — which is critical for automation catching things as they post.
  • Produce higher-quality NZBs that include PAR2 repair files and sensible naming, so SABnzbd verifies and renames cleanly.
  • Are the difference between Sonarr/Radarr grabbing a release the moment it’s out vs. missing it.

The catch: there’s no Yellow Pages of indexers. Most rely on community reputation, invite systems, or registration windows. That friction is half the reason the space is still full of mediocre options and why having a second indexer as a backup is a common trick.

Here’s the angle most indexer guides never connect: the indexer’s NZB is what feeds your PAR2 repair budget.

A good NZB includes three things that a bad one doesn’t:

  1. PAR2 parity files. The NZB lists the .par2 files as part of the post. SABnzbd auto-downloads them and uses the parity to repair missing articles. A poor-quality NZB can omit or mis-point the parity, silently robbing you of your repair headroom.
  2. Correct article references. If the NZB’s article IDs are wrong or half-dead, SABnzbd spends transfers fetching nothing and hits a completion wall that PAR2 can’t rescue.
  3. Sensible naming. Clean, consistent names let automation (Sonarr/Radarr) match releases reliably and let SABnzbd rename finished files correctly. Garbage names mean automation misses releases even when the data is there.

So the “free indexer is fine” logic has a hidden cost: free NZBs are more likely to be missing parity or carry dead references, which means you burn your finite repair budget before you even start. This is why the quality of the NZB — not just whether the indexer “finds” something — is what separates a setup that “just works” from one that’s permanently repairing.

The other link: indexer freshness interacts with retention/completion. An indexer that indexes slowly may hand you a release that’s already partway out of your provider’s clean coverage window, on an older post where thinned articles eat into parity headroom. Fast indexing keeps you inside high-completion territory where PAR2 rarely has to work hard. When it does work — and fails — the fixes live in when a repair fails, and why.

Newznab and Automation

If you’re using Sonarr/Radarr automation — and you should — you need an indexer that supports the Newznab API. Newznab is the de-facto standard protocol that lets automation tools query an indexer automatically: it fetches search results and hands matching NZBs to SABnzbd without you ever opening the indexer’s site.

When you set up Sonarr/Radarr you’ll add your indexer by URL and API key. Choose one with Newznab support or you lose the hands-off automation that makes Usenet great.

How to Choose an Indexer

There’s no single right answer, but the decision framework is:

  1. Start free to prove your pipeline works (provider + SABnzbd + one free indexer, grab one small NZB).
  2. Add a paid indexer for real use — prioritise freshness (fast indexing) and NZB quality (complete parity, clean naming, valid references) over raw group count. The PAR2 link above is exactly why quality beats coverage.
  3. Consider a second indexer once you rely on it, since no single indexer is 100% complete. Two good indexers markedly improve successful pulls.
  4. Prefer Newznab-compatible ones so automation hooks in cleanly.

Do I Recommend Any Specific One?

I’m not hiding an affiliate deal behind this — there isn’t one, and I deliberately keep indexers recommendation-free here. Indexer quality and availability shift too often for a static list to stay honest, and sign-ups are frequently closed or invite-gated. Follow the decision framework above instead of chasing a “best indexer” listicle that’s six months old, because those lists are exactly where the marketing nonsense lives.

Tying It Back Together

An indexer is only half the speed equation — the other half is your retention and completion, which depends on the backbone behind your provider. That’s why the honest provider roundup exists:

Need the Whole Picture?