Version control for websites records changes to site files so you can compare revisions and recover an earlier state. For a store owner, that history answers what changed, but not everything that matters. A saved revision, a working preview, and the version shoppers visit are different things. Know which one an action changes before treating it as an undo button for your business.
Disclosure: Runner AI publishes this guide. The Runner example describes its conditional checkpoint-based storefront history, not a feature available in every project.
What does version control for websites keep?
The Pro Git book defines version control as recording changes to files over time so you can recall specific versions later. For a website, those files can include page layouts, styles, scripts, and content stored alongside the code. A revision gives you a reference point for comparing a change instead of relying on memory or a folder named homepage-final-final.
The important word is files. An ecommerce site also depends on product records, inventory, customer accounts, orders, payment services, and settings outside those files. A saved storefront revision is not automatically a backup of those systems. Ask what the history includes and what needs a separate recovery process.
- Saved site revision. Identifies the recorded files, not whether those files are serving customers now.
- Preview of a revision. Lets you inspect appearance and interactions, but does not verify live payments or integrations.
- Publication record. Identifies a published version, not whether every customer task still works.
- Business-data backup. Defines which records can be recovered, not whether the storefront matches those records.
Git is a version control system. GitHub is a service that hosts Git repositories and adds collaboration tools. You can use a website builder’s history without operating Git yourself, but you still need to understand the scope of what it saves.
Preview, restore, and publish are separate decisions
Preview means inspection. Restore means changing the current working state. Publish means changing what a live deployment serves. A platform can connect these actions, but their consequences are not interchangeable. Read the confirmation rather than assuming that a button labeled Restore also changes the public website.
Consider an illustrative store with three recorded revisions. In v1, product cards use compact images. In v2, you enlarge those images and verify the mobile layout. In v3, a new navigation design makes collection links harder to find. You want to recover the v2 navigation without forgetting the work that came afterward.
First compare v2 and v3. If only the navigation is wrong, a focused correction may preserve useful v3 changes. A whole-revision restore can also bring back older layouts or text that you did not intend to recover. Review the change scope before choosing between those options.
In Runner’s documented checkpoint-based history, restoring an eligible earlier version creates a new current version with the older content. It retains the selected version and later history. In this example, restoring v2 after v3 would produce a new v4, not erase v3 or turn back the version counter. This is an example of the restore model, not a customer case study.
Publication remains separate. Review that new current version before deciding to make it live. Runner’s version-history guide owns the controls, availability conditions, and recovery instructions; the publishing guide explains the next decision.
What Runner’s history shows, and what it cannot prove
Runner’s published guide includes this example of a current v2 and an earlier v1. It shows recorded versions, not proof that either version’s checkout works or that a restore has completed.
Where the checkpoint-based experience is available, historical preview lets you inspect an eligible ready version without changing the latest project version or live store. A restore changes the project and can require a new build. History availability and supported actions depend on the project and version state; a failed or unavailable version is not a usable recovery point simply because it appears in a list.
The distinction matters when asking an AI builder for revisions. “Make it like before” leaves both the target and the scope unclear. Name the version, the route, and the behavior you want to recover. For example, a proposed request could be:
Compare the current collection navigation with the earlier version I selected. Keep the current product-card images. Propose a focused navigation correction, and tell me which other pages need review. Do not publish it.
This is a brief for work to inspect, not a guarantee that the resulting change is correct. Runner’s modern website design page explains its storefront revision capability. Use the product guide for the exact actions available in your workspace.
A review checklist before making restored content live
Choose a recovery point for a reason you can state. “The collection menu was usable on mobile in this revision” is more useful than “this version looks familiar.” Record the current version and the target, then check what else the earlier files would bring back.
Use this checklist as a review plan, not as a claim that version history performs these checks for you:
- Identify the changed customer task. Record the route, device size, action, and observed problem.
- Compare the scope. Decide whether to restore a whole revision or request a smaller correction that retains later work.
- Wait for conflicting work to finish. In Runner’s checkpoint flow, an active agent task or Design Mode save can block restoration.
- Verify the resulting current version. A request acknowledgment or screenshot is not enough. Inspect the actual content after the action and any required build.
- Retest the affected path. Check navigation, product selection, cart behavior, forms, and relevant mobile layouts. The responsive website testing guide provides a broader test matrix.
- Review external dependencies separately. Confirm product facts, inventory, checkout, payments, shipping, and connected services in the appropriate environment.
- Publish deliberately, then inspect the live result. Follow the live-store and checkout guide rather than treating a Published label as a health check.
If an action returns an error, establish the final state before repeating it. A failure to refresh history is not proof that the restore itself failed. Runner’s version-history error guide explains how to check the current-version marker and when to stop retrying.
Frequently asked questions
Is website version history the same as a backup?
No. Version history records the material covered by that system. A backup may cover databases, media, configuration, or other records that file history does not include. Define the recovery scope for each. For a store, do not assume restoring a layout also restores orders, stock levels, customer records, or a connected payment service.
Do I need GitHub to use version control for websites?
Not necessarily. Git can run without GitHub, and a website builder can expose saved revisions through its own interface. The choice depends on who edits the site and what they need to recover. Regardless of the tool, check that you can identify a revision, inspect its changes, and distinguish recovery from publication.
Does restoring a Runner storefront version delete newer history?
In the documented checkpoint-based restore flow, an eligible restore adds a new current version and keeps existing history. It does not publish that content automatically. Availability is conditional, so check the version-history guide and the actions shown for your project. Review the new current version before making a separate publication decision.
Can an earlier working design still fail after restoration?
Yes. Saved files are only part of the site. Products, services, configuration, or browser behavior may have changed since the revision was recorded. Retest the customer task that motivated the restore and its connected systems. A version that once looked right is a candidate for review, not evidence that the whole store works now.
Keep one record of what changed and another of what you verified. That makes the next revision easier to judge without turning every design experiment into a live-store gamble. Start a storefront project with Runner AI, or use the linked guides to review an existing one.