Do Sticky Headers Help or Hurt Your Marketing Site?

Do Sticky Headers Help or Hurt?

They help on long pages where navigation is the point, and hurt on short marketing pages where they just take space. The deciding factor is not taste. It is whether visitors actually need the navigation while they read, and most B2B landing pages they do not.

We get asked for a sticky header on nearly every project, usually because a competitor has one. That is not a reason. A sticky header costs vertical space on every screen, breaks anchor links by default, and has a documented accessibility failure mode.

This piece is the argument we have with clients, written down. It covers the real costs, the three patterns worth choosing between, and the technical traps that make sticky headers look broken.

What Does a Sticky Header Actually Cost?

Vertical space, permanently, on the device where space is scarcest. A header that occupies part of a phone screen occupies it for the entire visit, on every page, whether the visitor wanted navigation or not.

On a laptop that cost is small. On a phone held in one hand it is a meaningful share of what the reader can see at once, and the effect compounds with a cookie banner and a browser chrome that already took their share.

The second cost is attention. A persistent bar with a call to action is a permanent invitation to leave the page. On a page whose job is to make one argument, that is working against you. We would rather the reader finish the section.

There is also a craft cost that rarely gets discussed. A sticky header has to look right over every background on the site, which usually pushes it towards a solid or blurred fill and away from anything more interesting. Our piece on website navigation UX covers the wider set of trade offs.

Why Does the Sticky Header Break Your Anchor Links?

Because the browser scrolls the target to the very top of the viewport, which is exactly where your header now sits. So clicking a link to a section lands with the section heading hidden behind the bar, and the reader sees the second paragraph first.

This is the single most common sticky header bug we find, and it is invisible in design review because nobody clicks an in page link during design review. It shows up later when someone follows a table of contents and lands in the middle of a section.

The fix is one property. MDN documents that scroll-margin-top adds an outset to the element's scroll area, so the target scrolls into view with spacing from the top of the container instead of flush against it. Set it on your headings to a little more than the header height.

Support is not an issue. MDN lists the property as Baseline "Widely available," available across browsers since April 2021. There is no reason to solve this with JavaScript scroll offsets, which is how it was done for years and still is on plenty of sites.

What Does WCAG Say About Sticky Headers?

It names them directly as a problem. WCAG 2.2 added Success Criterion 2.4.11 Focus Not Obscured (Minimum) at Level AA, which states that "when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content."

The understanding document is unusually specific about the culprits. It says "typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs." Your header is on the list by name.

The failure happens during keyboard navigation. A visitor tabs down the page, focus moves to a link that sits just above the fold, the browser scrolls it into view, and the sticky header covers it. The focus is somewhere the user cannot see, which is disorienting in a way a mouse user never experiences.

There is a stricter version too. Success Criterion 2.4.12 Focus Not Obscured (Enhanced), at Level AAA, requires that "when a user interface component receives keyboard focus, no part of the component is hidden by author-created content." The AA version tolerates partial obscuring; the AAA version does not.

The remedies the understanding document mentions are the same ones you would reach for anyway, including "using scroll padding so the banner does not overlap other content." Test it by tabbing through a real page, which takes a minute and catches the problem immediately. Our piece on focus and accessibility in product UI covers the testing habit.

Why Does Sticky Positioning Sometimes Just Not Work?

Two reasons, both documented, and both the cause of a lot of wasted debugging. The element needs an offset, and it sticks inside the wrong ancestor if any parent has a scrolling mechanism.

The offset requirement is the simpler one. MDN states that at least one inset property "needs to be set to a non-auto value for the axis on which the element needs to be made sticky," and that if both inset properties for an axis are auto, the sticky value "will behave as relative." So sticky with no top value is just a normal element.

The ancestor rule is the one that wastes an afternoon. MDN says a sticky element sticks to its "nearest ancestor that has a scrolling mechanism," created when overflow is hidden, scroll, auto, or overlay, "even if that ancestor isn't the nearest actually scrolling ancestor."

Read that carefully, because it means an overflow hidden set six levels up, probably to fix an unrelated horizontal scrollbar, silently redefines where your header sticks. The header then scrolls away and nothing in your CSS looks wrong.

Support itself is never the problem. MDN lists sticky positioning as Baseline "Widely available," established across browsers since July 2015. If it is not working, it is one of the two rules above.

Should the Header Hide When You Scroll Down?

Often yes, and this is our default for content heavy pages. Hide the header as the reader scrolls down, bring it back when they scroll up. Reading gets the full screen, and the intent to navigate gets the header back instantly.

The pattern works because scrolling up is a reliable signal. Nobody scrolls up to keep reading forward. They scroll up to go back, re-read, or leave, and all three are moments where navigation is useful.

Pattern	Best for	Main cost
Always visible	Documentation, dashboards, long reference pages	Permanent loss of vertical space
Hide on scroll down, show on scroll up	Blog posts, long marketing pages	Motion, and a reveal that can feel twitchy if tuned badly
Not sticky at all	Short landing pages, single argument pages	Navigation needs a scroll to the top or a footer

If you use the hiding version, respect reduced motion preferences and keep the transition short. A header that slides in slowly on every small upward scroll is worse than one that never moves.

How Tall Should a Sticky Header Be?

Shorter than the static version. A header designed to be sticky should shrink on scroll, because the generous version that looks good at the top of the page is too heavy to carry down the whole document.

The practical approach is two states. A taller resting state with the full logo and comfortable padding, and a compact scrolled state with tighter padding. The compact state is what most visitors see for most of their visit, so that is the one worth polishing.

Whatever height you land on, remember it is now a number two other things depend on. Your scroll margin needs to clear it, and your focus testing needs to account for it. Changing the header height later without updating both is how the anchor bug comes back.

When Should a Header Not Be Sticky at All?

On any page with one job. A pricing page, a demo request page, a single product page with one call to action. If the page has one desired action and it is repeated in the content, a persistent bar adds nothing and takes space.

We also argue against it where the navigation is a large mega menu. A sticky trigger for a panel that covers most of the screen is a heavy thing to carry on every scroll position, and the panel design usually assumes a page top context. Our piece on mega menu design covers that interaction in more depth.

The honest test is to remove it for a week and see whether anyone complains or any metric moves. In our experience nobody notices on short pages, which tells you what the feature was worth there.

What About Sticky Footers and Cookie Banners?

Same rules, more risk, because they stack. WCAG's understanding document lists sticky footers alongside sticky headers as typical offenders, and gives a pointed example: "a notification implemented as sticky content, such as a cookie banner, will fail this success criterion if it entirely obscures a component receiving focus."

The compounding is the real danger. A sticky header, a cookie banner, and a chat widget can leave a phone visitor with a narrow strip of actual content, and each one was approved separately by someone who did not see the others.

Our rule is one persistent element at a time. If the cookie banner is showing, the sticky header waits. If a chat widget is open, it is the only thing pinned. That is a coordination problem rather than a design problem, and it needs someone to own the whole viewport.

What Would We Do on Your Site?

Three checks, ten minutes. Tab through a long page and watch whether focus ever disappears behind the header. Click an in page anchor link and see where it lands. And look at a phone screenshot to count how much of the screen is content.

If the anchor links land wrong, that is a one line fix and worth doing today. If focus disappears behind the header, that is a Level AA failure and worth treating as a bug rather than a refinement.

After that the pattern choice is a judgement call about the page, and it should be made per page type rather than once for the whole site. A documentation page and a pricing page do not want the same header.

If you want us to look at how your header behaves across the site, or to rebuild it properly, we are happy to help. You can find us at phoenix.studio.