Website RFP Template: What to Include Before Hiring an Agency

A useful website RFP does not begin with “we need a new website.” It begins with the business outcome, evidence of current problems, audience tasks, page/template inventory, content and CMS ownership, integrations, SEO/analytics/accessibility/performance acceptance, security constraints, timeline and procurement process. The best RFP gives vendors enough shared evidence to propose different solutions without forcing them to guess what “included” means.

What you'll learn / decide

• what belongs in a vendor-ready website RFP before an agency is asked for price or timeline;
• how to separate business outcomes from solution assumptions;
• which launch controls are critical and what evidence proves each is complete;
• who should own UX, SEO, engineering, analytics, accessibility and security requirements;
• how to make proposals comparable without pretending one universal score can choose an agency;
• how to export a concise brief and scorecard from the interactive generator above.

Last reviewed: October 7, 2026. Search, analytics, accessibility and platform guidance changes. Re-check current primary documentation before a major procurement or relaunch.

Decision snapshot for Website RFP Template

A website RFP should define the decision boundary, not pre-design the solution. Give every vendor the same business goal, constraints, evidence, page/template inventory, operating model, integration needs, quality requirements and acceptance evidence. Then let vendors explain how they would solve the problem, what assumptions they made, what is excluded and what changes cost or timeline.

The most important tradeoff is specificity versus premature prescription. If the RFP is vague, proposals price different projects and cannot be compared. If it dictates every technology and component without a real constraint, it can prevent a stronger solution. Be precise about outcomes, dependencies and evidence of done; stay open where implementation choices are genuinely negotiable.

The interactive lab above turns this approach into two artifacts: a vendor-ready project brief and a 24-check evidence worksheet. Use the progress views to find missing ownership before issuing the RFP.

Start with business outcome and constraints

An agency cannot make a strong architecture, UX or content recommendation without knowing what the site is supposed to change.

Write the outcome in business language:

• increase qualified demand from specific audiences;
• make a complex product easier to evaluate;
• reduce reliance on developers for routine publishing;
• support a new market or product line;
• consolidate brands or properties;
• replace a fragile CMS or integration stack;
• improve ecommerce discovery and checkout;
• preserve organic visibility through a redesign;
• make measurement trustworthy enough for investment decisions.

Avoid outcome statements such as “modernize the website” unless “modern” is translated into an observable business or operational change.

Define constraints separately

Constraints can include launch window, regulatory/security review, existing design system, mandatory CRM/commerce/identity platform, hosting policy, data residency, localization, accessibility acceptance, internal engineering capacity, content readiness and budget or procurement rules.

A constraint is not automatically a requirement to keep the old architecture. Explain why it exists so a vendor can distinguish a fixed boundary from a preference.

Evidence of done

For the business-outcome section, completion evidence can be a one-page statement with baseline, intended change, primary audience, business owner, measurement owner and decision date. That is more useful than a list of adjectives about the future site.

Current-state problems and evidence

Do not ask vendors to solve problems you have not described. Build a compact evidence pack with representative examples.

UX evidence

Useful inputs include customer/sales objections, support themes, usability findings, funnel drop-offs, search/navigation failures, mobile-specific pain and stakeholder publishing friction. Avoid converting every analytics anomaly into a UX diagnosis. State what you observed and where uncertainty remains.

Technical evidence

Provide what you can safely share: current stack, CMS, hosting/deployment model, important third parties, integration list, known incident/performance issues, content/URL counts, migration history, design-system status and environment constraints.

SEO evidence

If the project changes URLs, templates, content architecture or domains, include current organic landing pages, critical URL families and known redirect/canonical/indexation risks.

Google Search Central's current site-move guidance emphasizes old-to-new URL mapping, updating internal signals such as canonicals and internal links, and using server-side permanent redirects for moved URLs. That makes migration ownership an RFP requirement when a redesign changes URL structure; it should not be discovered after the new information architecture is approved.

Evidence of done

Ask the internal team to attach current sitemap/URL inventory, top template examples, analytics/search baselines, integration map, known defects/constraints and existing design/content guidelines. The goal is not to dump every report into a folder. Give vendors enough evidence to understand the problem and ask better questions.

Audience, journeys and conversion goals

A site can have many audiences without treating them as equal. For each priority audience, define what situation brings them to the site, what they need to understand, what proof reduces risk, the next useful action and what happens after that action.

Separate journey goals from analytics events

