Why search not returning results — and how to fix it

How to fix public-site search that returns 0 or wrong results

You added a new page to the Acme Coffee Roasters site, set it to Active, and saved it. A visitor types a relevant term into the public search bar and gets nothing back. Or the search surfaces an old page whose slug was renamed last month — clicking the result lands on a 404. This guide walks every reason that site search can go wrong and the fastest way to identify which one applies.

Work through the five checks below in order. Most cases resolve at check 1 or check 2. If you reach check 5 you are dealing with a scope exclusion that needs a settings change plus a manual rebuild. Each check takes under three minutes. Stop as soon as you find the cause, run the fix, and verify in the public search widget before moving on.

What is this for?

This guide is for SGEN admins whose public-site search widget is returning 0 results, returning the wrong pages, returning broken links, or surfacing outdated page titles and descriptions alongside current content. It covers the pipeline between "you publish a page or post" and "the search index reflects it", identifies every stage where that pipeline can stall, and gives you one concrete action per stage to confirm or rule it out.

The guide assumes the search widget itself is present and functional on your public site — visitors can see the search bar and submit a query, but the results are wrong or absent. If the search bar is missing from the page entirely, or if the widget is throwing a visible error rather than returning results, that points to a layout or widget-configuration issue, not an indexing problem. Start with your page layout or SG-Builder widget settings in that case.

There are five possible causes, listed from most to least frequent. Most teams encounter cause 1 or cause 2. Causes 3 through 5 are less common but worth knowing, because each has a distinct fingerprint that makes it easy to recognise once you know what to look for.

Good use cases

Example 1: New product page not appearing in search. Acme Coffee Roasters published a new

Seasonal Espresso Blend page and set it to Active. A week later, a teammate searched for "espresso blend" on the public site and got 0 results. Check 1 confirmed the page Status was Active. Check 2 revealed the index had not been rebuilt since before the page was added — the

Last index rebuild timestamp in Search settings predated the page's publish date by four days. Running a manual rebuild brought the page into results within two minutes.

Example 2: Renamed slug still pointing to a 404 in search results. The Acme Coffee Roasters team renamed the Brewing Methods page slug from /brewing-methods to /how-to-brew. Visitors who searched for "brewing" and clicked the result were landing on a 404 — the search index was still holding the old slug. Check 3 identified this as the cause. Rebuilding the index after the rename replaced the stale entry with the current URL, and subsequent search results linked correctly to /how-to-brew.

Example 3: Draft post appearing in search. A post titled "2026 Harvest Preview" was appearing in search results on the Acme Coffee Roasters public site even though it had not been published. Check 1 confirmed the post Status was Draft at the time of the last index rebuild — the page had briefly been Active, got indexed, then was reverted to Draft. An index rebuild after correcting the status removed it from results.

Example 4: Search returning correct page but displaying wrong title. Acme Coffee Roasters updated the page title from "Coffee Shop Menu" to "Our Full Menu — Acme Coffee Roasters" three days before a teammate noticed search still showed the old title in the result snippet. Check 2 pointed to index rebuild lag — the title change had not been re-ingested since the rename. Rebuilding the index updated the result snippet to reflect the new title immediately.

Example 5: Product category excluded from scope. An Acme Coffee Roasters product page for

Ethiopian Single-Origin was Active and correctly saved, but searching "ethiopian" returned 0 results. Checks 1 through 3 ruled out status, index lag, and slug issues. Check 5 revealed that the Products content type was not included in the Search scope — it had been removed during a settings cleanup six months prior and never re-added. Adding Products to the scope and running a rebuild resolved the issue.

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 know when the page or post was last published or edited. If the edit was recent — within the last 10–15 minutes — the index may not have refreshed yet. Waiting a few minutes and retrying is a valid first step. If results are still wrong or absent after 15 minutes, start at Check 1.

If the content you are trying to surface was recently moved between content types — for example, migrated from a page to a product, or vice versa — also make note of which type it now lives under. Type reassignment affects which scope bucket the record falls into.

• Admin access to the page or post you expected to find in search results.
• The public search widget — open the public site in a separate browser tab so you can run test searches and compare results as you work through each check.
• A note of the page title, slug, and status as they currently appear in the admin.

Where to go

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

• Pages — Admin → Pages
• Blog posts — Admin → Blog
• Search settings — Admin → Settings → Search
• SEO fields — found on each page and post edit screen under the SEO tab
• Slugs — found on each page and post edit screen under the URL or SEO tab

All five checks are in the Steps section below. Work through them in order. Stop as soon as you find the cause and run the fix before continuing.

Steps — five checks to restore search results

1. Confirm the record is Active or Published

Only records with a status of Active (pages) or Published (blog posts) are eligible for inclusion in the search index. Records in Draft, Pending, or Trash status are intentionally excluded — they do not appear in search results regardless of how recently they were saved or how relevant their content is to a visitor's query.

Open Admin → Pages (or Admin → Blog for posts). Find the record you expected to find in search. Look at the Status column.

If the status reads Draft, change it to Active or Published, click Save, and then allow up to 10 minutes for the index to pick up the change. Running a manual index rebuild (see Check 2 below) forces the change to take effect immediately, without waiting for the scheduled refresh.

If the status is already Active or Published, the record is eligible for indexing and the cause lies elsewhere. Continue to Check 2.

Notice the Seasonal Espresso Blend row above: Status is Active but the Indexed column reads

Pending — this is a recently published page that has not yet been ingested by the index. Running a manual rebuild (Check 2) brings it in immediately. The 2026 Harvest Preview row shows Draft status and Not indexed — this is the correct state for a post that should not yet be public.

2. Run a manual index rebuild

The search index does not update in real time after every save. It refreshes on a scheduled cycle, and the gap between saving a change and seeing it reflected in search results can be 10–30 minutes depending on your plan and the current rebuild queue.

When you need the index to reflect recent changes immediately, trigger a manual rebuild:

1. Go to Admin → Settings → Search.
2. Look at the Last index rebuild timestamp. If it predates your most recent content changes, the index is stale.
3. Click Rebuild Index Now.
4. Wait for the confirmation banner — the panel will update to show the current timestamp when the rebuild is complete.
5. After the rebuild finishes, return to the public site and run the search that was returning no results.

After the rebuild, check whether the expected page now appears. If it does, the cause was a scheduled rebuild lag — the index had not yet picked up your published content. No further action is needed. Consider whether your team's publishing frequency suggests running manual rebuilds as a routine step after batches of new content.

If the page still does not appear after a successful rebuild, continue to Check 3.

3. Check the page slug for recent renames

Every entry in the search index is tied to a specific slug — the URL path for that page or post. When you rename a slug in the admin, the stored URL on the edit screen changes immediately. However, the search index still holds the old slug until the next rebuild. This means search results can display the old URL for days or weeks after a rename, and clicking that result will take the visitor to a 404 because the old path no longer exists.

To confirm whether a slug rename is the cause:

1. Open the edit screen for the page in question — Admin → Pages → Edit, then look at the Slug or URL field under the SEO tab.
2. Note the slug exactly as it reads now.
3. Run a search on the public site for a term the page should match.
4. If a result appears, hover over or click the result link and check the URL in your browser's address bar.
5. Compare that URL to the current slug in the admin.

If the URLs do not match — the result is pointing to an old path that no longer exists — the index is holding a stale entry. Run a manual index rebuild (Check 2) to replace the old entry with the current slug. After the rebuild, the search result will link to the correct URL.

If the slug matches and no result appears at all, continue to Check 4.

4. Confirm the SEO title and description are filled in

The search index surfaces the SEO title and meta description from each page's SEO settings as the visible title and snippet in search results. When these fields are empty, the index has less information to work with — results may show the raw slug, a generic placeholder, or a truncated excerpt from the page body, none of which are as useful to visitors as a purposefully written title and description.

In some configurations, pages with missing SEO metadata are also ranked lower in result ordering, meaning the page appears further down the list or does not appear at all if the query-match confidence is below the index threshold.

To check and fill in these fields:

1. Open the edit screen for the page — Admin → Pages → Edit.
2. Click the SEO tab (sometimes labeled SEO & Metadata depending on your SGEN version).
3. Look at the SEO Title and Meta Description fields.

If either field is empty, fill it in now:

• SEO Title — use a clear, descriptive title that accurately names the page content (for example, "Seasonal Espresso Blend — Acme Coffee Roasters"). Keep it under 60 characters so it displays in full across search result layouts.
• Meta Description — write one to two sentences that a visitor would find helpful when deciding whether to click the result. Keep it under 155 characters.

After saving the updated SEO fields, run a manual index rebuild (Check 2) to push the metadata into the index. Once the rebuild completes, the search result for this page will show the correct title and description.

5. Confirm the content type is included in the search scope

