English (United States) Čeština Deutsch Español (España) Français (France) Italiano 日本語

See more

Site Backups

Who does this article apply to?

  • Enterprise, Partner, and Small Business accounts.
  • Accounts in all regions.

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.

Under the hood, the Pages system maintains a mapping of pages in your site to the specific deployment and Knowledge Graph JSON documents that were used as part of the 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.

From your deploys page, click Deploy Backup to open the backup activation modal. From here, select a specific date and time; the Pages system will generate an ISO 8601 timestamp query parameter for you automatically.

backup-modal.png

Simply append the timestamp to the end of your page URLs to preview each page exactly as it appeared at that time.

For example, observe the differences between these two URLs:

  • https://cargo-nape-suspend.pgsdemo.com/ny/new-york/location1

    production-url.png

  • https://cargo-nape-suspend.pgsdemo.com/ny/new-york/location1?history=2022-10-12T15:24:00-04:00 (production URL with ?history timestamp)

    production-url-backup-timestamp.png

Notice how the second URL redirects to a preview version of the site where the location name differs — demonstrating the point-in-time difference.

Backups History

To view an audit history of all backup activation and deactivation events, use the History tab in the left-hand navigation menu. For each event, you can see:

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

backups-history.png

Backup Limitations

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

Redirects

When you activate a backup, Yext will purge the Cloudflare cache to ensure subsequent requests reflect the backup timestamp. 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. Yext's 301 redirects are cache-controlled with a max age of 12 hours, so this edge case will be resolved either after 12 hours or if the user clears their browser cache.

Example scenario:

  • A location entity powers brand.com/a.html. The entity is mistakenly updated so the page moves to brand.com/b.html.
  • The Pages system automatically creates a 301 redirect from /a.html to /b.html.
  • You deploy a backup to before that update. The user should now see brand.com/a.html, as the redirect did not exist at that time.
  • Due to the cached redirect, the user is still directed to brand.com/b.html, which 404s.

Search Results Page Links

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

Example scenario:

  • On Wednesday, October 12th, you create brand.com/b.html. The page starts to rank on Google Search.
  • On Thursday, October 13th, you deploy a backup from October 11th — before brand.com/b.html existed. Clicking that search result after the backup is deployed will subsequently 404.

Preview Environments

To guarantee you are looking at a historical version of your site, timestamp query parameters should always be appended to production URLs.

For example, the production URL:

  • https://cargo-nape-suspend.pgsdemo.com/ny/new-york/location1?history=2022-10-12T15:24:00-04:00

redirects to a preview domain:

  • https://aphr4pgqki-41059-d.preview.pagescdn.com/ny/new-york/location1?history=2022-10-12T15:24:00-04:00

In the Pages system, each deploy is associated with a unique preview domain, and only a subset of deploys at any given time is in sync with the Knowledge Graph. Appending a timestamp to certain preview domains may return stale data. As a best practice, always append the timestamp to the production domain.