“Submit a form” is an event. “Help a qualified technical evaluator understand implementation risk and start a sales conversation” is a journey goal.

Google Analytics currently recommends generate_lead when a user submits a form or request for information and provides additional lead-funnel events such as qualify, disqualify, working and closed-lead states. You do not have to use every recommended event, but the RFP should require a documented event model that connects website actions to meaningful downstream outcomes.

Conversion acceptance

For each critical path, ask the vendor to show evidence that the CTA is reachable and understandable, the form/checkout works with keyboard and mobile input, validation/error states are visible, success is not shown before server/business processing succeeds, analytics receipt is verified, and CRM/commerce handoff is verified where applicable. That turns “conversion optimized” into testable delivery criteria.

Required page/template inventory

A total page count is not enough.

Create a template inventory such as home, service/solution, industry, case study, pricing, comparison, product/feature, resource hub, article, campaign landing page, contact, legal, ecommerce category/product/cart/checkout if relevant, and authenticated/application surfaces if relevant.

For each template, note representative URLs, content model, special states, traffic/business importance and whether it will be migrated or newly created.

Why templates matter more than URLs

One hundred pages mapped to six structured templates can be more predictable than twenty highly bespoke pages with calculators, personalization, complex data or unique motion.

Ask vendors to state template count, reusable components, bespoke pages, content-model assumptions, responsive states, empty/error/loading states and what marketing can create without engineering.

Evidence of done

The page inventory is complete when every launch-critical URL has a destination template or explicit disposition: migrate, merge, redirect, archive or create new. Do not wait until content entry to make this decision.

Content, CMS and governance requirements

A CMS requirement should describe editor jobs, not a product logo alone.

Describe publishing workflows

Examples include building a campaign page from approved modules, publishing a case study, updating product proof, managing navigation, scheduling a release, previewing changes, localizing content, editing SEO metadata, restricting high-risk global components and rolling back/auditing changes. Then define roles and approvals.

Content responsibility

State who creates strategy/message framework, copy, customer proof, product data, images, illustration, video, legal content, metadata and migration mappings. If a vendor must produce content, specify the expected review cycle and source experts.

Governance evidence

Ask for content model, sample editor workflow, roles/permissions matrix, preview/publish behavior, documentation/training and ownership after launch.

Integrations and technical constraints

Every integration should be described as a behavior, not a logo.

For each system, include owner, read/write direction, data fields, authentication method, environment/sandbox, rate/usage considerations where known, error/retry behavior, consent/privacy dependency, monitoring and acceptance test.

Common website dependencies include CRM, marketing automation, scheduling, search, identity, PIM, DAM, ERP, ecommerce, payments, reviews, careers and analytics.

Critical path

An integration can block launch when the vendor cannot obtain credentials, sandbox access or a final data mapping. Put external access and decisions on the project critical path before design is “done.”

Technical architecture response

Do not ask only “What technology will you use?” Ask vendors to explain rendering/deployment model, CMS/data boundary, cache strategy, environments, release/rollback, observability, dependency ownership, integration failure behavior, how marketing changes reach production and what requires engineering after launch. This makes architecture comparable as an operating model.

SEO, analytics, accessibility and performance requirements

Quality categories should have acceptance evidence.

SEO

When applicable, require crawlable internal navigation, canonical policy, indexability/robots rules, sitemap ownership, redirect mapping, metadata, structured data for eligible visible content, hreflang/localization policy, rendered-content validation and post-launch Search Console monitoring.

Google's canonicalization documentation describes redirects, sitemap presence and rel=canonical among canonical signals; the preferred canonical is still a signal rather than an absolute command. For an RFP, the practical requirement is consistency: redirects, internal links, sitemap URLs and canonical annotations should express the intended architecture.

Analytics

Define key events, parameters, user/privacy constraints, consent behavior, ad-platform needs, CRM/offline handoff if used, QA method and reporting destination. “GA4 installed” is not an analytics requirement.

A better acceptance line is: “The agreed generate_lead event fires only after successful submission, includes the agreed parameters, respects consent behavior and is verified in the analytics/debug destination and CRM test record.”

Accessibility

W3C encourages use of the latest WCAG version; WCAG 2.2 is the current standard in this guide's reviewed source set. The RFP should identify the target level/scope and evidence expected.

At minimum, discuss semantic structure, keyboard access, visible focus, forms/labels/errors, zoom/reflow, meaningful alt text, motion, target sizes, color/contrast and modal/menu behavior.

