Website Redesign RFP: What to Include Before Contacting Agencies

A website redesign RFP should do more than collect prices. It should give agencies enough context to understand your goals, constraints, delivery risks, and decision process before they recommend an approach.

Without that context, three agencies can price three different projects. One may assume a visual refresh, another may include content migration and CMS restructuring, and a third may allow for SEO, analytics, and launch QA. Their proposals may look comparable on the surface, but the scope behind the totals is not.

A useful RFP does not solve every design or technical decision in advance. It documents what your team knows, identifies what cannot be overlooked, and makes unknowns visible so agencies can plan discovery responsibly.

What a good website redesign RFP must accomplish

A strong website redesign RFP creates alignment before the selection process begins. Internally, it asks your team to agree on why the redesign is happening, what success looks like, what must not break, and who has authority to make decisions. Externally, it gives each agency a common factual baseline.

The document should describe the business problem, not just the requested output. “We need a modern website” is a design preference. “Prospective buyers struggle to understand our product tiers and rarely reach the right demo path” is a problem an agency can investigate and address.

This distinction matters when internal stakeholders disagree about the project. A marketing team may see a brand refresh, while demand generation needs better campaign landing pages and leadership expects organic visibility to be protected. Those needs can coexist, but they affect scope, sequencing, and the team required.

A good RFP also exposes known complexity early. Content libraries, legacy URLs, localization, legal review, CRM routing, and permissions can change both effort and launch risk. Naming them does not guarantee a fixed scope. It helps agencies state assumptions, exclusions, and validation steps before work begins.

The RFP is one part of the broader Website Redesign Process. It should support discovery, not replace it. Define the outcomes and constraints that matter now, then ask agencies to explain how they would validate the open decisions.

What to include in a website redesign RFP

The most useful website RFP template is not a rigid form. It is a shared outline that makes business context, required workstreams, technical dependencies, and responsibilities visible.

Business context, current-site problems, goals, and audiences

Start with why the redesign is needed now. The trigger may be a repositioning effort, product expansion, an outdated publishing workflow, weak conversion paths, or a site that marketing cannot update without developer support.

Describe current problems in plain language, separating symptoms from outcomes. “The site feels dated” may be true, but it does not help an agency estimate strategy or UX work. A more useful statement is: “Enterprise visitors do not understand the distinction between our products quickly enough to request a relevant demo.”

Name priority audiences and journeys. A B2B or SaaS site may serve executive buyers, technical evaluators, partners, candidates, and existing customers, but they will not all deserve equal emphasis. Explain the actions each priority audience should be able to take and where the present experience fails.

Include success measures, even if they are directional rather than final KPIs. Examples include clearer product understanding, more qualified inquiries, improved campaign-page publishing, stronger content discoverability, or reduced reliance on developers for routine updates. Also identify the project owner, decision-makers, and any legal, brand, or executive approvers.

Scope, deliverables, content, and ownership

List the workstreams you expect agencies to consider: strategy, information architecture, design, copywriting, development, accessibility, content migration, redirect planning, analytics validation, QA, training, and post-launch support. Mark each as required, optional, client-led, or still to be decided.

Provide approximate scale rather than false precision. An agency needs to know whether the work involves 12 core pages, a resource center with hundreds of entries, multiple regional variants, or a large set of product and integration pages. For CMS-heavy sites, list the content types you have today and the rough volume of each.

Ownership needs equal attention. Content, redirects, analytics, forms, and launch approval are common scoping fault lines because each party may assume the other is handling them. Use a responsibility model that identifies one accountable owner for each decision, the party doing the work, and those who must be consulted.

This model does not assign every task permanently. It prevents silent gaps in the proposal and gives agencies a basis for planning workshops, reviews, and handoffs.

CMS, integrations, analytics, and technical constraints

Document the current platform, any platform requirement, and the operational needs behind it. If Webflow is mandatory, say so. If your team is open to recommendations, describe the constraints instead of dictating an untested solution.

“Easy to edit” is not a complete CMS requirement. Explain how marketing publishes: the content types it manages, relationships between those types, required reusable sections, permissions, localization, filtering, search, campaign-page creation, and approval steps. CMS architecture should support the people maintaining the site after launch, not only the launch-day design.

This is particularly important for teams that publish regular resources, product updates, and campaign pages. A scalable Webflow CMS Architecture can reduce developer bottlenecks, but the model should follow real editorial workflows rather than a generic collection structure.

List integrations as data flows, not just tool names. Agencies need to know what a form submission triggers, where data is routed, whether gated content is delivered automatically, which events are tracked, and who validates the result. Include hosting, privacy, security, accessibility, procurement, or performance constraints that may affect implementation.

SEO, migration, QA, and launch requirements

If organic search contributes to pipeline or content discovery, put SEO requirements in the RFP. A redesign can alter URLs, templates, navigation, internal links, metadata, structured data, and indexation signals. Planning those changes early improves accountability and validation, but it does not guarantee traffic or ranking outcomes.

Identify priority organic landing pages, high-value conversion pages, resource libraries, international content, and areas under consideration for removal or consolidation. Agencies can review the supporting data during discovery, but they need to know that those assets matter before proposing the work.

Redirect mapping should not be treated as a launch-week task. The final map may be built during discovery and implementation, but its ownership, review process, and QA must be in scope from the beginning. The same applies to pre-launch crawl checks, metadata handling, internal links, XML sitemaps, canonicals, analytics, form testing, and post-launch monitoring.

