Most website proposals look polished. That does not mean they’re comparable.
One agency quotes a clean redesign. Another includes SEO migration, analytics, speed work, content structure, accessibility review, and post-launch support. A freelancer sends a lower number, but the proposal leaves out hosting, forms, training, and ownership details.
On paper, the cheapest quote wins. Six months later, the cheap quote can become the most expensive one in the stack.
That is why you need a website proposal scorecard.
Not procurement theater. Not a 40-page committee document. Just a practical way to compare web design proposals by business risk, not by vibes.
This matters because website work is rarely a tiny purchase anymore. Clutch’s web design pricing guide says web design companies typically charge $2,000 to $100,000 depending on scope and complexity. Clutch’s web development pricing guide reports an average web development agency project cost of $66,499.09 based on reviews on Clutch. When the spread is that wide, you need more than a gut feeling.
Use the scorecard below before you sign a contract. It will help you spot missing scope, fuzzy promises, hidden ownership problems, and proposal language that sounds good but won’t help your business get more leads.
The quick version: score every proposal out of 100
Give every vendor the same scorecard. If one proposal is vague, don’t fill in the blanks for them. Score what they actually wrote.
| Category | Points | What you’re testing |
|---|---|---|
| Business fit | 10 | Do they understand your customers, sales process, and goal? |
| Scope clarity | 15 | Are pages, features, content, integrations, and exclusions clear? |
| Conversion plan | 10 | Will the site help visitors call, book, buy, or request a quote? |
| SEO and migration | 15 | Are redirects, metadata, internal links, indexation, and content risk covered? |
| Performance and accessibility | 10 | Are speed, mobile usability, and accessibility part of the build? |
| Measurement | 10 | Are analytics, events, forms, calls, and reporting defined? |
| Ownership and maintainability | 10 | Will you own the site, accounts, assets, code, and documentation? |
| Timeline and communication | 10 | Are milestones, feedback windows, approvals, and launch steps realistic? |
| Support and risk control | 10 | Is post-launch support, warranty work, backup, and issue handling included? |
A proposal above 85 is probably worth a serious conversation. A proposal between 70 and 84 may be workable if the gaps are easy to clarify. Anything below 70 should make you slow down, even if the price looks attractive.
The trick is not to punish small vendors. A two-person studio can score well if the scope is clear and the handoff is clean. A big agency can score poorly if the proposal is mostly brand polish and vague deliverables.
1. Business fit: 10 points
A strong website proposal should show that the vendor understands how your business makes money.
If you’re a local service company, the proposal should talk about calls, service areas, reviews, before-and-after photos, trust signals, and quote requests. If you’re a B2B company, it should talk about buying committees, lead quality, gated resources, sales follow-up, and long decision cycles.
Score this section like this:
| Score | What it means |
|---|---|
| 0 to 3 | Generic proposal with little connection to your business |
| 4 to 7 | Mentions your goals, but mostly repeats your own words |
| 8 to 10 | Connects website decisions to customers, sales process, and revenue |
A vendor does not need to know every detail before discovery, but they should not treat a dentist, machine shop, law firm, and HVAC contractor like the same project with different colors.
If the proposal starts with design trends instead of business problems, be careful. Nice design helps, but only when it supports the job the site has to do.
2. Scope clarity: 15 points
Scope is where website quotes usually stop being comparable.
One proposal may include ten custom page layouts. Another may include three templates and unlimited content entry. A third may include design only, with development billed separately. If you only compare the total price, you are not comparing the same job.
A clear proposal should define the page types, deliverables, content responsibilities, revision limits, integrations, CMS setup, user roles, forms, email routing, third-party tools, launch support, and explicit exclusions.
This is not nitpicking. PMI has reported that 37% of projects fail because of inaccurate requirements gathering. On a website project, inaccurate requirements usually show up as change orders, delayed launches, rushed content, missing tracking, and arguments about what was “included.”
Give full points only when the proposal makes the work easy to inspect. You should be able to hand the proposal to another business owner and have them understand what is being built.
A vague scope is not always malicious. Sometimes the vendor is trying to keep the proposal short. But if the scope is unclear before payment, it rarely gets clearer when deadlines are tight.
3. Conversion plan: 10 points
Your website is not a brochure if it needs to produce leads.
A good proposal should explain how the new site will move visitors toward action. That includes page hierarchy, calls to action, trust signals, offer placement, form length, phone visibility, mobile behavior, and what happens after someone submits a form.
This is where a cheap redesign can quietly fail. The site may look better, but if the proposal does not discuss conversion paths, you may end up with a prettier version of the same lead problem.
Ask how the vendor will handle key pages like your homepage, service pages, pricing or quote pages, contact page, location pages, case studies, testimonials, and resource content. They do not need to promise a magic conversion lift, but they should explain the decisions that make a conversion lift more likely.
Portent analyzed 20 websites, more than 100 million page views, and over 27,000 landing pages. For B2B lead generation sites, Portent found that a site loading in 1 second had a conversion rate 3x higher than a site loading in 5 seconds. That is a conversion issue, not just a technical issue.
Score low if the proposal says “modern design” but never explains how visitors become customers.
4. SEO and migration: 15 points
This is the section that saves businesses from painful redesign mistakes.
If you already have search traffic, the proposal should include an SEO migration plan. That plan should cover current URL inventory, redirect mapping, title tags, meta descriptions, headings, internal links, XML sitemap, canonical tags, Search Console review, indexing checks, and a post-launch crawl.
If the vendor says SEO is not included, that is not automatically a dealbreaker. But it must be clear. You need to know whether someone is protecting existing rankings or whether you need a separate SEO partner before launch.
Google’s Search Console documentation says the platform helps site owners monitor search traffic, fix issues, and understand how Google sees a site. If the proposal never mentions Search Console, indexation, or redirects on a redesign, score it down.
For local businesses, this section should also include location pages, service area pages, Google Business Profile links, review markup where appropriate, and consistent name, address, and phone information. For B2B companies, it should include resource URLs, blog redirects, industry pages, and old lead magnets that still attract links.
The simplest test is this: if the new site launches, what happens to every valuable old URL? If the proposal cannot answer that, the proposal is incomplete.
5. Performance and accessibility: 10 points
Performance and accessibility are not bonus items. They affect usability, search, conversions, and legal risk.
Google’s Core Web Vitals documentation defines user experience metrics for loading performance, responsiveness, and visual stability. Those are not abstract developer terms. They describe whether a visitor can open your page, interact with it, and trust that the layout will not jump around while they are trying to tap a button.
Accessibility deserves the same practical treatment. WebAIM’s 2026 Million report found 56,114,377 distinct accessibility errors across one million homepages, an average of 56.1 errors per page. WebAIM also notes that automated tools do not catch every failure, so a low-error scan is not the same thing as full accessibility conformance.
A proposal does not need to promise perfection. It does need to define the standard. Look for references to responsive testing, keyboard navigation, color contrast, form labels, alt text process, heading structure, image optimization, lazy loading, caching, and performance testing.
If the proposal treats accessibility as a plugin and speed as a hosting upsell, score it low.
6. Measurement: 10 points
A website project without measurement is a guessing project.
The proposal should define how success will be tracked. At minimum, you want analytics setup, form submission tracking, phone click tracking, key button events, thank-you pages or conversion events, Search Console, and a simple post-launch reporting plan.
Google Analytics 4 documentation explains that events measure specific user interactions on a website or app. That matters because a contact form view, form submission, quote button click, phone tap, and file download are different actions. If everything is lumped into pageviews, you will not know whether the new site is doing its job.
Ask what will be tracked, who will own the analytics accounts, who will verify the events, and what report you will get after launch. If the vendor says “we install Google Analytics” and stops there, give partial credit only.
Measurement should also include lead handling. Where do forms go? Who receives them? Are spam controls included? Does the form connect to your CRM? Are submissions stored anywhere if email delivery fails?
These are boring details. They are also the details that decide whether a lead gets called back.
7. Ownership and maintainability: 10 points
This category protects you after the final invoice.
Your proposal should say who owns the domain, hosting account, CMS admin account, design files, code, content, images, analytics properties, tracking containers, plugin licenses, and documentation.
Do not assume ownership because you paid for the project. Ask directly.
The proposal should also explain how the site will be maintained. If the site is built on WordPress, who handles updates, backups, security, and plugin renewals? If it is built on a static framework, who can edit content, deploy changes, and recover from a bad release? If it is built on a hosted platform, what happens if you leave the vendor?
This is where business owners get trapped. The launch looks fine, but every future edit requires the original vendor because nobody documented the build or gave the client real access.
Score full points when ownership is plain, access is defined, and a future developer could reasonably take over the site.
8. Timeline and communication: 10 points
Website timelines fail when nobody defines approvals.
A realistic proposal should include project phases, stakeholder responsibilities, feedback windows, content deadlines, launch dependencies, meeting cadence, and what happens when either side misses a deadline.
Be cautious with timelines that sound too clean. A four-week website may be realistic for a focused project with ready content and fast approvals. It is not realistic for a larger redesign with custom copy, SEO migration, integrations, legal review, photography, and multiple decision-makers.
Asana’s guide to project failure lists unclear goals, scope creep, poor communication, and unrealistic expectations as preventable causes of project problems. Website projects are not immune to those issues just because the deliverable is a URL.
A good communication plan reduces rework. It gives you a clear process for decisions, not a pile of Slack messages, email threads, and last-minute calls.
9. Support and risk control: 10 points
The launch is not the finish line. It is the point where real users start finding what everyone missed.
A serious proposal should define post-launch support, bug fixes, warranty period, emergency response, backups, monitoring, training, documentation, and how future work is billed.
You do not need unlimited free support. You do need clear support.
Ask what counts as a bug versus a new request. Ask how long the warranty lasts. Ask whether launch day includes DNS support, form testing, analytics verification, redirect checks, and a live-site crawl. Ask what happens if a plugin conflict, hosting issue, or broken integration appears after launch.
Score low when the proposal says “30 days support” but does not define what support means.
Red flags that should slow you down
Some proposal problems are fixable with a follow-up question. Others are warning signs.
Watch for these:
- The proposal talks about aesthetics but not outcomes, tracking, SEO, or lead flow.
- The price is much lower than the others, but the deliverables are thinner or undefined.
- The vendor will not clarify ownership of code, design files, hosting, analytics, or admin access.
- SEO migration is missing from a redesign proposal for a site with existing traffic.
- The timeline depends on “quick feedback” but does not define feedback windows or decision owners.
- The proposal includes accessibility, performance, or security language without specific checks.
- The payment schedule is clear, but the acceptance criteria are not.
One red flag does not always mean you should walk away. It means you should ask for a written clarification before signing.
The questions to send every vendor before you decide
You can copy and paste these questions into your follow-up email:
- What exactly is included in the quoted scope, and what is excluded?
- How many page templates, custom pages, revisions, and content entries are included?
- Who is responsible for writing, editing, uploading, and approving content?
- What is your SEO migration process for existing URLs and search traffic?
- What performance targets do you test against before launch?
- What accessibility checks are included, and what standard are you using?
- Which analytics events and conversions will be tracked?
- Who owns the domain, hosting, CMS, code, design files, analytics, and tag manager accounts?
- What happens during the first 30 days after launch?
- What would increase the price after the contract is signed?
If a vendor answers these clearly, your risk drops. If they dodge, your risk goes up.
How to choose when two proposals both score well
If two vendors both score above 85, price can become a fair deciding factor. But do not stop there.
Look at the difference between the two proposals. One may be stronger on content and SEO. Another may be stronger on design and development. One may offer better long-term maintenance. Another may have deeper experience in your industry.
For most small businesses, I would rather choose the proposal with clearer scope, better ownership terms, and stronger post-launch support than the one with the flashiest mockups.
A website is not just a launch project. It becomes the front door, sales assistant, quote desk, hiring page, and proof point for your business. The proposal should respect that.
Final recommendation
Score the proposal before you fall in love with the presentation.
A strong web partner will not be offended by clear questions. They will usually appreciate them because clear requirements reduce rework for both sides.
If you want help comparing quotes, tightening your scope, or turning a messy website plan into a clean build, start here: get started with Your Web Team.
Richard Kastl
Founder & Lead EngineerRichard Kastl has spent 14 years engineering websites that generate revenue. He combines expertise in web development, SEO, digital marketing, and conversion optimization to build sites that make the phone ring. His work has helped generate over $30M in pipeline for clients ranging from industrial manufacturers to SaaS companies.