Product Fit Finder

Product Fit Finder turns your product attributes into a guided finder: the shopper answers two or three questions — make, then model, then what they need — and lands on the products that actually fit. Every combination gets its own crawlable URL and reads as a full category page, with the same filters, sorting and paging. It runs on a standard Luma storefront and on a headless (Astro) storefront from the same configuration.

Install

Install Product Fit Finder with Composer using your AgenticEcom licence key (find it on your My Licences page — one key unlocks every module you own):

# 1. Register the AgenticEcom repository (once per store)
composer config repositories.agenticecom composer https://repo.agenticecom.net
composer config --global --auth http-basic.repo.agenticecom.net <YOUR-LICENCE-KEY> x

# 2. Require this module
composer require agenticecom/module-product-fit-finder

# 3. Apply it
php bin/magento setup:upgrade && php bin/magento setup:di:compile && php bin/magento cache:flush

Have the whole platform?

Install every module in one command with composer require agenticecom/suite — see Install the complete suite.

Compatibility

Magento

Open Source 2.4.9 GA (and later 2.4.x).

PHP

Tested on 8.3, 8.4 and 8.5.

Storefront

Standard Luma and headless (Astro) via the synced store config.

Dependencies

None — no third-party libraries.

What a finder is

A finder — a chain — is an ordered list of product attributes. Pick manufacturer, then model, then accessory_type, and the module does the rest: it asks for each in turn, offers only the values that still have products behind them, shows a live count against each option, and ends on the matching set.

Because the questions come from attributes your catalogue already has, a finder stays correct as the catalogue changes. Add a product with a new model value and that model appears as an option; sell out of everything for a combination and it stops being offered.

A dead end is worse than a longer list

Options that would return nothing are never shown, and each option carries its product count, so a shopper always knows what they are walking into before they click.

Build a finder

1. Go to Catalog → ProductFitFinder → Finder Chains and click Add Finder Chain.

2. Give it a code (used in the URL) and a title. The Invitation Label is the wording the shopper sees when this finder is offered on its own — “Find the right radio accessories”.

3. Add a step per attribute, in the order you want them asked, and label each step in the shopper’s language: “Which radio do you have?” reads better than “manufacturer”.

4. Set the scope — the categories this finder searches within. Leave it empty to search the whole catalogue.

5. Choose the store views it runs on, and whether it appears in the header.

6. Save. The finder is live, and every combination it can produce now has its own URL.

Scope, redirects and thresholds

Further down the same form:

Category scope

A finder searches inside the categories you name, including everything beneath them — you name the parent, not every child.

Single result

When one product remains, send the shopper straight to it instead of showing a grid of one.

Indexing threshold

Combinations with fewer products than this are noindexed automatically, so thin pages never reach Google.

Remembered selection

Keep the shopper’s machine across pages — “my garage” behaviour — so they only answer once.

Let the catalogue suggest the finders

You do not have to design the first finder from a blank page. Suggest Chains reads the catalogue and proposes finders that would actually work: it looks at which attributes are filled in often enough to be worth asking about, how many distinct values each has, and how they overlap. Accept a suggestion as it stands, edit it, or ignore it and build your own.

This is ordinary statistics over your own products — no AI, and nothing leaves the store.

What makes a good suggestion

An attribute is only suggested when most products in scope have a value for it and it has enough distinct values to narrow anything down. An attribute filled in on a tenth of the catalogue makes a finder that dead-ends, so it is not offered.

Where the catalogue has gaps

A finder is only as good as the attribute data behind it. Fitment Coverage reports, for each finder and each of its steps, how many products carry a value for that attribute and how many are missing one, as a percentage and a bar — so a step sitting at 60% tells you immediately that four products in ten can never be found through it.

Each row links straight to the products missing that value, so the fix is a filtered list to work through rather than a hunt. Coverage is the difference between a finder that finds things and one that quietly dead-ends.

The storefront

Luma

The launcher sits in the header. With one finder configured it opens straight into the first question; with several it opens a chooser so the shopper picks the finder they want, each shown with the steps it will ask.

Headless (Astro)

The AgenticEcom storefront reads the finders from the synced store configuration — no extra API call — and renders the same launcher in the header, a tab in the mobile bottom bar, and the same combination pages. Add the Product Fit Finder block to your header in the page editor; leaving its Chain Code blank offers every finder, or set one to pin the launcher to a single finder.

A combination page is a category page

The result of a finder is not a stripped-back search page. It carries the layered-navigation filters, the sort control, the page-size selector, the grid/list toggle and paging — so a shopper who wants to narrow further can, without starting again.

SEO and AI visibility

This is the part that earns its keep long after launch. Every combination a finder can produce is a real URL — /finder/radio/motorola/dp4400 — with:

• a plain-language answer sentence naming what fits what, which is what an AI assistant quotes;
• structured data for the page and its products;
• a generated FAQ block built from live catalogue data, so it cannot drift from the truth;
• an entry in the sitemap, but only when the combination has enough products to be worth indexing.

Thin pages are a liability, not a win

Generating a page for every combination regardless of stock is how a catalogue picks up thousands of near-empty URLs. The minimum-products threshold exists so that never happens — set it per finder, and the coverage report tells you what falls below it.

Settings

Stores → Configuration → AgenticEcom → ProductFitFinder

Setting	What it does
Enable ProductFitFinder	Master switch for finders, combination pages and the PDP fits section.
Headless Frontend Base URL	On a headless store, the public origin. Every URL the module emits — sitemaps, canonicals, structured data — uses it, so the Magento URL is never exposed. Leave empty on Luma.
Finder Button Label	The wording on the launcher when it offers every finder. A launcher pinned to one chain uses that chain’s Invitation Label instead.
Remember Shopper Selection	Keep the chosen machine across pages.
Combination Landing Pages	Generate the crawlable page per selection.
FAQ Block on Combination Pages	Add the generated question and answer with FAQPage structured data.
Include Combination Pages in Sitemap	List only combinations at or above each finder’s threshold.

Frequently asked questions

Do I need new attributes to use this? No. A finder is built from attributes you already have. New attributes only help if the questions you want to ask are not in the catalogue yet.

What happens when a combination has no products? It is never offered — options that would dead-end are not shown — and the coverage report lists them so you can fix the data.

Does it work on a headless storefront? Yes. The finders are published in the synced store configuration, so the storefront renders them without calling back to Magento.

Is this just search with extra steps? No. Search asks the shopper to know the words; a finder asks the questions the catalogue can answer, never offers a dead end, and leaves behind an indexable page for each answer.