A concise requirement can prevent ambiguity:

The agency will propose a migration and launch-validation plan covering priority URLs, redirect mapping ownership, metadata and internal-link preservation, form and analytics testing, and post-launch indexation monitoring. The final redirect map will be validated during the project.

For a platform move or extensive restructuring, connect these requirements to an SEO-safe Webflow Migration plan. If there are existing crawl, indexation, or measurement concerns, an Technical SEO Audit can help establish the current state before scope is finalized.

How detailed should your redesign RFP be?

Be detailed about outcomes, conditions, constraints, dependencies, and non-negotiables. Leave the implementation methods open unless a method has already been validated or is genuinely required.

For example, “HubSpot forms must preserve lifecycle routing and consent requirements” is a useful requirement. “Use this exact embed pattern on every template” may prematurely limit better implementation options. Similarly, “protect priority organic pages through redirect planning and launch QA” belongs in the RFP, while the final redirect rules and destination mapping normally belong in discovery.

Separate four categories in the document:

Honest uncertainty is useful. If your team has not decided whether every legacy article should migrate, say that content assessment is required. A clear open question invites an agency to recommend a method. Pretending it is resolved produces a confident-looking proposal based on a weak assumption.

Set the budget, timeline, and proposal instructions

Budget and timing context allow agencies to recommend an appropriate delivery model instead of guessing at one. A range is most useful when it is paired with what it should include and what may be optional.

State a budget range and commercial assumptions

Share a realistic budget range if your procurement process allows it. It helps agencies distinguish between a focused redesign, a full strategy and copy engagement, a complex CMS rebuild, or a phased migration.

State whether the range includes copywriting, content migration, accessibility work, software or third-party costs, SEO planning, QA, training, and post-launch support. Ask agencies to show assumptions and exclusions separately from the total. A lower proposal may be suitable, but only if its missing workstreams are visible and acceptable.

Give timeline, submission, and decision instructions

Distinguish a preferred launch date from a fixed deadline. A site needed before a product launch, event, or contractual date requires a different plan from one that simply needs to launch within a quarter.

List dependencies such as brand work, content delivery, legal review, executive availability, translations, procurement approvals, and campaign milestones. Then provide a question period, proposal deadline, requested response format, interview stages, main contact, and decision date. These instructions make comparison easier without forcing every agency into an identical solution.

Evaluate agencies on process, capability, and risk

A redesign proposal is a delivery model, not just a price. Compare what each agency believes the work includes before comparing totals. The strongest proposals do not merely look polished. They explain their assumptions, identify unresolved risks, and show how decisions will be validated.

Assess business understanding first. Does the agency reflect your audiences, positioning, conversion needs, and stakeholder constraints, or does it jump directly to visual concepts? Then examine its discovery approach. A B2B site with complex content, integrations, and SEO considerations may need stakeholder interviews, analytics review, content assessment, information architecture, and a technical launch plan before development begins.

Related: B2B website redesign

Evaluate the proposed delivery team, not only the pitch team. Ask who will lead strategy, design, CMS development, technical SEO, QA, and project management, and how directly those people will be involved. Relevant evidence should relate to your actual risks, whether that is scalable publishing, CRM routing, accessibility, migration planning, or conversion paths.

Use a weighted scorecard to give stakeholders a consistent basis for discussion. These weights are illustrative. Adjust them to reflect your own risks and priorities.

Use the proposal to test how an agency handles uncertainty. Ask what happens if content volume grows, a key integration needs further validation, or approvals slip. An agency does not need to promise that no issue will arise. It should show a credible method for surfacing, managing, and communicating risk.

Run a final readiness check before sending the RFP

Before sending the website redesign RFP, confirm that a qualified agency can understand the project without guessing about its fundamentals. The document does not need every answer. It needs a clear account of the current state, desired outcomes, constraints, and response expectations.

Use this short send-or-revise check:

• Objectives: Can a reader explain the business problem and priority audiences, not just the desired visual change?
• Scope: Are required workstreams and uncertain areas named, including content, CMS, QA, and launch support?
• Ownership: Is there an accountable client decision-maker for content, technical access, approvals, and go-live?
• Technical requirements: Are integrations, analytics, privacy, accessibility, security, and publishing workflows visible?
• SEO and migration: Are priority URLs, redirect planning, launch validation, and post-launch monitoring part of the expected scope?
• Commercial context: Are budget boundaries, timing constraints, and proposal instructions clear?
• Evaluation: Do agencies know how the decision will be made?

Try a 60-second test. Give the RFP to someone outside the core team and ask them to explain the objective, scope, constraints, unknowns, and selection process back to you. If they cannot, revise the document before outreach.

Do not hide unknowns to make the RFP appear complete. A visible question about content consolidation or CMS structure is far safer than an unstated assumption that appears late in delivery.

Conclusion: Create better decisions, not just more bids

A strong website redesign RFP helps agencies see the real project beneath the request for a new website. It gives them enough context to identify complexity, define responsibility boundaries, price with clearer assumptions, and recommend an appropriate discovery and delivery plan.

The goal is not to eliminate every unknown before selecting an agency. It is to surface the risks that affect scope, SEO, CMS operations, integrations, and launch readiness early enough for informed decisions.

Resolve internal disagreement where you can, state the remaining questions plainly, and evaluate proposals for how well they handle the work ahead, not only how attractive the presentation looks.