Versioning a Small Website in 2026: Backups, Rollbacks, and Client Sign-Off Without a CMS
You build a small website. You publish it. The client asks for changes. You make the changes, publish again, and the client says the previous version was better. Now what? If you overwrote the old files, you are rebuilding from memory. If you kept a backup, you swap the folders and the problem is solved in thirty seconds.
Versioning is the practice of keeping trackable snapshots of your website at meaningful points in time, so that you can compare versions, roll back mistakes, and prove to clients exactly what changed and when. For large development teams, this means Git repositories, branching strategies, and CI/CD pipelines. For a small static website built with a desktop editor, it can be as straightforward as a dated folder on your hard drive. The important thing is not the sophistication of the system. It is that a system exists at all.
This guide covers versioning strategies for small websites ranging from manual folder-based backups through lightweight Git usage to client sign-off workflows. Every approach works with folder-based static sites and desktop editors like DFM2HTML. None of them require a CMS, a server-side application, or a team of developers.
Why Versioning Matters for Small Sites
The argument against versioning small sites goes like this: “It’s only five pages. I can rebuild anything that breaks.” That argument holds right up until one of these situations hits:
The client preferred the old design. You redesigned the homepage, published it, and the client wants to revert. Without a saved copy of the previous version, you are recreating the old layout from screenshots or memory, which is slower than it sounds and rarely exact.
You introduced a bug you cannot find. You changed a CSS rule that broke the layout on a specific page, but you made several other changes at the same time and you do not remember which edit caused the problem. With version snapshots, you can compare the current CSS file against the previous one and see exactly what changed.
A hosting incident destroys the live files. Server failures, accidental deletions, compromised accounts. The migration checklist covers moving between hosts deliberately, but unplanned data loss requires that you have a local copy that matches what was on the server.
You need to prove what was live on a specific date. Legal compliance, contractual disputes, regulatory requirements. Some clients need evidence of what their site displayed on a particular date. Versioned backups provide that evidence.
Multiple people edit the same files. Even a two-person team can overwrite each other’s changes without a versioning system. Person A updates the homepage. Person B, working from an older copy, uploads their version and erases Person A’s work. This happens constantly in teams that share files by email or cloud folders without version tracking.
None of these situations are exotic. They are routine events in the life of a small website. The question is whether you have prepared for them or not.
Strategy 1: Dated Folder Backups
The simplest versioning system is a folder-naming convention. Before making any significant change to your site, copy the entire project folder and name the copy with the current date:
projects/
├── acme-website/ (current working version)
├── acme-website_2026-03-15/ (backup before redesign)
├── acme-website_2026-04-01/ (backup before services update)
└── acme-website_2026-04-22/ (backup before navigation rework)
How to Do It Well
Use ISO date format (YYYY-MM-DD) in folder names. This sorts chronologically in any file explorer. 2026-04-22 sorts correctly. 22-04-2026 does not.
Add a brief description when helpful. acme-website_2026-04-22_nav-rework is more informative than just the date when you are scanning a list of backups six months later.
Back up before changes, not after. The backup captures the known-good state. If the changes you are about to make go wrong, this is what you restore. Making the backup after the changes defeats the purpose.
Include everything. The backup should contain the complete project: HTML files, CSS, JavaScript, images, DFM2HTML project files, configuration files. Everything. A partial backup that omits images because “they didn’t change” will betray you when you need to restore and discover the images you thought were unchanged were actually replaced three backups ago.
Automate the copy. A simple batch script saves time and prevents human error:
@echo off
set PROJECT=C:\Sites\acme-website
set BACKUP_DIR=C:\Sites\backups
set DATE=%date:~10,4%-%date:~4,2%-%date:~7,2%
set BACKUP_NAME=acme-website_%DATE%
xcopy "%PROJECT%" "%BACKUP_DIR%\%BACKUP_NAME%" /E /I /H
echo Backup created: %BACKUP_DIR%\%BACKUP_NAME%
pause
Run this batch file before starting any editing session. It copies the entire project folder to a timestamped backup directory in seconds.
Limitations
Dated folder backups are easy to understand and require zero tooling. But they have real limitations:
- Storage grows linearly. Every backup is a full copy of the project. A 50 MB site backed up twenty times consumes a gigabyte. For most small sites this is fine—hard drives are cheap—but it is worth being aware of.
- No line-level comparison. You can compare files between folders using a diff tool, but the backup system itself does not tell you what changed. You have to investigate manually.
- No merge capability. If two people make different changes to different copies, combining those changes requires manual comparison and integration.
- Discipline dependent. The system only works if you actually create backups consistently. One skipped backup before a major change and the safety net has a hole in it.
Strategy 2: Lightweight Git
Git is version control software designed for tracking changes in code. It records every change to every file, lets you compare any two points in history, and supports branching and merging for parallel work. Professional software development runs on Git. But you do not need to be a professional software developer to use Git’s basic features for versioning a small website.
The Minimum Viable Git Workflow
Install Git for Windows from git-scm.com. Open a terminal in your project folder and run:
git init
git add .
git commit -m "Initial version of site"
That is it. Your project is now a Git repository with one snapshot (called a “commit”) capturing the current state of every file.
When you make changes and want to save a new snapshot:
git add .
git commit -m "Updated homepage hero section and contact form"
The commit message describes what changed. Git stores only the differences between commits, not full copies, so storage is efficient.
Useful Git Commands for Small Site Versioning
See what changed since the last commit:
git status
git diff
git status shows which files were modified, added, or deleted. git diff shows the actual line-by-line changes. This is far more informative than comparing dated folders.
View commit history:
git log --oneline
Produces a compact list of all snapshots:
a1b2c3d Updated navigation links and footer
e4f5g6h Added services page
i7j8k9l Initial version of site
Restore a previous version of a specific file:
git checkout e4f5g6h -- css/style.css
This replaces the current css/style.css with the version from commit e4f5g6h, without affecting any other file. Surgical rollbacks.
Restore the entire site to a previous state:
git checkout e4f5g6h
This switches your entire project to the state it was in at that commit. You can inspect it, copy files out of it, or decide to make it the current version again.
Git Without GitHub
You do not need GitHub, GitLab, or any remote service to use Git for local versioning. Git works entirely on your local machine. The repository lives inside a hidden .git folder in your project directory. No internet connection required. No account required. No subscription.
That said, pushing your repository to a private GitHub or GitLab repository gives you off-site backup for free. If your hard drive fails, your entire version history is recoverable from the remote repository. For a private small-business site, a free private repository on GitHub or GitLab is a reasonable precaution.
Git with a GUI
If the command line feels hostile, several graphical Git clients work well on Windows:
- GitHub Desktop is free, simple, and handles the basic workflow (commit, push, pull, view history) through a clean interface.
- Sourcetree is free and more feature-rich, with visual branch graphs and diff viewers.
- TortoiseGit integrates into Windows Explorer, adding right-click menu options for Git operations. Commit, diff, and log viewing happen through standard Windows dialogs.
Any of these tools can manage a small site’s version history without requiring you to memorize command-line syntax.
Strategy 3: Client Sign-Off Workflow
Versioning is not just for your own safety. It is also a mechanism for managing client expectations and approvals. When a client requests changes, you need a process that establishes what was approved, when it was approved, and what the site looked like at the moment of approval.
A Practical Sign-Off Process
Step 1: Create a staging copy. Before making requested changes, create a new version (either a dated folder or a Git branch) and make the changes there. The current live version remains untouched.
Step 2: Share the staging version for review. Upload the staged version to a subdomain (staging.clientsite.com), a temporary URL, or a private folder on your host (clientsite.com/review/). Alternatively, package the folder as a ZIP file and send it to the client, who can open it locally in a browser.
Step 3: Get explicit written approval. An email reply saying “Looks good, go ahead” is sufficient. Save the email. The approval is tied to a specific version that you can identify by its date stamp or Git commit hash.
Step 4: Publish the approved version. Replace the live files with the approved staging version. Keep the previous live version as a backup.
Step 5: Confirm publication. Send the client a brief confirmation: “Changes are now live at clientsite.com. Previous version backed up as of [date].”
This process takes five minutes of extra effort per change cycle and eliminates the “I never approved that” conversation entirely.
Handling Revision Requests
Clients change their minds. Multiple rounds of revisions are normal. The versioning system makes this manageable:
- Round 1: Make changes, send for review. Client requests modifications.
- Round 2: Make modifications, send for review. Client approves.
- Round 3 (two weeks later): Client wants to revert one specific change from Round 1.
Without versioning, Round 3 is a research project. With versioning, you open the Round 1 snapshot, identify the specific content or layout element, and copy it into the current version. Five minutes instead of an hour.
How DFM2HTML Supports Versioning
DFM2HTML stores your website as a project containing both the editable source files and the exportable HTML output. This dual structure supports versioning naturally.
The project file captures your design decisions: element placement, template selection, style properties, navigation configuration. The exported HTML folder captures the published output. You can version both, and you should, because they serve different purposes.
Versioning the project file means you can reopen any previous version of the site in the DFM2HTML editor and make further changes from that point. Versioning the exported HTML means you can restore any previous version of the live site by uploading the corresponding folder to your host.
The built-in tutorial covers project file management. The feature overview describes the export process. For versioning purposes, the key point is that both the source and the output are ordinary files and folders on your hard drive. They work with dated folder backups, they work with Git, and they work with any other versioning approach that handles files.
Choosing the Right Strategy
The right versioning strategy depends on your situation:
Solo hobbyist, personal site: Dated folder backups are sufficient. Make a backup before each editing session. Keep the last five or ten versions. Delete older ones when disk space matters (it probably never will).
Freelancer building for clients: Dated folder backups plus a client sign-off process. Git is a bonus but not essential. The sign-off workflow matters more than the technical versioning mechanism because it protects you professionally.
Small team, shared project: Git is worth the learning investment. Even basic Git eliminates the overwrite conflicts that plague teams sharing files through Dropbox or email attachments. A shared private repository on GitHub gives everyone access to the latest version and the full history.
Any site with regulatory or compliance requirements: Git with remote backup. The commit history provides a timestamped, tamper-evident record of every change. For added assurance, tag specific commits with version numbers or client approval references:
git tag -a "v2.1-client-approved-2026-04-22" -m "Approved by client via email 2026-04-22"
Common Versioning Mistakes
Only backing up HTML, not project files. If you version the exported HTML but not the DFM2HTML project files (or whatever your editor’s source format is), you lose the ability to make further edits from a previous version. You can restore the live site, but you cannot reopen it in the editor and tweak it. Always version the source alongside the output.
Gigantic commit messages or no messages at all. “Updated stuff” tells you nothing. “Rewrote the entire CSS and also changed the homepage and added three new pages and fixed the contact form” tells you everything happened at once but nothing about the individual changes. Keep commits focused: one logical change per commit, one descriptive sentence per message.
Never testing restores. A backup you have never tested restoring is a backup that might not work. Periodically pick an old backup or Git commit, restore it to a test location, and verify it loads correctly. This takes two minutes and validates your entire versioning system.
Storing backups on the same drive as the original. If your hard drive fails, you lose both the project and every backup. Keep at least one copy on a different physical drive, an external drive, or a cloud storage service. Git repositories pushed to GitHub or GitLab automatically provide this off-site redundancy.
The Minimum Viable Versioning System
If you take nothing else from this guide, implement this:
- Before every editing session, copy your project folder and name the copy with today’s date.
- After the client approves changes, save their approval email alongside the backup.
- Keep backups on a different drive or cloud service from your working copy.
Three steps. No software to install. No new skills to learn. And the next time a client asks you to “put it back the way it was,” you will have the answer sitting in a folder, ready to upload.