WordPress 7.0 is bringing Customizable Navigation Overlays to the core editing experience, and frankly, it’s a release I’ve been waiting for since the early days of Full Site Editing. If you’ve spent any time trying to make a client’s mobile menu look like anything other than a standard list, you know the frustration. We’ve been stuck with a rigid, hardcoded overlay that required significant CSS overrides just to add a simple logo or a “Book Now” button.
The current call for testing on Make WordPress marks a shift in how we handle responsive menus. Instead of a “one-size-fits-all” overlay, we are moving toward a block-based approach where the overlay is essentially a template part.
Why Customizable Navigation Overlays Matter for Devs
Before this update, customizing the mobile “hamburger” menu often felt like a hack. We had to fight against the default styles using specific selectors that felt fragile. Consequently, maintaining brand consistency across desktop and mobile was a bottleneck in our workflow.
Specifically, the “Naive Approach” we used to use involved heavy CSS injections to hide or show elements within the menu container:
/* The old, hacky way to add a logo to the mobile menu */
.wp-block-navigation__responsive-container.is-menu-open::before {
content: "";
display: block;
background: url('logo.png');
height: 50px;
margin-bottom: 20px;
}With Customizable Navigation Overlays, this logic is refactored into the editor. You can now use patterns and blocks directly within the overlay. This means you can add Social Icons, Search blocks, or custom Call-to-Action buttons without writing a single line of custom CSS.
The Technical Architecture: Template Parts
Technically, these overlays are saved as template parts. This is a smart move by the Core team because it allows for reusability. You could potentially have different mobile menus for your Shop page versus your Blog, all managed within the Site Editor. Furthermore, themes can now ship with predefined overlay patterns, giving users a much better starting point.
I’ve previously discussed handling WordPress core update regressions, and this feature is a prime candidate for careful testing. The way the markup is injected into the DOM is currently a hot topic for debate.
The Markup Debate: SEO and Accessibility
One of the “gotchas” in the current testing phase is where the overlay markup should live in the HTML. The team is considering four options: within the <nav> element, as a sibling, or at the extreme top/bottom of the page.
As a developer, I lean toward keeping it close to the trigger for accessibility (focus management) but moving it to the end of the DOM can sometimes prevent z-index “wars” with sticky headers. However, from an SEO perspective, we need to ensure that crawlers don’t see duplicate navigation links that could dilute our link equity.
If you want to contribute to this discussion, check out the Gutenberg tracking issue on GitHub. Your input on how screen readers handle the focus trap within these new overlays is critical before the WordPress 7.0 feature freeze on February 9, 2026.
Look, if this Customizable Navigation Overlays stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway for Your Ship Dates
Don’t wait for the official release to see how this affects your custom themes. Use the WordPress Playground instance to test Scenario 2 (Building from scratch). If you find that complex block combinations break the mobile layout, report it now. Refactoring your navigation strategy today will save you dozens of hours of debugging once 7.0 hits the mainstream.
