Overview

Yext offers a powerful architecture for static site generation (SSG), allowing you to pre-render thousands of web pages using data from Content.

Yext takes SSG a step further by ensuring that:

  1. Your site is always up-to-date (has the freshest entity data)
  2. Your site is always pre-rendered (loads quickly)
  3. Only certain pages are regenerated when content is updated (no need for unnecessary full-site rebuilds)

This is known as our Streaming Static Generation architecture, and is made available for your production deployments right out-of-the-box.

Active Deployments

An “active” deployment indicates that pages in your deployment are actively regenerated in response to Content updates.

In the Pages UI, you can identify which deployments are active based on the status in the “Data Updates” section. Each time an entity within your site’s scope is updated, you should expect to see a corresponding data update activity.

active-deployments-list.png

By default, Yext guarantees that the following deployments on your production branch are always active:

  1. Production deployment - the deployment currently published to your production environment
  2. Staging deployment - the deployment currently published to the staging environment (note, staging deployments on non-production branches are inactive)
  3. Head deployment - the most recent deployment
  4. Previous Production deployment - the previous deployment that was published to your production environment

Inactive Deployments

An “inactive” status indicates that the pages in a particular deployment are not actively regenerated when Content is updated.

When viewing pages from an inactive deployment, it is possible to see outdated entity content on any pre-rendered entity pages.

<aside> 💡 Note, it is possible to publish an inactive deployment to production; however, that deployment will remain inactive. This means that some page content in this deployment could be stale.

To reliably ensure an old deployment is fully updated, we recommend redeploying that specific deployment, and then publishing the new one to production instead.

</aside>