Indie Wiki Buddy: a browser extension for the independent wikis

The problem: good wikis hidden behind search results

Indie Wiki Buddy is a browser extension that automatically notifies and redirects you from wikis on large, corporate-run wiki farms to independent wikis.

The reasoning behind it is laid out in the README, and it is a point about discovery rather than about quality in the abstract.

Large, corporate-run wiki farms have enabled hundreds of great wikis and communities. Unfortunately, these wiki farms can easily overshadow quality independent wikis, especially in search engine results. Independent wikis often have the benefit of greater self-determination and fewer ads, but are easily missed by users who are not aware of their existence.

So the extension is a corrective to a specific mechanism. An independent wiki can be better run, more community governed and less cluttered with advertising, and none of that matters if a search for the topic returns the farm's page and the independent wiki is on page three.

The extension's own project page is getindie.wiki, and the install links go to the Firefox add-on listing and the Chrome Web Store listing.

The licences and packaging are conventional. The project is MIT licensed, the primary language is JavaScript, the default branch is main, and the repository topics are extension, hacktoberfest and wiki. The releases are v3.14.8 on 2026-08-20, v4.0.0 on 2026-08-26 and v4.0.1 on 2026-09-25, with the last push to the repository on the same day as the last release.

Notify, redirect, or both, and the per-wiki control

The behaviour is stated in one sentence in the README, and it has three parts rather than one.

When visiting a wiki on a large corporate wiki farm such as Fandom, Indie Wiki Buddy will notify and/or automatically redirect you if a quality, independent alternative is available. And you can customize your experience per-wiki.

The and/or is the interesting part, because it is what makes the extension usable by people with different reactions to being redirected. A notification tells you that an alternative exists and lets you decide, which is the polite behaviour. A redirect takes you there without asking, which is the behaviour somebody who is annoyed by the farm wants and somebody who needed that particular page does not.

The per-wiki customisation is what resolves the second case. A reader who wants the redirect on Fandom but not on the one farm that has the article nobody has copied yet can set it per wiki, so the extension becomes a set of rules rather than a single policy.

Two design points are worth noting because they are easy to get wrong. The extension only acts when an alternative actually exists in its data, so a page with no entry is untouched. And it acts on the wiki farm, not on the independent wiki, so arriving at an independent wiki from any source is left alone. The intervention is one directional and conditional, which is the minimum needed to do the job.

The list of wikis lives in a separate repository

The most interesting structural decision in the project is that the data is not in the extension.

The badges at the top of the README are dynamic JSON badges, each pointing at a file in a separate repository, IndieWikiBuddy/indie-wiki-buddy-data, and each badge displays the number of wikis in that language. The badge URL for the English list points into that repository, and the extension is installed from the Firefox add-on site:

https://addons.mozilla.org/en-US/firefox/addon/indie-wiki-buddy/

The badge is a JSON query badge that fetches that file and reports its length, which is a neat piece of engineering: the count of independent wikis per language is never written down by hand, it is read out of the data that the extension itself uses.

The languages covered are visible in the badge list, and there are a lot of them: CA, DE, EN, ES, FI, FR, HR, HU, IT, JA, KO, LZH, NL, PL, PT, RU, SV, TH, TOK, TR, UK and ZH. That is twenty-two lists, from the major European languages through Japanese, Korean, Chinese, and a set of smaller language editions such as LZH for Literary Chinese, TOK for Toki Pona, TH for Thai and UK for Ukrainian.

Splitting the data out has two effects. The extension package stays small, because it carries logic rather than a database of sites. And the list can be updated without a new release of the extension, since a change to a JSON file in the data repository is enough to change what the extension knows.

The trade is that the extension depends on a remote resource it fetches at run time, so a change to the data takes effect immediately, including for users on an old version.

Search engines, not just wiki pages

The README then lists a second set of targets, and the list is presented there in full.

In addition, search results in Google, Bing, DuckDuckGo, Brave, Ecosia, Kagi, Qwant, Startpage, Yahoo!, and more are covered.

That is a much more aggressive scope than redirecting a wiki farm page. A search results page is where the problem starts: the user has asked a question, the search engine has returned a farm's page, and the independent alternative may be the second result. Intercepting the results page is the point at which the redirect can actually change the outcome rather than merely informing.

It also explains why the extension is listed for both Firefox and Chrome with a version, a downloads count and a rating badge for each store, and why there is a Weblate translation status badge. The extension has a user interface, the interface has strings, and the strings are translated through Weblate, which means the project has contributors who are not writing code.

