Static Website Client Editing Guide

· Sitecake

Static websites have a lot going for them. They load fast, they're cheap to host, they don't need database maintenance, and they're far less vulnerable to the kind of attacks that hit WordPress sites daily. For brochure sites, landing pages, portfolios, and small business websites, a static HTML site is often the most sensible choice.

The problem shows up at handoff. The client asks: "How do I update the text myself?" And suddenly the advantages of static HTML become a puzzle to solve.

This guide covers the realistic options for adding client editing to a static website — what each approach costs in time and money, what it gives clients in usability, and where each one breaks down.

Why static sites need special attention for client editing

A dynamic CMS like WordPress handles client editing as a core feature — content lives in a database, the CMS reads it, renders the page, and provides an admin interface for editing. The editing problem is solved by the platform.

A static HTML site doesn't have this infrastructure. The content is directly in the HTML files. Editing the content means editing the files. That's straightforward for a developer but a barrier for most clients.

The options for solving this fall into a few categories:

Option 1: You handle all updates

The client emails changes, you edit the HTML, and redeploy. Simple, requires no extra tools, and keeps the static site architecture clean.

Works well when: the client rarely needs updates (less than once a month), updates are small, and the ongoing relationship is already in scope of a maintenance retainer.

Breaks down when: the client needs frequent changes, has time-sensitive content (events, pricing, staff changes), or the maintenance retainer doesn't exist and each update becomes a billable discussion.

Option 2: Rebuild in a CMS

Convert the site to WordPress, Squarespace, or another full CMS. Recreate the design in a theme or template. The client gets a proper editing interface.

Works well when: the site is early in development and rebuilding isn't a large additional effort, or when the client genuinely needs CMS features (user accounts, e-commerce, a blog with many posts).

Breaks down when: you've already built the site in static HTML and rebuilding means starting over. The design you built doesn't exist as a WordPress theme — you'd recreate it in PHP, configure plugins, set up a database, and maintain it all going forward. For a 5-page brochure site, this is almost always overkill.

Option 3: Headless CMS

Use Contentful, Sanity, Netlify CMS, or a similar headless CMS to manage content separately. The static site fetches content from the CMS via API at build time or on request.

Works well when: you're already using a modern frontend framework (React, Next.js, Astro, etc.) and the build pipeline supports it. Headless CMS products are well-designed for this scenario.

Breaks down when: your site is plain HTML without a framework or build pipeline. Adding a headless CMS to plain HTML files means converting to a framework first — again, a rebuild. Also: most headless CMS products have monthly subscription costs that add up across multiple client sites.

Option 4: Flat-file CMS (drop-in)

A flat-file CMS edits your HTML files directly, without a database and without a rebuild. You mark the editable regions with a CSS class, upload the CMS files, and the site becomes editable.

Works well when: the site is plain HTML, the server supports PHP, and the client needs a simple visual editor for text and images. This is the minimal-overhead solution for handing off a static site without rebuilding it.

Breaks down when: the client needs complex content structures, multi-user access with different roles, or the site is on a static host that doesn't support PHP (like Netlify or GitHub Pages).

SiteCake is a flat-file CMS in this category. It attaches to existing HTML, requires no database, and provides an inline editor — clients click on the page to edit it, just as it looks to visitors.

Option 5: Git-based visual editor (JAMstack)

Tools like Tina CMS, Decap CMS (formerly Netlify CMS), or Forestry (now migrated to Tina) provide a visual editing interface that commits changes back to a git repository. A CI/CD pipeline builds and deploys the static files on each commit.

Works well when: the site is built with a static site generator (Jekyll, Hugo, Eleventy, Astro) and already has a git-based deployment pipeline. The editorial workflow is sophisticated and the development team is set up for it.

Breaks down when: the site is plain HTML (not generated from a static site generator), or the client is non-technical enough that the concept of "commit and deploy" needs explaining. Also requires setting up and maintaining the CI/CD pipeline.

Setting up SiteCake on a static site

For most web designers handing off a plain HTML site, the flat-file CMS approach is the most practical. Here's what the SiteCake setup looks like in concrete terms.

Step 1: Mark editable regions. Add class="sc-content" to any div you want clients to be able to edit. You can be selective — mark only the content areas, leave the navigation and footer protected.

<section>
  <div class="sc-content">
    <h1>Welcome to Our Business</h1>
    <p>We've been serving the local community since 2005.</p>
  </div>
</section>

Step 2: Upload SiteCake. Download from sitecake.com/pricing.html. Extract and upload sitecake.php and the sitecake/ folder to the web root alongside the HTML files.

Step 3: Test the editor. Open yourdomain.com/sitecake.php in a browser. Log in with the default password and verify the editable regions work as expected. Change the password before handing access to the client.

Step 4: Document the client's login URL. The client logs in at yourdomain.com/sitecake.php. That's the only URL they need to remember. A short one-page handoff guide with this URL, the password, and basic editing instructions is worth the five minutes it takes to write.

What clients can change

Inside any sc-content region, the client can:

What stays protected

Anything outside the sc-content regions is completely off-limits. The client cannot accidentally:

This is the most important practical benefit for designers. You define exactly what's editable. The design is protected.

Training clients to use the editor

Most clients need about 15 minutes of orientation. The editing interface is designed to be self-explanatory, but a brief walkthrough prevents confusion and reduces support requests later.

A typical training covers:

A screen recording of these steps, shared as a short video, is often enough to replace a live training session for most clients.