HTML and CSS — what you're looking at when you open your site's source code

This piece won't teach you to build websites. It exists so that the words in proposals and conversations with a contractor stop being jargon and become things you can actually ask about.

HTML, CSS, semantics, source code, heading structure — each means something specific, and some translate directly into what you'll pay for changes a year from now.

Three layers every website is built from

Every website — whatever it runs on — is made of three layers that do three different jobs.

HTML is content and its structure. It says what's a heading, a paragraph, a list, a link — not how it should look, but what it is. This is the layer read by a search engine and a blind person's screen reader.

CSS is appearance. Colours, spacing, typefaces, grid, behaviour on a small screen. The same HTML content can look completely different depending on the CSS — the whole point of splitting these two layers.

JavaScript is behaviour. Everything that happens after the page loads: reacting to a click, filtering, a calculator, a form submitted without a reload. Covered separately when choosing a frontend technology.

The split has a practical consequence: each layer is a different conversation with a contractor, and the first is mostly your decision, not theirs.

How to see your own site's code — and two things you can check yourself

You don't need to read code to check two things in it that decide whether a site is visible in search.

Open the source code. Right-click your own site and choose "View Page Source", or press Ctrl+U (Option+Cmd+U on a Mac). A tab opens with text — exactly what the server sent the browser, and what a crawler fetches. Don't confuse this with "Inspect", which shows the state after scripts run, a view the crawler doesn't see on its first pass.

First check: is your content there. Press Ctrl+F and search for any sentence from your page. Found it? The content is in the first response. A dozen lines of script references and nothing else? Content only builds in the browser, delaying indexing by days or weeks — the mechanism behind this is covered under Next.js and React.

Second check: does the page have search-engine descriptions. Look for <title> and meta name="description". If the title is identical on every page, says "Home" or isn't there — you're paying for a site that introduces itself poorly in search results. Five seconds' work, and one of the most common things we find in audits.

Check both on a few pages, not just the homepage — the problem usually starts from the second page.

Why headings aren't a matter of font size

This is the most common misunderstanding at the boundary between these layers, and the most expensive one in its consequences.

Headings — H1, H2, H3 — aren't text styles. They're the document's skeleton: H1 the book's title, H2 the chapter titles, H3 the subsections inside them. A search engine reads that hierarchy to understand what a page is about and which part answers which question.

What breaks when they're used for looks. Someone wants text smaller and bold, so they mark it as an H3 — structurally announcing a subsection that doesn't exist. A dozen spots like that, and a page has a skeleton matching nothing.

Who loses out. Not Google — someone using a screen reader, who navigates by jumping between headings the way you skim with your eyes. A list of headings is their table of contents; entries that don't start a section turn moving around the page into guesswork.

The rule is simple, and worth passing on to whoever writes the content: a heading says what a piece of text is. If what you actually want is for it to be smaller or bold, that's CSS's job, not the tag's. The same rule applies to accessibility requirements, which we cover separately in our article on WCAG.

Semantics, or the rest of the things that say "what this is"

Headings are the most visible example, but the same principle applies in a few other places — and getting it wrong costs the same way each time.

A list that isn't a list. Dashes in a paragraph look like a list and aren't one — a screen reader reads one long paragraph, not "list, five items", and a search engine sees continuous text, not an enumeration.

A button that's a link, and vice versa. A link takes you somewhere, a button does something. An element built "the wrong way" often can't be reached from the keyboard, which for some users means it simply doesn't work.

An image's alt text. A single field describing what's in a photo. A screen reader and image search both read it, and anyone whose image failed to load sees it too. This is a field your contractor cannot fill in for you — only you know whether it shows "the team" or "our production hall in Katowice".

The page's language. One piece of code saying the page is in English. Without it, a speech synthesiser can read English text with the wrong accent — and it sounds exactly as bad as you'd imagine.

All four have one thing in common: they cost nothing if done from the start, and they're a tedious fix once bolted onto a finished site. Worth having them in the contract as a requirement, not in a snag list after handover.

Why changing a button's colour is sometimes five minutes and sometimes a week

This is where CSS stops being a technical topic and becomes a line in your budget.

The cheap version. Well-written CSS keeps visual decisions in one place, as named values — primary colour, accent colour, text size, spacing. Every button, heading and border refers to those names instead of repeating the value. Changing the brand colour is then one edit in one file.

