What

The "Navigation" section in the Site Editor's global sidebar — the panel that opens when clicking the WordPress logo — currently shows navigation menus in isolation. Users see the contents of a navigation block divorced from any site context: no accurate styling, no indication of which templates use the menu, and no clear path to editing the menu in its actual rendered context.

The experience is also functionally limited: users can reorder and delete menu items but cannot edit or add links from this view. The preview reflects only the raw menu data rather than the styles, layout, or behaviour defined by the surrounding template — which is of limited value to most users trying to understand how their navigation looks on the site.

A core goal of this work is to make it possible to manage navigation menus — adding, removing, and reordering items — entirely from this sidebar, without requiring users to navigate to the block editor or locate a Navigation block in a template. The canvas remains the right place for styling and layout; this section should handle the content of menus directly.

Why

When users visit this section, they typically want to:

• Find the menu that controls a specific part of their site's navigation
• Understand which menus are active and where they appear
• Make changes to a menu and see those changes in the correct context

The current experience fails all three. The isolated view gives users no way to know which menus are in use, where they appear on the site, or how they actually look. There is no clear path from this view to editing a menu in its real template context.

This has been a known gap for some time. User testing has reinforced that the current view creates confusion — particularly for users with multiple menus, who have no basis for distinguishing between them or understanding how a change to one menu will affect the rest of their site. #65828 recognised a similar need and explored DataViews-based UI patterns as a direction; this issue builds on that prior thinking and grounds it in explicit user requirements.

How

Discussion in the comments has produced a candidate approach, treating this section as both a discovery surface and an editing surface — two distinct but sequential phases of the same workflow.

Discovery phase

• A DataViews list of all navigation menus, with a "where used" field visible at a glance — showing which template parts reference each menu
• Each menu should have a clear active/inactive status — indicating whether it is currently in use anywhere on the site. This is distinct from post status (draft/published); a menu can be published but not actively used in any template
• For v1, scope is limited to template parts only; pages and other document types are out of scope initially, though the design should leave room to expand later
• Menus that are not yet used anywhere on the site are shown alongside active ones — the preview frame displays a placeholder in this case. This is important for users preparing menus in advance of activation

Editing phase

• Selecting a menu from the list shows a preview frame on the right, displaying the template part(s) where that menu is used. The interaction model draws on the page selector design explored in Include a page selector in the site preview to enhance the UX of global style #72497 — allowing users to switch between the page and template contexts in which their content appears — applied here to navigation menu locations
• An editable list view — consistent with the existing navigation block inspector sidebar — provides a full editing surface including adding and removing items. The appender defaults to page link blocks; non-link blocks (e.g. social icons) remain a canvas concern
• Individual menu item settings are surfaced via a popover, keeping the full menu structure visible while editing — not a drill-down that removes list context. This mirrors the content-only editing experience introduced for the navigation block
• Clicking a template part in the preview frame takes you directly into editing it in context, with a clear route back — breadcrumbs at every level, no dead ends
• The editable list view should feel and behave as close as possible to the equivalent experience in the navigation block's inspector sidebar — same task, two surfaces

Open Questions

The following questions are genuine open points. They are intentionally left unresolved here — the answers will come from prototyping and observation, not from further design discussion.

• Preview frame: all locations or one? Should the preview frame show all template parts where the menu is used simultaneously (reinforcing the synced nature of menus), or focus on a single location by default? There is reasoned disagreement on this point and it warrants empirical exploration.
• Preview frame behaviour on edit — when a change is made in the editable list view, does the preview update live across all visible locations simultaneously? Or does it update the focused location only? The right answer likely depends on how the question above is resolved.
• Popover mechanics at scale — how does the popover approach behave when a menu has many items or deeply nested structure? This needs to be stress-tested in code.

User Stories

As a site owner, I want to manage and make simple edits to my navigation menu without having to use the navigation block in the canvas.

As a site owner, I want to see at a glance which of my navigation menus are currently in use on my site, so that I can quickly distinguish between active menus and ones that are unused or in preparation.

As a site owner, I want to see which navigation menus are active on my site and where they appear, so that I can quickly find the right menu to edit without guessing.

As a site owner, I want to understand how my navigation menu looks in context before I edit it, so that I can make changes with confidence.

As a site owner managing multiple menus, I want to see meaningful information about each one — such as where it's used — so that I can distinguish between them and understand the impact of any changes I make.

As a site owner, I want a clear path from the Navigation sidebar to editing a menu in its actual template context, so that I can make styling or layout changes that go beyond managing the menu's content.

As a site owner, I want to build and populate a navigation menu before it is live anywhere on my site, so that I can prepare it in advance without it affecting visitors.

Visuals

The following are lifted from @fcoveram's comments below

Related Efforts

• A solid routing foundation for the site editor + Extensibility. #70862 — Extensible Site Editor (routing foundation and extensibility tracking issue). This work is built on top of the route-based architecture introduced here and will be delivered under the same experiment flag.
• Include a page selector in the site preview to enhance the UX of global style #72497 — Page selector in the site preview (Page vs Template toggle). The interaction model for switching between contexts in the preview frame draws directly on the design explored in this issue.