The desktop page looks correct after unused-CSS optimisation, but the mobile menu opens without positioning, stays invisible or covers the page incorrectly. The optimiser probably analysed the closed initial state and removed selectors used only after JavaScript adds a class.
Restore reliable navigation first, then narrow the exception. Visitors should not lose access to the site for the sake of a smaller stylesheet.
Confirm that CSS removal caused the failure
Disable only the unused-CSS feature in staging or through its safe bypass parameter, leaving caching and JavaScript settings unchanged. Retest the same mobile width as a logged-out visitor.
If the menu works again, compare the original and optimised CSS. If it remains broken, investigate delayed JavaScript, a theme update or stale generated assets instead.
Record whether the button receives its open state and whether the menu element changes class or ARIA attribute.
Capture the dynamic selectors
Open the menu and inspect the changed DOM. A theme may add classes such as:
<body class="menu-open">
<nav class="site-menu is-active" aria-hidden="false">Relevant selectors might include:
.menu-open {
overflow: hidden;
}
.site-menu.is-active {
opacity: 1;
visibility: visible;
transform: translateX(0);
}An automated crawler that never activates the button sees none of these states. It may also miss nested submenus, focus styles and the close control.
Check responsive media queries
The required rule may exist only below a breakpoint. Compare CSS at the exact width where the failure occurs and test around the boundary—for example 767, 768 and 769 pixels.
Do not safelist only .is-active if the layout also depends on parent classes, pseudo-elements or selectors inside @media. Preserve the smallest complete group that makes the interaction correct.
Review landscape mode and browser zoom, which can trigger the mobile navigation on a wide physical screen.
Safelist stable patterns, not generated fragments
Use the optimiser’s documented exclusion or safelist for verified menu selectors. Prefer a stable component prefix such as .site-menu over hashed page-builder classes that change when assets regenerate.
Avoid broad patterns such as every class containing active; they can retain a large part of the original stylesheet. Equally, adding one visible rule while omitting focus and submenu states creates a partially repaired menu.
Keep a note of why each selector is retained so future cleanup does not remove it again.
Inspect JavaScript timing as a second factor
Unused-CSS removal and JavaScript delay are often enabled together. The CSS may be present while the click handler is still postponed.
In the console, check for errors and observe whether activating the button changes aria-expanded or menu classes. If nothing changes until the visitor scrolls, delayed JavaScript—not missing CSS—is blocking the interaction.
Change one feature at a time. Excluding the menu script and menu CSS simultaneously makes it difficult to know which repair mattered.
Regenerate assets in the right order
After updating the safelist, regenerate the optimiser’s used CSS, then purge the affected page and CDN cache. Page builders may also need their generated CSS refreshed.
Avoid deleting cache directories manually on production. Use supported controls and confirm the new CSS URL returns successfully rather than an old cached version.
Test in a fresh session without the administrator toolbar, as logged-in HTML and assets can differ.
Verify navigation beyond opening
Confirm the menu:
- opens and closes with pointer and keyboard;
- exposes the correct expanded state;
- keeps visible focus;
- allows submenus to work;
- prevents inappropriate background scrolling;
- restores focus logically when closed;
- remains usable with reduced motion.
Test the header on the homepage, article, service page and checkout if it shares the same navigation.
When the optimiser needs deeper adjustment
Request an assessment when selector names are generated, the menu exists in several header templates or used-CSS files differ unpredictably by cache state. Send the affected URL, viewport and optimisation feature name without placing credentials in the first message.
A proper repair should preserve the dynamic component states, regenerate a stable result and prove that navigation remains accessible—not merely make the menu visible in one screenshot.