The Navigation Block

What the Navigation block actually is: the block-theme replacement for the classic Menus screen — a block that stores its list of links as its own post, of type wp_navigation, instead of the older menu-location system built around a custom taxonomy. A block theme places it inside a template part, usually the header, and editing the menu happens directly on the page in the site editor rather than through a separate admin screen; internally it lays out its own top-level links the same way a Row block arranges any other set of children, horizontally by default.

Menus are stored as a post type now, not in the Menus screen

Classic themes store a menu as a nav_menu term with individual nav_menu_item posts attached to it, managed from the Menus screen and assigned to a theme-defined location. The Navigation block does not use that system. Each navigation menu is its own wp_navigation post, and its content — the links, submenus and their order — is stored as block markup inside that post, the same way a page's content is block markup. There is no separate location-assignment step; the block itself, placed wherever the theme's template part puts it, is the assignment.

This is also why the classic Menus screen tends to be missing or unfamiliar-looking on a genuine block theme: the concepts it managed — locations, drag-and-drop item ordering in that specific screen — have moved into the block editor and are edited in place.

Submenus and open-on-click

A link inside the Navigation block can hold child links, rendered as a submenu. By default a submenu opens on hover with a click fallback for touch and keyboard use, but the block includes a setting to switch that to open strictly on click instead, which some sites prefer for accessibility or to avoid an accidental hover-triggered submenu on a large target. Whichever mode is chosen applies uniformly to every submenu in that instance of the block, not per item.

The overlay (mobile) menu

Below a configurable width, the block collapses into a toggle button that opens the full list in an overlay rather than showing it inline. The overlay's trigger icon, its colours and whether it covers the full screen are all block settings, and because the collapse point and appearance are controlled per navigation block instance, a header that reuses the block in two places — a main site header and a separate landing-page header, for instance — can have its mobile behaviour configured differently in each, though the gap between top-level links themselves still follows the theme's general block spacing and layout rules unless overridden per instance.

Why a menu can vanish after a theme switch

A wp_navigation post exists independently of any theme, so the menu's content itself is not deleted by switching themes. What can disappear is the placement — the new theme's template parts may not include a Navigation block pointing at that post at all, since the previous theme's header template is what put it there. The fix is placing a Navigation block in the new theme's header template part and pointing it at the existing wp_navigation post, rather than assuming the menu carries over automatically; the block offers a way to select an existing navigation menu rather than only creating a new one. This is a narrower version of the same category of trouble covered in why a WordPress menu isn't showing.

Editing it in a template part

Because the block usually lives inside a template part rather than a page, editing it means opening that template part in the site editor rather than opening an individual page — editing a page's own content does not touch the shared header. This is the same relationship a child theme has to its parent: a template part is shared structure, and a change made there applies everywhere that part is used, normally the entire site's header or footer at once.

Accessibility and keyboard operation

The rendered markup uses semantic list and link elements, and the mobile overlay toggle is a real button, which keeps default keyboard behaviour intact — tabbing through links, activating the overlay with Enter or Space, and closing it typically with Escape. Where this breaks down is custom CSS that hides focus outlines or restyles the toggle button as something else entirely; visually removing focus indication does not remove keyboard access, it just makes it invisible to the person using it. A general grounding in adding a dropdown menu is useful background, since submenu keyboard behaviour follows the same underlying expectations regardless of whether the dropdown is built with the classic menu system or the block.

Common mistakes

• Assuming a menu transfers automatically to a new theme. The wp_navigation post survives; its placement in a template does not, and must be added again.
• Editing a page instead of the template part. A Navigation block inside a page's own content is a one-off; the shared header lives in the template part.
• Restyling the overlay toggle without checking it is still keyboard-operable. Custom CSS can silently strip the semantics a plain button carried by default.
• Setting hover-to-open submenus on a touch-heavy site. Touch has no hover state, so click-to-open is often the more reliable choice.
• Creating a second wp_navigation post instead of reusing the existing one. The block lets you pick an existing menu; creating a new one duplicates content that then has to be maintained twice.

Verify

Open the site editor, find the template part containing the Navigation block, and confirm which wp_navigation post it points to. Resize the browser below the theme's mobile breakpoint and confirm the overlay opens and closes with both mouse and keyboard alone, tabbing to the toggle and activating it with the keyboard. After any theme switch, check the new theme's header template part specifically, since a missing menu after a switch is almost always a placement problem rather than lost content.