How to Choose a Web Designer for a Small Business

Searching for a web designer often begins with portfolios and prices. Those are useful filters, but they do not reveal whether the finished site will make the offer understandable, help a mobile visitor act, deliver the lead correctly, remain accessible, preserve search value, or give the business control after the final invoice.

This guide provides a buying process for a local service business, professional practice, studio, restaurant, contractor, or other small organization purchasing a lead-generating website. It is not a substitute for legal, security, or accessibility advice for a regulated or high-risk project. Use qualified specialists when the website handles sensitive data, regulated claims, complex payments, accounts, or custom application logic.

Define the business outcome before looking at designers

A provider cannot scope the right website until the business names the customer decision it needs to improve. “A modern website” describes an appearance. “Help homeowners understand the three services, trust the crew, request an estimate, and receive confirmation” describes a working buyer path.

Write a one-page decision brief before requesting a quote:

• Audience: the customer, service area, and situation that should make the page relevant.
• Offer: what the business sells, how options differ, and which limitations must be clear.
• Proof: approved reviews, project examples, credentials, guarantees, policies, or process evidence.
• Primary action: call, book, request a quote, visit, order, apply, pay, or complete an intake.
• Lead handoff: who receives the action, what information arrives, and what confirmation the customer sees.
• Success evidence: the events and business records that will show whether the path works.

If the business is still choosing between one focused campaign and a broader site, start with the landing page versus website comparison. If page scope is the main uncertainty, use the small-business website page-planning guide before asking providers to quote different structures.

Choose the right type of provider for the actual scope

A visual designer, front-end developer, full-stack developer, copywriter, SEO specialist, and conversion strategist solve different problems. One person may cover several roles well, but the proposal should name the responsibilities rather than hide them behind “full service.”

The platform should follow the operating requirements. Compare editor skill, integrations, hosting, maintenance, SEO controls, and portability with the WordPress, Wix, Squarespace, and Webflow guide before accepting a provider's preferred platform as the default answer.

Ask for proof that resembles the decision in front of you

Three attractive homepages do not prove that a provider can structure service choices, preserve a migration, build a usable intake, or hand the site to a busy owner. Ask for two or three live examples that resemble the business model, complexity, or conversion path. Open them on a phone and complete the primary action yourself.

For each example, ask what the provider personally owned, what the client supplied, what constraints shaped the work, and what changed after launch. A designer should not disclose confidential client data, but they should be able to distinguish their contribution from photography, branding, copy, development, advertising, or SEO performed by someone else.

Review the live experience, not only a screenshot. Check whether the offer is clear without scrolling through a cinematic introduction, whether important text remains readable, whether navigation works by keyboard, whether forms explain errors, whether confirmation appears after submission, and whether the mobile action is easy to find. Zendory's website proof library shows the type of buyer path a portfolio example should make inspectable.

Require a written scope that follows the customer journey

A useful proposal names deliverables and responsibilities at the level where misunderstandings occur. “Five-page website” is not enough. The proposal should identify the pages, reusable sections, forms, integrations, content inputs, migration work, analytics events, revisions, testing, launch steps, hosting, maintenance, and exclusions.

Trace one customer from entry to business follow-up:

1. Which page matches the customer's search, referral, ad, or direct visit?
2. Where does the page explain the offer, fit, service area, price context, and proof?
3. What action is available on mobile and desktop?
4. Which fields are truly necessary, and where is submitted information sent?
5. What does the customer see if submission succeeds or fails?
6. How does the owner know the lead arrived, and who tests that delivery before launch?

Request an explicit assumptions list. Copy, photography, review permission, legal language, domain access, platform credentials, booking settings, and offer approval often belong to the client. The proposal should state those dependencies early enough to protect the timeline.

Turn quality claims into acceptance criteria

“Fast, accessible, mobile friendly, and SEO optimized” sounds reassuring but is difficult to enforce without tests. Ask the provider to translate each phrase into observable acceptance criteria using representative pages and real integrations.

• Mobile: responsive layouts, readable content, usable navigation, reachable controls, and the complete lead path on common viewport sizes.
• Performance: agreed pages tested with production-like images, fonts, forms, analytics, and embeds rather than an empty template.
• Accessibility: semantic structure, keyboard operation, visible focus, labels, error handling, alternative text, contrast, zoom, and other criteria appropriate to the project.
• Search foundations: crawlable navigation, unique titles and descriptions, canonical URLs, sitemap behavior, redirects where needed, indexability controls, and accurate structured data when eligible.
• Measurement: analytics under the business's account, agreed conversion events, lead-delivery testing, and a short verification record.

Google defines Core Web Vitals around loading performance, responsiveness, and visual stability, while its developer search guide asks sites to be secure, fast, accessible, and functional across devices. These are useful evaluation dimensions, not a promise that one tool score guarantees rankings or sales.

