A website redesign is not the same thing as building a new website. But most RFP guides treat them identically, handing you a generic template and wishing you luck. The result is a document that fails to address the specific challenges of a redesign: protecting your existing SEO equity, migrating content without losing anything, preserving integrations that took years to build, and managing the expectations of users who already know your site.
I've been responding to website redesign RFPs for over 25 years. I manage roughly 200 WordPress websites at FatLab, and a significant number of those came to us after redesign projects went sideways.
It's a common scenario for us: an organization calls and says they just launched a new website, or they're about to launch, and they've decided they're not going to use the vendor who built it for hosting and support because they're not happy. That almost always traces back to the RFP and the contract. The RFP was vague, the scope was undefined, the vendor guessed at what was needed, and the organization ended up with something that didn't match what they had in their heads.
This guide covers what a website redesign RFP should include, why most redesign RFPs produce poor responses, and how to write an RFP for website redesign projects that makes high-quality vendors want to respond.
A Redesign RFP Is Not a New Build RFP
This distinction matters more than most organizations realize, and getting it wrong is one of the most common mistakes I see.
A new website build starts from scratch. There's no existing traffic to protect, no content to migrate, no integrations to preserve. You can be aspirational. A redesign, on the other hand, is diagnostic. You already have a website with real users, real traffic, real content, and real technical infrastructure. Your RFP needs to account for all of it.
Organizations frequently use the word "redesign" when what they actually need is a rebuild. They'll say they want a redesign because it sounds smaller and cheaper. But as I tell clients, there's really no point in putting a new coat of paint on an old system.
If your site was built on a page builder five years ago and you want modern functionality, that's a rebuild. If you want new integrations, new administrative tools, new capabilities, that's a rebuild. Calling it a redesign doesn't change the scope of work required.
There's really no point in putting a new coat of paint on an old system. It's our job as consultants to educate clients, not just let them use phrases in hopes of getting a lower bid.
There are legitimate redesigns. If your site was built with clean custom code and you're happy with how everything works from an administrative standpoint, but you just want a fresh visual design, that can be a true redesign. With WordPress, depending on how the original theme was set up, you can sometimes replace a theme without rebuilding the entire site. But even then, the RFP needs to be clear about what's changing and what isn't.
The first thing your RFP should establish is whether this is a redesign, a rebuild, or something in between. If you're not sure, say so. A good vendor will help you figure it out during discovery. But don't assume that using the word "redesign" will reduce your costs. A good vendor will call that out, and a bad vendor will just deliver less than you expected.
For a broader look at the entire RFP process, including what vendors think when your RFP arrives and the single most important thing to include, see our complete website RFP guide.
Why Bad Redesign RFPs Get Bad Responses
The quality of your RFP directly determines the quality of proposals you receive. Whether you call it a website redesign proposal request or a formal RFP, the principle is the same. I've watched this causal chain play out hundreds of times.
A vague RFP forces vendors to guess at scope. When vendors guess, they make different assumptions. One vendor assumes you need 50 pages migrated. Another assumes 200. One budgets for a full content audit. Another assumes you'll handle content yourselves. One includes SEO preservation work. Another doesn't mention it.
Now you have proposals ranging from $15,000 to $150,000 for the same brief. Comparing them is impossible because each vendor was answering a different question. So you end up selecting based on price or personality rather than fit. And that's how bad projects start.
Quality vendors routinely decline to respond to poorly written redesign RFPs. The effort-to-win ratio doesn't make sense. According to Responsive, agencies spend an average of 25 hours on each RFP response, and nearly half of all RFPs received are deemed not worth the effort. When 40 percent of vendors say the RFPs they receive are poorly written, the problem is systemic.
If the RFP is vague, the budget is missing, and it looks like the organization doesn't know what they want, the math simply doesn't work for a good agency to invest that time.
When you don't provide a budget, you're choosing the vendor based on whether they happened to hit your number, and that may not be your best vendor.
I personally skip a lot of RFPs. If they're poorly written, vague, and it's clear the organization is just shopping around without a clear budget, I'm not going to invest the time. And I know a lot of really good vendors who do the same. Your poorly written RFP isn't just wasting your time. It's actively filtering out your best options.
What Your Redesign RFP Must Include
A redesign RFP needs everything a standard website RFP does, plus several sections that are unique to projects involving an existing site. Here's what I look for when deciding whether to respond.
Current Site Inventory
Before you can describe where you're going, you need to document where you are. This is the diagnostic work that separates a good redesign RFP from a generic template.
Your RFP should include:
- Page count and content types. A site with 30 pages is a fundamentally different migration project than one with 300. Include blog posts, landing pages, resource libraries, member areas, and any dynamic content.
- Current CMS and how it was built. Are you on WordPress with a custom theme? A commercial theme with a page builder? Squarespace? Drupal? This determines the migration approach entirely.
- Current integrations. List every third-party system your website connects to: your CRM, email marketing platform, donation processor, event management system, member database, and analytics tools. Integration requirements are the most common source of budget surprises in redesign projects.
- What works and what doesn't. Be specific. "The design looks dated" is different from "our staff can't update content without breaking the layout." "We need better SEO" is different from "we've lost 40% of organic traffic over the past year." The more honest you are about your current problems, the better vendors can solve them.
- Traffic and analytics baseline. Share your current monthly traffic numbers, top-performing pages, and any conversion metrics you track. This gives vendors context for what they need to protect during the transition.
Organizations that skip this inventory work produce vague RFPs that force vendors to guess at scope. And guessing at scope is how projects go off the rails.
Content Migration Scope
Content migration is often the single largest hidden cost in a redesign. I've seen it add 20-40% to project budgets when it wasn't properly scoped up front.
Your RFP needs to address:
- Will content be migrated as-is, or audited first? A content audit adds time but can reduce migration scope significantly by identifying pages to retire. If you have 300 pages and only 150 are worth keeping, that's a meaningful difference in project scope.
- Who writes new content? If the redesign includes new messaging, new page copy, or new sections, that work needs to be scoped separately. Content creation can account for 15 to 25 percent of the total project cost when included. Don't treat it as an afterthought.
- Who approves migrated content? Stakeholder review of migrated content is one of the most common timeline bottlenecks in redesign projects. Define the review process in the RFP so vendors can plan for it.
- What formats exist beyond standard pages? PDFs, videos, embedded media, downloadable resources, event calendars, member directories. Each requires a different migration approach, and each affects the budget.
I always tell clients: if it doesn't have a bullet point, it's not in scope. The same principle applies here. If your RFP doesn't specify what happens with your existing content, don't be surprised when the vendor's approach doesn't match your expectations.
SEO Preservation Requirements
A poorly executed redesign can lose 20 to 60 percent of organic traffic. I've seen it happen, and the organizations that suffer this loss often don't realize it for months. By then, the damage is done, and recovery takes far longer than the redesign itself.
Your RFP should explicitly require:
- A complete redirect map as a pre-launch deliverable. Every old URL that changes must have a 301 redirect to its new equivalent. Catch-all redirects to the homepage destroy SEO equity page by page. This is non-negotiable.
- No daisy-chain redirects. If your site has been redesigned before, existing redirects should point directly to the final destination rather than through intermediate URLs.
- Title tag and meta description migration. Custom metadata should be transferred or rewritten, with SEO intent preserved. This is tedious work that often gets overlooked.
- Post-launch 404 monitoring. Require at least 90 days of monitoring to catch missed redirects. Weekly reports for the first month, then monthly.
- Google Search Console monitoring. Updated sitemap submitted within 24 hours of launch, with indexing requests for high-priority pages.
Two more items that are easy to overlook: structured data and schema markup should carry over to the new site, and analytics continuity needs to be explicitly addressed. Google Analytics, Google Tag Manager, conversion pixels, heatmap tools, and any custom event tracking all need to be transferred. Existing conversion goals should be replicated or improved, not lost in the transition.
If your website redesign RFP doesn't include SEO preservation requirements, most vendors won't include the work in their proposals. It's not because they don't know about it. It's because it's time-consuming, detail-oriented work, and if you didn't ask for it, they'll keep their price competitive by leaving it out.
Technical Requirements That Actually Mean Something
The technical requirements section distinguishes serious RFPs from wish lists. But it only works if you're specific.
"Must be mobile responsive" tells a vendor nothing. Every website built in 2026 is mobile responsive. What matters is whether you've looked at your analytics and know that 80% of your traffic is on desktop, or that 60% is on mobile, or that your members primarily access the portal on tablets. That context changes the development approach entirely.
The same is true for "SEO optimized." That phrase doesn't mean anything actionable. What you should be asking for is a discovery process to figure out what SEO competitiveness means for your specific organization. Are you competing for high-traffic keywords, or is this a small niche that just needs to follow best practices? Do you already have an SEO firm? These questions lead to real answers.
What does belong in your technical requirements:
- CMS preference or openness. State whether you're committed to WordPress, open to alternatives, or migrating from another platform. If you're staying on WordPress, specify whether you expect a custom-built theme or are open to commercial themes. This matters more than most organizations realize. I've seen beautiful websites that are absolute spaghetti code underneath, built by vendors whose answer to every problem is "install another plugin." A vendor who builds custom themes and writes their own code will deliver a product that lasts years and stays maintainable. A vendor stacking commercial themes and plugins will deliver something that looks similar but costs you more in the long run. Both types claim to be "developers."
- Performance targets. Specify measurable goals: page load time under 3 seconds, Core Web Vitals passing scores, and mobile performance parity with desktop.
- Accessibility standards. WCAG 2.1 AA is the current standard. Specify whether you need only automated testing or manual testing with screen reader verification.
- Hosting requirements. Who hosts the site after launch? Will the vendor provide hosting, or will you manage it separately? This affects the entire post-launch support model.
- Specific integrations. Don't just say "CRM integration." Name the CRM. Specify whether it's an existing integration that must be preserved or a new one being added. Note whether the API is documented. Integration work is where budgets blow up, and vague requirements make it worse.
For each integration, be explicit about whether credentials and technical documentation will be provided, whether the integration is existing or new, and who is responsible for testing it.
The Difference Specificity Makes
To illustrate: a bad capabilities section says, "We are a membership organization, and we want our members to be able to sign in and access member-only material." That's it.
A good version says, "We are a membership organization with three levels of members. We'd like members to log in and access directories, PDFs, and gated content based on their membership level. Additionally, we need members to pay their dues, track payments, and download previous year invoices."
The first version forces every vendor to guess. The second gives us a real starting point. You'd be surprised how many clients act like it's obvious that a member area should include donations. It's not. Not all membership organizations are dues-based. This is the information we need.
Budget and Timeline
I feel very strongly about including a budget in any RFP, and redesign RFPs are no exception. There are two kinds of organizations: those that have a budget and know what they want to spend, and those that don't know what things cost and are doing exploratory planning. Both are fine. But you need to be upfront about which one you are.
If you tell me what you can spend, I'll tell you what I can do for that. You'd be surprised. If the project is good, I might be willing to do a lot more for less.
If you have a defined budget, share it. Even a range works. We're all playing on the same field. If you genuinely don't know what's reasonable, say so and declare you're seeking guidance on pricing. What's not fair is saying "let's see what you come up with" and then rejecting proposals because they came in above a number you never shared.
What Redesigns Actually Cost
For context on typical 2026 pricing:
- Simple visual refresh (10-20 pages, existing CMS): $5,000 to $15,000
- Small organization redesign (20-50 pages, possible CMS migration): $15,000 to $40,000
- Mid-range redesign (50-100 pages, custom functionality): $40,000 to $80,000
- Large project (100+ pages, complex integrations): $80,000 to $150,000
Your website is a 24/7 window into your organization, and this is not the place to cut corners. I get that there's sticker shock, but underinvesting in a redesign almost always costs more in the long run through fixes, rework, and lost opportunities.
One more thing: build a 10-20% contingency buffer into whatever budget you set. For a $60,000 project, that means budgeting $66,000 to $72,000. This is not padding. It accounts for the inevitable discoveries during development that nobody could have anticipated from the RFP alone.
Realistic Timeline Expectations
Be realistic about what you're asking for. A typical mid-range redesign, something in the range of 50 to 100 pages with custom functionality, runs 14 to 20 weeks from kickoff to launch. That breaks down roughly as:
- Discovery and strategy: 2 to 4 weeks
- Design: 3 to 5 weeks
- Development: 4 to 6 weeks
- Content migration: 2 to 4 weeks (often overlapping with development)
- QA and testing: 2 to 3 weeks
- Launch and stabilization: 2 to 4 weeks
For larger redesigns, consider whether a phased launch is acceptable. Launching the core site first and rolling out secondary sections, member portals, or complex integrations in a second phase reduces risk and gives your team time to adjust. State in the RFP whether phased delivery is an option or if the entire site must launch at once.
The single biggest cause of timeline delays is slow client feedback, followed closely by content that isn't ready when it's needed. If content creation or approval is on your side, it will be the bottleneck. Projects regularly extend by 30 to 50 percent beyond initial estimates due to content delays.
Keep in mind that the RFP process itself takes time before project work begins. Between drafting, vendor Q&A, proposal response periods, evaluation, presentations, and contract negotiation, most organizations spend 9 to 18 weeks on the RFP process alone. Organizations routinely underestimate this, then compress the actual project timeline to hit the same launch date.
If you have hard deadlines, state them and explain why. "We need to launch before our annual conference in October" gives useful context. "We need this done in six weeks" for a complex redesign tells vendors you don't understand what you're asking for, and many good ones will pass.
Evaluation Criteria
Tell vendors how you'll evaluate their proposals. This seems obvious, but most redesign RFPs skip it. When vendors don't know your criteria, they guess what to emphasize, making proposals harder to compare.
A straightforward scoring framework might weight:
- Relevant redesign experience: 25%. Not just portfolio screenshots, but case studies from comparable projects with measurable results.
- Technical approach: 25%. How they plan to handle migration, SEO preservation, and your specific integrations.
- Team and process: 20%. Who will actually work on your project, how they communicate, and how they handle changes.
- Cost and value: 20%. Total cost relative to scope, with line-item transparency.
- References: 10%. Verifiable references from comparable redesign projects.
When checking references, ask specific questions: Did the project launch on time? Were there significant cost overruns? How did the vendor handle scope changes? Would you hire them again? These questions reveal more than any portfolio ever could.
Look Under the Hood
One thing I'd add here: look at what vendors actually build, not just what their portfolios look like. I've held this role as a technical consultant for clients, evaluating proposals from other vendors because we're going to handle hosting and support long-term.
What I do is visit their portfolio sites and inspect the code. Are they building custom themes or using bloated commercial themes? Is every problem solved by installing another plugin? There's no regulatory body in our industry, no standard for what people pay for websites, so that pricing can be all over the place. I've seen proposals where the vendor bid $150,000 for a nonprofit website I would have built for $30,000 to $40,000. That's a clear case of someone taking advantage of a client who didn't understand the technical scope.
On the other end, be wary of the lowest bidder. A cheap proposal is often designed to win the project: give a low number without defining exactly what gets built, then deal with scope later. If it's too good to be true, it probably is. You probably don't want your lowest bidder, and you probably don't want your highest bidder either. If you like the lowest bidder, go back and ask why their number came in so low. You'll likely discover that things weren't included.
For a deeper framework on evaluating what comes back, see our guide to evaluating website proposals. And for the specific warning signs that should give you pause, see our breakdown of red flags in website vendor proposals.
Post-Launch Requirements
This is one of the biggest gaps in redesign RFPs, and one of the first things I look for when evaluating whether an organization has thought through its project. The launch is not the finish line.
Your RFP should address:
- Warranty period. Define how long the vendor will fix bugs and issues at no additional cost after launch. Thirty days is the minimum. Sixty is reasonable for mid-range projects. Ninety days is best practice for complex redesigns that need time for edge cases and seasonal functionality to surface.
- Training. Specify CMS training for your content editors, typically 2 to 4 hours of live training that should be recorded for future staff. Written documentation covering common tasks is also a required deliverable.
- Ongoing maintenance and support. Ask vendors to propose or price ongoing support: WordPress updates, security monitoring, backups, and ad-hoc development hours. If you don't include this in the RFP, you can't compare proposals where one vendor includes 12 months of support and another quotes just the build.
- Code and asset ownership. Your organization should own all custom code, design files, and content. This should be non-negotiable. The site should be portable. If the relationship ends, you should be able to move to another host and another vendor without penalty or technical barriers.
- Access documentation. All logins, API keys, and administrative access must be documented and transferred at project completion.
Common Redesign RFP Mistakes to Avoid
Beyond the general problems that plague all website RFPs, an RFP for website redesign work has its own specific failure modes.
Treating Content as an Afterthought
Content is the primary reason your website exists, yet redesign RFPs routinely treat it as something to figure out later. "Client will provide content" has killed more project timelines than any technical challenge I've encountered.
If your organization is responsible for content, the RFP should define milestones, deadlines, and consequences for late content. Every vendor has experienced this, and the good ones will tell you so upfront. See the content migration scope section above for what to include.
Ignoring What You Already Have
Many redesign RFPs read as if the current website doesn't exist. They describe the desired outcome without documenting the starting point, which forces vendors to do their own research into your existing site. The current site inventory section above covers exactly what to document. Skipping that work is one of the most reliable ways to produce proposals that miss the mark.
Stakeholder Creep
The RFP was written by marketing, but IT has opinions about the CMS; the membership team needs portal features; the executive director wants a blog; and the development team needs donation integration. None of these were in the original scope because nobody asked those departments during the RFP drafting process.
Define your decision-making structure in the RFP. Name the project lead. Specify who has approval authority. Identify which departments need input and ensure their requirements are captured before you send the document out.
Skipping Discovery
Any website redesign proposal request that jumps straight to "here's what we want, bid on it" without allowing for a discovery phase produces lower-quality outcomes.
A discovery phase, typically 2 to 4 weeks, includes stakeholder interviews, a content audit, a technical audit of your current site, and user research. Some organizations hire a vendor for discovery as a separate engagement before writing the redesign RFP. This approach typically costs $5,000 to $15,000 but can save multiples of that by preventing scope misalignment.
If you're not willing to do a separate discovery engagement, at least include discovery in the RFP as the required first phase of the project. Make it clear that the proposed budget and timeline may change based on what discovery reveals.
This is something I do in every project we win. In that first discovery meeting, I tell everyone in the room: this is your dream. What do you want this website to do? I know what was in the RFP and what the budget is, but I haven't brought that up yet. This is the time to get everything on the table.
Almost every time, that meeting surfaces ideas and requirements that were never in the RFP. Then I can go back to the organization and say, "There were a lot of great ideas in there, but none of them were mentioned in the RFP. Can we revisit the scope, the budget, the timeline?"
Projects don't fail because the vendor built something poorly. They fail because nobody forced the hard conversations about scope before the contract was signed.
Using a Template as a Starting Point
There's absolutely nothing wrong with using a template to structure your redesign RFP. In fact, I encourage it. If you use a template from a place like FatLab, what we're providing is the outline we'd like to see. If you structure your RFP the way we'd like, we can answer it more accurately. A more accurate answer gives you better timelines, a more realistic budget, and a tighter scope.
The key is using the template as a thinking tool, not just a form to fill out. Pull more than one template. Compare them. Use them to make sure you haven't missed anything.
We've put together a website RFP template that reflects what vendors actually need to see, along with real examples of effective vs. ineffective RFP language to help you understand the difference specificity makes.
But remember: an RFP for website redesign needs more than what a standard template covers. Whatever template you start with, you need to add sections for your current site inventory, content migration scope, SEO preservation requirements, and integration documentation. Generic templates treat redesigns and new builds identically, and that gap is where projects fall apart.
What Makes Vendors Want to Respond
I'll close with something no other redesign RFP guide discusses: what makes a quality agency actually want to respond to your RFP.
Good vendors are selective. They have to be, because responding to an RFP takes significant time and effort. Here's what signals that an RFP is worth responding to:
A defined scope with specifics. Bulleted lists of what the website needs to do. What users should accomplish. What administrators need to manage. Not "sleek modern design" but concrete functional requirements. Bulleted lists are better than general descriptions because they give us a real starting point.
A stated budget or honest acknowledgment that you need pricing guidance. This tells vendors you're serious and organized. It lets us right-size our recommendations instead of guessing.
A realistic timeline. If your timeline is physically impossible for the scope you're describing, that tells us you don't understand what you're asking for. That's a red flag.
A defined decision-making process. Nothing kills vendor enthusiasm faster than learning that every decision needs approval from a committee of 12. Name your decision-maker.
Evidence that the process is genuine. If vendors suspect the RFP is already wired for another firm, most good ones won't participate. I've seen what happens: the organization collects all the bids, gathers the good ideas, scope suggestions, and pricing, and hands it all over to their vendor of choice, who then puts together a winning bid using everyone else's work.
According to Loopio, incumbent vendors win 60 to 90 percent of formal RFP processes. The non-incumbents know this, and if they sense it, they won't invest the effort. Run an honest process, or don't run one at all.
The website redesign RFP that produces the best project isn't the longest or the most formally structured. It's the one that honestly describes your current situation, clearly states what you need, and gives vendors the information to respond accurately. Everything else follows from that.
If you're choosing a vendor for the first time or want guidance on what separates good development partners from order-takers, see our guide on how to choose a web developer or agency. And if your organization is a nonprofit with procurement requirements, board involvement, or grant-funded budgets, our nonprofit website RFP guide covers the considerations specific to your situation.
Frequently Asked Questions
How long should a website redesign RFP be?
A well-written redesign RFP typically runs 8 to 15 pages, depending on the complexity of the project. Length matters less than specificity. A 5-page RFP with detailed requirements, a clear content inventory, and a stated budget will outperform a 30-page document full of vague aspirational language. Focus on giving vendors the information they need to respond accurately rather than hitting a page count.
Should I include my budget in a website redesign RFP?
Yes. Including a budget or a budget range is one of the most effective ways to improve proposal quality. When vendors know what you can spend, they can right-size their recommendations, and you can compare proposals on an even playing field. If you genuinely do not know what is reasonable, say so and ask vendors to provide guidance. The worst approach is to withhold a number you already have in mind and then reject proposals that miss it.
How many vendors should I send my redesign RFP to?
Three to five vendors is the sweet spot for most redesign projects. Fewer than three limits your options for your website redesign proposal request, and more than five creates an evaluation burden that slows down the process without improving outcomes. Choose vendors whose portfolios and specialties align with your project type rather than casting the widest possible net.
What is the difference between a website redesign and a website rebuild?
A redesign updates the visual design and user experience of an existing site while preserving the underlying structure, CMS, and codebase. A rebuild replaces the technical foundation entirely, often including a CMS migration, new integrations, and restructured content. Many organizations say "redesign" when they actually need a rebuild, which creates scope confusion and budget misalignment from the start.
How do I protect my SEO during a website redesign?
The most critical step is to require a complete 301 redirect map as a pre-launch deliverable, ensuring that every old URL that changes points to its new equivalent. Your RFP should also require title tag and meta description migration, structured data preservation, submission of an updated sitemap within 24 hours of launch, and at least 90 days of post-launch 404 monitoring. If these requirements are not in your RFP, most vendors will not include the work in their proposals.
When should I hire a consultant before writing a redesign RFP?
If your organization lacks in-house web expertise, a pre-RFP discovery engagement can prevent costly scope misalignment. This is especially valuable when you are unsure whether you need a redesign or a rebuild, when you have complex integrations that need documentation, or when internal stakeholders have conflicting requirements. A discovery engagement typically costs $5,000 to $15,000 but can save multiples of that by producing a more accurate RFP.
FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. We've been reading, writing, and responding to website RFPs for over 25 years. If you're preparing for a website redesign and want guidance on the process, get in touch.