Website RFP Examples: What Good and Bad RFPs Look Like

Most website RFP guides tell you what to include. Include a budget section. Include a timeline. Include your requirements. That's fine as far as it goes, but it doesn't answer the question that actually matters: what do good website RFP examples look like versus bad ones, and what's the real difference in outcomes between the two?

I've been reading and responding to website RFPs for over 25 years. I manage roughly 200 WordPress websites at FatLab, many of which were built through an RFP process. I've seen the full spectrum, from RFPs that were so well written they practically scoped the project themselves, to ones that were so vague I couldn't tell if the organization wanted a 10-page brochure site or a full-scale membership platform.

What I can tell you from the vendor side is this: the language in your RFP determines which agencies take you seriously and which ones pass. A bad RFP doesn't just produce bad proposals. It systematically filters out the best vendors and attracts the worst ones. Quality agencies with healthy pipelines are selective. They evaluate potential clients just as carefully as clients evaluate them.

This article is built around concrete before-and-after website RFP examples drawn from actual projects. Not templates to download. Not abstract advice about "being specific." Real comparisons of what organizations write versus what they should write, with explanations of what each version communicates to the vendor reading it.

If you're looking for a broader overview of the entire RFP process, start with our complete guide to writing a website RFP. What follows here is focused specifically on the language itself.

Why the Words You Choose Matter More Than the Format

Every vendor who picks up your RFP is making a calculation: is this worth 25 to 40 hours of my team's unpaid time to respond to? That decision gets made in the first few pages. And it's not based on how polished your document looks or how many sections it has. It's based on whether the language tells them you know what you need.

According to Responsive, 40% of vendors say the RFPs they receive are repetitive and poorly written. That's nearly half. If your RFP reads like the last ten they saw, you're starting in a hole.

Vague language signals internal confusion. Overly prescriptive language signals micromanagement. Cookie-cutter language signals an organization that grabbed a template and filled in the blanks without thinking about what they actually need. Each of these tells the vendor something, and none of it is good.

The right language does two things: it gives vendors enough information to price the project accurately, and it signals that your organization has done the internal work to be a good client. Both of those things attract better agencies and produce better proposals.

And the difference shows up in the final product. I can tell when a website was built to a tight scope versus a loose one. It's a common scenario for us: an organization calls and says they just launched a new website, or they're about to launch, but they've decided not to keep the vendor who built it.

That almost always traces back to a poorly defined scope, which traces back to a vague RFP or no RFP at all. If the client were truly happy with the outcome, they wouldn't be shopping for a new vendor before the site is even live.

The Scope Section: Where Most RFPs Fall Apart

The scope section is where I spend the most time as a vendor, and it's where the biggest problems live. I always tell clients: if we can start with a list of things you want me to build, I can check them off, and at the end of the project, I can show you that I've built everything on this list. Then we're both going to be really happy. Without that list, we're guessing. And guessing is where projects go sideways.

Example 1: The Membership Area

Bad version:

"We are a membership organization, and we want our members to be able to sign in and access member-only material."

Why this fails: This single sentence could describe a $5,000 project or a $75,000 project. Does "member-only material" mean a few password-protected pages, or does it mean a full gated content library with role-based access? Can members manage their own profiles? Are there different membership levels? Is there a payment component?

The vendor has no idea, so they either guess high (and get eliminated on price) or guess low (and end up in a scope dispute later).

Good version:

"We are a membership organization with three tiers of membership (Individual, Institutional, and Student). Members should be able to:

• Log in and access a member directory, searchable by name and organization
• Download PDFs and recorded webinars, with some content gated by membership tier
• Pay annual dues online via credit card (currently processed through Stripe)
• View payment history and download invoices for the previous three years
• Update their own profile information and contact details

We currently have approximately 2,400 active members. Membership data is managed in our association management system (MemberClicks), and the website will need to integrate with it for single sign-on and data synchronization."

Why this works: Every line item in this description is something a vendor can scope, price, and build. The membership tiers, specific content types, payment processor, integration requirements, and even the member count all give the vendor concrete parameters to work with. When five agencies read this, they'll all be pricing roughly the same project. That makes their proposals actually comparable.

Example 2: The Blog and Content Section

Bad version:

"The website should include a blog with categories, tags, and social sharing functionality."

