History

One search box across many collections: the 2007 tool, and what a bookmark search actually indexes in 2026

Every tool in this space claims full-text search, and the phrase covers at least four different products — the URL and title, the fetched readable text, the stored snapshot, and an embedding index — which behave completely differently the moment the source page goes offline.

Published 2026-08-06 · Updated — · 2,915 words · 26 sources · Status of facts checked 2026-08-06

In February 2007 the site at this address published a way to search about fifty social bookmarking services from one field. Nineteen years later the only part of it that still exists as a file is 1,448 bytes of XML held in the Internet Archive: a browser search plugin describing where to send a query. The index it queried was never at this address, was never captured, and cannot be reconstructed. Every bookmark search sold in 2026 sits somewhere on that same axis — a pointer to somebody else’s index at one end, a copy the searcher holds at the other — and the label on the box is the same either way.

What is left of the 2007 tool

A Wayback CDX query against this exact path returns 43 records: http://web.archive.org/cdx/search/cdx?url=infopirate.org/_social-bookmark-search&matchType=exact&output=text (retrieved 2026-08-06).¹ Thirty-nine returned status 200. The first is stamped 2007-02-20; a 404 is recorded on 2007-06-27, after which 200 responses resume on 2007-07-05 and continue into 2011. The last 200 is stamped 2016-03-13, and by that date its body carried the same SHA-1 digest as the response at the sibling path /social-bookmark-search captured the same day — two addresses returning byte-identical bodies, which is what a placeholder looks like from outside. What that body contained is not asserted here.²

The tool itself lived one path over, at /social-bookmark-search, and its 2007 captures show two components: a search form carrying a Google Co-op custom search engine, loaded through a script at www.google.com/coop/cse/brand and identified by the engine string 003066389405821038163:ht3daia9abk;³ and a browser search plugin offered for download at /downloads/BookmarkSearch.xml.

That plugin file is the one component of the system that survives byte-for-byte. It is an OpenSearch 1.1 description document — root element OpenSearchDescription in the namespace http://a9.com/-/spec/opensearch/1.1/, carrying a single Url element whose template points back at the site’s own results path with the engine identifier and a {searchTerms} placeholder.⁴ That format is what a browser reads when it adds an engine to its search bar.⁵ Seventeen CDX records exist for the file, two of them 404s. Every 200 among them, from 2007-02-20 to 2011-03-15, carries the identical digest B2XH23DLFDX5WFWFIWVBD66MPAAC5LMP: the file was not edited across those four years.⁶

A pointer of 1,448 bytes is still readable in the archive nineteen years after it was first captured. The corpus it addressed is not readable anywhere, because it was never here.

Why one box across many services was a real problem in 2007

In 2007 a person who saved links seriously had collections in more than one place, and each service kept its own index over its own users’ records. A tag applied in one service was not a tag in another; there was no shared namespace and no query that crossed a service boundary. The roster the sibling page at this address enumerated ran to about fifty names, which is the measure of the problem.

The 2007 answer was to hand the list of domains to a search engine that already crawled them. Google’s own documentation for the product describes the arrangement plainly: the operator tells the engine which websites to search, prioritise or ignore.⁷ Four consequences follow from that design, and all four are still the consequences of any federated search built the same way in 2026.

Only publicly crawlable pages were reachable. A bookmark marked private, or held behind a login, was outside the corpus entirely.
Freshness was the crawler’s, not the saver’s: a link saved an hour ago became findable when Google next fetched the page it appeared on.
The engine held no copy of anything. It was a filter over an index someone else maintained, and that index did the remembering.
When a listed service went offline, its slice of the results went with it — not gradually, and with nothing left behind to consult.

Of the fifty names on the 2007 roster captured at this address, eight still offer somewhere to save a link, one survives read-only, eleven are documented as shut down, and thirty could not be verified; the dated row for each is in the Ledger, and the census is on the flagship page. A federated search across that roster today would reach a minority of it. Nothing about the tool failed; its subject did.

What happened to the platform, stated precisely

The often-repeated line that Google Custom Search Engine “was retired” is wrong, and the accurate version is more useful. Wikipedia, cited here as a secondary source, dates the product’s launch to October 2006, giving 2006-10-24 for Google Co-op and 2006-10-23 for Custom Search Engine.⁸ The product still exists as Programmable Search Engine, and its documentation is live as of 2026-08-06.⁷ What changed happened in two steps, both dated by Google itself.