The expensive version. A colour hard-coded everywhere — a hundred places in the code, a dozen plugins, content typed in by the editorial team. Changing it means finding every occurrence and checking nothing was missed. Weeks here come from the number of places, not the complexity.

How it looks for us. This site has 164 named values — colours, text sizes, spacing, light and dark variants — defined in a single file, across 315 declarations covering different themes (counted on 11 September 2026). Changing the accent colour across the whole site, dark mode included, is one line.

A question worth asking at handover: "where are the colours and typefaces defined, and how many places would need to change to change the brand colour." An answer of "one file, in variables" means you're paying for code that can be maintained. An evasive answer usually means every future change will be quoted from scratch.

The same goes for typefaces, spacing, and the points where the layout breaks onto a phone. CSS quality isn't visible on screen — it's visible on the invoice for the second change.

What happens when a site hits a phone

Responsiveness shows up in proposals as a single tick box, as if it were a switch. It isn't — it's a set of decisions about what happens to the layout as the screen narrows, and some of those decisions are yours to make.

Three columns sit side by side on a large screen; on a phone they stack, and the question is in what order. Not a technical question: a phone user sees whatever's on top first and may never read the rest. Tables on a narrow screen either collapse, scroll sideways, or stop being readable.

Three things worth checking yourself on your own phone before signing off on a site:

• Can you complete the main action with one thumb — find the offer, open the form, send it.
• Does anything spill off the edge of the screen. If the page scrolls sideways, something's wider than the screen; that's a bug, not a feature.
• Is the text readable without zooming, and can buttons be hit with a finger, not just a cursor.

These are the same checks we run in audits — and they turn out worse than everyone assumes, because a site gets designed on a monitor and viewed on a phone.

What's your decision, and what's the contractor's

The split we propose to clients, and that works for us:

Yours: the text and what it is — what's the page title, what's a section heading, what's a plain paragraph. Image alt text, because only you know what's in a photo and why it's there. Titles and descriptions for search engines, because that's marketing copy, not a technical setting.

Shared: the hierarchy of content on the page and which information matters most — the contractor suggests how to express it, but the order follows from what you're selling.

The contractor's: everything underneath — how the code is organised, where variables live, how the site behaves on a slow connection, how scripts work.

The line sits in one place: if a decision is about the meaning of content, it's yours; if it's about how it's built, it's theirs. Most disputes at handover come from someone crossing that line in one direction or the other.

What you don't need to know how to do

You don't need to know how to write HTML to commission a good website — any more than you pour your own office's foundations. You need to be able to ask four questions and check two things in the source code, which together take a few minutes.

If you'd still like to try it yourself — testing an idea, enjoying understanding things from the inside, or building a hobby site — we have a separate piece for that: how to build a simple website in HTML. It's a different road, and we're not pretending it doesn't exist.

Five words from proposals, translated

Semantic HTML — code where the tags describe what content is, not how it looks. What this whole piece is about.

Validation — checking that code is correctly built. Useful, but it says nothing by itself about a site's quality: code can be formally flawless and useless in practice.

Breakpoint — the screen width at which a layout changes. The fewer of them, and the better chosen, the fewer places a site looks odd.

Design system — a set of named visual decisions, discussed above: colours, spacing, typefaces in one place. In a proposal it signals that a contractor intends to write code that can be maintained.

Minification — stripping everything from a file that's there for a human, not a browser. A standard, not an advantage; if someone lists it as a separate selling point, it's worth asking what else in that proposal is standard.

Four questions for a contractor

1. Is the content in the page's code in the server's first response? Check it yourself, Ctrl+U.
2. Does every page have its own title and search-engine description? Same place, Ctrl+F.
3. Do headings describe the structure of the content, or just font size? A question that saves whoever writes the content a later fix-everything-at-once.
4. Where are colours and typefaces defined? One place or a hundred — that's the price of every future visual change.

Where these numbers come from

• 164 named values across 315 declarations — counted in this site's global stylesheet on 11 September 2026.
• Keyword volumes — UK Keyword Planner pull, 11 September 2026: what is html 2,900, what is css 1,600, what does html stand for 3,600.
• What's deliberately not here — a list of HTML tags. That family of searches is a cheat sheet for someone writing code, not for a company commissioning a site; covering it properly would mean writing documentation that already exists, and is better than anything we'd add.