HTML landmarks identify the major regions of a webpage. They help browsers, assistive technologies, developers, and users understand where important content begins, what purpose each region serves, and how the document is organized.

Landmarks are not visual layout tools. They are structural signals. A page may look unchanged after landmark elements are added, yet become substantially easier to navigate, interpret, and maintain.

What are HTML landmarks?

HTML landmarks are meaningful regions that communicate the broad structure of a document. They identify areas such as the site header, primary navigation, main content, complementary information, and page footer.

A landmark answers a structural question:

  • Where is the page’s primary content?
  • Which region contains navigation?
  • What content is complementary to the main subject?
  • Where does site-wide or page-level footer information appear?

This is different from describing appearance. A landmark does not say that a region is wide, centered, fixed, or displayed in a sidebar. It describes what the region means within the document.

That distinction is central to semantic HTML: HTML communicates structure and purpose, while CSS controls presentation.

Semantic elements and landmark regions are related, but not identical

Many HTML elements are semantic, but not every semantic element automatically creates a landmark. The terms should not be treated as interchangeable.

For example:

  • <main> normally represents the page’s main landmark.
  • <nav> normally represents a navigation landmark.
  • <header> may represent a banner landmark, depending on where it appears.
  • <footer> may represent a content information landmark, depending on its context.
  • <section> organizes related content but does not necessarily become a landmark.
  • <article> identifies self-contained content but is not ordinarily treated as a page landmark.

Landmark behavior depends on an element’s semantics, its position in the document, whether it has an accessible name, and how browsers expose it through the accessibility tree.

This is one reason strong HTML requires more than replacing every <div> with a semantic-looking element. The structure must accurately reflect the relationships within the content.

Common HTML elements associated with landmarks

Common elements and their typical structural purpose
HTML element Typical purpose Landmark behavior
<header> Introductory content for a page or section May represent a banner landmark when used as the page-level header
<nav> A significant group of navigation links Normally creates a navigation landmark
<main> The document’s primary content Normally creates the main landmark
<aside> Content related to, but distinct from, surrounding content Often creates a complementary landmark, depending on context
<footer> Footer information for a page or section May represent a content information landmark when used as the page-level footer
<section> A thematic grouping of content May be exposed as a region when it has an accessible name
<article> Self-contained or independently reusable content Provides semantic structure but is not normally a landmark

The <header> element

A <header> contains introductory or navigational material for the page or for a section of content. A page-level header commonly contains a site name, logo, search interface, and primary navigation.

A <header> nested inside an <article> or <section> belongs to that content unit. It does not usually become another page-level banner landmark.

The <nav> element

A <nav> identifies a significant navigation area. Common examples include primary site navigation, article navigation, breadcrumb navigation, and footer navigation.

Not every collection of links needs to be placed inside <nav>. A short list of related resources within an article may simply be a list. The element is most useful when the links form a meaningful navigation system.

The <main> element

The <main> element contains the page’s central subject matter. Repeated site components—such as the primary header, global navigation, and site-wide footer—generally sit outside it.

Most conventional webpages should expose one active main landmark. This gives assistive technology users a dependable way to bypass repeated interface elements and move directly to the page’s primary content.

The <aside> element

An <aside> contains material that is related to the surrounding content without being part of its primary flow. Examples may include a glossary note, author information, supporting resources, or contextual explanation.

The word “aside” describes a content relationship, not a screen position. An aside can appear on the left, right, above, or below the main content. On a small screen, it may be displayed in the normal document flow.

The <footer> element

A page-level <footer> may contain copyright information, organizational details, policies, secondary navigation, or contact information. In that context, it can be exposed as the document’s content information landmark.

A footer can also belong to an individual article or section. For example, an article footer might contain publication details or taxonomy links. A nested footer does not ordinarily become the page’s content information landmark.

The <section> element

A <section> groups content around a shared theme. It often begins with a heading that identifies the subject of that section.

Sections are useful for document organization, but a page should not be divided into sections merely to create wrappers. If an element exists only for styling or scripting and has no thematic meaning, a <div> may be more accurate.