First, the Custom Search Site Restricted JSON API: Google’s documentation for that endpoint states it “will cease to serve traffic on January 8, 2025”, directing users to Vertex AI Search.⁹ That is the machine interface rather than the search box — a site querying the platform programmatically lost that route on a stated date.

Second, on 2026-01-20, Google published a post titled “Updates to our Web Search Products & Programmable Search Engine Capabilities”. It sets a transition window running to 2027-01-01, keeps a free “Sites to search” feature for a maximum of 50 domains, and directs anyone querying more than 50 domains or set to “Search the entire web” to contact Google about a paid full-web solution.¹⁰ Reporting by heise online on 2026-01-24 states the same change from the other end: new Programmable Search Engines may index a maximum of 50 domains, the option to search the entire web is no longer available for new engines, and operators of existing engines which exceed 50 domains or use the full index must migrate by 2027-01-01, with Vertex AI Search offered as the paid replacement.¹¹

The arithmetic is worth stating plainly. The roster this address indexed in 2007 ran to about fifty services; an engine created on the same platform in 2026 may cover 50 domains. The same tool is still buildable, and only just.

Whether the original 2007 engine identified as 003066389405821038163:ht3daia9abk still exists or still returns results was not tested, and no claim is made here either way.

Four different things called full-text search

Nearly every current tool in this space advertises search, and many advertise full-text search. The phrase covers at least four products, distinguished by one question the marketing does not answer: what text is in the index, and where did that text come from? The answer decides everything that happens after the source page goes offline.

Tier 1 — URL and title

The index holds the address and a label: whatever title was scraped or typed at save time, plus any description, note or tag the saver entered. Nothing from the body of the page is in it. This index survives the death of the page perfectly, because it never touched the page — and it cannot answer a question the label does not already answer.

Tier 2 — extracted readable text

At save time the tool fetches the page, runs an article extraction over it, stores the resulting text and indexes that. The text is a copy the tool holds, so a query still matches after the source 404s. Not in it: layout, images, embedded media, whatever the extractor discarded, and anything that failed to fetch at save time.

Tier 3 — stored snapshot

The tool stores the page as files — single-file HTML, a DOM dump, a PDF — and builds the index out of those files. This is the only tier that can answer “what did that page look like”, and the only one whose index and artefact are the same object. It is also the tier whose custody question is sharpest, because the copy sits somewhere specific, on terms someone sets.

Tier 4 — embeddings

A vector index computed from text the tool already holds, matching by proximity of meaning rather than by shared words. It adds recall and no custody, and it has no tier of its own: an embedding computed from a title is an index of a title. Semantic search over a tier 1 store cannot find a phrase nobody stored.

What each index matches, checked 2026-08-06

Every cell below comes from the named project’s own source code or published documentation, retrieved 2026-08-06. No product was used, tested or run to produce this table, and nothing in it is a ranking.

Index scope and its source, checked 2026-08-06
Tool, and plan where it decides	Index tier	What the index matches	After the source page 404s	Evidence
Chromium bookmark index (Chrome)	URL + title	Strings occurring in a bookmark’s title or URL	Index intact; no content to return	¹²
linkding (source read 2026-08-06)	URL + title	Title, description, notes, URL; tag names too in lax mode	Index intact; stored snapshots are not searched	¹³
wallabag (source read 2026-08-06)	extracted readable text	Stored article content, title, URL, annotation text	Text stays searchable and readable	¹⁴
Readeck	extracted readable text	Bookmark text, title, authors, site name and domain, labels	Text stays searchable and readable	¹⁵
Karakeep v0.33.1 (2026-08-01)	extracted readable text; embeddings	Plain-text content of the crawled page, note, summary, title, tags; three modes — full text, semantic, hybrid	Crawled text stays searchable	¹⁶¹⁷
ArchiveBox (source read 2026-08-06)	stored snapshot	Text of archived outputs only — readability, singlefile, DOM or wget	Snapshot and index both held locally	¹⁸
Pinboard, regular account	URL + title	Titles, tags and descriptions	Index intact; no content to return	¹⁹
Pinboard, archival account, $39/yr	stored snapshot	Any word or phrase that appeared anywhere on the stored page; the full-text index is updated nightly	Cached copy remains viewable	¹⁹²⁰
Raindrop.io, free plan	URL + title	Title, description, URL, tags, notes	Index intact; no content to return	²¹
Raindrop.io, Pro plan	stored snapshot; embeddings	Full text of the web-archive copy, PDF and EPUB pages, YouTube transcripts; also matches by meaning	Copy survives the page — but not the subscription	²¹²²
Instapaper, Premium, $5.99/mo or $59.99/yr	extracted readable text	Full-text search across articles in the account; permanent archive listed as Premium	Archived article text remains	²³

