What Should a Small Business Website Package Include?

A three-page package can be complete for a focused service business. A ten-page package can still be incomplete if the quote form goes nowhere, the owner cannot access the domain, customer proof has not been approved, or nobody is responsible for measuring the result.

That is why “How many pages are included?” is only the beginning of a useful buying conversation. A website package is a set of decisions, deliverables, tests, rights, and operating responsibilities. The scope should tell you what will be built, what you must supply, how both sides will know it works, and what happens after it becomes public.

This guide focuses on package completeness. Use the small-business website cost guide to set a realistic budget, the web designer scorecard to evaluate providers, and this checklist to compare the work each proposal actually buys.

Start with the customer outcome, not the feature count

Write one sentence that describes the job of the website. For example: “Help homeowners in the service area understand the repair options, trust the company, and request an appointment that reaches the dispatcher.” Every included page, feature, integration, and measurement should support that job.

A complete package should identify four things before it lists design features:

1. Audience: who the primary visitor is and which requests are outside the scope.
2. Offer: the service, product, appointment, quote, or information the site presents.
3. Action: the call, form, booking, checkout, visit, or other next step that matters.
4. Operational handoff: where that action goes, who responds, and what the visitor should expect.

This outcome statement protects the project from two opposite mistakes. The first is buying pages with no clear role. The second is cutting a necessary step because it was not named as a “page.” A confirmation message, mobile call control, booking handoff, error state, or staff notification can matter more to revenue than another navigation item.

If one offer and one audience can be explained completely on a single page, compare a focused landing-page package with a broader site using the landing page versus website decision guide. Do not buy a page count before deciding how many distinct customer decisions need their own space.

Use a twelve-part package checklist

Ask every provider to mark each area as included, client-supplied, optional, or excluded. “Included” should point to a specific output or test rather than a reassuring adjective.

Not every business needs the largest version of each area. A brochure site may not need checkout. A one-location service business may not need a complex content system. The point is to make each decision explicit so that “basic website” does not hide a different assumption for the buyer and the provider.

Define pages by purpose and template

A page allowance should name the pages, their jobs, and what makes a new page billable. Ask whether “five pages” means five custom layouts, five URLs assembled from one design system, or five entries in a template. Those can all be reasonable products, but they are not the same work.

For a compact service-business package, a practical page map might include:

• a homepage that states the main offer, audience, proof, service area, and next step
• one or more service pages that explain meaningful differences in buyer intent
• an about or proof page that establishes people, process, credentials, and evidence
• a service-area, contact, or location page with accurate operational details
• a privacy page and any other policies required by the real data and business workflow

Also define the reusable parts: header, footer, announcement area, calls to action, cards, FAQs, forms, testimonials, and location details. Reusable components reduce inconsistent edits later. Ask whether adding a new service after launch means filling an existing template, commissioning a new layout, or changing the site architecture.

The small-business website page-planning guide gives a fuller method for deciding when a topic deserves a separate URL. A package should not generate thin service or city variants merely to reach a promised count.

Separate custom design from brand application

“Custom design” can describe very different processes. Ask which of these is included:

• original information architecture and visual direction for the business
• application of an existing brand system to a proven page framework
• adaptation of a commercial theme or template
• custom illustration, photography, video, animation, or icon work
• desktop, tablet, and mobile behavior for key sections and controls

Template use is not automatically a defect. A well-chosen system can make a small site faster, more consistent, and easier to maintain. The risk is paying a custom price for lightly edited stock structure or assuming that a static mockup includes the behavior needed in production.

Ask to review the implemented site on narrow and wide screens, not only polished desktop images. Navigation, long business names, buttons, tables, forms, error messages, embedded booking tools, and proof sections all need real responsive behavior.

Turn “content included” into a responsibility map

Content scope should distinguish discovery, source collection, research, interviewing, writing, editing, fact-checking, asset preparation, page entry, legal or specialist review, and final approval. A provider can own some or all of those tasks, but the business remains the source of truth for prices, hours, qualifications, service boundaries, claims, customer permissions, and operating promises.

For each page, name:

• who supplies the raw facts and customer evidence
• who writes the first draft and how many editorial rounds are included
• who obtains photo, logo, font, testimonial, and case-study rights
• who verifies claims, prices, credentials, policies, and regulated language
• who enters the content and checks it in the actual interface
• who has final approval authority and how approval is recorded

The FTC's Consumer Reviews and Testimonials Rule Q&A explains that a business displaying testimonials on its own site is disseminating promotional messages, not merely hosting reviews. That makes source, truthfulness, attribution, and relationship disclosures substantive project inputs rather than decoration to add at the end.

Use the website content preparation guide to assemble the business facts, offer details, proof, assets, form requirements, and approvals a builder needs. If a proposal says “copy included,” compare it against that input list.

