Navigation That
Maintains Itself
Point a menu item at a page folder once, and it tracks that folder from then on. No second tree to keep in step, no drafts leaking into your header, and no URLs moving underneath you.
Point at a folder instead of typing a URL
A menu item becomes folder-bound by carrying a source object. You pick the folder once. From then on the menu is generated from your live page tree, every time a visitor loads a page.
{
"items": [
{ "label": "Pricing", "url": "/pricing" },
{ "label": "Handbook",
"source": {
"kind": "folder",
"folder_id": "...",
"depth": 2
}
}
]
}Three kinds of item, in one menu
This is not a mode you switch a menu into. Each item is independently one of three kinds, and they sit side by side. Keep the destinations you want to control by hand, next to a section that keeps itself current.
Link
DefaultYou type the label and the URL. This is the original behaviour and it is still the default. Your existing menus did not change.
Folder
BoundThe item points at a page folder and shows that folder's pages, to a depth you choose between one and three.
Whole site
BoundThe same idea applied to your entire page tree, generated from your top-level folders and pages.
A draft page cannot reach your header
The convenience is obvious. The safety is the better half. A bound menu lists published pages only — and that is not a filter applied in the template. The query that walks your page tree cannot return a draft page in the first place.
Enforced in the query
SafetyExclusion happens where the tree is walked, not in a caller that could be forgotten. An unfinished page is not in the menu because it cannot be.
Nothing to remember
UpkeepUnpublish a page and the menu entry goes with it. With a bound item there is no stale link left pointing at something you took down.
One order, not two
Items appear in the order you dragged them into in Content → Pages. The menu order and the folder order are the same order, so there is no second sort to maintain and no way for the two to disagree. Reordering your pages is reordering your menu.
Folders get a landing page, and it heals
Once a folder can appear in a menu it needs somewhere to point. A folder is not a page and has no URL of its own, so it resolves a landing page — and pinning one does not become a thing you have to look after.
First page by position
DefaultThe folder points at whichever published page currently sits first inside it. Drag a different page to the top and the folder follows. This needs no configuration at all.
Choose a page
OptionalPin a written overview as the entry point. Delete or unpublish it later and the folder quietly returns to first-by-position, because the rule is re-checked when the menu is read rather than stored as a fixed pointer.
A folder knows what is inside it
When a page is its folder's landing page it receives the folder's contents, so you can build a real index — cards, a list, a directory — instead of writing the links out by hand and updating them forever.
<!-- folder is present only on a folder's landing page -->
{% if folder %}
<h2>{{ folder.title }}</h2>
{% for child in folder.children %}
<a href="{{ child.url }}">
<h3>{{ child.title }}</h3>
<p>{{ child.seo_description }}</p>
</a>
{% endfor %}
{% endif %}Drive all of it from an agent
Folders, page moves, pinned landing pages and menu bindings are all available over MCP and the CLI. One rule matters: the dashboard read returns the binding, with children empty. That is correct. Write the expansion back and the menu becomes a snapshot and stops tracking your pages.
# the output of get pipes straight back into set
spideriq content navigation get header > nav.json
spideriq content navigation set header --file nav.json
# edit the source, never the expansion
is_folder # create a folder
parent_id # move a page into it
index_page_id # pin its landing page