A website redesign RFP gives competing vendors the same project to evaluate. Describe your B2B website redesign scope through the pages, content, systems and customer journeys that need work. Then define website redesign acceptance criteria so each proposal explains how the delivered site will be checked, who approves it and what remains after launch.
A request for proposal (RFP) asks suppliers to explain their approach, deliverables, responsibilities and commercial terms against a shared brief. It is useful when you need to compare delivery options, rather than judge an attractive design presentation alone. Copy the sections below into your document and replace each prompt with information about your own site.
Start the website redesign request for proposal with business context
Give vendors enough context to identify the work without asking them to guess your strategy. Describe the visitors you serve, their main questions and the action you want them to complete. Explain the current problems with examples: a confusing service page, an incomplete form handoff or an editor who cannot update a case study.
Use these fill-in prompts:
- Primary audiences and markets: [organizations, roles, countries and languages].
- Priority journeys: [starting page, information needed and intended action].
- Current problems and evidence: [observations, support requests or available measurements].
- Content and brand elements to retain: [items and their approval owners].
- Business owner and decision-makers: [scope, content, design and launch approvers].
- Budget context and timing: [range or approval ceiling, currency, constraints and important dates].
For United States and Canadian proposals, state the currency and treatment of taxes and third-party charges. If you cannot disclose a budget range, ask suppliers to explain the assumptions behind their estimates and price optional work separately.
Separate delivery acceptance from later business outcomes. A form can be tested for correct submission and routing. An increase in qualified opportunities depends on traffic, the offer and sales activity as well as the site. Record both objectives, with an appropriate measurement period for each.
Define the B2B website redesign scope with an inventory
Provide a working inventory and identify what has been counted, sampled or left for discovery. Scope assumptions are conditions used to estimate work, such as receiving approved copy or importing a stated number of records. Ask vendors to flag the assumptions that could materially change their fees or timetable. Include the customer relationship management (CRM) system that receives website enquiries.
| Inventory item | Information to provide | Responsibility to assign |
|---|---|---|
| Existing URLs | Page count, important destinations and proposed changes | Who approves retaining, combining or retiring pages |
| Reusable templates | Layout types and required variants | Who designs, builds and checks each template |
| Content management system (CMS) | Collections, record counts, fields and relationships | Who maps, migrates and verifies content |
| Copy and images | Approved material, missing assets and usage rights | Who creates, edits and approves the final content |
| Forms and CRM handoffs | Fields, validation, destinations and routing rules | Who implements and tests each submission path |
| Integrations and tracking | Current tools, dependencies and account owners | Who configures connections and verifies behavior |
| Editorial work | Publishing, review and routine update tasks | Who configures access and trains the editors |
A content management system (CMS) stores and manages website content so authorized users can maintain it. For procurement, the important question is whether editors can perform the tasks your business needs. Ask vendors to demonstrate those tasks with representative content rather than relying on a feature list.
Specify responsive behavior and the states that matter: menus, empty results, validation errors, long headings and missing optional images. Include practical checks for keyboard use, readable content and understandable form errors. Assign content approval and record what happens when supplied material changes after design approval.
Use the website redesign checklist to prepare the inventory. Keep proposed additions separate from the existing site so suppliers can distinguish required migration from optional expansion.
Put website migration requirements into the quoted work
For search engine optimization (SEO), require a map of changed URLs that records the old destination, proposed new destination, reason and approver. Assign ownership of redirects, internal-link updates, canonical references and the sitemap. Ask how the vendor will identify unmapped important pages and document intentional removals.
According to Google's site-move guidance, significant changes can cause temporary ranking fluctuations while Google recrawls and reindexes the site. The same guidance recommends keeping redirects for as long as possible, generally at least one year. Include redirect maintenance in the ownership and cost discussion rather than treating it as a launch-day task.
Request a migration evidence pack containing the approved map, redirect-check results, unresolved exceptions and the person responsible for follow-up. Define what can be tested on staging and what needs checking after the public launch. A pre-launch review cannot substitute for verifying the final live destinations.
Measurement requires its own scope. List the existing analytics properties, important events, form destinations and account owners. Ask what will remain in use, what will change and how reviewers will access historical reports. Require an explanation of any reporting discontinuity before approving a new configuration.
Google's Analytics DebugView documentation explains that it displays collected events and user properties in real time when debug mode is enabled. Use an authorized test device to verify the intended events, while accounting for the site's privacy and consent settings. Check the resulting CRM record separately; an analytics event alone does not prove successful lead delivery.
The website migration SEO checklist provides execution background. Your RFP should identify which migration work the supplier prices, who approves it and where the evidence will be delivered.
State which evidence can be gathered before release and which requires the public site. A pre-launch review cannot establish that final live destinations behave correctly.
Write website redesign acceptance criteria before selecting a vendor
Acceptance criteria are observable conditions used to decide whether a deliverable meets the agreed requirement. Name the test, expected result, environment and reviewer. Avoid relying on words such as "fast," "intuitive" or "complete" without explaining how the parties will assess them.
| Deliverable | Example acceptance condition to adapt | Evidence and owner |
|---|---|---|
| Key page templates | Approved content and layouts work at the specified screen sizes | Recorded checks reviewed by the design owner |
| Forms | Required fields, errors, success messages and destination records behave as agreed | Test submissions and destination verification |
| Navigation | Priority journeys work with the agreed input methods | A reproducible task list and recorded exceptions |
| Content migration | Agreed records, fields, links and images match approved source material | Reconciliation results and exception decisions |
| Redirects | Approved old URLs reach the intended destinations | Pre-launch tests and live verification results |
| Editor tasks | A designated editor completes agreed publishing and update tasks | An observed demonstration and handover notes |
| Performance | Named pages meet agreed checks under documented conditions | Test settings, results and follow-up ownership |
Agree performance test conditions before fixing a threshold. Google's Core Web Vitals report documentation distinguishes real-world usage data from individual live tests. Its grouped measurements reflect the preceding 28 days, and insufficient data can leave pages out of the report. A new design therefore needs both reproducible pre-launch checks and an appropriate plan for reviewing available user data after launch.
Ask the supplier to record unresolved issues, their impact and who accepts or fixes them. Distinguish defects against approved requirements from new requests. User acceptance testing (UAT) is the business review of whether the delivered system supports its agreed use; it should include the people who operate the site, not only the project team.
Use a website RFP template for comparable vendor responses
Give every supplier the same response structure: approach, deliverables, named roles, customer inputs, assumptions, exclusions, schedule, pricing and handover. Ask for relevant work that can be verified, with permission where needed. A reference should help you understand the supplier's actual contribution and delivery responsibilities.
Use a scoring table with weights chosen by your team before reviewing the proposals. The example below deliberately leaves the weights blank. Your priorities should determine them, and the total should equal 100 percent.
| Criterion | Buyer-selected weight | Evidence to request |
|---|---|---|
| Scope completeness | [weight] | Response against each inventory and functional requirement |
| Migration and testing | [weight] | Proposed evidence, exceptions process and responsible roles |
| Delivery team | [weight] | Named responsibilities and relevant, verifiable experience |
| Commercial clarity | [weight] | Fees, assumptions, exclusions and change process |
| Handover and maintenance | [weight] | Editor training, access, documentation and support boundaries |
Score each response using a shared scale, such as zero for no evidence and five for a complete, substantiated response. Agree the intermediate ratings before using them. Record the reason for each score and list unanswered questions separately; arithmetic cannot resolve an unclear requirement.
Ask suppliers to identify the effect of alternative platforms or delivery methods. Compare the same required outcomes and make differences in customer effort, recurring costs and maintenance explicit. For platform background, the Webflow and Framer comparison can help frame those questions without turning this RFP into a platform purchase guide.
Assign launch and handover ownership
Name the person who authorizes launch and the conditions that would delay it. Record who implements the release, checks the live site and decides whether recovery action is needed. Rollback means returning to an agreed earlier working state; ask which parts can be restored and which changes need another recovery method.
For handover, request customer-controlled access, approved content, documentation, editor training and the agreed usable files. Identify third-party licences and assets with transfer restrictions. Define who maintains redirects, forms, integrations and tracking after the initial project ends.
Specify the support period and coverage in the actual agreement. A launch date does not establish how long the supplier will fix defects or handle new requests. Keep remaining work visible with an owner, acceptance condition and commercial treatment.
Glossary for website redesign RFP buyers
| Term | Meaning in the procurement document |
|---|---|
| Deliverable | A defined output the supplier commits to provide |
| Dependency | An input or decision needed before specified work can proceed |
| Exclusion | Work outside the quoted commitment |
| Content map | A record of existing material and its intended destination or treatment |
| Redirect | A response that sends a request for one address to another destination |
| Staging | An environment used to review and test changes before public release |
| Change request | A proposed adjustment to approved work with its effects reviewed before approval |
| Handover | The agreed transfer of access, usable assets, knowledge and ongoing responsibilities |
Website redesign RFP buyer FAQs
How detailed should the RFP be?
Give vendors enough information to price the same required work. Include the inventory, responsibilities, constraints and acceptance approach. Mark uncertainty as a discovery question instead of presenting an unverified count or assumption as settled.
Must we choose a platform first?
No. You can request a justified recommendation if the functional requirements are clear. Ask vendors to state the effect on implementation, subscriptions, editor tasks and ownership. If the platform is fixed, explain the constraint so proposals stay comparable.
Who supplies the content?
Assign that work in the brief. Separate writing, editing, asset sourcing, migration and approval. A vendor can price each responsibility only after it knows what your team will provide and what condition those materials will be in.
How do we compare different approaches fairly?
Apply the same requirements and evidence criteria, then record the tradeoffs. A higher fee may cover work your team would otherwise perform; a smaller scope can suit a capable internal team. Resolve those differences before ranking the totals.
What should handover include?
The access, documentation, training and usable assets needed to maintain the agreed site. Identify ongoing responsibilities and any restricted licences. Check that an editor can perform the required tasks before considering training complete.
Key takeaways
- Give vendors a shared inventory with clear assumptions and optional additions.
- Assign content, migration, measurement and customer-input responsibilities before comparing fees.
- Separate launch acceptance from outcomes that require later traffic and user data.
- Compare substantiated responses and record launch, recovery and handover ownership.
Twelverays' website development services describe website delivery informed by business goals, design, SEO and conversion needs. Bring your inventory and draft requirements to discuss the project scope.
