Website redesign RFP template (with the questions that actually matter)

Why most website RFPs fail

Most website redesign RFPs are written like procurement documents for office furniture. They list features, ask for pricing, and include a checklist of platforms supported. The result is responses that are mostly indistinguishable from each other, and a selection process that comes down to price and gut feel.

Useful RFPs do something different. They communicate context (what the business actually does, why a redesign is happening, what success looks like). They ask vendors specific questions that surface real differences in approach. They include scoring criteria that prioritize what actually matters (strategic thinking, design quality, technical execution, post-launch support) over what sounds important but does not (number of years in business, list of past clients, vague capability statements).

The template below is structured for service businesses redesigning their site to book more high-ticket work. It can be adapted for ecommerce or SaaS contexts but the section weighting is calibrated for service-business priorities.

Total length, when filled out for a typical service-business redesign: 8 to 12 pages. Long enough to give vendors real context; short enough that they will actually read it.

Section 1: Business context

One to two pages establishing what the business does and who the buyer is.

What the business does. Two to four sentences describing the core service offering, geography, and ICP. "Cascade Foundation Repair is a residential foundation specialist serving Portland, Oregon and surrounding metro areas. We diagnose and repair settling, cracking, and structural foundation issues, primarily in homes built before 1960. Founded 2008, family-owned, licensed in Oregon and Washington. Annual revenue $2.4M, 2024."

The buyer profile. Two to three paragraphs describing the typical client: who they are, what triggers them to start looking, how they find vendors, what concerns they have, what decision criteria they use. Be specific. "Most clients are homeowners aged 45 to 65 with kids, on properties valued $700k+. They start looking when they notice a specific symptom (door not closing, crack in foundation wall, sloping floor) or after a home inspection flags an issue. They typically research three to five contractors over four to six weeks, often pulling recommendations from real estate agents, neighbors, and online searches. Their primary concerns are project disruption, cost certainty, and whether the contractor has handled similar projects before."

Current revenue mix. Where leads come from now: percentage from referrals, repeat business, organic search, paid search, directories, other. The mix shapes which channels the new site needs to serve.

Differentiators. What separates the business from competitors, in plain language. Avoid marketing-speak; write what would actually be true to a knowledgeable insider.

Section 2: Current site problems

One page on what is wrong with the current site. Specifics, not vague complaints.

Conversion rate. The actual conversion rate on the current site, measured per channel where possible. "Sitewide conversion rate is 1.8%. Organic search converts at 1.2%, direct converts at 4.1%, paid search converts at 2.4%. We expect 4 to 6% sitewide on a redesigned site." Vendors who push back on these numbers know the field; vendors who accept them without comment do not.

Specific page problems. Three to seven specific issues with named pages. "Home page hero photo loads in 6.5 seconds on mobile and triggers Cumulative Layout Shift above 0.3. Service pages have no pricing context and convert at under 1%. Contact form has 14 fields and abandons at 78%." Specifics force vendors to engage with the actual problems instead of pitching generic redesigns.

Technical issues. Slow load, accessibility gaps, mobile experience problems, schema gaps. Run the site through pagespeed.web.dev and Google's Rich Results Test before writing this section; the data will name the problems for you.

Content problems. Pages that are missing, pages that are outdated, content that does not match what the business does today.

Section 3: Scope and goals

One page on what the redesign needs to achieve and what is in scope.

Primary goals. Three to five specific outcomes, not generic phrases. "Increase organic search traffic from 800 to 2,000 monthly visits within 12 months." "Move sitewide conversion rate from 1.8% to 4% within 90 days of launch." "Reduce mobile bounce rate from 68% to under 45%." Specific goals let vendors propose specific approaches.

In scope. Pages and capabilities the redesign covers. Be explicit. "Home, About, 6 service pages, 8 service-area pages, Contact, Work or case studies index, individual case study template, guides or insights section. Plus 12 to 15 pieces of long-form guide content." Vendors price differently on a 10-page site than on a 40-page site.

Out of scope. Things the redesign does not include. "Custom CRM integration. Booking calendar integration. E-commerce. Multi-language support." Out-of-scope items often surface during a project; naming them up front prevents scope creep and vendor mismatches.

Migration scope. Whether existing content carries over, whether URL structure changes, whether redirects need to be set up. For SEO continuity, URL structure choices matter; the RFP should make these explicit.

Section 4: Technical requirements

One page on the technical baseline the new site needs to hit.

Performance targets. Mobile Largest Contentful Paint under 2.5 seconds, Cumulative Layout Shift under 0.1, Interaction to Next Paint under 200ms. Vendors should commit to these specifically.

Platform preferences. Whether the business has a platform preference (Next.js, Astro, Webflow, WordPress) or wants the vendor to recommend. Be honest about post-launch maintenance capacity; complex stacks need someone to maintain them.

Hosting and CDN. Whether the vendor handles hosting, whether the business has a hosting setup it wants to keep, expectations around uptime, backups, and SSL.

Accessibility. WCAG 2.1 AA compliance as the baseline. Vendors should commit to this and explain how they will validate.

Schema markup. Specific schema types the new site needs (LocalBusiness, Service, FAQPage, Article, Person at minimum). Vendors who do not have specific answers about schema implementation are not yet thinking at the level required for SEO and AI search.

Analytics and tracking. Google Analytics 4, Google Search Console, optionally a call tracker like CallRail. The RFP should specify what gets set up at launch.

