Filters that only exist behind a click

This is the most common blocking failure we find. 37 of the 135 sites in our scan could not let an agent filter, sort or page through a listing from start to finish. 35 could not narrow by a published attribute and confirm at the same time that the item is buyable.

The customer asked for "a waterproof jacket in size L under 3000 kroner". Your catalogue has all three parts. The agent still does not get to them.

Why

An agent does not click. It fetches an address, reads the answer, and fetches another address. So everything it is supposed to be able to do must have an address.

A facet filter built as buttons that change state in the browser has no address. The sort control in a dropdown that fires a fetch behind the scenes has no address. The "show more" button that appends another 24 products has no address. To anyone looking at the screen all of this is obviously available. To the agent it does not exist.

We see three variants, in this order:

• The filter sets no address. The state lives only in browser memory. Copy the address bar, open it in a new window, and you are back to the unfiltered listing. It is the simplest test there is.
• The filter sets an address, but the server ignores it. The address looks right, but the content is assembled by a script afterwards. An agent fetching that address gets the unfiltered listing.
• The facets have no name an agent can understand. We have seen filter.eComFilter1 in production. It is a valid address, but nothing in it says this is "colour" or "size". An agent cannot guess which parameter means "waterproof".

We also see the opposite of a filter: apotek1.no answered every path we tried identically, and the category labels in the navigation carried no href at all. Then there is no route into the catalogue other than clicking.

How to check

The shortest test takes thirty seconds and needs no tools:

1. Open a category page in a browser.
2. Apply two filters and a sort.
3. Copy the address from the address bar.
4. Paste it into a private window.

If you get the same filtered listing, you are fine. If you get the unfiltered listing, or an address with no trace of your choices in it, you have the failure.

Then repeat the test the way an agent does it:

curl -sL "https://yourshop.no/jackets/?colour=black&size=l" \
  | grep -oiE "<a [^>]*href=\"[^\"]*jacket[^\"]*\"" | wc -l

If the number is the same with and without the parameters, the filter is not being applied on the server.

Finally, look for the facet links in the source.

curl -sL https://yourshop.no/jackets/ | grep -oE "href=\"[^\"]*(colour|size|filter)[^\"]*\"" | head -20

No matches means your facets exist only in JavaScript.

What to change

1. Put filter state in the URL. Every combination of choices should have its own address that returns the same listing when opened cold. This is one change, and it fixes most of the problem.
2. Make each facet a real <a href>. Then the agent can discover which choices exist by reading the page, instead of having to guess parameter names.
3. Name the parameters in a language a human can read. ?colour=black explains itself. ?f1=42 does not, and filter.eComFilter1 is worse.
4. Build the filtered listing on the server. The address should not merely exist; it should return the right content in the first response.
5. Make pagination links. ?page=2 as an <a href> is enough. "Show more" that exists only as a button makes the rest of the catalogue invisible.
6. Do not noindex the facet pages that actually matter. Blocking every facet combination to avoid duplicates is common. It also shuts off the one page the agent was meant to land on.

One caveat we put on ourselves: our filter-state and sort checks are among the most inferential in the suite, because we do not execute JavaScript and therefore have to conclude that a control is JS-only when it sets no address. We usually report them as warnings rather than blockers.

How to verify the fix

Take the same address with two filters and a sort, and fetch it with curl, no browser. You should see the right product names and prices as plain text, in the order the sort implies, and a link to the next page. If you can do that, an agent can complete the task the customer gave it.

It is doable. kicks.no puts 61 marked-up products on every listing page. When we tested it by hand on 8 August 2026, ChatGPT and Claude each found a product and its price immediately.

Where these numbers come from

37 and 35 are counts of sites in our own scan of 135 Norwegian sites in August 2026, from the most-common-blockers table in docs/findings.md. filter.eComFilter1 and the observations about apotek1.no and kicks.no come from the same corpus. That corpus is sampling — roughly 8 to 25 pages per site — not a full audit.