The number of search engines in that list is worth pausing on as a design question. A search results page is structured differently on every engine, and the page layout changes without notice. Supporting ten of them means maintaining ten sets of selectors, and any of the engines can break the integration on a layout change. The extension is therefore exposed to a churn that a wiki farm, which changes rarely, is not.

Two manifests, a background script and a locale directory

The repository is small and the layout is that of a WebExtension, which is to say it is mostly the browser's own conventions.

There are two manifest files, manifest-firefox.json and manifest-chromium.json, because Firefox and Chromium differ in the manifest keys they accept, and a WebExtension that supports both usually keeps one manifest per target. Then there is background.js, which is the extension's persistent logic: the part that decides whether the page you are on has an alternative and what to do about it.

The rest of the tree is the extension's own assets. The _locales/ directory holds the translation strings that Weblate manages, css/ holds the styles for the notification and the options interface, pages/ holds the extension's own pages, scripts/ holds the scripts those pages load, favicons/ and images/ hold the icon assets, and data/ holds whatever the extension ships locally.

The .github/ directory holds the issue and pull request templates and the workflows, and the top level also carries the licence and the README.

There is no build system in the repository listing, no package.json and no bundler configuration, which is a meaningful signal. The extension is plain JavaScript in the browser, and it is published to the two stores as it stands. For a project whose whole job is to look at URLs and act on them, a build step would add a failure mode without adding much, and the WebExtension APIs it uses are available directly.

Two stores, two audiences

The extension is distributed through the Firefox add-on site and the Chrome Web Store, and the README carries a badge for each: version, user count and rating for the Mozilla listing, and the same three for the Chrome listing.

The user counts are the interesting measurement, because the Firefox and Chrome populations are not the same people. The people who install an extension that redirects them away from Fandom are the readers who have an opinion about independent wikis, and the two stores have different extension review processes and different user bases.

The version history tells you about the project as well. The numbering reached v3.14.8 in August 2026, which is a lot of patch releases, and then jumped to v4.0.0 a month before v4.0.1 in late September. A version 3 line with a long tail of patch releases and then a major bump is the shape of a project that has been running for a long time and then changed something structural, most likely the extension permissions or the set of search engines it intercepts, since a change in the manifest is what forces a new release in the Chrome Web Store anyway.

The maintenance is spread across two repositories, the extension and the data, and the release dates in the two do not have to line up. That separation is what lets a correction to a wiki list reach users without anyone waiting for a build.

Where Indie Wiki Buddy is the wrong tool

There are cases where this extension is the wrong answer, and some of them are about taste rather than about fact.

If you arrived at a farm page deliberately, because that page has the article and the independent wiki does not, a redirect is a lost article rather than a discovery. The per-wiki customisation is the answer, but it is an answer you have to apply before it happens rather than after.

If you are a person who reads a farm wiki as a historical archive, some of the content there exists only there, because the community grew on the farm and its history is not reproduced elsewhere. The extension cannot know that, because its data is a list of alternatives rather than a comparison of coverage.

The search engine interception is the part most likely to annoy. A search results page is the user's own query, and rewriting it means the tool is deciding what the user should see for a query they typed. That is a different kind of intervention from noticing that a wiki page exists elsewhere.

The privacy side is worth naming too. An extension that sees every page you visit and every search you make has a lot of visibility, and it needs permission for the search engine pages specifically. The WebExtension permission model is there to make that visible, and the store listings are where the permission list appears, but it is still a real consideration for a browser extension that has to look at every result page.

The alternative approach is to change the discovery layer rather than the browser. A search engine that prefers independent wikis, or a personal instance of one, would mean the farm pages never appear in the first place, and there is no extension to install and nothing to intercept. The difference in approach is that that solution is a project you configure and maintain yourself, while the extension is a shared list that other people maintain, which is easier to start with and easier to outgrow.

Editorial conclusion

Indie Wiki Buddy suits a reader who keeps landing on a corporate wiki farm and would rather be somewhere else, and who wants the alternative suggested rather than hunted for. It does not suit somebody who wants the extension to be silent about the page they asked for, because the redirect is the feature, and it does not suit a reader who assumes an article on a farm has a copy on an indie wiki, because the mapping is a curated list and the coverage is uneven. Check three things before you install it: whether the wiki farm you use is covered and whether the indie alternative it points at is one you want, which you can see from the per-wiki customisation and the data files, which language versions you need, since the list is maintained per language, and whether the redirect behaviour suits you or whether you want the notification only. The last push to the repository was on 2026-09-25 and the newest release is v4.0.1.

Frequently asked questions

Official sources

1. IndieWikiBuddy/indie-wiki-buddy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases