Website Redesign RFP: How to Scope the Project and Compare Proposals

Most website redesign RFPs fail in one of two opposite ways.

Some are so vague that agencies can’t scope or price the work responsibly. “We need a modern, user-friendly website” tells a vendor almost nothing, so each one fills the gaps with its own assumptions, and the proposals that come back can’t be compared.

Others are so prescriptive that they lock in a solution before anyone has looked closely at the problem. They specify the platform, the number of templates and the page list in detail, leaving qualified agencies little room to say, “There’s a better way to do this.”

A useful website redesign request for proposal sits between those extremes. It defines the problem, the desired outcomes, the boundaries and the decision criteria without pretending the organization already knows the solution.

In practice, a strong RFP explains:

• your business context and why the project is happening now
• what the current website does, and what’s wrong with it
• the outcomes you want for customers and internal teams
• what is known to be in scope and out of scope
• real constraints, such as systems, integrations, timing and content ownership
• budget and timeline expectations
• exactly what vendors must submit
• how proposals will be evaluated

The goal is to make proposals comparable, not identical. Every invited vendor should receive the same useful starting information and the same response requirements. A good agency should still be free to challenge an assumption and recommend a better approach.

This guide explains when you need a formal RFP, what to include, which questions to ask agencies, how to compare proposals and how to avoid common mistakes. It ends with a copyable outline you can adapt.

Do You Actually Need a Website Redesign RFP?

Not every redesign needs a formal RFP. There are three common paths, and the right one depends on how much you know and how you need to select a partner.

A formal RFP is useful when several vendors must respond to the same information, when your organization has a formal procurement or selection process, or when you need comparable written proposals for approval. Organizations with formal procurement, approval or vendor-selection requirements often fall into this group.

A project brief is often enough when a private company is talking to a smaller, already-qualified shortlist. It covers context, goals, scope and budget without the overhead of a formal procurement document. Many of the principles in this guide still apply; the document is simply lighter.

Discovery first makes sense when you know the website has problems but can’t yet define the real scope. Major technical, content or user-experience questions may still be open. In that situation, fixed proposals would be based on guesses. A paid discovery or assessment phase can produce the clarity needed for a better RFP or brief later.

If your organization has formal procurement rules, those rules come first. Legal, contractual and procurement requirements should be reviewed by the people responsible for them in your organization. This guide is about making the content of the document useful, not about procurement law.

What Makes a Website Redesign RFP Useful?

The core idea is simple: comparable information plus room for professional judgment.

Comparable information means every vendor works from the same facts about your organization, your website, your goals and your constraints, and answers in the same format. Room for judgment means you describe the need rather than inventing an implementation, so qualified vendors can recommend how to meet it.

Consider the difference:

• Over-prescribed: “Build exactly 23 templates in Technology X.”
• More useful: “Editors need to publish the identified content types without developer assistance.”

The second version tells vendors what has to be true when the project is finished. It lets them propose the number of templates and the technology that fit. If Technology X genuinely is required, because it’s your organization’s standard or other systems depend on it, say so clearly and explain why.

When drafting requirements, it helps to separate three things:

Many RFPs mix these together. When everything reads as mandatory, vendors either price for things you don’t really need or quietly ignore requirements they think are wrong. Neither helps you compare.

NogaTech’s Website Redesign RFP Framework

To organize the document, NogaTech uses a practical six-part framework for website redesign RFPs:

Context → Current State → Outcomes → Scope → Constraints → Selection

This isn’t an industry standard or a required format. It’s a way of making sure the RFP moves logically from why the project exists to what vendors need to understand, propose and be evaluated against.

Context. Who is the organization? Who uses the website, and what role does it play in the business? Why is the project happening now? A vendor who understands the “why” will make better recommendations about the “how.”

Current State. What exists today? This includes the website, the CMS or platform if known, the rough number of pages, the content, analytics, forms and integrations. It also includes the problems you know about, and the useful assets worth protecting, such as strong content, valuable pages or a working integration.

Outcomes. What should become easier or better for customers and for your internal team? Describe outcomes in practical terms. If you have reliable baseline data, include it. If you don’t, don’t invent targets. “We don’t currently track this reliably” is honest, and it tells vendors that measurement setup may be part of the work.

Scope. What appears to be included, what is definitely included and what is definitely excluded? Distinguishing these helps vendors see where their recommendations are welcome and where boundaries are firm.

Constraints. Timing, existing systems, integrations, content ownership, accessibility requirements, procurement rules and any genuine platform dependencies. These are the things vendors must work within.

Selection. What vendors need to submit, by when, and how proposals will be evaluated. Defining this upfront is what makes proposals comparable.

What to Include in a Website Redesign RFP

The sections below follow the framework. You won’t need every detail in every RFP. Include what’s relevant and true, and be explicit about what you don’t know.

Organization and business context

Briefly describe your organization, your main audiences or users, your products or services and the role the website plays. For example, it might generate leads, support existing customers, recruit members, take bookings or publish information. Name the key stakeholders who will be involved in decisions. Most importantly, explain why the project is happening now: a rebrand, a new service line, a failing platform, a merger, persistent user complaints or a strategic shift.

Current website

Share the relevant facts: the current URL, the CMS or platform if known, the approximate site size if known, the important sections, the forms, the analytics tools, any integrations and who manages content today. Describe known problems honestly, and point out useful assets worth keeping.

You don’t need to know every technical detail. If you’re unsure which platform runs a feature, or how many pages exist, it’s often better to write “Unknown — vendor should assess” than to guess. A wrong guess can send every proposal in the wrong direction.

Problems and goals

Separate the current problem from the desired outcome, because vendors need both.

“Make it modern” is a common request, but it isn’t a requirement. Try translating vague statements into operational or user needs:

These are fictional illustrations, not recommended goals. Your own wording should reflect your situation.

Scope

Potential scope areas include discovery, strategy, information architecture, UX, visual design, content, development, CMS setup, integrations, content migration, redirects, QA, launch, training, documentation and post-launch support.

Not every redesign needs every item. A focused visual refresh may need very little of this list. A redesign that changes platform, structure and content will need much more. If you’re unsure whether the existing technical foundation should stay, NogaTech’s guide to website redesign vs. website rebuild covers that decision.

A simple way to communicate scope is to describe what stays, what changes, what’s added and what’s excluded.

Content responsibilities

Content can become a major source of misunderstanding in redesign projects when responsibilities are not defined. Spell out who will:

• audit existing content
• write or revise content
• supply photography and other media
• approve content
• enter content into the new CMS
• migrate existing content

These choices affect scope and schedule directly. If the agency writes and migrates content, its proposal needs to include that effort. If your team does it, the schedule depends on your team’s availability. Delays can happen when each side assumes the other is handling content.

Technical requirements and dependencies

List the systems the website genuinely depends on or must connect to. These might include the CMS, hosting, forms, CRM, analytics, booking, payments, APIs, authentication or other business systems. For each, say what it does, whether it must be kept, and who manages it.

Avoid arbitrary technology requirements. If your organization has a genuine platform standard, state it and explain why. If you don’t, describe what the platform needs to do and ask vendors to recommend an approach, including the assumptions behind it.

The same principle applies across the whole RFP: describe what must be true at the end of the project, and keep genuine constraints explicit.

SEO, migration and accessibility requirements

At the RFP stage, you don’t need a full migration plan. You do need to tell vendors what must be protected and ask them to explain how they’ll handle it.

For search and migration, identify your important existing URLs and high-value landing pages, along with any content or metadata that matters. State that you expect redirects wherever URLs change, analytics to continue working, and a clear owner for migration tasks. Google Search Central’s guidance on site moves with URL changes recommends mapping old URLs to new ones and using server-side permanent redirects. It also recommends updating internal links and sitemaps, then monitoring both sites. It also notes that rankings may fluctuate while Google recrawls and reindexes a site. A proposal should show the vendor understands this work. It shouldn’t promise that rankings will be preserved. The full process is covered in NogaTech’s guide to website redesign SEO.

For accessibility, state any requirement your organization has, and ask vendors how they address accessibility in design, content and development, and how they test it. The W3C’s Web Content Accessibility Guidelines (WCAG) are published web accessibility standards. WCAG 2.2 is the latest version, and W3C encourages using the latest version. W3C’s guidance on planning and managing web accessibility recommends integrating accessibility throughout the web production process and evaluating early and regularly. Which legal obligations apply to your organization is a separate question for your legal advisers. Meeting a WCAG level isn’t automatically the same as legal compliance.

