What a website brief must contain so you do not rebuild later

A good brief does not describe what the site looks like. It describes what must be true once the work is delivered — in a way that can be checked.

The difference is substantial. “Modern, convenient, high-converting” cannot be verified, and can be argued about indefinitely. “Each service page has exactly one first-level heading” is verified in a second, and leaves nothing to argue about.

Below are eleven points that most often fall outside the brief and surface later, when rebuilding costs the most.

Structure and addresses

1. A list of pages with their addresses

Not “a services section” but a list: which pages there will be, at which addresses, and which is reachable from which. This is settled before any design work, because rebuilding the structure after launch costs more than everything else put together.

State separately what happens when a page changes address: a redirect from the old one must remain. Without it, every reshuffle of sections loses the positions and external links you had accumulated.

2. Language versions

If there is more than one language, set the rule: what each version’s address looks like, what happens when the language is switched on an inner page, and what to show when a page is not translated into every language.

The most expensive mistake here is a switcher that always leads to the home page. Someone was reading a service description, changed language and ended up at the beginning. The second: pages in different languages that are not linked to each other by the relevant tags — a search engine treats them as separate sites and sometimes picks the wrong one.

3. Breadcrumbs and nesting

Describe which page belongs to which. This is not only about navigation: the same structure produces the markup a search engine reads. If the nesting exists only in the designer’s head, it will appear in neither.

And specify a mechanism rather than a list: tomorrow a sub-service will appear inside a service, and the chain must build itself without a code change.

Content and who edits it

4. What can be edited without a developer

List it by name: headings, body text, prices, blocks, questions and answers, links, SEO fields. Anything not on that list will only change through a task for the developer — which means it will not change at all.

The check is simple: after delivery, try changing one sentence in three languages yourself. If it worked, the point is met.

5. How repeating blocks are built

Lists, cards, questions and answers must be filled in through fields, not as markup in a text box. The difference shows up in the third month, when the content is being maintained by someone who did not build the site: one stray quotation mark and the block disappears from the page.

6. Who is responsible for the text

Not a technical point, but the one that derails schedules most often. Agree in advance who writes the text, by when, and what happens if it is not ready: the site ships with placeholders, or the work stops.

“The client provides the text” with no date is a deferred conflict. Add the date, and agree what happens if it slips.

7. Empty states

What to show when a section has nothing in it yet, when a search returns nothing, when an article has no tags. This is always forgotten, and always discovered on the live site. Describe it in advance — it costs one line in the brief.

The technical part

8. What counts as done

Spell out what readiness looks like: the site assembled at its working address, filled with real content, checked against the list in the final section. Not “the layouts are built” but “the pages work”.

Agree on access separately. Domain, hosting, admin panel, analytics, code repository — all of it registered to you, not to the contractor. Transferring it later is possible, but it depends on goodwill, and goodwill sometimes ends when the project does.

9. SEO fields and their limits

Page title, description, address, service tags — for every page. Plus the limits: title up to sixty characters, description between seventy and a hundred and fifty-five. It helps if the panel shows a counter and warns when you go over: this cannot be controlled by eye.

The sitemap and the robots file belong here too. They look like a detail until the day you discover half the pages never made it into search.

10. Behaviour on a phone

Not “responsive” but specifics: the minimum tap target, what happens to long headings, how rows of buttons behave when they do not fit — wrap or scroll sideways. And without exception: the page must not scroll horizontally at any width.

11. Accessibility and themes

If a dark theme or font scaling is planned, build it in from the start. Bolting it on later means rewriting the colours in every block. The minimum worth requiring in any case: text-to-background contrast of at least four and a half to one, and the ability to enlarge the text without the layout falling apart.

How to accept the work

The last point, and more important than half of the above: the brief must contain a list of checks, not a description of what you would like.

Phrase them so the answer is yes or no. Not “the page should look good on mobile” but “at 375 pixels wide there is no horizontal scrolling”. Not “we need structured data” but “the validator passes without errors on every page type”. Not “the site should be fast” but specific values and a way to measure them.

A brief like that takes longer to write and is far quicker to accept. And it protects both sides: the contractor knows what is expected, and the client does not expand the requirements as the work goes on.

If you take only one of the eleven points, take this one.

And a final remark about length. A brief for a services website is rarely longer than ten pages, and that is fine: its value is not in detail but in verifiability. A document where half the requirements begin with the word “convenient” will protect neither side, however thick it is.