You Built the Site in a Weekend. Who Updates It Next Month?

Building the site was the fun part. You prompted, Claude or ChatGPT wrote the files, you deployed, and you had a live URL by Sunday night. Then Monday of the following month arrives and a quieter question sets in: now what? A website isn't a deliverable, it's a living thing — prices change, blog posts age, links rot, and the AI tool that built it doesn't schedule a follow-up appointment.

Here's the good news: if you own the code (and if you prompted for raw files rather than using a site builder, you do — the ownership test that decides that is worth an hour of your time if you haven't already run it), maintenance doesn't require a developer. It requires a loop. And the loop is mostly prompting.

The three kinds of maintenance, sorted by frequency

Before you build any routine, know what you're actually maintaining. It falls into three buckets:

1. Content maintenance — weekly or monthly. New blog posts, updated copy, changed prices or dates, new testimonials.
2. Health maintenance — monthly. Broken links, typos, pages that render weird on mobile, images that fail to load.
3. Structural maintenance — quarterly or as-needed. Dependency updates, security patches, dependency refreshes for anything your site pulls in from outside itself.

Most people conflate these and end up doing none of them, because "maintain the website" is too vague to put on a calendar. "Check for broken links on the first of the month" is a task. Vague is the enemy, not technical difficulty.

The content update prompt

Content is the maintenance you should be doing most often, and it's the one your AI handles best. The mistake people make is opening a chat and saying "update my website." That produces a rewrite of everything, which is how working pages get broken.

Instead, treat content updates like a change request. Keep a running file — a TODO.md in your project folder works fine — and when something needs to change, add one line to it. Then, when you sit down to update, use a prompt shaped like this:

Here are the current contents of index.html and my TODO list.
Make ONLY the changes listed in the TODO. Do not restructure
the HTML, do not rename classes, do not touch any section not
mentioned. After editing, list every line you changed so I can
review it.

The last sentence is the important one. Asking the model to enumerate its changes forces it to be surgical, and it gives you a review artifact. If the model rewrote a section you didn't ask about, you'll see it immediately instead of three weeks later when something looks off.

The broken-link audit

Links rot faster than anything else on a static site. External sites redesign their URLs, blog posts you cited get moved or deleted, and your own internal links break when pages get renamed. A dead link on a landing page quietly costs you credibility with every visitor who clicks it.

You don't need a crawler tool for a small site — your AI plus a bit of scripting handles it. Once a month, run this:

Write me a small script that crawls every HTML file in this
project, extracts all href and src attributes, checks whether
each URL responds (both internal file paths and external URLs),
and prints a report of anything that 404s or fails to resolve.
Then run it and show me the results.

For a site of ten to twenty pages, this runs in seconds. Every broken external link gets a fix-it line added to your TODO file. Every broken internal link usually means a page got renamed — fix the reference, don't just delete it.

If you'd rather not script it at all, free checkers exist, but the script approach has an advantage: it lives in your repo, reruns forever, and you can ask the AI to extend it later (say, to also flag images over 500KB) without learning a new tool.

Dependency refreshes without the fear

This is the bucket that actually sounds technical, so let's demystify it. If your site is plain HTML, CSS, and a little JavaScript, you may have almost no dependencies at all — in which case this bucket shrinks to nearly nothing, which is one of the quiet advantages of the AI-built static site.

But if your project has a package.json — because it uses a build tool, a framework, or libraries — dependencies do age, and aged dependencies occasionally carry security issues. The safe version of the refresh is not "update everything to latest." It's:

List my project's dependencies and their current versions.
For each one, tell me: (1) what it does in my site, (2) whether
a newer version exists, (3) whether upgrading is likely to break
anything based on what you know of my usage. Suggest the safest
order to upgrade in, and upgrade one at a time.

One at a time is the whole trick. Upgrade a single dependency, run your site locally or on a preview deploy, check that the key pages still work, then move to the next. If something breaks, you know exactly which change caused it, and rolling back is one line.

The loop, on a calendar

Here's the whole routine as it actually runs:

• Weekly (15 minutes): append anything you notice to the TODO file. Pricing changed, a new testimonial came in, a paragraph reads awkwardly. Just capture it; don't fix it yet.
• Monthly (45–60 minutes): sit down with your AI of choice. Work through the TODO list with the surgical prompt. Run the link checker. Deploy the changes.
• Quarterly (30 minutes): dependency review if you have any. Also a good moment to reread your own homepage with fresh eyes and add "the homepage copy feels dated" to the TODO if it does.

Batching is what makes this sustainable. Fifteen minutes of capture per week means the monthly session has no guesswork — you're executing a list, not remembering three weeks of scattered annoyances.

One thing this loop deliberately doesn't cover

Editing and deploying changes safely — preview deploys, git diffs, and the sequence that stops a bad edit from taking down a working page — is its own discipline, and we've covered the safe edit loop in full already: Your AI Site Isn't Done, It's on Version One: The Safe Edit Loop for Sites Claude and ChatGPT Built. Read that before you run your first monthly session, because "the AI edited the file" and "the edit reached your live site safely" are two different events, and the second one deserves its own guardrails.

The fear worth retiring

The scenario people actually fear — the site builder with no developer, no technical skills, trapped with a site only its creator can touch — doesn't apply to you. You own the files. The files are text. Text is the one thing every LLM is fluent in. As long as you keep your changes scoped, review what the model says it changed, and batch the work on a calendar instead of hoping you'll remember, your maintenance cost is roughly an hour a month. That's less time than most people spend adjusting their site builder's theme settings.