Website Contract Checklist: 27 Clauses Every Business Should Review Before Signing

A bad website contract usually looks fine until the project gets uncomfortable.

The quote says “new website.” The kickoff call feels productive. Everybody agrees the site should be modern, fast, easy to update, and ready to bring in leads. Then the questions start. Who writes the service pages? Are redirects included? How many revisions do you get? Who owns the source files? What happens if the client takes three weeks to approve the homepage? Who fixes a broken form after launch?

If the contract doesn’t answer those questions, the project answers them the hard way.

This checklist is for business owners, freelancers, agencies, and marketing managers who want fewer surprises before signing a website agreement. It is not legal advice. Have an attorney review anything that matters financially. But if a contract is missing several of the clauses below, slow down before you send a deposit.

Quick Website Contract Review Scorecard

Use this first. If the contract is already signed, use it before the next change order or renewal.

A contract does not need to be hostile. It needs to be specific. Project management platforms warn that scope creep is uncontrolled growth in project requirements, and web projects are especially exposed because content, design, SEO, integrations, and stakeholder approvals all overlap. A good agreement gives both sides a clean process when the work changes.

1. Parties, contacts, and decision authority

Start with the boring part because it prevents expensive confusion.

The contract should identify the client, the web professional or agency, billing contacts, project contacts, and the person who can approve scope changes. If a committee can give feedback but only one person can approve, say that. If the owner has final say over brand and the marketing director has final say over page copy, say that too.

This matters because project tools like Monday describe unclear requirements as a major driver of scope creep, where ambiguity gets filled by new requests during execution (Monday). Decision authority is one of the cheapest ways to reduce that ambiguity.

2. Project objective

The agreement should say what the website is supposed to do. Not in fluffy brand language. In operational terms.

Examples: generate quote requests, support local SEO, replace an outdated brochure site, improve hiring applications, sell products, support paid ad campaigns, or make the site easier for internal staff to update.

This clause is useful when a stakeholder asks for a feature that sounds nice but does not support the job of the website. If the objective is lead generation, a project manager can push back on a late request for a custom animation that slows the service pages.

3. Deliverables

List what the client will actually receive. A clean deliverables section should cover page templates, page count, forms, navigation, CMS setup, blog templates, basic SEO fields, analytics setup, redirects, training, and launch support.

Do not rely on a single line that says “custom website.” Webflow’s contract guidance recommends covering services, payment, confidentiality, ownership, and responsibilities in writing (Webflow). Deliverables are where that advice becomes practical.

4. Explicit exclusions

Exclusions are not rude. They are protective.

If copywriting, brand strategy, logo design, photography, product data entry, video editing, ADA legal review, paid plugin licenses, CRM setup, hosting, email deliverability, or ongoing SEO are not included, the contract should say so.

This is especially important for small businesses because website cost ranges vary by what is included. Forbes breaks website cost into build cost, hosting, and ongoing maintenance, with small business informational sites often having separate design, hosting, app, and maintenance costs (Forbes Advisor). If the contract hides those categories, the budget is not really a budget.

5. Assumptions

Assumptions are the quiet part of scope. Put them in writing.

A proposal might assume the client will provide final copy, product photos, staff headshots, brand fonts, DNS access, hosting credentials, CRM access, and legal policy language. If those items arrive late, the timeline should move.

Good contracts say what the vendor is assuming and what changes if the assumption is wrong. For example: “Project pricing assumes up to 15 standard content pages. Additional pages are billed at the approved page template rate.”

6. Timeline and approval windows

A project schedule should include client responsibilities, not just agency milestones.

A useful timeline names kickoff, sitemap approval, design approval, content due dates, development review, QA, launch readiness, and launch. It should also state how long the client has to respond at each stage and what happens if feedback is late.

Without approval windows, the vendor eats idle time or the client gets surprised by a delayed launch. Neither is good. ProjectManager notes that scope creep can come from incomplete requirements and weak change control (ProjectManager). Approval windows are part of that control system.

7. Payment schedule

The payment clause should answer four questions: how much is due, when it is due, what triggers each payment, and what happens when payment is late.

Common structures include deposit plus launch payment, deposit plus milestone payments, or monthly billing for longer projects. For business owners, avoid paying the full amount before any work starts. For web professionals, avoid making final payment dependent on an undefined idea of “perfect.”

A better trigger is concrete: sitemap approved, design approved, staging site delivered, or site launched.

8. Change order process

Every serious website project needs a change process. Not because the client is difficult, but because better information appears during the project.

The contract should explain how new requests are submitted, priced, approved, and scheduled. It should also say whether work stops until the change is approved.