Scroll →

Storage tier and index tier are separate settings

The most useful fact in that table is easy to miss: a tool can hold a copy it cannot search.

linkding is the documented case. Its own documentation describes server-side archiving that creates an HTML snapshot of each bookmarked page using singlefile-cli, plus two browser-side routes that upload a snapshot taken in the reader’s own browser.²⁴ Those snapshots answer the custody question. They do not answer the retrieval question, because the search conditions in the project’s query code match on title, description, notes and URL — and, in lax mode, tag names — and on nothing else.¹³ A phrase remembered from the middle of an archived page is in the snapshot on disk and outside the index that finds it.

ArchiveBox is the inverse arrangement. Its indexing helper takes content only from four extractor outputs — readability, singlefile, DOM and wget — and returns nothing for any other extractor.¹⁸ The index is built out of the stored artefact by construction, so it cannot describe anything the archive does not hold.

Pinboard separates the two on a third axis, time. Its FAQ states that a bookmarked link is crawled once, that updating the saved copy requires asking for a re-crawl, and that full-text search is updated nightly.¹⁹ The stored copy and the index over it run on different clocks, and neither is the clock of the page.

Stated as a rule: a collection whose owner expects to search by remembered wording needs its index tier and its storage tier chosen together, and in most tools that offer both they are configured separately.

What an embedding index adds, and what it cannot

Karakeep’s v0.33.1 release of 2026-08-01 is a dated example of the fourth tier arriving in a tool that already had the second. The release notes describe three search modes: full text, the existing keyword search and still the default; semantic, described as experimental and powered by embeddings; and hybrid, which fuses both.¹⁷ What is being embedded is visible in the project’s own indexing worker, whose document for each bookmark includes the plain-text content, note, summary, title and tags.¹⁶ Raindrop’s help pages describe the same combination on a hosted service: matching by meaning, over an archive they state is required for content search and available on the Pro plan.²¹

The property that matters is inheritance. A vector index is derived from text the tool already stored; it fetches nothing and preserves nothing. Where the stored text is an article body, semantic search reaches into the article; where the stored text is a title, it reaches a title more cleverly. Embeddings are also not readable: vectors do not reconstitute a page for someone who wants to see what it said.

Why a saved page cannot be found again

The question this article exists to answer was put on Hacker News on 2025-08-16 by a commenter posting as hungmung, in the thread “Ask HN: Do you still bookmark websites?”. The words below are that commenter’s, quoted from the archived thread and not this publication’s:²⁵

Yes, but I can never find what I’m looking for again because I don’t organize them myself and Firefox mobile’s bookmark search is bordering on unusable. … I want a separate, local-only, bookmark application that saves the bookmark, takes a full snapshot of that page, and lets me grep through all the snapshots for whatever I’m searching for.

The mechanism is checkable in a browser’s own source. Chromium maintains a bookmark index whose header describes it as a map from a lower-case string to the set of nodes containing that string in their title or URL.¹² A phrase from the body of a saved page has never been in that structure. A published Mozilla statement of what Firefox for Android’s bookmark search matches could not be verified, so no equivalent claim is made about it.

Three rules follow, each tied to a stated requirement rather than to a preference:

A collection that must be re-findable by remembered content requires text stored at save time. Adding search to a tier 1 collection later cannot recover text nobody kept; retrieval is decided when the link is saved, not when the search is run.
A collection that must answer “what did that page look like” requires a stored snapshot, and a collection that only needs to be re-findable by name does not.
A stored copy inherits the lifespan of whoever holds it. Raindrop’s own documentation states that when a subscription expires, archived copies become inaccessible and are permanently deleted after about a month, while the bookmarks themselves are unaffected — which is the tier 3 collection reverting to tier 1 on a billing event.²²

The 2007 tool at this address failed in the first way, at the scale of an entire web of services: the index it queried was a view of other people’s pages, and the moment those pages stopped being served there was nothing to search. The 1,448-byte pointer outlived all of it, which is the ordinary outcome. Pointers are small and cheap to keep. What they point at is neither.

Where to find it now

