qBittorrent search-plugins: the community hub behind the search box

A repository of Python plugins that is not itself a qBittorrent release

The first thing to get straight is what this is. The repository description is one line: search plugins for the qBittorrent search feature. It is not a fork of the client, and it does not build into anything you ship. It is a collection point for plugin files that the qBittorrent client loads at runtime.

That has practical consequences. You do not clone this to build a torrent client; you clone it to read, review or contribute to a plugin. The plugins are Python files, the repository language is reported as Python, and the tree shows a `nova3/` directory where the plugin sources live alongside a `wiki/` directory that holds the documentation the README links to.

The `package.json` at the root exists only to describe the wiki: its name is `qbittorrent/search-plugins/wiki`, the description reads qBittorrent search-plugins Wiki, and the repository field points back at this GitHub project. If you see a `package.json` in a Python plugin repository and reach for npm, that file is the explanation. There is nothing to install with it.

The README is a table of contents to the wiki

The front page has a Start Here section and nothing else of substance, which is a deliberate choice given how little the project itself ships. Five wiki pages are linked, and they cover exactly the tasks a new user has.

Two are for people using plugins: a list of unofficial search plugins, and instructions for installing search plugins. One is for people who maintain a site and want their index listed, described as a request for an unofficial search plugin. One is for integrators, on configuring the Jackett plugin. One is for contributors, on writing a search plugin.

The last of those is the interesting one for anyone evaluating the project, because a plugin here talks to a third-party index that will change its HTML without notice. Reading how the plugin is expected to be written tells you more about the maintenance burden than any feature list would. For users, the unofficial plugin list is the file you actually want, and it is one click from the README.

Community maintained, explicitly not the core team

The Contribute section is unusually blunt about governance. It says the maintainers currently lack the capacity to maintain additional official plugins, that pull requests fixing existing ones are highly welcome, that the repository is maintained by community contributors, and that it is not directly managed by the qBittorrent core team.

Read together, those four sentences describe a deliberately federated model. Official plugins are a scarce resource the core team declines to spend on, so new sites are added by whoever runs the site, and maintenance of existing ones is shared. The stated purpose is to provide a hub for third-party contributors to gather and share their plugins.

For a user, this means two different trust levels sit in one directory. A plugin that broke because its target site changed markup may sit next to one maintained by the site owner. There is no per-plugin badge in the README telling you which is which, so the wiki list and the plugin's own repository history are where you look. For a prospective contributor, the capacity statement is the real signal about review turnaround.

What the news section tells you about compatibility

The News section on the README has exactly two entries and both are from 2020. The first, dated 2020-04-26, warns that Python 2 support will be removed soon. The second, dated 2020-08-19, confirms it: Python 2 support is gone and users need to upgrade to Python 3 to keep using the search function.

That is old news, but it is still the most useful compatibility statement the README makes, because it fixes the Python version floor for every plugin in the collection. A plugin is Python 3 or it does not work, which is worth knowing before you start writing one against an old tutorial.

There is also a prominent notice above it telling users to use the plugins and the websites they connect to at their own risk, and to follow the copyright laws of their country. That is not boilerplate. A search plugin queries a site index of downloadable files, and where you point it and what you do with the results is your responsibility, not the repository's.

Repository shape and what the numbers say

The tree is short: `.gitattributes`, `.pre-commit-config.yaml`, `.gitignore`, `LICENSE`, `README.md`, the `nova3/` plugin directory, `package.json` for the wiki, and the `wiki/` folder itself. The pre-commit configuration tells you linting runs before commits land, which matters in a repository where every file is executed by someone else's client.

The project reports GPL-2.0, a licence that fits: the plugins are copied into a GPL client's feature set, and the repository exists to host third-party contributions rather than to sell anything.

The activity signal is strong: around 6,600 stars, more than 580 forks, and a last push on 2026-09-21. The open issue count is under 50, which for a repository this size and this degree of automation is low. There are no tagged releases at all, and for a collection of loose plugin files that is consistent rather than a gap: there is nothing here to version as a unit, because the client pulls the current state of the wiki and loads individual plugin files from it.

Where the README ends and the wiki takes over

The division is clean enough to state plainly. The README tells you the project exists, that it is community run, that it is not the core team's, that plugins are Python 3, that you use them at your own risk, and where the five useful documents are. It does not list a single plugin, and it does not document the plugin API.

That is an unusual amount of delegation for a repository with six thousand stars, and it is defensible here. A plugin list ages weekly, while governance and legal notices do not. But it means the README is close to useless as a catalogue, and anyone evaluating this project for the first time should open the unofficial plugin list before drawing any conclusion about coverage.

What you can conclude from the repository itself is about process. Documentation is versioned in-tree under `wiki/`, linting is enforced pre-commit, third-party contributions are the expected shape of a change, and the client-facing contract lives in a wiki page rather than in code you can read. For a project whose entire job is to be a well-lit junction between end users and independent index maintainers, that is roughly the right amount of process.

Editorial conclusion

This repository is infrastructure rather than a product: it is where the search feature finds plugins that qBittorrent itself does not ship, and it works because contributions are cheap and review is light. What you get from the README is the map of that process, namely where to install a plugin, how to request one, how to write one and how to point the client at Jackett. What you have to read elsewhere is the plugin list itself, which lives in the wiki. If you are adding search to a qBittorrent install, start with the unofficial plugin list, and if you maintain one, read the contributing page before opening a pull request.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. qbittorrent/search-plugins on GitHub
5. README