Finally, describe your QA expectations: which devices, browsers, forms and key user journeys must be tested before launch, and who signs off.

Budget and pricing expectations

Many organizations hesitate to share a budget, but some budget guidance usually helps. A range, or even a ceiling, lets vendors propose a realistic scope instead of guessing at your expectations. Without it, one vendor may propose a lean refresh and another a full rebuild, and neither is easy to compare.

Whatever you share, ask every vendor to break their pricing down in the same way:

• base scope
• assumptions
• exclusions
• optional work
• recurring costs
• licenses and third-party costs
• how change requests will be handled

For a deeper look at what drives redesign pricing, see NogaTech’s guide to website redesign cost.

Timeline and decision process

Publish your procurement milestones so every vendor works to the same dates. Typical milestones are the RFP issue date, the deadline for vendor questions, when shared clarifications will be sent, the proposal deadline, shortlist or interview dates, final selection, the expected project start and the desired launch.

A desired launch date is useful context, but it isn’t evidence that the redesign can responsibly be completed by then. Explain why the date matters, such as an event, a campaign or a contract end. Ask vendors to say whether it’s realistic for their proposed scope, and what would need to be true to meet it.

Required proposal format

If every vendor answers in a different format, comparison becomes guesswork. Ask each one to cover the same points, ideally in the same order: their understanding of the project, proposed approach, recommended scope, team, relevant experience, assumptions, timeline, pricing, exclusions, references or other proof where appropriate, support and handoff, and answers to your required vendor questions.

You can still invite vendors to recommend a different approach. Ask them to explain it within the same structure, so the difference is visible.

Common Website Redesign RFP Mistakes

Most RFP problems are easy to avoid once you know to look for them.

• Starting with “make it modern.” Visual freshness may be part of the goal, but it doesn’t explain what’s wrong or what should improve.
• Failing to explain the business problem. Without the “why,” vendors can only respond to the surface request.
• Prescribing the solution too early. Requiring a specific platform, template count or page list before discovery can rule out better options.
• Hiding known problems with the current site. If forms break, content is outdated or an integration is fragile, say so. Vendors will find out eventually, and their pricing will be more accurate if they know now.
• Leaving content responsibility undefined. Content is a common source of scope disputes and delays.
• Forgetting forms and integrations. A form that feeds a CRM or a booking system is a dependency that has to be scoped.
• Forgetting SEO and URL migration. If URLs change without a plan, valuable pages can lose search visibility.
• Requesting fixed pricing against undefined scope. A fixed price for an unclear project either carries a large contingency or leads to change requests.
• Giving no budget context. Vendors are left guessing how ambitious their proposals should be.
• Presenting an unrealistic launch date without context. Explain why the date matters and ask whether it’s achievable.
• Requesting different response formats from every vendor, or giving no format at all. Comparison becomes much harder.
• Having no selection criteria. Decisions then default to presentation quality or price.
• Judging only portfolios. Attractive past work doesn’t show how a vendor would approach your specific problem, constraints and content.
• Failing to define ownership and handoff. Ask what you’ll own at the end: accounts, code, design files, content and documentation.
• Turning the RFP into a huge feature wishlist. A long list of “nice to haves” makes scope and pricing harder to compare. Separate essentials from options.

How to Compare Website Redesign Proposals

Define your evaluation criteria before proposals arrive. Doing so keeps the decision tied to what matters to your organization, rather than to whichever proposal happens to be most persuasive. It also lets you tell vendors in the RFP how they’ll be evaluated.

Criteria you might use include:

• understanding of the problem
• proposed approach
• scope completeness
• relevant experience
• technical fit
• SEO and migration planning
• accessibility and QA approach
• team and communication
• timeline realism
• pricing clarity
• handoff and support

There’s no universally correct weighting. Some organizations prioritize migration risk, others technical fit, others budget certainty. Weight the criteria according to your actual priorities, and agree those weights internally before you read the proposals.

