Fix a Messy Obsidian Vault - The 30-Day Findability Makeover

This article is part 4 of my series on finding notes in Obsidian. The overview, with the map of all 12 parts, is The Complete Guide to Obsidian Search.

The usual way to clean up a vault is a big weekend reorganization. It rarely survives the week, and you never find out whether search actually got better.

This article gives you a different plan. First, a 30-day findability makeover: 15 minutes a day, one layer at a time, with a measurement on day 3 and another on day 28, so you can see the difference in numbers. Second, a findability pass for notes you imported from Evernote, Notion, OneNote or another app, including how to let an AI agent do the tedious part safely.

TL;DR

• Fix what you search for, not the whole vault. A note you never look for doesn't need a better title.
• Measure before you change anything. Write 20 real queries, score them on day 3, and score them again on day 28.
• One layer per week: cut the noise, then names and aliases, then types, tags and properties, then links and maps. 15 minutes a day.
• Back up or commit before bulk changes. Tag merges can't be undone, and your sync must finish first.
• Imported notes go into their own folder. Keep their original dates in properties, and promote notes into your system when you need them.
• An AI agent can propose titles, tags, types and links in bulk. Work on a git branch, in small batches, and never let it delete.

A 30-day findability makeover for a messy vault

Part 2 and part 3 assume you're creating new notes. But what if your vault already holds thousands of notes with vague titles, three tagging systems and no note types? You don't need to start over, and you shouldn't try to fix everything at once.

The rule for the whole plan: fix what you search for, not the whole vault. A note you never look for doesn't need a better title. In It's fine if your note-taking system is a bit messy, I put it this way: "Just improve what you can when you can. Don't turn your PKM into a way to procrastinate."

The plan below takes 15 minutes a day for 30 days. It starts by measuring how well search works today, so that on day 28 you can compare. Each step reuses a tool explained elsewhere in this series; I point to the part instead of repeating it.

Before you start

• Back up your vault, or commit it to git. Several steps rename, merge and move notes in bulk. Tag merges can't be undone, and you want an easy way back (see "Recover old versions and deleted notes" in part 6).
• Create one note for the makeover. It holds your test queries, your scores and your numbers. Call it something you'll find, like Findability makeover 2026-10.
• Set a 15-minute timer, and stop when it rings. Unfinished items move to the next day. Skipping a day is fine; skipping the measurement on days 3 and 28 is not.

Week 1 (days 1 to 7): measure, then cut the noise

• [ ] Day 1. Write down 10 real searches from the past weeks, with the note you expected to find. "Test your search with 20 queries" (part 10) explains how to pick them.
• [ ] Day 2. Write 10 more. Mix them like part 10 suggests: exact names, paraphrases, vague memories, and two queries with no answer in your vault.
• [ ] Day 3. Run all 20 in the quick switcher and the Search view. Note the rank of the expected note, and compute your Recall@5 (the share of queries where it shows up in the top 5). That's your baseline.
• [ ] Day 4. Write down the mess in numbers: obsidian orphans total, obsidian unresolved total, the number of tags in the Tags view, and how many notes have no tags at all.
• [ ] Day 5. Create a maintenance Base with three views from part 5 ("Real Bases I use to find notes"): orphans, notes without tags, and notes created in the last 7 days. You'll use it all month.
• [ ] Day 6. Cut the noise: add your archive, templates and generated or imported folders to Excluded files, or scope them out of your saved searches with -path: (see "Archive what's done" in part 3).
• [ ] Day 7. Archive one batch of dead notes: finished projects, closed tasks, abandoned drafts. One folder per session. Move them to your archive; don't delete them.

Done when: you have a baseline score, a list of numbers, and fewer irrelevant results on every search.

Week 2 (days 8 to 14): names and aliases

• [ ] Day 8. List the 30 to 50 notes you open most: your bookmarks, the recent notes in the quick switcher (empty query), your Maps of Content, the notes linked from your home note. These are the ONLY notes you rename this week.
• [ ] Days 9 to 11. Rename 10 to 15 of them per day with the rules from "Name notes like you'll search for them" in part 2: keywords first, claims for idea notes, ISO dates, the acronym in parentheses. Keep each old title as an alias.
• [ ] Day 12. Go back to the misses from day 3. For each one, rename the expected note with the words you searched for, or add those words as aliases.
• [ ] Day 13. Run the duplicate checks from part 6 ("Find and merge duplicate notes") and list the pairs.
• [ ] Day 14. Merge the real duplicates with Note composer, and add the losing title as an alias of the note you keep.

