On time, or a full refund.How the guarantee works

Website redesign RFP template

A complete website RFP to fill in and send.

A website redesign RFP tells agencies what you need, what you can spend and how you’ll choose. This template has all 20 sections, with a guidance note on what to write in each. Agencies: send it to the client who asks for a proposal without a brief.

Part A
The RFP: 20 sections, each with a guidance note
Part B
Add-ons for a redesign, a new design, or development only
Part C
A scoring sheet for the proposals you receive
Format
On this page, copy as text, print or save as PDF, or .txt

A starting draft. Adapt it.We build websites; we aren’t a procurement or law firm. The template is written to be changed, so fit it to your organisation and your project, and have whoever handles contracts for you check the terms before you send it.

What’s in the website RFP template.

One document in three parts. Part A is what you send. Parts B and C are there to shape it and to score what comes back.

  • Part A

    The RFP

    Background, goals, audience, the current site, scope, pages and features, platform, content, integrations, launch, timeline, budget, what a proposal must include, how you’ll choose, and how to submit.

    Go to Part A
  • Part B

    Add-ons by project type

    Extra sections for a website redesign RFP, a website design RFP for a new site, and a website development RFP where the designs are already done.

    Go to Part B
  • Part C

    The scoring sheet

    One page for each proposal: a score and a line of evidence for every criterion, and four questions to settle before the shortlist meeting.

    Go to Part C

How to use it.

Four steps. An afternoon’s work if you already know your goals and your budget.

  1. 1

    Copy it and fill in the brackets

    Copy the text into your own document. Fill every bracketed field, and where a bracket offers options, keep one.

  2. 2

    Add the section for your kind of project

    Part B has add-ons for a redesign, a new design and development only. Move the one that fits into Part A.

  3. 3

    Delete the guidance, state the budget

    Remove every guidance note before sending. Leave a budget or a range in: without one, the proposals can’t be compared.

  4. 4

    Send it to a short list

    Send it to the few agencies you’d actually hire, answer questions to all of them at once, and score with Part C.

The website RFP template.

The whole text is below. Jump to a section from the index, then copy it all as text, download it or print it. Printing gives you the template and nothing else.

Plain text, about 2,600 words. Paste it into your own document.

Website RFP template

Version 1.0 ·

This template is a starting draft. Adapt it to your organisation and your project before you send it. It isn’t legal or procurement advice, so have whoever handles contracts for you check section 20 and any terms you add.

Square brackets mark the fields to fill in. Where a bracket holds options separated by a slash, keep one. Sections in Part B marked "Optional" are add-ons for a redesign, a new site or a development-only project: move the ones you need into Part A. Guidance notes explain what to write and should be deleted before sending.

Part ARequest for proposal: website

The RFP itself, in the order a bidder needs to read it. Each section is short on purpose.

1.Summary and key dates

1.1[Organisation name] invites proposals to [redesign / design and build / develop] our website, [website address]. This document describes what we need, how to respond and how we will choose.

  • Project name
  • RFP issued on
  • Questions due by
  • Answers sent to all bidders by
  • Proposals due by (date, time and time zone)
  • Shortlist meetings
  • Decision by
  • Project start
  • Target launch date
  • Contact for this RFP (name, role, email)

Guidance (delete before sending). Put the dates first: a bidder decides whether to respond from this section alone. Leave enough time between issue and deadline for a considered proposal.

2.About us

2.1[Organisation name] is [what you do, for whom, and where]. We have [number] staff [and any facts that shape a website: locations, languages, a regulated sector].

2.2Our website is used for [what the site does for the organisation: enquiries, sales, bookings, recruitment, information].

Guidance (delete before sending). Three or four sentences. Bidders will read your website, so don’t paste in the About page. Say what they couldn’t find there.

3.Why we are doing this

3.1We are [redesigning our website / building a new website / building a site from finished designs] because [the reason, in one or two sentences].

3.2The problems we want to solve are:

  1. (a)[Problem 1, with what it costs you today]
  2. (b)[Problem 2]
  3. (c)[Problem 3]

