Sticky Menu WordPress: 7 Proven 2026 Methods That Convert

A sticky navigation bar is no longer a nice-to-have design flourish in 2026 — it is a measurable conversion and usability lever that separates high-performing WordPress sites from the rest. Modern users expect persistent access to primary navigation, search, and calls to action regardless of scroll depth, and search engines reward the improved engagement signals that follow. This guide walks through every viable method for building a sticky menu in WordPress, from block-theme-native approaches to custom CSS, JavaScript, and plugin-driven solutions.

Table of Contents

Why Sticky Navigation Still Matters for WordPress in 2026

The business case for a sticky menu has strengthened rather than weakened. Interaction data from 2025 and 2026 consistently shows that persistent navigation reduces the number of scroll-backs users perform, which correlates with longer session durations and lower bounce rates on content-heavy sites. For ecommerce, keeping the cart icon and category links in view has a direct, measurable effect on add-to-cart and checkout completion rates. For publishers, a sticky header that surfaces search and newsletter signup converts anonymous traffic into subscribers at a higher rate than a static header.

From a Core Web Vitals perspective, the conversation has matured. The naive sticky header that listens to scroll events and recalculates layout on every frame is a performance anti-pattern that can wreck Interaction to Next Paint (INP). The modern approach uses CSS position: sticky, which the browser compositor handles off the main thread, or a lightweight IntersectionObserver that fires only at threshold crossings. Understanding this distinction is the difference between a sticky menu that helps your metrics and one that quietly sabotages them.

Accessibility is another dimension that has become non-negotiable. A sticky header that covers content when a user zooms, or that traps keyboard focus, or that fails to respect prefers-reduced-motion, is a liability under WCAG 2.2 and the European Accessibility Act enforcement that ramped up through 2025. A well-built sticky menu must remain dismissible, must not obscure the focused element, and must announce state changes to assistive technology. These requirements shape the implementation choices throughout this guide.

There is also the question of mobile. On small viewports, a full sticky header can consume a disproportionate share of vertical space, especially when the browser chrome is also present. The 2026 best practice is a compact sticky bar that appears only after the user scrolls past the hero, often containing just the logo, a menu toggle, and the primary CTA. This pattern, sometimes called a shrink-on-scroll or reveal-on-scroll header, balances persistent access with screen real estate.

Finally, the tooling has improved. Block themes expose header templates that you can style with theme.json, plugins like Sticky Menu (or Anything!) on Scroll and My Sticky Menu have been rewritten for the block editor, and the WordPress Interactivity API (stable since 2025) provides a declarative way to add scroll-driven behaviour without a jQuery dependency. The methods below reflect this 2026 reality rather than the plugin-and-Customizer workflows of the previous era.

Choosing the Right Approach: Block Theme vs Classic Theme vs Plugin

Before writing a single line of CSS, decide which architectural layer owns the sticky behaviour. The three viable layers are the theme (block or classic), a plugin, and custom code in a child theme or code snippets plugin. Each has trade-offs in portability, performance, and maintenance that matter more in 2026 than they did when themes were the only realistic option.

A block theme with native sticky support is the cleanest path if you are starting fresh. Because the header is a template part composed of blocks, you can apply position: sticky through the block’s Additional CSS or through a theme.json style variation. This keeps the behaviour inside the theme, version-controlled, and free of third-party dependencies. The downside is that switching themes later means re-implementing the sticky logic, and not every block theme exposes the necessary hooks cleanly.

A plugin is the pragmatic choice when you need sticky behaviour on a classic theme, when you want a visual configuration UI, or when you need per-post or per-device control without touching code. The 2026 plugin ecosystem has consolidated around a few well-maintained options that support the block editor and respect performance budgets. The risk is plugin bloat: a sticky menu plugin that loads its own jQuery, its own CSS framework, and its own settings page can add hundreds of kilobytes for a feature that CSS handles natively.

Custom code in a child theme or a snippets plugin gives you maximum control and minimum overhead. If you are comfortable with PHP, CSS, and a little JavaScript, this is often the best long-term answer because you ship exactly what you need and nothing more. The trade-off is that you own the maintenance, including testing against WordPress core updates and browser changes.