Done when: the notes you use most have titles you'd actually type, and the day 3 misses are fixed.

Week 3 (days 15 to 21): types, tags and properties

• [ ] Day 15. Write down your note types. Five to ten is plenty: meeting, person, project, book, idea... For each one, pick a type tag (or a type value) and a folder, as described in "Folders: few, and by type" in part 3.
• [ ] Days 16 and 17. Add the type to existing notes, one folder at a time. When a folder only holds one kind of note, a small loop does it (see below).
• [ ] Day 18. Open the Tags view, sort by frequency, and list the near-duplicates: #book and #books, #meeting and #meetings.
• [ ] Day 19. Merge them with Tag Wrangler (part 8). Let your sync finish first.
• [ ] Day 20. Do the same for properties in the All properties view: author and authors, source and sources.
• [ ] Day 21. Fix the source of the mess: give each note type a template that adds the type, the dates and a few tags (see "Your capture-time checklist" in part 3). From now on, new notes don't add to the pile.

Here's the loop for days 16 and 17. It uses the Obsidian CLI (part 6), so Obsidian writes the property itself and the YAML stays valid:

cd ~/vault
fd -e md . "Meetings" | while IFS= read -r f; do
  obsidian property:set path="$f" name=type value=meeting
done

property:set sets a value: it doesn't add to a list. Use it for a property the notes don't have yet, like type. Don't use it on tags, or you'll replace the tags those notes already carry. It's one call per note, so on a big folder, let it run while you do something else. Commit before, and check a few notes after.

Week 4 (days 22 to 30): links, maps and a second measurement

