Site Backups | Yext Hitchhikers Platform

Should a bug or corrupt dataset make its way into your production site, Yext provides you with the ability to deploy a backup version of your full site. From the moment you publish a site to production, you can deploy a backup version of your site as it existed at any previous point in time - right down to the second.

Refer to our Pages Backups guide for a step-by-step walkthrough on deploying a backup.

How this works under the hood is that the Pages system maintains a mapping of pages in your site to the specific deployment and Content JSON documents that were used as part of static generation process.

Preview Pages with UNIX Timestamps

While this feature is technically for disaster recovery, you can also use it to quickly preview what your pages looked like previously using UNIX timestamps! Here’s how it works:

From your deploys page, you can trigger the backup activation modal by clicking “Deploy Backup”. From here, you can select a specific date and time; the Pages system will generate an ISO 8601 timestamp query parameter for you automatically! (Refer to the screenshot below)


Simply append the timestamp to the end of your page URLs, and you can preview each page exactly as it appeared at that time!

For example, observe the differences between these two URLs:

Notice how this URL redirects you to a preview version of this site, where the location name differs (we added (edit from October 12th, 3:32PM EST) so you can see the difference)!

Backups History

To view an audit history of all backup activation/deactivation, you can use the “History” tab located in the left-hand navigation menu. From here, you can observe details on each backup-related event, including the:

  • Event timestamp
  • Event action
  • Backup timestamp query parameter
  • Event actor


Backup “Limitations”

There are a few things to consider when activating a backup:


When you activate a backup, Yext will purge the cache in CloudFlare to ensure any subsequent requests for your pages reflect the time of your backup. However, there is no way to invalidate a user’s browser cache when a backup is deployed, so it’s possible a user may encounter stale redirects. Worst case scenario, Yext’s 301 redirects are cached-controlled with a max age of 12 hours, so this edge case will be rectified either after 12 hours or if the user clears their browser cache.

Take the following example:

  • You have a location entity that powers the page; the location entity is mistakenly updated such that the page is updated to
  • Due to this update, the Pages system will automatically create a 301 redirect for /a.html to /b.html.
  • You deploy a backup to before that entity update occurred; as such, the user should expect to see when they request the page, as the redirect did not exist at the time.
  • Due to the cached redirect, the user will be directed to, which 404s.

It is possible for page links referenced in search engine results to 404 if such pages were created after the point-in-time backup timestamp.

Take the following example:

  • On Wednesday, October 12th, you create a new page:
  • The page starts to rank on Google Search.
  • On Thursday, October 13th, you decide to deploy a backup of your site from October 11th (back when did not exist). As such, clicking on that search result after the backup is deployed will subsequently 404. This is to be expected, but still something to consider.

Preview Environments

To guarantee that you are looking at a historical version of your site, timestamp query parameter strings should be appended to the end of your PRODUCTION URLs. To illustrate this clearly, observe the following example below:

In this example, is a production domain, while is a preview domain. In the Pages system, each deploy is associated with a unique preview domain. Per the “ Data Updates ” section of this unit, only a subset of your deploys at any given time is in-sync with the Content. As such, appending a timestamp query parameter to the end of certain domains will be “stale”, so as a best practice you should always append to the production domain.