WebsitesTechnology for businessesCompany16 min czas czytania18 668 znaków3173 słowa
A static website in HTML — when it is enough, and what happens when it stops being enough
Four conditions that have to hold at once, what maintenance really costs, and the three thresholds past which a static site stops paying off.
Redakcja Digital VantageYour Partner in Business, Digital Vantage Team · Digital Vantage team is a group of experienced professionals combining expertise in web development, software engineering, DevOps, UX/UI design and digital marketing. Together we carry out projects from concept to implementation - websites, e-commerce stores, dedicated applications and digital strategies.
Our team combines years of experience from technology corporations with the flexibility and immediacy of working in a smaller, close-knit structure. We work in agile methodologies, focus on transparent communication and treat each project as if it were our own business.
The strength of the team is the diversity of perspectives - from systems architecture and infrastructure, frontend and design, to SEO and content marketing strategy. As a result, the client receives a cohesive solution where technology, aesthetics and business goals go hand in hand.
Publikacja
Aktualizacja
A static HTML site is the oldest way of being present online and it is still sometimes the right choice — just for different reasons than the ones usually given. Not because it is "cheaper" — the cost of such a site does not sit in the build. And not because it is "faster" — today's systems can be just as fast.
This text does not teach you to write HTML. It answers the question a company is actually asking: is a static site enough in our particular case, and what happens when it stops being enough.
When static HTML really is enough
"Static" here means exactly one thing: every page is a separate file, and changing anything means opening that file and editing it by hand. No panel, no login, no database. A folder of files on a server.
Four conditions that have to hold at the same time for this to be a good choice:
There are a handful of pages, not dozens. Home, services, about, contact. Maybe two or three service pages. At that scale, editing by hand is workable.
The content does not change. Not "changes rarely" — does not change. A company that corrects its price list once every two years fits this condition. A company that wants to add projects or write news does not, even if today it thinks otherwise.
There is one person who can do it. Somebody who will open a file, change the text between the tags and upload it back without breaking the rest. If that person is an external contractor billed by the hour, the condition is only apparently met — more on that shortly.
You need nothing that remembers. A form that stores submissions, a booking, a customer account, a basket — each of those requires something beyond files. A static site can have a form, but somebody external handles that form anyway.
If any one of those four conditions fails, static HTML is not a saving — it is a deferred cost.
This is the entire skeleton of such a page. We show it not to teach you to write, but so you can see what you are managing in this model:
1<!DOCTYPE html>2<html lang="en">3 <head>4 <meta charset="utf-8">5 <title>Services for business — company name</title>6 </head>7 <body>8 <header>Phone: 000 000 000</header>9 <h1>What we do</h1>10 <p>Service description.</p>11 <footer>Company reg. 00000000 · 2026</footer>12 </body>13</html>
That is one file, meaning one page. The phone number in the header and the registration number in the footer are written into it permanently.
What a static site is not
Three beliefs circulate around this choice and all three lead to a bad decision — two arguing for it, one against.
A static site — what comes in the box and what does not
Own analysis
It is not faster to build. What consumes the time is content, photographs and decisions, not technology. A static site with your copy takes as long as the same site on a system — the difference only appears at the first change after handover.
It is not faster for the visitor by definition. That was a strong argument a decade ago. Today modern systems generate pages in advance and serve finished files in exactly the same way — this site works precisely that way. That is not our invention or our reading: the documentation of the framework we use describes the mode explicitly as serving prerendered, static pages for most requests, with the option of refreshing a single page without rebuilding the entire site (Next.js, "Incremental Static Regeneration"). Being static guarantees nothing on its own: badly prepared images will slow a static site exactly as they slow any other. We describe how to measure it yourself so the result means something in the text on testing.
It is not worse for search engines. That belief runs the other way and is also untrue. A search engine does not care whether a file was written by hand or generated by a system — it reads the same thing. The problem with a static site is different: nobody adds content to it regularly, because in this model every addition costs more.
One thing does work in its favour and is worth knowing: a static site needs no database and no server-side language, so you can put it on the simplest and cheapest hosting you can find. There is also nothing to update for security — no plugins that can go stale. That is a real advantage and the only one that has not evaporated over the last ten years.
What it means in maintenance — the arithmetic nobody does
Here is the whole difference, and it is invisible on handover day.
In a content management system the footer exists once. You change the phone number in it and it changes everywhere, because every page calls it rather than containing it. In the static model the footer is copied into every file. Changing the phone number means opening twelve files and correcting twelve places — or rather twenty-four, because the number is also in the header.
The scale of that mechanism becomes clear when you hold it against something concrete. This site currently has 182 articles and all of them share one header and one footer. Changing the company address is one edit for us. In the static model it would be 182 files — and the point is not that it takes a long time, but that at the hundred and eighty-second file somebody makes a mistake and nobody notices for six months. An honest caveat: we have not run a static HTML site and have no cost measurement of our own from one. This is an illustration of the mechanism's scale, not a quote.
Three operations that cost disproportionately much in this model:
Adding a page. A new file is not enough. It has to be added to the menu in every existing file, because the menu is copied too.
Changing anything shared. The number, the address, the year in the footer, a new link to the privacy policy. Every such small change multiplies by the number of files.
Changing the appearance. If the styles are written into the files rather than into a separate sheet, repainting the buttons means going through the whole site. If they are in a separate sheet, it is one edit — and that is exactly the thing worth checking before you buy a template.
The practical conclusion: if that one person who "can do it" is a contractor billed by the hour, a static site is not cheaper to maintain — it is only cheaper to build, and you hand the difference back at every correction. The arithmetic works when you genuinely leave the site alone.
A bought template — what you get and what you do not
Ready-made HTML templates are a sensible shortcut and it is worth knowing what is in the box.
You are buying files, not a website. A template is a set of HTML files, a stylesheet, scripts and sample images. It contains none of your content, none of your photographs and nobody's admin panel. The work left after the purchase — putting your own copy and images into every page — is usually larger than the work the template saved.
Check where the styles are. If the template keeps appearance in a separate sheet, later changes are cheap. If the styles are written directly into the tags on every page, you have bought something that costs as much to change as to write from scratch. That is the one thing worth looking at before buying, even without knowing any code — just ask the developer or the seller outright.
Check the licence. Some templates may be used on one site, some require you to keep a link to the author, some forbid resale. Three sentences to read, and the difference can matter.
Check what "responsive" means in this particular template. Almost every one describes itself that way, and the difference can be large: some rebuild the layout on a phone sensibly, others merely shrink everything proportionally, leaving the text unreadable and the buttons too small to hit with a thumb. Checking takes a minute — open the template demo on your own phone and walk the path to contact.
Count the work after the purchase. A template usually has five to eight finished pages with sample content. Turning it into your site means: inserting the copy, replacing every image, removing sections you do not need, fixing the menu, adding registration details and a privacy policy. That is several to a dozen hours of somebody's work, and it is worth pricing before the purchase rather than after.
The demo photographs are not yours. A template looks good because it has good photographs — and those are almost never covered by the licence. The site looks different once your own material goes in, and it is better to assume that up front than to discover it after launch.
And one thing not to do. Older templates and older tutorials suggest a contact form built on action="mailto:". That does not work for most visitors: it requires a mail client configured on their device, and on a phone or in webmail there usually is not one. The effect is worse than having no form — the visitor clicks "send", nothing happens, and you do not know anybody tried. A form that actually arrives needs a server-side service, and that is an item to settle before choosing hosting.
Three cases where this is the natural choice
The conditions in the earlier section sound abstract, so it is worth holding them against something concrete. Three situations in which a static site is not a compromise but an accurate fit:
A portfolio. A photographer, an architect, a designer, a joiner. The content is the work rather than the copy; it changes rarely and in whole batches rather than a sentence at a time. There is no price list to correct and no news section nobody will write. There is one risk and it is worth knowing in advance: if the work accumulates monthly, you come back to the first threshold faster than you expect.
A brochure site for a company that sells elsewhere. A workshop, a clinic, a local service — clients call or walk in anyway, and the site is there to confirm the company exists, show the scope and give the address. Four pages, zero changes in a year. This is the case where a static site wins most clearly, because all four conditions hold at once.
A one-off site. A conference, a competition, a seasonal campaign. It is meant to live three months and disappear. Building a content management system for that is work that will not have time to pay for itself.
And the inverse, so the boundary is sharp: a shop, a blog, anything with a login, and any site somebody is meant to add to regularly — there static HTML is a choice that will have to be undone, and undoing it costs more than doing it differently in the first place.
Three thresholds past which HTML stops paying off
These are not intuition-based thresholds. Each can be checked in five minutes.
Threshold one: ten pages. Below that, editing shared elements by hand is tedious but workable. Above it, errors start multiplying — and the problem is not the number of files but that nobody remembers which of them have already been corrected.
Threshold two: changes more often than quarterly. If somebody in the company wants to change something monthly, the static model means somebody else does it for them every month. Multiply that hour by twelve and compare it with the annual cost of a system that lets you do it yourself.
Threshold three: a second person. The moment somebody else is meant to change the content — a second person in the company, an intern, an agency — static HTML stops being a technical choice and becomes an organisational bottleneck. You cannot grant somebody access to "just the service descriptions"; you can give access to all the files or to none.
Three thresholds past which static HTML stops paying off
Own analysis
How to work this out for yourself before anyone issues a quote: list the pages the site should have in a year, not the ones it should have on launch day — that is the most common mistake in this arithmetic. Then count how many times in the last year you wanted to change something on your current site and did not, because it was too much trouble. If that happened more than twice, threshold two has already been crossed, whatever the publishing calendar says.
Crossing one threshold settles nothing. Crossing two means you are counting a saving that is no longer there.
Do you have to be able to code
The question comes back regularly in this conversation and the answer is narrower than it seems.
To write a site from scratch — yes. Not at a developer's level, but enough to understand what each tag does and why the browser reacts as it does. That is a dozen or so hours of learning and thousands of hours of practice if the result is to look professional.
To maintain a finished site — surprisingly little. If somebody built it properly, the daily work comes down to opening a file and changing the text between the tags, exactly as in a word processor. Somebody who has never seen code can, after an hour of instruction, manage to correct a phone number or a service description.
The boundary runs in one place and is worth knowing: changing content is safe, changing structure is not. Correcting a sentence between tags will break nothing. Adding a new section, moving a block or pasting something copied from another site can break the layout, and the cause is often invisible to the eye — a missing closing tag looks innocent and breaks everything below it.
The practical conclusion if you go this route: ask the developer for two things at handover. First, a copy of all the files somewhere you have access to — because a site without a copy is a site that one mistake deletes. Second, half an hour of being shown what may be touched and what may not. That is the cheapest training you will buy in this model, and nobody usually asks for it.
What to do when a threshold is crossed
This is the question nobody asks during the build, and it comes anyway — so it is worth knowing the answer early, because several decisions at the start then look different.
Moving off a static site is one of the easier migrations. There is no database to transfer, no plugins to recreate, no user accounts. There is text, images and a URL structure. That is less than most migrations involve — and it is a real, rarely mentioned advantage of this model.
What moves by itself: copy and images. They have to be rewritten or copied into the new system, but nothing is lost and nothing needs converting.
What has to be recreated: the appearance. An HTML template does not translate into any system automatically. If you want the site to look the same, somebody has to rebuild that appearance in the new tool — and that is usually the largest line in the cost of the move.
What must not be lost: the addresses. Every page has a URL, and if the site was in search results those URLs carry value. In the new system the structure usually looks different and every old address needs a redirect to its new equivalent. Redirecting everything to the home page is a false solution — a search engine reads it as content removal rather than as a move. We describe how to plan this in the text on migration.
One decision at the start that saves a week later: keep the styles in a separate sheet rather than in the tags, and name the files the way you want the addresses to read — services.html, not page2.html. The first makes a change of appearance one edit instead of a walk through the whole site. The second means that after a move the addresses can be mapped one to one, instead of being reconstructed from memory.
What this text does not settle
What it costs. The arithmetic has two parts and a static site changes the proportion between them, not the total. The full breakdown is in the cost section.
Whether it can be done entirely free. It can, and we describe it separately, including the boundary where free ends.
Whether clicking beats writing. A subscription builder solves exactly the problem the maintenance section describes — at a price worth knowing in advance: website builders.
Which system, if not HTML. Choosing a family of content management system starts from the question of who changes what — and it has its own text.
How the whole project runs. Regardless of technology: from the first four decisions to launch.
Where these numbers come from
- 182 articles on this site — our own content index, as at 14 September 2026. Used as an illustration of the scale of the shared-elements mechanism, not as a measurement of what maintaining a static site costs; we have not run one and have no data from it.
- The three thresholds — our observation from implementations, presented as an observation. We have not studied it numerically and we give no percentages or medians.
- Static generation in modern systems — not our claim but a description from the documentation of the tool this site runs on: Next.js, "Incremental Static Regeneration". We cite it because the argument that "a static site is faster" rests on an assumption that documentation invalidates.
- The `action="mailto:"` form — the limitation follows from how the mechanism itself works: the browser hands the content to the default mail client, and if there is none, nothing happens. It is not a matter of the browser or the provider.
Not sure which side of these thresholds you are on?
A quarter of an hour on how many pages you genuinely need and who would be changing them — including the answer "static is enough", if that is what the conversation produces.
Related Posts
- Website design process — the order in which changing your mind is still free
How a website actually gets built, stage by stage. Find the stage you are in and skip the rest — plus the three things that stall projects.
- 1.Wireframe — what the sketch settles, and what code can no longer undo
What a wireframe decides, why the same change costs thirty times more once built, and how to test one with five people before you approve it.
- 2.The website brief — six things an agency has to guess without
Six things an agency has to guess without, and what each omission costs. Plus the most common mistake: writing solutions instead of the problem.
- 3.How to build a website — four decisions, the layout, and what really stretches a project
What to settle before anyone designs a screen, what has to be on the page, how long it really takes, and what happens on launch day.
- 1.
About the Team
Digital Vantage Team
Your Partner in Business, Digital Vantage Team
Digital Vantage team is a group of experienced professionals combining expertise in web development, software engineering, DevOps, UX/UI design and digital marketing. Together we carry out projects from concept to implementation - websites, e-commerce stores, dedicated applications and digital strategies. Our team combines years of experience from technology corporations with the flexibility and immediacy of working in a smaller, close-knit structure. We work in agile methodologies, focus on transparent communication and treat each project as if it were our own business. The strength of the team is the diversity of perspectives - from systems architecture and infrastructure, frontend and design, to SEO and content marketing strategy. As a result, the client receives a cohesive solution where technology, aesthetics and business goals go hand in hand.