Legal applicability varies by jurisdiction and organization. Procurement teams should route legal conclusions to qualified counsel rather than asking an agency to provide legal advice.

Performance

Current Core Web Vitals use LCP, INP and CLS as core user-experience metrics. Put performance into the RFP as representative templates, production-like media/scripts, test method, performance budget, third-party ownership and regression process.

Do not require a magic Lighthouse number on one empty page while production templates load different media and tags.

Security/legal/procurement requirements

Security scope depends on what the site handles. A public marketing site with a newsletter form has a different threat/data model from an authenticated portal or checkout flow.

Data boundary

Document personal data collected, sensitive fields, processors/third parties, retention expectations, credentials/secrets, admin roles, authentication if present, authorization requirements and logging/monitoring owner.

Vendor access

Define how vendors receive source control, CMS, cloud, analytics, CRM, domains/DNS and third-party credentials. Use least-privilege access appropriate to the system and remove access according to your offboarding policy.

Legal/privacy

The RFP can ask the agency to implement requirements supplied by your legal/privacy owner. It should not turn an agency proposal into the company's legal opinion.

Ask for a list of third-party tags/processors introduced, cookies/storage used, forms/data captured, external embeds and data flows. Then have the responsible internal/legal party decide the required notices, consent or contracts.

Procurement

State required insurance/vendor documents, security questionnaire, contract terms, data-processing review if applicable, invoicing/currency rules, IP/source-code expectations, subcontractor disclosure and reference requirements. Late procurement is a timeline dependency.

Timeline, budget and decision process

A useful RFP tells vendors how the decision will be made.

Timeline

Include RFP issued, question deadline, answer window, proposal deadline, shortlist, interviews/workshops, decision date, desired discovery start, target launch and immovable business dates. Ask vendors to identify assumptions that make the launch date plausible.

Budget

If you can share a budget range or ceiling, state the currency and what must fit inside it. If you cannot, still ask the vendor to separate discovery, design, engineering, migration/content, integrations, QA, launch, recurring services/software and optional phases.

Do not compare a fixed-price build that excludes migration to a larger proposal that includes migration, content and post-launch support as if they were the same project.

Decision process

Name decision makers, evaluators, technical reviewers, content/marketing owners and procurement/security/legal reviewers. A vendor should know whether the proposal is evaluated primarily on price, capability, operating fit, timeline, specialist expertise or some combination.

Vendor response scorecard and RFP template

Require every vendor to answer the same structure.

Vendor response sections

1. Understanding of outcome and current-state evidence.
2. Proposed approach and major assumptions.
3. Information architecture / UX / content approach.
4. CMS and editorial operating model.
5. Technical architecture and integrations.
6. Migration and SEO approach.
7. Analytics/measurement.
8. Accessibility/performance acceptance.
9. Security/privacy boundary.
10. Team, roles and availability.
11. Timeline and critical path.
12. Price/cost structure and recurring ownership.
13. Explicit exclusions.
14. Change-control process.
15. Evidence from relevant past work.
16. Risks and questions the vendor thinks the buyer missed.

Score after evidence, not before

The exported scorecard provides eight criteria with blank 1–5 buyer scores. Set criterion weights before reviewing final proposals.

A simple transparent method is weighted result = sum(score × buyer-selected weight). But the number is only a decision aid. Record the evidence behind each score and keep disqualifying constraints separate.

For example, a vendor that cannot satisfy a mandatory security requirement should not win because high design scores compensate mathematically.

Interview questions

Ask finalists:

• What assumption in our RFP creates the largest cost uncertainty?
• Which requirement would you challenge and why?
• Which workstream is most likely to delay launch?
• Show us what “done” looks like for migration, analytics and accessibility.
• What will our internal team own after launch?
• What happens when an integration fails?
• What can marketing change safely without engineering?
• How do you test on real devices and production-like data?
• How will you report scope changes before work is performed?
• What would you remove first if budget must shrink?

The answers expose operating maturity better than another portfolio slideshow.

Critical path: what can actually block launch

Not every RFP check has the same consequence. Treat these as potential critical-path controls when relevant: final URL/redirect mapping, CMS content readiness, integration credentials/data mapping, domain/DNS ownership, analytics event specification, payment/checkout dependencies, security review, privacy/legal approvals, accessibility-critical defects, production infrastructure access, stakeholder approval dates and release/rollback plan.

A “Critical” filter in the tool shows checks that can block launch or create expensive data/search/revenue risk.