Why this fails: Every WordPress website includes a blog with categories and tags. That's built into the platform. This tells the vendor nothing about what you actually need. How many posts are you migrating? Who writes the content? How often do you publish? Do you need email notifications? This is the equivalent of telling a contractor, "The house should have walls."

Good version:

"Blog requirements:

• Migrate approximately 180 posts from our current WordPress site (2022 to present). Posts older than 2022 should redirect to a category archive page, not be migrated individually.
• Blog posts should support a consistent template: featured image, author bio, related posts section, and a call-to-action block that we can customize per post.
• New post notifications should integrate with our Mailchimp account (currently ~6,500 subscribers on our blog list). We publish 2-3 times per month.
• We need an editorial workflow where draft posts can be reviewed and approved before publishing. Three staff members will have author access."

Why this works: The vendor now knows the migration scope (180 posts, not 2,000), the integration requirement (Mailchimp), the publishing cadence, the staffing model, and the functional requirements for the blog template. They can price this accurately. They can also flag potential issues, like whether the editorial workflow needs a plugin or custom development, during the proposal stage rather than mid-project.

Example 3: The General Requirements List

Bad version:

"The website must include: Homepage, About page, Services pages, Blog, Contact form, Search functionality, Social media integration, Newsletter signup, Photo gallery, Video section, Testimonials, FAQ page, Sitemap, 404 page."

Why this fails: This is a list of pages, not a list of requirements. "Photo gallery" could mean 20 images in a simple grid or 5,000 images with tagging, filtering, and lightbox functionality. "Video section" could mean embedded YouTube links or a custom video library with gated access. "Social media integration" could mean footer icons or a live feed. Every item on this list needs context to be useful.

Good version:

"Content requirements by section:

• Programs (8 pages): Each program page follows a consistent template with an overview, eligibility criteria, outcomes data, and an application call-to-action. Content for all program pages exists and will be provided as Google Docs.
• Resource Library (new section): Approximately 50 downloadable PDFs, filterable by topic (6 categories) and audience type (3 types). Must support future growth to 200+ resources without performance issues. Our staff will upload resources during user acceptance testing.
• Events: Integration with our existing Eventbrite account to display upcoming events. Event registration should link to Eventbrite, not be handled on the website.
• Donation system: Integration with our existing Stripe account. Must support one-time and recurring donations. Our current average online donation is $75, and our goal is to increase that to $100 through better donation page design and suggested giving levels."

Why this works: Each section includes volume (8 pages, 50 PDFs), functionality specifics (filterable by topic and audience), integration requirements (Eventbrite, Stripe), content ownership (who provides what), and measurable goals (increase average donation). A vendor reading this can build an accurate estimate.

The Budget Section: Stop Playing Games

I personally hate it when organizations choose not to share a budget. I feel strongly about this. When you don't provide a budget, you're forcing vendors to take shots in the dark. 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, or I personally like the client, I might be willing to do a lot more for less. But when you hide the number, none of that can happen.

For a thorough breakdown of how to write a complete website RFP, including budget strategy, see our full RFP guide. Here, I want to focus specifically on how different budget language reads from the vendor side.

Example 4: No Budget at All

Bad version:

"Please provide your best pricing for this project."

What the vendor thinks: This is a fishing expedition. You either don't know what things cost (which means you might reject every proposal that comes back), or you do know, and you're trying to get vendors to undercut each other. Either way, the best agencies will skip this. Those who respond will either pad their numbers to protect themselves or lowball to get in the door and change orders later.

When you don't provide a budget, you're essentially choosing the vendor based on whether they happened to hit your number. And that may not be your best vendor. A cheap proposal is often one that's simply designed to win the project: give a low number without defining what you're building. The theory is to win the client, then deal with it later. If a proposal looks too good to be true, it probably is.

You probably don't want to go with your lowest bidder, and you probably don't want to go with your highest bidder either. The best website RFP examples I've seen produce proposals where every vendor is working from the same scope and budget parameters.

Example 5: Unrealistic Budget Stated as Firm

Bad version:

"Our total budget for this project, including design, development, content migration, CRM integration, member portal, and 12 months of hosting, is $8,000."

What the vendor thinks: This budget doesn't match the scope described. Quality vendors will not respond. The vendors who do respond are either planning to cut significant corners (commercial theme, minimal customization, no real discovery process) or planning to renegotiate the scope after winning the contract. It's like walking into a McDonald's and asking for a fine steak dinner. You might leave full, but it won't be what you wanted.

