Footer nav holds secondary and exhaustive links; it does not replace primary nav
Aliases: footer nav · secondary links · not a replacement for primary
What it is
The footer holds secondary or exhaustive links—legal, jobs, partners, a full section list: not the main road of the current task, but findable at the bottom of every page. It does not replace primary nav. The main road still sits in a compressed class list at the top or side. Putting primary classes only in the footer asks everyone to scroll to the end of the document before classification can start. The footer may repeat primary names as confirmation; it must not be those names’ only home.
A sitemap may live in the footer; the footer is not itself a sitemap. It is a position-stable strip of secondary links.
Why it happens
Reading and task attention sit in the upper and middle viewport. The footer appears after content ends; people who reach it have often already decided the main road failed, or they want legal/jobs things that are not on that road. Putting primary classes at that moment schedules classification after the abandon point. Search and back-to-top skip the footer; if the main road exists only there, those people never see classes.
The footer’s exhaustiveness is valuable because the main road is compressed. Repeating primary classes can confirm (“yes, these sections exist”) but the scan is expensive and cannot be the first-choice UI. Legal links in the primary row pollute content scent; in the footer they match “secondary but reachable on every page.”
Studying it
Compare first-choice location when primary classes live only above, only in the footer, or in both.
- Paradigms: known-item content tasks, scroll depth and first-click vertical position; legal/jobs tasks for whether the footer can be reached without search.
- Independent variables: whether primary classes appear only in the footer, whether the footer repeats primary nav, whether legal links mix into the primary row.
- Dependent variables: vertical position of the first content-task click, abandon-without-scroll rate, success reaching the footer on secondary tasks.
- Methodological note: labs often instruct people to scroll to the end of long pages, which overestimates the footer as a main road. Allow leaving. On mobile the footer is farther; primary-only-in-footer hurts more—stratify.
Where it stops holding
A single-screen landing page has no convention of upper primary nav; the footer may be the only link strip and temporarily is the main road, which should be handed back once a multi-page structure exists. Print and email still need footer legal links; primary nav need not appear. Infinite streams have no stable bottom, so the footer may never arrive; exhaustive and secondary links need another entrance (utility or an annual page) rather than a pretence that scrolling will reveal them.
Applying it
- The first clickable appearance of primary classes must be in primary nav above the footer. The footer may repeat them as confirmation and exhaustiveness, not as the only copy.
- Legal, jobs, partners, and the map entrance go in the footer, not mixed into the primary class row.
- Verify on a first-screen shot: primary classes should already be there. Then a jobs or privacy task should complete in the footer without changing primary structure. If a content task must scroll to the end to see classes, the footer has usurped the main road.
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.3 A sitemap is the exhaustive fallback when primary nav fails · G2.09.5 Help and support must stay reachable from every page without entering the main structure
- Adjacent: G2.06 Global and local navigation · F1.11 First screen and below the fold · G2.01 Hierarchical navigation
- Search terms:
footer navigation·secondary links·primary versus footer
Cards in the same group
- G2.09.1Utility navigation holds function entries that are not part of the content tree
- G2.09.2Utility entries need less visual weight than primary nav so they do not compete
- G2.09.3A sitemap is the exhaustive fallback when primary nav fails
- G2.09.5Help and support must stay reachable from every page without entering the main tree