If you search for a small-business website contract checklist, you are usually trying to avoid a specific failure: the finished site exists, but the form does not reach anyone, the domain is held by a former contractor, the “five pages” exclude the content you expected, or the launch keeps moving because nobody agreed on what done means.
The contract should turn those risks into named responsibilities and observable conditions. It should connect the work to the buyer path the site must support, record what the business supplies, and leave the business able to operate or change providers later. A contract is not a substitute for legal review, but an unclear brief cannot become clear through legal wording alone.
Start with the clauses that control the outcome
Before comparing fonts, platforms, or page counts, check that the agreement answers these questions:
| Contract question | Minimum useful answer | Why it matters |
|---|---|---|
| What is being built? | Named pages, templates, buyer paths, content, integrations, and exclusions | Prevents “complete website” from meaning different things to each party |
| Who does what? | Client inputs, provider responsibilities, approval windows, and dependencies | Makes delays and missing content visible before launch |
| How is it accepted? | Representative tests, defect process, review rounds, and a definition of completion | Replaces subjective approval with a usable handoff |
| Who controls it? | Domain, platform, content, code or export, analytics, forms, billing, and recovery | Protects continuity when staff, vendors, or platforms change |
| What continues after launch? | Hosting, subscriptions, support, maintenance, response boundaries, and prices | Shows the first-year operating commitment, not only the deposit |
| How can either side leave? | Termination, payment for completed work, export, transfer assistance, and access removal | Reduces the risk of being trapped by a provider or an unfinished project |
If one of these answers is “we will work that out later,” mark it as an open commercial risk. The redesign proposal comparison explains how to normalize scope before signing; this guide focuses on the agreement that makes the selected scope enforceable and operable.
Score the contract before you sign
Use this 100-point scorecard as a decision artifact. Give each row a score from 0 to 5, multiply by the weight, and write one piece of evidence beside the score. It is not a legal standard or a prediction of project success. Its purpose is to expose a dangerous blank before money, access, or deadlines make the blank costly.
| Dimension | Weight | 0 means | 5 means |
|---|---|---|---|
| Scope and buyer path | 20 | Only a vague page count or visual promise | Pages, actions, content, integrations, and exclusions are named |
| Responsibilities and approvals | 15 | Inputs, owners, and review windows are unclear | Each dependency, approver, deadline, and escalation is assigned |
| Acceptance and launch | 15 | “Client satisfaction” is the only completion test | Representative paths, devices, defects, launch, and rollback are defined |
| Ownership and portability | 20 | Provider holds accounts or rights without a transfer plan | Business control, licenses, exports, and transfer assistance are explicit |
| Security and data boundaries | 10 | Passwords, data, backups, and incident roles are absent | Access roles, MFA expectations, data handling, backups, and notification are documented |
| Commercial clarity | 10 | Price, revisions, renewals, or change orders are open-ended | Fees, schedule, taxes, limits, recurring costs, and approval rules are clear |
| Support and exit | 10 | No post-launch boundary or handoff path | Support window, maintenance, termination, export, and access removal are defined |
Calculate each row as (score ÷ 5) × weight. Treat a score below 3 in scope, acceptance, ownership, or security as a pause even when the total is high. A contract with beautiful deliverables and no account recovery path is not a complete contract.
- 0–49: return the agreement for clarification before approving a deposit.
- 50–74: proceed only after resolving every critical-row gap and documenting the assumptions.
- 75–89: the agreement is structurally usable, subject to business and legal review.
- 90–100: the terms are unusually clear, but still test the actual deliverables and provider fit.
Define scope as a set of buyer paths
“A responsive five-page website” describes a shape, not an outcome. Add a page-purpose map: which customer question each page answers, which proof supports it, and which next action it enables. A service business might need a home page, service pages, area or location context, proof, a quote form, confirmation state, and policy pages. A professional practice may need eligibility, booking, privacy, and referral information instead.
For each deliverable, mark one of five states: included, optional, client-supplied, excluded, or not yet decided. Apply the labels to:
- information architecture, navigation, page templates, and responsive states
- copywriting, editing, migration, photography, illustrations, and alt text
- forms, booking, payments, CRM or email routing, and confirmation messages
- titles, descriptions, canonicals, structured data, redirects, sitemap, and Search Console setup
- browser, device, accessibility, performance, analytics, and failure-state checks
- training, documentation, source or export files, backups, and post-launch support
Do not put important scope only in a sales email or a screenshot. Attach the final page map, feature list, content responsibilities, and assumptions to the agreement. The website package checklist helps identify the work a “full package” often leaves implicit.
Write the dependency chain for content and approvals
Many website delays are not design delays. The provider is waiting for service details, prices, photos, reviews, legal copy, access, or one person's approval. Record who supplies each input, its format, the due date, and what happens when it arrives late or changes after approval.
A useful approval clause distinguishes three states:
- Review: the client checks factual accuracy, brand fit, accessibility, and business risk.
- Approval: the client confirms the named version can move to build or launch.
- Change: a new request after approval is evaluated against the change-order rule.
Set a reasonable review window and name an escalation contact, but do not let “silence equals approval” quietly approve legal claims, prices, redirects, or a payment flow. If the business is responsible for facts or regulated wording, say so without pretending that responsibility transfers all implementation risk to the client.
Use the content-approval planning guide to create a practical inventory before the contract is finalized. A vendor cannot schedule a reliable launch around a content list that nobody owns.
Make acceptance a test, not a feeling
Define acceptance by the paths a buyer and the business must complete. The test record should include the URL or screen, device and browser, action, expected result, observed result, severity, owner, due date, and retest result.
| Path | Acceptance evidence | Typical failure to catch |
|---|---|---|
| Find and understand | Navigation, headings, service content, proof, mobile layout, and readable focus states | A polished homepage hides the actual service or next action |
| Contact or quote | Validation, spam handling, delivery, notification, confirmation, and fallback | The form submits but no one receives the request |
| Book or pay | Availability, required fields, handoff, receipt, cancellation or error state | Third-party flow works in the demo but fails from the production CTA |
| Search and migration | URL map, direct redirects, canonicals, robots, sitemap, internal links, and monitoring | Old pages disappear or new pages are accidentally noindexed |
| Operate and recover | Business login, delegated roles, billing, backup or export, and documented recovery | The site is live but only the builder can change or restore it |
W3C explains that WCAG conformance is evaluated against testable success criteria and that complete processes, including a checkout sequence, need to be considered together. Ask the provider to name the accessibility criteria and human or automated checks in scope; do not accept “accessible” as a test result without a method and boundary. The small-business accessibility checklist shows how to record a retestable issue.
Put accounts, files, and rights in the agreement
Separate account control from provider access. The business should be the registrant or account owner for the domain and should control the hosting or platform, analytics, Search Console, form destination, booking, payment, email, and recovery methods. Invite the provider as a named user or delegated role where the platform supports it. Record billing ownership and who can change recovery details.
ICANN's registrant information describes rights and responsibilities connected to domain registration. Use it as a prompt to verify the intended business entity, current contact details, renewal access, and transfer process. A contract cannot make an inaccessible personal account safe by describing it as “managed.”
List the files and rights that will be delivered:
- client-supplied logos, photographs, copy, testimonials, and data
- new copy, design files, code, configuration, exports, and documentation
- stock imagery, fonts, plugins, templates, APIs, and other third-party material
- licenses, geographic or term limits, attribution, renewal responsibility, and replacement obligations
- the date and format of the final export, plus the assistance included in a transfer
The U.S. Copyright Office's Circular 66 on websites and website content notes that an independent contractor may be the author and copyright owner of commissioned website work unless rights are acquired through a signed written agreement. That is a reason to clarify rights with legal counsel, not a reason to copy a generic “work made for hire” sentence and assume it solves every asset or jurisdiction issue.
Make migration and search preservation concrete
If an existing site has useful URLs, forms, search visibility, or links, migration belongs in the scope and acceptance schedule. Google Search Central recommends preparing a URL map, implementing direct permanent redirects, checking canonicals and robots rules, testing redirects, updating internal links and sitemaps, and monitoring old and new URLs. Its site-move documentation also warns that ranking fluctuations can occur while URLs are recrawled.
Ask the contract to name these artifacts:
- the current URL, page, form, analytics, and download inventory
- a keep, improve, merge, redirect, or retire decision for meaningful URLs
- a one-to-one redirect map that avoids irrelevant homepage redirects and chains
- pre-launch and post-launch checks for canonicals, noindex, robots, links, sitemaps, and structured data
- an owner and review window for post-launch errors, lead delivery, and indexing signals
Do not promise that a vendor can preserve rankings or traffic as a guaranteed outcome. Put the work and monitoring in writing, then measure what happens. The redesign migration checklist provides the companion inventory.
Set sensible security and data boundaries
A small-business website may touch names, email addresses, appointment details, payment events, or sensitive service context. The contract should say what data the provider can access, where it is processed, which subcontractors or third parties are involved, how access is granted and removed, and what happens if an incident is suspected. Do not place passwords in the contract. Use an approved password manager and named roles.
Ask who is responsible for updates, vulnerability reports, backups, restore testing, domain renewal, certificate renewal, and emergency contact. CISA's guidance for managed service providers and small businesses recommends practical controls such as continuously backing up critical data and system configurations. Adapt the control to the platform and risk rather than promising a backup regime the provider cannot operate.
For a regulated workflow, ecommerce operation, or custom application, ask qualified privacy, security, and legal specialists to review the data and liability terms. A brochure-site contract is not an adequate risk model for every business.
Compare the full commercial commitment
Separate the launch fee from the cost of getting the site to a stable first-year state. Record the payment schedule, taxes, deposit treatment, revision limits, rush work, change-order rate, third-party subscriptions, renewal increases, and support response. A recurring service should state what happens when a plan changes or a provider's relationship ends.
| Cost or term | Question to answer in writing |
|---|---|
| Project fee | What deliverables and review rounds are included, and when is each payment due? |
| Client effort | How many hours of content, approvals, data entry, access, and testing are assumed? |
| Change orders | What counts as new scope, who approves it, and how are price and schedule changed? |
| Third-party services | Who selects, pays, renews, and replaces hosting, forms, booking, payments, fonts, or plugins? |
| Support | What is covered after launch, for how long, through which channel, and with what response expectation? |
| Exit | What does the business receive, how quickly, and what transfer or export fees apply? |
The small-business website cost guide can help estimate overlooked content, platform, migration, and maintenance work. If the provider cannot explain the first-year operating picture, compare the proposal again before signing.
Worked example: choosing between two contract drafts
Imagine a home-services company buying a redesign with service pages, a quote form, analytics, redirect work, and managed hosting. This illustrative comparison is not a rating of any real provider.
| Dimension | Draft A | Draft B | Decision note |
|---|---|---|---|
| Scope and buyer path | “Up to 12 pages” | Page map, quote path, content responsibilities, and exclusions | B can be tested; A needs a scope attachment |
| Acceptance and launch | Client approval after preview | Form, mobile, redirect, analytics, accessibility, and launch checklist | A leaves failure states undefined |
| Ownership | Provider-managed domain and hosting | Business-owned accounts with delegated access and export | A is a critical pause until control is fixed |
| Recurring cost | “Hosting billed separately” | Named plan, billing owner, renewal term, and transfer rule | A cannot be compared on first-year cost |
| Exit | No transfer language | Final export and defined assistance after termination | B reduces lock-in risk |
Draft B may still be a poor fit if the team cannot supply content on time or the provider lacks the needed expertise. The point of the scorecard is to expose what the price does and does not buy. Require Draft A to answer the critical rows before considering its lower fee.
Pause for these contract red flags
- “Modern website” or “SEO included” with no page map, acceptance test, or named search work.
- Guaranteed rankings, leads, speed scores, or accessibility compliance without conditions and a test method.
- Provider-only ownership of the domain, billing, analytics, forms, booking, payment, or recovery account.
- Client responsibility for all content and approvals, but no list of required inputs or schedule impact.
- Unlimited revisions, pages, or support without a definition of completion or a response boundary.
- Third-party assets or plugins with no license, renewal, replacement, or transfer terms.
- Changed or deleted URLs with no inventory, redirect map, canonical plan, or post-launch monitoring.
- Termination language that allows access or files to be withheld after the business has paid for them.
A red flag is a question to resolve, not proof of bad intent. Ask for the answer in the agreement or an attached schedule so the project team can act on it later.
Use a six-step signing process
- Write the business decision. State the audience, offer, primary action, deadline, and evidence of success.
- Attach the scope. Include the page-purpose map, content inventory, integration list, exclusions, assumptions, and client inputs.
- Score the contract. Use the 100-point artifact and resolve every critical-row score below 3.
- Verify control. Confirm business-owned accounts, recovery contacts, files, rights, licenses, exports, and transfer assistance.
- Schedule acceptance. Name the tests, reviewers, defect process, launch checklist, and post-launch observation window.
- Get appropriate review. Ask a qualified lawyer, privacy adviser, security specialist, or accessibility professional to review the parts that match the project's risk.
If the project is not ready for this level of definition, reduce the first phase. A small paid discovery or fixed-scope audit can be safer than signing a broad build contract that both sides interpret differently. Zendory's free website audit, website build packages, and website examples are useful starting points for defining the job before a contract is drafted.
Primary sources for this contract checklist
These first-party references support the ownership, rights, migration, accessibility, and security checks above. They do not provide a universal contract or replace advice for the business, jurisdiction, industry, or platform involved.
- ICANN information for domain name registrants, for domain registration responsibilities, access, and transfer questions.
- U.S. Copyright Office Circular 66, Copyright Registration of Websites and Website Content, for authorship and rights questions involving contractors and website content.
- Google Search Central site-move documentation, for URL mapping, redirects, canonicals, robots rules, sitemaps, and monitoring.
- W3C Web Content Accessibility Guidelines 2.2, for testable accessibility criteria and complete-process conformance.
- CISA guidance for managed service providers and small and mid-sized businesses, for practical account, backup, and recovery risk questions.
The right website contract makes the future handoff boring: the pages are known, the buyer paths are tested, the accounts are recoverable, the costs are visible, and both sides know what happens when the scope changes. If those facts are not clear before signing, pause the purchase and make the decision smaller until they are.