Your website is a 24/7 window into your organization. For nonprofits and associations with membership portals, dues collection, and event management, a website costing tens of thousands of dollars that handles all those interactions is actually incredibly cheap compared to what it would cost to have a human manage that many touchpoints with that level of efficiency. This is an investment in a critical communications channel, not a line item to minimize.

A related pattern: organizations that know their budget is below market rate but try to compensate with promises instead of honesty. Don't promise us a great portfolio piece. Don't tell us your members will hire us. Don't say you're well-connected and can get us more work. In 25 years of business, I have yet to be made or broken by such promises. I value them at zero dollars. It just doesn't happen.

If your budget is genuinely low, say so directly and look for a vendor who cares about your mission or can work within those constraints. Honesty attracts better partners than sugarcoating.

Example 6: Budget Range with Context

Good version:

"Our approved budget range for this project is $40,000 to $60,000. This should cover discovery, design, development, QA, and launch support. Content writing and photography will be handled internally and are not included in this budget. If our budget does not align with the scope described above, we would rather hear that honestly and adjust scope than receive an under-resourced proposal."

Why this works: This organization has done its homework. They know roughly what things cost, they have internal approval, and they're open to honest feedback. The last sentence is critical: it invites the kind of candid conversation that leads to successful projects. It tells the vendor, "We'd rather hear the truth than get a proposal that makes us feel good."

Example 7: Phased Budget with Fiscal Year Reality

Good version:

"We have $35,000 available in our current fiscal year (ending September 30) and anticipate an additional $20,000 in FY2027. We are open to a phased approach in which Phase 1 (core website redesign and launch) completes within the current fiscal year, with Phase 2 (member portal and event registration system) following in FY2027. Please propose a phased approach that works within these constraints, and identify which scope items you would recommend for each phase."

Why this works: Real-world budget constraints presented honestly, with flexibility for the vendor to propose creative solutions. Nonprofit and association budgets are frequently tied to fiscal years, grant cycles, and board approval processes. Acknowledging this reality in the RFP doesn't make you look weak. It makes you look like an organization that understands its own constraints and can plan accordingly.

The Timeline Section: Be Honest About What's Realistic

Compressed timelines are one of the top reasons quality agencies decline to bid. When I see an RFP that expects a 50-page website with custom integrations to launch in six weeks, I know the organization either doesn't understand the process or has already been burned by delays.

Example 8: Unrealistic Timeline

Bad version:

"We need the new website launched within 6 weeks of contract signing."

What the vendor thinks: For anything beyond a simple template site, this is not possible without cutting corners that will cost you later. Most full-scale website redesigns take 12 to 16 weeks for standard projects, 18 to 26 weeks for complex ones. An unrealistic timeline signals an organization that will be difficult to work with throughout the project, as they'll pressure the team to move faster at the expense of quality at every stage.

Example 9: Realistic Timeline with Context

Good version:

"Target launch: September 2026 (flexible by 4-6 weeks if needed). Key context: We have a major fundraising gala on October 15 and would prefer the new site to be live before that date, but this is a preference, not a hard deadline. Our board meets quarterly, and the next meeting, where we could approve the vendor selection, is on May 15. We anticipate the selection process taking approximately 6-8 weeks from RFP distribution to contract signing."

Why this works: The vendor now understands not just the deadline but the reason behind it. They can plan backward from October 15 and determine whether the timeline is feasible given the expected contract signing date. They also know about the board approval dependency, which is critical for scheduling. And the phrase "preference, not a hard deadline" signals an organization that can be reasonable when reality intervenes.

The Evaluation Criteria Section: Tell Vendors What You Actually Value

When your evaluation criteria are vague, vendors can't tailor their responses to what matters most to you. And when you can't tell vendors what matters most, it usually means you haven't decided internally, which is a problem that will surface throughout the project.

Example 10: Vague Evaluation Criteria

Bad version:

"Proposals will be evaluated on quality, cost, and experience."

What the vendor thinks: This tells me nothing about what you actually value. Is this a cost-driven decision? A portfolio-driven decision? A relationship-driven decision? Without knowing, I'm going to write a generic proposal that tries to be strong everywhere. And so will every other vendor. The result is a stack of proposals that all look the same and are impossible to compare meaningfully.

Example 11: Weighted Evaluation Criteria

Good version:

"Proposals will be evaluated using the following weighted criteria:

1. Strategic approach and demonstrated understanding of our goals: 30%
2. Portfolio of comparable projects (nonprofit websites with membership or donation functionality): 25%
3. Technical approach and proposed technology stack: 20%
4. Ongoing support and maintenance capabilities: 15%
5. Cost: 10%

References will be checked for the two finalists. We plan to conduct 60-minute interviews with our top three candidates the week of June 9."

Why this works: When cost is weighted at 10%, it signals to vendors that the organization values quality and fit over price. Agencies that compete on quality rather than price will invest more time in their response. The specific portfolio criteria (nonprofit websites with membership or donation functionality) indicate whether vendors are a good fit before they invest 30 hours in a proposal. And the interview timeline lets vendors plan their availability.

This kind of transparency in evaluation criteria also makes the eventual selection more defensible. When the board or a committee asks why you chose a vendor that wasn't the cheapest, you can point to the scoring rubric you published at the start. For more on how to build a structured evaluation process, see our guide to evaluating website proposals.

The Technology Section: Goals, Not Prescriptions

One of the patterns I see most often in bad RFPs is prescribing specific technical solutions when the organization lacks the technical expertise to know what they're prescribing. In almost every web design RFP example I've reviewed that over-prescribes technology, the organization would have been better served stating goals and letting vendors propose solutions. It's the equivalent of telling your doctor which medication to prescribe before they've examined you.

Example 12: Over-Prescribed Technology

Bad version:

"The website must be built on WordPress using a responsive theme from ThemeForest. It must use WooCommerce for all e-commerce functionality, Yoast SEO for search optimization, Gravity Forms for all forms, and WPML for multilingual support. The site must be hosted on a shared cPanel hosting account."

Why this fails: This RFP has already made every technology decision without understanding the implications. A ThemeForest theme comes with significant performance and maintenance overhead. WooCommerce might be overkill if the "e-commerce" is just accepting donations. WPML is expensive and complex, and the RFP never mentions what languages are needed. And requiring shared cPanel hosting limits performance and security options before the project even starts.

More importantly, this eliminates vendors who might have better solutions. A strong WordPress developer might recommend a custom theme instead of ThemeForest, Stripe integration instead of WooCommerce for simple donations, or a different multilingual approach based on the actual content volume. But they can't propose any of that if the technology choices are dictated in the RFP.

Example 13: Goals-Based Technology Section

Good version:

"Technology requirements:

• The website must be built on WordPress. Our internal team is familiar with WordPress content editing and wants to maintain that workflow.
• We need to accept online donations (one-time and recurring). We currently use Stripe and would prefer to continue with it, but we're open to alternatives if there's a strong reason.
• The website needs to be available in English and Spanish. Our English content is approximately 45 pages. Spanish content will be a subset, roughly 15-20 key pages, not a full mirror of the site. Our bilingual staff will handle translation.
• We need the site to be fast and perform well on mobile. We don't have specific performance benchmarks, but we want to understand your approach to performance optimization.
• Ease of maintenance is a priority. We want to minimize the number of plugins and avoid solutions that create heavy technical overhead for routine updates."

Why this works: The organization has stated its platform preference (WordPress) and provided a rationale (staff familiarity). They've described their payment needs in terms of functionality rather than specific plugins. The multilingual requirement includes the actual scope (15-20 pages, not a full mirror), which changes the approach entirely. And the maintenance priority tells the vendor something critical about what this organization values over the long term.

That last point is something I feel strongly about. What I care about most in any project is the maintainability of the final product. Are they going to use a commercial theme and a whole bunch of plugins, or build a custom theme with a limited number of carefully chosen plugins?

When their answer to every problem is "install another plugin," you end up with a website that's expensive to maintain and fragile when updates are applied.

The Organization Background Section: Context, Not Marketing Copy

Most RFPs open with a section about the organization that reads as if it were pulled from the About page. That's a missed opportunity. Vendors need context to understand your project, not your mission statement.

Example 14: Marketing Copy Background

Bad version:

"We are a leading research organization focused on healthcare innovation. Founded in 2003, we are committed to advancing the boundaries of medical science through collaborative research, education, and community engagement. Our dedicated team of researchers and staff works tirelessly to improve health outcomes for communities nationwide."

What the vendor thinks: This tells me nothing I need to know to build your website. How many people work here? How many sites do you have? What does your current website do? Who uses it? I still don't understand what we're building or why.

