A practical small-business
website checklist.

The 10-point small-business website checklist

A first release is ready when the business can answer each item with evidence, not only a visual preview.

1. Outcome: the right visitor can tell what the business offers, who it helps, and what to do next.
2. Content: services, service area, hours, contact details, limits, and required disclosures are accurate.
3. Pages: each page has a distinct visitor purpose instead of repeating the same copy for page count.
4. Proof: photographs, reviews, credentials, and work samples are real and used with permission.
5. Enquiry path: the quote, booking, call, or contact flow asks only useful questions and reaches the right person.
6. Ownership: the business controls the domain, primary email, billing, recovery methods, and finished assets.
7. Protection: forms and private features are enforced by a backend, secrets stay off the frontend, and abuse controls are tested.
8. Search foundation: titles, descriptions, headings, internal links, canonicals, structured data, robots.txt, and the sitemap match the real site.
9. Launch test: mobile layouts, links, forms, redirects, HTTPS, accessibility basics, and error pages are checked on the public domain.
10. Measurement: Search Console and any consented analytics measure useful actions, with an owner assigned to review and improve them.

1. Define the website’s job

Start with one sentence: “After visiting this website, the right customer should understand ___ and do ___.” A landscaper may want a homeowner to request an estimate. A retail store may want a visitor to confirm hours, directions, and product categories before visiting. A real-estate professional may want a buyer or seller to ask a local-market question.

This sentence keeps the first release focused. If the goal is a qualified enquiry, the site needs persuasive service information and a dependable enquiry path. It does not automatically need accounts, a dashboard, online payments, inventory synchronization, or a custom scheduling system.

2. Plan useful pages and gather real content

There is no correct page count for every small business. A page earns its place when it resolves a distinct customer need: a service with its own scope, a location with genuinely different information, a comparison a buyer must understand, or a question that would otherwise delay an enquiry. Do not publish near-duplicate service or town pages only to make the site look larger.

A useful first release often includes a focused home page, clear service information, an about or credibility page when it helps establish fit, a guided enquiry or contact path, and applicable privacy and legal pages. A business with several meaningfully different services may need more pages. A simple storefront may need fewer.

Build an owner-approved source pack

A designer can improve presentation, but the owner remains the source of truth. Gather accurate information before design begins so the project is not delayed by missing hours, unclear services, or photographs nobody has permission to use.

• Business name exactly as customers should see it
• Primary service area, storefront address, or an accurate statement that service is remote
• Public phone and email, plus the person or inbox that will answer enquiries
• Current hours, holiday handling, and the best time for customers to call
• A short list of core services or product categories with honest descriptions
• What makes the business a good fit and what it does not offer
• Original photographs, licensed images, logo files, and any required brand rules
• Required legal, licensing, brokerage, accessibility, or regulated-product disclosures

Choose one primary call to action

“Request an estimate,” “Ask about availability,” and “Schedule a consultation” create different expectations. Pick the action the business can reliably fulfill. A form should ask only for information needed to respond; every unnecessary field makes the visitor do more work.

Use proof carefully

Real photographs, licenses, public work samples, and permissioned testimonials can reduce uncertainty. Do not invent reviews, performance numbers, client results, or team size. If a project demonstrates capability but was not a paying client engagement, label it as work or a product—not a testimonial.

3. Design the enquiry around the customer’s objective

Do not default to the same name, email, phone, and open message box for every business. Match the next step to the service and the way the owner qualifies work.

• Use a clear action such as “Request an estimate,” “Check availability,” or “Start your project”
• Ask only the questions needed to route or answer the enquiry
• Use conditional steps when service type, location, timeline, or project scope changes what must be asked
• Collect contact details after the visitor understands the process and has begun the request
• Explain the expected response time and what happens after submission
• Show a confirmation screen with a useful next step and provide a reasonable phone, email, or booking fallback

A working form needs more than visual fields. The backend should validate submissions, limit abusive traffic, handle uploads safely when used, avoid logging sensitive content, and deliver the enquiry to a monitored destination. Send an authorized production test and verify receipt before launch.

4. Keep ownership clear and protect the implementation

The business should control its domain registration, primary email, billing relationship, and recovery methods. A developer can be granted limited access without becoming the permanent owner of the account.