A section with an accessible name may be exposed as a region. This can be useful for important portions of a page, but naming every section can create an overcrowded landmark list.

The <article> element

An <article> represents a self-contained composition that could remain meaningful outside its immediate page. Examples include a news story, forum post, product review, or knowledge-base entry.

An article can contain its own header, sections, asides, and footer. This makes it especially useful for expressing nested document relationships, even though the article itself is not normally one of the principal landmark regions.

How landmarks relate to document hierarchy

Landmarks describe major regions. Headings describe the hierarchy of subjects within those regions. These systems support one another, but they perform different jobs.

Consider a long technical guide:

  • The <main> element identifies where the guide’s primary content begins.
  • The <article> identifies the guide as a self-contained composition.
  • Headings identify the guide’s title and subordinate topics.
  • Sections group related portions of the explanation.
  • A navigation landmark may provide links to major sections.
  • An aside may contain supporting information.

A landmark cannot repair an unclear heading hierarchy, and headings do not replace landmarks. A durable page uses both to communicate its structure from different perspectives.

This layered organization is part of expressing information relationships with semantic HTML. It gives readers multiple ways to orient themselves without requiring the visual design to carry every structural cue.

When multiple landmarks are appropriate

A page may contain more than one landmark of the same type. Multiple navigation landmarks are especially common:

  • Primary navigation
  • Breadcrumb navigation
  • Article navigation
  • Footer navigation

When multiple landmarks share the same type, each should have a useful name so users can distinguish them. The name can come from an associated heading or from an ARIA label when no visible heading is appropriate.

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Article navigation">
  ...
</nav>

The label should describe the navigation region rather than repeat its role. “Primary” is generally more useful than “Primary navigation navigation,” which some assistive technologies may announce redundantly.

Multiple complementary regions or named sections can also be appropriate when each serves a distinct purpose. The goal is not to minimize landmark count at all costs. It is to create a concise, understandable map of the page.

Common HTML landmark mistakes

Using landmarks as visual layout containers

Selecting <aside> because an element appears in a sidebar confuses presentation with meaning. The correct element depends on the content’s relationship to the document, not its coordinates on the screen.

Putting all links inside <nav>

The <nav> element is intended for significant navigation systems. Ordinary links, citation lists, and small collections of related resources do not automatically require a navigation landmark.

Creating multiple active <main> elements

Multiple main regions can make the page’s primary content ambiguous. This sometimes happens when a content management system template supplies a <main> element and a page component inserts another one.

Treating every <section> as a landmark

Sections are valuable for thematic organization, but not every section needs to appear in a user’s landmark list. Excessive named regions can make navigation slower rather than easier.

Adding unnecessary ARIA roles to native HTML

Native HTML already provides landmark semantics in many situations. For example, <main role="main"> is usually redundant. Additional ARIA should solve a specific accessibility need rather than restate semantics the browser already understands.

Using landmarks without meaningful content structure

A page can contain <header>, <main>, and <footer> while still having an unclear heading hierarchy, vague link labels, or poorly grouped content. Landmark elements support good document engineering; they do not replace it.

HTML landmarks in WordPress and other content management systems

In a content management system, landmark structure is often distributed across several files or components. A theme may generate the site header, navigation, main region, article wrapper, sidebar, and footer separately.

This modular construction is useful, but it can hide the final document structure from individual editors and developers. A component may appear correct in isolation while producing duplicate or misplaced landmarks after the complete page is assembled.

Common issues include:

  • A template and page builder both generating a <main> element
  • Several navigation regions receiving no distinguishing names
  • A sidebar being marked as an <aside> even when its content is unrelated
  • Article headers or footers being mistaken for page-level landmarks
  • Generic components introducing named regions throughout the page

Reviewing the final rendered HTML is therefore more informative than reviewing template fragments alone. The browser receives the assembled document, and that complete structure is what users and assistive technologies encounter.

A practical landmark structure

The following example shows one possible structure for an article page. It is not a required template, but it demonstrates how major regions and content hierarchy can work together.

<header>
  <a href="/">Example Site</a>

  <nav aria-label="Primary">
    <ul>
      <li><a href="/guides/">Guides</a></li>
      <li><a href="/glossary/">Glossary</a></li>
    </ul>
  </nav>
