Website Redesign RFP: What to Include Before You Invite Proposals

A website redesign request for proposal should make agencies compete on the same problem, scope, evidence, and commercial terms. It should not ask vendors to guess what “modern,” “better,” or “high converting” means. This guide shows what to disclose, what to require, and how to compare responses without pretending the buyer already knows the solution.

What is a website redesign RFP?

A website redesign RFP is a request for proposal that tells agencies why the current site must change, what outcomes matter, what work is in scope, which constraints apply, and how responses will be evaluated. Its purpose is to produce comparable proposals, not a stack of unrelated sales pitches.

The RFP should describe the problem and required result without prescribing every design choice. Buyers need enough specificity to expose cost drivers, dependencies, risks, and exclusions. Agencies still need room to recommend a content model, information architecture, platform, research method, and delivery approach that fit the evidence.

If the project has not yet defined its users, content, features, integrations, and acceptance conditions, start with LeWebsite’s website requirements document template. An RFP asks vendors to propose a solution; a requirements document defines what the solution must accomplish.

What should you prepare before writing the RFP?

Prepare a current-site evidence pack before drafting the RFP: analytics, priority URLs, content inventory, conversion paths, user feedback, accessibility findings, performance data, platform details, integrations, known defects, ownership records, and business constraints. That baseline lets agencies estimate real work instead of pricing assumptions they cannot verify.

Build a current-site evidence pack

• Primary audiences, top tasks, conversion journeys, and the business owner for each outcome.
• Current sitemap, page and template counts, content owners, migration candidates, and planned removals.
• Organic landing pages, backlinks worth protecting, metadata, structured data, redirects, and international variants.
• CMS, hosting, DNS, analytics, forms, CRM, ecommerce, email, search, consent, and automation integrations.
• Known accessibility, performance, security, content, editorial, and operational problems.
• Brand assets, design system status, legal constraints, internal review capacity, and immovable dates.

Separate evidence from preferences

“Users cannot find pricing on mobile” is a testable problem. “Make the site feel innovative” is a preference until the RFP explains the audience, behavior, and proof of success. Label fixed requirements, desirable outcomes, open questions, and vendor recommendations separately so bidders understand where they may challenge the brief.

Which scope details make agency proposals comparable?

Comparable proposals require counted deliverables and named responsibilities. State the number of unique templates, languages, content items, integrations, forms, workflows, migrations, environments, and training sessions. Assign who writes, approves, enters, translates, tests, and maintains each item, then require agencies to price assumptions, options, and exclusions separately.

Avoid one total price beside a vague promise. Ask bidders to use the same response table for discovery, design, development, content, migration, quality assurance, launch, training, warranty, support, third-party costs, and optional work. Comparable structure reveals what each price includes rather than rewarding the shortest proposal.

How should the RFP define content, SEO, accessibility, and performance?

Define these as delivery requirements with baselines, responsibilities, and tests. Content needs inventory and migration rules; SEO needs URL and metadata continuity; accessibility needs a named standard and verification method; performance needs agreed page types, devices, conditions, and metrics. “Follow best practices” is not an acceptance criterion.

Protect search visibility during migration

Provide priority organic URLs, planned removals, canonical and hreflang needs, structured-data dependencies, and required measurement access. Ask each agency for content mapping, redirect ownership, prelaunch crawl evidence, launch monitoring, and rollback criteria. Google’s site-move guidance explains why URL mapping and redirect monitoring belong in the plan.

Name an accessibility standard

Specify the applicable target, normally a current Web Content Accessibility Guidelines level chosen with qualified legal and accessibility advice. Require design, code, content, keyboard, screen-reader, zoom, focus, contrast, form, and document checks. The authoritative WCAG 2.2 recommendation provides testable success criteria rather than a generic accessibility claim.

Define performance conditions

Name representative page types, target devices, connection conditions, geographic assumptions, and measurement tools. Ask agencies to explain performance budgets and third-party-script tradeoffs. The official Web Vitals guidance helps buyers distinguish measurable user experience from a one-time laboratory score chosen after the site is built.

What technical requirements belong in a redesign RFP?

Include current architecture, required integrations, data flows, user roles, environments, hosting constraints, security expectations, backup and recovery needs, deployment process, logging, monitoring, privacy obligations, and ownership boundaries. Ask bidders to identify proposed changes, dependencies, licenses, recurring costs, unsupported assumptions, and every action only their team could perform.

