# How to clear a bookmark backlog · ZeroMark > A method for working down hundreds of saved posts: separating the backlog from the queue, what order to work in, and why letting go is the whole skill. Canonical: https://www.zeromark.io/blog/clear-your-bookmark-backlog [ZeroMark](https://www.zeromark.io/) / [Blog](https://www.zeromark.io/blog) ## How to clear a bookmark backlog August 26, 2026 A method for the pile you have been not-looking-at for two years. The pile is not a reading list. It is a list of decisions you postponed, and it shrinks when you make them, not when you read. Most saves should be deleted unread, and accepting that is the entire difficulty. Everyone who has a backlog has already tried the obvious thing, which is to read their way out of it. It does not work, for a reason worth stating plainly: you save faster than you read. If the pile took two years to build at a rate you could not keep up with, no burst of reading closes it. The rate has to change or the pile has to be triaged rather than consumed. ### Before anything else, export Take a copy. Bookmarks are excluded from X's official data archive so this means a browser extension, and it takes about five minutes. The point is not that you will read the export. It is that every decision after this becomes reversible, and reversible decisions get made. People stall on deleting saves because deleting feels permanent; it stops feeling permanent when there is a CSV on your desktop. ### Split the backlog from the queue Draw a line at a date. Six months back is a good default. Everything older is the backlog; everything newer is the queue. These are different objects and the mistake is treating them as one list. Then be honest about the backlog. Something you saved eighteen months ago and have not opened was not important. It felt important for ninety seconds inside a thread you no longer remember. The realistic options are: - **Delete the lot.** You have the export. Nothing is destroyed. - **Skim titles only**, rescue the handful that make you sit up, delete the rest. Budget one session, not one project. What does not work is deciding to work through it properly later. That is what the last two years were. ### Working the queue Three rules, and the order matters: #### Oldest first Newest-first feels better and never finishes, because new saves keep arriving at the top and you re-triage the same recent posts forever while the old ones calcify. Oldest first is unpleasant and it is the only order where the count reaches zero. #### One at a time, one decision each Open a save and decide immediately: keep it, let it go, or come back to it on a named day. Not "maybe". A maybe is a save you have now handled twice and disposed of zero times, and a pile of maybes is where backlogs come from in the first place. #### Time-box it Fifteen minutes, same slot each week. Long sessions make you lenient, because at minute forty everything starts looking worth keeping and you stop deleting. Short sessions keep you honest. ### A script for the first session The hardest session is the first one, so here it is as a set of instructions you can follow without deciding anything in advance: - Export. Five minutes. Do not skip it, because everything below depends on decisions feeling reversible. - Set a timer for fifteen minutes. - Go to the oldest saves you can reach. - For each one, ask a single question: *would I choose to spend ten minutes on this today?* Not "is this good", not "might this be useful". Would I choose it, today, over the other things I could read. - No is a delete. Yes goes in a folder called This Week. There is no third option. - When the timer goes, stop, even mid-scroll. Note the count. Most people delete somewhere between seventy and ninety percent in that first pass and feel noticeably lighter afterwards, which tells you what the pile was actually made of. ### The ways this goes wrong - **Reading during triage.** The single most common failure. You open something good, read it, twenty minutes evaporate, and you have triaged one item. Triage and reading are separate activities on separate days. - **Inventing a Maybe pile.** A maybe is a decision you have now made twice and resolved zero times. If it needs a maybe, it is a no. - **Starting from the newest.** Feels productive, never terminates. - **Waiting for a big block of time.** The four-hour session you are waiting for will not happen, and if it does you will be too lenient by hour two. - **Rescuing things into a folder you never open.** If This Week does not get read this week, the honest move is to delete it rather than promote it to a second backlog. ### The number that matters Track how many are left, not how many you have read. Reading is not the goal; the goal is that the pile is gone. Those come apart immediately, and the count is the only one of the two that tells you whether the situation is improving. If the count is flat, you are saving as fast as you triage, and the fix is upstream: save less, or triage more often. If it is climbing, no session length will rescue it. ### What to do with the ones you keep Triage produces two outputs, and most advice only covers the deletions. The keeps need somewhere to go or they quietly reconstitute the pile: - **If it is a thing to read,** put it where you actually read, which for most people is not X. Move it and delete the bookmark, so the queue reflects only what is undecided. - **If it is reference,** move it to wherever your reference lives and, again, delete the bookmark. A save that exists in two places is a save you will triage twice. - **If it needs a reply,** do it now. It is almost always ninety seconds and it is the only category that gets worse with age. The rule underneath all three: a bookmark should mean "not yet decided". The moment it has been decided, it should leave, whichever direction it goes. A list where keeps and undecideds live together is a list you cannot read the length of. ### Stopping it coming back - **Raise the bar at save time.** "Would I set aside ten minutes for this on a Tuesday?" removes most of what you save. - **Read short things now.** If it takes two minutes, it never needed saving. - **Keep the standing slot** even when the pile is small. It is much easier to hold at zero than to return to it. ### The uncomfortable part A bookmark is a promise to your future self, and a backlog is a stack of broken ones. That is why the pile feels heavier than a list of links should, and why "organise it" is so appealing: filing feels like keeping the promise without doing the reading. It is not, and the relief people describe after clearing a backlog does not come from having read anything. It comes from having stopped owing. ### Related - [How to organize your X bookmarks](https://www.zeromark.io/blog/how-to-organize-x-bookmarks) - [Is there a limit on X bookmarks?](https://www.zeromark.io/blog/x-bookmark-limit) - [How to search your X bookmarks](https://www.zeromark.io/blog/search-x-bookmarks) **ZeroMark** is inbox zero for X bookmarks. Agents read every save and file it by field, then you keep it, let it go, or come back later, one at a time, until the pile is gone. It is the opposite of an archive: the open count only goes down. [Start free →](https://www.zeromark.io/trial)