Scope the complete conversion path

A package that includes a contact form should include more than visible fields. Define the destination, notification, storage, confirmation, privacy context, spam protection, error handling, and test evidence. A useful acceptance test follows a realistic customer from page entry through a successful business handoff.

For each conversion path, document:

1. the action and the minimum information the customer must provide
2. field labels, requirements, validation, consent, and accessible error messages
3. the system and owner that receive the submission
4. the customer-facing confirmation and promised response time
5. the fallback when email, booking, payment, or another integration fails
6. the analytics event that confirms the action without collecting unnecessary sensitive data
7. the person responsible for monitoring and responding after launch

Booking, quoting, qualification, payment, subscriptions, and account creation add operational complexity. Confirm whether third-party setup, taxes, products, prices, transactional email, webhooks, refunds, cancellations, and staff training are included. Zendory separates its fixed-price website build packages by the kind of revenue flow included, which is a more meaningful boundary than adding pages around an unfinished form.

Ask what “basic SEO” produces

SEO should be translated into named work. At a minimum, a public site needs pages that can be accessed, understood, and linked. Google's current Search Essentials identifies technical requirements, spam policies, and key practices such as people-first content, descriptive words in prominent locations, and crawlable links. The documentation also makes clear that meeting requirements does not guarantee crawling, indexing, or ranking.

For a new small-business website, define whether the package includes:

• search-intent and competitor review before the page map is approved
• unique titles, descriptions, headings, page copy, and descriptive internal links
• canonical URLs, index controls, robots rules, and XML sitemaps
• structured data that matches visible, verified business information
• redirects from replaced URLs and preservation of valuable existing content
• Google Search Console and analytics ownership, verification, and baseline reporting
• accurate local identity, service-area, contact, and Business Profile coordination

Google's LocalBusiness structured-data documentation says markup must represent the page's visible content and describes business properties such as name, address, hours, telephone, and URL. Ask who verifies those facts and who corrects conflicts. “Schema included” is not valuable if it encodes information the business does not show or support.

For a redesign, the package should also inventory existing URLs, search traffic, links, canonicals, and redirects. Use the website redesign SEO migration checklist to compare that work against a provider's migration scope.

Define an accessibility target and testing method

“Accessibility included” is too vague to accept. The Web Content Accessibility Guidelines 2.2 is a W3C Recommendation with testable, technology-neutral criteria covering perceivable, operable, understandable, and robust content. A package should identify the target level, the pages and components in scope, the review methods, and how findings are resolved.

Ask whether the work covers semantic headings, landmarks, keyboard navigation, visible focus, contrast, zoom and reflow, meaningful link text, images and alternatives, form labels, instructions, errors, media alternatives, motion, third-party widgets, and authentication where applicable. Automated scanning can help find some defects, but it is not a complete acceptance method.

Request a short accessibility record at handoff: target, tested routes and components, tools and manual checks used, known limitations, third-party exceptions, unresolved findings, and the person responsible for future content. The small-business website accessibility checklist provides a practical buyer-side test plan. Legal obligations vary, so obtain qualified advice for a particular business or jurisdiction rather than treating a package label as legal assurance.

Include production performance and security responsibilities

A website package should name the production environment, not only the design tool or content platform. Define who is responsible for HTTPS, software and dependency updates, account permissions, backups, recovery, form abuse, security notifications, and third-party service changes.

For performance, ask which representative pages and devices are tested, what image and font work is included, how third-party scripts are controlled, and what happens if an embedded tool dominates loading time. Avoid a promise based only on one test score. Record the test conditions and fix material problems that affect the intended customer journey.

If the package uses a managed platform, ask which maintenance duties the platform handles and which remain with the provider or owner. If plugins or extensions are involved, identify the license owner, renewal cost, update process, compatibility responsibility, and response when a vendor abandons the product.

Make ownership and portability explicit

The business should know who controls the domain, DNS, hosting, content system, source repository or export, analytics, search tools, email service, forms, booking, payment accounts, fonts, stock assets, plugins, and licenses. Ownership does not require the owner to operate every account daily. It means the agreement makes authority, access, billing, and transfer clear.

ICANN's information for domain registrants explains that the registrant enters a contract with a registrar and manages the domain through that registrar. Confirm the business is the intended registrant, the contact information is accurate, and the owner can access renewal, transfer, and recovery processes.

Create an account register with:

• service and purpose
• account owner and administrator
• billing owner, renewal amount, and renewal date
• recovery email and multifactor-authentication method
• data, content, or code export method
• transfer steps and any practical lock-in

Ask the provider to state which design files, code, content, and assets are assigned or licensed to the business after payment, and which underlying tools remain the provider's property. If hosting is bundled, define what happens to the website and domain when hosting ends.

