How to Keep an AI-Built Site Maintainable

The short version

Most advice about maintainable code is written for teams of engineers who will read it. Your situation is different. You are the only person who touches this site, you cannot read most of it, and your repair tool is a conversation with a model that has no memory of last month. That changes which habits matter. Clever abstractions do not help you. Being able to find the one place a thing lives does.

So the useful question is not how clean the code is. It is how long it takes you to make a small change without breaking something. If updating a price takes ten minutes of searching, the site is already in trouble, no matter how tidy each individual file looks.

Everything below is about that one number: the cost of a small change, six months from now, on a site you did not write and will not remember.

How an AI-built site actually decays

The decay has a shape, and it is well documented. GitClear analyzed 623 million code changes from 2023 to 2026 and found that commits containing a duplicated block of five or more lines rose 81% over 2023 levels, the highest on record, while refactoring, meaning code moved rather than added, fell about 70% over the same period. Reporting on the same study, LeadDev quotes GitClear's Bill Harding describing the end state: five different implementations of the same thing that are similar yet different.

That research is about engineering teams, and a five-page business site is a much smaller problem. The mechanism is identical though, and it is worth understanding because it explains why your site will feel fine for two months and awkward in the third.

A model answers the request in front of it. Ask for a pricing page and you get a complete pricing page, header and footer included, written fresh. It has no way to know you already have a header, and no incentive to reuse yours even if it did, because writing a new one is more reliable than depending on something it cannot see. Every page you add this way is self-sufficient and slightly different from its siblings.

Duplication is not a sin by itself. The cost is what GitClear calls a propagation tax: change one copy and you have quietly taken on the job of finding every other copy. Two copies you will remember. Six you will not. The first symptom is usually cosmetic drift, where the nav on one page has slightly different spacing. The second symptom is worse, because an old phone number or a dead link survives on a page you forgot existed.

Decide where things live before page three

Decide this before page three, because retrofitting it is the part nobody does. The structure that works for a small site is boring and has not changed in twenty years.

One folder at the root. index.html for the home page, then a folder per page with an index.html inside it, so /pricing/index.html serves at yoursite.com/pricing. One style.css that every page links to. One /images/ folder. If you have scripts, one main.js. That is the whole layout, and it will hold a thirty page site without strain.

One rule matters more than the rest, and it is the shared stylesheet. A self-contained single file page is a fine way to start, and it is what most models hand you by default. It stops being fine at page four, because now your colors and spacing exist in four separate copies and changing the accent color is four edits with four chances to miss one. Moving to one external stylesheet is a ten minute job while you have three pages and an afternoon once you have twelve.

Header and footer are the harder case, because plain HTML has no built-in way to include a shared chunk. You have three honest options. Keep the page count low enough that copying by hand is tolerable, which is the right answer for most small business sites. Accept the copies but keep a note in your project listing every file that contains the nav, so updating it is a checklist rather than a search. Or use a static site generator, which solves it properly and adds a build step and a new category of thing that can break. For a five page site, the checklist wins.

The third copy rule

Here is the one piece of engineering discipline worth borrowing, translated for someone who does not write code. Two copies of something is fine. The third copy is a signal.

When you notice you are about to create a third instance of the same block, that is the moment to pull it into one place instead. Three pages that each define their own button styles means the styles belong in the stylesheet. Three pages with a slightly different testimonial section means you want one section definition and three sets of text. This is not about elegance. It is a cheap trigger that fires before the mess is expensive, and you can apply it without understanding any of the code, because you are counting, not reading.

Say it out loud in your request. A line like "use the existing classes in style.css, do not add new CSS unless there is no existing class for it" changes what you get back, because the model optimizes for whatever you made explicit. More on request shape in how to prompt Claude for a website, and on handing over your existing conventions in how to give Claude a design system to work from.

You will still end up with duplication. The goal is not zero. It is knowing where it is.

Names your future self can search

Naming is the cheapest maintainability work available and the easiest to skip. The test is whether you can find a file in six months by guessing its name, without browsing.

Pick one pattern and keep it. All lowercase, hyphens instead of spaces, no dates in the name unless the content is dated. pricing.html and contact.html, not Pricing_Final.html and contact-v2-NEW.html. Images named for what they show and where they go: hero-workshop.jpg, not IMG_4471.jpg. Capital letters and spaces in filenames cause real breakage on the way to a live server, because the web is case sensitive even when your laptop is not.

Kill the version suffixes. A folder holding index.html, index-old.html, index-new.html and index-final.html is the single most common way a small site becomes frightening to edit, because now every change starts with archaeology. Keep one live file per page. Put the old one in a dated backup folder outside the site, or delete it, since you have a backup anyway.

Inside the HTML, ask for comment markers around each section: a line reading <!-- PRICING TABLE --> above the pricing table. Comments are invisible to visitors and cost nothing. They turn "somewhere in this 400 line file" into a search that lands in one jump, both for you and for the model you paste the file into.

