How many top-level nav items can you have before people stop scanning them?

The working ceiling is whatever the eye can still take in at a single glance, not a fixed number you can paste into every project. A primary nav stays scannable while a person can absorb the whole row in one pass and form a quick map of what the site offers. It degrades the moment the items multiply into a long strip that no one reads to the end. So the real limit is glanceable comprehension paired with clear labels, and the count is downstream of that, not the rule itself.

The reason a hard number alone fails is that the ceiling moves with the words. A nav of short, distinct, instantly understood labels reads in one sweep even when there are several of them, while a nav of long, vague, or overlapping labels exhausts the reader’s attention sooner because each item demands interpretation rather than recognition. Glanceable comprehension is the thing degrading, and the count is just its most visible symptom. This is what the “add every section to the top nav so nothing is hidden” instinct leaves out: visibility is not the same as scannability. Putting everything in the top row does not make everything findable, it makes the whole row harder to scan, and items that cannot be scanned are effectively hidden in plain sight.

You see the failure on sites that treat the primary nav as a complete table of contents. A header crammed with a dozen top-level links, each a slightly different department, forces the visitor to read the entire row word by word instead of recognizing the few destinations they care about, and most people stop partway, give up, and reach for search instead. The same site with a tight set of clear primary items, the genuinely top-level paths, and everything else grouped underneath or demoted, lets the eye land in an instant and gives the visitor a usable mental model of the place on the first look.

One case sits outside this: this is about the count of top-level items, not about how the menus beneath them are built. A short, glanceable primary nav can sit on top of a deep and well-organized structure; the demoted items are not deleted, they are grouped under sensible parents or moved to a footer, a secondary nav, or a within-section menu where the people who want them will look. There are also dense, expert tools where a power user genuinely scans a wider command surface fluently, and the glance test still applies, it is just calibrated to that audience. For a general audience, the row that reads at a glance is short.

The reason the glance is the right unit, rather than a memorized maximum, is that the primary nav’s job is recognition, not reading. When a visitor can take in the whole set at once, the nav functions as a map: it tells them what the site is and where to go without asking them to process it line by line. The instant the row grows past what a glance can hold, the nav stops being a map and becomes a list to read, and lists invite skipping, fatigue, and the retreat to search. Grouping is not a compromise forced by the limit; it is how a sprawling structure is made comprehensible, because a few clear parents are easier to scan and reason about than a dozen flat siblings, even though the same destinations live inside.

Keep the primary nav to what reads at a glance, and group or demote the rest. Decide by the glance, not by a quota: look at your top row the way a first-time visitor would, in one quick pass, and if you cannot take in the whole set and grasp what each item means before your attention drifts, you are over the ceiling. Trim the top level to the genuinely primary paths, give them labels clear enough to recognize rather than decode, and let the structure beneath carry everything else.