Asana defines scope creep as uncontrolled requirement growth (Asana). The word “uncontrolled” is the problem. A change order does not block change. It controls it.

9. Revision limits

A revision clause should define what counts as a round of revisions, how many rounds are included, and what happens after those rounds are used.

For example, a homepage design might include two consolidated revision rounds. That means the client collects internal feedback and sends one combined response, not five separate email threads from five stakeholders.

Unlimited revisions sound customer-friendly, but they often create slow projects and weaker decisions. A defined revision process keeps feedback focused.

10. Content responsibility

Website projects often stall because everybody assumes somebody else is writing the words.

The contract should name who writes copy, who edits copy, who approves copy, who uploads copy, and whether the vendor can rewrite supplied content for clarity or SEO. If AI-assisted drafting is allowed, say how it will be reviewed.

The same applies to images, video, PDFs, case studies, testimonials, team bios, location pages, and product descriptions.

11. SEO scope

“SEO included” is too vague to be useful.

Specify the SEO work. That may include keyword research, title tags, meta descriptions, heading structure, internal linking, schema markup, URL planning, redirect mapping, XML sitemap submission, Google Search Console setup, and post-launch crawl checks.

If the project is a redesign, redirects matter. Google tells site owners to use redirects when changing URLs so users and search engines are sent to the new location (Google Search Central). A redesign contract that changes URLs but does not mention redirects is leaving traffic at risk.

12. Accessibility expectations

Accessibility cannot be waved in at the end.

The agreement should state the target standard, testing approach, and limits of responsibility. WCAG 2.2 defines how to make web content more accessible to people with disabilities across visual, auditory, physical, speech, cognitive, language, learning, and neurological needs (W3C). If the project aims for WCAG 2.2 AA, write that. If legal compliance review is not included, write that too.

For clients, ask what accessibility testing is included. For vendors, avoid promising legal compliance unless a qualified legal review is part of the scope.

13. Privacy, cookies, and tracking

If the website collects form submissions, runs analytics, embeds ad pixels, uses chat tools, or offers newsletter signup, the contract should state who supplies privacy policy language and who approves tracking tools.

The vendor can install tools. The business usually owns the legal promises made to visitors. If a client sells to regulated industries, serves EU or California visitors, or collects sensitive information, privacy should not be treated as a footer task.

14. Security responsibilities

Security should be split into setup, access, maintenance, and incident response.

The contract should cover SSL, hosting responsibility, CMS updates, plugin updates, backups, admin access, password practices, and who responds if the site is hacked. The FTC says its Safeguards Rule requires covered companies to maintain safeguards that protect customer information (FTC). Not every local business falls under that rule, but the broader point is practical: if a site handles customer information, security responsibilities need names attached.

15. Hosting and infrastructure

The contract should say where the website will be hosted, who owns the hosting account, who pays for it, who can access it, and what happens if the relationship ends.

Client-owned hosting usually gives the business more control. Vendor-managed hosting can work well when the vendor provides real maintenance and support. The danger is vague hosting where the business does not know who owns the account, where backups live, or how to move the site later.

16. Third-party tools and licenses

Themes, plugins, fonts, stock photos, scheduling tools, form tools, CRM connectors, maps, and payment tools may have separate licenses.

The contract should list paid tools, renewal costs, ownership, and whether those licenses transfer to the client. This is where many “cheap” projects get expensive later. A site can launch on a developer license, then break or lose updates when the client relationship ends.

17. Intellectual property ownership

This clause deserves careful reading.

U.S. copyright law treats work made for hire in a specific way, and the U.S. Copyright Office explains that specially ordered or commissioned works must meet legal requirements to qualify (U.S. Copyright Office). LegalGPS also notes that if an agreement does not specify ownership, the creator may retain copyright while the client receives only an implied right to use the work (LegalGPS).

A web contract should separate final deliverables, pre-existing vendor tools, open-source code, stock assets, licensed software, custom code, copy, design files, and portfolio rights. “Client owns the website” is not enough.

18. Source files and admin access

A business may own the final website but not automatically receive every design file, component library, build script, private plugin, or internal project file.

If source files matter, name them. If the client gets Figma files, theme files, Git repository access, exported site files, CMS admin access, or only the published site, say that before signing.

This is not just a client issue. Agencies also need to protect reusable internal systems they bring to multiple projects.

19. Portfolio and attribution rights

Many web professionals want to show finished work in their portfolio. Many clients are fine with that. Some are not, especially if the project is confidential, regulated, or tied to a launch that has not been announced.

The contract should state whether the vendor can display the work, use screenshots, name the client, publish a case study, or place a footer credit on the site.

20. Client warranties