Guidance (delete before sending). Describe problems, not solutions. “Visitors cannot find our prices” lets a bidder propose something. “We need a mega menu” doesn’t.

4.Goals and how we will measure them

4.1The project will be a success if:

  1. (a)[Goal 1, with a number and a date]
  2. (b)[Goal 2, with a number and a date]
  3. (c)[Goal 3]

4.2Today those figures are [current figures, or “not measured yet”].

Guidance (delete before sending). Goals with numbers let bidders size the work and let you judge the result. If nothing is measured today, say so, and ask for measurement to be part of the proposal.

5.Who the website is for

5.1Our main audiences are:

  1. (a)[Audience 1: who they are and what they come for]
  2. (b)[Audience 2]
  3. (c)[Audience 3]

5.2The most important thing a visitor should be able to do is [action].

Guidance (delete before sending). Put the audiences in order of importance. Bidders will design for the first one first.

6.Our current website

  • Website address
  • Platform and version
  • Hosting company
  • Approximate number of pages
  • Approximate visits a month
  • Who maintains it today

6.1What works and must be kept: [list].

6.2What does not work: [list].

6.3We [will / will not] give shortlisted bidders read access to our analytics and Search Console.

Guidance (delete before sending). For a new site with nothing to replace, delete this section. For a redesign it’s one of the most useful pages in the RFP: add the redesign section from Part B.

7.Scope of work

7.1We are asking bidders for:

  1. (a)[Discovery and strategy]
  2. (b)[User experience and visual design]
  3. (c)[Development]
  4. (d)[Copywriting]
  5. (e)[Content migration]
  6. (f)[SEO set-up, including redirects from the old site]
  7. (g)[Analytics and tracking set-up]
  8. (h)[Training and handover]
  9. (i)[Hosting]
  10. (j)[Maintenance after launch]

7.2Out of scope: [list what you are not asking for, and who is doing it instead].

Guidance (delete before sending). Delete the lines you don’t need. Say what’s out of scope as clearly as what’s in; in our experience, that’s where most price differences come from.

8.Pages and templates

8.1The site will have about [number] pages, built from about [number] unique page layouts.

8.2The layouts we expect are:

  1. (a)[Home]
  2. (b)[Service or product listing]
  3. (c)[Service or product detail]
  4. (d)[About]
  5. (e)[Blog or news index, and article]
  6. (f)[Case study or project]
  7. (g)[Contact]
  8. (h)[Campaign landing page]

8.3A draft sitemap is [attached as (file name) / not yet written, and we expect the bidder to propose one].

Guidance (delete before sending). Many agencies price by the number of unique layouts. Fifty pages on one layout is a smaller job than ten pages on ten.

9.Features and functionality

9.1Must have:

  1. (a)[Feature 1: what a visitor or editor needs to be able to do]
  2. (b)[Feature 2]
  3. (c)[Feature 3]

9.2Nice to have:

  1. (a)[Feature 4]
  2. (b)[Feature 5]

Guidance (delete before sending). Common ones to consider: contact and quote forms, site search, filters, a member or customer login, online payments, bookings, events, job listings, more than one language. Say what each one has to do, and leave the how to the bidder.

10.Platform and technical requirements

10.1Platform: [we want to stay on / move to (platform), because (reason)] / [we are open to a recommendation, with reasons].

10.2Editing: our team needs to be able to [add pages, edit text and images, publish posts, change products] without a developer.

10.3Hosting: [we host with (company) / we want the bidder to recommend hosting].

10.4Browsers and devices: [current versions of the main browsers, on phones, tablets and desktops].

10.5Accessibility: the site should meet [WCAG 2.2 level AA / other standard].

10.6Performance: [any target, such as passing Core Web Vitals on key pages].

10.7Security and compliance: [requirements, such as two-factor sign-in for editors, a data processing agreement, sector rules].

Guidance (delete before sending). If you name a platform, say why. If you don’t, ask each bidder to explain their choice and what editing will be like for your team.

11.Content

