Publishing doesn’t stop after launch

Your first full-site publish gets the site live.

After that, your team will keep making smaller updates — publishing individual pages, updating CMS items, merging branches, and moving changes through staging.

Some of those changes can remain pending until the next full-site publish.

That’s why it helps to think of full-site publishing as an ongoing maintenance step, not just a launch-day event.

What can stay pending?

A few types of changes are especially easy to lose track of.

CMS deletions and slug changes

If you delete a CMS item or change its slug, a full-site publish may still be needed before the old URL is fully cleared from the live site.

If your team regularly reorganizes CMS content, keep those changes in mind when planning your next full-site publish.

Shared changes after single-page publishing

Single-page publishing lets you move one page forward without publishing the rest of the site.

But if that page includes a change to something shared (like a component, variable, style, or interaction) only the page you published gets the updated version.

Other pages keep their previously published version until you publish those pages too or run a full-site publish.

A full-site publish brings those shared changes back into sync across the site.

Decide when a full-site publish is due

There isn’t one schedule that works for every team.

Instead of publishing the full site on an arbitrary cadence, look for signals that broader changes need to move together.

Ask:

• Have we made shared changes that should now update across the site?
• Have we deleted or reorganized CMS content that needs a full-site publish?
• Are there redirects, fonts, custom code, or other site-level changes waiting to go live?
• Have enough smaller publishes accumulated that it makes sense to bring production back into sync?

The right rhythm depends on how your team actually works.

Make the process repeatable

As more people contribute to the site, it helps to document how your team publishes.

That doesn’t need to be complicated. A simple publishing procedure might define:

• When changes should go through staging
• Who reviews or approves them
• Who can publish to production
• How teammates coordinate before a full-site publish
• What your team checks before and after publishing

Check before and after you publish

A routine full-site publish shouldn’t mean skipping review.

Before publishing, take a quick look at what’s waiting to go live. That might include:

• Unpublished page changes
• Queued CMS items
• Shared component, variable, style, or interaction changes
• Redirects
• Fonts, custom code, or other site-level settings

If your team uses staging, review those changes there first.

Then, after a meaningful production publish, spot-check the live site. Confirm that key pages look and behave as expected, especially anything affected by the changes you just published.

Feeling good?

Next, you’ll look at how to trace what changed and recover when something doesn’t go as planned.