Evidence beats status labels

“SEO done,” “analytics done” or “accessible” are status labels. Evidence is crawl export, redirect test, canonical sample, event debug receipt, CRM test record, keyboard test, performance trace, release runbook, screenshot/recording of a critical task or signed requirement/decision.

Make evidence part of the acceptance language before a vendor is selected.

Ownership and recheck cadence

An RFP is not only a vendor document. It is also an internal responsibility map.

The checklist assigns likely owner classes: Marketing, Design, Engineering, SEO, Data and Security. Change them to match your organization. The important point is that every acceptance item has somebody who can approve the evidence.

One-time versus recurring controls

Some checks are procurement-time, such as vendor response normalization, initial page inventory and the initial budget boundary.

Some repeat on releases: analytics validation, form/checkout handoff, performance, accessibility and deployment/rollback.

Some repeat monthly or after material changes: Search Console monitoring, third-party inventory, integration health and content governance.

If the RFP does not define day-two ownership, the site can be delivered “complete” while every recurring responsibility is unassigned.

How to use this RFP template

1. Edit the ten brief fields in the generator.
2. Filter to Critical and close only checks with real evidence.
3. Review category progress for weak requirements.
4. Review ownership progress for internal gaps.
5. Copy the vendor-ready RFP.
6. Add organization-specific legal/security/procurement clauses.
7. Issue the same core brief to every vendor.
8. Allow clarifying questions.
9. Require explicit assumptions and exclusions.
10. Set buyer-selected scorecard weights before reading final proposals.
11. Score against evidence, not brand familiarity.
12. Preserve the chosen brief as the baseline for change control.

WebDesignK can help turn the completed brief into a scoped web design and development implementation plan. Related guides include agency vs freelancer vs in-house, the website redesign checklist, and landing-page design cost drivers.

Source and legal boundary

This template uses current primary guidance for the areas that can change: Google Search Central for migration/canonical behavior, Google Analytics for recommended lead events, web.dev for Core Web Vitals and W3C for WCAG 2.2.

The checklist, severity labels, owner suggestions and scorecard are WebDesignK editorial procurement controls. They are not industry benchmarks, legal requirements or objective vendor rankings.

Security, privacy, accessibility-law and contracting obligations depend on jurisdiction and context. Use qualified legal/security specialists for conclusions that carry legal or regulatory consequences.

Frequently asked questions

How long should a website RFP be?

Long enough to define outcomes, constraints, evidence, ownership and response format; short enough that vendors can identify the real decision. Attach inventories and technical evidence rather than burying them in narrative.

Should I include a budget in the RFP?

If your organization can disclose a range or ceiling, state currency and what must fit inside it. If not, still require vendors to separate discovery, delivery, migration/content, integrations, QA, recurring software/services and assumptions.

Should the RFP prescribe the tech stack?

Only when a stack or platform is a genuine constraint. Otherwise describe operating, integration, security, publishing and performance requirements and ask vendors to justify their architecture.

How should we score agencies?

Set buyer-selected criterion weights before reviewing final proposals, score each criterion against evidence, and keep mandatory constraints/disqualifiers outside the arithmetic. Do not treat an editorial score as an objective vendor ranking.

What is evidence of done?

A specific artifact or test that proves the requirement: crawl output, redirect map, event receipt, CRM test record, keyboard test, performance measurement, content model, integration test or release runbook.

What should happen after selecting a vendor?

Preserve the accepted brief, assumptions, exclusions and evidence criteria as the baseline for discovery, statement of work, change control and launch acceptance.

Evidence

Sources and assumption boundaries

Fast-changing platform, pricing and search claims were reviewed on 2026-10-07T00:00:00.000Z. Interactive scores and scenarios are clearly labeled planning models, not sourced market benchmarks.

• Google Search Central — Site moves with URL changes Official current migration guidance on URL mapping, canonicals/internal links, sitemaps and permanent redirects. Reviewed October 7, 2026.
• Google Search Central — Canonicalization Official current canonicalization guidance and canonical signals. Reviewed October 7, 2026.
• Google Analytics Help — Recommended events Official current recommended events including generate_lead and lead-funnel events. Reviewed October 7, 2026.
• web.dev — Web Vitals Current Core Web Vitals definitions and user-experience measurement guidance. Reviewed October 7, 2026.
• W3C WAI — WCAG 2 Overview Current W3C accessibility standards overview; W3C encourages use of the latest WCAG version. Reviewed October 7, 2026.