Restoring your site from a backup

If something goes wrong with your website (a bad update, accidental deletion, or a security incident), you may need to restore it from a backup. What that looks like, and whether it's possible at all, depends on what your site is built on. This guide walks you through what a restore means on each platform and what to expect.

When a restore is the right call

A full restore is not always the first response. A more targeted fix is often better. But a restore is the right call when:

An update or change has broken the site and can't be quickly undone
Content or data has been accidentally deleted at scale
The site has been compromised by malware or a hacker
Something has gone seriously wrong and a targeted fix isn't working

For smaller problems (like a single deleted page, or a broken plugin on WordPress) we may be able to fix just that piece without a full restore.

Think you've been hacked? Contact us before you restore anything

Take screenshots and note what changed first. A restore can remove the evidence of what happened: on Wix, for example, restoring a version erases any changes made after it. See Recovering from a hacked website.

Restoring by platform

For WordPress sites on our care plan, we restore from our own daily backups, following the process described in the rest of this page.

If you manage your own WordPress site, your host's backups are usually where you start: see Flywheel backups, WP Engine backups or Kinsta backups.

Our care-plan backups cover WordPress sites only at this time. Most of the rest of this page describes how we restore a WordPress site on our care plan.

What gets restored

On WordPress, a full restore replaces your entire site with the backup copy. That includes:

All pages, posts, and content
All images and uploaded files
All settings and configuration
All plugin and theme files

Important: changes after the backup are lost

Any changes you or your team made after the backup was taken will not be in the restored site. For example, if you published a blog post yesterday and we restore from a backup taken two days ago, that post will be gone from the restored version. We'll let you know what the cutoff point is before we restore. On Wix, restoring a version also erases later changes to your pages and design, but content in Wix apps such as Stores and Blog, and in CMS collections, isn't rolled back.

A restore puts back the whole backup copy, so anything that happened after it goes with it: the problem, which is the point, and your own work in between, which is the cost. That is why we often try a more targeted fix first, and why we tell you the cutoff date before we restore.

Read this as text

Take an example. A backup is taken two days ago. Yesterday you publish a blog post. Today something goes wrong with the site.

A full restore is not always the first response to that. We often try a more targeted fix first, for smaller problems, like a single deleted page or a broken plugin, that may be all it takes. A restore is the right call when a problem is serious enough to warrant it: an update that broke the site and cannot quickly be undone, content deleted at scale, or a hack.

A restore returns your site to the backup copy, so everything after the backup was taken is undone: today’s problem, which is the reason a restore fixes anything, and yesterday’s blog post, which is what it costs. That post is what you re-add afterwards, and we tell you the cutoff date before we start so you know what there is to re-add.

The restore process

For WordPress sites on our care plan, a restore runs in three stages.

PreparePick a clean backup and confirm the cutoff with you
RestoreStaging first where possible, then the live site
CheckVerify the site and tell you what to re-add

Stage 1 of 3: Prepare

We identify the right backup. We look at your backup history and choose the most recent clean backup: one from before whatever went wrong. For security incidents, we check carefully to make sure the backup itself is clean.

We confirm with you. Before we restore, we'll tell you which backup we're restoring from and what the cutoff date is. You'll know what changes will be lost.

Stage 2 of 3: Restore

We restore to a staging site first (where possible). If time allows, we restore to a staging copy and verify it's working before touching the live site.

We restore the live site. We push the backup to your live site. During this step, your site may show a brief maintenance message or be temporarily unavailable.

Stage 3 of 3: Check

We verify the restored site. We check key pages, forms, and functionality to confirm the restore was successful.

We let you know it's done. We confirm the restore is complete and explain what was lost and what to re-add if anything.

How long does a restore take?

For a WordPress site on our care plan, it depends on the size of your site:

Site size	Approximate restore time
Small site (a few pages, minimal media)	30 to 60 minutes
Medium site (blog, standard business site)	1 to 3 hours
Large site (store, lots of media, complex setup)	3 to 6 hours or more

During a restore, your site may be temporarily unavailable or show a maintenance message. We'll let you know before we start.

On other platforms, where a restore is possible at all, it uses the platform's own tools, so these times don't apply.

After the restore

Once the restore is complete:

Review your site to confirm it looks correct
Check for any content you need to re-add (posts published after the backup date, form changes, etc.)
On WordPress, if the restore was triggered by a security incident, we'll walk you through the additional steps to secure the site before it goes live again

Some platforms need extra checks:

Webflow: add your reCAPTCHA keys again if your forms use reCAPTCHA, turn bot blocking back on, and check CMS items that were set to "Queue to publish".
Wix: a restore only covers your pages and design. Check content in Wix apps such as Stores, Blog, Events and Bookings, your contacts, your media and pro galleries, your site's SEO Settings and your CMS collections by hand, because none of them revert. Bring back any CMS collection items you need from their item history or a CMS backup.
Custom-coded: ask your developer to check that your data and settings match the restored code, and to undo a Vercel rollback once a fix is ready, so new changes go live again.

Common questions

Can you restore just one page or one piece of content?

On a WordPress site on our care plan, in many cases, yes. We can sometimes pull a specific page or file from a backup without restoring the whole site. This is more complex but can preserve more of your recent work. Ask us what's possible for your specific situation.

On other platforms, it depends on the platform. Squarespace can restore deleted pages and blog posts for 30 days. Shopify's Timeline view can restore individual theme files. On Webflow, a restore rolls back the whole site, not a single page or CMS item. On Wix, a deleted product or blog post won't come back from Site History. For CMS collections, Wix says you can use CMS backups to restore earlier versions, and each item has its own item history.

What if the backup is also infected?

For security incidents on WordPress sites on our care plan, we check each backup before restoring. If several backups are compromised, we go further back in time until we find a clean one. We'll be transparent with you about how far back we need to go.

On Wix, a restore doesn't change your CMS collections or content in Wix apps such as Stores and Blog, so spam added to a blog, store or CMS collection stays after a restore. Site members' permissions don't revert either. A restore alone doesn't prove the site is clean, so check those by hand. On a custom-coded site, a rollback doesn't undo changes to your data, and any leaked keys must be replaced. On Vercel, a replaced key only takes effect with a new deploy: rolling back to an earlier build doesn't apply it. See Recovering from a hacked website.

Will my site go down during a restore?

On WordPress, there may be a brief period of downtime or a maintenance page while we apply the restore. We'll warn you before we start and aim to minimize any disruption.

On Webflow, a site manager restores the backup, checks it, and publishes it when it's ready.

How do I request a restore?

If your WordPress site is on our care plan, open a ticket on our support portal or email support@chykalophia.com. Describe what happened and when, and we'll take it from there. For urgent situations, see When & how to request emergency support.

On other platforms, contact us the same way and we'll tell you what your platform can restore and what has to be put back by hand. On any platform, contact us before you restore anything yourself, especially after a hack.

When to call a pro

Restoring the wrong backup can wipe out recent orders, form entries or content changes, and restoring onto a compromised site can bring the problem straight back.

If any of that sounds risky for your business, book a free call and we'll tell you whether you need help. Clients can email support@chykalophia.com.