Connect analytics to decisions

Analytics setup should start with a small measurement plan, not a promise to “install tracking.” Name the actions that matter: calls, qualified form submissions, bookings, quotes, checkouts, purchases, or another outcome. Identify the account owner, property, events, consent requirements, exclusions, test procedure, and reporting responsibility.

Capture a launch baseline such as organic clicks, qualified inquiries, booking completions, response time, or conversion rate where reliable data exists. Page views alone cannot tell the owner whether the revenue path works. If calls matter, decide how they are attributed and how customer privacy is protected. If the business cannot support a complex measurement stack, choose a smaller set of reliable events.

Require a launch and handoff checklist

Launch is a production change with business consequences. A package should assign an owner and a rollback or recovery path. Depending on the project, the checklist should cover:

• approved final content, prices, policies, and contact details
• domain and DNS access, HTTPS, canonical host, and redirect behavior
• forms, booking, checkout, notifications, confirmation, and failure states
• mobile and desktop review across representative browsers
• accessibility, crawlability, index controls, sitemaps, and structured data
• analytics and search-tool verification
• backup or known-good release and recovery instructions
• administrator access, documentation, training, and third-party renewals
• support window, defect definition, response method, and escalation contact

The website is not handed off when the homepage looks correct on the provider's laptop. It is handed off when the agreed production path works, the owner has the necessary access and documentation, and unresolved limitations are recorded.

Define revisions, changes, defects, and delays

A revision changes an agreed draft within the approved direction. A change request adds scope or reverses an approved decision. A defect fails the agreed requirement. The package should distinguish those categories because treating them as one vague pool creates conflict.

Ask what counts as a feedback round, how feedback must be consolidated, how long each side has to respond, and what happens when owner-supplied content or access is late. A clear agreement might include two consolidated page-review rounds while treating a new service, new integration, or different brand direction as separately priced work.

Also ask which corrections are covered after launch and for how long. A warranty might cover defects in the delivered scope but exclude new browser behavior, owner edits, third-party outages, new regulations, or newly requested features. Ongoing care is a different product and should have its own duties, price, and cancellation terms.

Score packages by completeness and fit

Use a weighted score instead of counting features. Give the most weight to the parts that determine whether the business receives a working customer path and can continue operating it.

Adjust the weights for the business. A regulated intake flow should place more weight on accessibility, privacy, security, and specialist review. A campaign landing page may place more weight on speed, copy, measurement, and one integration. Write why each score was given so a confident sales presentation does not replace evidence.

Example package comparison for a local service company

Suppose a plumbing company compares two proposals. Proposal A includes ten pages, a premium theme, stock images, “basic SEO,” and six months of hosting. Proposal B includes five purpose-defined pages, original copy based on an owner interview, approved job photos and reviews, a mobile call path, an emergency-request form routed to dispatch, local facts, redirects from the old site, accessibility checks, analytics events, launch testing, and owner-controlled domain access.

Proposal A has more pages. Proposal B has a more complete operating path. If the five pages cover the real services and buyer decisions, Proposal B is probably the stronger package even before price is considered.

Now suppose the company also wants online deposits, technician scheduling, service-area eligibility, CRM synchronization, and customer accounts. Neither compact package may be appropriate. The right answer is a separate systems scope through a provider's custom systems path, not a vague promise to “add integrations” inside a basic website price.

Watch for package red flags

• a long feature list with no audience, offer, action, or acceptance criteria
• “unlimited revisions” with no process, schedule, or definition of a change
• SEO, accessibility, security, or compliance claims with no named work or evidence
• provider-controlled domain, analytics, payment, or business-profile accounts with no transfer terms
• testimonials, images, fonts, or copy with unclear sources and usage rights
• a launch fee that excludes forms, redirects, analytics, or production checks the buyer assumed were included
• low initial pricing that hides required plugins, platform plans, licenses, hosting, maintenance, or renewal increases
• no process for backups, recovery, defects, third-party outages, or ending the relationship

A proposal does not need to be long to be clear. A concise scope can still name the pages, responsibilities, tests, account ownership, timing, limits, price, and handoff. Ambiguity is the problem, not brevity.

Choose the smallest complete package

First define the customer journey and the operational handoff. Then compare page and template scope, content ownership, conversion behavior, search foundations, accessibility, production quality, analytics, account control, launch, support, and total cost. Require evidence for the areas that matter most.

A good package can be modest. It does not need every marketing feature. It needs every essential link between a buyer's question and the business's response, plus a clear way to operate, measure, maintain, and transfer the site.

If that scope matches a fixed-price local-business build, compare Zendory's landing page, service website, and revenue website packages. Each path states the page allowance, revenue action, revision limit, delivery window, hosting term, and important exclusions before checkout.