Website Specification Document: The Complete Guide for 2026

Why a website specification document changes everything for your project

A vague quote, endless back-and-forth with your provider, a finished site that no longer resembles the project you imagined at the start: this scenario is far from rare. According to the CHAOS Report from the Standish Group, the world reference on the topic, only 31 % of IT and digital projects finish without going over budget or schedule, 50 % are "challenged" (delays, extra costs, reduced features), and 19 % fail outright. Incomplete or poorly worded requirements are consistently cited among the top causes.

For French small and medium businesses, the stakes are far from anecdotal: according to the France Num barometer, 65 % of small and medium businesses in France had a website in 2025. For those who don't have one yet, or who are planning a redesign, the specification document (in French, the "cahier des charges") is what tips the project onto the right side of these statistics. It isn't an administrative exercise reserved for large companies: it's a steering tool any business owner can use, even without technical skills.

Website specification document: what it actually is

A specification document describes what you want to achieve, not how the developer should build it. That's the key difference with the technical specifications your provider will draft afterward. Your job isn't to choose the technology or the server architecture: it's to clearly express your objectives, your audience, your content and your constraints.

This document serves three concrete purposes. First, it allows you to get genuinely comparable quotes from several agencies, since each one responds to the same document instead of an approximate verbal request. Second, it acts as a reference throughout the project to settle disagreements about scope. Third, it protects your budget: any request that falls outside the initial document becomes an identifiable amendment, rather than silent scope creep.

The 8 essential sections of a website specification document

A good specification document usually runs 6 to 10 well-structured pages. A short, usable document beats a thick file full of vague intentions.

1. Your company and your objectives

Who you are, your market, your direct competitors, and above all what the site should concretely bring you: generating quote requests, selling online, recruiting, reassuring a prospect before a meeting, centralizing contact requests. A measurable objective (number of leads, target conversion rate) is worth more than a vague intention like "having a nice website."

2. Your audience and their journey

Describe who visits your site: individuals or professionals, age range, geographic area, level of familiarity with your brand (do they already know you, or are they discovering you). This profile directly shapes the tone, the site structure and the calls to action.

3. Site structure and page content

List the expected pages (home, services, portfolio, about, contact, blog) and, for each one, the content it should include. A clear, well-organized structure makes navigation easier and helps search engine visibility just as much.

4. Expected features

Contact form, online booking, client area, internal search engine, online payment: list only what you genuinely need. Splitting features into three tiers (essential, desirable in the short term, optional for later) keeps the budget from being weighed down by features that will never actually be used.

5. Visual identity and user experience

Existing brand guidelines or ones to be created, examples of sites you like (and why), brand constraints. If your visual identity isn't finalized yet, it's more efficient to settle it upfront through design mockups rather than reworking it after the site has already been built.

6. Technical requirements, security and accessibility

Domain name (existing or to be registered), hosting, mobile compatibility, expected load time, security certificate, backups. This is also the right place to specify your accessibility requirements if your sector is subject to them: this point, often missing from specification documents published online, avoids costly compliance work after the fact. If your domain name isn't settled yet, our complete guide to choosing one covers the criteria to decide before launching the project.

7. SEO expectations and internal linking

Target keywords, targeted geographic areas, whether or not you want a blog, an internal linking strategy to connect your content together. Without this section, SEO is often handled at the last minute, once the site is delivered, which costs noticeably more than building it in from the design stage.

8. Budget, timeline and validation criteria

Realistic budget range, go-live deadline, validation milestones (mockups, integration, testing). Also specify who, on your team, will validate each stage: a project with no clearly identified point of contact on the client side almost always gets stuck.

Showcase site, e-commerce site, custom platform: what changes

A showcase site focuses on message clarity and converting visitors into contacts or calls. An e-commerce site adds entire sections: catalog management, payment methods, logistics, returns handling, compliance with legal obligations for online sales. A custom platform (client area, intranet, business tool) requires detailing user roles, access rights and integrations with your existing tools (CRM, invoicing). The more complex the project, the more precise the specification document needs to be about use cases, or you risk discovering forgotten requirements mid-development.

The mistakes that make a specification document unusable

The first mistake is documenting everything in exhaustive detail instead of staying precise on the points that actually matter: an overly dense document discourages anyone from reading it. The second is copying a generic template found online without adapting it to your business, which produces a document that looks reassuring on the surface but is unusable in substance. The third, and the most costly, is writing the specification document alone, without consulting the people who will actually use the site day to day (sales team, customer service): their needs then surface too late, once development is already underway, generating exactly the overruns the document was meant to prevent.

Before even starting to write, it can help to take stock of what already exists. If you're starting from a site that's already live, a prior audit helps identify what's working and what needs to change, instead of starting from scratch as a matter of principle.

A simple template to copy and get started

For a quick first draft, an eight-point outline is more than enough:

• Company and objectives: who you are, what the site should bring you
• Audience: who should visit the site and why
• Pages and content: list of pages with a summary of each one's content
• Features: sorted into essential / desirable / optional
• Design: existing guidelines, visual references, things to avoid
• Technical: domain, hosting, security, accessibility
• SEO: keywords, geographic areas, blog or not
• Budget and timeline: range, deadlines, validation milestones

This document doesn't need to be perfect from the first version: it's a starting point you'll refine with your provider during the initial scoping phase. To see what a well-used specification document looks like in practice, a few concrete examples are visible in our portfolio.

Getting an agency to help scope the project

You don't have to write this document alone. Many business owners prefer a scoping workshop with their future provider: the provider asks the right questions, challenges poorly worded needs and turns your answers into a usable specification document, without technical jargon. That's the approach we follow for every website creation project at Majoli: scoping always comes before development, never the other way around. If you're unsure how to proceed, our team is reachable through the contact page to talk it through before you commit to anything.

This scoping stage also has a direct effect on the final budget: the clearer the requirements are upfront, the fewer late changes and amendments come to inflate the invoice. To give you an order of magnitude before you start, our article on estimating the price of a website redesign breaks down the items that make a quote vary.

Frequently asked questions

Do I need to be a developer to write a website specification document?

No. Your job is to clearly express your objectives, your audience and your constraints, not to choose the technology or the technical architecture. It's up to the provider to translate your needs into a suitable technical solution. A specification document written by a non-technical business owner, but precise about what they expect, is often more useful than one packed with poorly understood technical terms.

How long does it take to write a website specification document?

For a standard showcase site, plan for half a day to two days of actual work, spread over one to two weeks to consult the right people internally. For an e-commerce site or a custom platform, you should generally plan for more time to detail the features and user journeys.

Is the specification document different from the quote?

Yes. The specification document describes your needs and objectives; the quote, written in response by the provider, details the proposed services, price and timeline to meet them. A clear specification document lets you get genuinely comparable quotes from several agencies.

Can the specification document be changed during the project?

Yes, but every change should be identified and approved by both parties, usually as a priced amendment. That's precisely the value of the initial document: it lets you distinguish a deliberate evolution of the project from unmanaged scope creep.

Is a specification document useful even for a small showcase site?

Yes, and that's actually where it pays off the most. On a small project, every back-and-forth or misunderstanding weighs proportionally heavier on the budget and the timeline. A well-structured two- to three-page document is more than enough for a showcase site and avoids most misunderstandings.