Someone saved a link to your page.

There is no schedule and no index behind it. It never follows a link out of a page it fetched, never asks for a second page from your site on its own initiative, and never returns to see whether anything changed. Every address it asks for is one a person saved by hand or brought with them from another bookmark manager — nothing here discovers a page. One extraction attempt for one saved link makes one document request to you, plus one for a preview image if your document names one. A transient failure can be retried later. The person’s browser can’t read that image cross-origin any more than it could read your page — that’s why we need the second request.

There is a backlog, though, and it is theirs rather than ours. Links saved before previews were turned on, and anything brought in by an import, sit unfetched until their owner asks for them — so a request can arrive long after the save, and several can arrive together: a drain hands us addresses in batches — the cap on one request is in the table below — and we fetch a batch in parallel. Someone importing two hundred of your pages means one request for each page, close together; transient failures may be retried later. What decides the initial batch is the size of one person’s library, not a crawl or index of ours.

The person who asked keeps what comes back: it lives on their own devices from then on, encrypted, so saving the same address again doesn’t re-ask you for it.

It also only runs for people who turned it on. Fetching on someone’s behalf means seeing an address they chose to save, so it is an opt-in setting that is off until they enable it — the browser extension and the mobile apps read the page on the device instead, with no server of ours in it. The full account of that is in the privacy policy.

Said plainly, because this is the page where you came looking for it. A robots directive won’t stop this fetcher, and we would rather disclose that than let you write a rule that quietly does nothing.

The reasoning, for what it is worth, is about who chose — not about how much gets read. A robots directive governs automated discovery: something deciding on its own what to visit next, at a cadence and a volume you never agreed to. Nothing here decides anything. One person put one address into their own library, one request went out because of that, and what came back went to their device and nowhere else. There is no queue behind it for a directive to shorten and no next page for it to keep us away from.

That is an argument, and one we could lose. It rests entirely on the request being one person’s and on there being exactly one of them. If this service ever fetches on its own initiative, or at a volume that a single save can’t account for, the argument is gone and this section gets rewritten rather than defended. Blocking by user agent works either way, which is why that is documented below.

Match the user agent — every request carries bracemark-extractor in that header, and it is never spoofed as a browser — then answer with 403.

The status code you pick decides how long we keep trying. A 403 is retried on a widening backoff and then abandoned for good. A 404 or 410 settles it immediately, first time. A 429 or a 5xx reads as temporary, so it will come back — slowly, and at most once a day for that one link, but it will. The 403 in the rule above ends it; send a 410 instead if you would rather that happened on the first request than at the top of the ladder.

Don’t block it by address. It runs on Cloudflare Workers, so its requests leave from a shared pool that has nothing else to do with us, and banning those addresses costs you traffic you wanted while barely inconveniencing this.

What blocking does to the person who saved the link: they get your hostname as the title and no preview image. The link still works, they aren’t told why, and nothing else about your site is affected.