Two web professionals discussing a webpage layout beside a monitor

The basic shape of an HTML document

The WHATWG HTML Standard models the root html element as containing a head followed by a body. The browser parser can recover from incomplete or unusual markup, but a predictable document shape gives people and tools a clearer starting point.

<!doctype html>\n<html lang='en'>\n  <head>\n    <meta charset='utf-8'>\n    <meta name='viewport' content='width=device-width, initial-scale=1'>\n    <title>Trail conditions | Example Park</title>\n  </head>\n  <body>\n    <header>...</header>\n    <main>...</main>\n    <footer>...</footer>\n  </body>\n</html>

This is a useful starting shape, not a checklist that requires every possible element. A small document may have a very simple body. A larger page may contain several articles, navigation regions, forms, or sections. The important question is whether each element truthfully represents the content it contains.

What belongs in the head

The head is a collection of metadata for the document. It is not the place for the article's visible paragraphs or the page's primary controls. A typical head contains the document title, character encoding, viewport information, stylesheet links, scripts, canonical information, and metadata used by search or social platforms.

  • Use <title> for the document title. It is different from the visible H1.
  • Declare the character encoding early enough for the document to be decoded consistently.
  • Use the viewport meta element when the page needs to communicate its intended mobile layout.
  • Put stylesheet links, scripts, canonical links, and other metadata in the head when their roles require document-level metadata or resource loading.
  • Keep visible content such as headings, paragraphs, navigation links, forms, and images in the body.

The Standard describes head as document metadata and requires a title in most ordinary documents. A title tag can describe the document without appearing as a visible heading, while an H1 can name the main content without replacing the title tag.

What belongs in the body

The body represents the document's contents. Its children can include introductory content, navigation, main content, articles, sections, complementary material, forms, media, and footer content. Choose the element based on meaning, not on the size or position you want to give it in CSS.

<body>\n  <header>\n    <a href='/'>Example Park</a>\n    <nav aria-label='Primary'>...</nav>\n  </header>\n  <main>\n    <article>\n      <h1>Trail conditions</h1>\n      <p>Conditions for the north loop.</p>\n    </article>\n  </main>\n  <footer>Contact details</footer>\n</body>

The W3C WAI page-regions tutorial explains how common elements such as header, nav, main, aside, and footer can expose the page's regions to assistive technologies. These elements help describe structure, but they do not repair incorrect labels, missing keyboard behavior, or inaccessible custom controls by themselves.

Use landmarks for the page's major regions

Landmarks are the large regions a person may want to navigate directly. Use nav for a major navigation block, main for the dominant content, aside for related but separate material, and header or footer for introductory or closing content belonging to the page or a section. If a page has multiple regions of the same type, give them useful accessible labels where the distinction matters.

  • <header>: introductory or navigational aids for the page or a section.
  • <nav>: a major group of links to other pages or parts of the current page.
  • <main>: the dominant content of the document; normally one main region is enough.
  • <article>: a self-contained composition that could stand on its own, such as a post or comment.
  • <section>: a thematic grouping that normally has a heading and belongs in the document's structure.
  • <aside>: content that is tangentially related and can be considered separate.
  • <footer>: closing information for the page or its nearest sectioning ancestor.

Do not add landmarks simply to make the markup look advanced. A short group of footer links does not need to become a second navigation region if a footer already communicates its purpose. For the accessibility reasoning behind labels and landmark navigation, see W3C's landmark regions guidance.

Build a heading hierarchy readers can follow

Headings name sections and let readers scan or navigate the content. Use an H1 for the page's primary topic, H2 for major sections, and lower levels for real subsections. A heading level is not a font-size control. Use CSS for appearance and choose the heading rank that matches the content hierarchy.

<h1>Beginner bicycle maintenance</h1>\n<h2>Before you start</h2>\n<h2>Clean the drivetrain</h2>\n<h3>Choose a degreaser</h3>\n<h3>Dry and lubricate the chain</h3>\n<h2>When to visit a mechanic</h2>

The outline above has one main topic, three peer sections, and two subsections inside one H2. A jump such as H2 directly to H4 is a reason to inspect the content relationship, not proof of a ranking penalty. Use How to Check HTML Heading Structure for a focused source-order workflow.

Match native elements to the content

Semantic structure continues below the page landmarks. Use a native element when it accurately describes the content or interaction. Native semantics give browsers and assistive technology information that a class name or visual styling does not automatically provide.

  • Use <p> for a paragraph, not a heading chosen only because it is bold.
  • Use <ul> or <ol> for a real list, and <li> for each item.
  • Use <table> for two-dimensional data with appropriate row and column headers.
  • Use <form> and associated <label> elements for user input.
  • Use a real <a href='...'> for navigation and a real <button> for an action.
  • Use <figure> and <figcaption> when an illustration or diagram has a caption that belongs with it.

A div is not wrong. It is a generic container for cases where no more specific element describes the grouping. The problem is using generic containers to imitate a button, link, heading, list, or landmark while leaving the expected semantics and keyboard behavior to be rebuilt manually.

Inspect returned markup without confusing it with the DOM

When you inspect a deployed page, start with the returned HTML if your question is about what the server delivered. Use View Source to read the response, or HTML Viewer when you already have markup and want to preview it. The browser may then parse, repair, hide, replace, or extend that structure. MDN's DOM documentation covers the live document interface that scripts can modify.

  • Returned source answers: Was this element or attribute in the response you retrieved?
  • The live DOM answers: What document does this browser have after parsing and runtime changes?
  • A rendered inspection answers: What is currently visible and interactive in this session?
  • A search-engine or accessibility test answers a different question and should not be inferred from a source-only snapshot.

Use a repeatable document-structure review

A structure review is more useful when it ends in a concrete decision. Work from the outer document toward the content details, and keep an unusual pattern as a review signal until the surrounding markup explains it.

  • Confirm the document has an understandable root, language declaration, head, and body.
  • Check that the title and metadata describe the document without being mistaken for visible content.
  • Identify the main region, navigation, article, sections, complementary content, and footer where they genuinely exist.
  • Read the H1-H6 outline in order and check that labels match the sections that follow.
  • Check interactive elements, lists, tables, forms, and images for their native roles and required context.
  • Compare returned source with the live DOM when JavaScript or the browser session can change the answer.
  • Use HTML Extractor for readable text and a focused checker when one element needs a deeper review.

This workflow helps you find structural evidence without turning a single unusual tag into a universal SEO diagnosis. For a semantic-element decision guide, continue with Semantic HTML for SEO and Accessibility.

Frequently asked questions

What is the difference between head and body?

The head contains document metadata and resource information; the body contains the document's page content and controls. A title tag belongs to the head, while a visible H1 belongs in the body.

Does the title tag replace the H1?

No. The title describes the document in metadata contexts such as a browser tab, while the H1 identifies the main topic in the page content. They can be related without being identical.

Is a section the same as a div?

No. A section represents a thematic grouping that normally has a heading and belongs in the document structure. A div is a generic container used when no more specific semantic element fits.

Does semantic HTML guarantee better rankings?

No. Meaningful markup can make a document easier to understand and maintain, but changing containers alone does not guarantee rankings, indexing, or a search feature. Evaluate content, links, rendering, accessibility, and technical delivery separately.

Can I inspect a document I already have?

Yes. Paste it into HTML Viewer to preview the markup, or use HTML Extractor when the immediate task is reading its text. Keep the original file so your interpretation can be checked against the input.

Sources

Continue exploring

Editorial note

SolViewer develops the tools linked in this guide. They are included when they help with the next practical step; they do not replace browser testing, official documentation, or professional review where those are needed.