Why public site showing wrong content — and how to fix it

How to fix public pages that display outdated or incorrect content

The Acme Coffee Roasters homepage is showing the old winter menu instead of the current spring menu. A visitor on the pricing page is seeing a promotional price that was removed two weeks ago. A blog post the team updated yesterday still shows last month's opening paragraph. This guide covers every reason a public SGEN site can display stale, wrong, or unexpected content — and the structured path to find and fix the cause.

Work through the five checks below in order. Most cases resolve at check 1 or check 2 — browser cache and draft vs published confusion account for the majority of reports. If you reach check 5, the content genuinely changed in a way that was not intentional and a snapshot restore is the fastest path to recovery.

What is this for?

This guide is for SGEN admins whose public site is displaying content that does not match what is currently saved in the admin — including outdated pricing, old page copy, superseded images, or content that was supposed to be updated but has not yet changed on the live URL. It covers every stage between "you saved an edit" and "a visitor sees the correct version", from browser cache to platform delivery.

The guide assumes the admin shows the correct content. If the admin itself is showing wrong content — the edit screen does not reflect the values you typed — start with the save-persistence path described in the Changes not showing guide first.

Good use cases

Example 1: Old pricing showing on the live page. Acme Coffee Roasters updated their seasonal catering package prices on the Pricing page. The admin save banner confirmed the change. A week later, a catering client called to say the old prices were still showing on the site. Check 1 confirmed the admin record had the correct new prices. Check 2 (hard-refresh) showed the same old prices. Check 3 (private window) showed the correct new prices. The cause was browser cache on the sales team's machine. A full cache clear and reload resolved it for every team member.

Example 2: Draft version of a page visible on the public URL. Acme Coffee Roasters was working on a major homepage refresh. The draft was set to Active accidentally during a save, and the incomplete redesign became visible to visitors for approximately 40 minutes. Check 1 caught the status as Active when it should have been Draft. Changing it back to Draft immediately removed the incomplete page from the public URL and restored the previous Active version.

Example 3: SG-Builder section showing old content after an edit. The Acme Coffee Roasters team updated the hero section in SG-Builder — changed the headline from "Roasted in Melbourne" to "Roasted in Melbourne, delivered nationwide". They clicked the in-builder Save but did not click Publish. The public page continued showing the old headline. Check 4 identified the missing Publish step. Returning to SG-Builder and clicking Publish regenerated the page correctly.

Example 4: Content reverted to an earlier version unexpectedly. Acme Coffee Roasters noticed the "About Our Roastery" page had reverted to a version from three months ago — the recent additions describing their new roasting facility were gone. Check 5 identified that a team member had restored a snapshot the previous afternoon without realising it would overwrite the current content. The most recent snapshot before the restore was used to recover the lost content.

Example 5: Wrong blog post appearing at a specific URL. A blog URL on the Acme Coffee Roasters site was routing to the wrong post — a different post was appearing at the URL the team expected to own. Check 1 revealed that two posts had been given the same slug, causing a routing conflict. Renaming the duplicate slug resolved the conflict and the correct post appeared at the intended URL.

What NOT to use this for

How this connects to other features

Before you start

Before working through the checks, have the following available:

It helps to open the admin edit screen and the public URL in separate browser tabs before beginning. Comparing the two side by side makes it faster to identify whether the discrepancy is on the admin side (the wrong content is stored) or the delivery side (the correct content is stored but not rendering).

• Admin access to the page or post showing the wrong content.
• The public URL — you will open it multiple times during the checks.
• A clear description of what the public page is currently showing versus what it should show. Write this down before starting — it will be useful if you need to contact support.

Where to go

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

• Pages — Admin → Pages
• Blog posts — Admin → Blog
• SG-Builder — accessed via Admin → Pages → Edit → SG-Builder for the affected page
• Snapshots — Admin → Pages → Edit → Revision History or Admin → Snapshots

Steps — five checks to resolve wrong or stale content

1. Confirm what the admin record actually contains

Before concluding the public page is wrong, confirm what the admin is currently storing. The edit form on the admin side is the source of truth — if the admin shows the correct content, the issue is with how the public page is being served. If the admin shows the wrong content, the issue is with the save itself.

To confirm the admin record:

1. Go to Admin → Pages (or Admin → Blog for posts).
2. Find the page or post in question and click Edit.
3. Read the current body content and compare it to what the public page is showing.

If the admin shows the correct content — the updated version you expected — but the public page still shows the old version, the issue is on the delivery side. Continue to Check 2.

If the admin also shows the wrong content — the old or unexpected version — this means the correct edit was either not saved, was overwritten, or was reverted. Check the Status field first. If the page is in Draft, set it to Active and save. If the content itself is wrong, continue to Check 5 to look at snapshot history.

Also check the Status field regardless. A page set to Draft serves no content on the public URL; what visitors see is either a 404 or, in some configurations, a cached version of the last Active state.

{{emit:admin-list-view {"title":"All Pages — Content Review","subtitle":"Acme Coffee Roasters","filterTabs":[{"label":"All","count":22,"active":true},{"label":"Active","count":18},{"label":"Draft","count":4}],"columns":["Title","Status","Last Modified","Last Published"],"rows":[{"cells":[{"html":"Homepage
Spring menu refresh — updated today"},"Active","today","today"]},{"cells":[{"html":"Pricing
Catering packages — last updated 2026-05-10"},"Active","2026-05-10","2026-05-10"]},{"cells":[{"html":"About Our Roastery
Roastery expansion details — needs review"},"Draft","3 days ago","1 month ago"]}],"height":360}}

2. Hard-refresh the public page

Browsers cache pages aggressively. Even after an admin save, your browser may be serving you a locally stored copy that predates the change. A hard-refresh forces the browser to bypass its local cache and fetch the current version from the server.

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.

Wait for the page to fully reload — watch the browser spinner complete — then check whether the correct content is now showing. If it is, the cause was browser cache. No further action is needed. Notify any other team members who were also seeing the wrong content to hard-refresh their tabs.

If the correct content still does not appear after a hard-refresh, continue to Check 3.

3. Open the public URL in a private browser window

A private window starts with no cookies and no cached resources. If the correct content appears in a private window but not in your regular browser tab, the cause is a deep browser cache that a hard-refresh did not fully clear.

To open a private window:

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 is stored in the admin.

If the correct content appears in the private window: clear your browser's full cache. Go to your browser settings → Clear browsing data → select Cached images and files and a time range that covers at least the period since the content was last updated → Clear. Reload the public URL in your normal tab.

If the wrong content appears in the private window as well, the cause is not browser cache — it is something on the server side. Continue to Check 4.

4. Confirm the SG-Builder publish step was completed

If the page uses SG-Builder for its layout or content, the wrong content may be the result of a missing Publish step in the builder. SG-Builder has two save actions: the in-builder Save button (which records changes inside the builder session) and the Publish button (which regenerates the public-facing page from the current builder state). If only the Save was clicked, the public page continues showing the last published version.

To confirm and complete the Publish step:

1. Go to Admin → Pages → Edit for the page in question.
2. Click the SG-Builder button to open the builder.
3. Review whether the builder shows the content you expected — if it does, the builder session is correct and you only need to publish.
4. Click Publish in the SG-Builder toolbar.
5. Reload the public page to confirm the correct content is now showing.

If the builder itself shows the wrong or old content, check whether another team member's session may have overwritten your changes — SG-Builder sessions are per-user, and if two users edit the same page, the most recent Publish wins. In that case, re-enter your changes in the builder, save, and publish again.

If the content is correct in the builder after publishing but the public page still shows the old version, continue to Check 5.

5. Review the revision history and restore a snapshot

If the wrong content appeared without any team member intentionally making that change, the most likely explanation is an accidental snapshot restore, an overwritten save, or a content reversion during a failed save cycle. SGEN records snapshots at each save point, and the revision history for a page shows every version that was saved.

To review the revision history:

1. Go to Admin → Pages → Edit for the affected page.
2. Look for the Revision History or Snapshots tab on the edit screen.
3. Browse the list of saved versions, noting the timestamp and the user who saved each one.

Identify the snapshot that corresponds to the correct version — the one that had the content you expected to see on the public page. Click Preview to confirm the content matches before restoring.

To restore a snapshot:

1. Click Restore next to the snapshot you want to recover.
2. Confirm the restore action in the confirmation modal.
3. After the restore completes, review the page content on the edit screen to confirm it is correct.
4. Click Save, then reload the public URL (or click Publish in SG-Builder if the page uses the builder) to push the restored content live.

The revision history above shows that Version 7 — the current state — was created by a snapshot restore on 2026-05-11. The correct content (the roastery expansion addition) was in Version 6. Restoring Version 6 and saving would bring back the missing content.

What success looks like

What to do if it does not work

If you have worked through all five checks and the public page is still showing wrong or stale content, collect the following before contacting SGEN support:

1. A description of what the public page is showing versus what it should show.
2. A screenshot of the public page (taken in a private browser window) showing the wrong content.
3. A screenshot of the admin edit screen showing the correct content that should be appearing.
4. The page title and public URL.
5. The most recent revision history entries from the edit screen, showing timestamps and users.
6. Whether the page uses SG-Builder, and whether the Publish step was completed.

When you contact support, the comparison between the private-window screenshot and the admin edit screen is the most actionable data point. If they diverge — the admin is correct but the public page is wrong — that points to a delivery-layer issue. If both show the wrong content, the issue is a save or reversion problem that the revision history can help support investigate.

Quick reference — the five checks

Common causes at a glance

Browser cache is the most frequent cause by volume. The admin save completed correctly and the server holds the right content, but the browser is serving a stored copy from before the save. A hard-refresh or a private window reveals the correct version. Full cache clearing resolves it persistently.

Missing SG-Builder Publish step is the second most common. The content was updated inside the builder, the Save button was clicked, but the Publish step was skipped. The public page continues showing the last successfully published version. Returning to the builder and clicking Publish regenerates the page.

Accidental snapshot restore is less common but high-impact. A team member restores a snapshot to check an earlier version, then forgets to re-apply the current content. The revision history makes this immediately visible — a restore action shows in the history with a timestamp and the user account that triggered it.

{{emit:bulk-action-result {"title":"Content Consistency Check — Acme Coffee Roasters","subtitle":"2026-05-13","rows":[{"label":"Pages checked","value":"22"},{"label":"Admin and public match","value":"20"},{"label":"Browser cache discrepancy found","value":"1"},{"label":"SG-Builder missing Publish","value":"1"},{"label":"Action taken","value":"Cache cleared + Publish run — both resolved"}],"height":200}}