11.1Copy will be [written by us / written by the bidder / written by us and edited by the bidder].

11.2About [number] existing pages and [number] posts or products will be moved to the new site.

11.3Photography, video and illustration: [we will supply / we need the bidder to source or produce].

11.4Languages: [list].

Guidance (delete before sending). Be realistic about who writes the copy and when it will be ready. It affects the price and the launch date more than most features.

12.Integrations

12.1The website must connect to the systems below. For each one, tell us how you would connect it.

  • CRM
  • Email marketing platform
  • Payments
  • Booking or scheduling
  • Analytics and tag management
  • Stock, orders or other business systems
  • Other

Guidance (delete before sending). For each system give its name, who owns the account, and what should move between it and the website.

13.SEO, analytics and launch

13.1We expect the successful bidder to:

  1. (a)redirect every address that changes to its new address, with a list we approve before launch;
  2. (b)carry over, or rewrite with our approval, the page titles and descriptions of existing pages;
  3. (c)set up and test analytics and the conversions listed in section 4;
  4. (d)build on a staging site that search engines cannot index;
  5. (e)give us a launch checklist to sign off before the site goes live.

Guidance (delete before sending). If the site replaces an existing one, don’t delete this section. Missing redirects are how a redesign loses search visits.

14.After launch

14.1We need:

  1. (a)[training for (number) editors]
  2. (b)[a handover document: platform, plugins or apps, licences, hosting and how to update]
  3. (c)[a period after launch in which defects are fixed at no charge: please state yours]
  4. (d)[a separate quote for ongoing maintenance]

14.2We expect to own the design files, code and content produced for this project once it is paid for, and to hold the domain, hosting and other accounts and licences in our name.

Guidance (delete before sending). This states what you expect. The contract you sign is what actually sets the terms on ownership and warranty.

15.Timeline

  • Project start
  • Design approved
  • Build complete, on staging
  • Content complete
  • Launch

15.1The launch date is [fixed, because of (event or reason) / flexible].

Guidance (delete before sending). If the date is fixed, say why. Bidders will tell you whether it’s realistic, and what would have to be cut to meet it.

16.Budget

16.1Our budget for this project is [amount or range], [including / excluding] taxes.

16.2Running costs after launch (hosting, licences, maintenance) are budgeted separately at [amount] a [month / year].

Guidance (delete before sending). State a budget or a range. Without one, each bidder guesses the size of the project, and you get proposals you can’t compare.

17.What to include in your proposal

17.1Please include, in this order:

  1. (a)who you are, and the people who would work on this project;
  2. (b)who will do each part of the work, and who is responsible for it;
  3. (c)your approach, and anything in this RFP you would change;
  4. (d)[two or three] comparable projects, with links and a contact we can call;
  5. (e)a timeline, including what you need from us and when;
  6. (f)a price for each phase, with what is not included;
  7. (g)your assumptions;
  8. (h)running costs after launch;
  9. (i)your standard terms.

17.2Please keep proposals to [number] pages. We are not asking for design concepts at this stage.

Guidance (delete before sending). Asking for free design work puts good agencies off and tells you little. Ask for their process and their past work.

18.How we will choose

18.1Proposals will be scored against these criteria:

  • Understanding of our goals (weight, %)
  • Relevant experience and references (weight, %)
  • Approach and process (weight, %)
  • The team who would do the work (weight, %)
  • Price and value (weight, %)
  • Timeline (weight, %)

18.2Proposals will be read by [names or roles]. Shortlisted bidders will be invited to [a meeting / a presentation] on [date].

Guidance (delete before sending). Publish the criteria and their weights, and make them add up to 100. If price is the only stated criterion, you’ll get the cheapest proposals, which are rarely the best.

19.Questions and submission

19.1Send questions to [email] by [date]. We will send every question and answer to all bidders, without naming who asked.

19.2Send your proposal as [a PDF] to [email] by [time, time zone] on [date].

19.3We will confirm receipt, and tell every bidder the outcome by [date].

Guidance (delete before sending). Name one contact and use one address for questions and proposals. Tell the bidders you don’t choose, too: they spent time on you.