</header>

<main id="main-content">
  <article>
    <header>
      <h1>Understanding Document Structure</h1>
      <p>An introduction to meaningful HTML organization.</p>
    </header>

    <nav aria-label="Article navigation">
      <ul>
        <li><a href="#structure">Structure</a></li>
        <li><a href="#landmarks">Landmarks</a></li>
      </ul>
    </nav>

    <section id="structure">
      <h2>Document structure</h2>
      <p>...</p>
    </section>

    <section id="landmarks">
      <h2>Landmark regions</h2>
      <p>...</p>
    </section>

    <aside aria-labelledby="related-heading">
      <h2 id="related-heading">Related concepts</h2>
      <p>...</p>
    </aside>

    <footer>
      <p>Last reviewed July 2026.</p>
    </footer>
  </article>
</main>

<footer>
  <p>&copy; Example Site</p>
</footer>

The two headers and two footers do not all have the same meaning. The outer elements belong to the page, while the nested elements belong to the article. Context establishes their structural scope.

How to review a page’s landmark structure

A useful review begins with the rendered document rather than a preferred template. Ask what each major region means and whether its markup communicates that meaning accurately.

  1. Find the primary content.
    Confirm that the page has a clear main region and that repeated site components sit outside it.
  2. Identify significant navigation systems.
    Use navigation landmarks for meaningful groups of navigational links.
  3. Distinguish repeated landmarks.
    Give multiple navigation or complementary regions concise, descriptive names when needed.
  4. Review contextual nesting.
    Determine whether headers, footers, and asides belong to the page or to a nested article or section.
  5. Check heading structure separately.
    Make sure headings describe the hierarchy of topics rather than relying on landmarks to do that work.
  6. Inspect the accessibility tree.
    Browser accessibility tools can show which regions are exposed as landmarks and what names they receive.
  7. Navigate with a screen reader when possible.
    Landmark navigation can reveal duplicate, unnamed, or excessive regions that are not obvious from source code alone.
  8. Test more than one browser and assistive technology combination.
    Accessibility behavior can vary, particularly in complex or unusual nesting situations.

Landmark review fits naturally within broader web standards quality assurance. It should also be considered alongside keyboard navigation, heading order, link purpose, form labeling, and the principles described in the Web Content Accessibility Guidelines.

Why landmark structure remains useful over time

Landmarks make a document easier to navigate today, but their value also extends into maintenance. Meaningful regions help future developers understand where components belong, how templates are assembled, and which parts of a page serve different purposes.

This reduces dependence on visual assumptions and class names such as .top-area, .left-column, or .bottom-box. Those names may describe one design state, but semantic elements describe relationships that can remain accurate through redesigns.

Clear structure also gives browsers and retrieval systems better source material for interpreting a page. Semantic HTML does not guarantee a particular search or AI retrieval outcome, but it can reduce ambiguity by expressing document relationships directly. This principle is explored further in AI retrieval and semantic HTML.

Frequently asked questions

Does every webpage need every landmark element?

No. Landmark choices should reflect the page’s actual structure. A simple page may not need an <aside>, several navigation regions, or numerous named sections.

Is a <section> always a landmark?

No. A section is a thematic grouping of content. It may be exposed as a region when it has an accessible name, but sections should not be named solely to increase the number of landmarks.

Can a page contain more than one <nav> element?

Yes. A page may have primary, breadcrumb, article, and footer navigation. When several navigation landmarks exist, descriptive labels help users distinguish them.

Should native landmark elements also receive ARIA roles?

Usually not. Native elements such as <main> and <nav> already provide the relevant semantics. ARIA is most useful when it adds necessary information that native HTML does not already communicate.

Landmarks create a meaningful map of the page

HTML landmarks identify the major regions of a document and explain how those regions function. Used carefully, they help people move through a page, help assistive technologies present useful navigation options, and help developers preserve structural clarity as a website evolves.

The durable mental model is simple: landmarks describe purpose, not appearance. They work alongside headings, sections, articles, links, and other semantic elements to create a document whose organization remains understandable beyond its visual design.