By now you can write every kind of element a page needs — headings, text, links, images, forms, tables, lists. Layout is the next level up: instead of asking “what does this one element do?”, you step back and ask “how is the whole page arranged?” Where does the logo go? Which part is the menu? What’s the main content, and what’s off to the side?
That arrangement of big regions — header at the top, navigation, the main content, maybe a sidebar, a footer at the bottom — is what people mean by layout. In this article you’ll learn the standard way to lay out a page with HTML, the page patterns you’ll meet over and over, and — importantly — exactly where HTML’s job stops and CSS takes over. Getting that boundary right is what saves you a lot of confusion later.
What “layout” actually means
Open almost any website and you’ll spot the same skeleton: a strip across the top with a logo and a menu, a wide central column holding the actual content, sometimes a narrower column beside it for extra links or ads, and a bar along the bottom with copyright and contact details. Those regions are the layout.
HTML’s job in all this is to mark which region is which — to declare “this part is the header, this is the navigation, this is the main content.” It does not decide where those regions sit on the screen, how wide they are, or whether the sidebar is on the left or the right. That visual placement is CSS’s job. So when we talk about HTML layout, we’re really talking about structure: writing the right containers, in the right order, with the right meaning.
HTML structures, CSS positions
This is the single most important idea in the whole article. HTML says what each region is; CSS decides where it goes and how big it is. A <header> doesn’t appear at the top because it’s called “header” — it appears wherever your CSS puts it (which is usually the top, because that’s where you’d style it to go). Keep these two jobs separate in your head and layout stops being mysterious.
The standard semantic layout
In the semantic HTML article you met the elements that name a page’s regions: <header>, <nav>, <main>, <aside>, and <footer>. Layout is where they all come together into one coherent page. Here’s the structure you’ll reach for as your default:
<body>
<header>
<h1>ACY Partner Indonesia</h1>
<nav>
<a href="/">Home</a>
<a href="/services">Services</a>
<a href="/contact">Contact</a>
</nav>
</header>
<main>
<article>
<h2>Welcome</h2>
<p>This is the main content of the page.</p>
</article>
</main>
<aside>
<h3>Related</h3>
<ul>
<li><a href="/blog/post-1">A recent post</a></li>
<li><a href="/blog/post-2">Another post</a></li>
</ul>
</aside>
<footer>
<p>© 2026 ACY Partner Indonesia. All rights reserved.</p>
</footer>
</body>Read it top to bottom and the shape of the page is obvious without a single comment: a header with the site title and menu, the main content with an article inside, a sidebar of related links, and a footer. That readability is the whole reason we use these elements instead of a pile of generic <div>s.
Notice the order you write them in matters more than you might expect. The source order is the order the content appears for a screen reader, for a search engine crawling the page, and for anyone reading with CSS turned off. So write your regions in a sensible reading order — header, then main content, then supporting content, then footer — even if CSS later moves the sidebar to the right or the menu into a hamburger.
A quick tour of the layout elements
Each region has a job. You’ve seen these before, but here’s how they fit together specifically as layout building blocks:
| Element | Its role in the layout |
|---|---|
<header> |
The top band — logo, site title, often the main nav |
<nav> |
The primary navigation menu |
<main> |
The one central region holding the page’s unique content |
<article> |
A self-contained chunk inside <main> — a post, a card |
<section> |
A thematic grouping when nothing more specific fits |
<aside> |
Content beside the main flow — a sidebar, related links, an ad |
<footer> |
The bottom band — copyright, contact, secondary links |
A couple of placement notes that trip people up:
<main>appears once per page and wraps only the primary content. The header, nav, and footer live outside it.<aside>doesn’t have to be a visual sidebar. It just means “content tangentially related to the main content.” CSS decides whether it ends up beside, below, or hidden on mobile.<nav>is for major navigation, like the site menu — you don’t wrap every stray link in one.
Common page layout patterns
Most pages are a variation on a small number of patterns. Once you recognise them, you’ll see them everywhere.
Header — main — footer
The simplest useful layout: a header, the content, and a footer. No sidebar. This is great for a blog post, a documentation page, or a landing page — anything where you want the reader focused on one column of content.
<body>
<header>
<h1>My Blog</h1>
<nav>
<a href="/">Home</a>
<a href="/about">About</a>
</nav>
</header>
<main>
<article>
<h2>My First Post</h2>
<p>The full text of the post goes here...</p>
</article>
</main>
<footer>
<p>© 2026 John Doe</p>
</footer>
</body>Two-column: content plus sidebar
Add an <aside> next to the <main> and you’ve got the classic two-column layout — a wide content area with a narrower sidebar for navigation, ads, or related links. Structurally it’s just the previous pattern with one element added:
<body>
<header>...</header>
<main>
<article>
<h2>Article Title</h2>
<p>The main content...</p>
</article>
</main>
<aside>
<h3>In this section</h3>
<ul>
<li><a href="#intro">Introduction</a></li>
<li><a href="#setup">Setup</a></li>
</ul>
</aside>
<footer>...</footer>
</body>Remember: writing <aside> after <main> does not force it to the right or even beside the content. The HTML just declares both regions exist. It’s CSS — using Flexbox or Grid — that lays them side by side. We’ll come back to that boundary in a moment.
Sections within the main content
Inside <main>, longer pages are usually broken into <section> blocks, each with its own heading. A homepage, for example, might stack several themed sections:
<main>
<section>
<h2>What We Do</h2>
<p>...</p>
</section>
<section>
<h2>Our Work</h2>
<p>...</p>
</section>
<section>
<h2>Get in Touch</h2>
<p>...</p>
</section>
</main>Each <section> is a self-contained band of the page. This keeps the markup organised and gives both screen readers and your CSS clear hooks to work with.
Always give a section a heading
A <section> is meant to group content under a heading. If a block has no natural heading, it probably isn’t a section — reach for a plain <div> instead. As a rule of thumb: every <section> should contain a heading (<h2>, <h3>, etc.) that names what it’s about. A section with no heading is usually a sign you’ve used the wrong element.
Where HTML stops and CSS begins
This is the part beginners most often get tangled in, so let’s be very clear about it.
Your HTML layout — the <header>, <main>, <aside>, <footer> — only declares what the regions are and in what order they appear in the document. By itself, that markup renders as a plain top-to-bottom stack: header, then main, then aside, then footer, each one full-width, one below the other. There are no columns, no fixed header, no sidebar-on-the-right. Nothing is positioned.
To turn that stack into a real visual layout — columns side by side, a header that sticks to the top, a sidebar of a fixed width — you use CSS. The two main tools for it are Flexbox and Grid, which is exactly why this section has dedicated articles on CSS Flexbox and CSS Grid. HTML builds the skeleton; those CSS tools arrange the bones.
Don't try to position things with HTML
There’s no HTML attribute for “put this on the right” or “make these two columns.” Old tutorials sometimes show layouts built with <table> elements or stacks of <div>s with align attributes — that approach is long dead. Tables are for tabular data, not page layout. If you find yourself reaching into HTML to move something on the screen, stop: that’s CSS’s job. Your HTML should describe structure and meaning only, and stay completely free of positioning.
So the healthy mental model is a two-step process. Step one (HTML): write your regions in a sensible reading order with the right semantic elements. Step two (CSS): position those regions however the design needs. Keep them separate and each one stays simple. Mix them up and both become a mess.
When to use <div> in a layout
You won’t build a whole layout from semantic elements alone, and that’s fine. The semantic elements name the meaningful regions, but you’ll still need plain containers purely for grouping and styling — and that’s exactly what <div> is for.
A common, perfectly correct pattern is wrapping content in a <div> so CSS has something to grab. For instance, you might centre your page content with a wrapper:
<main>
<div class="container">
<article>
<h2>Article Title</h2>
<p>...</p>
</article>
</div>
</main>That <div class="container"> carries no meaning — it’s a styling hook, used to set a max width and centre the content. There’s no semantic element that means “wrapper for centring,” so a <div> is the right tool. The rule stays the same as always: reach for a semantic element when one fits the meaning, and fall back to <div> for plain grouping when none does. Using a <div> here isn’t sloppy — using it instead of an available <header> or <nav> would be.
A complete layout, start to finish
Let’s pull everything together into one realistic page that uses each region properly:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>ACY Partner Indonesia</title>
</head>
<body>
<header>
<h1>ACY Partner Indonesia</h1>
<nav>
<a href="/">Home</a>
<a href="/services">Services</a>
<a href="/blog">Blog</a>
<a href="/contact">Contact</a>
</nav>
</header>
<main>
<article>
<h2>Building Better Websites</h2>
<p>Welcome to our site. Here's what we've been working on...</p>
</article>
<section>
<h2>Recent Projects</h2>
<p>A look at our latest work.</p>
</section>
</main>
<aside>
<h3>Latest Posts</h3>
<ul>
<li><a href="/blog/post-1">Getting started with HTML</a></li>
<li><a href="/blog/post-2">Why semantics matter</a></li>
</ul>
</aside>
<footer>
<p>© 2026 ACY Partner Indonesia. All rights reserved.</p>
<p>Contact: <a href="mailto:hello@example.com">hello@example.com</a></p>
</footer>
</body>
</html>This is a complete, professional page skeleton. Every region announces what it is, the reading order is sensible, and there isn’t a single positioning trick in sight — because there shouldn’t be. Hand this to a designer (or open your CSS file) and you can arrange it any way you like, on any screen size, without touching the structure. That separation is the payoff for laying things out cleanly.
Wrapping up
Layout is the step where you stop thinking about single elements and start thinking about the page as a whole:
- Layout is the arrangement of a page’s big regions — header, nav, main, aside, footer.
- HTML’s job is to mark which region is which, using semantic elements, in a sensible reading order. It does not position anything.
- The standard layout stacks
<header>,<main>(with<article>/<section>inside),<aside>, and<footer>. - Most pages are variations of a few patterns — header/main/footer, the two-column content-plus-sidebar, and sections inside the main content.
- CSS — Flexbox and Grid — does the actual positioning. Never try to move things around with HTML, and never use
<table>for layout. - Reach for
<div>when you just need a plain container to style, and a semantic element when one fits the meaning.
Get the structure right first, and styling becomes the easy part. With a clean, semantic skeleton, you can build the same page as a single column on a phone or a multi-column dashboard on a desktop — all from CSS, without rewriting a line of your HTML.