The client should warrant that it has the right to provide logos, photos, copy, product claims, testimonials, and customer data.

This protects the vendor from being blamed for publishing assets the client did not have permission to use. SignWell’s web design contract template includes client representations about rights to proprietary information, trademarks, logos, copyrights, images, data, and content supplied by the client (SignWell). That kind of language belongs in most website agreements.

21. Testimonials and endorsements

If the site uses reviews, testimonials, influencer quotes, affiliate claims, or before-and-after results, the contract should say who verifies them.

The FTC says material connections between endorsers and marketers should be disclosed when that connection would affect how people evaluate the endorsement (FTC). The FTC also provides business guidance on endorsements, influencers, and reviews (FTC). A designer can place testimonials on a page, but the business needs to stand behind the claims.

22. Testing and acceptance criteria

Testing should not be a mystery.

The contract should state what will be checked before launch: key browsers, mobile layouts, forms, links, analytics events, page speed basics, redirects, 404 page, sitemap, robots.txt, security certificate, backups, and content accuracy.

Acceptance criteria should be observable. “Looks professional” is subjective. “Contact form sends to sales@example.com and records a conversion event in GA4” is testable.

23. Launch plan

Launch is a production step, not a button.

A good launch clause covers DNS changes, launch timing, content freeze, backup, rollback plan, redirect testing, analytics checks, form testing, search engine indexing settings, and who is on call after launch.

For ecommerce, membership, booking, or lead generation sites, launch also needs transaction or form testing. A pretty site with a broken quote form is not done.

24. Warranty period

A website warranty should define what counts as a bug and how long fixes are included.

For example: “Vendor will fix defects reported within 30 days of launch where the delivered website does not function according to approved specifications.” That is different from new features, copy edits, plugin conflicts caused by later updates, or third-party outages.

A warranty is not the same as maintenance. Keep those separate.

25. Maintenance and support

After launch, somebody must update software, monitor forms, renew licenses, refresh content, review analytics, check backups, and respond to issues.

The contract should state whether maintenance is included, optional, or excluded. If included, specify response times, monthly hours, update frequency, exclusions, and emergency rates.

Network Solutions estimates small business website maintenance can run from $600 to $6,000 annually, depending on site type and needs (Network Solutions). That range is wide because maintenance can mean anything from basic updates to active support, content work, security monitoring, and conversion improvements.

26. Termination and pause rights

The contract should explain how either side can pause or terminate the project, what notice is required, what fees are owed, and what deliverables are handed over.

If the client disappears for 45 days, can the vendor pause the project and reschedule? If the vendor misses a critical milestone, can the client terminate? If the client terminates halfway through, does the client receive work completed to date after paying open invoices?

Clear termination terms keep a stalled project from becoming a hostage situation.

27. Handoff and exit plan

The best time to negotiate the exit is before anyone is unhappy.

A handoff clause should cover admin accounts, hosting access, domain access, CMS login, paid tool list, license renewal dates, backup copy, documentation, training recording, and any fees for migration support.

This protects both sides. The client can leave without losing the business website. The vendor can hand off cleanly without unpaid support dragging on for months.

Red Flags Before You Sign

Watch for these before sending a deposit:

• The contract promises “unlimited” work without defining time, scope, or revision limits.
• The vendor controls the domain, hosting, analytics, and CMS accounts with no exit language.
• The agreement says “SEO included” but does not mention redirects, metadata, page structure, or Search Console.
• Ownership language ignores third-party tools, stock assets, source files, and pre-existing code.
• The launch plan does not include form testing, backups, analytics, redirects, or rollback.
• The payment schedule requires too much upfront with too little detail about deliverables.
• Maintenance is implied but not priced, scoped, or assigned.

If you see one red flag, ask for clarification. If you see four or five, you probably do not have a contract yet. You have a sales document.

A Simple Clause Request You Can Send

If you are reviewing a proposal and want better terms without sounding combative, send this:

Before we sign, can you add a short section covering scope exclusions, change orders, ownership of final deliverables and source files, launch QA, warranty period, maintenance responsibilities, and handoff if we ever move the site? We want both sides to have a clear process before the project starts.

That request is reasonable. A professional vendor may adjust the wording, but they should not be offended by the topics.

Final Takeaway

A website contract is not there to make the project feel legal. It is there to make the project easier to finish.

The best agreements answer boring questions early: what is included, what is not included, who approves, who pays, who owns the work, who fixes problems, and how both sides leave cleanly if the relationship changes.

If you want a website partner who scopes the work clearly before taking your money, start a project conversation with Your Web Team. We will help you define the website, the budget, and the launch plan before anybody starts designing pixels.