Example 15: Contextual Background

Good version:

"We are a healthcare research institute with 12 active research programs, 450 staff across three locations, and an annual operating budget of approximately $28 million. Our website serves two primary audiences: potential research partners evaluating our capabilities and community members seeking clinical trial enrollment opportunities.

Our current website is five years old, built on WordPress 5.x with a commercial theme (Avada). It has approximately 85 pages and 200 blog posts. Our primary pain points: the site is slow (4+ second load times on mobile), the Avada page builder makes routine updates difficult for non-technical staff, and our clinical trials section requires manual updates that should be automated through our CTMS integration.

This project is being initiated because our current site no longer supports our recruitment goals. Clinical trial enrollment from the website has dropped 30% year-over-year despite increased traffic."

Why this works: The vendor now understands the organization's size, the website's current state, the technical debt they're inheriting, the real problem driving the project (declining trial enrollment), and the two audiences the site needs to serve. This is the context that shapes a good proposal. Every decision, from design direction to information architecture to technology choices, flows from understanding this context.

The Content Migration Section: The Most Underestimated Part of Any RFP

Content migration is the single most underestimated element in website RFPs across every sector. You'll rarely see it covered well in a sample website RFP or template, which is part of the problem. Organizations consistently fail to understand the scope of their own content, and the vague way they describe migration requirements is responsible for more budget overruns and timeline blowouts than any other RFP section.

Example 16: Vague Content Migration

Bad version:

"All existing content will be migrated to the new site."

Why this fails: This sentence can mean 50 pages or 5,000 pages. It can mean copy-paste or complete restructuring. It can mean the vendor handles it or the client provides it. Without quantification, this is arguably the most dangerous sentence on any website RFP. When the vendor discovers mid-project that "all existing content" includes 3,000 blog posts, 500 PDFs, and a resource library that needs restructuring, someone will be unhappy about the budget.

Example 17: Specific Content Migration

Good version:

"Content inventory and migration plan:

• Pages (45 total): All pages will be rewritten by our staff and provided as Google Docs organized by site section. Target delivery: two weeks after design approval.
• Blog posts (312 total): Posts from 2023 to present (approximately 120 posts) will be migrated as-is by the vendor, preserving categories, tags, and featured images. Posts older than 2023 will redirect to category archive pages. We do not want to migrate the full archive.
• Resources (89 downloadable PDFs): Our staff will upload these to the new resource library during user acceptance testing. The vendor is responsible for building the resource library structure and providing training on uploading.
• Redirects: The vendor should provide a redirect map for all pages whose URLs will change, and implement 301 redirects before launch.

Content responsibilities summary: Our staff handles all content writing and PDF uploads. The vendor handles blog migration scripts, redirect mapping and implementation, and content entry training for our team."

Why this works: Both sides now know exactly who does what. The vendor can price blog migration for 120 posts (not 312). The client has committed to content delivery timelines. The redirect requirement is explicit. And there's a clear division of labor that prevents the "who was supposed to do that?" arguments that derail projects.

The Post-Launch Section: What Most RFPs Completely Ignore

Here's something most RFP guides skip entirely: what happens after the website launches. Your RFP should address ongoing support, hosting, and maintenance because those requirements affect the proposals you receive in ways most organizations don't realize.

Example 18: No Post-Launch Requirements

Bad version:

[This section does not exist in the RFP]

Why this fails: When you don't specify post-launch requirements, you can't compare proposals. One vendor includes 12 months of support and maintenance in their price. Another quotes just the build. A third includes 30 days of bug fixes and nothing else. Without post-launch requirements in your RFP, these proposals look like they're $10,000 to $20,000 apart when they may actually be comparable in total cost of ownership.

It also signals to the vendor that you haven't thought about what happens after launch, which is a red flag. In our experience, organizations that don't plan for post-launch support end up in a "launch and neglect" cycle, where the website deteriorates over 18 to 24 months until it needs another redesign.

Example 19: Defined Post-Launch Requirements

Good version:

"Post-launch support requirements:

• Warranty period: 90 days of bug fix support after launch, covering any defects in the delivered work.
• Training: On-site or virtual training session (minimum 2 hours) for our content editors, covering page editing, blog publishing, resource uploads, and basic troubleshooting.
• Documentation: Administrator guide covering custom functionality, integration configurations, and routine maintenance procedures.
• Ongoing maintenance (optional, quote separately): We are evaluating whether to retain the build vendor or use a separate managed hosting provider for ongoing maintenance. Please include a separate line item for monthly maintenance, including security updates, plugin updates, daily backups, uptime monitoring, and up to 2 hours of minor content or functionality changes per month.

Note: We will be evaluating hosting and maintenance options separately from the build. If you offer these services, please quote them as a separate line item so we can compare them independently."

Why this works: The vendor now knows exactly what's expected during the transition period. The separate line item for ongoing maintenance allows accurate comparison. And the note about evaluating hosting separately signals organizational maturity without closing the door on the build vendor's maintenance offering.

If you're planning a redesign specifically and need to understand how these post-launch considerations differ from a new build, see our website redesign RFP guide.

The Vendor Qualification Section: Ask What Actually Matters

Most RFPs ask vendors to provide a company overview, a list of clients, and three references. That's the minimum. The questions that actually reveal whether a vendor is right for your project go deeper.

Example 20: Generic Vendor Qualifications

Bad version:

"Please provide a company overview, number of employees, years in business, and three client references."

Why this fails: Every responding agency will present well in these areas. The one-person shop will position itself as "nimble and dedicated." The 50-person agency will position itself as "full-service with deep bench strength." Three hand-picked references will all say positive things. None of this helps you make a real decision.

Example 21: Targeted Vendor Qualifications

Good version:

"Vendor qualifications: In your proposal, please address the following:

• Provide 3 examples of WordPress websites you've built for organizations similar to ours (nonprofit or association, 40+ pages, with membership or donation functionality). For each, describe your role, the project budget range, and the biggest challenge you solved.
• Describe your development approach: Do your developers write custom code, or do you primarily use commercial themes and plugins? How do you approach plugin selection and management?
• Describe your team structure for a project of this scope. Who will be our day-to-day contact? Will any work be subcontracted?
• What is your process if, mid-project, we discover a requirement that wasn't in the original scope? Walk us through how you handle scope changes.
• Provide one reference from a project that did not go smoothly. We want to understand how you handle challenges, not just successes."

Why this works: The development approach question is critical, and it's one I ask whenever I evaluate vendors on behalf of my clients. Both types of vendors claim to be "developers." But a vendor who provides real custom WordPress development can meet each challenge of your project with creativity and freedom. A point-and-click developer, someone who installs a commercial theme, changes some colors, and loads up plugins, simply can't offer that.

The question about a project that didn't go smoothly is one most organizations would never think to ask, but it reveals more about a vendor's character than any success story. For a deeper framework on what questions reveal real competence versus rehearsed marketing, see our guide on how to choose a web developer.

Full Website RFP Examples: Putting It All Together

To see how much difference language quality makes across an entire RFP, here's a side-by-side of how a complete "About the Project" section might read in a bad RFP versus a good one. This is the closest thing to a sample website RFP you'll find that focuses on the quality of language rather than just structure.

Bad Version: Full Section

About the Project

We are looking for a qualified web design firm to redesign our organization's website. The new site should have a modern, clean design that is mobile-responsive and SEO-friendly. We want it to be easy to navigate and reflect our brand identity.

The site should include the following pages: Home, About Us, Our Team, Programs (multiple), News/Blog, Events, Resources, Donate, Contact Us. We also need a member login area.

We would like the project completed as quickly as possible. Please provide your best pricing.

What the vendor sees: Buzzwords, no scope, no budget, no timeline, no context. This is a textbook web design RFP example of what not to do. It's identical to dozens of other RFPs this vendor has received this quarter. The best agencies will pass. The agencies that respond will be either hungry for work or planning to define (and expand) the scope after winning the contract.

Good Version: Full Section

About the Project

We are a regional environmental advocacy nonprofit with a staff of 18 and an annual budget of $2.4 million. Our website is our primary tool for public engagement, volunteer recruitment, and online donations.

Our current site was built in 2019 on WordPress using the Divi theme. While the design has held up reasonably well, the Divi page builder has become increasingly difficult for our communications team to manage. Routine updates that should take minutes often take hours. We also have performance concerns: our homepage loads in 5.8 seconds on mobile according to Google PageSpeed, and our bounce rate has increased from 52% to 71% over the past two years.

