Converting a Static HTML Template into a Working Blog
Two page types carry a small blog, the post list and the single post, and most static templates already contain rough versions of both. Turning them into a blog is mostly a matter of structure, shared layout and knowing when to automate.
Rework the layout for reading
A typical static template has a landing page with several columns of promotional blocks and one generic inner page. A blog needs something calmer. The list of posts can live with a sidebar on wide screens, but individual articles read best in a single column with generous spacing.
Start by checking that every page has a viewport meta tag. Without it, phones render the desktop layout and shrink it, and no amount of CSS tuning will help. Then look at how the columns are built. If the template uses floats or fixed pixel widths, rebuilding the main layout with CSS Grid or flexbox lets it fall back to one column on narrow screens without any squeezing.
Give the article column a maximum width as well. A limit such as max-width: 68ch stops paragraphs from stretching into tiring, monitor-wide lines.
While you are at it, thin out the sidebar. Long lists of tags, archives and external links pull attention from the writing. A short author note, a few recent posts and the main navigation are usually enough.
Build the post list
The front page of a blog is a list of entries, newest first. Each entry is a self-contained item, which is exactly what the article element is for:
<article class="post-preview">
<h2><a href="/posts/planning-a-layout.html">Planning a layout before you code</a></h2>
<p class="meta">
<time datetime="2026-02-10">February 10, 2026</time>
</p>
<p>Why a quick sketch on paper saves time once the CSS starts.</p>
</article>
The time element carries a machine-readable date in datetime and shows a friendly one to readers. Making the heading itself the link keeps things simple: one clear link per entry instead of a heading link plus several "read more" links that all sound the same to a screen reader user scanning the page.
Build the single post page
An article page puts the post title in the h1, with the date and author near it. Sections of the post use h2, and subsections h3, without skipping levels.
<main>
<article>
<header>
<h1>Planning a layout before you code</h1>
<p class="meta">
<time datetime="2026-02-10">February 10, 2026</time>
</p>
</header>
<p>Opening paragraph.</p>
<figure>
<img src="/images/layout-sketch.jpg" width="1200" height="800"
alt="Pencil sketch of a two column page layout" loading="lazy">
<figcaption>A rough sketch is enough to settle the column structure.</figcaption>
</figure>
<h2>Start with the content</h2>
<p>Supporting paragraph.</p>
</article>
</main>
The figure and figcaption pair keeps an image and its caption together. The width and height attributes let the browser reserve space before the image loads, so the text does not jump. Lazy loading suits images further down an article; leave it off any image that appears at the top of the page.
Because the content is marked up with plain elements, you can style it with a few broad selectors scoped to the article, such as .post p or .post h2, instead of adding a class to every paragraph.
Share the header and footer
The first real pain of a hand-built blog is repetition. Every page carries the same header, menu and footer, and changing one link means editing every file. There are several lightweight ways out.
Server-side includes
Some web servers can insert a shared file into a page as it is served. You keep header.html and footer.html in one place, and each page includes them with a short directive. Whether this is available depends on your host and how the server is configured, so check before relying on it.
A small build step
If the server cannot do it, your computer can. A short script in whatever language you are comfortable with can read each page body, wrap it in the shared header and footer, and write finished HTML files to an output folder that you upload. The published site stays fully static.
Client-side components
You can also define the header as a custom element in JavaScript and drop it into each page. It works, but the menu then depends on a script running successfully, and it can appear a moment after the rest of the page. For something as basic as navigation, assembling the page before upload is the more robust option.
Keep the CSS lean
Older templates tend to carry styles for long-gone browsers. A short modern reset and a few layout rules usually replace a lot of that. Setting box-sizing: border-box on all elements makes widths include padding and borders, which removes a whole class of overflow bugs.
A simple blog rarely needs more than one breakpoint:
.layout {
display: grid;
gap: 2rem;
}
@media (min-width: 48rem) {
.layout {
grid-template-columns: minmax(0, 2fr) minmax(0, 1fr);
}
}
Below 48rem everything stacks in one column. Above it, the post list and sidebar sit side by side. Choose the breakpoint where your own content starts to look cramped rather than copying a device width.
Know when to automate
Hand-written HTML is fine while the blog is small and posts are occasional. As it grows, the chores multiply: adding each post to the list page, updating "recent posts" everywhere, keeping archives and a feed in sync.
A static site generator handles those chores. You write posts as Markdown files with a block of metadata at the top, keep your template's HTML as layout files, and the generator produces the finished pages, lists, tag archives and feeds on each build. The output is still plain HTML and CSS, so it stays fast and simple to host.
Signs it is time to switch:
- adding a post means editing several other files
- you want tag or category pages
- you want a feed that updates on its own
- writing inside HTML tags slows you down
A full content management system makes sense when other people, especially non-technical writers, need to publish. It adds a web-based editor, user accounts and media management, along with a database and software that needs regular updates. For a blog written and maintained by one person, a generator usually gives the better balance of simplicity and convenience.
Frequently asked questions
Can a blog run on plain HTML and CSS files?
Yes. For a small number of posts, each article can be its own HTML file, linked from a list page. The work grows with every post, because the list, navigation and any archive pages are all updated by hand.
How do I share a header and footer without copying them into every file?
Use server-side includes if your host supports them, a small build script that assembles pages before upload, or a static site generator. Each lets you edit the shared parts in one place.
When is it time to move to a static site generator?
When updating lists, archives and navigation by hand starts to take longer than writing the posts. Wanting tag pages or a feed is another strong sign, since generators produce those automatically.