Blog

Structure a Findable Obsidian Vault - Folders, Links, Dates and Daily Notes

Sebastien Dubois

27 Oct 2026 — 30 min read

📚 Part of a series The Complete Guide to Obsidian Search 3 parts

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

You often remember roughly when something happened, with whom, or what it was related to, long after you've forgotten what you called the note. Good names get you most of the way. The rest depends on where a note lives, what links to it, and how it connects to time.

The previous part was about single notes: names, aliases, types, properties and tags. This part moves to the vault as a whole: where notes live, what happens to them when they're done, how they link to each other and to time, how web clips arrive, and what to check when you capture something new.

Here's what you'll get:

Why topic folders fail, and how to file notes by type instead (PARA at the top, Johnny.Decimal for the numbers)
How archiving what's done makes every search result list shorter
How to make your vault the one place to look first, even for files that live elsewhere
When and how to link, and how Maps of Content help you find notes you can't name
ISO dates in names and folders, and daily notes as a timeline that links everything you capture
Web Clipper templates that name, type and tag your clips for you
A capture-time checklist you can copy

TL;DR

File by type, not by topic. A few folders, one per note type, never deeper than 3 or 4 levels. A note has only one folder but can have many tags and links, so topics go there.
Archive what's done. Finished tasks and closed projects compete with your active notes in every result list. Moving them out lightens the search space.
Make the vault the one place to look first. Bring in what you'll process, and write a small pointer note for what has to stay outside.
Link to people, projects and sources, and gather topics in Maps of Content. Then you can reach a note you can't name from one you can.
Link everything to time. ISO dates in names and a daily note that links every note you create turn "roughly when" into a few clicks.
Clip with templates, so web pages arrive with a useful name, a type and tags instead of piling up in a Clippings folder.

Folders: few, and by type

From my course: "Folders are a disease of the past. Yes they are useful. But no, they're not mandatory." And: "Your structure should be no deeper than 3 or 4 levels."

My recommendation is to organize folders by what a note is (its type), not by what it's about (its topic). A contact note goes in the contacts folder, period. You don't have to decide which topic or sub-topic it belongs to, which is exactly where topic folders break down: notes don't fit in a single box. I explain this in Folders as Silos.

Steph Ango, Obsidian's CEO, goes even further: he keeps almost everything in the vault root and organizes through properties and Bases.

The research gives folders some credit, though. Navigation through folders is cheaper cognitively than search, and seeing a note's neighbours reminds you of things (Barreau and Nardi called this "finding and reminding" back in 1995). So keep a few stable buckets, organized by type or actionability (PARA does this well), and put the rich cues in titles, properties and links.

So no, **I'm not anti-folders. I'm anti-topic-folders**.

Why topic folders fail

In Folders as Silos, I list four problems with folders organized by topic:

Exclusive categorization. A note about using psychology in marketing has to go in /Psychology/ OR /Marketing/. Whichever you pick, half of its context is gone.
An evolution barrier. Your interests change. The categories that make sense today won't in five years, and you either leave notes in obsolete places or reorganize forever.
No collisions. Ideas from different domains rarely meet when each one stays in its box.
Retrieval dependence. You can only find a note by browsing if you remember which category you chose. Filed under "marketing", searched under "psychology"? You'll never find it by browsing.

One note type, one folder

Type folders don't have these problems. An article is always an article; it doesn't become something else when your interests change. The decision takes zero thought, and it never needs revisiting.

When each note type maps to exactly one folder, folders also become a reliable filter. In my vault, every note type has an associated folder:

contacts go in a contacts folder under 36 People
meeting notes go in 37 Meeting notes, in a sub-folder per year
tasks go in 24 Tasks, in sub-folders per year and month
daily notes go in 41 Daily Notes, in sub-folders per ISO year and week number
permanent notes, literature notes, MoCs and so on each have their own
...

Because the mapping is strict, three things become trustworthy:

