Semantic HTML: How to Structure a Web Page Clearly
Learn what semantic HTML means, why it helps readers and assistive tools, and how to choose the right elements for a clear, usable web page.
Semantic HTML uses elements that describe what their content is for. A <nav> element identifies a group of navigation links. A <button> tells the browser that an item can be pressed. These choices make a page easier to understand for people, browsers, and assistive tools.
If you are building or updating a website, semantic HTML is a practical way to improve its structure without changing how it looks. You can often make a page clearer by replacing general-purpose containers with elements that describe their role. This guide explains how to choose those elements, how to use them well, and what mistakes to avoid.
What is semantic HTML?
HTML is the language used to describe the parts of a web page. Each element has a name and a purpose. Semantic HTML means choosing an element based on the meaning of the content, not just on how you want it to appear.
For example, a heading should usually use a heading element such as <h2>, rather than a paragraph made large with a visual style. A list of steps should use list elements, rather than several paragraphs with numbers typed in by hand. The HTML then tells more than one story: it describes what people see and how the parts relate to each other.
By contrast, <div> and <span> are general-purpose containers. They are useful when you need to group content or apply a visual style, but they do not explain what that content means by themselves. A page made mostly of these containers can still work, but its structure may be harder for tools and people to recognize.
Why semantic HTML matters
Clear structure helps people scan a page and find the part they need. It also gives screen readers and other assistive tools useful information about headings, lists, controls, and major page areas. A screen reader is software that reads page content aloud or presents it in another format.
Semantic elements also make code easier for developers to understand and update. When a section is marked as navigation or the main content, its role is easier to spot than if it is only a container with a vague name. This can help when a site grows or when another person needs to work on it.
Well-structured HTML may also help search tools understand the parts of a page. It does not guarantee better search placement, and a semantic tag is not a substitute for useful content. Its main value is that it describes the page accurately.
Common semantic elements and when to use them
Choose elements by asking what the content does. The following table covers several elements you are likely to use on a typical page.
| Element | Use it for | Keep in mind |
|---|---|---|
| <header> | Introductory content for a page or a section, such as a title or opening details. | A page can have a header, and a section or article can have its own header too. |
| <nav> | A major group of links used to move around a site or page. | Not every group of links needs to be marked as navigation. |
| <main> | The central, unique content of the page. | Usually use one visible main area per page, and do not place it inside another main area. |
| <article> | A piece of content that can make sense on its own, such as a post or news story. | Use it when the content is a self-contained item, not just because a section looks like a card. |
| <section> | A themed group of related content, often with its own heading. | Do not use it as a generic wrapper when a plain container is enough. |
| <aside> | Related but secondary content, such as a sidebar note. | The content should be related to the page or nearby section, but not part of its main flow. |
| <footer> | Closing or supporting information for a page or section. | A page or an article may each have a footer with information that fits that area. |
These elements describe broad areas, sometimes called landmarks. Assistive tools can use landmarks to help people move between the main parts of a page. A good landmark plan is simple: mark the parts that truly have a clear role, and avoid adding extra labels that do not help.
How to structure a page with semantic HTML
Start with the purpose of the page. A basic article page might have a site header, a navigation area, the main article, a related-content area, and a page footer. The exact layout can change, but the HTML should still describe the job of each part.
-
Identify the main content. Ask what a visitor came to this page to read, watch, or do. That content belongs in the main area.
-
Group the supporting parts. Put major site links in navigation. Put extra, related notes in an aside if they are separate from the main flow.
-
Choose the right content element. Use an article for a complete post or other self-contained item. Use a section for a themed group within a larger page.
-
Add headings that describe each part. Headings help people scan and let assistive tools offer a list of sections.
-
Check the finished page. Read the headings on their own and see whether they make a useful outline.
For example, an article page could be described as a header containing the site name, a navigation area with key links, a main area containing an article, and a footer containing site details. If the article has a related reading list beside it, that list may fit in an aside. Its visual position does not decide the element; its purpose does.
Think of a semantic element as a label for the content inside it. If you cannot explain why a label fits, a plain <div> may be more honest than choosing a semantic element just because it sounds more advanced.
Use headings to create a clear outline
Headings are among the most useful semantic elements. They help readers see what a page covers and jump to a section that matters to them. Use heading levels to show how ideas fit together, not to control the size or weight of the text.
A page usually has one main title, followed by major sections marked with <h2>. A subsection under one of those sections can use <h3>. If that subsection has a smaller part of its own, an <h4> may fit. Keep the order logical rather than skipping levels just to get a smaller-looking heading.
For example, a guide might have a page title, then an “Equipment” section and a “Steps” section. Under “Steps,” headings could name individual stages. If the heading text is only there to make a line look bold, consider whether it should be ordinary text with visual emphasis instead.
Quick check: Read only the headings from top to bottom. They should give someone a useful sense of the page and its main sections.
Make links and buttons say what they do
Links and buttons may look similar, but they have different jobs. A link takes someone to another location, such as a different page or a specific place on the current page. A button performs an action, such as opening a menu or sending a search request. Use the matching element so browsers and assistive tools can identify its purpose.
Write link text that makes sense on its own. “Read the return policy” tells a reader more than “click here.” This matters when someone scans a list of links outside the surrounding paragraph. If several links say only “learn more,” it may be hard to tell where each one leads.
A visual shape is not enough to create a working control. If you make a <div> look like a button, it may not behave like one for someone using a keyboard. Start with the built-in button element when the control performs an action. Then add styles to change its appearance while keeping its built-in role.
Use lists, images, and tables for their real purpose
If items belong together as a list, use list elements. Use an ordered list when the order matters, such as a recipe or a set of steps. Use an unordered list when the order does not matter, such as a set of features. This helps tools describe the group as a list instead of treating each item as unrelated text.
Images need care too. When an image adds important information, its text description should explain that information in context. When an image is only decoration and repeats nothing useful, it may not need a spoken description. The right choice depends on what the image contributes, not simply what it shows.
Use tables for information that belongs in rows and columns, such as a schedule or a comparison of features. A table should not be used just to arrange page sections visually. Clear column headings help readers understand what each cell means.
Common semantic HTML mistakes
- Using section for every container. A section is a themed group of content, not a replacement for every div. It often makes sense to give a section a heading.
- Choosing elements for their look. A heading element means “heading,” not “large text.” A blockquote means quoted material, not “text I want indented.”
- Marking every link group as navigation. Use nav for major navigation areas. A few links in a sentence or a small list of related posts may not need that role.
- Using article when content is not standalone. A small visual card is not automatically an article. Ask whether the item would still make sense if it appeared by itself.
- Adding landmarks without a plan. Too many named areas can make a page harder to explore. Keep the structure clear and useful.
- Forgetting that structure and appearance are different. HTML describes meaning. Visual styles control things like color, spacing, and font size. You can change the appearance without changing the meaning.
When you are unsure, choose the element that best matches the content’s purpose. If no specific element fits, using a general container is fine. Semantic HTML is about accurate choices, not using the largest possible number of special tags.
A practical review checklist
Before publishing a page, take a few minutes to review its structure. You do not need to memorize every HTML element. A small set of questions can catch many common problems.
- Is the main content easy to identify?
- Do headings describe the content that follows them?
- Do heading levels follow a sensible order?
- Are major site or page links grouped clearly?
- Do links explain where they go, and do buttons perform actions?
- Are lists and tables used for grouped or tabular information?
- Does each image have a suitable text alternative, or is it clearly decorative?
- Have you avoided adding semantic elements only to change the visual layout?
It also helps to navigate the page without relying only on its visual design. Try moving through headings, links, and controls with a keyboard or an assistive tool if one is available. This will not find every issue, but it can reveal places where the page’s structure is unclear.
Frequently asked questions
Does semantic HTML change how a page looks?
Not by itself in a reliable way. Some elements may have a default appearance in a browser, but the main purpose of semantic HTML is to describe content. Visual styles can change how elements look without changing their meaning.
Can I use div and span on a semantic page?
Yes. They are useful when you need a container for grouping or visual styling and no more specific element fits. A semantic page does not need to avoid them completely.
Does semantic HTML improve accessibility?
It can make a page easier for assistive tools to understand and navigate, especially when you use headings, landmarks, lists, links, and controls correctly. It is one part of accessibility, not a complete solution. People still need clear text, useful descriptions, keyboard access, and working controls.
Do I need a section element for every part of an article?
No. Use a section when you are grouping related content as a distinct theme. A heading followed by a few paragraphs may not need an extra wrapper. Choose the simplest structure that clearly describes the content.
Build meaning into the page from the start
Semantic HTML is a habit of describing what content does, rather than relying on appearance alone. Use headings for structure, links for moving between places, buttons for actions, and page landmarks for major areas. Choose sections and articles only when their meaning fits.
These choices help people scan a page, support assistive tools, and make code easier to maintain. Begin with the purpose of each part, then choose the element that tells the truth about it. A clear, accurate structure is more useful than a complicated one.