Why changes not showing — and how to fix it

How to fix changes that aren't showing on the live site

You edited the your business homepage hero — changed the call-to-action copy from "Shop Now" to "Order Online", clicked Save, saw the green banner, then opened the public site. The old text is still there. This guide walks every reason that can happen and the fastest way to confirm which one it is.

Work through the seven checks below in order. Most cases resolve at check 1, 2, or 3. If you reach check 7 you have encountered a save-handler quirk; the fix is a deliberate clean re-save.

What is this for?

This guide is for SGEN admins who completed a save action — on a page, post, global setting, Custom CSS snippet, Custom Code, or an SG-Builder block — and the change has not appeared on the public-facing URL. It covers the full pipeline between "you click Save" and "a visitor sees the result", flags every point where that pipeline can stall, and gives you one concrete action to confirm or rule out each stage.

The guide assumes you completed the save and the admin showed a success banner. If the admin showed a red error banner when you clicked Save, start with the error text — that is a different path.

There are seven possible causes, listed from most to least common. You will rarely need to go past check 3. When you do, each subsequent check takes under two minutes.

Good use cases

Example 1: Homepage CTA text not going live. your business updated the hero CTA from "Shop Now" to "Order Online" inside SG-Builder, clicked the in-builder Save button, and then checked the public site. The old copy was still there. Check 4 identified the surface: SG-Builder has two separate actions — the in-builder Save (records the change in the builder session) and the

Publish button (regenerates the public page). The in-builder Save had been clicked but Publish had not. Clicking Publish pushed the change live within 30 seconds.

Example 2: Blog post edit not visible after save. an editor, a content editor at your business Coffee Roasters, updated the intro paragraph on the "your detailed content piece" post and clicked Save. The public post still showed the old paragraph. Check 1 revealed the status had silently reverted to Draft — she had accidentally bumped the status dropdown while editing. Switching back to

Published and saving resolved it within seconds.

Example 3: Custom CSS brand override not applying. A .hero-cta color override was saved as an Active Custom CSS snippet but the button on the public site remained the old red. Opening the URL in a private window (Check 3) showed the correct color. The cause was browser cache — the normal tab was serving a locally stored stylesheet. A hard-refresh (Ctrl+Shift+R) cleared the cached copy and the correct color appeared immediately.

What NOT to use this for

message, not this guide.

success banner.

not showing it is correct behavior.

settings docs.

render; wait 60 seconds and hard-refresh before treating it as missing.

How this connects to other features

See Create and manage pages.

See Create and manage blog posts.

See Structure and layout in SG-Builder.

See Create a Custom CSS snippet.

See Create and manage Custom Codes.

Before you start

Before working through the checks, have these to hand:

expect.

It also helps to be on a desktop browser where you can open a private window alongside your normal tab. On mobile browsers, the private-window path (Check 3) is harder to act on quickly.

If the edit you made was inside SG-Builder, keep the builder tab available — you may need to reopen it for the Publish step (Check 4). The builder URL is the same as the page edit URL with the SG-Builder button clicked; navigating back to it reopens the last builder session.

• Admin access to the record you edited (page, post, or setting).
• The public URL of the page you changed — you will open it several times during the checks.
• A second browser tab open to the SGEN admin so you can compare what is stored against what you

Where to go

The seven checks in this guide touch several areas of the SGEN admin:

• Pages — Admin → Pages
• Blog posts — Admin → Blog
• Custom CSS — Admin → Custom CSS
• Custom Codes — Admin → Custom Codes
• SG-Builder — open via Admin → Pages → Edit → SG-Builder on the page you changed
• Settings — Admin → Settings for global values like site name or email

All seven checks are covered in the Steps section below, in the order you should try them. Stop as soon as you find the cause. Do not skip ahead — checks 1 through 3 are fast and rule out the most common causes. Skipping them and going straight to check 7 will cost you more time if the actual cause turns out to be a simple browser cache hit.

Steps — seven checks in order

1. Confirm the record is Active, not Draft

Every page and post in SGEN has a status. If it is set to Draft, the public URL returns a 404 and none of your edits are visible to visitors regardless of what the admin shows.

Open Admin → Pages (or Admin → Blog for posts). Find the record you edited and look at the

Status column.

• If it reads Draft, open the edit screen, change the status dropdown to Active (pages)

or Published (posts), and click Save. Reload the public URL. You are done.

• If it reads Active or Published, continue to Check 2.

Notice the "your detailed content piece" row above — status shows Draft, which is why the public URL returns a 404 rather than the post content. Changing it to Active and saving pushes it live. The change takes effect on the next public page load.

2. Hard-refresh the public page in your browser

Browsers cache pages aggressively. Even after a successful save, your browser may be showing you a locally stored copy from minutes or hours ago. A hard-refresh forces the browser to fetch the current version from the server, bypassing its local cache entirely.

To hard-refresh:

• Windows: press Ctrl+Shift+R while the public page is the active tab.
• Mac: press Cmd+Shift+R while the public page is the active tab.
• Safari on Mac: hold Shift and click the reload button in the address bar.

Wait for the page to fully reload — watch the spinner complete — then check whether your change is now visible. If the change appears after the hard-refresh, the cause was browser cache. Nothing else to fix.

If the change still does not appear, continue to Check 3.

3. Open the public URL in a private window

Sometimes a logged-in browser session introduces caching or auth-state behavior that a regular hard-refresh does not clear. A private window starts with no cookies and no cached resources, giving you a clean view of what a first-time visitor sees.

Steps:

1. Open a new private window — Ctrl+Shift+N on Chrome, Ctrl+Shift+P on Firefox.
2. Paste the public URL into the address bar and press Enter.
3. Compare what you see with what you saved in the admin.

If the change appears in the private window but not in your normal tab, clear your browser cache fully: browser settings → Clear browsing data → check "Cached images and files" → Clear. Then reload the normal tab.

If the change does not appear in either window, continue to Check 4.

4. Confirm which surface owns the content and use its correct save path

SGEN has several editing surfaces that each have their own save path. Missing a step in a multi-step save is one of the most common reasons a change does not go live. The table below maps each surface to the save action it requires.

SG-Builder specifically has two steps. Clicking the in-builder Save button records your changes inside the builder session but does not update the public page. You must also click the

Publish button in SG-Builder to push the change to the live page. If you only clicked Save without Publish, the public page still shows the previous version.

To fix a missing Publish step:

1. Return to Admin → Pages → Edit for the page you changed.
2. Click the SG-Builder button to reopen the builder.
3. Click Publish in the builder toolbar.
4. Reload the public URL.

If the change appears after using the correct save path, you are done. If the record was already saved correctly and the change still does not appear, continue to Check 5.

5. Re-open the admin record and confirm the save persisted

The admin save banner says "Saved" — but did the value you typed end up in the stored record? Re-open the edit screen fresh — not from the tab you are currently on, which may still show pre-save state — and compare what is stored to what you expect.

Steps:

1. Navigate away from the edit screen entirely — go to the list view

(Admin → Pages or Admin → Blog).

1. Click into the record again to reopen it fresh from the database.
2. Read the field you edited. Does it show your new value?

• Yes — the value is saved correctly. The issue is on the delivery side. Continue to Check 6.
• No — the save did not persist even though the banner showed success. Go directly to Check 7.

6. Wait for CDN cache to expire

SGEN sites use a CDN (Content Delivery Network) that caches public pages to serve them quickly to visitors. After a successful admin save, the CDN may continue serving the old version of the page until its cache entry expires.

• Typical wait on staging: 5–15 minutes.
• Typical wait on production: usually under 30 minutes; can be longer depending on your plan.

To confirm CDN cache is the cause:

1. Wait 15 minutes.
2. Hard-refresh the public URL (Ctrl+Shift+R).
3. If the change is now visible, CDN cache was the cause and no further action is needed.

You cannot clear the CDN cache manually from inside the SGEN admin. If you need a change to appear immediately on production — for example, a price correction or an urgent content update — contact SGEN support and request a manual cache purge. Include the public URL and the time you saved the change.

7. Re-save cleanly — the admin success banner can show even when the save did not complete

This is a known behavior in SGEN: the green success banner fires based on the admin receiving and processing your submission, not on a confirmed database write. In some edge cases the write is silently skipped and the stored value is not updated — but the banner looks identical to a successful save either way.

You confirmed in Check 5 that the stored value does not match what you typed. Here is how to resolve it:

1. Navigate to the list view and reopen the edit screen fresh — do not use the browser back

button, which restores a cached version of the form.

1. Clear the field you are editing and retype the value. Do not paste from a copy of the old

field, which may carry invisible formatting characters.

1. Click Save.
2. Immediately navigate away — go to the list view — and then re-enter the edit screen.
3. Confirm the new value is now stored correctly. If it is, reload the public URL.

If the value still does not persist after two clean save attempts on separate edit-screen sessions, capture a screenshot of the admin edit screen showing the field and what you typed, then contact SGEN support with the page or post title, the field name, and the expected value.

What success looks like

What to do if it does not work

If you have worked through all seven checks and the change still does not appear on the public site, collect the following before contacting support:

1. A screenshot of the admin edit screen showing the field and its current stored value.
2. A screenshot of the public URL showing what is rendering.
3. The page or post title, the specific field you changed, the value you entered, and the time of

your last save attempt.

When you contact SGEN support, the most useful thing you can tell them is whether the stored value matches what you typed when you re-opened the edit screen fresh (Check 5 result). If it does not match, that confirms a save-persistence issue. If it does match, that points to a CDN or delivery issue. Both route to different teams, and knowing which it is gets your report to the right place faster.

Quick reference — the seven checks

Common combinations

These are the three most frequent root causes when changes are not showing, based on typical patterns reported to SGEN support:

Browser cache (most common). You saved successfully, the admin record is correct, but your browser is serving a locally cached copy. The private-window test (Check 3) shows the correct version while your normal tab does not. Fix: hard-refresh with Ctrl+Shift+R, or clear the full browser cache.

SG-Builder missing Publish step (second most common). You clicked Save inside the builder but did not click Publish. The admin record stores your edit but the public page is not regenerated until Publish is clicked. Fix: reopen SG-Builder and click Publish.

Draft status (third most common). A status dropdown was accidentally changed to Draft, or the record was never published to begin with. Fix: open the edit screen, set status to Active or Published, and save.

Surfaces and their save paths at a glance

Understanding which surface you used to make the change is the fastest path to knowing which save action applies. Mismatched surfaces — editing a field in one place and expecting it to update content owned by a different surface — account for a significant share of "my change isn't showing" reports.

Standard edit form (pages, blog posts, most settings): one-step save. Fill the form, click Save, the record is updated immediately. The public page reflects the change on the next page load, subject to browser cache and CDN.

SG-Builder: two-step save. The in-builder Save button writes your changes to the builder session. The Publish button regenerates the public page from that session. Both steps are required. If you only complete the first step, visitors loading the public page get the last published version, not the current builder session.

Custom CSS snippets: one-step save, but with a status gate. Click Save, then confirm the snippet Status column in the list reads Active. If Status is Inactive, the CSS is stored but not injected on public pages — the snippet is completely invisible to visitors even though it saved correctly.

Custom Code snippets: same pattern as Custom CSS. Save, then confirm Active status. An inactive snippet injects nothing into the page, regardless of what it contains.

Global settings (site name, contact email, social links): one-step save. Click Save Settings. Changes appear on the next full page load of any public page that renders that setting — usually immediately, subject to browser cache.

Save-handler false positives — what they look like and why they matter

The SGEN admin save flow shows a green success banner when the server receives and processes your form submission. In most cases this means the database write completed. In some edge cases it does not — the server acknowledges the submission but the write to the database is silently skipped.

This behavior is not limited to one area of the admin. It has been observed across pages, blog posts, custom codes, and other record types. The result looks identical from the admin side: you see the green banner, no error appears, but re-opening the edit screen fresh shows the old value still stored.

The most reliable way to detect a false positive is Check 5 above: navigate away from the edit screen entirely and re-enter it fresh from the list. If the value you typed is not there, the save did not persist — the banner was misleading.

When this happens, a clean re-save (Check 7) resolves it in most cases. The re-save works because the submission payload and timing change on the second attempt, and the write goes through. If the re-save also fails after two attempts, the issue is persistent and needs support involvement — bring the screenshot evidence from Check 5 showing what is stored versus what you expected.

This behavior is documented here so you can recognize it quickly and skip the browser cache and CDN checks when the root cause is upstream of delivery.

Frequently asked questions

My change shows in the admin but not on the public site. Which check handles that? Start with Check 2 (hard-refresh) and Check 3 (private window). If both show the old version, go to Check 6 — the most likely cause is CDN cache, which means the admin save was successful but the cached public page has not expired yet. Only move to Check 5 if you want to rule out a false positive before waiting for CDN expiry.

I clicked Publish in SG-Builder and waited five minutes but the old version is still showing. Confirm the page Status is Active (Check 1) — an SGB Publish on a Draft page has no visible effect on the public URL until the page is also set Active. If Status is already Active, open the public URL in a private window (Check 3) before concluding the publish failed. SGB Publish on a live Active page normally takes effect within 30 seconds.

The green save banner appeared but when I reopened the edit screen the old value was there. This is the save-handler false positive described in Check 7. Retype the value from scratch in a fresh edit session — navigate away first, then re-enter the edit screen — and save. Immediately navigate away again and re-enter to confirm the new value is stored before reloading the public URL. If it fails a second time, contact support with a screenshot showing the mismatch.

How long should I wait before assuming the CDN is the problem? On staging, up to 15 minutes. On production, up to 30 minutes. If the change is not visible after 30 minutes and you have confirmed the admin record is correct (Check 5), contact SGEN support and request a manual cache purge for the specific URL. Include the URL and the exact time you saved.

I changed the site name in Settings and it still shows the old name on the homepage. Settings changes apply immediately to the database. The most likely cause is browser cache on the homepage — hard-refresh (Ctrl+Shift+R) on the homepage tab. Some themes also cache the site name in a theme-level template; a second hard-refresh after the first usually clears it. If the old name persists in a private window, re-open Settings and confirm the new name saved (Check 5).

I updated a Custom CSS snippet but the style change is not visible. First confirm the snippet Status is Active in Admin → Custom CSS — an Inactive snippet does not inject, regardless of its content. If Status is Active, do a hard-refresh on the public page (Check 2), since browsers cache stylesheets aggressively. If the style is still absent after a hard-refresh in a private window, re-open the snippet fresh from the list and confirm the CSS body stored the value you typed (Check 5).