The decision matrix below summarises when each approach wins. Use it as a starting filter, then read the detailed sections that follow for the implementation specifics.

Approach	Best For	Performance Impact	Maintenance Burden	Portability
Block theme native	New sites on FSE themes	Minimal (pure CSS)	Low	Low (theme-locked)
Classic theme + child CSS	Existing classic themes	Minimal	Medium	Medium
Dedicated plugin	Non-technical site owners	Variable (audit needed)	Low	High
Custom code snippets	Developers wanting control	Minimal	Medium-High	High
Page builder module	Elementor/Bricks users	Moderate	Low	Low

A useful rule of thumb: if your theme already renders the header as a block template part, start there. If it does not, and you are not ready to migrate, a plugin is faster than rebuilding the header. Only reach for custom JavaScript if you need behaviour that CSS cannot express, such as a header that hides on scroll-down and reveals on scroll-up.

Method 1: Native Sticky Headers in Block Themes

Block themes have made sticky headers a first-class concern. When you open the Site Editor and select the Header template part, you can apply sticky positioning without leaving the editor. The mechanism is straightforward: the header block receives position: sticky and a top offset, and the browser keeps it pinned within its scroll container. Because this is handled by the compositor, it does not block the main thread and does not degrade INP.

Configuring sticky behaviour through the Site Editor

In WordPress 6.7 and later, the Group and Header blocks expose a Position control under the Advanced panel in the block sidebar. Setting Position to Sticky and Top offset to 0 pins the header to the top of the viewport. You can also set a z-index to ensure the header sits above hero images and other positioned elements. This is the zero-code path and it works with any block theme that uses standard template parts.

One nuance: the sticky element only sticks within its parent container. If your header template part is wrapped in a container with overflow: hidden, sticky positioning will silently fail. This is the single most common reason a native sticky header does not work, and it is worth checking the parent chain before assuming the theme is broken. The fix is to remove overflow: hidden from any ancestor or to move the header outside that container.

Styling sticky headers with theme.json

For teams that want the sticky behaviour encoded in the theme rather than clicked into the database, theme.json is the durable option. You can define a style variation that applies position: sticky to the header, and because theme.json is version-controlled, the behaviour travels with the codebase. This is especially valuable for agencies managing many client sites from a shared parent theme.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "styles": {
    "blocks": {
      "core/template-part/header": {
        "position": {
          "type": "sticky",
          "top": "0px"
        },
        "zIndex": 100
      }
    }
  }
}

This snippet targets the header template part specifically, so you do not accidentally make every template part sticky. The version 3 schema is current for WordPress 6.7 and later, and the position object supports type, top, right, bottom, and left. If you are on an older schema version, upgrade before relying on this, because the position API was refined across 6.5 and 6.6.

Handling the admin bar offset

When a logged-in user views the site, the WordPress admin bar occupies the top of the viewport and pushes the sticky header down. The admin bar has a fixed height that changes at the 783px breakpoint, so a hard-coded top offset will be wrong at one size or the other. The robust solution is to use the CSS custom property that WordPress exposes, or to add a body-class-scoped override.

/* Respect the admin bar height for logged-in users */
body.admin-bar .wp-block-template-part.header {
  top: 32px;
}

@media screen and (max-width: 782px) {
  body.admin-bar .wp-block-template-part.header {
    top: 46px;
  }
}

This is a small detail that separates a polished implementation from one that looks broken for editors and administrators. Always test sticky headers while logged in, because that is the state in which many site owners first notice the overlap.

Method 2: Sticky Menus on Classic Themes with CSS

Classic themes still power a large share of production WordPress sites, and the good news is that you do not need a plugin to make their headers sticky. A few lines of CSS in a child theme stylesheet, or in the Additional CSS panel, will do the job. The key is to target the correct header selector, which varies by theme, and to avoid the overflow trap described earlier.

Identifying the correct header selector

Open your site in a browser, right-click the header, and inspect the element. You are looking for the outermost element that wraps the logo and navigation, often something like .site-header, #masthead, or header.site-header. Once you have the selector, apply position: sticky and a top value. If the theme uses a fixed header already, you may only need to adjust the offset and z-index.

