ParticleSearch 2026-07-2929 min read

ParticleSearch Catalog Health: How to Know Shopify Search Is Ready to Trust

Catalog health is the difference between a search result you can evaluate and a result you can only speculate about. A storefront may load, a search request may return products, and the dashboard may show activity while the live catalog is missing products, carrying stale fields, or receiving no future updates.

ParticleSearch treats readiness as a set of observable contracts: storefront, catalog index, Shopify connection, and webhook delivery. The goal is not to produce a flattering green score. The goal is to tell a merchant whether a missing result belongs to assortment, source data, eligibility, synchronization, presentation, or relevance.

Product contract checked July 29, 2026. The guide describes the merchant-visible health, catalog, deployment, and query-review surfaces in ParticleSearch. It does not claim that a healthy index makes every product record or every search result good.

The short answer

Call the catalog ready only when coverage, freshness, and storefront evidence agree

Use health before relevance. If the catalog is incomplete or the storefront is unverified, a ranking or synonym change is solving the wrong problem. If health is stable and the same query still produces a poor buyer outcome, you now have a meaningful relevance or presentation review.

Readiness has a boundary. It means ParticleSearch can make a trustworthy observation about the configured store at the time of the check. It does not mean Shopify data is perfect, the assortment is complete, or a result will convert.

Healthy enough to test

The catalog is current enough, the runtime is live, and the team can run a fixed query set without confusing a system defect for a store-data defect.

Not ready to judge

A failed sync, missing products, stale delivery, or unverified theme means the next search result has an ambiguous cause.

ParticleSearch operational signals chart showing passing, warning, failed, and unknown health checks alongside the next review item — A useful health summary does more than colour a score. It shows the mix of passing, warning, failed, and unknown checks, then points to the smallest evidence gap to close next. Counts in this demo capture are time-specific.

Chapter 1 · Four health domains

Each health domain answers a different failure question

A single score hides the repair path. ParticleSearch groups checks by the surface they describe so the merchant can move to the right owner instead of treating every warning as search relevance.

Storefront

Can the published theme run search for a real shopper?

Visible checks: Theme embed, runtime, configuration, and smoke search

A catalog can be perfect and still be invisible if the published storefront is not running the app.

Catalog index

Does the live catalog contain the products the store intends to expose?

Visible checks: Coverage, freshness, dependency health, parity, and deployment state

Search quality cannot be judged against products that are missing, stale, or not eligible for discovery.

Shopify connection

Can configured capabilities read the Shopify resources they depend on?

Visible checks: Permissions shown against the capabilities enabled for the store

A missing permission has a different repair path from a weak result set or an incorrect product field.

Webhook inbox

Can product and store changes reach the system reliably?

Visible checks: Webhook registration and durable delivery state

Freshness is an operating property. A one-time sync can look healthy while later changes stop arriving.

ParticleSearch Search health overview showing storefront, catalog, connection, and delivery signals — The health overview puts operational evidence before tuning. This is a dated demo capture, so the counts, timestamps, and warning state describe that store at that moment, not a promised baseline for every merchant.

Step 1 · Check visibility

The catalog starts with the products Shopify says shoppers may discover

ParticleSearch follows Shopify’s product visibility boundary for active storefront discovery. Active products published to the Online Store can be eligible. Draft, archived, unlisted, unpublished, or intentionally hidden products should not appear in the active catalog. That is a safety property, not a search failure.

When a known item is missing, begin in Shopify. Confirm that the product is published to the Online Store, that the intended variant is available, and that the store has not marked it as direct-link-only. Then return to ParticleSearch and check whether the record is included in the current catalog. Only after those checks pass should you inspect field coverage or matching.

State	What it means	First owner
Active and published	Eligible for storefront discovery	Catalog owner
Draft or archived	Not an active shopper record	Shopify admin owner
Unpublished or hidden	Excluded by visibility intent	Shopify admin owner
Eligible but missing	Sync or catalog coverage review	Search operator

ParticleSearch storefront health checks showing app connection, search key, catalog, theme embed, script, and fallback status — Storefront checks separate “the app is connected” from “a shopper can actually run a search.” A needs-confirmation state is a prompt to test the published theme, not evidence that the catalog or relevance model is wrong.

Chapter 2 · Read coverage correctly

Indexed percentage is a starting signal, not a quality verdict

The catalog view puts indexed products, searchable products, missing products, repeated coverage reviews, and products with search activity next to one another. Those values answer different questions. “Indexed” asks whether a record is present. “Missing” asks whether an expected record is absent. “Coverage reviews” asks whether shoppers repeatedly encounter thin or empty responses. “Products with activity” asks whether returned products are receiving a downstream action in the selected window.

Do not turn those values into an invented health benchmark. Record the baseline for your store, identify which products matter commercially, and compare the same values after a source-data or sync change. The useful trend is store-specific.

Indexed

Is the record present?

Next question: Coverage

Missing

What should be present but is not?

Next question: Sync or visibility

Coverage reviews

Which repeated queries are thin?

Next question: Assortment or fields

Product activity

Which returned items received action?

Next question: Handoff or relevance

ParticleSearch catalog index health showing live catalog, search engine, Shopify catalog, catalog parity, and variant availability checks — The catalog view makes the coverage question concrete. A warning on the live index can coexist with a responsive search engine, which is why the repair starts with the catalog deployment and freshness evidence.