path: in Search. path:"37 Meeting notes" returns meeting notes, and only meeting notes. Combine it with anything: path:"37 Meeting notes/2025" pricing finds the 2025 meeting where pricing came up.
Browsing in the file explorer (or Notebook Navigator). When you know the kind of note you want, you know which folder to open. You see its neighbours, which helps with Barreau and Nardi's "reminding".
Bases filters. file.inFolder("30 Areas/37 Meeting notes") gives you a reliable list of meeting notes, and you can group or sort it however you like.

Folders and type tags are redundant on purpose. Tags survive a note being moved to the wrong place; folders work in tools that know nothing about tags (your OS file manager, rg, a cloud drive, an AI agent listing files).

To make this sustainable, don't file by hand. In the course, I show how I used the Auto Note Mover plugin to move notes to the right folder based on their type tag. Today, the Obsidian Starter Kit does it: each note type knows its folder (including date placeholders like {{year}} and {{month}}), and new notes go straight there. Filing takes zero seconds, which is the "F" in FILE. I compared the options in my article on moving notes automatically.

PARA at the top, Johnny.Decimal for the numbers

For the top level, I use the PARA method by Tiago Forte: Projects, Areas, Resources, Archives. It's dead simple, and as I say in the course, it "works across tools and platforms". My top-level folders look like this:

10 Meta
20 Actions
30 Areas
40 Journal
50 Resources
60 Archives

(I added Meta for things like goals, routines and processes, Actions for goals/projects/tasks/activities etc, and Journal for periodic notes.)

The numbers come from the Johnny Decimal system: at most 10 areas, each with at most 10 categories, every one with a two-digit number. Inside 30 Areas, you'll find 31 Fleeting notes, 32 Literature notes, 33 Permanent notes, 34 Maps, 36 People, 37 Meeting notes and so on. One level deeper, IDs like 33.02 identify a specific category (33.02 Content holds my permanent notes about concepts). I'm not religious about the numbering rules of the Johnny Decimal system, but I try to keep it all sane.

Why bother with numbers? Because they give you a stable mental model:

The order never changes. Without numbers, folders sort alphabetically, so Areas lands before Journal and after Archives, and adding a folder reshuffles everything. With numbers, the order is the one you chose. In the course: I combine the two "to ensure that folders are always neatly organized, and always appear in the same order, independently of the tool that you use to explore your content."
The same structure works everywhere. I use the same layout in Obsidian, in my file manager, in the terminal and in cloud drives. Learn it once, find things everywhere.
You stop reading and start recognizing. From my Johnny Decimal note: "Once you recognize the numbers, you don't even need to read the names anymore." 37 means meeting notes. Your eyes go straight there.
Things stay shallow. The limits (10 areas, 10 categories) force you to keep the structure flat. In my Johnny Decimal article, I put it this way: everything gets a unique ID, and "nothing is more than two clicks away".

The numbers also make search more precise. path:33.02 or path:"37 Meeting notes" can't accidentally match a note whose name happens to contain "Meeting notes".

If you're starting out, don't over-engineer this. As I say in the course, you could "just choose a single folder and put everything in it, and it can work fine actually, if you have the right metadata in place". Start with a few type folders, let friction tell you when you need another one, and never go deeper than 3 or 4 levels. I wrote about both methods in my PARA article and in the Johnny Decimal article linked above.

Give every structure a findability budget

Every folder, tag family, property, Map of Content and plugin you add has a cost. You pay it when you file a note (one more decision), when you maintain the system (one more thing to keep consistent), and when you search (one more thing to remember). In Challenges with folders and tags, I list the three ways that cost shows up: consistency (applying the same metadata everywhere), manageability (updating it everywhere) and usability (finding data quickly). A structure that doesn't make retrieval faster is pure cost.

That's why I think of structure as a budget. Before you add something, it has to "pay" for itself in faster finding.

[!tip] The findability budget Before you add a folder, a tag family, a property, a MoC or a plugin, answer four questions: 1. Which search does it make faster? Name one real search you've had. If you can't, don't add it yet. 2. Will I remember it when I search? A category you won't recall later is the recall problem Lansdale described in 1988 (see part 2). 3. Who maintains it? A template, a plugin or a Base: fine. Your willpower: it will drift. 4. What happens if I stop maintaining it? If the answer is "my searches start missing notes", keep it small. If a structure fails two of these, skip it. You can always add it later, when friction shows you need it.

