A website design RFP is not simply a list of pages, features, or visual examples you like. It is a structured brief that tells prospective vendors what business problem you need to address, what constraints they must work within, and how you will compare their proposals.
Doing this work before issuing a website design RFP helps you ask for responses that are comparable. It also makes important launch considerations—such as content migration, account ownership, accessibility testing, analytics continuity, and acceptance criteria—visible before they become assumptions.
What Is a Website Design RFP—and When Should You Use One?
A website design RFP, or request for proposal, invites vendors to recommend an approach to a defined website need. It should provide enough context for vendors to propose a scope, team, timeline, pricing structure, assumptions, and implementation plan.
An RFP can be useful when you plan to evaluate multiple agencies or freelancers against the same brief. For a small, clearly defined project, a discovery conversation or a tightly scoped request may be more practical. The right approach depends on the project’s uncertainty, risk, and number of stakeholders—not on a universal rule.
The Pre-Issuance Readiness Gate
Before you send an RFP, answer yes or no to each item below. If an answer is unknown, label it as a discovery question instead of presenting it as a fixed requirement.
- Can we describe the business problem this project should address?
- Have we identified measurable outcomes or acceptance criteria?
- Do we have a budget range or a clear instruction for how vendors should price options?
- Is there one accountable decision-maker and a defined review team?
- Have we identified target audiences and priority user journeys?
- Can we provide current-site pain points, analytics, customer feedback, or other evidence?
- Do we know who owns content decisions and approvals?
- Have we listed CMS, integrations, hosting, domain, and account-access dependencies?
- Do we have a desired launch window and known constraints?
- Have we documented procurement, legal, brand, or contractual constraints that affect the work?
If several answers are no, the project may benefit from a short internal planning phase before proposals are requested.
Reusable Asset 1: Website Design RFP Readiness Worksheet
Copy this table into your planning document. The “fixed requirement” column is for non-negotiables. The “vendor recommendation requested” column preserves room for vendors to solve the problem using their judgment.
| Decision area | What we know | Fixed requirement | Vendor recommendation requested | Internal owner | Evidence/link to provide | Unresolved question |
|---|---|---|---|---|---|---|
| Goals/KPIs | Business need and baseline | Required measures | Measurement approach | Project lead | Analytics or research | What defines success? |
| Audiences | Priority groups | Required audience coverage | Research or journey recommendations | Marketing lead | Personas or feedback | Which group comes first? |
| User journeys | Key tasks | Must-support tasks | Journey improvements | Operations lead | Support requests | Where do users get stuck? |
| Pages/content | Known inventory | Content quantity or pages | Information architecture | Content owner | Content inventory | What needs rewriting? |
| CMS | Current or preferred platform | Platform constraint, if any | Publishing workflow | Website owner | Access details | Is a change needed? |
| Integrations | Required systems | Named integrations | Implementation plan | Technical owner | API/vendor documentation | Who approves access? |
| Hosting/domain access | Current arrangements | Account ownership | Environment recommendation | Account owner | Access inventory | What access is missing? |
| Analytics | Current tracking | Continuity requirements | Measurement plan | Marketing lead | Analytics access | Which events matter? |
| SEO/migration | Current URLs and search visibility | Redirect and migration needs | Migration plan | Website owner | URL export | Which pages are critical? |
| Accessibility | Applicable target | Stated conformance target | Testing and remediation plan | Project lead | Existing audit | Who validates results? |
| Security/privacy | Data and risk context | Applicable obligations | Security practices | Technical owner | Policies | What review is needed? |
| Timeline | Launch window | Immovable dates | Milestone plan | Project lead | Campaign calendar | What causes delay? |
| Budget | Funding range | Pricing format | Phased options | Decision-maker | Budget guidance | What needs approval? |
| Training | Editor needs | Required trainees | Training format | Content owner | Team list | What tasks need training? |
| Support | Post-launch needs | Support expectations | Support model | Website owner | Current support issues | Who handles updates? |
| Acceptance | Review process | Acceptance criteria | Testing evidence | Decision-maker | Approval workflow | Who signs off? |
The Website Design RFP Checklist
1. Company and project context
Briefly explain your organization, the reason for the project, current website situation, key stakeholders, and any context a vendor needs to understand the assignment.
2. Business problem, objectives, and success measures
State the problem to address, the outcomes you want to measure, the baseline evidence available, and how deliverables will be reviewed and accepted.
3. Audiences and priority journeys
Identify priority audiences and the actions they need to complete, such as finding service information, requesting help, purchasing, booking, or accessing resources.
4. Content, brand inputs, and page or screen inventory
Provide existing brand materials, content inventory, known page or screen needs, content owners, and which materials will be supplied, revised, migrated, or created.
5. Scope and deliverables
List expected deliverables, including discovery, information architecture, design, development, content work, testing, launch, and documentation where applicable. Identify what is explicitly out of scope.
6. Technical, platform, and integration requirements
Name required platforms, integrations, authentication needs, environments, and access constraints. If you need help choosing a platform or hosting arrangement, frame that as a recommendation request. For ongoing infrastructure needs, see Netserj’s managed hosting information.
7. Content and URL migration
Specify what content and files move, who approves migrated content, and what must happen to retired or changed URLs.
8. Accessibility requirements
State the applicable accessibility target, testing approach, responsible party, remediation expectations, and evidence required for acceptance.
9. Security, privacy, and account access
Define account ownership, permissions, backups, data handling, and any applicable review requirements. Ask vendors to describe their secure-development practices, third-party component handling, vulnerability remediation, authentication and authorization where relevant, backups, and incident responsibilities.
10. SEO and analytics continuity
Document current analytics and search-related accounts, tracking requirements, baseline reporting, and ownership after launch.
11. Timeline, milestones, budget, and dependencies
Give the proposal deadline, desired launch window, review milestones, budget treatment, and dependencies such as content approvals or vendor access.
12. Training, documentation, support, and post-launch remediation
Specify who needs training, required documentation, support expectations, and how issues found after launch will be handled.
13. Contractual, ownership, and handoff expectations
Address ownership of accounts, source files, content, code, credentials, documentation, and final handoff materials. Obtain qualified advice for contract terms that affect your organization.
14. Proposal instructions
Set a response deadline, submission method, contact for questions, requested format, pricing format, and required assumptions and exclusions.
15. Evaluation criteria
Publish the factors you will use to evaluate proposals. A useful adaptable procurement principle is to align requirements, proposal instructions, and evaluation criteria, then assess proposals against the published criteria. Federal procurement guidance provides this as a model; it is not a private-business legal requirement.
How Specific Should a Website Design RFP Be?
Be precise about constraints, but do not turn every solution choice into a requirement. This distinction helps vendors give useful recommendations while keeping proposals comparable.
| Fixed requirements | Problems for vendors to solve |
|---|---|
| Required integration with a named system | Make publishing easier for nontechnical staff |
| Approved launch deadline | Reduce unnecessary support requests |
| Defined content quantity or migration volume | Improve self-service for priority users |
| Stated accessibility target | Help visitors find the right service path |
| Account and ownership constraints | Recommend a maintainable content workflow |
Website Redesign Requirements That Should Not Be Left Implicit
For a redesign, include these items as explicit response requirements:
- Current URL and content inventory.
- Old-to-new URL redirect map and approval process.
- Staging and testing approach before launch.
- Crawlability and indexing checks.
- Sitemap plan.
- Analytics and Search Console ownership and access.
- Launch monitoring and escalation responsibilities.
- Acceptance testing, rollback approach, and documentation.
For URL-changing site moves, Google’s migration guidance advises preparing and testing the new site, mapping old URLs to new URLs, implementing redirects, and monitoring the move. Google generally recommends retaining redirects for at least one year; treat this as Google’s general guidance and validate the appropriate plan for your project.
Accessibility, Security, and Privacy
Accessibility should be written as a testable project expectation, not a vague statement that the website should be “accessible.” WCAG 2.2 is a current W3C Recommendation. WCAG conformance uses Levels A, AA, and AAA; AA includes applicable Level A and Level AA success criteria. WCAG 2.2 is not a universal legal mandate.
Ask vendors for their testing approach, who performs testing, what evidence they provide, and how remediation works. Section508.gov procurement guidance similarly emphasizes stating accessibility requirements, evaluation expectations, and validation evidence in applicable acquisitions.
Legal, sector-specific, and privacy obligations vary by organization, jurisdiction, data practices, and contract. Seek qualified legal or privacy review for requirements that apply to your project. For security expectations, NIST’s Secure Software Development Framework provides a shared vocabulary that purchasers can use when discussing secure software development with suppliers during acquisition.
What Vendors Should Submit
Require every vendor to use the same response structure. Documentation should match the project’s size and risk.
- Proposed approach and understanding of the business problem.
- Named team members, roles, and responsibilities.
- Comparable work relevant to the requested scope.
- Implementation and migration plan.
- Testing and accessibility approach.
- Assumptions, exclusions, dependencies, and risks.
- Itemized pricing and any optional phases.
- Timeline and milestone plan.
- Support model and handoff approach.
- References, if appropriate for the project.
Reusable Asset 2: Proposal Comparison Scorecard
Copy one scorecard per vendor. These illustrative weights total 100; adjust and publish them before reviewing proposals. First check mandatory requirements separately. A high weighted score does not override a failed mandatory requirement.
Vendor: ______ Reviewer: ______ Date: ______ Proposal version: ______
Mandatory requirements: Pass / Fail / Clarification required. List any unmet requirement: ______
Rate each factor from 0 to 5: 0 = no response or evidence; 1 = major gaps; 2 = partial response with significant unresolved questions; 3 = meets the stated requirement with adequate evidence; 4 = strong evidence and clear delivery detail; 5 = exceptional, relevant evidence and a convincing implementation plan. Record the proposal page or clarification supporting each rating.
Weighted points = rating ÷ 5 × weight. Example: a rating of 4 on a 20-point factor earns 16 points. Add all seven weighted results for a total out of 100. Have reviewers score independently before discussing material differences.
| Factor | Weight | Rating 0–5 | Weighted points | Evidence / unresolved question |
|---|---|---|---|---|
| Business problem and audience understanding | 20 | ____ | ____ / 20 | ____ |
| Approach and relevant experience | 20 | ____ | ____ / 20 | ____ |
| Scope, deliverables and assumptions clarity | 15 | ____ | ____ / 15 | ____ |
| Technical, migration, accessibility and security approach | 15 | ____ | ____ / 15 | ____ |
| Team, communication and support | 10 | ____ | ____ / 10 | ____ |
| Timeline and dependencies | 10 | ____ | ____ / 10 | ____ |
| Price and pricing transparency | 10 | ____ | ____ / 10 | ____ |
| Total | 100 | — | ____ / 100 | Decision rationale: ____ |
Assumptions: ______
Exclusions and optional charges: ______
Content, access or approval dependencies: ______
Clarifications requested, owner and due date: ______
Quoted price and recurring charges: ______
Use the following summary only after completing each vendor sheet. Record unresolved exclusions alongside scores so that incomplete scopes are not compared as if they were equivalent.
| Vendor | Mandatory requirements | Score / 100 | Price and recurring cost | Open assumptions or exclusions |
|---|---|---|---|---|
| Vendor A: ____ | ____ | ____ | ____ | ____ |
| Vendor B: ____ | ____ | ____ | ____ | ____ |
| Vendor C: ____ | ____ | ____ | ____ | ____ |
Plain-text version to copy into your RFP document
READINESS WORKSHEET — repeat for each decision area Decision area: What we know and supporting evidence: Fixed requirement: Vendor recommendation requested: Internal owner: Unresolved question and due date: VENDOR SCORECARD Vendor / reviewer / date / proposal version: Mandatory requirements: PASS / FAIL / CLARIFY Business and audiences — weight 20; rating __; points __ Approach and experience — weight 20; rating __; points __ Scope and assumptions — weight 15; rating __; points __ Technical and launch approach — weight 15; rating __; points __ Team and support — weight 10; rating __; points __ Timeline and dependencies — weight 10; rating __; points __ Price transparency — weight 10; rating __; points __ For each factor: points = rating / 5 * weight. Total: __ / 100 Evidence or proposal page for each rating: Assumptions: Exclusions / optional charges: Dependencies and owners: Price / recurring costs: Clarification request / owner / due date: Decision and rationale:
Keep vendor questions and answers in one shared clarification log. A lower headline price may reflect missing work; evaluate exclusions before selecting a proposal.
A Final Pre-Send Review
- Decision-maker, proposal deadline, submission format, and questions process are named.
- Budget treatment and evaluation criteria are stated.
- Fixed requirements are separated from vendor-solved outcomes.
- Acceptance criteria and testing evidence are clear.
- Ownership and account-access expectations are documented.
- Migration, accessibility, security, analytics, and post-launch risks require explicit responses.
Netserj Company provides website design and serves clients across the United States. If you are defining a new website project, its website design service page is one place to begin exploring the service.
FAQ
What should be included in a website design RFP?
Include project context, business objectives, audiences, scope, technical requirements, content and migration needs, accessibility and security expectations, timeline, budget treatment, proposal instructions, ownership expectations, and evaluation criteria.
Should I include a budget in a website design RFP?
Include a budget range when you can, or state how vendors should present pricing and options. This helps vendors frame an appropriate scope, but it does not replace a clear description of requirements and assumptions.
How do I compare website design proposals?
Use a published weighted scorecard, require a consistent response format, and review assumptions and exclusions with pricing. Set the weights before receiving proposals and record clarifications consistently.
What should a redesign RFP say about SEO migration?
Request a URL inventory, old-to-new redirect map, testing plan, crawl and indexing checks, sitemap plan, account ownership, launch monitoring, and documentation. Google’s site-move guidance is a useful reference for URL-changing projects.
Should an RFP require accessibility testing?
If accessibility is an applicable project requirement, state the target and ask for a testing process, responsible party, remediation expectations, and acceptance evidence. Confirm applicable legal or contractual obligations with qualified advisors.
Turn Your Readiness Work Into a Better Project Brief
Complete the readiness worksheet and scorecard before requesting proposals. You will then have a clearer basis for discussing scope, identifying open questions, and comparing vendor responses.
