Filters that only exist behind a click

This is the most common blocking failure we find: a listing an agent cannot filter, sort or page through from start to finish, because none of those actions has an address it can request.

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. ?f1=42 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.
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: we do not execute JavaScript, so when a labelled control reduces to no address we conclude it is JavaScript-only. That is an inference about the markup, not a demonstration that the filter failed, and we report it as a warning rather than a blocker.

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

The observations about apotek1.no and kicks.no were made by hand on 8 August 2026, against the sites' own pages. What our scanner measures today is narrower than this article describes: it counts labelled controls that reduce to no URL and no form, and reports them as a warning. It does not attempt the customer's task.