A shopper on a product page, such as Harbor in the fictional Example Sneaker Store, has scrolled down to the specifications. The full site header is still sitting at the top of the screen: the logo, a long navigation row, a search field, and a promotional banner. The section they came to read is now competing with a bar that has not changed since the top of the page.
A header that stays visible can keep useful controls within reach. It can also cover the content, distract from reading, or leave too little of the page in view, especially on a phone. Decide whether to keep the header visible, change its contents or behavior, or let it scroll away.
The header arrangements described below are fictional teaching inputs. They are not test results or measured comparisons.
Decide Whether the Header Has a Job Mid-Page
Before you argue for or against a persistent header (a fixed header), answer this: what will visitors need from this header halfway down this page?
Then choose one of these outcomes:
- Keep the header visible while people scroll, if they reasonably need its controls mid-page and the page stays comfortable to read and use.
- Change it, if access is useful but too much of the header persists, or its behavior gets in the way.
- Remove the persistence, if the header offers little ongoing value compared with the space it takes or the distraction it causes.
Nielsen Norman Group’s guidance on sticky headers is the main reference in this guide. Treat it as guidance, not as a measured finding. A persistent header can make navigation, search, and utility links easier to reach without scrolling back up. Done poorly, the same guidance says, it can be annoying, distracting, and obstructive.
Do not assume that a header which stays on screen is automatically better. The useful question is whether its continuing job justifies what it covers.
What belongs in the first view of a page, before anyone scrolls, is a different decision, covered in What Belongs Above the Fold on Mobile?.
Check How Much of the Page Remains Visible
A persistent header uses vertical space for as long as it stays on screen. That cost is easier to see on a phone than on a wide desktop view.
Nielsen Norman Group’s guidance is to keep the share of the screen given to content high, and says this matters even more on a phone. It also advises making controls large enough to tap, then minimizing any extra height. Look at the header together with other bars that stay put, such as a cookie message or a promotional strip. Several persistent elements can leave little of the page readable, even when each one seems modest on its own.
Check the actual labels, not a shortened demonstration. A wrapped navigation row, a second line of utility links, or a banner under the header can double the space in use.
Online Website Previewer can help you compare how much height the header takes at a phone width. It is a free tool and does not need an account. Paste the page address, press Preview, and look at the phone view at 390 by 844, alongside the tablet view at 820 by 1180 and the desktop view at 1920 by 1080, in CSS pixels. Each frame loads the live page, so you can scroll in the preview. This is a visual check in your current browser, not a test on a real phone. It does not copy a particular browser or touch behavior. Those sizes are a starting view rather than a match for your visitors.
A preview at phone width can reveal a space problem. Confirm the scrolling behavior on a real phone.
Keep Only What Earns Its Place
If the header stays on screen, everything in it has to earn that space.
Nielsen Norman Group advises an opaque, high-contrast header, because a translucent bar makes the content behind it hard to read. It also advises keeping motion to a minimum, so the header stays in a fixed place rather than arriving late as a moving bar.
A compact persistent bar might keep the logo, the menu control, and one important action. The full navigation, a promotional message, or a secondary search field may belong in the open menu, or only at the top of the page, rather than in the bar that follows the visitor down. The content and structure of the menu itself are covered in How to Review a Mobile Menu.
You can also consider a header that hides as the visitor scrolls down and returns when they scroll up. Nielsen Norman Group describes this as common on phones and says it “works moderately well.” That is a qualified judgment, not a proven result. Scrolling up is not always a request for the header. Someone may be rereading a line they just passed. If you try this behavior, evaluate it on a real phone rather than treating it as the default fix.
Watch What Happens While Scrolling
Open the page on a real phone and on a desktop, and scroll through a long page such as a product or article. Watch whether the header stays, shrinks, hides, or reappears, and whether that movement interrupts reading or covers useful content.
Look for a bar that jumps, lags behind the scroll, or changes size in a way that shifts the text you were reading. Check a page with short content as well as a long one, and turn a phone on its side. A header that feels modest in portrait can take a much larger share of a short landscape screen.
If the persistent bar includes a second purchase action, such as a sticky Buy control, check whether it competes with the action already on the page. The roles of those actions are covered in Button Hierarchy: Primary vs Secondary Buttons.
Check That Focused Controls Are Not Entirely Hidden
A persistent header can cover the control someone has reached with a keyboard.
WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum), at Level AA, requires that when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content. Sticky headers, sticky footers, and non-modal dialogs are named as typical causes. A control that is only partly covered can still pass this criterion. A requirement that no part of the control is hidden sits in Success Criterion 2.4.12, which is Level AAA, and is not the baseline.
Ask the team to check keyboard focus on the actual page, including when the header is visible. A visual preview cannot replace the team’s keyboard check on the actual page. If a focused item is being covered, describe what you saw and ask the team to keep it in view. Name the outcome you need, and leave the method to the team.
For a wider pass on banners and sticky elements that cover content, use the relevant checks in How to Test Your Website Before Launch. This guide is the decision about the header, not a substitute for that checklist.
Send a Keep, Change, or Remove Note
Include the page address, the width or device you checked, what the header contains while it stays on screen, and a screenshot. A useful note could say:
On the Harbor product page at [page address], in the 390 by 844 preview, the full header and promotional banner stay visible as I scroll to the specifications. They leave little room to read that section. Please review a more compact option, or let the header scroll away, so more of the page stays readable.
Send any observation from a real-phone check separately, naming the phone and what happened while scrolling.
If the header behaves differently on the listing, the product page, and an article, record that as well. How to Check Visual Consistency Across Your Website is the place to compare whether those differences are intentional.
Keep persistence when the mid-page job is real and the page stays usable. Change or remove it when the bar is covering more than it gives back.