GONE infopirate.org/_social-bookmark-search — this address: 43 records in the Wayback CDX index, 39 with status 200, first stamped 2007-02-20, last 200 stamped 2016-03-13. The four remaining records are a 404 on 2007-06-27, a 301 from the www host on 2012-06-23, a 404 on 2016-11-09 and a 301 on 2020-02-06 (query and retrieval date in reference 1). No export existed and none survives; this path was a listing page, not a data store.
GONE infopirate.org/social-bookmark-search — the search tool itself: 109 CDX records, 103 with status 200, first stamped 2007-02-19, last 200 stamped 2016-03-13; the path was already returning 404 on 2011-11-11, and the final record is a 404 stamped 2021-10-03. The captures preserve the search form and the page around it. They do not preserve the engine, whose configuration and index were held by Google and never served from this domain.
GONE infopirate.org/downloads/BookmarkSearch.xml — the search plugin: 17 CDX records; every 200 from 2007-02-20 to 2011-03-15 carries the same digest, so the file is recoverable in its original form from any of them. It is an OpenSearch 1.1 description document of 1,448 bytes: a query template, not a copy of anything.
KEPT Google Co-op / Custom Search Engine: The product continues as Programmable Search Engine (documentation live, checked 2026-08-06). The Site Restricted JSON API ceased serving traffic on 2025-01-08 per Google’s own documentation; the announcement of 2026-01-20 keeps a free tier of at most 50 domains and sets 2027-01-01 as the transition deadline for anyone above that or using the whole-web option. Whether the 2007 engine at this address still functions was not tested and is not claimed either way.
GONE Pocket — the reason many readers faced this question in 2025: Mozilla announced the shutdown on 2025-05-22; the service stopped working on 2025-07-08; exports remained available until 2025-10-08, after which accounts and data were deleted.²⁶ An export taken before that date is the only copy that exists, and whether it carries article text or only URLs and titles was decided years earlier, by the tier question above.

References