Be careful comparing headline totals. One proposal may include content migration, redirects and training while another lists them as exclusions or optional extras. Before comparing price, line up scope, assumptions and exclusions side by side. Shared clarification answers help here, because every vendor responded to the same information.

Interviews or presentations with shortlisted vendors are useful for testing how a team thinks. Ask them to talk through your project, not just their portfolio.

Shared deadlines and clarifications also matter. A typical selection sequence looks like this, though organizations may adapt or shorten it.

15 Questions to Ask Every Website Redesign Agency

Include these in your RFP as required questions, or use them in interviews. Asking every vendor the same questions makes answers easier to compare.

Copyable Website Redesign RFP Outline

Use this outline as a starting point. Replace the bracketed prompts with your own information, and remove sections that don’t apply. It’s a planning document, not a contract. Any legal or contractual terms should come from your organization’s legal or procurement team.

1. Project Summary

[Organization] is seeking a qualified website partner to [redesign / restructure / replatform] [website URL]. The project aims to [one or two sentences describing the main outcome]. Proposals are due by [date].

2. Organization

[Organization] is a [type of organization] that provides [products/services] to [main audiences]. The website’s main role is to [generate inquiries / support customers / publish information / take bookings / other].

3. Why We’re Redesigning

We’re undertaking this project because [reason: rebrand, platform issues, user complaints, new services, strategic change]. The main problems with the current site are [list known problems].

4. Current Website

• URL: [URL]
• CMS/platform: [name, or “Unknown — vendor should assess”]
• Approximate size: [number of pages, or “Unknown”]
• Important sections: [list]
• Forms: [list and where submissions go]
• Analytics: [tools in use, or “Not reliably tracked”]
• Integrations: [list]
• Content managed by: [team/role]
• Assets worth keeping: [content, pages, imagery, functionality]

5. Audiences/Users

Our main audiences are [audience 1], [audience 2] and [audience 3]. They typically use the site to [key tasks]. Internal users include [teams that update or rely on the site].

6. Goals and Desired Outcomes

[If baseline data exists, include it. If not, state that measurement may need to be established.]

7. Known Scope

• Keep: [content, URLs, integrations or functionality that should remain]
• Change: [areas needing improvement]
• Add: [new pages, features or capabilities]
• Out of scope: [items intentionally excluded]
• Open questions: [items where we want the vendor’s recommendation]

8. Content Responsibilities

9. Functional/Integration Requirements

The new website must [list genuine functional needs]. It must connect with [systems: CRM, booking, payments, analytics, other]. [State any genuine platform or hosting constraint and the reason for it.]

10. SEO/Migration Requirements

Important URLs and landing pages: [list or attach]. We expect [redirects where URLs change / analytics continuity / preservation of key content and metadata]. Please describe your approach to migration planning, redirects and post-launch checks, and who is responsible for each task.

11. Accessibility and QA Expectations

Our accessibility requirement is [standard or level, if your organization has one]. Please describe how you address accessibility in design, content and development, and how you test it. QA should cover [devices, browsers, forms, key user journeys]. Sign-off will be given by [role].

12. Budget or Budget Guidance

Our budget guidance for this project is [range / ceiling / “to be discussed”]. Please separate base scope, assumptions, exclusions, optional work, recurring costs, third-party or license costs, and your approach to change requests.

13. Timeline and Selection Dates

Please tell us whether the desired launch date is realistic for your proposed scope.

14. Proposal Response Requirements

Please structure your proposal as follows: understanding of the project; proposed approach; recommended scope; team; relevant experience; assumptions; timeline; pricing; exclusions; references or proof where appropriate; support and handoff; answers to the vendor questions in Section 15.

15. Vendor Questions

Please answer each of the following questions: [insert the questions you want every vendor to answer, such as the 15 above].

16. Selection Criteria

Proposals will be evaluated on [list criteria, such as understanding of the problem, approach, scope completeness, experience, technical fit, migration planning, accessibility/QA, team, timeline realism, pricing clarity and handoff]. [Optional: state relative weighting, if your organization has agreed one.]

17. Contact / Clarification Process

Questions should be sent to [name, role, email] by [date]. Answers will be shared with all invited vendors by [date]. Please don’t contact other staff about this RFP during the selection period. [Add any procurement rules required by your organization.]

Frequently Asked Questions