DIRECT ANSWER
HTML is not outdated. Every web page a browser displays is delivered as HTML, and the standard is still maintained. What varies is how the HTML is produced: saved as files in advance, assembled by a server for each visit, or built in the browser by JavaScript. Those choices change speed, search visibility and who can edit the site, not whether HTML is used.
Key terms
- HTML
- The markup language that describes a web page's structure and content, such as headings, paragraphs, links, images and forms. Browsers read it and display the page.
- Static site
- A website whose pages are prepared in advance and saved as files, so the server returns the same file to every visitor who asks for that address.
- Dynamic site
- A website whose server builds some pages when a visitor asks for them, usually by combining stored data with templates.
- Static site generator
- Software that builds a static website from source material such as templates and text, and outputs finished HTML, CSS and JavaScript files.
What the browser receives
When someone opens a web page, the browser receives HTML. The HTML Standard describes HTML as the web's foundational markup language, one that began as a way to structure scientific papers and has been adapted to many kinds of documents and applications [1]. It is a living standard, continuously maintained rather than frozen in a fixed version, and the edition for web developers was updated on the day this entry was written [1].
So the question "should we build on HTML?" has a short answer. Every website is built on HTML, including sites made with WordPress, Squarespace, Wix, Shopify and custom code. The browser receives HTML in each case. The difference lies in where that HTML comes from and how much the server decides about its content [2].
A business owner who says they would never build on HTML again is usually reacting to something else: a site that was hard to edit, a developer who was hard to reach, or a design that looked dated. Those are real problems. They come from how a site was built and maintained, not from the markup language.
Three ways the HTML gets to the browser
A static site returns the same prepared file for a given address. The server finds the file and sends it [2]. A dynamic site builds some responses when the request arrives. Server-side code reads data from a database, fills in a template and returns the generated HTML [2]. A third approach builds the page in the browser. The server sends a small amount of HTML and a larger amount of JavaScript, and the JavaScript assembles the page [4].
| Approach | Where the HTML is made | When it is made | Typical strength | Typical cost |
|---|---|---|---|---|
| Static files | In advance, on a build computer | Before launch and at each update | Fast, simple to host, few moving parts [4] | Changing content means rebuilding and republishing the files [4] |
| Server-built pages (a CMS such as WordPress) | On the server | Each time a page is requested | Editors change content in a dashboard; large catalogs and logins are practical [2] | Software, plugins and a database that need ongoing updates and backups |
| Browser-built pages (JavaScript apps) | In the visitor's browser | After the page loads | Rich interaction inside an application [4] | More JavaScript to download; search engines must run it to see the content [4][5] |
Many sites mix the approaches, serving prepared pages where possible and generating pages on demand where content must be live or personal [4].
What this means for speed and search
Prepared HTML responds quickly and consistently, can be cached close to the visitor, and needs little JavaScript before a page is usable [4]. For a service business whose pages change a few times a year, that suits the work.
Search is the other practical difference. Google crawls a page, runs its JavaScript in a separate rendering step, and indexes what it finds in the rendered result [5]. Content that is already in the initial HTML is the simplest case. Pages whose real content only appears after JavaScript runs depend on that extra step, and Google recommends server-side or pre-rendering for that reason, partly because not every crawler runs JavaScript [5]. Speed measures such as those in Core Web Vitals follow from the same choices.
Applications
A plumbing company deciding what to ask a developer
Illustrative example. A plumbing company owner wants a site that lists services, shows the service area and takes quote requests. Pages change twice a year, but a phone number and a few prices change more often. A static site fits the pages. The owner's real question is how the phone number and prices get changed, which is an editing question, covered in who edits your website.
A shop with weekly inventory
Illustrative example. A boutique adds products every week and takes orders. Its stock changes daily, which suits a platform that stores products in a database and builds pages from templates [2]. A hand-built static site would be the wrong tool for that part of the business. The shop can still keep its guides and service pages as prepared pages.
Limits and edge cases
- "Static" does not mean "no interactivity." A static site can include forms, calculators and booking links that call outside services. The pages themselves are prepared in advance.
- A static site is not automatically better. It trades a dashboard for simplicity. The trade-off is covered in the next entry.
- Frameworks blur the line. A site can be built with tools that produce static files from templates and content, which is what a static site generator does [3]. The visitor sees ordinary pages either way.
- Search results depend on more than technology. Prepared HTML removes one source of trouble. It does not replace useful content, clear pathways or accurate facts.
How So It Sticks applies this
Our builds are delivered as standard website files that run on ordinary hosting, and the full set goes to the client at handoff, as our hosting and handoff terms describe. We choose that approach because most service businesses need fast pages, few moving parts and a site they own outright. If your business needs a database-driven catalog or customer logins, we say so before scoping. Start a Project Brief and tell us what your site has to do.
Sources and method
The comparison table and examples are So It Sticks editorial frameworks. The examples are illustrative and describe no real business. Each linked source supports only the statements numbered beside it. Sources verified October 16, 2026.