As I wrote in It's a Tool, Not a Goal: "Don't try to solve problems you don't have yet. Wait until you actually experience friction before adding complexity." In my article about common PKM mistakes, I give the warning sign for the opposite: "You've spent more time this month reorganizing your system than using it."

Folders are where the budget runs out first, because each extra level adds a filing decision to every note. See Avoid complex folder structures and If you become serious about note-taking, forget about folders. Type folders pass the test: the decision takes zero thought, and path: and Bases filters get more precise. Topic folders usually fail it.

Researchers reached the same conclusion as PARA

In The Science of Managing Our Digital Stuff (2016), Bergman and Whittaker point out that personal information is different from public information, because the same person organizes and retrieves it. Search, tags and grouping methods that work for public information don't work as well for personal information. They propose what they call the user-subjective approach, with three principles:

User-subjective principle	What it means	The PKM equivalent
Subjective project classification	Keep everything about a project together, whatever its format	PARA's Projects, and project notes as hubs (part 8)
Subjective importance	Make important items more visible, and demote the rest	Progressive summarization, archiving what's done (next section), pins and ratings
Subjective context	Retrieve items in the context where you last used them, and capture that context	The daily-note timeline, links to people and projects

Tiago Forte himself framed progressive summarization as a findability technique: his original essay was titled "Progressive Summarization: A Practical Technique for Designing Discoverable Notes".

None of the three principles is about topics.

Archive what's done

Folders by type have one more benefit: they make archiving clean. And archiving is an underrated findability tool, because it lightens the search space. Finished tasks, closed projects and old goals are rarely what you're looking for, yet they compete with your active notes in every quick switcher list, every Search result, every Base and in the graph. Move them out of the way, and the notes that matter rank higher everywhere.

Archive in a way that keeps things findable. In my vault, the archive mirrors the live structure: a task archived from 20 Actions/24 Tasks lands in 60 Archives/20 Actions/24 Tasks/<year>/<month>. A project lands in 60 Archives/20 Actions/23 Projects/<year>. Goals go to 60 Archives/20 Actions/21 Goals/<year>. Same names, same numbers, just under 60 Archives. If you know where a note lived, you know where its archive lives. The year and month folders then let you find old work by when it ended.

I don't archive by hand either. The Obsidian Starter Kit has archive rules per note type: when a note enters a given status, it waits a grace period, then moves the note to the type's archive folder. For my tasks, it's "7 days after 80 - Done". The grace period keeps recently finished work in sight for a few days (handy during a weekly review), and if I move a note out of the done state before the delay is over, the pending archive is cancelled. Links are updated by Obsidian, so nothing breaks.

Then you have a choice to make: should the archive be searchable or not?

