Website RFP template: what to ask, and how to judge the answers

The short answer

A website RFP (request for proposal) should describe your organization, the problem the website has to solve, who uses it, what it must do, what content and systems already exist, your timeline and budget range, and exactly what each responder should send back. Keep it short enough that a good designer reads every word, and specific enough that every proposal answers the same questions.

The template below is free to copy. Each section lists what to write, with notes in square brackets for you to replace. After the template comes the part most RFPs forget: how to score the responses fairly.

When a website RFP helps, and when a conversation is better

A formal RFP earns its keep when several people have to agree on the choice: a city or county office, a school, a nonprofit with a board, or a company that has to show it compared vendors. It puts every proposal on the same footing and leaves a paper trail.

For a small business with one decision maker, two or three conversations often get further, faster. Even then, writing the first three sections below is worth an hour. It forces the decisions a designer will ask you about anyway.

Section 1: About your organization

Give responders enough context to understand who they would be working for.

• Who you are: [name, what you do, where, how long, how many people]
• Who you serve: [your customers, members or residents, and what they come to you for]
• Your current website: [address, and roughly how old it is]
• The main contact for questions: [name, email, and the deadline for questions]

Section 2: The problem and the goals

This is the most important section, and the one most often skipped. Describe what is wrong now and what success would look like, in your own words.

• What is not working: [for example, people call to ask things the site should answer, the site is hard to update, it does not work well on phones]
• What the site must achieve: [for example, more quote requests, online bookings, fewer routine phone calls, a place to publish meeting agendas]
• Who the site is for, in order of importance: [customers, members, job seekers, the press, staff]
• How you will measure it: [calls, form submissions, bookings, sales, or time saved]

Goals stated as problems get better proposals than a list of pages. Responders can then propose the right size of solution instead of guessing.

Section 3: Scope and requirements

Separate what the site must do from what would be nice. Responders can price the first list firmly and the second as options.

• Pages and sections: [the main areas you expect, or ask responders to propose a structure]
• Features: [forms, online payments, bookings, a store, event calendar, document library, staff directory, search]
• Connections to other systems: [CRM, email marketing, point of sale, payment processor, booking software]
• Content to move from the old site: [roughly how many pages, posts, documents and products, and whether old addresses must be redirected]
• Who writes and photographs: [you, the responder, or a mix]
• Editing: [who will update the site after launch, and how often]
• Accessibility: [the standard you need, for example WCAG 2.1 Level AA]
• Hosting, security and care: [whether the responder should host and maintain the site, and what you expect for backups, updates and response times]
• Search: [protecting current rankings during the move, and basic search setup at launch]

Public bodies should note the accessibility rule that applies to them. Under the Justice Department’s ADA Title II web rule, state and local government websites must meet WCAG 2.1 Level AA. An April 2026 rule extended the compliance dates to April 26, 2027 for governments serving 50,000 people or more, and April 26, 2028 for smaller ones and special districts. If that applies to you, say so in the RFP, and ask how each responder tests for it. An accessibility audit of your current site is a useful starting point.

Section 4: What you already have

Responders price more accurately when they know what they are starting from.

• Platform and hosting: [what the current site runs on, and who hosts it]
• Domain: [who the registrar is, and whose account it is in]
• Brand: [logo files, colors, fonts, any style guide]
• Content and photos: [what exists, what is usable, what is missing]
• Analytics and Search Console: [whether you have access, and the pages that bring the most visitors]
• Logins: [confirm you can get into the domain, hosting and site admin before the project starts]

Section 5: Timeline, budget and process

• Key dates: [RFP issued, questions due, answers published, proposals due, interviews, decision, project start, target launch]
• Fixed deadlines: [an event, a season, a board meeting, a funding deadline]
• Budget range: [a range for the build, and separately for yearly hosting and care]
• Contract expectations: [payment schedule, ownership of the domain, code and content, insurance, any required forms]
• Who decides: [the people or committee scoring the proposals]

State a budget range. It is not a weakness. Without one, responders guess, and you get one proposal sized for a brochure and another sized for a portal, which cannot be compared. What the contract itself should contain is covered in web design contract: what yours should say.

Section 6: What every response must include

Ask every responder for the same things, in the same order, so the proposals line up side by side.

1. Who will do the work: names and roles, and whether any of it is subcontracted.
2. Two or three live websites similar to this project, with what the responder did on each.
3. How they understand your problem, in their own words.
4. Their approach: the steps from kickoff to launch, and what they need from you at each step.
5. The proposed structure and features, mapped to your must-haves and nice-to-haves.
6. How content is moved and checked, and how current search rankings are protected.
7. How the site is tested before launch: phones, browsers, forms, accessibility, and what evidence you receive that each must-have works before you accept the site.
8. A timeline with the steps that depend on you marked.
9. Pricing, with the build, any options, hosting and ongoing care listed separately.
10. What is not included, and any assumptions behind the price.
11. What you will own at the end: domain, code, content and accounts.
12. Support after launch: who you call, and how fast they respond.
13. Two references you may contact.

How to evaluate website RFP responses

Agree on the scoring before the proposals arrive, so the most polished document does not win by default. A simple weighting that works for most website projects:

• Understanding of the problem: 25 points. Did they restate your goals accurately, or paste a generic pitch?
• Relevant, live work: 20 points. Open each example on your phone. Does it load, work and look cared for?
• Clarity of scope and exclusions: 20 points. Could you tell exactly what you are getting?
• Who does the work, and continuity: 15 points. Will the people in the interview be the people building the site, and will they be there next year?
• Plan for after launch: 10 points. Hosting, updates, backups and response times, in writing.
• Price and value: 10 points. Judged against the scope, not on the total alone.

Then interview the top two or three. Ask each one to walk you through a past project from first call to the weeks after launch, and call their references. A reference who has stayed with a firm for years tells you more than any proposal.

Mistakes that make website RFPs backfire

• No budget range, so proposals cannot be compared.
• Forty pages of boilerplate copied from another organization’s RFP, with requirements that do not apply to you.
• Asking for free design mockups. Good firms often decline, and a mockup made without research tells you little. Ask for past work and an approach instead.
• A deadline of a week or two. Thoughtful responders need time to ask questions and write a real plan.
• Scoring price first. The cheapest proposal is often the one that left out redirects, testing or care.
• No answer to questions. Publish every question and answer to all responders, so everyone works from the same information.

For the questions to ask in the interview round, see how to choose a Louisville web designer. If your project replaces an existing site, ask every responder how they handle your Google rankings in a website redesign.

Frequently asked questions

What is a website RFP?

A request for proposal: a document that describes your organization, the website you need and the questions every bidder must answer, so you can compare web designers on the same terms.

Should I include a budget in a website RFP?

Yes, as a range. It lets responders propose the right size of project instead of guessing, and it makes the proposals comparable.

How long should responders get to reply?

Give enough time to ask questions and receive answers before writing, usually a few weeks. A rushed deadline mostly filters out the careful firms.

Should I ask for free design mockups?

It is better not to. A mockup made without research says little about the final site. Ask for live examples, an approach and a clear scope instead.

Do you respond to website RFPs?

Yes, when the project is a good fit. Send it to me and I will tell you honestly whether it is, and if it is, every answer comes back in writing from the person who would build the site.