The parts that rot while you do nothing

The parts of your site most likely to break are the parts you did not write. A page made of your own HTML and CSS, sitting on static hosting, will render the same in three years as it does today. Nothing in it expires. The things that expire are the borrowed pieces.

Scripts loaded from someone else's server are the main one. A chart library, an animation library, a cookie banner, a font loader: each one is a request to a machine you do not control, and it can change, slow down or stop answering. If the script is doing something you could live without, remove it. If you need it, download the file, put it in your own folder and link to the local copy, so the version you tested is the version that serves.

Embeds are the second category. A booking widget, a form, a video player, a chat bubble. Each one is a live dependency on an account that can lapse and a product that can be retired. Keep a short list of every embed on the site, which account it belongs to, and what the page should do if it fails. A booking page that shows a blank gap where the calendar used to be is worse than one with a visible email address underneath it.

Then the housekeeping with actual deadlines. Domain renewal, payment card on file at your registrar and host, any API key with an expiry. Those have dates attached, which makes them easy to handle and easy to forget. Put the renewal dates in a calendar rather than trusting an email you may never see.

The maintenance you avoid by not building it

Refusing to build things is the highest leverage maintenance decision available. Every feature is a thing that can break, and on a small site most of them earn nothing.

Some concrete omissions worth making. You do not need a login system unless you are selling access, and if you are, use a payment provider that handles accounts rather than building one. You do not need a custom blog engine, since a folder of HTML pages serves the same content with nothing to patch. You do not need a carousel, which hides most of its content behind a click nobody makes and adds a script. You do not need animation on scroll, a dark mode toggle, a newsletter popup with delay logic, or a live chat you will not staff.

Forms deserve a sentence of their own, because they are the one dynamic thing most small sites genuinely need. Use what your host provides rather than a custom handler. Netlify Forms and similar built-in features work with plain HTML, have no code you maintain, and have one setting to get right instead of a server to look after. The no-code route to a working site covers that end of it.

Each refusal sounds like laziness and reads like a smaller site. It is really a decision about what you want to be doing in eight months, which is selling something, not patching a carousel.

The fifteen minute monthly pass

Maintenance on a site this size is not an ongoing project. It is one short pass, once a month, on a fixed list. Fifteen minutes, same checks every time, written down so you are not deciding what to look at.

Click every link in your nav and footer, including the ones in body text you added last month. Submit your own contact form and confirm the message arrives in your inbox rather than assuming it does, because a form that silently stops delivering is the most expensive failure on a small site and gives no sign at all. Load the home page on your phone. Check the prices and the phone number against reality. Open the site in a private window so you see it without your cache.

Then confirm you have a current copy of the whole site somewhere other than your laptop and your host. A zip in cloud storage is enough. Date the folder name. The point is being able to answer the question "what did this look like before I changed it" without relying on your host's history, which may be shorter than you think.

Write the list in a file and date each run. Five lines per month. That record is also what makes a problem diagnosable later, since "this worked in September" narrows the search enormously. If something is broken when you find it, the symptom usually tells you where to look.

None of this requires reading code. It requires deciding, early, that there is one place for each thing and one name for each file, and then being slightly stubborn about it when the model offers you a fresh copy instead. The sites that stay editable are not the well-engineered ones. They are the small, boring, consistently named ones with nothing borrowed that can expire.

Pick the structure this week, while moving a stylesheet is a ten minute job.

Common questions

Does AI-generated code really get harder to maintain over time?

The pattern is duplication rather than low quality. GitClear's analysis of 623 million code changes found duplicated blocks up 81% over 2023 levels and refactoring down about 70%, because a model writes a fresh copy of something instead of reusing what already exists. On a small site that shows up as the same header living in five files, so one edit becomes five edits and you miss one.

Should my website be one HTML file or several?

One self-contained file is the right way to start and stays fine for a single page. Once you have three or four pages, move the styling into one shared stylesheet that every page links to, otherwise your colors and spacing exist in four copies and a single design change becomes four edits. The move takes about ten minutes early and an afternoon later.

How do I change a site when I cannot read the code?

Work from the structure rather than the code. Know which file the page lives in, which stylesheet it uses, and roughly where each section sits, using HTML comment markers above each block. Then you can describe the change precisely, paste the one relevant file, and check the result, without ever reading a line of CSS yourself.

How often should I check an AI-built site?

Once a month is enough for a small static site, as a fixed fifteen minute pass: click every nav and footer link, submit your own contact form and confirm the message arrives, load the home page on a phone, verify prices and contact details, and check that a dated backup exists off your laptop. Date each run so you can tell later when something last worked.

What should I avoid building to reduce maintenance?

Skip anything with moving parts you would not test monthly: a custom login, a hand-built blog engine, carousels, scroll animation, popup logic and live chat. Use your host's built-in form handling instead of a custom one. Every feature you decline is a failure mode you never have to diagnose, and on a small site most of them earn nothing anyway.