Website requirements document template

Last updated October 8, 2026

What should a website requirements document include?

A website requirements document template should cover the site's purpose, its audience, a sitemap with page-by-page requirements, content, forms and integrations, SEO, hosting, what is out of scope, and open questions. Fill it in from the client conversation, describe each page separately, and only add features like login or payments if the client asked for them. The free template is below.

Most website projects go wrong in the same place: a vague brief that says the client wants a modern site with a few pages, and a fixed price based on that. A website requirements document replaces the vague brief with a list of pages, what goes on each one, and what is not included.

This template is built for client work. It follows the order of a typical client discovery questionnaire, so you can fill it straight from the call, and it ends with a sign-off line so it can serve as the agreed scope.

The website requirements template

Copy the template below into a document and replace everything in angle brackets. Add a block under section 4 for every page in the sitemap.

website-requirements.md

# Website requirements: <site name>
Client: <company>   Prepared by: <you>   Date: <date>   Version: <1.0>

## 1. Purpose
<What the website is for, in one or two sentences.>
Main goal: <for example, get booking enquiries from local customers>
How we will measure it: <for example, enquiries per month>

## 2. Audience
- <Primary audience>: <what they come to the site to do>
- <Secondary audience>: <what they come to the site to do>

## 3. Sitemap
- Home
- <Page>
- <Page>
  - <Sub-page>
- Contact

## 4. Page-by-page requirements
### Home
- Purpose: <why this page exists>
- Sections, in order: <hero with headline and call to action, services summary, testimonials supplied by the client, contact strip>
- Call to action: <what the visitor should do next>

### <Page name>
- Purpose: <...>
- Sections, in order: <...>
- Call to action: <...>

## 5. Content
- Who writes the copy: <client | us | copywriter>
- Images and video: <supplied by client | stock | photo shoot>
- Content due by: <date>

## 6. Forms and integrations
- <Form name>: fields <name, email, message>; sends to <email address or tool>
- <Integration>: <for example newsletter signup, booking widget, analytics>
- Accounts or login: <none, unless the client asked for them>
- Payments: <none, unless the client asked for them>

## 7. SEO
- Target keywords per page: <...>
- Page titles and meta descriptions written by: <...>
- Redirects from the old site: <list, or none>

## 8. Hosting and domain
- Domain: <owned by | to buy>
- Hosting: <provider or to decide>
- Who maintains the site after launch: <...>

## 9. Out of scope
- <For example: blog, online shop, multiple languages, user accounts>

## 10. Open questions
- <A question the client needs to answer before build>

## 11. Sign-off
Approved by: ______________________   Date: __________

Step by step

1
Start from the discovery call
Fill the document from what the client said on the call, using the transcript if you have one. The meeting transcript to PRD guide explains how to pull requirements out of a conversation.
2
Define the purpose and audience
Write one or two sentences on what the site is for and who it is for. Every later decision, from page order to calls to action, should support that goal.
3
Build the sitemap
List every page and sub-page the site needs at launch. A page that is not in the sitemap is not in the price.
4
Write requirements page by page
For each page, describe its purpose, the sections in order and the call to action. Page-by-page requirements are far easier to estimate and approve than a general feature list.
5
Add content, forms, integrations, SEO and hosting
Record who supplies the content, what each form does, which tools the site connects to, the SEO basics and who owns the domain and hosting.
6
List what is out of scope, then get sign-off
Write down what is not included, list the open questions, and send the document to the client for approval before you start.

Why page by page beats a feature list for websites

Apps are best described feature by feature: book a walk, pay for an order, manage a team. Websites are different. Clients think in pages, visitors move through pages, and your effort scales with the number of pages and the sections on each one.

Describing the site page by page also exposes gaps early. When you write out the sections for the services page, you discover that nobody has decided whether each service needs its own page, which is exactly the kind of question to answer before quoting.

Website requirements checklist

Before you send the document for sign-off, check that it answers these:

Is the main goal of the site written down, with a way to measure it?
Is every launch page in the sitemap, with its sections and call to action?
Is it clear who supplies the text, images and video, and by when?
Does every form say what fields it has and where submissions go?
Are integrations, SEO tasks and redirects from an old site listed?
Are domain, hosting and post-launch maintenance assigned to someone?
Is there an out of scope list, and a list of open questions?

Website requirements for clients: keep it readable

A website requirements document is also a client document. Write it in plain language the client can read without help, keep technical detail to a minimum, and use their words for goals and tone. A client who understands the document is far more likely to approve it quickly, and far less likely to dispute it later.

The approved document becomes the backbone of your quote. Add pricing, milestones and terms with the scope of work template for software development.

How TaskyTrack writes website specs

TaskyTrack classifies the project type before it writes anything. When the call is about a website, the AI PRD generator writes the requirements page by page, with the sections the client described, in order. It does not add login, payments or a database unless the client asked for them, because most websites need none of the three.

You review and edit the draft, then use it as the basis for this requirements document or send it to the client as it is.

Key takeaways

Describe a website page by page: purpose, sections in order and call to action for each.
Assign content, forms, hosting and maintenance to someone by name.
End with an out of scope list, open questions and a sign-off line.

Frequently asked

What is a website requirements document?

It is a written description of what a website must include: its purpose, audience, pages and the content and features on each, plus forms, integrations, SEO, hosting and what is out of scope. It turns a client conversation into something you can price and build.

Is there a free website requirements document template?

Yes. The template on this page is free to copy and covers purpose, audience, sitemap, page-by-page requirements, content, forms and integrations, SEO, hosting, out of scope and open questions.

How detailed should website requirements be?

Detailed enough that you could estimate each page without another call. For most small business sites that means a few lines per page: its purpose, the sections in order and the call to action.

Who should write the website requirements document?

Whoever runs the discovery call, usually the agency or freelancer, using the client's answers. The client should read and approve it before work starts.

What is the difference between website requirements and a scope of work?

Requirements describe what the site must do and contain. A scope of work adds the commercial side: deliverables, timeline, pricing, payment terms and change requests. You usually write the requirements first, then build the scope of work around them.

Related guides

Get practical guides by email

Occasional, useful tips on turning client calls into build-ready specs. No spam. Unsubscribe anytime.

Turn your next call into a spec

Free to start. No card required.

Get started free