Section 5: Vendor questions (the most important section)

Two to three pages of specific questions that surface real differences between vendors. The questions should be unanswerable with generic capability statements.

Strategy and discovery. "Walk us through your discovery process. How long does it take, what specifically do you produce at the end, and how do you validate that the strategy is right before design starts?"

Design ownership. "Who specifically will design our site? Are they full-time at your firm? How many concurrent projects will they be on during ours? Will we ever speak with them directly?"

Technical execution. "What stack will you propose for our site, and why over alternatives? Who specifically will write the code? What is your testing process before launch?"

Performance commitment. "What page speed and accessibility scores will you commit to at launch, and how will you validate them?"

SEO and migration. "How will you handle URL migration to preserve organic search rankings? What schema markup will you implement? How will you handle 301 redirects and Search Console transition?"

Content authoring. "Will you write content, or do we provide it? If you write, who writes it, what is the process for approval, and how do you handle revisions?"

Post-launch support. "What is included in the project price after launch? What is your hourly rate for changes? How quickly do you respond to support requests?"

Failure modes. "Tell us about a project that went wrong and what you learned. What is your worst client review, and how did you respond?" Vendors who cannot answer this honestly are signaling something.

References. "Provide three references from clients similar to us in size and category, including one whose project ended in the last 12 months."

Case studies. "Show us two case studies of projects similar to ours. We want to see the brief, the design process, the technical decisions, and the measurable outcomes."

These questions take vendors hours to answer well. The quality of the answers separates real partners from pitch-deck-driven sales operations.

Section 6: Deliverables and timeline

Half a page on what gets produced and when.

Deliverables. The list of artifacts the project produces: strategy document, design files, code repository or hosted site, content, training materials, transition documentation. Be explicit about what the business owns at the end.

Timeline. Total project length and phase breakdowns. For a typical service-business redesign, 8 to 16 weeks is realistic. Less than 8 indicates either a templated approach or aggressive scope cuts. More than 16 indicates either a complex scope or an inefficient process.

Milestones and review points. Clear stage gates where the business reviews progress and approves before the next phase starts. Common stages: discovery and strategy approval, design approval, development sign-off, content approval, launch readiness review.

Launch and post-launch period. What happens at launch, what the immediate post-launch support window includes, what gets handed off to the business team.

Section 7: Budget range

Be honest about budget in the RFP. Vendors who get a real budget range respond with realistic proposals; vendors who get no budget range either over-bid or under-bid, and the resulting proposals are harder to compare.

The right framing. "Our budget range for this project is $20,000 to $35,000, with up to $5,000 of flexibility for unusual scope. Annual maintenance and ongoing support budget is $500 to $1,500 per month." Specific ranges let vendors recommend the scope that fits the budget honestly.

Avoid. "We are looking for the most cost-effective solution" with no number. This invites lowball proposals that have no chance of producing what the RFP describes. Vendors capable of doing the work walk away when budget is opaque.

Payment structure. The RFP can specify expected payment terms (typical for service-business redesigns: 30 to 50% at signing, 25 to 35% at design approval, 20 to 30% at launch, 10 to 15% at 30-day post-launch review). Vendors deviating from a reasonable structure should explain why.

Scoring the responses

Define scoring criteria in the RFP itself. This forces objective evaluation and surfaces decision-relevant differences.

Suggested weights for a service-business redesign.

Strategic approach: 25%. The quality of the discovery and strategy answer, the depth of buyer-profile thinking, the proposed positioning work.

Design quality: 25%. The proposed design direction, the case studies of comparable work, the visual sophistication evident in their portfolio.

Technical execution: 20%. The stack proposal, performance commitments, schema and SEO approach, accessibility plan.

Process and people: 15%. Who specifically will work on the project, communication cadence, review checkpoints, what happens if the relationship breaks down.

Pricing and timeline: 10%. Whether the proposal fits the budget and timeline; less weight than vendors expect because price-driven selection in this category usually goes badly.

References and post-launch: 5%. The quality of references, the post-launch support model, the maintenance plan.

These weights are not universal. Adjust based on what matters most for the business. The discipline of writing them down before reading proposals reduces the chance of selecting on charisma rather than capability.

Red flags in vendor responses

Six patterns predict bad outcomes regardless of how good the proposal looks.

Generic responses that could apply to any client. If the proposal does not engage with the specific buyer profile, the specific page problems, or the specific service-business context, the vendor either did not read the RFP or does not customize their work to clients.

Vague answers to vendor questions. If specific questions about strategy, design ownership, or technical stack get answered with capability statements rather than concrete details, the vendor is selling a story rather than execution.

Year-long timelines without justification. Service-business redesigns typically take 8 to 16 weeks. Proposals that quote 24+ weeks are either including unnecessary process layers or doing work in series that should be in parallel.

No named team members. "Our experienced team will work on your project" tells you nothing. The named designer, named developer, and named project lead matter. If the vendor cannot name them, they may not be assigned yet, or may be junior staff fronted by senior salespeople.

Unrealistic guarantees. "We guarantee top-three Google rankings" or "we guarantee 5x conversion lift" are signs of either misrepresentation or contracts written to never deliver. Real vendors set ambitious targets and explain the work that produces them, without guaranteeing outcomes that depend on factors beyond their control.

Pressure to move fast. Vendors who pressure you to sign within days or who criticize taking time to compare are signaling something about how they treat clients post-signing. Real partners welcome the comparison process because it surfaces fit.