An RFP for a website redesign has to answer a question a brand-new site never asks: what happens to everything that already exists. You have live traffic, indexed pages, a CRM hooked into a contact form, and three years of blog posts ranking for terms you can’t afford to lose. A new-site brief can stay aspirational because there’s nothing to protect yet. A redesign RFP is diagnostic first, aspirational second, and most of the templates floating around skip the diagnostic half entirely.
That gap shows up fast once proposals start arriving. Ask five vendors to quote a “redesign” without an inventory of pages, integrations, and current traffic, and you get five different projects wearing the same word. One agency assumes a visual refresh on the current CMS. Another assumes a full replatform with new integrations. Neither is wrong, because you never told them which one you meant.
What a redesign RFP has to ask that a new-site brief doesn’t
Start by naming the kind of work this actually is. A visual redesign keeps the CMS, the content structure, and most of the integrations, and changes the look and the interface. A rebuild replaces the foundation: new CMS, new content model, possibly new integrations, with design coming along for the ride. W3C’s public redesign RFP made this distinction explicit, requiring an incremental redesign of its existing site with URL mapping, 301 redirects, and integration with existing back-end services, not a from-scratch build. Say which one you’re asking for before a vendor has to guess from your budget line.
Four things belong in a redesign RFP that a greenfield brief can skip: a current-site inventory, a content migration scope, SEO preservation requirements, and documentation of every integration the new build has to keep talking to. Google’s own site-move guidance backs the SEO piece up directly: map every old URL to its new destination, use permanent server-side redirects, update internal links and canonicals, submit a fresh sitemap, and avoid redirect chains longer than a couple of hops, since a chain can technically run ten deep but anything past three risks losing crawl budget along the way. None of that is optional cleanup after launch. It’s scope, and scope belongs in the RFP, not in a change order three weeks after kickoff.
This is also where website redesign and rebuild get confused on purpose. A vendor quoting a cheaper number because they scoped a visual refresh isn’t lying if your RFP never specified otherwise. If you’re trying to figure out what you actually need before any of this gets written down, write the job before the RFP: the document works a lot better when it follows a real decision instead of preceding one.
How to describe the current site so vendors stop guessing
Every practitioner source that publishes a redesign RFP checklist lands on the same list: page count and content types, current CMS and how it was built, named integrations like CRM, email, analytics, and payments, what’s working, what isn’t, and a traffic baseline with top pages and conversion numbers. Skip any of those and a vendor prices the unknown with a margin, which means you pay for their uncertainty instead of your own clarity.
The harder part isn’t the inventory, it’s naming why you’re doing this at all. Major Tom’s advice, updated earlier this year, is that the most useful section in a redesign RFP, and the one most often missing, is the actual pain: a CMS nobody wants to touch, a bounce rate that embarrasses the marketing team, mobile scores that keep failing, a CRM that never made it into the last build. Vendors read vision statements all day. What moves a proposal from generic to specific is a buyer who names the broken thing out loud.
Label your content honestly while you’re at it: retain, revise, merge, remove, or unknown. “Unknown” is a better answer than a hidden assumption buried in one vendor’s price and not another’s. We see this constantly in website redesign and custom websites work: the client who says “just keep what’s working” without naming which pages those are ends up with a vendor who guessed wrong about half of them.
Who scores the proposals, and on what
Decide the scoring committee and the criteria before the RFP goes out, not after proposals land. Responsive’s process guidance has marketing, sales or ops, and IT writing the questions together, then scoring the sections that match their expertise: IT on technical approach, sales and marketing on design and references. Keep the invited list to six vendors or fewer. More than that and the evaluation becomes a skim.
Publish your weighting or something close to it. One agency’s public framework splits scoring as relevant redesign experience at 25%, technical approach including migration and SEO at 25%, team and process at 20%, cost and value at 20%, and references at 10%. You don’t have to copy those numbers, but vendors who know cost is 20% of the decision write a different proposal than vendors guessing it’s 50%. North Dakota’s public procurement guide takes this further and keeps price hidden from the evaluation committee until after technical scoring is done, specifically so a cheap number doesn’t drag a weak proposal over a strong one on the first read.
My take: hide price during technical review if you can manage it internally, even on a private project. The buyers who see the number first consistently rate the same proposal lower on substance than buyers who score it blind. That costs you nothing but a little procedural discipline, and it’s the cheapest bias you’ll ever remove from a hiring decision.
Setting budget and timeline without boxing yourself in
Disclose a budget or a range. Every practitioner source on this topic agrees on that one point even when they disagree on everything else, because a hidden budget produces proposals that can’t be compared, only guessed at. Published bands vary wildly depending on who’s publishing them: one WordPress-focused agency puts a mid-range redesign with custom functionality at $40,000 to $80,000, while W3C’s own RFP cited an estimated $200,000 for a large institutional project with phased delivery. Treat any single number you read online as scope-dependent, not a market price, and ask for redesign cost guidance that matches your actual page count and integrations before you anchor on a figure that fits nobody.
Leave the CMS and the exact template count open if you genuinely don’t know what’s right, that’s a fair unknown for a vendor to help solve. Don’t leave content ownership, migration volume, integration scope, or your real launch deadline open. Those aren’t creative decisions, they’re facts about your organization, and an RFP that treats them as flexible is asking vendors to price a moving target.
We close roughly nineteen out of twenty projects on budget, and it has nothing to do with being conservative estimators. It’s that the scope gets written down, including the unglamorous migration and redirect work, before anyone opens a design file. A number that’s agreed on paper before kickoff survives scope creep a lot better than a number that gets negotiated after someone discovers the content migration was never actually scoped.
RFP and proposal are not the same document
The RFP is yours. You write it, state the need, and ask vendors to respond. The proposal is theirs, the vendor’s answer to your need, with an approach, a team, a price, and whatever exceptions they want on record. Direction of travel runs buyer to vendor, then vendor back to buyer. That sounds obvious until you read how often the terms get blurred in practice: searches for website redesign proposal pull up guidance for writing the buyer document and guidance for writing the vendor’s pitch, sometimes on the same page.
The GSA’s own framework for federal buyers draws a cleaner line that’s worth borrowing even outside government work: an RFQ is for when you already know exactly what you need and only want pricing, while an RFP is for when the approach itself is part of what you’re buying. Most website redesigns are the second kind. You’re not buying a fixed deliverable off a shelf, you’re buying judgment about how to protect a live site while rebuilding around it, and that judgment is exactly what a well-scored RFP is built to surface.