Warranty on a website build - what it covers and how long it should last

A warranty is worth exactly as much as the line that says what counts as a defect and what counts as a new feature. It always breaks down at the same moment: six weeks after launch the client writes that “something is not working”, the developer answers that this is a change of scope, and on paper both of them are right, because nobody ever drew that line. A warranty on a website build is not a promise that the site will keep running forever, and it is not free care after launch. It is an undertaking to fix faults in the developer’s own work that surfaced after handover. Everything else in that conversation is an argument about what qualifies as a fault.

I write this from the developer’s side of the table, since building company sites and stores is what I do for a living. One thing up front: this is not legal advice. I am talking about what can realistically be reported, defended and fixed without a second invoice. The legal effect of specific clauses, including how a granted warranty sits next to the statutory liability for defects, is for a lawyer to confirm before you sign. This piece is about the period after handover; what belongs in the document itself I covered in the piece on the website build contract.

What a warranty on a website build covers

The scope comes down to one sentence: it covers what the developer got wrong or left unfinished, and what only showed up in real use. Examples I have fixed after other people, which fall inside a warranty with no discussion:

• Redirects from the old addresses after a rebuild that nobody verified - the old price list and the three strongest pages return 404, and the search positions go with them.
• A form that reaches the client but not the company inbox, or drops the attachment, because the mail server rejects a message sent without domain authentication.
• Caching set up with no exceptions for the cart and the customer account - a logged-in user sees somebody else’s price or an empty order.
• A newsletter integration that accepts the signup and does nothing with it, because the API key came from a test account.
• Structured data and language versions wired up wrong, so search engines index one version instead of two.

The common thread: none of these are new ideas. They are things that were meant to work on the day of handover and did not, and nobody clicked them at the time. Outside the warranty sits everything that changes the scope: a new page, a different homepage layout, replacing copy and photos, adding instalment payments, wiring in a wholesaler feed. Outside it too sit the consequences of other people’s decisions: a plugin installed by the client, a move to a different host, an expired certificate, an outage on a server the developer does not run.

A decent contract names both of those buckets. A bad one only says that “the contractor grants a warranty on the work performed”, and from then on every report starts with a negotiation rather than a fix.

How long a warranty should last - and when the clock starts

The most common question gets the least useful answer: “the standard is X months.” There is no standard, and the length on its own means nothing without two other things - when it starts, and what has to fit inside it.

When it starts. The clock runs from handover, meaning the day the client confirmed they got what they ordered, not from the moment files landed on the server and not from the first commit. That has a practical consequence: if sign-off waits three weeks on a decision at the client’s end, the warranty is not quietly burning through that time.

What has to fit inside it. Instead of asking how many months, work out what the site has to survive first. A sensible window covers at least:

• one full round of updates to WordPress, the theme and the plugins - most faults in the build surface not on launch day but at the first update that touches custom code;
• one real business cycle - a month end with invoicing, a season, a campaign, a newsletter sent to the full list;
• traffic from real devices rather than from testing - some bugs only appear once a few hundred people arrive on a dozen browser versions.

A window set that way is derived from the risk in the project rather than from a table. On a small brochure site all three conditions are met quickly. On a store wired into a warehouse system, or a B2B panel, they are met much later, which makes a short warranty there largely decorative.

The second element almost nobody writes down: a deadline for the developer to act on a warranty report. An obligation with no deadline is one you can keep fulfilling indefinitely. A single line about how fast a report is acknowledged, and how fast a fault that blocks sales gets fixed, is worth more than an extra quarter on the period.

Finally, the thing clients ask about most: statutory liability. A site made to order is covered by law whether or not the developer “granted” anything - that liability comes from the statute and is what remains when the contract is silent, while a warranty is a voluntary undertaking on top of it. In practice that means the absence of the word “warranty” in your document does not release the developer from answering for defects. The scope and the time limits of that statutory liability are a question for a lawyer, not for a programmer.

What voids a warranty

Four situations in which a developer is entitled to say “that is not a warranty case” - and usually is right:

1. Somebody else went into the code. An edit in the theme, a plugin from a friend in IT, a snippet pasted from a forum. Nobody can answer for a file they did not write. It does not mean you lose the warranty on everything - you lose it on what was touched, which is exactly why such changes are worth declaring rather than hiding.
2. The environment changed. A move to another host, a different PHP version, a module the site depends on switched off. A website is a program and it runs in a specific setting.
3. A report nobody can reproduce. “It was broken yesterday” is not a report. The page address, the time, the device, the browser and a screenshot turn an argument into a fix.
4. An unpaid final invoice. In most contracts the assignment of rights and the warranty are both tied to payment in full. With the last payment on hold, the developer is under no obligation to repair anything.

There is one more quiet killer on top of that list: automatic plugin updates left unattended. An update lands overnight, something drifts out of place, nobody notices for two weeks, and afterwards it is genuinely hard to tell a fault in the build from the result of somebody else’s change.

Warranty and ongoing care are not the same thing

This distinction is the heart of the subject, because it is where most post-launch conversations come apart. A warranty looks backwards: it repairs what was done badly. Care looks forwards: it watches the site against things that have not happened yet.

The practical conclusion is that a warranty does not stand in for care for a single day. A site with no backups and no updates is not protected by the fact that its developer answers for their own faults, because the first vulnerability in a popular plugin is not a fault in the build. What belongs in an agreement for that routine work I set out in the piece on the website maintenance contract.

The developer vanished after handover - what to do

The worst case is not a developer refusing to fix something. It is a developer who stops replying. The warranty formally still exists, there is simply nobody to enforce it against, and pursuing a claim against a one-person company often costs more than the repair itself.

The order I recommend when somebody comes to me in that position:

1. Secure the credentials while they still work. The WordPress admin account, the hosting panel, the database, the domain registrar, the accounts in third-party services. Any access you do not hold today may tomorrow require a conversation with somebody who is not picking up.
2. Take a full copy of the files and the database and pull it down to your own machine, not just to the server. It is the one thing that cannot be recovered later.
3. Move the domain and the hosting into your own name. A domain registered to the developer is the most expensive kind of convenience - once they go quiet, getting it back can take months.
4. Check the licences on paid plugins. A licence bought on the developer’s account stops receiving updates, which after a few months turns it into a security hole. It has to be repurchased under your own account.
5. Write the list of faults down, even with nobody to send it to. A new developer quotes from it, and if the matter goes further, it is evidence.

Then comes the real question: repair or rebuild. A code review answers it. A site built on standard components with a sane theme can often be taken over in a few hours, while a site glued together from twenty plugins and edits pasted straight into theme files costs more to keep alive than a new one does to build. That is the first step whenever I take over or rebuild an existing company site: I look at what is actually on the server and say plainly whether it is worth saving. How to pick someone this does not happen with again I covered in the piece on who can build my website.

How I handle it

I work fixed-bid, so I answer for what I quoted, and the warranty is a natural part of that rather than a paid extra. The scope is the one described above: faults in my build get fixed with no invoice, while new features, content changes, other people’s plugins and hosting outages are handled separately. The length and the response deadline I set per project and write into the contract along with the scope, because a store full of integrations carries different risk than a five-page brochure site.

Separate from the build warranty runs what I call the peace-of-mind guarantee, attached to my ongoing support packages: if a store goes down through my fault and I do not have it back up within four hours, you do not pay for that month of care. That is no longer a warranty on workmanship but a promise about response time - and it illustrates the distinction from the previous section rather well.

Have a site from another developer and no idea whether what you are looking at is a fault in the build or a change of scope? Send me the address and a short description, and I will tell you what can still be claimed under the warranty.

Frequently asked questions

Does a website warranty cover hosting and the domain? Not unless the developer sells them to you. A server outage, an exhausted resource limit or an unpaid domain are not faults in the build. The developer answers for the code and the configuration they put in place.

What if the contract says nothing about a warranty? You are not left with nothing - liability for defects in commissioned work follows from the law whether or not the contract mentions it. Enforcement is the harder part, because you have to show the defect existed at handover. That is a question for a lawyer; your job is to keep the correspondence with what was agreed and a dated list of faults.

Does changing the content void the warranty? Typing text and uploading photos does not. What loses cover is whatever was changed in the code or the configuration, and only that. If something broke after your change, say plainly what you did; with that information the fix takes minutes, without it half a day.

Need something like this on your side? I design and build websites for B2B companies - from scratch or as a rebuild of what already stands. Let’s talk about your project.