How to Edit a Static HTML Website (Without Coding)

Static sites are fast, cheap to host and almost impossible to hack. Then someone asks you to change the opening hours, and you discover the catch: there's no admin panel. No login, no "edit page" button. Just a folder of files somewhere, and the person who set it up is on holiday.

This guide is for that moment. It covers how to find out what you're actually dealing with, the five realistic ways to edit a static site, and what each one costs in money, time and nerves.

Why editing a static site feels harder than it should

Three reasons, and it helps to know which one is hurting you:

There's no editor. A content management system like WordPress keeps your text in a database and builds the page on every visit. A static site has already been built. The text lives inside the HTML file itself.
Shared parts are copied, not shared. On a plain HTML site, the header, menu and footer are pasted into every single page. A site with 40 pages has 40 copies of the menu. Add one menu item and you have 40 files to change, and if you miss one, that page quietly shows the old menu.
Every change has a publish step. Editing the file on your laptop changes nothing until it's uploaded or deployed.

None of this makes static a bad choice. It's the trade we weigh in static websites: benefits and weaknesses. It just means the editing has to be planned.

First, find out how your site is built

Two questions decide which method works for you.

Where do the files live? In a hosting account you reach by FTP or a file manager, in a Git repository (GitHub, GitLab) connected to a host like Cloudflare Pages or Netlify, or only as a ZIP on someone's laptop. If you don't know, look at who sends the hosting invoice, and ask them.

Is it plain HTML, or generated? Many "static" sites are produced by a site generator such as Astro, Hugo, Jekyll or Eleventy. In the repository you'll see files like package.json, astro.config.mjs, hugo.toml or _config.yml, and the content often sits in Markdown files. This matters a lot:

The mistake that undoes your work

If the site is generated, never edit the finished HTML in the output folder (often dist, public or _site). The next build overwrites it, and your change disappears without a trace. Edit the source files instead.

If your site came from a WordPress export (Simply Static, WP2Static or a crawl), it's plain HTML, and probably a lot of it. We describe how those exports are made in converting WordPress to static HTML.

Method 1: Edit the file in a code editor

For the occasional text fix, this is the fastest route and costs nothing.

Get a copy of the files (download from the host, or clone the repository).
Open the folder in a free code editor such as VS Code. Avoid word processors, which break HTML.
Find the text with search (Ctrl/Cmd+Shift+F searches every file at once), change it, save.
Open the file in your browser to check it.
Upload the changed file to the same place, or commit and push.

For a change to the menu or footer, use search-and-replace across all files, and check a few pages afterwards. It works, but it relies on every copy being identical, and after a few years of hand edits they rarely are.

Good for: technical people, rare changes. Not good for: anyone who has to ask "where's the file?".

Method 2: Edit directly in GitHub

If the site deploys from a GitHub repository, you can edit without installing anything. Open the file on github.com, click the pencil icon, change the text and commit. Hosts like Cloudflare Pages and Netlify rebuild and publish automatically within a minute or two.

It's the friendliest of the do-it-yourself options for small text changes. It's no help for images, new pages or layout changes, and you're still reading raw HTML to find the sentence you want.

Method 3: Put a CMS on top

A Git-based CMS gives editors a proper interface while the site stays a set of files. Each saved edit becomes a commit, and the host publishes it. The options split into two groups:

Visual editing of existing HTML. CloudCannon can make regions of a plain HTML page editable, so an editor clicks into the text on the page and types. A developer has to mark those regions and set the site up first, and it's a paid product. We compared it in detail in CloudCannon vs ShiftPress.
Form-based editing of Markdown. Decap CMS, TinaCMS and Pages CMS are free or open source, and they're good. But they edit content files (Markdown, JSON, YAML), not finished HTML. For a plain HTML site that means first rebuilding it with a site generator so the content lives in those files. That's a development project, not an afternoon.

Good for: teams with a developer who sets it up once, and editors who then change text and images regularly.

Method 4: Ask an AI coding tool

Claude Code, Cursor and similar tools can open the whole folder and change it from a sentence: "update the phone number on every page", "add a page for our new service in the same style". They're very good at exactly the job that hurts most on static sites, the same change across many files.