/* Classic theme sticky header */
.site-header {
  position: sticky;
  top: 0;
  z-index: 999;
  background-color: var(--wp--preset--color--base, #ffffff);
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.08);
  transition: box-shadow 0.2s ease;
}

/* Add a stronger shadow once the page is scrolled */
body.is-scrolled .site-header {
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.12);
}

Using the WordPress preset color variable means the header background follows the theme palette, which keeps it consistent if you later change colours in the Customizer or theme.json. The transition on box-shadow is a subtle cue that the header is now floating above content, which improves perceived quality without adding motion that could trigger vestibular issues.

Adding the scrolled state with a tiny script

If you want the header to change appearance after scrolling, you need a class toggle. The performant way to do this in 2026 is an IntersectionObserver watching a sentinel element at the top of the page, not a scroll event listener. The observer fires only when the sentinel leaves the viewport, which is a single callback rather than a per-frame calculation.

// Toggle a class on the body when the user scrolls past the hero
const sentinel = document.querySelector('.hero-sentinel');
if (sentinel && 'IntersectionObserver' in window) {
  const observer = new IntersectionObserver(
    ([entry]) => {
      document.body.classList.toggle('is-scrolled', !entry.isIntersecting);
    },
    { rootMargin: '0px', threshold: 0 }
  );
  observer.observe(sentinel);
}

Place a sentinel element, such as an empty div with the class hero-sentinel, immediately after the header. When it scrolls out of view, the body gains the is-scrolled class and your CSS can respond. This pattern is battery-friendly, works with the browser’s rendering pipeline, and avoids the jank that scroll listeners cause on low-powered devices.

Respecting reduced motion and zoom

Two accessibility details are easy to miss. First, if you animate the header height or position, wrap the transition in a prefers-reduced-motion media query so users who have requested less motion are not subjected to it. Second, test at 200% zoom, because a sticky header that occupies too much vertical space can obscure content when the viewport is effectively halved. A common fix is to reduce the header padding at high zoom levels or to allow the header to become non-sticky below a certain effective height.

Method 3: Plugin-Based Sticky Menus Without the Bloat

The plugin route remains valid, especially for site owners who prefer a settings UI over code. The difference in 2026 is that you should audit plugins for performance before installing them. A sticky menu plugin should not enqueue jQuery, should not load a CSS framework, and should not add database queries on every page load. The best modern plugins are thin wrappers around the same CSS you would write by hand.

Evaluating a sticky menu plugin

Before installing, check three things. First, look at the plugin’s readme for the last-updated date and the tested-up-to version; anything not tested against the current WordPress release is a risk. Second, install it on a staging site and measure the added page weight with your browser’s network panel. Third, check whether it supports the block editor and block themes, because a plugin built only for the classic Customizer will not help you on an FSE site.

Plugin	Block Editor Support	Added Page Weight	Per-Device Control	Notes
Sticky Menu (or Anything!) on Scroll	Yes	Low	Yes	Mature, widely used
My Sticky Menu	Yes	Low	Yes	Block-friendly UI
Sticky Header by Themepoints	Partial	Moderate	Yes	Classic-focused
Elementor Pro sticky header	Yes (Elementor)	Moderate	Yes	Only within Elementor

A plugin is the right call when you need per-post overrides, such as disabling the sticky header on landing pages, or when multiple non-technical editors manage the site. If you are the only person touching the site and you are comfortable with CSS, the hand-written approach is leaner and easier to debug.

Configuring a plugin correctly

Most sticky menu plugins follow a similar flow: install and activate, open the settings page, choose the element to make sticky by CSS selector or by picking from a list, set the offset and z-index, and optionally enable shrink-on-scroll or hide-on-scroll-down behaviour. The critical setting is the selector. If you pick the wrong element, you may end up making the entire page wrapper sticky, which produces bizarre results. Always preview on a staging copy first.

One underrated feature to look for is the ability to disable stickiness on specific templates, such as the checkout page or a full-screen landing page. A sticky header on a distraction-free landing page undermines the design intent, so per-template control is genuinely useful rather than a gimmick.

Method 4: Custom JavaScript for Advanced Scroll Behaviour