• Required CMS capabilities, editorial workflow, roles, reusable components, search, and multilingual behavior.
• Form destinations, CRM fields, ecommerce paths, APIs, webhooks, identity systems, and failure handling.
• Production, staging, development, repository, deployment, backup, restore, rollback, and monitoring controls.
• Data categories, retention, consent, vendor processors, export requirements, and access-review expectations.
• Business-owned domain, hosting, source code, design files, analytics, licenses, accounts, and recovery methods.

Do not force a platform merely because the current site uses it. State any nonnegotiable constraint and ask vendors to explain fit, migration cost, operational burden, editor experience, update path, exit options, and recurring fees. If WordPress is required, distinguish core capabilities from commercial plugins and custom code.

How should budget, timeline, and change control be written?

State a realistic budget band, procurement dates, decision date, desired launch window, immovable events, review capacity, and payment constraints. Require a milestone schedule with buyer dependencies and contingency. Define how assumptions become changes, who approves them, how price and timing are recalculated, and which discoveries can reopen scope.

Use a budget band instead of silence

A budget band helps agencies propose an appropriate level of research, design, engineering, content, and support. If approval is not final, state the planning range and conditions. Ask for a base scope, priced options, third-party fees, recurring costs, payment schedule, and the assumptions that could materially change the estimate.

Expose buyer-side dependencies

Agency timelines depend on content decisions, stakeholder availability, legal review, integration access, data exports, brand approvals, and feedback speed. Require a responsibility matrix and make internal owners commit time. A launch date without buyer dependencies is not a schedule; it is a hope that hides foreseeable delay.

What should every agency proposal include?

Require every bidder to answer the same response structure: understanding of the problem, proposed approach, scope, deliverables, schedule, team, responsibilities, assumptions, exclusions, risks, accessibility and SEO methods, platform rationale, quality plan, ownership, support, references, itemized price, recurring costs, and explicit departures from the RFP.

1. Executive summary tied to the stated outcomes, not a generic agency introduction.
2. Work plan by phase with deliverables, decision gates, responsibilities, and acceptance evidence.
3. Named team members, roles, availability, subcontractors, and who remains after the sale.
4. Relevant examples with the agency’s exact role and permission to verify references.
5. Technical, content, SEO, accessibility, analytics, migration, and launch approaches.
6. Assumptions, exclusions, buyer dependencies, risks, alternatives, and change-control method.
7. Itemized fees, optional work, third-party costs, recurring charges, and payment schedule.
8. Warranty, support, maintenance, ownership, licensing, handover, and exit terms.

Ask vendors to flag contradictions instead of pricing around them quietly. A strong proposal should explain what cannot be known before discovery and how that uncertainty will be resolved. Penalizing honest unknowns encourages hidden assumptions that surface later as delays, change orders, or reduced quality.

How do you score website redesign proposals?

Score proposals against published, weighted criteria before opening them. Use several reviewers, record evidence and conflicts, normalize price against included scope, and interview finalists around assumptions and risks. The cheapest total is not comparable when one bidder includes migration, testing, training, and support that another leaves unstated.

Adjust weights to the project, then define what a score of one, three, or five means. Reviewers should cite proposal pages or interview answers. Add pass/fail gates for conflicts, missing disclosures, unacceptable ownership, or mandatory standards so a polished presentation cannot compensate for a material requirement failure.

Which acceptance and handover terms protect the buyer?

Attach acceptance criteria to milestones and final payment. Require traceable tests, resolved critical defects, owner-controlled accounts, production-matching source files, content reconciliation, redirect verification, analytics continuity, documentation, training, backup restore, deployment and rollback instructions, support terms, and a dated exceptions register. Legal terms still need qualified counsel.

Define who accepts each deliverable, how long review takes, what evidence is required, how defects are classified, what happens after rejection, and when silence does or does not count as approval. Keep warranty correction separate from new features and maintenance. Use the website handover checklist to make final delivery independently testable.

Ownership should include the domain, hosting, CMS, repository, design source, analytics, integrations, licenses, billing, and recovery methods appropriate to the contract. If a managed service remains vendor-controlled, require documented access, data export, continuity, termination, migration assistance, and costs. A convenient service is acceptable; an undisclosed dependency is not.

