50 Requirements to Put in a Website RFP

A website RFP fails in one of two directions. Either it is so vague that every proposal describes a different project, or it is so exhaustive that no bidder can price it accurately and the requirements you actually care about are buried among fifty you will never enforce.

This list is meant to be cut down. Below are fifty requirements across eight categories, drawn from the same source as our downloadable requirements checklist. Most projects need twenty to thirty of them. Go through once and delete anything you would not reject a proposal over — what survives is your real specification.

They are written to be pasted into the scope section of your document, and they pair with the RFP template pack, which includes the editable document and a weighted scoring sheet.

Discovery and strategy

The requirements most often cut for budget, and the ones whose absence costs most. A rebuild that skips discovery reproduces the existing site's problems in a nicer typeface. Note the second item in particular: asking for an analytics review before design work starts tells you quickly which bidders intend to look at your data and which intend to redesign from taste.

• Stakeholder interviews across [ ] departments
• Analytics review of the existing site before any design work
• Content audit with keep / rewrite / retire decisions per page
• Competitor and peer review
• Documented user personas or audience definitions
• Measurable success criteria agreed before design begins

Information architecture and UX

Where most of the eventual user experience is actually decided. The item worth defending in budget conversations is the interactive prototype: it is far cheaper to discover a navigation problem in a prototype than in a built site, and it gives your stakeholders something concrete to react to before anything is expensive to change.

• Sitemap covering every template type
• Navigation tested with real users, not just approved internally
• Wireframes for every unique template
• Interactive prototype of the primary user journeys
• Mobile layouts designed, not merely reflowed
• Search behaviour defined, including empty and error states

Design

Ask for a design system rather than page comps. Comps cover the pages someone remembered to ask for; a component library covers the pages you will build in two years. The states item matters more than it looks — focus, hover, error and disabled states are where accessibility and polish are both won or lost, and they are routinely absent from design deliverables.

• Design system or component library, not one-off page comps
• Documented colour palette meeting contrast requirements
• Typographic scale with defined minimum body size
• Focus, hover, active, disabled and error states for every component
• Empty, loading and error states for every dynamic component
• Print styles where documents are printed in practice

Build and CMS

These are the requirements your team will feel every week for the next five years. The single most valuable one is that no routine update should require editing HTML. If your editors have to open a code view to fix a link, the site will decay regardless of how good the launch was.

• Every template editable by a non-technical editor
• No page requiring HTML editing for routine updates
• Reusable components rather than duplicated page markup
• Role-based permissions with a named approval workflow
• Draft preview that matches what publishes
• Scheduled publishing and unpublishing
• Staging environment matching production
• Version control with a documented rollback path

Accessibility

The section to write most carefully, because it is the one that turns into a legal problem rather than an inconvenience. Two of these are commonly missed: the authoring interface itself must be usable by a disabled editor, and third-party integrations must be tested even though your vendor did not build them. We cover the whole section in more depth in our guide to accessibility requirements in a website RFP, including how to read a conformance report when one arrives.

• WCAG [2.2] Level AA across templates, components and documents
• Authoring interface itself keyboard accessible
• Alternative text required by the CMS, not optional
• Heading structure enforced by the editor
• Captions and transcripts for all video and audio
• Accessibility Conformance Report delivered before final acceptance
• Manual keyboard and screen reader testing, not automated scans alone
• Third-party integrations tested and failures documented

Content and migration

Consistently the most underestimated line in any rebuild. Count your documents before you issue the RFP, and count how many are scans rather than exported text, because that is where the cost concentrates. The redirect map is not optional: it is the difference between a redesign and a traffic loss you spend a year recovering from.

• Redirect map covering every retired URL
• Metadata and structured data preserved or improved
• Documents remediated or replaced with accessible HTML
• Image alt text written during migration, not after
• Broken links and orphaned pages resolved before launch

Performance and technical

Specify thresholds and how they will be measured, on real devices rather than a developer laptop. The backup item is worth reading twice — plenty of sites have backups and no tested restore, which is not the same thing as having backups.

• Core Web Vitals thresholds defined and tested on real devices
• Images served responsively in modern formats
• Documented caching strategy
• Automated backups with a tested restore procedure
• SSL, security headers and a patching responsibility named

Launch and after

The requirements that decide whether you own the site or merely use it. Verify analytics before launch, not after, or you will lose the baseline you need to prove the project worked. And get the handover in writing: accounts, source code, credentials, documentation. This is the clause organizations most often discover they needed at the exact moment the relationship has ended.

• Launch checklist agreed in advance with named owners
• Analytics and conversion tracking verified before launch, not after
• Editor training delivered, with recordings retained
• Written documentation covering content standards and common tasks
• Defined support arrangement: hours, response times and costs
• Full handover of accounts, source code and credentials

How to cut the list down

Three passes work well.

First, delete anything you would not actually reject a proposal over. If you would accept a bid that omitted it, it is a preference, not a requirement, and it belongs in a conversation rather than a contract.

Second, mark what is genuinely mandatory versus desirable, and say which is which in the document. Bidders price mandatory requirements defensively. Letting them distinguish the two usually lowers your price and improves the proposals.

Third, check that every remaining requirement is testable. "Modern, professional design" cannot be verified and therefore cannot be enforced. "WCAG 2.2 Level AA, demonstrated by manual keyboard and screen reader testing of the journeys listed in section 5" can be. If you cannot describe how you would check it, either rewrite it or remove it.

Next steps

Take the template pack for the editable document, the full checklist and the scoring sheet. If you want a second read on your requirements before you issue them, we will do that whether or not we are bidding — the RFP and procurement FAQ covers the common questions, and you can send us an RFP when yours is ready.