The catch is that you're now reviewing code changes and deploying them yourself. You need a terminal, Git and enough HTML to notice when the tool changed more than you asked for. If that's you, our guide to building a website with Claude Code covers the setup, and the best Claude Skills for web design covers how to keep design changes on-brand.

Method 5: Use an AI website editor that hosts the site

The fifth option keeps the fast static site and removes the files from your life. You describe the change in plain words, the editor makes it, shows you a before-and-after preview of every affected page, and you publish when it's right. This is what we built ShiftPress for, and the details are in editing your website by chat.

Two things matter specifically for static sites:

Shared elements change everywhere at once. Ask for a new menu item, choose "apply to all pages", and the same header is updated on every page in one publish. No missed copies.
Rollback is one click. Every published change is versioned, so a mistake is a button, not an afternoon.

To get an existing site in, enter its address in the migration form: we copy it across, keep the URLs, and a person checks the result before you see it. If you have the files rather than a live site, you can upload them as a ZIP of HTML pages from the build page.

Stop editing files. Describe the change.

ShiftPress keeps your site static and fast, and you change it by chat with a preview of every affected page. Your URLs stay the same, the code stays yours.

Move my site ↗

The five methods compared

Method	Code skills	Cost	Best for
Code editor	Some HTML	Free	Rare text fixes by a technical person
GitHub web editor	Some HTML	Free	Small text changes on a Git-deployed site
Git-based CMS	A developer for setup	Free (Decap, Tina) to a monthly fee (CloudCannon)	Teams that edit content often
AI coding tool	Terminal and Git	An AI subscription	Developers making many changes quickly
AI website editor	No	A platform plan	Owners who want to change the site themselves

After any edit: three things to check

Can't see your change? It's almost always the cache. Hard-refresh (Ctrl/Cmd+Shift+R), try a private window, and give the host's CDN a minute. If it still doesn't show, check you edited the source and not the build output.
Did you rename or move a page? Add a 301 redirect from the old address, or you lose its rankings and every link pointing at it. More on that in static website SEO.
Added a page? Make sure it's in the menu, in sitemap.xml, and linked from at least one related page.

For the basics of getting files onto a server in the first place, MDN's publishing your website guide is a clear, neutral reference.

Frequently asked questions

Can you edit a static website without coding?

Yes, with the right tool. A Git-based CMS such as CloudCannon gives editors a visual interface once a developer has set it up, and an AI website editor lets you describe the change in plain words and approve a preview. Editing the files yourself, in a code editor or on GitHub, needs at least basic HTML.

How do I change the header or menu on every page of a static site?

On a plain HTML site the header is copied into every file, so you either search and replace across all files in a code editor and then check the pages, or use a tool that updates shared elements everywhere at once. On a site built with a generator such as Astro or Hugo, the header lives in one layout file, so you change it once there.

Is there a CMS for a plain HTML website?

CloudCannon can edit plain HTML directly once editable regions are marked. Open-source options such as Decap CMS, TinaCMS and Pages CMS edit Markdown or data files instead, so a plain HTML site has to be rebuilt with a site generator before they can manage it. AI website editors work on the HTML pages as they are.

Why don't my changes show up on the live site?

Usually the browser or the host's CDN is still serving the cached version, so hard-refresh or open a private window. If the site is built by a generator, you may have edited the build output instead of the source, and the next build replaced it. Also check that the change was actually uploaded or pushed.

Do I need FTP to edit a static website?

Only if your host works that way. Many static sites deploy from a Git repository instead, where you edit the file on GitHub or push a commit and the host publishes it automatically. Managed platforms handle publishing for you, with no FTP or Git at all.

How do I add a new page to a static HTML site?

Copy an existing page with a similar layout, rename it, replace the content, and update its title and meta description. Then add it to the menu on every page, to sitemap.xml, and link to it from a related page, otherwise visitors and search engines won't find it.

The bottom line

Editing a static site is easy once you know what you're dealing with: where the files live, and whether they're plain HTML or generated. For a rare fix, edit the file. For a team that edits often, put a CMS on top. If you want to change the site yourself without touching files at all, use an editor that understands the site, updates shared parts everywhere, and shows you the result before it goes live.

Whichever you choose, choose it on purpose. The worst setup is the common one: a fast static site that only one person can change.