20.Terms of this RFP

20.1This RFP is an invitation to send a proposal. It is not an offer or a contract, and we may change or withdraw it.

20.2Bidders bear their own costs of responding.

20.3Information we share for this RFP is confidential. [A non-disclosure agreement is attached / is available on request.]

20.4Proposals stay the property of the bidder. We will not use ideas from proposals we do not accept.

Guidance (delete before sending). Have whoever handles contracts for you read this section. The wording is a starting draft, and procurement rules differ by country and sector.

Part BAdd-ons by type of project

Three optional sections. Move the one that fits your project into Part A, and delete the rest.

For a website redesign RFPOptional

Add this after section 6 when the project replaces a website you already have.

These pages bring most of our visits or enquiries and must keep their content and their place in search: [list, or “see attached export”].

Web addresses will [stay the same wherever possible / change, because (reason)].

We need the bidder to:

  1. (a)crawl the current site before work starts, and keep the record;
  2. (b)list every existing address and agree with us what happens to each;
  3. (c)tell us what they would keep, rewrite, merge and remove;
  4. (d)record a benchmark of visits, enquiries and speed before launch, and report against it [30 / 60 / 90] days after.

Please describe how you have protected search visibility on a past redesign, and what happened to visits afterwards.

For a website design RFP (a new site)Optional

Add this after section 5 when there is no site to replace, or when design is the main thing you are buying.

Our brand is [established, with guidelines attached / being developed alongside this project / not yet defined].

We [have / do not have] a logo, a colour palette, fonts and photography.

We are asking for [design only, as files another team will build / design and build together].

We need the bidder to:

  1. (a)propose the sitemap and page layouts;
  2. (b)design for phones and desktops, with the states of each component;
  3. (c)supply design files we own and can open, in [Figma / other];
  4. (d)show [number] rounds of revisions in the price.

Websites we like, and why: [list]. Websites we do not, and why: [list].

For a website development RFP (designs are done)Optional

Add this after section 7 when the designs exist and you are buying the build.

Designs are [complete / complete for (number) layouts] in [Figma / other]. A view link is [here / available to shortlisted bidders].

The designs include [desktop and mobile layouts / desktop only], and [do / do not] include hover, focus and error states.

Design questions during the build will be answered by [name or role].

We need the bidder to:

  1. (a)review the design files and list what is missing before quoting a fixed price;
  2. (b)say how the build will be compared with the designs, at which screen widths, and by whom;
  3. (c)build on a staging site we can review;
  4. (d)keep the code in a repository we own, or hand it over at the end;
  5. (e)state how defects are handled after launch, and for how long.

Part CScoring sheet

For your own team only; bidders never see it. One copy for each proposal, filled in by each reader before you compare notes.

Score each proposal

  • Bidder
  • Read by
  • Date

Score each criterion from 1 to 5, multiply by its weight from section 18, and add the results.

  • Understanding of our goals (score, and one line of evidence)
  • Relevant experience and references (score, and one line of evidence)
  • Approach and process (score, and one line of evidence)
  • The team who would do the work (score, and one line of evidence)
  • Price and value (score, and one line of evidence)
  • Timeline (score, and one line of evidence)
  • Total
  • Did they answer what was asked, in the order asked?
  • What did they challenge or improve in the RFP?
  • What is missing or unclear, to ask at the shortlist meeting?
  • Did the references confirm what the proposal says?

End of template. This template is a starting draft. Adapt it to your organisation and your project before you send it. It isn’t legal or procurement advice, so have whoever handles contracts for you check section 20 and any terms you add.

Redesign, new design or development only: what changes in the RFP.