SGEN's search settings let you configure which content types the index covers — Pages, Blog posts, Products, and so on. If a content type is not included in the scope, no records of that type will appear in search results, regardless of their status, slug, or SEO metadata. This is a deliberate exclusion, not a bug — it is designed to let you narrow search to only the content types your site's visitors most need.

The symptom is distinctive: every record of one specific content type is absent from search results, while records of other types appear correctly. If all blog posts return results but no products do — or vice versa — the scope setting is the likely cause.

To check and update the search scope:

1. Go to Admin → Settings → Search.
2. Look at the Search scope field — it lists the content types currently included in index builds.
3. If the content type you are trying to surface is not listed, add it using the scope controls on that settings screen.
4. Click Save Settings.
5. Run a manual index rebuild (Check 2) to apply the expanded scope to all existing records.

After the rebuild, run a search for a term that should match a record from the previously excluded type. If it appears, the cause was a scope exclusion. Add a note in your admin documentation so future team members know which content types are included.

If the result still does not appear after scope correction and a rebuild, continue to the next section — it is time to contact support.

What success looks like

What to do if it does not work

If you have worked through all five checks and the expected content still does not appear in search results — or still appears incorrectly — collect the following before contacting SGEN support:

1. The page or post title and current slug, exactly as shown on the edit screen.
2. A screenshot of the public search results page showing what did or did not appear when you searched.
3. A screenshot of the Search settings panel showing the Last index rebuild timestamp, the current scope, and any excluded slugs.
4. The time of your last manual rebuild attempt and whether the rebuild confirmation banner appeared.
5. If the result appears but links to a wrong URL: the URL shown in the result and the correct current slug side by side.

When you contact SGEN support, confirming that you ran a manual rebuild, what the scope includes, and whether the affected records are Active or Published will route your report to the right team. An index rebuild that completes without error but still excludes a specific record points to a record-level flag or a data integrity issue that support can inspect directly from the server side.

Quick reference — the five checks

Common root causes at a glance

Index rebuild lag is the most frequent cause overall. The index refreshes on a schedule, and pages published or edited shortly before a visitor searches may not yet be ingested. A manual rebuild from Admin → Settings → Search resolves this in under two minutes. It is worth making manual rebuilds a standard step after publishing a batch of new content — particularly before a campaign launch or seasonal update where visitors are expected to search for specific new pages.

Slug rename without a rebuild is the second most common. Renaming a slug updates the record in the admin immediately, but the search index holds the old slug until the next rebuild. Visitors who click a search result pointing to the old slug land on a 404. Always run a manual rebuild after any slug rename if the correct URL needs to appear in search results the same day.

Draft status accounts for a smaller but consistent portion of reports — often because a status was accidentally set to Draft during an edit session, or because a post was created but never explicitly published. The fix is a Status change plus a rebuild.

Scope exclusion tends to be a one-time discovery: a content type was removed from scope during a settings review and no one noticed until a visitor reported missing results for that type. Once the scope is corrected and a rebuild runs, all records of that type are indexed going forward.

Frequently asked questions

The rebuild completed but the page still does not appear in search. What next? After a confirmed rebuild, open the page edit screen and check two things: first, that the Status is Active or Published; second, that the SEO Title and Meta Description fields are filled in. An empty SEO title can cause a record to index without a usable title token, which may prevent it from matching queries. Fill in both fields, save, and run another rebuild.

My search returns results for old, deleted pages. How do I remove them? Deleted or trashed records should be excluded on the next scheduled rebuild because they are no longer Active or Published. If deleted pages persist in results, run a manual rebuild. The rebuild re-evaluates every record's current status — records no longer Active or Published are dropped from the index during the build.

How often does the automatic index rebuild run? The scheduled rebuild frequency depends on your SGEN plan. You can see the last rebuild time in

Admin → Settings → Search. If the gap between rebuilds is longer than your publishing cadence requires, run manual rebuilds after significant content updates or contact SGEN support to enquire about rebuild scheduling options.

I renamed multiple slugs at once. Do I need a rebuild for each one? No — a single rebuild after all renames are complete will update every stale entry in one pass. There is no benefit to running a rebuild between individual renames. Complete all the slug updates, then trigger one rebuild.

A page appears in search but the snippet shows old body text, not the meta description. This happens when the Meta Description field is empty. The index falls back to extracting a snippet from the page body, which may be outdated or cut off in an unhelpful place. Open the page edit screen, fill in the Meta Description field under the SEO tab, save, and rebuild the index. The snippet in search results will then pull from the meta description you wrote.