Last year we covered some RFP basics: outcomes over deliverables, real budgets, published weighting. This time we wanted to go section by section through what an RFP needs to contain, what to ask potential partners, especially with so many technology changes happening so rapidly. There is a downloadable website redesign RFP template at end to help get you started.
Understanding RFPs
What is a website redesign RFP?
A website redesign RFP (request for proposal) is the document a college, university or nonprofit issues to invite agencies to propose on a website project. You will also see it called a web design RFP or a website development RFP; same thing. At its simplest, it gives potential partners your current situation, your goals, your approximate budget, your timeline, and your selection criteria. They respond with a proposal: their approach, their team, their price.
It is your one chance to articulate to a bunch of vendors what you are trying to do clearly enough that they can provide a scope, timeline, process and cost.
You are hiring a partner precisely because you don’t know the solution yet.
Why the RFP matters in web development
The RFP sets the stage for everything that follows. A vague RFP tends to get vague proposals, and a vague proposal becomes a contract with a lot of assumptions baked into it. And nobody wants that…
Budgets make this hard. Budgeting cycles mean RFPs often have to ask for a fixed bid, even when the project isn’t very defined. And that is fair, because you are hiring a partner precisely because you don’t know the solution yet. We’ve read recent RFPs that ask the agency to recommend a CMS and, in the same document, give a fixed price for the build. Nobody can price a build on a platform that hasn’t been chosen. You can try…but you are going to receive numbers that are padded or full of assumptions. Most of what follows is about avoiding that.
You can’t price a site build on an undefined platform .
Key components of a website redesign RFP
Executive summary
A good opening is one page a potential partner can read quickly and understand the ask: who you are, what the project entails, why now, roughly what you can spend, and when proposals are due. Include the drivers behind the project: enrollment is down in two programs, the site is on a platform that is going end of life, the brand just changed. Partners write better proposals when they know your goals.
Also, state the unknowns. It is okay to not know everything. You may not be able to get a super accurate fixed bid if, say, you don’t actually know what CMS you want to be on, but it is better to be transparent and hear from a swath of potential partners about how they would help you make those decisions than to let partners ‘throw spaghetti at the wall and see what sticks’.
A 450-page site on twelve feature-rich templates and a 450-page newsroom site require different levels of effort.
Project scope and goals
Start with goals. Framing them as the outcomes you need instead of the features you want gives agencies a chance to show you how they would meet those goals, and you may find some surprising, creative opportunities in the answers. “Increase inquiries from prospective graduate students” is a goal. “A program finder” is one of several ways to get there.
Then say what success looks like. Goals tell an agency where you want to go; a short list of indicators tells them how you will know you got there, and it turns “is the new site working?” from a feeling into a question with an answer. Three to six is plenty: inquiries and applications started from the site, whether a prospective student can find a program’s deadline and cost in a couple of clicks, whether AI search tools cite your pages for program questions, accessibility conformance after launch, how long it takes an editor to publish a page. Capture a baseline before launch so there is something to compare against. Agencies will propose better measurement approaches if they know what you plan to measure, and it sets up the reporting conversation later in the RFP.
Then scope. This is often where an RFP loses the plot: it gives a page count with no sense of the features, functionality or complexity behind it. It helps a lot to describe the site in page templates and features, not just pages. A 450-page site on twelve templates and a 450-page site that is mostly basic content with no unique features are different jobs, and “approximately 450 pages” on its own tells an agency very little. Think carefully about the content, too. Migrating it, rewriting it and writing it new are three different levels of effort, and if the RFP doesn’t say how you want content handled, agencies will make a lot of assumptions.
If the platform is undecided, we think the better move is to split the work. A short discovery RFP for research, maybe a content model, a platform recommendation and a scoped plan can help. The design and development RFP can then be fixed price. It feels like an extra step, but in our experience it gets you a clearer budget.
A site organized around the org chart serves nobody.
Budget considerations
Be transparent with your budget. It helps everyone. It keeps vendors who cannot work within your budget from responding. With a number in hand, partners can tell you what it is possible and where you may have to make trade-offs. If you can’t publish a figure, publish a range, and say whether it includes CMS licensing, hosting and third-party fees. Our redesign cost post has ranges if you need a starting point.
It also helps to outline what can be budgeted separately: the post-launch retainer, any AI chatbot, content writing beyond a set number of pages, photography. If you ask for those as priced options so you can decide on those a la carte.
Without a budget, vendors guess, and the guesses range so widely that the proposals cannot be compared.
Timeline and milestones
It helps to give two timelines. The procurement timeline and the project timeline. The procurement timeline includes: issue date, question deadline, when answers are published, proposal deadline, interviews, notice of selection. In our experience it is a few months from first draft to signed contract, longer at public institutions, so it is worth working backward from there.
The project timeline is tricky because you are asking your future partner to agree to a timeline before they really know your working style and your team’s availability. Share the constraints that are real: the admissions cycle, commencement, an accreditation visit, a platform contract that expires. Give a desired launch and say whether it is a hope or a hard date. Then ask each agency for their milestones and, more usefully, the decisions and materials they will need from you.
Crafting your website design proposal
Defining your target audience
Start by listing your audiences and their key goals on the site. Prospective undergraduates, their parents, transfer students, graduate prospects, current students, faculty and staff, alumni and donors, the community.
It also helps to say which audiences are the priority, because they can’t all be. If you have research, attach it. If you don’t, that is okay too; just say so.
Design concept expectations
We’d encourage you not to ask for design concepts in the proposal. Concepts produced in two weeks without research or your content are guesses, and they tend to reward the firm with the most free time rather than the best process. Case studies, an approach walkthrough and references will tell you more. If you really want to see design thinking before you sign, it is reasonable to pay a finalist for a short, scoped exercise.
‘The site must support AI’ is not a clear requirement.”
Technical specifications and requirements
Most website RFPs cover the technical basics well: CMS, hosting, responsive design, integrations. Five areas have changed in the last few years and are worth some extra attention.
AI search. Prospective students now ask ChatGPT, Google’s AI Mode, Perplexity and Copilot about you, so your site needs to be readable and quotable by those tools. Writing “the site must support AI” in the RFP won’t get you that, because agencies read it two different ways: some will propose an AI product, like a chatbot or AI personalization tools, and others will propose making your content visible to AI search. Be clear about what you want. If it is AI search, ask each agency what they would do to your most important pages, how they would measure whether AI tools cite you compared with peer institutions, and what they would report 90 days after launch. (Our AI visibility and SEO and GEO pages describe this work, and GEO vs. SEO explains the thinking behind it.) If you also want a chatbot, a personalization engine, or embedded AI/conversational search in the site, ask for it as a separately priced option so you can see its cost on its own.
Content portability. Nobody knows which web platforms will matter in 2030, which makes committing to a content management system a somewhat anxiety provoking decision. Ask each agency to describe, in a page, how your content would be exported: in what format, how much effort it would take, and who owns the design system and code afterward. Ask, too, whether the content model (the definition of a course, a program, a person, an event) is documented separately from the CMS, so it can move with you. Structured content like that is also what AI search tools read best.
Accessibility. The standard to require is WCAG 2.2 AA, which has been current since October 2023. The ADA Title II web deadlines were extended in April 2026, to April 2027 for larger public entities and April 2028 for smaller ones. Who on the agency team does accessibility testing, how do they test, and do they test with real assistive technology or only automated tools. (Here is how we approach accessibility, including testing with people who use assistive technology.)
Security and data. Your IT and procurement colleagues will need answers to these eventually, so it saves time to ask in the RFP. Does the agency hold a current SOC 2 Type 2 report, and will they share it under NDA? Where will your data be stored during the build? Which AI tools does the agency use in its own work, what of your content goes into them, and how long is it kept? We went through SOC 2 ourselves and it was a bit of a bear, but it means we now have a third-party verified report we can hand to a review committee.
Integrations. List every system the new site has to connect to: the CRM (Slate, Salesforce), the student information system, the course catalog, the events calendar, the giving platform, the directory. Ask each agency to state its assumptions and any third-party costs for each one. Integrations are the most common source of surprise costs in a fixed-price build, so the more detail you give here, the more accurate the proposals will be.
Integrations are where fixed bids go to die.
Evaluation criteria for vendors
Scoring framework
We recommend publishing your scoring criteria and their weights in the RFP. Agencies write to what you score, and a committee that has agreed on a rubric before the proposals arrive has an easier time choosing. The right criteria depend on your institution, but as a light example: an RFP might put the most weight on how well a proposal responds to your specific goals and on the approach, including how the agency would handle search and AI visibility; a similar share on the team and their comparable launches, and on overall value rather than lowest price; and a smaller share on references.
Security documentation is better treated as pass/fail before scoring than as points. And it helps to structure the contract in two parts: a fixed-scope build, and a separate, optional, priced retainer for what comes after.
Launch is no longer the end of the project; it’s closer to the midpoint. Asking potential partners what that retainer should contain (content, measurement and reporting, search and AI visibility, accessibility upkeep) is one of the more revealing questions in the RFP, because it shows what each one thinks will matter.
The importance of cultural fit
You will be in a weekly meetings with these people for a long time. Liking them is important, and so is transparency. Will they tell you the truth when if schedule slips? How do they manage cultural change management? How they handle disagreements? Interview the project team, not the sales team, and notice who answers the hard questions.
Before you send your website RFP out
The web will keep changing. A great partner can support your institution’s journey through this new web landscape.
Want a sounding board to get that RFP just right? We read a lot of these, and we’re happy to tell you what will confuse vendors and what will get you a clear answer on budget, with no obligation on the other side of it. Contact us and we’ll take a look. And enjoy this website RFP template which is free to download.
Frequently asked questions about website redesign RFPs
Discovery gets you research, a content model, a platform recommendation and a scoped plan. Implementation, written from that, buys the build against a known scope and can carry a real fixed price.
Not always. Sole-source thresholds, cooperative purchasing agreements and an RFI first are all worth checking with procurement before you write anything.
Ten to fifteen pages if the goals, constraints and scoring are clear. Feature checklists every agency will tick add length and no information.