Most of a website RFP stays the same whatever you’re buying. These are the sections that change.

  • Website redesign RFP

    You have a site and you’re replacing it.

    • Describe the current site: platform, size, what works and what doesn’t.
    • List the pages that bring visits and enquiries, so they are protected.
    • Ask for a crawl, a list of every address and redirects for the ones that change.
    • Ask for a benchmark before launch and a report against it afterwards.
    The redesign add-on
  • Website design RFP

    There’s no site to replace, or design is the main thing you’re buying.

    • Say where the brand stands: guidelines, logo, fonts, photography.
    • Say whether you want design only, or design and build together.
    • Ask bidders to propose the sitemap and layouts instead of assuming them.
    • Ask for design files you own and can open.
    The design add-on
  • Website development RFP

    The designs are finished and you’re buying the build.

    • Share the design files, and say what they do and don’t include.
    • Ask bidders to review the files before they quote a fixed price.
    • Ask how the build will be checked against the designs.
    • Settle where the code lives and who owns it.
    The development add-on

How an agency should respond to a website RFP.

For the agencies and freelancers on the receiving end. Eight habits that make a proposal easier to score, and easier to deliver if you win.

  1. Decide whether to bid. Check the budget, the dates, the fit, and whether the RFP says how it will be judged. No budget and no named contact are reasons to ask a question, or to pass.
  2. Ask your questions early, in writing. The answers usually go to every bidder, so ask what you need to price the work and keep the rest to yourself.
  3. Answer in their order, under their headings. The readers work through a scoring sheet. Make each answer easy to find.
  4. Price by phase, and list what is left out. A single figure invites a single objection. Phases, assumptions and exclusions show how the number was built.
  5. Show similar work and name the team. Two or three projects close to this one, with what you did on each, and the people who would do the work.
  6. Get your build partner’s price before you quote. If a partner or freelancer will build part of it, have their fixed price and dates in writing first. Your margin and your deadline both depend on theirs.
  7. Say what you would change. An RFP is a first draft of a project. A proposal that improves it is worth more than one that repeats it.
  8. Send it early, and ask for confirmation. Portals and inboxes fail at the deadline. A day early costs nothing.

Where we fit

We don’t answer RFPs from end clients; we work for agencies and for freelancers who resell. If you’re answering one, send us the brief and we’ll price the build for your proposal.

Within 2 business daysA written scope, a fixed price and a date.The scope lists every template, page and feature. The price is fixed and changes only if the scope does, and you approve any change first. The turnaround is counted in business days, in your time zone.

Website RFP questions.

For the people writing one, and the agencies answering it.

A website RFP, or request for proposal, is the document an organisation sends to agencies when it wants a website designed, redesigned or built. It describes the organisation, the goals, the scope, the budget and the dates, and it says what a proposal must contain and how the proposals will be judged.

Everything a website RFP includes, plus the current site. Background, goals with numbers, audience, scope, pages and features, platform, content, integrations, timeline, budget, evaluation criteria and submission instructions. For a redesign, add what works on the current site, the pages that must be protected, and a request for redirects from every address that changes. Part B of the template has that section.

Yes, as a figure or a range. Without one, each bidder guesses the size of the project, and the proposals that come back describe different projects at different prices. With one, bidders compete on what they can do for the money.

A website design RFP asks for the thinking and the look: sitemap, layouts and visual design, with or without the build. A website development RFP starts from finished designs and asks for the build: how it will be coded, checked against the designs, hosted and handed over. The template covers both with an add-on section for each.

Yes. Copy it, change it, put your own name on it and send it. It’s only a starting draft, though, and it isn’t legal or procurement advice, so have whoever handles contracts for you check the terms section before it goes out.

A short list of agencies you’d be glad to hire. A good proposal takes real work to write, and real time to read and score properly. A short list gets more effort from each bidder and a fairer reading from you.

Yes. Before you quote, get the build priced. With us that works like this: The scope lists every template, page and feature. The price is fixed and changes only if the scope does, and you approve any change first. The turnaround is counted in business days, in your time zone. You stay the bidder and the client’s only contact.

No. We build for agencies and for freelancers who resell, under their name, and we don’t take on end clients directly. If you’re choosing an agency, this template is still yours to use.

Answering an RFP? Get the build priced before your proposal is due.

Next, you send a short brief and we reply with a fixed price and a delivery date in writing. You pay nothing until you sign the order.