Website RFP 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.
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:
- (a)[Problem 1, with what it costs you today]
- (b)[Problem 2]
- (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:
- (a)[Goal 1, with a number and a date]
- (b)[Goal 2, with a number and a date]
- (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:
- (a)[Audience 1: who they are and what they come for]
- (b)[Audience 2]
- (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:
- (a)[Discovery and strategy]
- (b)[User experience and visual design]
- (c)[Development]
- (d)[Copywriting]
- (e)[Content migration]
- (f)[SEO set-up, including redirects from the old site]
- (g)[Analytics and tracking set-up]
- (h)[Training and handover]
- (i)[Hosting]
- (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:
- (a)[Home]
- (b)[Service or product listing]
- (c)[Service or product detail]
- (d)[About]
- (e)[Blog or news index, and article]
- (f)[Case study or project]
- (g)[Contact]
- (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:
- (a)[Feature 1: what a visitor or editor needs to be able to do]
- (b)[Feature 2]
- (c)[Feature 3]
9.2Nice to have:
- (a)[Feature 4]
- (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:
- (a)redirect every address that changes to its new address, with a list we approve before launch;
- (b)carry over, or rewrite with our approval, the page titles and descriptions of existing pages;
- (c)set up and test analytics and the conversions listed in section 4;
- (d)build on a staging site that search engines cannot index;
- (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:
- (a)[training for (number) editors]
- (b)[a handover document: platform, plugins or apps, licences, hosting and how to update]
- (c)[a period after launch in which defects are fixed at no charge: please state yours]
- (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:
- (a)who you are, and the people who would work on this project;
- (b)who will do each part of the work, and who is responsible for it;
- (c)your approach, and anything in this RFP you would change;
- (d)[two or three] comparable projects, with links and a contact we can call;
- (e)a timeline, including what you need from us and when;
- (f)a price for each phase, with what is not included;
- (g)your assumptions;
- (h)running costs after launch;
- (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:
- (a)crawl the current site before work starts, and keep the record;
- (b)list every existing address and agree with us what happens to each;
- (c)tell us what they would keep, rewrite, merge and remove;
- (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:
- (a)propose the sitemap and page layouts;
- (b)design for phones and desktops, with the states of each component;
- (c)supply design files we own and can open, in [Figma / other];
- (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:
- (a)review the design files and list what is missing before quoting a fixed price;
- (b)say how the build will be compared with the designs, at which screen widths, and by whom;
- (c)build on a staging site we can review;
- (d)keep the code in a repository we own, or hand it over at the end;
- (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.