Clauses Every Website Contract Should Include

Almost none of the disputes in website projects come from bad intent. Most come from two parties reading the same sentence differently. To the client, a corporate site means seven pages and a blog; to the agency, five pages. The client says revisions and means unlimited changes; the agency means two rounds. The contract's job is to make these gaps visible before the project starts.

The clauses below are not a substitute for legal advice. For large or unusual projects, we recommend having a lawyer review the text. But if the following isn't in writing, the contract remains incomplete no matter how long it is.

Scope: the most important clause

Scope defines what your money buys. Vague scope causes arguments at every stage.

A good scope clause states, with numbers and names: the number and names of pages, number of languages, number of forms and where they send data, integrations (payment, shipping, booking, CRM), whether there is an admin panel and what it lets you edit, and who prepares text and images.

That last point is often skipped. Will you provide the content, or will the agency write it? If the agency writes it, how many pages and how many words? Who holds the stock image licences? If this isn't written, content delays push back the delivery date and nobody knows who is responsible.

Listing what is outside the scope helps too. A single sentence like social media management is not included prevents a later misunderstanding. Our article on reading a website quote can help you check how scope is phrased.

Revisions and extra work

A revision is a correction within the approved scope. A new page or a new feature is not a revision; it is extra work. The contract should draw that line clearly.

A common approach is two or three revision rounds at the design stage. The idea of a round matters: changes are sent together in one batch. Do corrections sent one by one each day count as separate rounds? Write it down from the start.

How extra work is priced should be clear too. An hourly rate, or a quote per job? A sentence like no extra work starts without written approval prevents surprise invoices.

Delivery and acceptance

When is the site considered delivered? If the answer isn't written, the final payment stays in limbo.

Acceptance criteria should be measurable. For example: all pages in scope are live at the final address, forms are tested and emails reach the specified address, the site displays correctly in current Chrome, Safari and Firefox and on mobile, SSL is installed.

An acceptance period is defined as well. The agency announces delivery, and the client reports issues in writing within a set time (say 7 or 10 business days). A structure often seen in contracts is that delivery is deemed accepted if there is no response within that time. A clause like this keeps the project from staying open for months; work out the wording with your lawyer.

Deadlines should also be tied to the client's obligations. Something like if content and images arrive late, the delivery date moves by the same amount is fair.

Source code, domain and account handover

This section matters most years after the project. Whether you can move your site to someone else when you part ways with the agency or freelancer depends on these clauses.

The contract should state:

• Whose name the domain is registered in (preferably the client's).
• That hosting, email, analytics and Search Console accounts are opened in the client's name or in a way the client can access.
• Which passwords and admin access are handed to the client at delivery.
• Whether source code and design files are delivered, and the scope of the client's right to use that code.

The last point has nuance. Some agencies build sites on their own platform and transfer the right to use the site, not the platform itself. In a ready-made model, reusing a design template across projects is normal. None of this is a problem as long as what is transferred is written down clearly. The problem is when nothing is written. We discussed who should own what in our article on website ownership.

Don't forget third-party licences. If a paid theme, plugin or font is used, the contract should say whose name the licence is in and who pays for renewal.

Maintenance, bug fixes and support

Who is responsible for bugs found after delivery? A good contract splits this in two.

The bug-fix period is when the agency fixes errors in its own work for free. 30, 60 or 90 days are commonly seen. The scope should be explicit: a broken form is covered; restoring a page the client deleted from the panel may not be.

Maintenance is a separate service: regular backups, updates, security checks, small content changes. It may be paid or included for the first year. What matters is that what it covers and how quickly you get a response are in writing. Concrete times, such as a response within 4 hours if the site is down and within 2 business days for small changes, are worth far more than a vague promise of fast support.

Payment plan

Payment should follow progress. A frequently seen structure:

• A deposit on signing (for example 30 to 50 percent)
• An interim payment at design approval (if any)
• The remainder on delivery and acceptance

Paying everything upfront or everything at the end leaves one side unprotected. The contract should also state whether prices include VAT, whether they are in lira or a foreign currency, and what happens if payment is late.

Think about cancellation as well. How is the work done so far valued, and is the deposit refundable? The clause you hope never to use is the one that helps most when you need it.

When the draft contract arrives, write these headings on a sheet and tick them off one by one. If anything is missing, ask for it to be added before signing.

This article is for general information only and is not a substitute for legal, financial or tax advice. For your own situation, consult a lawyer or a certified accountant.