Before a single dominant way of finding things existed, people used several partial ones at once, and most of those were built and maintained by hand. This is an account of the five main mechanisms, what each one was actually doing, and why each stopped being the thing people reached for.
Editorial note. Every named service and every figure in this piece is attached to a source we opened, listed at the end with the date we retrieved it and, where the source is an archived capture, the date the capture was taken. Widely repeated numbers about the early web usually trace back to each other rather than to a source, so where we could not open something we have left the gap rather than filling it with what merely sounds right. The same sources are recorded at our source ledger.
What this is, and who it is for
This is a reference piece for anyone who wants to understand how web discovery worked before search consolidated, and who is tired of accounts that are mostly fond memories with the dates guessed.
It is organised by mechanism. That is a deliberate choice and the next section explains why. If you want the argument rather than the survey, what the blogroll specifically did is the shorter route in. If you want to know which of these still runs, why the current revivals stay small covers that.
One thing this piece will not do, here or anywhere: claim that this site continues, revives or succeeds any of the services described. Those were built by people, a number of whom are still working, and inheriting their reputation by implication would be a cheap thing to do. We describe what the mechanisms did and stop there.
How to read this: mechanisms, not brands
Brands are a bad unit of analysis for this subject, for three reasons.
Brands die and mechanisms recur. The same underlying structure — a human list of outbound links, a ring, a shared queue — has been implemented many times by many parties under many names. Organising by brand produces a story about companies. Organising by mechanism produces something that still explains a tool built next year.
Brand histories invite motive. Once you write about a company you start explaining what it wanted, and from the outside nobody knows that. A mechanism has properties. It does not have intentions, and its consequences arrive whether or not anyone chose them.
Brand facts are the hardest things to source. Founding dates, user counts and shutdown dates circulate widely and are frequently repeated without a primary source behind them. The mechanism, by contrast, can be described from how it worked, which is checkable against the artefacts themselves.
So each section below describes a structure first, and names an implementation only where we could open documentation the service published about itself, which in most cases means an archived capture of its own pages, cited below with the date that capture was taken. Where no service is named, it is because we could not open anything of its own to name it from.
Human-edited directories
The structure. A hierarchical tree of categories, populated by submissions from site owners, with human editors deciding whether a submission was accepted and where it belonged. The Open Directory Project's own submission page, in an Internet Archive capture taken on 1 January 2005, describes a directory "hierarchically arranged by subject - from broad to specific" and "maintained by community editors who evaluate sites for inclusion in the directory", states that "all submissions are subject to editor evaluation", and says plainly: "We don't accept all sites, so please don't take it personally should your site not be accepted." Its submission FAQ, captured the same day, told site owners that "it may take up to 2 weeks or more for your site to be reviewed", "depending on the activity level of the editors in your area".
What it solved. Two things at once. First, an inventory problem: it gave the web a table of contents at a point when browsing was the main way people moved around. Second, a quality problem: because a person made the accept-or-reject decision, inclusion carried a small amount of information beyond mere existence.
What made it work. Judgement applied at the door. A tree of categories is only useful if the things placed in it were placed thoughtfully, and that required a human who understood the category well enough to distinguish a real thing from a shell.
Its structural weaknesses. Three of them, and they are the same three that any curated collection meets. The submission queue grows faster than the reviewing capacity. The category tree stops fitting reality as the reality diversifies. And the editors are a small group of people whose knowledge and attention are unevenly distributed across the tree, so some branches are careful and others are decorative.
We go into this in much more depth in what a directory was supposed to be, because it is the mechanism closest to what this site does, and its failure modes are the ones we are most likely to repeat.
Webrings
The structure. A set of sites on a related theme, each carrying a small navigation widget. Following the forward control repeatedly walked you around the ring and eventually returned you to where you started. WebRing's own homepage, in an Internet Archive capture taken on 25 January 1999, describes "member websites organized by related interests into easy-to-travel rings" and tells the reader that at any member page they can "click on the navigation buttons or hypertext to travel to other sites in the ring"; the same page states that "any web site owner can apply to join an existing ring or create a new ring" and that "rings are listed in the Directory once they contain at least five sites". A capture of one ring's navigation page taken on 23 April 2000 shows the controls themselves: "Prev 5", "Next 5", "Ring Home Page", "List Sites" and "Random Site". The coordinator was a role in the software rather than an informal arrangement: WebRing's management page, captured on 17 January 1999, gave ring owners "the ability to modify their ring configuration and to manage sites in the ring".
What it solved. Discovery for sites too small and too specific to be found any other way. If your subject was narrow, the audience for it existed but was scattered, and a ring collected the scattered audience by chaining the sites together rather than by ranking them.
What made it work. Mutual consent. Every member had agreed to be in the ring and had placed the widget on their own site, which means the endorsement went in both directions. That is a genuinely different property from a directory, where inclusion is decided about you rather than with you.
Its structural weaknesses. The chain is only as good as its weakest link, quite literally. A member who removed the widget, changed their URL or went offline broke the traversal for everyone downstream unless the coordinator noticed and repaired it. The coordinator role was unpaid, involved moderation as well as maintenance, and had no succession plan. What a webring was covers the mechanism in enough detail to build one, along with what the current implementations do differently.
Blogrolls and link pages
The structure. A standing list of outbound links, maintained by hand by the owner of the site it sat on, usually in a sidebar or on a dedicated page, ordered by the owner's own judgement. WordPress shipped a built-in Link Manager for this: the WordPress.org plugin that restores it calls it "the Link Manager (which some use to build blogrolls)", and WordPress's release documentation for version 3.5, released on 11 December 2012, records that the feature was thereafter "hidden for new installs and for any existing installs that have no links". We retrieved both on 6 September 2026.
What it solved. Transitive discovery. You did not need to know what you were looking for; you walked from a place you already trusted into places that place trusted, and the chain could be followed for as long as your afternoon held out.
What made it work. Attribution. You knew whose list it was, which meant a recommendation could be calibrated. Over time you learn that one person's taste overlaps yours and another's does not, and that learning is only possible when the recommender has a stable identity.
Its structural weaknesses. Maintenance is recurring and unpaid, links break, and editing the list is socially loaded once the people on it can see whether they are still there. The list also stops paying its owner back when readers stop arriving in a browsing mood. The full argument is in the piece this cluster is built around.
Social bookmarking and the shared queue
The structure. People saved links for their own use, with tags, on a service that made those saves visible to others. Aggregate saving behaviour produced a shared surface: what a lot of people had just saved, what a particular person had saved, what had been saved under a given tag. del.icio.us described itself, in an Internet Archive capture of its homepage taken on 16 September 2005, as "a social bookmarks manager" that "allows you to easily add web pages you like to your personal collection of links, to categorize those sites with keywords, and to share your collection not only among your own browsers and machines, but also with others", and said that what made it a social system was "its ability to let you see the links that others have collected, as well as showing you who else has bookmarked a specific site".
What it solved. It got curation without asking anybody to curate. The primary act was selfish (save this so I can find it later), and the discovery layer was a by-product. That is a structurally elegant arrangement, because the maintenance effort is paid for by the immediate personal benefit rather than by goodwill.
What made it work. Volume with a personal anchor. You could read the aggregate when you wanted popularity, or follow one person's saves when you wanted a specific sensibility, from the same underlying data.
Its structural weaknesses. Any surface that ranks by aggregate saving behaviour becomes worth manipulating the moment it sends meaningful traffic, and defending it requires ongoing anti-gaming work that nobody budgets for at the start. There is also no accuracy obligation anywhere in the system: a save is a record of what someone thought at a moment, and nothing in the mechanism ever revisits whether the destination still exists.
The random button, in its various forms
The structure. A control that sends you to a member of some collection, selected without reference to your query, your history or a ranking. The collection may be curated, may be scraped, or may be the entire index of some site.
Two documented examples, at opposite ends. MediaWiki's own documentation for Special:Random describes a feature that "allows users to view a wiki page at random", optionally restricted to a namespace of the reader's choice; the whole thing is one control placed over a collection that other people maintain for other reasons. StumbleUpon, in an Internet Archive capture of its About page taken on 30 June 2007, described something that is not random at all: clicking Stumble delivered "high-quality pages matched to your personal preferences", drawn from pages that had been "explicitly recommended" by other users, using "a combination of human opinions and machine learning". We retrieved the MediaWiki page on 6 September 2026. The distance between those two is the whole subject of this section.
What it solved. The complete absence of a query. Every other mechanism here still requires you to start somewhere specific — a category, a ring theme, a person's list. The random button removes even that, and it is the only mechanism that offers genuine surprise as its main product.
What made it work. It is trivially cheap to operate once the collection exists. That is why it recurs constantly and why it is usually a feature of something else rather than a product on its own.
Its structural weakness, and it is the decisive one. A random button is only as good as the collection behind it, and the collection is the expensive part. Random selection from an unfiltered index produces mostly noise; random selection from a curated collection produces something worth using, and now you are back to paying for curation. The button is the cheap half of a product whose other half is very expensive. We wrote about that distinction separately in why random is not the same as curated.
What each mechanism solved, side by side
| Mechanism | Who decided | Consent from the linked site | Standing accuracy obligation | Cost driver |
|---|---|---|---|---|
| Human-edited directory | Editors, on submission | Requested by the site owner | Weak — usually none after acceptance | Review capacity per submission |
| Webring | The coordinator, with member agreement | Explicit and mutual | Real, but manual and fragile | Coordination and repair per member |
| Blogroll | One named author | None required | Social only | The author's attention |
| Shared bookmarking queue | Everyone, in aggregate | None | None | Anti-manipulation work |
| Random button | Whoever built the collection | Depends on the collection | Inherited from the collection | Building and keeping the collection |
Two columns in that table do most of the explaining. Consent determines whether the mechanism can be used against someone. Standing accuracy obligation determines whether it rots. Only one mechanism in the table has both, and it is the one that depended entirely on a single unpaid coordinator.
Why each one stopped working, or stopped being maintained
The causes overlap heavily, which is the most useful finding in the whole survey.
Maintenance is recurring and nothing funded it. Every mechanism here has a per-item recurring cost of checking, repairing and removing, and none of them had a revenue model attached to it. Intake attracted effort because it produces something visible. Accuracy attracts none, because doing it well is indistinguishable from nothing happening. This is the argument in the economics of not pruning.
Moderation load arrives with success. A mechanism that nobody uses needs no moderation. A mechanism that sends real traffic acquires people who want to be on it for reasons unrelated to its purpose, and defending against that is skilled, thankless, continuous work.
The coordinator was one person. Directories had editors, rings had ringmasters, blogrolls had an author. These roles had no redundancy. When the person's circumstances changed, the artefact stopped being maintained the same week, and there was rarely a handover.
The traffic pattern changed underneath them. These mechanisms assume a reader who is browsing. As arrivals shifted toward query-shaped and feed-shaped entry, a reader lands with a specific intention already formed, and a sidebar of unrelated destinations is furniture rather than an invitation.
Link rot did the rest. Any list of external links degrades over time as its destinations move or disappear, and the degradation is silent until someone clicks. The Pew Research Center's study When Online Content Disappears, published on 17 May 2024 and based on a random sample of just under a million webpages drawn from the Common Crawl archives, reports that 38% of the webpages that existed in 2013 were no longer available at the time of the study. Disappearance is not the only silent failure: Klein and colleagues, writing in PLOS ONE in December 2014 under the title Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot, examined over 3.5 million articles from arXiv, Elsevier and PubMed Central published between 1997 and 2012, and defined reference rot as "the combination of link rot and content drift" — a link can still resolve while what it pointed at has quietly become something else. That study measured references in scholarly articles rather than link lists on websites, and its figures should not be read as a measurement of anything wider. We retrieved both on 6 September 2026. A list that is visibly wrong is worse than no list, so the rational response to a rotting list is usually deletion.
Note what is absent from that list: nobody had to do anything to anyone. Every cause above is structural and most are uncoordinated. That is the honest shape of the story.
What survived, and where
Some of it did survive, in three recognisable forms.
Inside communities rather than on the open web. Shared queues and recommendation lists live on in forums, group chats, and niche communities, where the maintenance burden is spread and the social contract is understood. The mechanism is the same and the surface is private, which means it is invisible to anyone measuring the open web.
As newsletters. A person who reads widely and writes a periodic list of what they found is a blogroll with a delivery schedule. The attribution property survives intact; the standing-list property does not, because a sent issue does not update.
As small, deliberately limited collections. Curated collections with a stated scope still exist and new ones appear regularly. They are small for the reason described throughout this piece: the cost of keeping one accurate scales with its size and never stops. Current examples, and the survey of who is doing what, are in why the current revivals stay small, and a route list is in where people still find independent work.
The glossary carries plain definitions of the terms used here, and the independent web collects the rest of this cluster.
In Plain English
Before search dominated, people found websites through five main mechanisms: human-edited directories, webrings, blogrolls, shared bookmarking queues, and random buttons. Each was partial, and people used several at once.
Directories applied judgement at the door and drowned in submissions. Rings had genuine mutual consent and broke whenever a member vanished. Blogrolls were attributable and depended on one person's unpaid attention. Shared queues got curation as a by-product of people saving things for themselves, and became worth manipulating as soon as they mattered. Random buttons were cheap, and were only ever as good as the collection behind them.
They stopped for overlapping reasons that mostly do not involve anybody being at fault: recurring maintenance that nothing funded, moderation load that arrived with success, single unpaid coordinators with no succession, a change in how readers arrived, and links that quietly stopped working.
The parts that survived are the parts where the maintenance is either shared, personal, or deliberately kept small.
Sources
Each entry below is recorded in the source ledger under the identifier shown.
- S-039 · ODP submission page — Submitting a Site to The Open Directory Project, dmoz.org. Archived capture, captured 1 January 2005: https://web.archive.org/web/20050101020727/http://dmoz.org/add.html Retrieved 2026-09-06. Supports: the directory was hierarchically arranged by subject, maintained by community editors, and every submission was subject to editor evaluation with no guarantee of acceptance.
- S-038 · ODP submission FAQ — Submitting a Site to the Open Directory, dmoz.org. Archived capture, captured 1 January 2005: https://web.archive.org/web/20050101012335/http://dmoz.org/help/submission-guide.html Retrieved 2026-09-06. Supports: review could take two weeks or more depending on editor activity in the area, which is the submission queue outrunning reviewing capacity.
- S-043 · WebRing homepage — Welcome to WebRing, webring.org. Archived capture, captured 25 January 1999: https://web.archive.org/web/19990125104438/http://www.webring.org/ Retrieved 2026-09-06. Supports: sites organised by related interest into rings, navigation buttons on member pages, owners applying to join or creating a ring, and rings listed in the directory only once they hold at least five sites.
- S-042 · WebRing ring navigation — WebRing: Navigation (HTML Helper Webring), webring.org. Archived capture, captured 23 April 2000: https://web.archive.org/web/20000423135427/http://www.webring.org/cgi-bin/webring?ring=htmlhelper&id=1&next5 Retrieved 2026-09-06. Supports: the ring controls in use, including previous, next, list sites and random site.
- S-041 · WebRing management page — WebRing Management, webring.org. Archived capture, captured 17 January 1999: https://web.archive.org/web/19990117072025/http://www.webring.org/manage.html Retrieved 2026-09-06. Supports: ring owners could modify ring configuration and manage the sites in the ring, so the coordinator was a defined role.
- S-036 · WordPress Link Manager — Link Manager (plugin by Andrew Nacin), WordPress.org Plugin Directory. https://wordpress.org/plugins/link-manager/ Retrieved 2026-09-06. Supports: WordPress shipped a built-in Link Manager used to build blogrolls.
- S-035 · WordPress 3.5 release notes — Version 3.5, WordPress.org Documentation. https://wordpress.org/documentation/wordpress-version/version-3-5/ Retrieved 2026-09-06. Supports: WordPress 3.5 was released on 11 December 2012, and the Link Manager was hidden for new installs and for existing installs with no links.
- S-037 · del.icio.us homepage — del.icio.us, del.icio.us. Archived capture, captured 16 September 2005: https://web.archive.org/web/20050916215933/http://del.icio.us/ Retrieved 2026-09-06. Supports: the service's own description of itself as a social bookmarks manager with tagging, personal collections, visible saves by others and per-person subscription.
- S-033 · MediaWiki random page — Help:Random page, MediaWiki.org. https://www.mediawiki.org/wiki/Help:Random_page Retrieved 2026-09-06. Supports: Special:Random shows a wiki page at random, optionally within a chosen namespace.
- S-040 · StumbleUpon About page — About StumbleUpon, stumbleupon.com. Archived capture, captured 30 June 2007: https://web.archive.org/web/20070630101103/http://www.stumbleupon.com/about.html Retrieved 2026-09-06. Supports: the service described preference-matched delivery of pages recommended by other users, not random selection.
- S-010 · Pew link rot study — When Online Content Disappears, Pew Research Center (Athena Chapekis, Samuel Bestvater, Emma Remy and Gonzalo Rivero, 17 May 2024). https://www.pewresearch.org/data-labs/2024/05/17/when-online-content-disappears/ Retrieved 2026-09-06. Supports: 38% of webpages that existed in 2013 were no longer available at the time of the study, from a random sample of just under a million pages taken from Common Crawl.
- S-011 · Reference rot study — Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot, Martin Klein, Herbert Van de Sompel, Robert Sanderson, Harihar Shankar, Lyudmila Balakireva, Ke Zhou and Richard Tobin, PLOS ONE, 26 December 2014. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0115253 Retrieved 2026-09-06. Supports: reference rot defined as link rot plus content drift, measured across more than 3.5 million arXiv, Elsevier and PubMed Central articles published 1997–2012.
Try the stumble if you would rather see the mechanism working than read about it.