An agent adds a page, then adds a menu item for it. Repeat that for two years and the navigation stops describing the site. It describes the order things got built in.
The question that follows is almost always the wrong one: how many items is too many. There is no fixed number, and treating the count as the target misses what actually breaks.
The 7-item rule is a myth, not a standard
Every agent who has read a web design article has heard some version of "keep your menu to 7 items or fewer, because that is the limit of short-term memory." It sounds precise. It is not accurate.
Nielsen Norman Group, the usability research group that has studied navigation menus for decades, states plainly that this is a common misconception. Visitors do not memorize a menu and then choose from memory. They scan the visible options on the page and recognize the one that matches what they are looking for. Recognition does not have the same limit as short-term recall, so a 9-item menu with clear labels can outperform a 6-item menu with vague ones.
Every additional item still adds scanning effort, and a visitor who has to read carefully to find the right label is a visitor who might leave instead. Clarity of the labels is what decides the outcome; the count only matters as a side effect of that.
What actually determines the right number
For a typical agent or small-team site, five factors decide whether a menu is working, and none of them is a target number.
How many distinct things a visitor comes looking for. A solo agent selling in two neighbourhoods needs fewer top-level categories than a team covering ten. Count the actual searches: buying, selling, neighbourhoods, about the agent, contact. That is close to the natural ceiling for most agent sites before dropdowns are needed at all.
Whether labels describe the visitor's question or the office's structure. "Resources" describes nothing. "Buying a Condo" describes exactly who should click it. The label test is simple: could a stranger who has never seen your site guess what is behind each word.
How deep the dropdowns run. NN/g's menu-design checklist is direct about this: a simple dropdown works for one tier and becomes frustrating at two. Beyond two tiers, it calls the pattern highly inadvisable, and recommends a mega menu or a dedicated landing page instead of a third level of nesting.
Whether the menu is visible or hidden. This is the factor most agent sites get wrong, and it costs more than item count ever does.
Whether the links are real links Google can follow. A menu can look correct and still be invisible to search, which is a separate failure covered below.
The hamburger icon is not a desktop shortcut
Plenty of agent sites hide the entire main menu behind a hamburger icon on desktop, treating it as a clean, minimal look. The usability cost of that choice is measured, not theoretical.
NN/g ran a controlled study comparing visible navigation against hidden, icon-triggered navigation. The finding: hiding a site's main navigation cuts content discoverability almost in half. Desktop tasks took 39% longer to complete with hidden navigation, and participants rated those tasks 21% more difficult. On mobile the gap was smaller, 15% slower, but still present.
The reasons NN/g identifies are practical rather than abstract: a small icon is easy to miss, the icon itself does not say what is inside, and on desktop it is an unfamiliar pattern that visitors do not expect to have to click. None of that is about taste. It is about a real visitor failing to find a page that exists on the site.
The guidance splits cleanly by device. On desktop, skip hidden navigation entirely and keep primary links visible across the top, where there is enough width to fit them. On mobile, hiding navigation behind an icon is reasonable once the list runs past about four items, since screen space is the real constraint there. A site with three or four mobile links can often show them directly instead of adding a tap.
Menu links Google cannot follow are worse than a long menu
A confusing menu costs leads. A menu built the wrong way can cost search visibility entirely, and this failure is invisible to anyone looking at the site in a browser.
Google's own link guidance states that it can only crawl a link when it is a real anchor element with an href attribute pointing to an actual address. It explicitly calls out two patterns as not recommended: a link built with a framework routing attribute instead of a plain href, and a link that only responds to an onClick handler in JavaScript with no href present at all.
Some website builders and custom menu components produce exactly this second pattern by default: a menu item that looks and behaves like a normal link to a visitor, clicking correctly and taking them to the right page, while carrying no crawlable href underneath. A visitor never notices. Google's crawler does, and a page reachable only through such a link can sit outside the index regardless of the quality of the content on it.
The fix does not require a redesign. It requires checking, page by page,
whether view-source on the menu shows a normal <a href="/buying"> tag
under every item, including items inside dropdowns that only appear on
hover or tap. If a dropdown item does not show up in the page source
until a script runs, that is worth testing directly.
A practical structure for an agent or small-team site
For most solo agents and small teams, a working starting point looks like this: Home, Buying, Selling, Listings, Neighbourhoods (or Areas), About, Contact. That is 7 top-level items, arrived at because those map to 7 real, distinct things a visitor is looking for, not because 7 is a magic ceiling.
A team adds one more: a Team or Agents entry, so a visitor comparing agents on the roster does not have to guess which dropdown holds bios.
Within Buying and Selling, a dropdown can hold the deeper pages: first-time buyer content, a market report, a home valuation tool, a specific property type page. This matches the case laid out in what buyers and sellers actually check on an agent's website: the visitor arrives already knowing roughly what they want, and the job of the menu is to confirm the site has it within a click or two, not to walk them through every page the site has ever published.
Neighbourhood pages deserve special handling once there are more than a handful. Nest them under one Neighbourhoods or Areas item rather than listing each community as its own top-level entry, and let the neighbourhoods hub page do the work of routing a visitor to the specific area. The same logic that applies to choosing what belongs on a neighbourhood page applies to how those pages get linked from the menu: one clear entry point, not ten competing ones.
Rebuilding navigation without losing what already ranks
Restructuring a menu is one of the changes agents worry about most before a rebuild, and the worry is reasonable: get it wrong and pages that used to rank can quietly disappear from search.
The actual risk is not the new label or the new grouping. It is a page losing every internal link that used to point to it. A page with no link from anywhere on the site, sometimes called an orphan page, becomes much harder for both visitors and search engines to find, even if the URL itself keeps working. Reorganizing a site's navigation is fine during a redesign, as long as every page that used to be reachable stays reachable, either at the same address or through a working redirect to wherever it moved.
Before touching the menu, list every URL currently linked from it, and confirm each one has a place in the new structure, whether that is a top-level slot, a dropdown, or a link from within a hub page. Nothing on that list should end up with zero paths pointing to it.
The takeaway
Stop counting menu items and start testing them. Hand the site to someone who has never seen it, ask them to find your listings and your contact page on their phone, and watch where they hesitate. That hesitation is the real defect, whether the menu has 5 items or 15.
Visible navigation on desktop, dropdowns no deeper than two tiers, real crawlable links under every item, and labels that name what a buyer or seller is actually looking for: get those four right, and the exact count stops being the thing worth arguing about. If the current menu grew one page at a time without anyone stepping back to look at the whole thing, that is usually the moment a full website rebuild is worth more than another round of patching, since a rebuild starts from what visitors actually search for rather than from whatever the existing structure already has.
