Logseq Namespaces and Page Hierarchy

Organizing knowledge effectively is the core challenge of any personal knowledge management (PKM) system. In Logseq, you have the powerful freedom of a flat page system, where every note exists independently without enforced folders. But how do you create order when you need it? That’s where namespaces come in. This feature allows you to create clear, navigable hierarchies—like Projects/Writing/Blog—while preserving the flexible, connection-first philosophy that makes Logseq so powerful. Mastering namespaces bridges the gap between rigid folder structures and a messy, unsearchable graph, giving you the best of both organizational worlds.

Understanding Namespaces and the Flat Graph

Before diving into hierarchies, it’s crucial to grasp Logseq’s foundational model. Unlike traditional note-taking apps that store files in folders on your disk, Logseq operates on a flat page system. Every page you create is essentially a single node in a vast network, or graph. Connections are made through bidirectional links ([[Page Name]]), not by placing a page "inside" another. This model is incredibly flexible, allowing ideas to interlink in multiple, non-linear ways, much like how your brain associates concepts. Namespaces don’t change this underlying flat structure; instead, they add a layer of semantic organization on top of it. They use a simple syntax—the forward slash (/)—to imply parent-child relationships between pages, creating a navigable tree without sacrificing the power of the graph.

Creating Hierarchies with Forward Slashes

The mechanics of namespaces are elegantly simple. You create a hierarchical relationship by including forward slashes in a page title. For example, creating a page named [[Projects/Writing/Blog]] does three things automatically. First, it creates the target page "Blog." Second, it implicitly creates the parent pages "Projects" and "Writing" as namespace pages, if they don’t already exist. Third, it establishes "Blog" as a child of the "Writing" namespace, which itself is a child of the "Projects" namespace.

This syntax is the entire technical basis for the feature. You can link to any level of this hierarchy directly. You might reference [[Projects]] in a daily note for a high-level overview, or link specifically to [[Projects/Writing]] when discussing your writing initiatives. The system is intuitive: more slashes mean deeper nesting. A key advantage is that a page can belong to only one explicit namespace through its name, but it can still be linked from anywhere in your graph, maintaining the flat system's flexibility. For instance, your [[Projects/Writing/Blog]] page could also be linked from a [[Content Calendar]] page, creating a separate, useful connection.

Navigating with the Sidebar Hierarchy View

Once you create namespaced pages, Logseq provides a dedicated tool to navigate them: the hierarchy view in the right sidebar. This is where the implied tree structure becomes visually tangible and actionable. When you open a namespace page—like [[Projects]]—the hierarchy view in the sidebar will automatically display a collapsible tree of all its child pages and sub-namespaces.

This view is your fast-access directory. If you have Projects/Writing/Blog and Projects/Research/Paper, you can click the arrow next to "Projects" to expand it, then "Writing" to see "Blog," all without leaving your current page. It enables you to drill down into a category or get a bird’s-eye view of a project's structure instantly. This sidebar tool effectively transforms the flat graph into a familiar, folder-like explorer when you need it, without forcing that structure on every part of your knowledge base. It’s the perfect companion to the linking system, offering both associative and hierarchical paths to your information.

Using Namespace Pages as Overview Hubs

A namespace page, such as [[Projects/Writing]], is a fully functional page. This allows it to serve a powerful secondary role: an overview or dashboard for everything within that category. Instead of being just an empty placeholder, you can turn it into a purposeful hub.

On your [[Projects/Writing]] page, you could include:

• A brief description of your writing goals.
• A query that dynamically lists all child pages (like {{query [[Projects/Writing]]}}).
• Links to key resources, templates, or deadlines related to writing.
• Notes that apply to all writing projects.

This practice leverages the hierarchy you’ve built to create context. When you or someone else visits the [[Projects/Writing]] namespace, they aren't met with a blank page or just a list of links; they find a curated starting point that explains the scope and contents of that branch of your knowledge base. It makes your graph not only organized but also intelligible and purposeful.

Common Pitfalls

1. Over-Structuring from the Start: The biggest mistake is forcing a deep, complex folder-like hierarchy on every note immediately. This fights Logseq’s strength as a connected, fluid thinking tool. Correction: Start flat. Use namespaces organically as broad categories (Areas/, Projects/, People/) naturally emerge from your content. Let the structure grow to serve your needs, not dictate them.

1. Creating Empty or Redundant Namespaces: Creating a page like [[Projects/Writing/Blog/Ideas/Draft1]] will generate every namespace page in that chain, potentially cluttering your graph with empty, meaningless pages. Correction: Only use namespaces that represent meaningful categories. Consider if a simple tag like #blog or a direct link [[Blog Ideas Draft 1]] would be more appropriate for very specific or one-off notes.

1. Mixing Hierarchical and Flat Linking Inconsistently: You might link to [[Writing]] in one note and [[Projects/Writing]] in another, creating two separate, unlinked pages and fragmenting your information. Correction: Decide on a convention. If you create a namespaced page, always use its full path ([[Projects/Writing]]) when linking to it. Use the non-namespaced version only if it represents a truly distinct, top-level concept. The "Page References" section at the bottom of any page shows all linked references, helping you spot and merge these duplicates.

1. Ignoring the Power of Queries and Tags: Relying solely on namespace navigation can make finding cross-category information difficult. A note in Projects/Writing about a specific tool might be relevant to a note in Projects/Research. Correction: Supplement namespaces with tags (#tool, #meeting) and block references. Use queries to surface content based on multiple attributes, not just its location in the hierarchy. This preserves the network benefits of your PKM.

Summary

• Namespaces use forward slashes (e.g., [[Area/Project/Topic]]) to create implicit, navigable hierarchies within Logseq's fundamentally flat page system.
• The hierarchy view in the sidebar provides a tree-based explorer for your namespaced pages, offering folder-like navigation on demand without breaking the graph model.
• Namespace pages are fully functional and should be used as overview hubs or dashboards for their child content, adding context and utility to your structure.
• The system bridges outliner flexibility with structured organization, allowing you to link freely across your graph while maintaining clear categories for projects, areas, and topics.
• Avoid common pitfalls by letting structure emerge organically, using full namespace paths consistently, and supplementing hierarchies with tags and queries for true network-based thinking.