• [ ] Day 22. Rank your unresolved links by count (part 8, "Rank unresolved links to find missing hubs"). Create the notes for the top five, and fix the broken ones.
• [ ] Days 23 and 24. Open the orphans view of your maintenance Base and process 15 notes per day: link each one from a MoC or a related note, merge it, archive it or delete it.
• [ ] Days 25 and 26. Build two or three Maps of Content where browsing feels overwhelming (Nick Milo's "mental squeeze point", see "Links and Maps of Content" in part 3).
• [ ] Day 27. Add a section to your daily note template that links every note you create that day (see "Daily notes as a timeline" in part 3).
• [ ] Day 28. Re-run your 20 queries, and compare Recall@5 with day 3. Update the numbers from day 4.
• [ ] Day 29. For each query that still fails, ask which layer of the findability stack (part 1) should have caught it, and fix that layer. Bookmark the searches you ran more than twice this month.
• [ ] Day 30. Put a monthly 30-minute findability review in your calendar: check the numbers, work through the maintenance Base, and re-run the 20 queries once a quarter.

Done when: you have two scores to compare, and a review on your calendar.

Gotchas

• Don't rename your whole vault. Thirty days won't cover 5,000 notes, and they don't need to. After the makeover, keep fixing notes when you run into them, with the debugging loop of the findability stack (part 1): every failed search fixes one note.
• Scope the days in a big vault. If your vault holds 10,000 notes or more, apply each day's task to one folder or one note type, not to everything.
• Bulk changes and sync don't mix well. Before a bulk rename, a tag merge or the property loop, let your sync tool finish, and avoid editing the same notes on another device.
• Treat old notes as drafts. In Iterative and incremental note-taking, I wrote: "Every time you stumble upon an old note, you should consider it as a draft that needs improvements." The makeover gives you a clean starting point; the habit keeps it clean.

Imported notes need a findability pass

The official Importer plugin, made by the Obsidian team, converts notes from Evernote, Notion, Microsoft OneNote, Apple Notes, Google Keep, Bear, Roam Research and other apps into Markdown files. What it can't do is fit those notes into YOUR system: they arrive with the source app's titles, tags and folders, without a note type, and with no links to the rest of your vault.

An Obsidian forum thread from April 2025 shows what that looks like. After importing an Evernote notebook, the author found the graph view "basically unusable", got "too many search results from Evernote", and saw that every # before a word in an Evernote note had become a tag that "really clutters up my tag space". Most of that clutter came from web clippings.

So I recommend two steps: import everything into one folder first, then bring notes into your system one at a time, when you need them.

Import into a separate folder

Importer asks for an Output folder before it starts (Evernote imports default to Evernote). Keep every import in its own folder, and keep that folder out of your everyday results: add it to Excluded files, or add -path:Evernote to the searches you save (see "Archive what's done" in part 3). The notes stay searchable when you go looking for them on purpose, and they stop drowning the rest.

Two more output settings matter for findability:

• Existing notes decides what happens when you import the same data again: Update, Skip or Create a copy. Create a copy is how you end up with two versions of every note.
• Save source ID, when an importer offers it, adds the source ID to each note's properties "so future imports can recognize moved or renamed notes". Turn it on if you plan to rename and move imported notes (you should), and might import again later.

Keep the original dates in properties

You'll often remember when you wrote something years ago, so don't lose the dates. Importer lets you edit the template it uses: select Edit above the preview. Templates have access to {{ctime}} and {{mtime}}, the creation and modification times from the source app, and {{importer}}, the importer's ID. Add lines like these to the properties of the generated template:

created: {{ctime | date:"YYYY-MM-DD"}}
updated: {{mtime | date:"YYYY-MM-DD"}}
imported_from: {{importer}}

Why bother? The Evernote importer puts the original dates on the files themselves, and file dates rarely survive syncs, migrations and restores (see "A minimum of metadata" in part 2). Properties travel with the note. Plus, imported_from lets you list every imported note with [imported_from:evernote], or filter them in a Base. Importer shows up to ten sample notes in the preview, so you can check the result before anything lands in your vault. And it remembers your edited template for the next import in the same format.

{{ctime}} is empty when the source doesn't provide a date, so check a few notes after the import.

Promote notes when you need them

You don't have to process every imported note. Jamie Todd Rubin had more than 12,000 notes in Evernote when he moved to Obsidian, and he chose not to migrate them all at once. His order: first the notes he used often (50 or fewer), then the ones he knew he wanted to keep in digital form, and everything else only when he needed it. In his words: "I'm getting what I use most frequently right away without migrating in a bunch of noise."

He copied notes by hand. With an import folder, you get the same effect with less typing: everything is in the vault, but a note only joins your system when you touch it. Promoting a note means running the capture-time checklist on it: a name you'd search for, a type, a couple of links, and a link from today's daily note. Then move it to the folder of its type. A note you never touch stays in the import folder, out of your way, and that's fine.

Clean up tags and titles

Imported tags mix with your own tag families, so clean them up early. Open the Tags view, sort by frequency, and decide which imported tags to keep. Merge those into your existing tags with Tag Wrangler (part 8); leave the rest inside the import folder, where they don't bother anyone.

A few things to know per app:

Titles need a look too. An Evernote note without a title is imported as Untitled, and web clips keep the page's title, which is rarely the words you'll search for. path:Evernote file:Untitled lists the first kind. Rename them when you promote them, not all at once.

Let an AI agent do the tedious part

Everything above is simple, but on 3,000 imported notes, it's also mind-numbing. That's exactly the kind of work an AI agent like Claude Code or Codex CLI, running inside your vault, does well. It can read every imported note, compare it with your conventions, and propose the fixes in bulk. You stay the one who decides what goes in.

What to ask it for, in roughly this order:

• Titles. A proposed name for every Untitled note and every web clip named after the page title, written with the words you'd search for (see "Name notes like you'll search for them" in part 2). The old title becomes an alias, so nothing you remember gets lost.
• Tags. The inline #tags from Evernote and friends, mapped to YOUR tag families, then moved to the tags property. Imported tags with no equivalent in your vault go on a list for you to decide on, instead of quietly joining your tag space.
• Note types. "This one is a meeting note, this one is a recipe, this one is a web clip." Once a note has a type, it gets that type's properties, folder and name.
• The minimum metadata. created and updated from the import template, a type, a couple of topic tags, and aliases for the acronyms the note uses.
• Links and maps. The notes each imported note should link to (people, projects, concepts that already exist in your vault), and the Map of Content it belongs in.
• Duplicates. Notes that exist twice (an earlier import, the "Create a copy" setting, or a note you had already rewritten by hand).

A few rules keep this safe:

1. Commit first, and work on a branch. git switch -c import-cleanup before the agent touches anything. If the result is bad, you throw the branch away. (Part 7 covers Git in more detail.)
2. Small batches. One notebook, or 50 notes at a time. A diff you can actually read is a diff you'll actually review.
3. Proposals before edits. Ask for a review table first, then let it apply only the rows you approved.
4. Review the diff. git diff --stat shows what changed, git diff shows how. Look at a few notes in Obsidian too: broken YAML is easy to miss in a diff.
5. Never let it delete. Duplicates go on a list. You merge them yourself, after looking at both notes.

In my Obsidian Starter Kit, a few skills cover the import-specific part of this (the ones for aliases, orphans, links, MoCs and tags are in part 10, under "Use AI to retrofit findability into old notes", so I won't repeat them here):

• osk-meta-vault-import reads an external vault (or any folder of Markdown notes), classifies every file by note type with a confidence level (high, medium or low), flags name collisions and missing required properties, and writes a migration plan. It never modifies the source. If you haven't imported yet, here's an even safer order: run the Importer into an empty, throwaway vault, and point the skill at that.
• osk-vault-note-retype gives a note its type: the right properties, tags, folder and name, with the links updated. It always shows a dry run first. Inside Obsidian, the OSK plugin's Retype the current note command does the same for one note, with a review screen before anything changes.
• osk-vault-validate-notes checks a note, a folder or the vault against the type definitions and only reports. osk-vault-fix-notes then backfills the missing required properties and mandatory tags (additive only, dry run first). The plugin's Validate notes in the current folder command is the in-app equivalent.
• osk-vault-audit --mode hygiene reports exact and near-duplicate titles. It's read-only. To fold a duplicate into the note you keep, osk-cli retype "<keeper>" --to <type> --merge "<duplicate>" --dry-run shows the plan; you run it without --dry-run once you agree. The details are in Obsidian Starter Kit - Tutorial - Retyping and repairing notes.

No kit? The same works with a plain prompt. Here's one you can copy and adapt:

You're working in my Obsidian vault. The folder "Evernote/Recipes" holds notes I just imported.
Do NOT modify or delete anything yet. For each note in that folder, propose:
1. A new title using the words I'd search for (keep the old title as an alias)
2. The note type, from this list: meeting, recipe, reference, idea
3. Tags: map each inline #tag to one of my existing tags (list the ones with no match)
4. Missing properties: created, updated, type
5. Up to 3 links to existing notes in my vault (check that each note exists)
6. Possible duplicates elsewhere in the vault
Work on the first 30 notes only. Output one Markdown table, one row per note.
I'll mark the rows to apply. Then apply ONLY those, and show me the git diff.

Watch out for two things. Agents tend to "improve" the body while they're at it: tell it explicitly that the body stays untouched, except for the inline tags you asked it to move. And imported notes can contain anything (old passwords, medical records, client data): check what you send before you point a cloud model at a whole notebook.

Count what arrived

Compare the number of notes per notebook in the source app with what landed in your vault: fd -e md . "Evernote/My notebook" | wc -l gives you the count for one folder. Locked notes and sections are skipped by design, and imports don't always bring everything: on the same forum thread, a new user reported that a notebook of 536 notes came in as fewer than 20. It's much easier to notice that on import day than a year later, when you search for a note that never made it.

FAQ

My vault is already a mess. Where do I start? Not with a full reorganization. Measure first: write 20 real queries and check how many your current tools find. Then fix what you actually search for: the names of the notes you open most, the notes your test missed, the note types, the tags. The 30-day plan above has one 15-minute task per day.

I imported my notes from Evernote, Notion or OneNote. How do I make them findable? Import into a separate folder and keep it out of your everyday searches. Edit Importer's template to keep the original dates in properties ({{ctime}}, {{mtime}}), clean up the imported tags with Tag Wrangler, and count the notes per notebook to catch anything that didn't arrive. Then promote notes into your system as you need them: rename, add a type, link them. Details in "Imported notes need a findability pass" above.

Conclusion

Thirty days, 15 minutes a day, and two scores to compare. That's the whole makeover. After day 30, keep the loop going: every failed search fixes one note, and imported notes join your system as you touch them.

Next in the series: Obsidian Search Mastered - Quick Switcher, Search Operators and Bases. Previous: Structure a Findable Obsidian Vault - Folders, Links, Dates and Daily Notes.

Prefer to read the whole series in one place? I turned it into an ebook, The Obsidian Search Handbook, with an exercise at the end of every chapter (the Complete edition adds a starter pack and worksheets).

Free cheat sheet. The commands and operators worth remembering, and the search escalation ladder (which tool to try first, depending on what you remember about the note), on 13 pages you can keep next to your vault. Enter your email and I'll send it right away: the Obsidian Search Cheat Sheet.

Free Obsidian Search Cheat Sheet: operators and the search escalation ladder

A free 13-page PDF with the Obsidian search operators worth remembering and the search escalation ladder: which tool to try first, depending on what you remember about the note.

Sébastien DuboisSebastien Dubois

About Sébastien

Ready to get to the next level?