Sometimes CSS alone is not enough. If you want a header that hides when the user scrolls down and reappears when they scroll up, or that shrinks after a threshold, you need JavaScript to track direction. The 2026 best practice is to keep this logic minimal, run it off the main thread where possible, and always provide a CSS-only fallback for users with JavaScript disabled.

Implementing hide-on-scroll-down, reveal-on-scroll-up

The pattern compares the current scroll position with the previous one. If the user is scrolling down and has passed a threshold, hide the header by translating it up. If they scroll up, reveal it. Throttling with requestAnimationFrame keeps the work aligned with the browser’s paint cycle.

// Reveal-on-scroll-up header with requestAnimationFrame throttling
let lastY = window.scrollY;
let ticking = false;
const header = document.querySelector('.site-header');
const threshold = 120;

function onScroll() {
  const y = window.scrollY;
  if (y > threshold && y > lastY) {
    header.classList.add('header--hidden');
  } else {
    header.classList.remove('header--hidden');
  }
  lastY = y;
  ticking = false;
}

window.addEventListener('scroll', () => {
  if (!ticking) {
    window.requestAnimationFrame(onScroll);
    ticking = true;
  }
}, { passive: true });

The passive: true option tells the browser the listener will not call preventDefault, which allows scrolling to proceed without waiting for the handler. This is essential for smooth scrolling on touch devices. The header–hidden class applies a transform: translateY(-100%) with a transition, so the movement is smooth but cheap to animate.

Providing a no-JavaScript fallback

If JavaScript fails to load, the header should remain visible rather than disappearing. The safest approach is to make the header sticky by default in CSS and only apply the hide behaviour once JavaScript has added a class to the html element, such as js-enabled. This progressive enhancement pattern ensures the navigation is always usable.

/* Default: header is sticky and visible */
.site-header {
  position: sticky;
  top: 0;
  transition: transform 0.25s ease;
}

/* Only hide when JS is active and the class is applied */
html.js-enabled .site-header.header--hidden {
  transform: translateY(-100%);
}

@media (prefers-reduced-motion: reduce) {
  .site-header {
    transition: none;
  }
}

This layered approach means the site degrades gracefully. Users on slow connections where the script has not yet executed still get a working sticky header, and users who prefer reduced motion get an instant state change rather than an animation.

Testing across browsers and devices

Sticky positioning and IntersectionObserver are well supported in 2026, but edge cases remain. Safari has historically had quirks with sticky elements inside flex containers, and some in-app browsers on social platforms behave differently. Test on real iOS Safari and Android Chrome, not just desktop DevTools emulation, because the emulator does not reproduce the dynamic browser chrome that affects viewport height on mobile.

Optimising Sticky Menus for Core Web Vitals and Accessibility

A sticky menu touches two of the three Core Web Vitals directly: it can affect Cumulative Layout Shift if it changes size after load, and it can affect Interaction to Next Paint if its scroll handling is heavy. Getting these right is not optional in 2026, because the thresholds are enforced and the competition is fast.

Preventing layout shift

CLS happens when the sticky header changes height after the initial render, pushing content down. The fix is to reserve the header’s space from the start. If the header shrinks on scroll, do it with transform: scale or by animating padding, not by changing the element’s height in a way that reflows the document. Better still, keep the header height constant and change only its background and shadow, which are compositor-friendly properties that do not trigger layout.

Keeping INP low

INP measures the responsiveness of the page to user input. A sticky header that runs a scroll handler on every frame competes with input handling and can push INP above the 200ms good threshold. The remedies are the ones already described: use CSS position: sticky instead of JavaScript, use IntersectionObserver instead of scroll events, and throttle any remaining scroll work with requestAnimationFrame and passive listeners.

Accessibility requirements

A sticky header must not trap focus, must not obscure the element that currently has focus, and must be operable by keyboard alone. If your header contains a mega-menu, ensure it can be closed with the Escape key and that focus returns to the trigger. Also ensure the sticky header does not cover anchor targets when a user jumps to a section via a table of contents link; the common fix is scroll-margin-top on the target elements.

/* Prevent the sticky header from covering anchor targets */
:target,
h2[id],
h3[id] {
  scroll-margin-top: 96px;
}

This single rule resolves one of the most annoying sticky-header bugs, where clicking an in-page link scrolls the heading underneath the header. Adjust the 96px value to match your header height plus a little breathing room.