ParticleSearch insights showing no-result, no-click, and narrow-result search patterns — A repeated no-result or narrow-result insight is evidence to inspect, not a reason to change ranking immediately. Compare it with catalog visibility and the actual product set first.

Step 3 · Inspect the record

A present record can still be the wrong record for the query

Use a real query and trace the intended product through the source catalog, searchable fields, result card, destination, selected variant, and cart. The point is to find the first place the buyer’s identity is lost.

Is the product meant to be discoverable?

Inspect

Published status, Online Store availability, direct-link-only intent, and hidden flags

Interpret

If the answer is no, an empty search result is expected. If the answer is yes, continue to record-level checks.

Is the record present in the current catalog?

Inspect

Indexed count, missing count, sync status, and the current catalog deployment

Interpret

A missing record is a coverage or sync issue, not a ranking issue.

Does the record contain the identity buyers use?

Inspect

Title, SKU, barcode, model, options, compatibility language, and structured fields

Interpret

A record can be indexed and still be hard to find when the useful identity is absent or inconsistent.

Does the result hand off to the right sellable item?

Inspect

Product card, product page, selected variant, availability, and add-to-cart state

Interpret

A result that opens the wrong product or variant is a handoff defect even when retrieval looked successful.

Chapter 3 · Catalog deployments

A rebuild should protect live search while it is being validated

Catalog changes need history. ParticleSearch exposes deployment states so a merchant can tell whether a candidate catalog is being built, validated, live, previous, rolled back, or failed. The important behaviour is the boundary between “candidate” and “live”: a rebuild should not replace the validated version while the new version is still being checked.

If a rebuild fails, keep the last validated catalog serving shoppers. Fix the underlying source or permission issue, rebuild again, and compare the same protected queries. This makes catalog recovery reversible rather than an irreversible leap into an unknown state.

Deployment state	Meaning	Merchant action
Building	A separate catalog version is being prepared.	Wait for validation. Live search stays on the current version.
Validating	The new version is being checked before it can serve shoppers.	Do not compare a partial build with live search.
Live	The validated catalog version is serving live search.	Run the acceptance queries and record the version date.
Previous	The version remains available as deployment history.	Use it to understand what changed, not as a second live source.
Rolled back	Live search returned to the previous validated version.	Investigate the failed change, then rebuild when the source issue is understood.
Failed	The candidate could not become a validated live version.	Keep the last validated version live and resolve the failure before retrying.

ParticleSearch webhook inbox and catalog recovery sections showing durable delivery and live and previous catalog versions — A deployment history is useful only if it explains what is serving now and what can be recovered. The dated demo capture shows a live version beside previous versions, plus the webhook delivery state that feeds future catalog changes.

ParticleSearch catalog recovery controls for building a fresh version and restoring a previous version — Rebuild and restore are explicit operating actions. Build after a meaningful catalog change; restore only when the current version is visibly wrong and the previous version is the safer known state.

Chapter 4 · Diagnose the first divergence

Choose the repair from the first layer that disagrees

The same storefront symptom can have different causes. These paths keep the diagnosis narrow and protect the buyer from a plausible but wrong fix.

A known SKU returns nothing

Start with: Check Online Store eligibility, product and variant coverage, then the identifier field in Shopify.

Avoid: Do not add a synonym for a product that is absent or incorrectly published.

Then: Run the same exact query in the live storefront after the record is eligible and indexed.

A broad category has too few products

Start with: Inspect the actual result set, category values, product visibility, and variant eligibility.

Avoid: Do not boost products to hide missing assortment or inconsistent category data.

Then: Repair the catalog or choose a filter and layout that help a buyer narrow a real set.

Products appear, but the wrong variant is handed off

Start with: Compare the result card, product page, selected option, availability, and cart line.

Avoid: Do not treat a product-level click as proof of variant-level correctness.

Then: Keep the query in the acceptance set until the complete handoff passes.

Results changed after a catalog update

Start with: Check webhook delivery, deployment history, freshness, and the source product edit.

Avoid: Do not immediately publish a ranking rule when the live catalog version is uncertain.

Then: Re-run a protected query set after the catalog is validated and live.

Chapter 5 · From health to useful search

Health is the gate. The query is still the proof.

Once health is stable, run the same query set through the live storefront. For a known item, verify identity and variant handoff. For category discovery, inspect the breadth and the path to narrow. For an empty query, confirm the state is honest. For a repeated low-click query, compare the result set with the product card and action path before changing ranking.

That is the boundary between operational quality and relevance quality. ParticleSearch can tell you that a catalog is current and a storefront is live. The merchant still decides whether the assortment, wording, result order, filters, and product handoff are good for the business.

Use health to decide what not to touch. A clean visibility and deployment state is valuable because it prevents a merchant from applying a ranking, synonym, or redirect rule to compensate for a missing or stale catalog.

Final checklist

A catalog is ready to trust when another person can reproduce the decision

Record the visible and indexed product baseline.

Confirm Shopify visibility for the products that matter.

Check identifier, option, availability, and compatibility fields.

Confirm the published theme runtime and run a smoke query.

Review webhook and deployment history after a product change.

Run protected exact, discovery, filter, recovery, and empty queries.

Assign an owner for source data and an owner for search review.

Document the next repair and the evidence that will prove it.

If the checks pass, move to the ParticleSearch analytics review loop and the query-tools guide. If they do not, resolve health before trying to make the results look better.