For accessibility, use the W3C's WCAG 2.2 quick reference to identify criteria and techniques relevant to the project. An automated scan can catch some failures, but it cannot replace keyboard review, content judgment, form use, and appropriate human testing.

Ask what the provider means by SEO

A small-business website needs sound search foundations, but “SEO included” can mean anything from a title field to a complete research and publishing program. Separate launch implementation from ongoing growth work.

At launch, ask who owns keyword and intent mapping, page titles, descriptions, headings, internal links, canonical URLs, redirects, sitemap submission, indexability, local business information, analytics, Search Console access, and structured-data validation. Google's LocalBusiness structured-data documentation requires accurate properties and validation; adding markup is not permission to invent ratings, services, locations, prices, or business facts.

Ask what happens after launch. Publishing useful service pages, maintaining local proof, earning mentions, reviewing Search Console, and improving weak pages are ongoing activities. Reject a guaranteed ranking and ask for a clear statement of controllable deliverables instead.

Keep critical accounts under business control

The business should understand who controls the domain registration, DNS, website platform, hosting, source files or export, analytics, Search Console, form destination, payment provider, booking system, email, billing, and recovery methods. A provider may manage those systems, but management should not depend on an account the business cannot identify or recover.

ICANN explains that the domain registrant enters the registration agreement and manages domain settings through the registrar. Use its registrant information to understand domain responsibilities, transfer, renewal, and restoration before allowing a contractor to register the business domain under an unknown identity.

Google's Analytics account-structure guidance describes an account as data owned by a legal entity and recommends a simple structure for a business with one website. Create business-owned accounts first, then grant the provider the role needed for the project.

Require multifactor authentication wherever supported, especially for domain, hosting, email, analytics, and administrative access. CISA's small-business MFA guidance recommends starting with administrative and privileged accounts and using stronger phishing-resistant options where possible.

Score proposals on the complete operating result

Use a weighted score before discussing preference. Give every candidate the same brief and evidence request, score independently, then discuss the differences.

A score does not remove judgment. It exposes why a beautiful but vague proposal feels risky and why a more expensive quote may create lower operating cost. Compare the ranges and hidden categories in the small-business website cost guide.

Ask these questions before signing

1. Which customer action and business result will organize the build?
2. Which pages, reusable components, forms, and integrations are included?
3. Who writes, edits, approves, and legally reviews the copy?
4. Who supplies photography, logos, reviews, credentials, and service details?
5. Which live projects are comparable, and what work did you personally perform?
6. How will you test the primary path on mobile and by keyboard?
7. Which performance and accessibility checks are included, on which pages, and when?
8. What does launch SEO include, and what ongoing SEO work is excluded?
9. How will redirects and existing search pages be protected during a redesign?
10. Whose accounts will hold the domain, hosting, analytics, Search Console, and form data?
11. What access will you retain after launch, and how can the business revoke it?
12. How many revision rounds are included, and what counts as a scope change?
13. Which client dependencies can move the delivery date?
14. What support, updates, backups, monitoring, and renewal costs begin after launch?
15. What files, documentation, training, and acceptance record will the handoff include?

Treat vague guarantees and hidden control as red flags

• A guaranteed first-page ranking, conversion rate, or revenue result without controllable assumptions.
• A proposal that names a page count but not the offer, proof, forms, confirmation, or lead destination.
• A refusal to identify who controls the domain, hosting, platform, analytics, or recovery methods.
• Only mockups or screenshots, with no relevant live work the buyer can operate and inspect.
• Accessibility, performance, security, or SEO claims with no acceptance criteria.
• An unrealistically short schedule that ignores copy, assets, approvals, integrations, migration, and testing.
• Low headline pricing that omits essential platform, plugin, hosting, maintenance, or renewal costs.
• A platform recommendation made before the provider understands editing, integration, ownership, and growth requirements.

One red flag is not always disqualifying; it may reveal a question that needs a written answer. Repeated vagueness is itself evidence about the future working relationship.

Run a final comparison meeting with evidence on screen

Open the brief, normalized scope table, live examples, scorecard, total-cost worksheet, and draft agreement together. Resolve each material difference in writing. If a candidate changes the scope verbally, request an updated proposal before deciding.

For a redesign, require the SEO migration checklist and assign post-launch ownership with the website maintenance checklist. If the business needs diagnosis before implementation, compare a website audit with a competitor report so the research purchase does not get confused with the build itself.

Zendory publishes fixed-price scope, delivery windows, page counts, revisions, hosting terms, and exclusions on its website build packages. That path fits a compact landing page, service website, or revenue flow with async onboarding. A portal, complex migration, regulated workflow, or custom backend should use a custom scope instead of being forced into a standard package.