A sitemap is the exhaustive fallback when primary nav fails

What it is

Primary nav must choose, compress, and hide, so it will miss. A sitemap lists still-findable content exhaustively by structure, for when primary scent fails and a search word will not come. It is a fallback, not a second primary: people walk the compressed main road first, and open this inventory when that road dies. The XML sitemap search engines fetch is not a human exhaustive entrance. This leaf is the browsable page.

Exhaustive does not mean every query-parameter page. It means the legitimate classes and key leaves that primary nav dropped can still be scanned here.

Why it happens

Compressed nav bets on scent. When the bet loses, people often still hold a vague class name or a memory of seeing it on the tree. An exhaustive list substitutes scanning for scent: no need to guess the parent, only to recognize the target in a roster. The cost is length, so it cannot be the main road—the main road has to stay short enough to scan. Reverse the fallback (home is only a map, no primary) and every task pays the exhaustive-scan tax.

The map must also match the live structure. A stale map is worse than none: it offers a false sense of completeness, clicks are dead, and the fallback promise is falsified.

Studying it

On tasks where primary nav is designed to fail, compare presence versus absence of a human-browsable map.

• Paradigms: known-items whose primary labels preview badly or whose tree is too deep; one group with only primary and search, one with an HTML map added. Record how the map is discovered and success from it.
• Independent variables: entrance (footer / utility / zero-results), granularity (classes only / down to leaves), sync with the live structure.
• Dependent variables: whether people switch to the map rather than leave after primary failure, steps from the map, clicks on stale links.
• Methodological note: putting the map link in the task script overestimates discovery. Measure who finds the entrance unprompted. Crawler XML coverage is not human success on the map.

Where it stops holding

On a tiny site (a dozen pages) the exhaustive list can be the primary; a separate map duplicates it. In-app screens without stable URLs need a list of reachable functions, not a fake web tree. Where permission varies widely, the map must filter to the current user, or exhaustiveness exposes unreachable items that behave like broken links. Personalized streams have no stable exhaustive tree; a map does not apply.

Applying it

• Ship an HTML map in sync with the live structure, down to classes and key leaves that primary dropped—not every filter state.
• Put the entrance in the footer or utility cluster, and from zero-results offer “browse the full directory” into it. Do not put it on primary as another class.
• Update the map the same day as structural redirects.
• Verify with three items primary almost cannot find, without hinting where the map is. Reaching the map from the footer or zero-results and recognizing the target is what makes a fallback. If only a search-console XML exists, humans still have no exhaustive exit from primary failure.

Related

• Within the group: G2.09.1 Utility navigation holds function entries that are not part of the content tree · G2.09.2 Utility entries need less visual weight than primary nav so they do not compete · G2.09.4 Footer nav holds secondary and exhaustive links; it does not replace primary nav · G2.09.5 Help and support must stay reachable from every page without entering the main structure
• Adjacent: G2.01 Hierarchical navigation · G3.07 Zero-result handling · G1.07 Content inventory and audit
• Search terms: HTML sitemap · exhaustive fallback · secondary navigation