Should you use blocks or pages in LogSeq?

LogSeq users deciding between pages and blocks should default to pages for anything that will grow over time—topics, references, and “things” worth revisiting—because pages are faster to find, easier to navigate, and form the backbone of LogSeq’s knowledge graph. Blocks still matter, but they’re best reserved for the connective tissue: notes, metadata, and journal entries that point back to those pages.

Pages in LogSeq are top-level blocks stored in their own file. That structure gives them practical advantages. They’re easier to search and add while typing, largely because there are fewer pages than blocks. They also tend to appear quicker in search results. Pages can include multiple top-level blocks in a single page, with the first block commonly used to hold page properties. For quick access, pages can be marked as favorites. Most importantly, the knowledge graph is built from pages, so the network of relationships LogSeq can visualize and traverse is fundamentally page-centered.

Blocks, by contrast, are the “lines of text” that can nest into sub-blocks. They’re ideal when the goal is to keep writing without breaking flow. Adding information to a block is frictionless: link to a page, add details, and return without needing extra navigation steps. The workflow difference becomes especially noticeable when capturing time-sensitive or high-volume notes—like a daily journal—where constant context switching would slow down capture.

In one personal system, the split is intentionally fuzzy but follows a consistent rule of thumb. Anything expected to accumulate and expand becomes a page: projects, people, books, movies, and software applications. Blocks then serve as references to those pages. That shows up strongly in the journal. When a gift is relevant to a person, a block tagged “gift” gets linked to that person’s page, enabling later retrieval by opening the person’s page and filtering on the gift tag. Meeting notes work the same way: a block created during the day includes tags such as “meeting,” plus metadata like the relevant project and attendees, and links back to the relevant pages. The same pattern applies to emails or chat messages saved to the journal with appropriate tags.

The payoff is a project page that acts like a timeline: opening a project page typically surfaces a clear sequence of related activities, because blocks in the journal link back to the project page. Over time, this builds a database of small notes—articles saved for later, quotes extracted from books, observations captured in context—each linking back to a stable page.

When deciding whether to start with a page or a block, the guidance is pragmatic: pick a page by default because it can always be merged with other pages later, and blocks can be redirected to new pages if needed. If a page has no references yet, it may be worth reconsidering whether it should have stayed a block—but changing structure later can be harder than choosing the safer option upfront. The overall strategy is simple: pages anchor the system; blocks feed it with structured, linkable detail.