How to use queries and indentation in Logseq (with examples)

Logseq queries become genuinely powerful once indentation is treated as structure: parent blocks define inherited links, child blocks automatically carry those links, and queries then retrieve exactly the blocks that match the inherited page references. The practical payoff is faster, more reliable retrieval than manual filtering—especially when journal entries are nested and scattered across time.

Indentation in Logseq isn’t just formatting. Blocks form a hierarchy where a parent block holds context and child blocks nest under it. Using Tab and Shift+Tab to indent or unindent turns a block into a child of the block above, which means the child inherits backlinks/page links from its parent. This inheritance enables quick collapsing of sections like an outline—chapters under a book, paragraphs under a chapter—while keeping the underlying linked data consistent. The video also distinguishes sibling blocks: blocks at the same indentation level under the same parent don’t inherit each other’s context, which matters when linking and later when queries combine conditions.

Linking is the foundation for queries. Backlinks and hashtags both create links to pages, and the choice is largely personal preference. For multi-word page targets, square brackets (or backlinks) are needed; hashtags work for single-word page names. In practice, the core pattern is: create page links on blocks (either via hashtags or square brackets), then query those page-linked relationships.

To run a query, the forward-slash command “/query” opens the query builder, which uses curly-brace syntax: {query ...}. The simplest form returns all blocks linked to a given page name. Blocks can link directly (a block has the page link itself) or indirectly through inheritance (a child block inherits the page link from its parent). That inheritance is what makes nested journal writing usable for later retrieval.

Queries also support boolean logic, letting users treat sets of blocks like Venn diagrams. Using AND returns blocks that have both page links (e.g., {query [a] [b]} yields the overlap). Using OR returns blocks linked to either page (e.g., {query [a] or [b]} yields the union). A NOT operator enables exclusion, such as “AND a and b but not c,” implemented by nesting {query [a] [b] not [c]}-style logic.

Beyond page links, the query system extends to block types like to-dos and to properties. Properties use a similar bracketed syntax: {query property <name> <value>}, returning pages whose defined property matches. The transcript highlights a “type: books” example, where querying property type=books returns specific book pages. For habit-tracking or quantified-self use cases, properties like wake up and bedtime can be queried to produce a history of values; the results can even be arranged into a markdown table.

Finally, queries are positioned as more than search filters: they provide targeted retrieval that respects parent-block inheritance and can be saved as permanent query pages for quick reuse. The overall message is that indentation plus correct linking turns Logseq into an outline-driven database—one where structured writing and precise querying reinforce each other rather than fighting for attention.