Exclude it. Add 60 Archives to Settings → Files and links → Excluded files. Excluded files are hidden from Search results, the graph and unlinked mentions, and they're ranked lower in the quick switcher and the link suggester. Your everyday searches become cleaner. The downside: when you DO need something from the archive, core Search won't show it, and you have to remember that.
Keep it searchable, but scope your searches. Leave the archive in, and add -path:"60 Archives" to the searches where it gets in the way (for example tag:#obsidian -path:"60 Archives"). Bookmark those searches so you don't retype them. In Bases, add a !file.path.contains("60 Archives") filter. Nothing is hidden, but you control the noise.

In my own vault, 60 Archives/ is in Excluded files (next to my templates and prompts folders), so it stays out of my way. The price is that core Search no longer finds anything in there, so when I do need something archived, I go through the file explorer, the quick switcher (excluded notes are only ranked lower) or the terminal. If you dig in your archive often, keep it searchable and scope your searches instead. Either way, remember that rg, git and your AI tools don't care about Obsidian's Excluded files setting (we'll come back to that).

One place to look first

Archiving shrinks the search space inside your vault. The bigger leak is everything outside it. Notes in three apps, PDFs in Google Drive, contracts in Dropbox, ideas in a voice memo app, highlights in Readwise, pages of handwriting on a tablet: every extra place is one more place you have to remember to search. And when you forget to look there, the information is as good as lost.

The fix I use is a single source of truth. Here's how I define it: "A single source of truth is where you can go to either find all the information or to find where what you are looking for is located." Read the second half again. Your vault doesn't have to hold everything. It has to know where everything is.

In practice:

Pick one home per type of information. Notes and ideas go in the vault. My family pictures all end up on my NAS. Shared documents live in the drive your team uses. Bookmarks in one tool, highlights in one tool. Once the home is decided, you never wonder where to start looking.
Bring in what you'll process. Text you'll search, link and reuse belongs in Markdown, inside the vault. That's what the clipping, transcription and capture workflows in this series are for.
Point to what has to stay outside. A large video, a contract your accountant also needs, a file in a shared drive: create a small note in the vault that describes it and links to it. Search finds the note, and the note takes you to the file. Part 7 shows how ("Find what lives outside your vault").
Keep an index of what lives where. In my note on the topic, I recommend to "Create and maintain an index of what is where for each type of data (i.e., create a single source of truth about your single sources of truth!)". One note in your vault does the job, and it's the first place to check when you can't remember which tool holds something.

This is what lets you document to forget, not to remember. Once you trust that everything is either in the vault or pointed to from it, you can stop carrying the map in your head. I explain the reasoning in this article about single sources of truth.

Links and Maps of Content

Links are how you navigate from a note you know to the one you need. My rule from the course: "If you think 'if I re-read this, then this other note might also be useful at that point', then it's a good enough reason to link those together. It's not about purity or perfection. It's about creating pathways between ideas." When in doubt, add a link. Links aren't the only option, though: I list the others in Ways to connect ideas in a PKM system.

My templates end every note with a References section (external sources) and a Related section (links to other notes). It takes seconds, and it weaves every new note into the graph.

When a topic grows, I create a Map of Content (MoC): a note that links to the notes about a topic. I like this analogy: "If links and backlinks are like roads, tags are like road signs, folders are like houses and MoCs are maps." They're complementary. Nick Milo recommends creating a MoC when you hit a "Mental Squeeze Point", the moment a pile of notes gets messy enough to overwhelm you. Not before.

Niklas Luhmann's Zettelkasten worked the same way: his keyword index was sparse, with one or two entry points per keyword. The links did the rest.

Why links help you find things

Links give you a way to find a note without remembering anything about it, as long as you remember something related. In the course, I describe it like this: "Instead of having to find a specific note, you can just go into the ballpark and find the related notes that you know you have linked to the one that you're after." That's Teevan's orienteering from the overview of this series: small steps from something you know. Every link is also a backlink, so the note you link TO now points back at the note you're writing. One link, two new paths.

When and how to link

When I write a note, I ask a few questions (they come from the course):

What does this remind me of?
What is this similar to?
How is this different from that other idea? (The pattern and the anti-pattern, the micro and the macro view.)
Why is this important? Is there a broader or a more specific note?
What does this relate to?

Each "yes, I have a note about that" is a link. Then, a few habits make those links more useful:

Prefer inline links, like on Wikipedia, inside your sentences. Use aliases so the sentence still reads well out loud.
Don't link everything. Link the ideas that add meaning, not every term you could explain. A sentence full of links is as useless as none.
Avoid generic link text like "see also" or "here". The link text should tell you where it goes.
Use the References and Related sections for links that don't fit in the text.
Link to people, projects and sources. Those are the cues you'll remember later. A meeting note that links to the person and the project will show up in both of their backlinks.

And let tools help. The "Unlinked mentions" section of the backlinks pane shows notes that mention a note's name (or alias) without linking to it, with a button to turn each mention into a link. AI tools are also good at suggesting links, because they work with meaning rather than exact words. We'll come back to both later.

Maps of Content

A Map of Content (MoC) is a note whose job is to link to other notes about a topic, a question or an area of interest. A table of contents for part of your vault. A note can only live in one folder, but many MoCs can link to the same note, which makes them "folders on steroids", as I wrote in my MoC note.

For findability, a MoC gives you an entry point into a topic when you don't know where to start. It gathers notes across folders and types, so a single map can link permanent notes, literature notes, articles and projects about the same topic. And it can add context: a sentence next to each link that explains why it's there turns a list into a map.

How I create one:

Pick a topic you have several notes about (broad like "Productivity", or narrow like "Morning routines").
Gather the related notes: search, tags, backlinks of a central note.
Group them by subtopic under headings.
Add a line of context next to the important links.
Revisit it as you add notes on the topic.

When should you create one? Not on day one. Signs it's time: you have 50+ notes and browsing feels overwhelming, topics overlap and a note could belong to three folders, you keep rediscovering notes you forgot existed, or you can't find things you know you wrote down. That's Nick Milo's squeeze point.

Common mistakes I've seen (and made): creating MoCs for every possible topic, treating them as rigid taxonomies, dumping 50 links without any context (a glorified search result), and never updating them. That last one is the big one. In the course, I say it clearly: "Note that I don't maintain such lists manually. I leverage metadata and tags on my notes." In my vault, MoCs are a note type with their own tag (type/map/moc, 189 notes) and folder, and many of them are generated by queries. I show how in part 8 ("Maps of Content that maintain themselves").

You can also go one step further and create a MoC of MoCs: a single note listing all your maps, so you always have a top-level entry point. In my vault, a "Maps" Base does that job: it lists every MoC and every Base file. I wrote a full article about Maps of Content if you want to go deeper.

Maps of Content as foraging patches

Peter Pirolli and Stuart Card's information foraging theory (published in Psychological Review in 1999, first presented at CHI in 1995) describes people looking for information the way biologists describe animals looking for food: they weigh what they'll gain against the effort it costs. Three of its concepts map directly to a vault:

Information scent: the cues that tell you whether a path leads to what you want. In a vault, that's titles, link text, aliases and search snippets. It's the term I used in the naming section of part 2.
Patches: clusters of information where you stay for a while before moving on. A Map of Content is a patch you build on purpose: the notes about a topic in one place. Folders, tag pages and a Base filtered on a type work as patches too.
Diet: deciding which items are worth pursuing at all. Claim-style titles help here, because you can judge a note without opening it.

Dates in names and folders: make time lookups trivial

You'll often remember roughly when something happened before you remember anything else about it: "it was in March last year", "the week before that conference". So I make time a first-class cue, in three places.

In names. Every chronological note has an ISO date in its name:

Note type	Name pattern	Example
Daily notes	`YYYY-MM-DD`	`2025-03-04`
Weekly notes	`YYYY-Www`	`2025-W10`
Monthly notes	`YYYY-MM`	`2025-03`
Meeting notes	`YYYY-MM-DD - Topic`	`2025-01-21 - Work session`

In folders. Notes that pile up over time get date sub-folders, generated automatically from placeholders in the note type's folder setting. Daily notes live in 41 Daily Notes/<ISO year>/<week> (e.g., 41 Daily Notes/2025/10/2025-03-04.md). Weekly notes are grouped per ISO year. Meeting notes go in a folder per year. Tasks go in 24 Tasks/<year>/<month>. No folder ever grows to thousands of files, and the path itself tells you when.

In properties. created and updated (kept reliable by the Update Time plugin) cover notes without a date in their name.

Here's what that buys you. Say you're looking for a meeting from March 2025, and you don't remember who was in it or what it was called:

Quick switcher: type 2025-03. You get every daily note and every meeting note from that month, because the date is in the name. Add a word you remember (2025-03 coaching) to narrow it down.
Search: path:"37 Meeting notes/2025" file:2025-03 lists the meeting notes from March 2025 and nothing else. Or tag:#type/meeting file:2025-03 if you prefer tags.
Bases: filter on file.inFolder("30 Areas/37 Meeting notes") and file.name.startsWith("2025-03"), or on the date properties, and sort by date. (Part 5 covers Bases filters in depth.)
The daily note of that day: once you have a date, open its daily note and follow the links (see the next section).
The periodic notes view: my Journal Bases plugin adds a Periodic Review view to Bases where you drill down from a year to a quarter, a month, a week and its daily notes.

Easy peasy. None of this needs a plugin or AI: just a naming convention that you apply consistently (or better, that a template applies for you).

Daily notes as a timeline

You often remember roughly when something happened, and with whom. Daily notes turn that memory into a path. If your daily note links to every note you created or touched that day, then "it was the week of that conference" becomes a few clicks.

In my vault, every new note gets linked from the Discoveries section of that day's daily note. So the daily note of any day lists what I created on that day, and the link is one click away. I wrote about this in why you should link knowledge to time and how I use daily notes.

Link everything to time

If everything you capture is connected to a date, then narrowing down WHEN something happened is enough to find it back. In my article about knowledge and time, I explain that you don't need to keep everything in your head: "most of the time, all you need to keep in your head are cues towards the information you need (i.e., I know how and where I can find what I need)". Time is one of the strongest of those cues. You might not remember a note's title, its tags or its exact words, but you'll often remember that it was "last spring", "during that project" or "around the time I read that book".

That's why I write it down systematically: "Whenever I take or make notes, I keep track of when I learned and captured new information." (The short version: Why you should link your notes with time.) Two mechanisms make that happen: the daily note as the entry point for everything, and periodic reviews that bubble things up.

The daily note is where everything lands first

My daily note is my knowledge inbox. Its sections are generated by my template, and two of them matter for findability:

Notes: interstitial journaling, i.e., what happened, thoughts and observations as the day runs, one line each.
Discoveries: what I learned, plus one link per line to every note created or updated that day.

So everything I capture during a day ends up in that day's note, either inline (a raw idea, a quote, a link) or as a link to the note where it now lives. As I describe in Knowledge rollover through Periodic Reviews, the knowledge is then "connected to time (i.e., if you go back to that day's notes, you will find the information back)". My AI assistant follows the same rule: whenever it creates or updates a note in my vault, it adds the link to today's daily note. The habit no longer depends on my discipline. I explain why the daily note makes such a good entry point in why daily notes should be your capture system.

The link works in both directions:

From a date to the notes. Open the daily note of a given day (type the date in the quick switcher), and its links show what you created or captured that day.
From a note to its date. Open any note and look at its backlinks: you'll see the daily note that links to it. That tells you when it entered your system, and the daily note shows what else you were doing at the time: the meeting, the book, the project. That context is often exactly the cue you were missing.

Knowledge ingestion: from raw captures to findable notes

Raw captures in a daily note are findable by date, but they're not great notes. As I say in the course, at that stage "they're not connected, and they're not reusable". The Knowledge Ingestion Process fixes that. I run it during my weekly review, while the content is still fresh. For each daily note of the past week:

Clean up: remove what I don't need anymore and merge duplicates (I often capture the same idea on different days).
Extract: split complex ideas into atomic notes, and give each one a clear name. From the course: "the goal is to have a name that really clearly identifies what is in the note. Because that will make it much easier to find this note back later on."
Replace: swap the raw text in the daily note with a link to the new note. The daily note keeps its timeline, and the idea now has a proper home.
Enrich: add metadata, tags and links to the new notes, and update the relevant Maps of Content.
Roll up: add what matters to the weekly note.

Notice how this connects everything in this part and in the previous one. Ingestion is the moment where captures get the names, tags, links and dates that make them findable. Capture stays fast (a bullet point in a daily note), and the findability work happens in a batch, once a week. I describe the whole path in the knowledge funnel.

Periodic reviews bubble things up

The weekly note is not the end. My Periodic reviews continue the rollover: daily notes roll up into weekly notes, weekly notes into monthly notes, then quarterly and yearly notes. At each level, I keep less and less: the highlights, the achievements, the important discoveries, the decisions, the books I finished. In the course, I put it this way: "you get to see at one glance, everything that you have learned or the challenges that you faced, or the things that you have done in a specific period of time."

For findability, this gives you a zoomable timeline. Take my yearly note for 2025 (a private note, so no link here). It has sections for highlights, achievements, discoveries and challenges, a "Finished reading" table (a serialized query listing the books I finished that year), and a "Notes created this year" table: a serialized query that lists every note created in 2025 (outside my journal and resources folders) with its creation date. A single page gives me an overview of the whole year, and every line links down to the details.

So when I'm looking for something and I only know roughly when, the flow goes like this:

Roughly when? "Sometime in 2025." Open the yearly note 2025 from the quick switcher. Scan the highlights and discoveries, or search the "Notes created this year" table with Ctrl/Cmd+F.
Narrow it down. "It was in spring." Open the quarterly or monthly note (2025-03). It lists what bubbled up that month.
Find the week. The monthly note links to the weekly notes (2025-W10), and each weekly note links to its daily notes.
Open the day. The daily note's Discoveries section links to every note created or updated that day.
Follow the link to the note you were after.

Each step is a click or a few keystrokes, and none of them requires remembering a single word of the note. If you don't want to click through the hierarchy, my Journal Bases plugin has a Periodic Review view that shows it as columns: select a year, then a quarter, a month, a week, and you see its daily notes.

All of this works in any tool, because the names follow one scheme: yyyy-MM-dd for daily notes, yyyy-Www for weekly notes, yyyy-MM for monthly notes, yyyy for yearly notes (see Naming Scheme for Periodic Review Notes). I wrote more about the review side in this article about periodic reviews.

As I once put it: PKM enables having conversations with yourself through time. And that's powerful. Linking notes to time is what lets you find the other side of that conversation.

Getting started and gotchas

Getting started. Enable the Daily notes core plugin, set a folder and a date format (YYYY-MM-DD), assign a hotkey to "Open today's daily note", and add a section for links to what you create. Add a weekly note when you start doing weekly reviews. The monthly, quarterly and yearly levels can come later. As I write in my periodic reviews note: "You don't have to perform all of those. You can start simple and expand from there if you feel like it."

Gotchas.

The timeline is only as complete as your habit. If you link half of your new notes, the daily note shows half of your day. Automate it if you can: a template snippet, a command, or an AI assistant that does it for you.
Skipped reviews leave gaps. If you skip the weekly review for a month, the raw captures stay raw, and the higher levels of the timeline stay empty. Small regular batches work better than occasional marathons.
The daily-note link is not the file's creation date. It records when the note entered your thinking, even if the file was moved, synced or restored since. Keep created in properties as well, for queries like the "Notes created this year" table.

Clip web pages with findability built in

Web clips are one of the fastest ways to fill a vault with notes you can't find. Out of the box, the Obsidian Web Clipper names each note after the page title ({{title}}), saves everything to a Clippings folder, and adds the same handful of properties to every clip: title, source, author, published, created, description and a clippings tag. That's a fine start. But page titles are often SEO titles ("10 Tips for Better Notes | Some Blog"), every clip gets the same tag whatever it is, and a hundred clips later they all look alike in the quick switcher.

The fix is to treat a clip like any other note type: it deserves a name you'd search for, a type, a folder and properties. Web Clipper templates give you all four, and you set them up once.

One template per kind of page

A template defines the note name, the location, the properties and the content. Variables work in all four places, so the name and the folder can come from the page itself. Triggers pick the template for you:

URL prefix: https://www.reddit.com/r/ matches every subreddit page.
Regular expression, between slashes, for finer patterns.
Schema.org data: schema:@Recipe matches any page that declares itself a recipe, whatever the site.

The first matching template in your list wins, and pages that match nothing get the first template in the list. So put your general-purpose "article" template at the top as the fallback, and drag the specific ones in the order you want them tested.

Example: my Reddit template

Here are the settings that matter for findability in the template I use to clip Reddit threads (the content part is left out):

Triggers:    https://www.reddit.com/r/
             https://reddit.com/r/
Note name:   Reddit - {{selector:shreddit-post?post-title|safe_name|slice:0,120}}
Location:    30 Areas/32 Literature notes/32.08 Curated/Reddit
Properties:
  title        {{selector:shreddit-post?post-title}}
  source_url   {{url|split:"?"|first}}
  source_type  reddit
  subreddit    {{selector:shreddit-post?subreddit-prefixed-name}}
  published    {{selector:shreddit-post?created-timestamp|date:"YYYY-MM-DD"}}
  description  {{selector:shreddit-post div[slot="text-body"]|strip_md|slice:0,200|trim}}
  tags         type/curated (plus my zone tags)

What each line does:

The Reddit - prefix works like the type suffixes from part 2: typing reddit in the quick switcher lists every thread I clipped, and adding one word from the topic narrows it down.
safe_name strips the characters that break links and sync (see "Avoid characters that break links and sync"), and slice:0,120 keeps the names short.
source_url without the query string. The same page often reaches you with tracking parameters (?utm_source=..., ?share_id=...). The default template stores the full URL, so [source:"<url>"] misses a page you already clipped from a different link. Cut everything after ?, and the same thread always gets the same value. My IMDb template goes one step further and drops the #fragment too: {{url|split:"?"|first|split:"#"|first}}.
published as a real date lets a Base sort clips by when they were written, and description gives the Search view and Bases a short excerpt to show.
The type tag and the folder file every Reddit clip with the rest of my curated content, so any Base filtered on that type lists it.

My media templates follow the same logic with schema triggers. The IMDb one triggers on schema:@Movie and names the note {{schema:@Movie:name|safe_name}} (Movie), which is exactly the name and suffix of the movie notes I create by hand. A clipped movie lands in the movies folder with the movie properties, and nothing tells it apart from the others. That's the goal: a clip should be indistinguishable from a note you made yourself.

Let the Interpreter fill the gaps

When the data you want isn't in a predictable place on the page, prompt variables like {{"three keywords describing this page"}} ask a Large Language Model (LLM) to extract it (see the Web clips bullet in part 9 for summaries and keyword properties). The official docs recommend avoiding them when another variable type can get the data: they're slower and can have cost and privacy implications depending on the model you use. Use them for topics or a summary; take titles, authors and dates from the page.

Gotchas

Order matters. The first match wins. A broad URL trigger above a specific one hides the specific one.
Schema triggers apply to any site. A schema:@Movie trigger also fires on any other site whose page declares a Movie. Site-specific properties (like an IMDb ID) just stay empty there.
Property types are global in the Clipper. A property name has one type across all your templates, so keep published a date everywhere.
Selectors break when sites change their markup. If a Reddit clip suddenly comes out empty, the shreddit-* selectors are the first thing I check. And the Clipper only captures what's rendered: expand collapsed replies before clipping.
Images stay remote. Clipped images link to their web URL. The Download attachments for current file command brings them into the vault.

Getting started. Import a few templates from the community (Obsidian's docs point to the kepano/clipper-templates repository), then adapt the name pattern, the folder and the properties to your note types. My Obsidian Starter Kit includes pre-configured Web Clipper templates. I walk through the extension in more detail in my Web Clipper article.

Your capture-time checklist

When you create a note, check that it has:

A name you'd search for: keywords first, a claim for idea notes, an ISO date for chronological notes, the acronym in parentheses if there is one
A type: a type/... tag (and the matching folder), added by a template
Aliases for the other names you'll think of (abbreviations, translations, the name without its type suffix)
created and updated dates in properties, kept up to date automatically
A few topic tags, as many as feel useful
A couple of links: to a person, a project, a source or a related idea, and from a MoC when the topic has one
A link from today's daily note

And when a note is done (a finished task, a closed project), let it move to the archive. Most of this can be automated with templates and plugins, so the real cost is close to zero.

Conclusion

A findable vault doesn't need a clever structure. It needs a few folders by type, an archive, one place to look first, links to the people and projects you'll remember, and a daily note that ties everything to time. Pick one item from the checklist above, automate it with a template this week, and add the next one when it sticks.

Next in the series: Fix a Messy Obsidian Vault - The 30-Day Findability Makeover. Previous: Design Notes You Can Find - Names, Aliases, Types and Metadata in Obsidian.

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.

Get the free Obsidian Search Cheat Sheet. 13 pages to keep next to your vault: the search operators worth remembering and the search escalation ladder. Enter your email and I'll send it right away. You'll also get a few short follow-up emails about finding notes in Obsidian, and you can unsubscribe at any time.