Search in Multi-Warehouse Shopify Stores

When a store ships from several warehouses, "is this in stock?" stops being a yes/no and becomes "in stock where?" Shoppers want to search and filter by what's actually available to them, and merchants want to route orders efficiently. Shopify tracks inventory per location natively — but the storefront and search surface far less of that than most teams assume. Here's the honest map of what's built in, what isn't, and how to bridge the gap.

How multi-location inventory actually works on Shopify

Every stockable variant has an inventory level per location (each warehouse, retail store, or 3PL is a Location). Shopify sums those into the availability the storefront shows. So the platform knows the per-warehouse breakdown — the question is how much of it reaches the theme and the search index. The answer: the aggregate does; the per-location detail mostly doesn't, not without help.

What the theme can and can't see

In Liquid you get aggregate availability cleanly, but not a per-location breakdown:

{%- assign v = product.selected_or_first_available_variant -%}
{% if v.available %}
  <span class="in-stock">In stock</span>
  {% if v.inventory_management and v.inventory_quantity > 0 %}
    <span>{{ v.inventory_quantity }} available</span>  {%- comment -%} AGGREGATE, all locations {%- endcomment -%}
  {% endif %}
{% else %}
  <span class="sold-out">Sold out</span>
{% endif %}

{%- comment -%}
  There is NO storefront Liquid object for "quantity at Warehouse B".
  Per-location inventory lives in the Admin API (InventoryLevel), not in
  the theme — so surfacing it requires syncing it somewhere the theme can read.
{%- endcomment -%}

Native search filters on availability — but not on location

Shopify's Search & Discovery app adds faceted filters to collection and search pages, including an availability filter ("in stock"). That's genuinely useful and free. But it filters on the aggregate available boolean — there is no native "in stock at my nearest warehouse" facet. If your requirement is "show me items available from the Berlin warehouse," native search cannot express it. Knowing that boundary up front saves a lot of wasted configuration.

Bridging the gap: three real patterns

• Per-location metafields (lightweight). A scheduled job reads InventoryLevel from the Admin API and writes a compact per-location availability into product/variant metafields (e.g. custom.stock_by_location). The theme then renders "In stock in Berlin, London" from the metafield, and Search & Discovery can filter on a metafield-backed facet. Trade-off: it's only as fresh as your sync interval — fine for "available near you," not for live scarcity.
• Storefront API + a custom search service (robust). Feed a dedicated search backend (Algolia, Searchspring, Nosto) with per-location inventory alongside the catalog. The search service owns the location facet and returns location-aware results in real time. This is the right answer for large catalogs and true per-warehouse filtering — at the cost of a third-party search dependency.
• Geo → location routing (UX layer). Resolve the shopper's region (IP or a chosen store), map it to a preferred Location, and bias display/filters to that location's stock. Pair it with either pattern above so "availability" means "available to this shopper."

Don't forget fulfillment routing — it's the other half

Showing accurate per-location availability is pointless if the order then ships from the wrong warehouse. Shopify's fulfillment location routing (and, on Plus/with apps, more granular rules) should route each order to the location that actually has the stock you advertised. Search accuracy and fulfillment logic have to agree, or you promise "in stock in Berlin" and ship late from London.

A pragmatic decision path

• Just need "in stock" filtering? Use Search & Discovery's availability facet — done, no build.
• Need "available near me," modest catalog? Sync per-location inventory into metafields and filter on them; accept near-real-time freshness.
• Large catalog, true per-warehouse search, live stock? Offload to a Storefront-API-fed search service that models location as a first-class facet.

The mistake in multi-warehouse search isn't technical — it's assuming Shopify surfaces per-location stock to the storefront. It doesn't. Once you accept that the platform knows it but the theme doesn't, the architecture picks itself.WS24 — how we scope multi-location commerce

Multi-warehouse search on Shopify is a solved problem once you draw the line correctly: native availability filtering for the simple case, metafield sync for "near me," and a dedicated search backend for real per-location facets — always paired with fulfillment routing that ships from where you said the stock was.