• Register the domain in an account the business controls
• Turn on multi-factor authentication and save recovery codes securely
• Use role-based or limited access when the provider supports it
• Never send an account password by email, text, or a project form
• Document where the code, domain, DNS, form delivery, and backups live
• Write down what happens to hosting and support after the included term

For a Cloudflare-managed domain, a limited authorization flow or exact guided DNS changes can connect the site without transferring the domain or sharing the full account password. The safe method depends on the provider and the client’s existing setup.

Security must be enforced behind the page

The browser is not a trusted security boundary. Private features require backend authentication, authorization, ownership checks, input validation, rate limits, safe errors, and least-privilege access. API keys, database credentials, service-role keys, and signing secrets must stay on trusted server processes rather than in frontend code. The Ash security approach explains how those claims are scoped and verified instead of being added as a generic badge.

If the site has accounts or private records, test direct API requests, copied private URLs, changed record identifiers, logged-out reuse, expired sessions, and cross-user access. A login screen, database service, or security product does not replace these implementation checks.

Match privacy and cookie disclosures to reality

Collect only information the business needs. The privacy notice should identify the actual categories collected, purposes, recipients, retention approach, contact method, and choices that apply. If optional analytics or advertising technology is used, configure the appropriate consent behavior before loading it. A template that describes tools the site does not use is not a substitute for an implementation review.

5. Verify the public launch and search foundation

A page appearing on one laptop is not a launch test. Check the public domain, common screen sizes, the actual form-delivery path, and the way search engines are instructed to crawl the site.

• HTTPS works and HTTP redirects to the preferred HTTPS address
• Preferred domain versions redirect consistently
• Navigation, buttons, forms, email links, phone links, and external links work
• Every indexable page has a unique title, description, main heading, and canonical URL
• The sitemap lists the real public pages and is referenced in robots.txt
• Private, payment, success, and duplicate pages are excluded from search where appropriate
• Images have useful alternative text when they communicate content
• The contact form rejects obvious abuse and sends a real test notification
• The owner knows how and where incoming enquiries will arrive

After launch, add the domain to Google Search Console, verify ownership, submit the sitemap, and inspect important pages. Search visibility is not immediate: crawling, indexing, and ranking are separate steps, and no technical checklist guarantees a first-page position. If the business serves customers in person, review how a Google Business Profile and the official website work together without treating either one as a ranking guarantee.

Internal links should help visitors and crawlers reach important pages. Structured data should describe the real business and page content, not create facts that are missing from the visible page. New pages should answer distinct demand with original information rather than repeat a template with different keywords.

6. Measure useful actions and improve the site

Google Analytics can show visits, page paths, and configured events. Google Search Console shows how Google crawls the site and, after data accumulates, which searches and pages produce impressions and clicks. Neither tool creates rankings merely by being installed.

For a lead-generation site, the most useful early measurements are usually successful enquiry submissions, clicks to call or email, and the pages people visit before contacting the business. Avoid collecting more personal information than the business needs, disclose enabled analytics, and obtain consent where applicable.

Review the evidence on a regular schedule. Search impressions without clicks may point to weak search alignment. Visits without enquiries may point to unclear fit, missing proof, an awkward next step, or a broken form. Treat those as investigation prompts, then change one meaningful thing and compare the result rather than publishing more pages blindly.

7. Ask these questions before paying

• Exactly which pages and features are included?
• Who supplies and approves the words, images, and legal disclosures?
• Is a working contact or quote backend included, or only a visual form?
• Who owns the domain, source code, accounts, and finished files?
• What outside subscriptions or transaction fees are not included?
• How many revision rounds are included, and what counts as a new feature?
• What technical SEO work is included, and is ongoing content or link work separate?
• How will forms, redirects, HTTPS, mobile layouts, and indexing instructions be tested?
• What happens to the site when the hosting or maintenance term ends?

A clear written answer to these questions matters more than a long feature list. It gives both sides a shared definition of finished.

Common questions

Technical references

For implementation details, review Google Search Central’s SEO Starter Guide, Google’s Search Console guidance, Google’s consent implementation guidance, and the OWASP Cheat Sheet Series. Product rules and security guidance change, so recheck the current sources during implementation.