How to write a website RFP

The accessibility clause uses the W3C's WCAG 2 overview, the WCAG 2.2 standard and its evaluation methodology (WCAG-EM). For the buying process we lean on the U.S. government's guide to buying accessible products and services on Section508.gov, written for federal agencies but useful for any buyer. The rest is our own view as a web agency, and we say so where it matters.

When an RFP is worth writing

If you are talking to one or two developers you already know, a two-page brief and a conversation are usually enough; our guide on choosing a web developer covers that route. An RFP earns its time when you send the same request to several agencies, when a board or a funder needs to see how you chose, or when your organisation's rules require a written process.

Whatever its length, the RFP should describe the problem and the result you want, not the technical solution. Agencies are good at proposing the how; they cannot guess your goals, your audience or your limits.

What to include

A useful website RFP covers these parts, in roughly this order:

• About you. Who you are, what you sell or do, and a link to the current site.
• Goals. Two or three outcomes you can check later: more quote requests, fewer support calls, online bookings, donations. Say how you measure them today.
• Audiences. Who visits and what each group comes to do. Existing customers checking hours have different needs from first-time buyers comparing options.
• Page list. The pages or page types you expect (home, services, one page per location, blog, contact) and roughly how many. If this is a redesign, attach a list of current URLs so the vendor can plan redirects; our redesign SEO guide explains why that list matters.
• Who writes the content. Say whether you will supply text and photos, or want the vendor to write, edit or source them. This is one of the biggest swings in scope and timeline. Our content checklist lists what you will need.
• Features and integrations. Forms, booking, payments, a CRM, email marketing, a store, a member area. Name the tools you already use and must keep.
• Editing. Who on your team will update the site after launch and how often.
• Hosting and the move. Whether you will keep your current host, want the vendor to host, or want a recommendation. If the site moves to a new host, ask for the migration plan, including email and DNS; our hosting migration guide covers the steps.
• Accessibility (see the next section), plus any privacy and security needs, such as where form data goes.
• Support after launch. Updates, backups, fixes and small changes, and whether you want a monthly plan.
• Budget range, timeline, evaluation criteria and ownership (below).
• Submission details. What a proposal must contain, the deadline, a date for questions, and one contact person.

The accessibility clause

Name a specific standard rather than asking for an "accessible website". The W3C's Web Content Accessibility Guidelines (WCAG) have success criteria "at three levels: A, AA, and AAA", and WCAG 2.2 was "published on 5 October 2023". In our view, WCAG 2.2 Level AA is the right target for a new business website. The W3C notes that later versions "add new success criteria, and do not change existing success criteria", so a site that meets 2.2 also covers what 2.1 and 2.0 require (the one exception is 4.1.1 Parsing, which 2.2 removed). One detail from the standard is worth copying into the RFP: conformance "is for full web page(s) only, and cannot be achieved if part of a web page is excluded", which matters for embedded booking, chat or payment widgets. Our view: say that the target covers the content you add later too, so the vendor sets up templates and editor guidance that keep it.

Ask how the vendor will prove it. For development services, Section508.gov tells buyers to ask vendors for two things: "A plan for accessibility testing and evaluation during the development life cycle" and "Evidence of the vendor's capability to develop accessible solutions". Its advice for checking claims is "Trust but verify", and it notes that automated tools have limitations, so manual testing is needed as well. The W3C's WCAG-EM describes a test process: "define the scope of your evaluation", explore the site, "select a representative sample of web pages", evaluate it and report the findings. Asking for a WCAG-EM style report at launch gives you something concrete to accept or reject. Background on what the criteria cover is in our accessibility basics guide.

Budget, timeline and evaluation criteria

Budget range. Our view: give one. Without it, one agency quotes a template site and another a custom build, and you cannot compare them. A range lets vendors show what they would do for that money. Our website cost guide explains what drives the price.

Timeline. Give the dates for questions, proposals, a decision and the start, plus any fixed launch date and the reason for it (a season, an event, a contract ending at the old host).

Evaluation criteria. List what you will score and how much each part weighs, for example relevant past work, the approach and plan, the team, accessibility and testing, support after launch, and price. Publishing the criteria gets you proposals that answer them. Section508.gov's own process puts this at the award stage: evaluate each proposal "to validate vendor claims against your stated accessibility requirements". Score every proposal with the same sheet, ideally by two or three people separately.

Who owns the domain, code and accounts

Say in the RFP, not after signing, that the domain, hosting, analytics, Search Console and any paid licences will be in your organisation's name, and that you will own the site's content, design and custom code once paid for, with any third-party themes or plugins listed. Vendors who cannot agree can drop out early. Our guides on what you should own and on development contracts go through each account and clause.

Questions to ask vendors

Ask every vendor the same questions in the RFP, so the answers line up:

• Which two or three past sites are closest to this project, and what did you do on each?
• Who will work on our project day to day, and is any part subcontracted?
• What are the phases, and what do we review and approve at each one?
• How do you test accessibility, and what will you hand us at launch to show WCAG 2.2 AA?
• What is included in the price, what is not, and how are changes priced?
• Which platform or CMS do you propose, and why for us? What would it take to move away from it later?
• How will you protect our search traffic during the redesign or move?
• What happens after launch: updates, backups, response times, and the cost of support?
• Which accounts and files will we have at handover?

Leave room for their questions too. A vendor who asks good questions before quoting has usually understood the job.

Red flags in the answers

Most warning signs are the same as when hiring any developer, and our list of red flags covers them. A few are specific to RFP answers:

• A proposal that repeats your RFP back to you without a plan of its own.
• "Fully accessible" or "100% compliant" with no named standard, no test method and no sample report.
• A price far below the others with no explanation of what was left out.
• No answer on ownership, or the domain and hosting staying in the vendor's name.
• No mention of redirects or the current site's pages in a redesign.
• Guaranteed search rankings.

Frequently asked questions

What should a website RFP include?

Your goals, audiences, a page list, who writes the content, features and integrations, hosting, an accessibility target such as WCAG 2.2 AA, support after launch, a budget range, a timeline, evaluation criteria and who will own the domain, code and accounts.

Should I put a budget in a website RFP?

In our view, yes. A range lets agencies propose work that fits it, and makes the proposals comparable. Without one, the quotes often describe very different projects.

Which accessibility standard should a website RFP name?

We recommend WCAG 2.2 Level AA, the current W3C Recommendation. Ask vendors how they will test it and to deliver an evaluation report at launch.

If you are planning a new website or a redesign, our website development service is happy to answer an RFP or help you write one.