When a small business asks for a website redesign, proposals often arrive in incompatible shapes. One vendor sells page count, another sells a visual direction, and a third sells a custom system. The cheapest number may not describe the cheapest project, because the missing work appears later as copywriting, redirects, integrations, subscriptions, or an emergency fix after launch.
The buyer's job is to make the proposals comparable before making a selection. Start with the customer decisions the site must support, then test whether each proposal includes the content, evidence, implementation, measurement, and handoff needed to support them.
Define the job before reading the proposals
A redesign can mean a new visual layer, a search-preserving migration, a conversion repair, a new booking or quote flow, or a broader change to how the business operates online. Those are related projects, but they are not interchangeable.
Write a one-page brief that answers:
- Which audience and services matter most?
- Which actions count as success: qualified calls, quote requests, bookings, purchases, or something else?
- Which pages and URLs already earn traffic, leads, links, or trust?
- Which systems must continue working, such as forms, calendars, payments, CRM routing, analytics, or email?
- Who will approve content, supply proof, maintain the site, and own the accounts after launch?
- What deadline, budget range, and ongoing cost can the business actually support?
If the brief says only “make the site modern,” every vendor will fill in the blank differently. The website content preparation guide can help collect the business facts, offer details, proof, assets, and approvals that make a redesign brief usable.
Compare buyer paths, not page counts
Page count is easy to quote and hard to evaluate. A five-page site can contain a complete path for one service, while a fifteen-page site can repeat the same promise with different headings. Ask each vendor to map the pages to a buyer's decision:
| Buyer question | Evidence the proposal should name | Useful acceptance test |
|---|---|---|
| What does this business do for me? | Audience, problem, service, outcome, area served | A first-time visitor can identify fit and the next step quickly |
| Can I trust it? | Reviews, credentials, examples, guarantees, team, process | Proof is specific, current, and placed beside the relevant claim |
| Is this service right for my situation? | Scope, exclusions, pricing context, FAQs, response expectations | A qualified visitor can self-select without guessing |
| What happens if I contact or book? | Form fields, availability, confirmation, routing, fallback | A test submission reaches the business and explains what happens next |
| Can I find this from search or a referral? | Distinct URLs, titles, headings, internal links, redirects | Important pages are crawlable, linked, and mapped from old URLs |
Use the page-planning guide to decide when a service or location deserves its own complete answer. A proposal should explain why a page exists, who it serves, and where it leads, not just promise a number of templates.
Normalize the scope into comparable lines
Copy every proposal into one comparison sheet. Use the same line items for each vendor and mark every item as included, optional, excluded, client-supplied, or unclear. This turns persuasive language into a decision record.
- Strategy and information architecture: discovery, audience and offer decisions, navigation, page-purpose map, wireframes, and content model.
- Content: copywriting, editing, migration of existing text, image sourcing, reviews, case studies, metadata, and approvals.
- Design and build: responsive layouts, components, templates, CMS or platform setup, forms, booking, ecommerce, and integrations.
- Search preservation: URL inventory, redirect map, canonicals, metadata, structured data, sitemap, robots rules, and Search Console checks.
- Quality assurance: browser and device coverage, accessibility review, performance checks, form and payment tests, analytics tests, and launch rollback.
- Handoff and operations: account ownership, roles, source or export files, documentation, training, backups, maintenance, and support.
- Commercial terms: fixed fee, payment schedule, revision limits, timeline assumptions, recurring subscriptions, renewal increases, and transfer fees.
The website package checklist is useful when a proposal says “complete website” but does not define content, forms, testing, hosting, ownership, or launch responsibility.
Treat migration as a deliverable
If the site already has useful pages, changing URLs or removing content creates real risk. Google recommends preparing a URL mapping, configuring redirects, checking canonicals and robots rules, testing redirects, updating internal links and sitemaps, and monitoring both old and new URLs during a move. Read its current site-move guidance before accepting a proposal that calls migration “included” without describing the work.
Ask for these artifacts before signing:
- An inventory of current indexable URLs, important landing pages, forms, analytics, and business profiles.
- A proposed keep, improve, merge, redirect, or retire decision for each meaningful URL.
- A one-to-one redirect map for changed URLs, with a plan to avoid irrelevant redirects or chains.
- A pre-launch and post-launch checklist for canonicals, noindex rules, robots.txt, internal links, sitemaps, structured data, and Search Console.
- An owner and duration for monitoring traffic, indexing, forms, calls, and errors after launch.
Use the redesign SEO migration checklist to turn those requests into line items. A proposal that promises a new look but has no URL or measurement plan is pricing only the visible part of the change.
Test the conversion and measurement plan
A redesign should make an important action easier to complete and easier to learn from. Ask which events the vendor will measure, where each event is sent, and who can access the data. “Analytics installed” is not enough if the business cannot tell a qualified form from a privacy-page visit.
Google Analytics describes event parameters as context about an interaction, such as which button was clicked or which product entered a cart. Its event-parameter documentation supports a practical buying test: the proposal should say what meaningful actions are tracked and which parameters make them understandable.
For a local service business, a useful measurement plan may include:
- quote or contact form started, submitted, failed, and confirmed
- clicks on phone, email, directions, booking, and primary service CTAs
- booking completion, cancellation, reschedule, or payment status when relevant
- source, campaign, service, location, and device context without collecting unnecessary personal data
- a monthly report that separates traffic, qualified inquiries, booked work, and revenue
Require a real test in the acceptance criteria: submit a representative inquiry, verify delivery to the correct business-controlled destination, confirm the confirmation message, inspect the recorded event, and document the fallback if the integration fails.
Put quality, accessibility, and access in writing
Quality is not a mood board. It is a list of conditions the delivered site must meet on the devices and paths that matter. The W3C WCAG 2.2 Recommendation covers perceivable, operable, understandable, and robust web content. Ask the vendor which criteria and components will be reviewed, how keyboard and focus behavior will be checked, and what third-party limitations remain.
Performance also needs a defined method. Google's Web Vitals guidance says the current Core Web Vitals focus on loading, interactivity, and visual stability, with recommended targets for LCP, INP, and CLS at the 75th percentile. A proposal does not need to guarantee a score it cannot control, but it should name the templates, assets, scripts, and field or lab checks included.
Finally, verify control. The business should own the domain, hosting or platform account, analytics, Search Console, business listings, form destination, booking system, payment account, source or export files, and billing identity. Vendors can have delegated roles. They should not be the only person who can recover the revenue path.
NIST's small-business Cybersecurity Framework resources emphasize practical risk management, including protecting accounts and preparing recovery. Add account roles, multifactor authentication, backups, and a handoff test to the proposal instead of leaving them to goodwill.
Compare first-year cost, not the launch invoice
Build a first-year total for every proposal:
| Cost bucket | Questions to ask |
|---|---|
| Project fee | What is included, what triggers change orders, and how many revision rounds are real? |
| Client effort | How many hours of copy, photos, approvals, data entry, testing, and training must the team provide? |
| Platform and services | What renews for hosting, CMS, forms, email, booking, payments, plugins, fonts, or monitoring? |
| Migration and launch | Are redirects, content transfer, analytics, DNS, QA, rollback, and post-launch fixes included? |
| Ownership and exit | Are transfer assistance, exports, source files, and account changes included or separately billed? |
| Maintenance | Who updates content, patches dependencies, tests forms, monitors errors, and responds when something breaks? |
Keep one-time project cost separate from recurring operations, but show both. The small-business website cost guide gives a broader way to think about build, platform, content, maintenance, and migration costs.
Example: three proposals for the same contractor
Imagine a roofing company with an existing site, four profitable services, a service area, a quote form, and several pages that receive organic traffic. It receives three proposals:
- Proposal A: a low-cost template refresh with ten pages, client-supplied copy, no redirect map, and hosting billed separately.
- Proposal B: a fixed-scope redesign with a service and proof architecture, migrated content, responsive QA, analytics events, redirect map, business-owned accounts, and thirty days of launch support.
- Proposal C: a custom application with a higher fee, a new CRM workflow, and broad automation that the brief does not require yet.
Proposal A may look cheapest but leaves the search and content work with the client. Proposal C may be capable but asks the business to fund infrastructure before proving that the core buyer path needs it. Proposal B is the best fit only if its acceptance criteria are real and the business can maintain the included system. The point is not that fixed scope always wins. The point is that fit becomes visible after the three proposals are normalized against the same job.
Recognize proposal red flags
- “Unlimited” pages, revisions, or support with no definition of completion.
- Guaranteed rankings, leads, or performance scores with no conditions or measurement method.
- A redesign that promises to delete or rename URLs without an inventory and redirect plan.
- “SEO included” with no titles, internal links, canonicals, structured data, sitemap, or post-launch checks named.
- Hosting, domain, analytics, forms, or Business Profile ownership held in a provider's personal account.
- Stock imagery, fonts, plugins, or code with no license, renewal, or transfer terms.
- A launch date that depends on client content but does not list the required inputs or approval windows.
- A polished homepage concept with no service-page, proof, quote, booking, mobile, accessibility, or failure-state plan.
Red flags do not automatically disqualify a vendor. They identify questions that need a written answer before a deposit becomes difficult to recover.
Use a short decision process
- Issue the same brief. Give every vendor the same goals, existing URLs, services, proof, integrations, timeline, budget range, and ownership expectations.
- Normalize the proposals. Copy each deliverable, exclusion, assumption, recurring cost, and acceptance test into one sheet.
- Test the risky parts. Ask for one representative service page, one conversion flow, a sample redirect, and an account-ownership explanation.
- Check the team fit. Confirm who does strategy, writing, design, development, QA, launch, and support, and who is available when something fails.
- Choose the smallest complete scope. It should close the most expensive gap, preserve what already works, and leave a clear path for the next phase.
- Attach the acceptance schedule. Put deliverables, tests, ownership, recurring fees, content responsibilities, and exit terms in the agreement.
If the business first needs to understand whether a redesign is appropriate, start with the free website audit or compare Zendory's website build packages. Review the website examples to see how the scope connects page structure to real buyer paths.
Primary sources used for this proposal checklist
These first-party references support the migration, content, accessibility, performance, measurement, and account-security checks above. Platform features and legal or technical guidance can change, so verify the current terms that apply to the specific business and jurisdiction.
- Google Search Central site-move documentation, for URL mapping, redirects, canonicals, sitemaps, and post-launch monitoring.
- Google Search Central SEO Starter Guide, for descriptive titles, useful links, and people-first search fundamentals.
- W3C Web Content Accessibility Guidelines 2.2, the current web accessibility Recommendation.
- Google web.dev Web Vitals, for field performance metrics and the current Core Web Vitals thresholds.
- Google Analytics event-parameter documentation, for adding useful context to measured interactions.
- NIST Cybersecurity Framework 2.0 for Small Business, for practical account protection, recovery, and risk-management guidance.
The best redesign proposal is not the one with the most pages or the most impressive estimate. It is the one that names the buyer path, protects valuable history, measures the action that matters, defines quality, keeps the business in control, and makes the next improvement easier to fund.