We are seeking a complete WordPress rebuild with a custom theme (no page builder dependency). The project scope includes:

• Public-facing pages (22 pages): Redesign and rebuild. Content will be rewritten by our staff and delivered as Google Docs.
• Action center (new section): Landing pages for active campaigns where visitors can sign petitions, contact legislators, and share on social media. We run 4-6 active campaigns at any given time and need to launch new campaign pages quickly without developer involvement.
• Blog (migrate ~150 posts from 2022 to present): Older posts archived with redirects.
• Events: Pull from our existing Eventbrite account, display upcoming events, link to Eventbrite for registration.
• Donations: Integrate with our existing Stripe account. One-time and recurring. Our current online donation conversion rate is 1.8%, and we'd like to improve that through better donation page design.
• Volunteer portal: Authenticated area where active volunteers can access training materials, sign up for shifts, and track hours. Approximately 200 active volunteers. Integration with our volunteer management system (VolunteerHub) is required.
• Email integration: New blog posts and campaign actions should trigger notifications to segmented lists in Mailchimp (~12,000 subscribers across 4 lists).

Our approved budget for this project is $45,000 to $65,000. If our scope exceeds this range, we'd like your recommendation for a phased approach. Content and photography are handled internally and not included in this budget.

Target timeline: Live by early October 2026. We have flexibility of 4-6 weeks, but would prefer to launch before our annual fundraising campaign in mid-November.

The difference between these two versions is not length. It's clarity. The bad version is shorter, but it would produce five proposals that each describe a completely different project. The good version is longer, but it would produce five proposals that can be compared side by side because every vendor is responding to the same defined scope. That clarity is the single biggest factor in RFP outcomes.

When an RFP is the Wrong Tool

Not every website project needs a formal RFP, and it's worth being honest about that. An RFP makes sense when you're spending $25,000 or more, when you need to evaluate multiple vendors, when internal stakeholders require a structured procurement process, or when the project is complex enough that you need to see how different agencies approach it.

An RFP is the wrong tool when you already know who you want to work with and the process is just a formality. I've been on both sides of weird RFPs. I've been the obligatory competing bid when the organization already knew exactly who they were going to hire. I consider it an unethical business practice. It happens often, especially in the nonprofit and association space where bylaws require competitive bidding.

If your organization requires competitive bids, run an honest process. Your vendors can tell when it's theater, and the good ones won't participate again. And the organization loses too, because they end up collecting bids, gathering up the good ideas and pricing, and handing it all over to their vendor of choice. That's not a procurement process. It's intellectual property theft with extra steps. If you're a nonprofit navigating board procurement rules, grant timelines, and committee decision-making, our nonprofit website RFP guide addresses those challenges directly.

An RFP is also the wrong tool when you don't have internal clarity on what you need. If your team can't agree on the project's goals, audience, or priorities, no RFP template will fix that. Do the internal work first. Run a discovery process. Figure out what you're trying to accomplish. Then write the RFP.

Using the RFP process as a substitute for internal alignment just exports your confusion to the vendors and produces proposals that reflect that confusion right back.

For organizations looking for a structured starting point, we've created a website RFP template that walks through each section, with guidance on what to include and what to skip.

What Your RFP Language Tells Vendors About You

Every RFP communicates a meta-message beyond its content. Across the hundreds of RFPs I've reviewed over the years, vendors read between the lines of every document, and the patterns they identify shape whether they invest time in a response and how much effort they put into it.

Vague scope with high expectations signals an organization prone to scope disputes. I've seen the pattern too many times: the RFP describes wanting "a slick modern website that does all these things" paired with language about budget constraints.

Using "redesign" when you mean "rebuild" signals an organization trying to lower the scope (and therefore the budget) through word choice. There are really two kinds of projects: those that want a new visual design, and those that want new capabilities, integrations, or administrative tools.

Organizations frequently write "redesign" in their RFPs because they think it sounds less expensive. But there's no point in putting a new coat of paint on an old system. If the site was built on a page builder five years ago and you need modern functionality, that's a rebuild, and the RFP should reflect it. It's our job as consultants to educate clients on the difference, not to let imprecise language set false expectations.

Over-detailed technical specifications from a non-technical organization signal that someone copied requirements from the internet without understanding them. Vendors notice when an RFP prescribes "React for the frontend and Node.js for the backend," but also says the organization needs "a WordPress website." These contradictions tell the vendor that the organization hasn't done the internal homework to understand what they're asking for.

