A website redesign RFP that makes proposals comparable.

A website redesign request for proposal should help several suppliers price and explain the same business problem. It needs enough detail to expose differences in scope, delivery and ongoing costs, while leaving room for a supplier to suggest a better approach.

Download the editable website redesign RFP template and scorecard. It is a plain-text file, requires no email address, and can be used with any supplier. The Absurd Company provides website redesign services; this guide reflects our practical approach to defining work, not an independent ranking of agencies.

Decide whether you need an RFP

An RFP is useful when several teams need to agree requirements, procurement needs comparable responses, or the project carries meaningful migration and integration risk. A small, well-defined improvement may only need a short brief and a scoped proposal. Do not create weeks of paperwork for a task that can be described and evaluated directly.

A website brief explains the problem and desired result. An RFP adds a common response format, evaluation criteria, commercial questions and a decision process. That distinction matters: a long description of your company does not make two quotes comparable.

Describe the existing website before specifying its replacement

Give suppliers the current URL, platform, content types, important integrations and account owners. Explain what works as well as what needs to change. Include a URL inventory if one exists, with the pages that bring useful enquiries or support customers.

State the audience, served markets and primary action. “Improve our website” leaves most decisions open. “Help business buyers understand three service packages and submit an enquiry that reaches our sales team” gives suppliers something to design and test. It still leaves space to challenge whether those packages are clear.

Separate observed problems from hypotheses. If you know that enquiries fail to arrive, say how that was established. If you suspect visitors cannot find a service, label that as a question to investigate. Avoid presenting assumptions as analytics findings.

Make responsibility visible in every scope item

For design, development, copy, images, migration, integrations, testing and training, state whether the supplier provides it, your team provides it, it is excluded, or the decision remains open. Ask suppliers to return the same responsibility list with their proposal.

For example, “content included” might mean moving approved paragraphs into templates. It might instead mean interviewing your team, rewriting service pages and obtaining approval. Those are different jobs. Ask for the number and type of content items, the approval owner and the included review process.

Have each bidder identify assumptions that affect its website redesign cost. A smaller price is useful only when you understand what has been removed or transferred to your team.

Specify launch evidence, including the enquiry journey

Ask for acceptance evidence tied to an observable task. An enquiry should reach the agreed destination, the visitor should receive accurate status, and an operational owner should be able to detect a failure. A button animation or an opened email application cannot establish delivery.

For a content editor, require a handover demonstration of the updates they actually need to make. For navigation and forms, specify keyboard use, small-screen behavior, errors and retries. Agree accessibility requirements and the evaluation method before pricing; a generic promise to be “accessible” leaves too much unresolved. W3C’s evaluation resources explain the role of evaluation throughout a project.

If URLs change, require an approved redirect map and a launch verification owner. Google’s site-move guidance provides the search-specific planning context. A redesign proposal should explain its migration work without promising a particular ranking after launch.

Compare the full ownership and support arrangement

Request a breakdown of one-time work, recurring services, third-party licenses and renewals. Record the currency and how tax is treated. Ask who owns the domain account, hosting, code, content and design files, and what the client can export if the relationship ends.

Support needs a scope. A defect correction period, content maintenance, hosting operations and a new-feature retainer are different commitments. Ask for the included hours or activities, duration, response arrangement and escalation path. Do not infer ongoing support from the word “handover.”

For integrations, identify the third-party account owner and dependencies. Payment, booking or CRM eligibility should be confirmed before a platform choice becomes a fixed promise. Record which integration costs are estimates and which have been verified.

Score proposals against a brief, not a presentation

Choose criteria before opening the proposals. The downloadable template suggests weights for understanding the problem, relevant delivered evidence, complete scope, delivery risk, ownership and comparable total cost. They are an editable planning example, not a universal procurement formula.

Score each criterion from zero to five and record the evidence behind the score. “Relevant work” should describe what the supplier actually delivered. Distinguish a live client project, a concept, a subcontracted contribution and a result measured by someone else. None should be silently presented as another.

Normalize exclusions before comparing totals. If one supplier excludes copywriting or migration, request a consistent option or account for the work your team must perform. Ask the same material clarification questions of each shortlisted supplier and record their answers.

Set a decision process your team can keep

Name the sponsor, final approver, proposal deadline, questions deadline and decision date. Explain any genuine launch dependency and the review time your team can provide. For remote work, agree meeting overlap and how feedback will be consolidated.

An illustrative example: a consultancy rebuilding forty service and insight pages may first shortlist suppliers on migration experience and editing workflow, then compare a core launch with a second content phase. That is a hypothetical procurement scenario, not an Absurd client result. It shows how a phased response can make budget choices clearer without pretending all forty pages need equal effort.

Before issuing the RFP, have an internal reviewer answer: could two competent suppliers interpret the essential requirements differently? If so, clarify the requirement or explicitly invite alternatives with assumptions. You need comparable choices, not identical creative ideas.

Bring a defined redesign brief

Use the RFP worksheet with your shortlist, or explore our website redesign services and redesign SEO checklist first. To discuss fit with Absurd, include your current URL, the business problem, important integrations and any fixed deadline in your project enquiry. The current enquiry tool prepares a draft for you to send through your email service.

← Back to the journal