Internet Archive. “CDX Server API.” Wayback Machine documentation, n.d. https://github.com/internetarchive/wayback/blob/master/wayback-cdx-server/README.md — retrieved 2026-08-06. Query used: http://web.archive.org/cdx/search/cdx?url=infopirate.org/_social-bookmark-search&matchType=exact&output=text ↩
Internet Archive. “Capture of infopirate.org/_social-bookmark-search.” Wayback Machine, 2007-02-20. https://web.archive.org/web/20070220083221/http://infopirate.org/_social-bookmark-search — retrieved 2026-08-06. ↩
Internet Archive. “Capture of infopirate.org/social-bookmark-search.” Wayback Machine, 2007-02-19. https://web.archive.org/web/20070219022016/http://infopirate.org/social-bookmark-search — retrieved 2026-08-06. ↩
Internet Archive. “Capture of infopirate.org/downloads/BookmarkSearch.xml.” Wayback Machine, 2007-02-20. https://web.archive.org/web/20070220070931/http://infopirate.org/downloads/BookmarkSearch.xml — retrieved 2026-08-06. Byte count taken from the unmodified archived response. ↩
Clinton, DeWitt, et al. “OpenSearch specification.” OpenSearch, n.d. https://github.com/dewitt/opensearch — retrieved 2026-08-06. ↩
Internet Archive. “CDX records for infopirate.org/downloads/BookmarkSearch.xml.” Wayback Machine, n.d. https://web.archive.org/cdx/search/cdx?url=infopirate.org/downloads/BookmarkSearch.xml&matchType=exact&output=text — retrieved 2026-08-06. ↩
Google. “Programmable Search Engine: Overview.” Google for Developers, n.d. https://developers.google.com/custom-search/docs/overview — retrieved 2026-08-06. ↩
Wikipedia contributors. “Google Programmable Search Engine.” Wikipedia, n.d. https://en.wikipedia.org/wiki/Google_Programmable_Search_Engine — retrieved 2026-08-06. Cited as a secondary source for the October 2006 launch dates, which the article gives one day apart. ↩
Google. “Custom Search Site Restricted JSON API.” Google for Developers, n.d. https://developers.google.com/custom-search/v1/site_restricted_api — retrieved 2026-08-06. ↩
Google. “Updates to our Web Search Products & Programmable Search Engine Capabilities.” Programmable Search Engine Blog, 2026-01-20. https://programmablesearchengine.googleblog.com/2026/01/updates-to-our-web-search-products.html — retrieved 2026-08-06. ↩
Förster, Moritz. “Google is discontinuing its free web search index for developers.” heise online, 2026-01-24. https://www.heise.de/en/news/Google-is-discontinuing-its-free-web-search-index-for-developers-11152411.html — retrieved 2026-08-06. ↩
The Chromium Authors. “components/bookmarks/browser/titled_url_index.h.” Chromium source, n.d. https://chromium.googlesource.com/chromium/src/+/main/components/bookmarks/browser/titled_url_index.h — retrieved 2026-08-06. ↩
Ißbrücker, Sascha, and contributors. “bookmarks/queries.py.” linkding source, master branch, n.d. https://github.com/sissbruecker/linkding/blob/master/bookmarks/queries.py — retrieved 2026-08-06. ↩
wallabag contributors. “src/Repository/EntryRepository.php.” wallabag source, master branch, n.d. https://github.com/wallabag/wallabag/blob/master/src/Repository/EntryRepository.php — retrieved 2026-08-06. ↩
Readeck. “Bookmark List.” Readeck documentation, n.d. https://codeberg.org/readeck/readeck/src/branch/main/docs/src/en/bookmark-list.md — retrieved 2026-08-06. ↩
Karakeep contributors. “apps/workers/workers/searchWorker.ts.” Karakeep source, main branch, n.d. https://github.com/karakeep-app/karakeep/blob/main/apps/workers/workers/searchWorker.ts — retrieved 2026-08-06. ↩
Karakeep. “Release 0.33.1.” GitHub, 2026-08-01. https://github.com/karakeep-app/karakeep/releases/tag/v0.33.1 — retrieved 2026-08-06. ↩
ArchiveBox contributors. “archivebox/search/utils.py.” ArchiveBox source, main branch, n.d. https://github.com/ArchiveBox/ArchiveBox/blob/main/archivebox/search/utils.py — retrieved 2026-08-06. ↩
Pinboard. “Frequently Asked Questions.” pinboard.in, n.d. https://pinboard.in/faq/ — retrieved 2026-08-06. ↩
Pinboard. “A Tour of Pinboard.” pinboard.in, n.d. https://pinboard.in/tour/ — retrieved 2026-08-06. ↩
Raindrop.io. “Search.” Raindrop.io help, n.d. https://help.raindrop.io/using-search — retrieved 2026-08-06. ↩
Raindrop.io. “Web archive.” Raindrop.io help, n.d. https://help.raindrop.io/web-archive — retrieved 2026-08-06. ↩
Instapaper. “Instapaper Premium.” instapaper.com, n.d. https://www.instapaper.com/premium — retrieved 2026-08-06. ↩
linkding contributors. “Archiving.” linkding documentation, n.d. https://github.com/sissbruecker/linkding/blob/master/docs/src/content/docs/archiving.md — retrieved 2026-08-06. ↩
hungmung. Comment in “Ask HN: Do you still bookmark websites?” Hacker News, 2025-08-16. https://news.ycombinator.com/item?id=44925925 — retrieved 2026-08-06. ↩
9to5Mac. “Mozilla announces shutdown of Pocket.” 9to5Mac, 2025-05-22. https://9to5mac.com/2025/05/22/mozilla-announces-shutdown-of-pocket/ — retrieved 2026-08-06. ↩

Notes

CDX record counts are counts of index records, not of distinct page states: the same body captured twice produces two records with one digest. Counts here were taken from the unfiltered CDX response on 2026-08-06 and will grow if the address is crawled again.
The engine identifier printed in this article appears in a publicly archived page and is reproduced as a machine-readable fact about the artefact. It is not a working search box, a recommendation, or a claim about the current state of that engine.
Prices are the figures published on each service’s own page, retrieved 2026-08-06, and are stated to show which tier a plan boundary falls on. No plan is recommended and no comparison of value is made.
The blockquote in “Why a saved page cannot be found again” is a third party’s posted comment, quoted for what it asks. Nothing in this article describes anyone at this publication using, testing or running any product named in it.

From 2007 to about 2010 this address was a listing page on a Drupal social bookmarking community, carrying the postings for its custom search tool: a Google Co-op engine over roughly fifty bookmarking services, plus an OpenSearch plugin served from the same site. Captures of substance run from 2007-02-20 into 2011, the last 200 response is stamped 2016-03-13, and a 404 follows on 2016-11-09; the sibling path that held the tool was already returning 404 on 2011-11-11. The address is still cited by playpcesor.com, a Taiwanese productivity blog.