A lawn-care business changes its online estimate form. The next morning, the form stops working, and the owner asks the website provider to restore yesterday's version. The provider says automatic backups are enabled—but nobody has checked what those backups contain or how a restore would work.

That is a problem worth finding before the website breaks.

For a small service business, the useful question is not simply “Do we have backups?” It is “Can we recover the website and the information we need to keep serving customers?” The answer depends on the platform, the backup's contents, its age, and who is responsible for restoring it.

Start With What You Need to Recover

Consider the work your website does. A basic handyman site may have service pages, photos, and a quote form that sends messages to an outside email inbox. A cleaning business may also take bookings through a separate scheduling service. Those systems can require different recovery steps.

Before discussing backup software, name the essentials: the public pages, working contact forms, current service details, and any records actually stored on the website. Also identify what lives somewhere else, such as business email or a third-party booking account. A website backup should not be assumed to include data held by a separate provider.

Ask what would have to be working again for customers to reach you. That becomes your recovery goal, rather than the vague promise of having a copy of “everything.”

Find Out What the Backup Really Contains

Backups are not all the same. On a typical self-hosted WordPress website, the WordPress documentation distinguishes the site's files from its database. Files can include themes, plugins, and uploaded images; the database stores much of the content and settings. Restoring a typical WordPress site requires both.

Other platforms manage this differently. WordPress.com provides automatic site backups on eligible plans, while its lower-tier plans offer content and media exports rather than that same automated backup feature. A content export should not be treated as proof that an entire site can be restored unchanged.

A website builder's version history may serve a different purpose again. For example, Wix's Site History lets users restore earlier saved or published versions, but Wix notes that some elements are not affected by that restoration.

These examples aren't a ranking of platforms. They show why you should ask your provider for a plain-language description of what is saved, what is excluded, and which recovery actions are possible on your actual plan.

Check Where Copies Are Kept and Who Can Access Them

A recent backup is more useful when it remains available after a hosting problem, account lockout, or compromised website. The Federal Trade Commission's small-business cybersecurity guidance recommends regular backups and protection of sensitive data, including encryption where appropriate.

If your designer manages the site, ask whether backup copies are stored separately from the live site, how access is protected, and who can retrieve them if the designer is unavailable. You do not necessarily need to operate the backup system yourself, but you should know who owns the recovery responsibility.

Also ask how long older copies remain available. One recent copy might contain a problem that existed before anyone noticed it. Keeping earlier restore points can be useful, but retention periods, storage arrangements, and fees depend on the provider and plan. Don't assume unlimited history or an automatic off-site copy without checking.

Test Recovery Without Overwriting Your Live Website

A backup dashboard may show “successful” while leaving the business unsure whether the copy can be restored. Ask your provider to demonstrate a recovery in a safe test environment, if the platform and service agreement allow it. For a self-hosted site, this may be a staging or separate test installation. For a managed platform, it may mean reviewing its supported version-restore process and what the account actually permits.

The test should confirm that the recovered pages load, essential images appear, and the inquiry path can be checked without sending real customer messages into an unintended inbox. Record the date, what was restored, what was not tested, and who performed the work.

Do not restore an old backup onto a working live site merely to prove that the button functions. A full restore can replace newer content or settings. WordPress.com's restore guidance explicitly warns that changes made after the selected backup point can be lost.

If no safe test is available, document that limitation and ask what the provider would do during a real outage. An untested recovery plan is still a risk, even when backup files exist.

Decide How Much Recent Work You Could Afford to Lose

A website updated once a month has different recovery needs from one receiving new appointment records throughout the day. Think about the latest change you would be uncomfortable losing, and ask whether the backup schedule can support that expectation.

A backup taken before a new service page was added will not automatically preserve that later edit. Restoring a website also does not establish whether a separate email inbox, customer-management tool, or booking service has its own recoverable records.

If inquiries or bookings are stored directly in the site database, restoring an older copy may affect records received afterward. Coordinate any real restoration with whoever manages those records, and confirm what can be preserved before proceeding. The right plan may involve more than rolling back the website.

There is no universal schedule that fits every small business. The frequency should reflect how often important information changes and how much loss the business can tolerate.

Put Five Questions in Your Website Care Agreement

Whether you pay an agency, use managed hosting, or maintain the site yourself, get clear answers to these questions:

  1. What is included? Are the site files, content, settings, uploads, and relevant stored form records covered—and what is not?
  2. How recent and how old? How often are copies made, how many restore points remain available, and for how long?
  3. Where are they kept? Are backups protected and accessible if the live site or hosting account fails?
  4. Who performs the restore? Who has the required access, what support is included, and are restoration fees separate?
  5. Has recovery been checked? Can the provider show a safe test or a documented recovery procedure, including likely data-loss limitations?

Keep the answers with your website account and maintenance records. Revisit them after a major site change or a switch in providers.

A reliable website care plan is more than a promise to create copies. It tells the business what can be brought back, who can bring it back, and what may be lost along the way. That's the distinction worth paying attention to before something goes wrong.

Sources and Further Reading