To fix a WordPress navigation menu appearing under the admin bar, first compare the same page while logged in and logged out. If the header shifts or overlaps the toolbar only while you are logged in, check the header’s fixed or sticky positioning and its responsive offset. If the toolbar is present but hidden behind the header or menu, investigate the elements’ stacking order instead. These are different layout problems and do not have one universal CSS fix.
Identify what is actually appearing under what
WordPress’s admin bar, also called the toolbar, is shown to logged-in users on the front end when enabled. A menu that looks misplaced may indicate an offset problem, a stacking problem, or a menu-specific issue:
- The header starts beneath the toolbar: this may be expected spacing, or a header positioning rule may be pushing it down.
- The header covers the toolbar: the header may be painted above the toolbar because of its stacking order.
- The toolbar is visible but a dropdown is obscured: inspect the dropdown and its ancestors; the dropdown can have a stacking-context problem distinct from the header.
Open the same page at the same viewport size once logged in and once logged out. Note whether the header moves, overlaps the toolbar, or only hides a dropdown. This comparison helps determine whether the toolbar is involved or whether the logged-out page has the same theme or plugin issue.
Find the right place to edit the menu
The editing route depends on the active theme. In the dashboard, open Appearance and check which editing options are available. WordPress.com’s menu troubleshooting guide describes the theme-dependent routes and common menu issues.
- Block theme: open Appearance → Editor and inspect the site header and Navigation block.
- Classic theme: use Appearance → Menus or, where available, Appearance → Customize → Menus.
Changing menu items will not fix a header’s positioning or stacking CSS. Use the theme’s supported editor to identify the header or navigation element, then investigate the layout rule affecting it.
Inspect the toolbar and header in browser developer tools
On a typical WordPress front end, the toolbar uses the #wpadminbar element. Verify that selector on the affected page, then inspect the actual header, navigation, and dropdown elements rather than assuming the theme uses a particular class.
In the browser inspector, compare the relevant elements’ position, top, margin, padding, z-index, and transform values. Also check ancestors: properties on a parent can create a stacking context, which affects how its children layer against other elements.
Offset a fixed or sticky header only when needed
If inspection confirms that the header is fixed or sticky at the top of the viewport and is overlapping the toolbar while logged in, its top offset may need to account for the toolbar. WordPress Core’s WordPress 5.9 developer note documents the responsive custom property --wp-admin--admin-bar--height. The note describes toolbar offsets of 32 or 46 pixels depending on screen width; using the property avoids hard-coding one of those values for every viewport.
/* Replace .site-header with the actual fixed/sticky header selector. */
body.admin-bar .site-header {
top: var(--wp-admin--admin-bar--height, 0px);
}This is an illustrative pattern, not a drop-in fix. Apply it only if the identified header is fixed or sticky and the theme does not already offset it. A header in normal document flow may develop an unwanted gap if given this rule. WordPress Core also documents using the custom property with scroll padding, but that is a separate setting from positioning a header.
Correct a stacking conflict without guessing at z-index
If the toolbar is being painted behind the header or menu, test a narrowly targeted stacking change on the element identified in the inspector. Do not assign a very large z-index blindly: a child cannot necessarily outrank an element outside its ancestor’s stacking context, and changing the wrong layer can place dropdowns behind other content.
A WordPress.org support thread reports a case in which the front-end toolbar was hidden behind site content and discusses z-index. It demonstrates that this symptom occurs, but does not establish a universal selector or value. The correct adjustment depends on the theme, page builder, and stacking contexts on the affected page.
Rank #3
Check for a missing or disabled toolbar
If the toolbar does not appear at all on the front end, check whether a plugin disables it and whether the theme calls wp_footer(). WordPress’s Toolbar documentation identifies these as possible reasons for its absence. Core’s admin-bar file references the toolbar stylesheet and bump styles, so a missing toolbar should not automatically be treated as a menu-positioning problem.
Recommended Free Tools
WordPress provides show_admin_bar() to control toolbar display. Disabling the toolbar can be useful as a diagnostic comparison, but it is not a general layout repair; avoid changing shared or public plugin behavior solely to conceal a header conflict.
Quick Recap
Save safely and retest
- Make the change in the theme’s supported custom CSS area or a child theme, and keep a reversible copy of the previous CSS.
- Clear relevant page and stylesheet caches so the browser is not showing an older rule.
- Retest the affected page on desktop and mobile, both logged in and logged out.
- If visitors still see the fault while logged out, investigate the theme’s header CSS and any menu or page-builder plugin; the toolbar is not the sole cause.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
