The red flags that kill an enterprise website redesign aren't in the proposals you get back. They're in the RFP you sent out.
Most teams don't see it that way. They treat the RFP as a filter, a way to sort credible vendors from the ones who'll overpromise and underdeliver. So they read every response looking for warning signs: vague timelines, padded teams, portfolios that don't match the pitch. All of that is worth doing.
But it's the wrong place to look first.
Your RFP is the first governance document of the redesign. Whatever it specifies is what your vendor can be held to. Whatever it leaves out becomes your problem after launch, when the contract is signed and the leverage is gone. The most consequential website redesign RFP red flags aren't vendor behaviors at all. They're the questions your own team never asked.
This is one piece of the strategic frame for evaluating redesign partners, and it starts from an uncomfortable premise: the document you wrote to evaluate vendors is the document most likely to be evaluating you.
What follows moves from what an RFP is actually for, through the specific gaps that turn up in nearly every enterprise version, to the disciplines that turn a procurement form into something that protects the project.
A well-structured RFP does its most important work before anyone reads it
Here's the part that gets missed: the best thing a well-structured RFP does has nothing to do with vendors.
It forces your own team to agree on what you're building.
Writing requirements down is how internal disagreement surfaces. Who owns content quality after launch? What does "done" mean for accessibility? Which team is accountable when organic traffic drops in week three? These questions have answers. The RFP is where you find out whether your organization has agreed on them, or whether five stakeholders have five different versions in their heads.
When you skip that work, you don't avoid the disagreement. You defer it. And deferred disagreement doesn't get cheaper. It surfaces during the build, when changing course costs real money, or after launch, when it costs the thing you redesigned to protect.
The components most enterprise RFPs are missing aren't technical. They're governance provisions. Who owns what after the vendor packs up and leaves. Who monitors quality once the project team disbands. Who is accountable for compliance in month six, when nobody remembers the launch and the agency's invoice is long paid.
Parachute Design Group has practical guidance on how to write an RFP for UX and redesign work, and it's a reasonable baseline for structure. But structure isn't the gap. Coverage is.
Vague language is where this becomes contractual. When a requirement isn't specified, both sides get a defensible reading of it. You think "modern, accessible design" meant WCAG 2.2 AA. Your vendor thinks it meant "looks current." Neither of you is lying. You just never wrote it down, so now you're negotiating it in a meeting nobody budgeted for.
The most dangerous red flags are the ones you built in
Ask a room of digital leaders to name RFP red flags and you'll get a familiar list. Unrealistic timelines. Lowball pricing. Scope that keeps moving.
Those are real. They're also not the ones that sink projects.
The red flags that do the damage are omissions. Not what the RFP asks badly, but what it never asks at all. And because they're absences, your review process is built to miss them: you can't catch a requirement that isn't on the page.
Start with scope. Everyone treats vague scope as a vendor problem, something the agency should have pinned down. It's not. Vague scope is a symptom of undecided internal governance. The RFP didn't make the scope fuzzy. The RFP revealed that your team hadn't decided, and then handed that indecision to a vendor who priced around it.
Now the one that costs the most and shows up the least: accessibility.
An RFP that doesn't name an accessibility standard is guaranteeing a compliance gap. Not risking one. Guaranteeing one. If you don't specify WCAG 2.2 success criteria and a conformance level, your vendor will build to whatever they assume, which is usually nothing in particular. The result is a redesigned site that's less accessible than the one it replaced, discovered after launch, by someone who files a complaint.
For public sector and regulated buyers this isn't optional reading. Section 508 digital accessibility requirements apply to federal agencies and their contractors, and the Department of Justice's web accessibility guidance has given accessibility obligations direct legal grounding. An RFP that stays silent on conformance isn't being neutral. It's choosing exposure.
Measurement is the other silent omission. Most RFPs say nothing about preserving analytics continuity or monitoring quality after go-live. So tracking breaks during migration, nobody specified that it shouldn't, and you lose the ability to prove whether the redesign worked at the exact moment you need to.
These gaps share a quality: they're invisible until they're expensive. Which is why the cost categories most RFPs underspecify tend to be accessibility, measurement, and governance, the same three that never make the requirements list.
Clarity is not completeness
Here's a distinction worth holding onto, because confusing the two is how good-looking RFPs fail.
Clarity is how well your RFP communicates. Completeness is whether it covers the right things.
You can have one without the other. An RFP can be beautifully clear about an incomplete set of requirements. Clean language, well-organized sections, precise about everything it mentions, and silent on everything it doesn't. It reads well in review. It still leaves the project exposed.
Most internal RFP reviews optimize for clarity. People read for tone, for whether the asks make sense, for whether a vendor could understand it. Almost nobody reads for what's absent. And absence is the more consequential failure, because a clear question with no answer is a problem you can negotiate, while a question that was never asked is a problem you don't know you have.
So review for completeness against the categories that actually carry redesign risk:
- Governance and ownership: who decides, who's accountable after launch, how standards get enforced
- Accessibility and compliance: named standard, conformance level, regression expectations during migration
- Content quality and migration: what gets migrated, what gets retired, who audits before the move
- Performance and discoverability: redirect integrity, crawl equity, technical SEO continuity
- Measurement continuity: analytics preservation, tracking validation, baseline metrics
- Operational QA: testing stages, staging requirements, rollback planning
- Post-launch governance: who monitors quality once the project team is gone
Run your RFP against that list. The two categories most often missing are measurement continuity and post-launch monitoring, and their absence isn't a small gap. It's the difference between treating the redesign as a project with an end date and treating it as the start of an ongoing quality program. A site that launches well and decays quietly over the following year is the most common enterprise outcome, and it traces back to an RFP that never required anyone to keep watching.
Misalignment is a governance problem, not a communication problem
When an RFP process goes sideways, the usual diagnosis is communication. The vendor misunderstood. We weren't clear enough. We should have had more calls.
Mostly wrong.
The problem isn't getting vendors to understand your requirements. It's that your stakeholders never agreed on the requirements before the RFP went out. You can't communicate alignment you don't have.
This is why the absence of certain people from the RFP process is itself a red flag. When accessibility leads, analytics owners, and content governance teams aren't in the room while requirements are written, their requirements don't get written. Then those gaps surface after the contract is signed, as scope disputes, as "we assumed that was included," as the expensive discovery that a whole dimension of the project has no owner.
The teams that get this right run a structured internal alignment exercise before the RFP is released, not after the vendor is selected. They map the stakeholders who should be in the RFP conversation and make sure each one has put their requirements on the page while the page can still change. For public sector teams, federal digital experience and content requirements on Digital.gov are a useful checklist for who needs a seat and what they're responsible for.
The sequence matters more than the effort. Alignment before release is cheap. Alignment after award is a change order.
A vendor who pushes back on your RFP is doing you a favor
Most buyers prefer the vendor who accepts the RFP without friction. Clean response, no awkward questions, easy to score.
That's backwards.
A vendor who raises concerns about your RFP is giving you free diagnostic information. They're telling you where your requirements are ambiguous, where they're missing, where the timeline doesn't survive contact with the actual work. The vendor who says nothing has either decided not to mention it or hasn't looked closely enough to notice. Neither is the partner you want.
So when a vendor flags something, the question isn't "how do we negotiate this away." It's "what does this reveal about our own alignment."
Run the flag through three questions:
- When they say the scope is ambiguous, ask: did our team actually decide this, or did we leave it open and hope?
- When they say a requirement is missing, ask: who on our side owns that requirement, and were they in the room?
- When they say the timeline is unrealistic, ask: what did we assume about effort that we never validated internally?
Each one points back at your RFP, not at the vendor.
Here's the mistake that follows from getting this wrong. Teams resolve red flags at the contract level instead of the requirements level. The vendor flags a gap, both sides paper over it with contract language, everyone signs, and the project starts on a definition that's still incomplete. The flag got closed. The gap didn't. Platform selection has its own parallel discipline for evaluating CMS platforms, and the same trap applies there: a signed contract on an unresolved requirement is just a deferred argument with a price tag.
Fix it where it lives. If the flag exposed a requirements gap, close the requirements gap. Then sign.
What failed redesigns have in common
Look at redesign projects that went badly and a pattern shows up fast. The lesson is almost never what the vendor did wrong. It's what the RFP failed to require.
Take a familiar one. A large organization redesigns its site, launches on schedule, and three months later organic traffic is down by a third. The post-mortem blames the agency's SEO work. But the RFP never specified redirect integrity, never required crawl-equity preservation, never asked anyone to monitor technical SEO health through the migration. The traffic loss wasn't a vendor failure. It was an unrequired outcome.
Or the accessibility version, which is the one that recurs most. An agency rebuilds the templates, the visual design is genuinely better, and the new site fails accessibility on components that passed before. Previously compliant pages broke when the templates changed. Everyone treats it as a surprise. It wasn't a surprise. It was the predictable result of an RFP that never named a conformance standard or asked anyone to test for regression as the build progressed. Nobody was required to catch it, so nobody did.
The pattern holds across every category. The failure traces back to a requirement that wasn't there.
Which is the whole argument in one line: successful RFP processes treat the document as a governance instrument. Unsuccessful ones treat it as a vendor filter. The project pays the difference, and it pays it after launch, when the difference is hardest to fix.
The RFP is where the project is won or lost
Specify governance ownership. Name an accessibility standard. Require measurement continuity. Align your stakeholders before the document goes out, not after the vendor is chosen.
Do all of that and one reframe falls out of it: the RFP isn't the last step of vendor selection. It's the first step of project governance. Every red flag you fail to build into your requirements becomes a risk you can't contract your way out of later.
No vendor quality compensates for a requirement that was never written. The best agency in the country can't deliver an accessible site if your RFP didn't ask for one, and can't protect your traffic if your RFP didn't require it.
So before your next RFP goes out, run it against the seven risk categories. Governance, accessibility, content, performance, measurement, operations, transformation. If any of them is unaddressed, and it's almost always governance handoff, accessibility conformance, and post-launch monitoring, you haven't finished writing it yet.
The red flags you're looking for in vendor responses are worth catching. The ones in your own RFP are the ones that decide the project.