Complaints about previous vendors can go either way. Sometimes it's valuable to understand what went wrong. But when an RFP dwells on past vendors' failures, it raises a fair question: did the vendor fail the client, or did the client fail the vendor? That question definitely contributes to whether a quality agency decides to respond.

Clear goals, transparent constraints, and honest budget information signal an organization that will be a good partner. The best agencies want to work with clients who respect their time, communicate openly, and have done the internal work to set the project up for success. Your RFP is your first impression. Make it count.

For specific warning signs to watch for on the vendor side when proposals come back, see our guide to red flags in website vendor proposals.

One Consistent Lesson After 25 Years

PMI's 2024 Pulse of the Profession report confirms what I've seen across hundreds of projects: initiatives with clearly defined success metrics at the start consistently outperform those without. The same applies to RFPs.

The RFPs that produce the best projects share one trait: they describe what the organization wants users to be able to do, not what they want the website to look like. "Sleek modern design" doesn't mean anything. "Our members need to log in, access continuing education materials, pay dues, and download certificates" gives a vendor something real to work with.

The most common scenario when a client is unhappy with the end product isn't that the quality of the work was poor. It's that they didn't get what they wanted because they didn't know what they wanted. Your RFP is your chance to figure that out before money changes hands.

If you take one thing from these website RFP examples, let it be this: bulleted lists of what your website needs to do are worth more than pages of marketing language about what you want it to look like. Give your vendors the raw material. Give them the real picture. And share your budget so everyone is working from the same page.

The organizations that do this consistently end up with websites that work, vendors they want to keep working with, and projects that come in on time and on budget. The ones that don't keep cycling through vendors, wondering why nothing ever turns out the way they imagined.

Frequently Asked Questions

How long should a website RFP be?

Most effective website RFPs range from 8 to 15 pages. The length matters far less than the specificity. A 6-page RFP with concrete scope details, a stated budget, and clear evaluation criteria will outperform a 30-page document padded with organizational history and generic requirements. If your RFP is over 20 pages, you're probably including information that belongs in an appendix or a follow-up conversation.

How many vendors should I send my website RFP to?

Three to five is the practical range for most organizations. Fewer than three doesn't give you enough points of comparison, and more than five creates an evaluation burden that slows the process without meaningfully improving your options. If you're sending your RFP to ten or more agencies, you probably haven't done enough pre-qualification to narrow the field, and quality vendors may decline, knowing their odds are low.

Should I include my budget in a website RFP?

Yes. Withholding your budget forces vendors to guess, which means you'll receive proposals spanning wildly different price ranges for wildly different interpretations of your project. Sharing a realistic budget range lets every vendor respond to the same scope, makes proposals genuinely comparable, and signals to quality agencies that you've done your homework. The fear that vendors will simply spend your whole budget is unfounded when you've written a clear scope.

What is the difference between a website redesign and a website rebuild?

A redesign is primarily a visual refresh in which the underlying platform, content structure, and functionality remain largely the same. A rebuild means replacing the technical foundation, which typically involves a new theme architecture, new or updated integrations, and potentially a different hosting environment. If your current site was built on a page builder or commercial theme and you need modern functionality, that's a rebuild regardless of what you call it in the RFP. Using the wrong term can set inaccurate budget expectations from the start.

How long does it take to get proposals back after sending a website RFP?

Plan for three to four weeks from distribution to proposal deadline. Quality agencies need time to review your requirements, assemble their team's input, and develop a thoughtful response. Giving vendors less than two weeks signals that you either don't respect their time or have already chosen your vendor and are treating this as a formality. Build in an additional one to two weeks after the deadline for internal review and scoring before scheduling finalist interviews.

Can I use a website RFP template I found online?

A template can be a useful starting point for structure, but filling in the blanks without adapting the language to your specific project is exactly what produces the generic RFPs that quality vendors ignore. Any sample website RFP you find online will give you sections and formatting. But the examples in this article illustrate why structure alone is not enough: effective RFP language includes your actual page counts, your specific integrations, your real budget, and your honest constraints. A template gives you the sections, but you still need to do the internal work to populate them with substance.

FatLab Web Support manages roughly 200 WordPress websites for nonprofits, associations, and organizations nationwide. If you're preparing for a website project and want help structuring your RFP or evaluating vendor proposals, get in touch.