Website redesign RFP template outline

A practical website redesign RFP can follow twelve sections: instructions, business context, current-site evidence, audiences, goals, scope, content, technical requirements, quality standards, commercial terms, required proposal format, and evaluation process. Add appendices for inventories and data, then remove anything that does not change scope, risk, or selection.

1. Procurement instructions: contact, question process, submission format, deadline, decision date, and confidentiality.
2. Business context: organization, offer, audience, market, stakeholders, and reason for redesign.
3. Current-site baseline: platform, inventory, analytics, priority journeys, known problems, and dependencies.
4. Goals and measures: outcomes, baselines, targets, owners, and measurement access.
5. Scope and exclusions: research, design, templates, features, integrations, content, migration, launch, training, and support.
6. Content and SEO: ownership, writing, entry, redirects, metadata, schema, international needs, and post-launch monitoring.
7. Technical and quality requirements: CMS, accessibility, performance, security, privacy, analytics, devices, and testing.
8. Ownership and operations: accounts, source files, licenses, environments, backups, deployment, documentation, and handover.
9. Commercial framework: budget band, payment limits, schedule, dependencies, changes, warranty, and recurring costs.
10. Required response: approach, deliverables, team, proof, assumptions, exclusions, risks, price, options, and departures.
11. Evaluation: weighted criteria, pass/fail gates, interviews, references, demonstrations, and award process.
12. Appendices: sitemap, inventory, analytics summary, integrations, brand assets, policies, and draft agreement.

Keep the core document readable and place volatile detail in appendices. Give every bidder the same answers to material questions and issue amendments to all participants. Before release, ask one internal reviewer and one technically informed reviewer to identify ambiguity, conflicting requirements, missing ownership, and untestable acceptance language.

Website redesign RFP FAQ

These answers cover the choices buyers most often face before issuing a website redesign RFP: what belongs in the document, whether budget should be disclosed, how long the request should be, how many vendors to invite, and how an RFP differs from requirements. Procurement rules may impose additional obligations.

What should a website redesign RFP include?

Include business context, current-site evidence, audiences, measurable goals, counted scope, content and migration responsibilities, integrations, technical constraints, SEO, accessibility, performance, analytics, timeline, budget, ownership, acceptance criteria, required proposal structure, and weighted evaluation criteria. Attach inventories and data that materially affect effort, risk, or vendor selection.

Should you disclose the website redesign budget?

Usually, yes. A realistic band helps qualified agencies decide whether to respond and propose an appropriate approach. State whether the range includes content, licenses, tax, hosting, support, or contingency. If funding is conditional, explain the approval boundary and require base scope, options, recurring costs, and assumptions separately.

How long should a website redesign RFP be?

Use the shortest document that removes material ambiguity. A concise core RFP with structured appendices is often more useful than a long narrative. Length should follow scope complexity, not a page target. Every section should change estimates, risks, responsibilities, acceptance, or selection; otherwise, edit it out.

How many agencies should receive the RFP?

Invite a manageable shortlist of qualified agencies rather than broadcasting the request indiscriminately. The right number depends on procurement rules, project complexity, and reviewer capacity. Prequalify for relevant capability, conflicts, availability, and budget fit, then give every invited bidder equal information and a fair question process.

What is the difference between an RFP and a website requirements document?

A requirements document defines what the website must support and how acceptance will be judged. An RFP adds procurement context: instructions, proposal format, vendor qualifications, commercial terms, evaluation criteria, and award process. The requirements may sit inside or beside the RFP, but vendors should answer the same baseline.

How can LeWebsite help with a website redesign RFP?

LeWebsite can help turn business goals, current-site evidence, content, technical constraints, SEO migration, accessibility, performance, integrations, and ownership into a proposal-ready scope. LeWebsite can also review agency responses for hidden assumptions, missing deliverables, recurring costs, acceptance gaps, and practical risks before a buyer selects a partner.

Review LeWebsite’s website redesign scope guide and web development services, or contact LeWebsite with the current URL, target launch window, known platform, and procurement stage. A useful first review should clarify what belongs in the RFP, what remains unknown, and which evidence agencies need to price responsibly.