Common Pitfalls and How to Troubleshoot Them

Even experienced developers hit the same handful of problems when implementing sticky menus. Knowing them in advance saves hours of debugging. The most frequent issue is the overflow trap, where an ancestor element with overflow: hidden or overflow: auto prevents sticky positioning from working. Walk up the DOM tree from the header and remove or change any overflow value that is not visible.

The sticky element scrolls away immediately

If the header sticks for a moment and then scrolls off, the parent container is almost certainly the culprit. Sticky positioning is relative to the nearest scrolling ancestor, so if the header’s parent is only as tall as the header itself, there is no room to stick. The fix is to ensure the header’s parent spans the full page height, or to move the header out of any wrapper that constrains it.

The header overlaps the admin bar or a modal

Z-index conflicts are the second most common complaint. A sticky header with z-index: 999 can sit above a modal that should be on top. Audit your z-index scale and use a documented range, such as 100 for the header, 200 for dropdowns, and 1000 for modals. Avoid arbitrary large numbers, because they make future layering decisions impossible.

The header jitters on mobile

Mobile browsers resize the viewport as the address bar hides and shows, which can cause a sticky header to jump. Using position: sticky rather than position: fixed largely avoids this, because sticky is relative to the scroll container and does not depend on viewport height. If you must use fixed, consider the dynamic viewport units (dvh) introduced in modern browsers, which account for the collapsing browser chrome.

The menu is inaccessible on keyboard

If the sticky header contains a dropdown that only opens on hover, keyboard users cannot reach the submenu. Ensure the trigger is a button element, that it toggles aria-expanded, and that the submenu is reachable by Tab. This is a WCAG requirement and a common failure point in hand-rolled sticky menus.

Testing, Measuring, and Maintaining Your Sticky Menu

Shipping a sticky menu is not the end of the work; it is the beginning of a measurement cycle. You should verify that the feature improves the metrics you care about and does not introduce regressions. The tools available in 2026 make this easier than ever, but you have to actually use them.

Lab testing versus field data

Use Lighthouse or PageSpeed Insights for a quick lab check of CLS and INP, but treat field data from the Chrome User Experience Report as the source of truth. Lab tests run on a fast machine with a clean cache and will not reveal the jank that real users on mid-range Android devices experience. If your field INP regresses after adding a sticky header, the scroll handling is the first place to look.

A/B testing the sticky menu

If you run an ecommerce or lead-generation site, A/B test the sticky header against the static version. Measure add-to-cart rate, checkout completion, and scroll depth. In many cases the sticky header wins, but not always; on minimal landing pages it can be a distraction. Let the data decide rather than assuming the pattern is universally better.

Maintenance checklist

Sticky menus depend on theme structure, so a theme update can break them. After any theme or plugin update, re-test the header on desktop, mobile, and while logged in. Keep your custom CSS in a child theme or a code snippets plugin so it survives updates, and document the selectors you rely on so a future maintainer knows what to check. If you use a plugin, subscribe to its changelog and test major versions on staging before updating production.

For authoritative background on the underlying web platform features, consult the MDN documentation on position: sticky at https://developer.mozilla.org/en-US/docs/Web/CSS/position, the WordPress Theme Handbook on block themes at https://developer.wordpress.org/themes/block-themes/, the web.dev guide to Interaction to Next Paint at https://web.dev/articles/inp, the WCAG 2.2 specification at https://www.w3.org/TR/WCAG22/, and the WordPress Interactivity API reference at https://developer.wordpress.org/block-editor/reference-guides/interactivity-api/. These resources are kept current and are the right place to verify behaviour when browser or core updates land.

A sticky menu done well is invisible in the best sense: users never think about it, they simply always find what they need. Done poorly, it is a source of jank, overlap, and accessibility failures. The methods in this guide give you a path for every type of WordPress site in 2026, whether you are working in the Site Editor, a classic child theme, or a custom JavaScript layer. Pick the layer that matches your team’s skills and your site’s architecture, measure the result, and iterate.

Pay Writer

STAY TUNED WITH US

Sign up for our newsletter to receive our latest blogs.

Get Best Web Hosting and Services for your Business

Resources

Company

Most read