If Your Filters Aren't URLs, Nobody Can Find Them

Filtering is the most common interaction on a catalogue site, and one of the easiest to build in a way that quietly costs you every search it should have won. It usually goes like this.

You have a collection: properties, products, cars, courses, cakes. You add a filter bar, because that is what a collection needs. Clicking a brand narrows the list underneath it. Adding a price band narrows it further. It feels right, it demos well, and everybody signs it off.

Now look at the address bar. It says /collection. It said /collection before the click too, and it will keep saying /collection whatever the visitor does next.

Whatever they are now looking at exists only inside their browser. As far as anything outside that browser is concerned, your site has exactly one collection page, and it contains everything.

This is on nearly every e-commerce site, directory, portfolio and property listing we are asked to look at, and it is usually the largest single thing wrong with them.

What that costs

There's nothing to rank. Somebody searching for a specific marque, a specific era, a specific category in a specific city is running a narrow search. A narrow search wants a narrow page. You have one broad page, so you're competing on the broad term against everyone, and losing the narrow terms to competitors who did make pages.

A crawler can't click. Googlebot renders JavaScript, so it may see the default state, but it isn't going to work through every combination of your filter bar to discover the rest. Most AI crawlers don't run JavaScript at all, so they see the initial HTML and nothing else. Either way, the filtered views aren't discoverable, because there's no link and no address pointing at them.

Nobody can send anyone there. Somebody finds five cars worth looking at and wants to forward the list. They copy the URL, which is /collection, and the person opening it sees everything. That's a shared link that doesn't work, on every filtered site, every day.

The back button lies. Filter, open an item, press back, and you're on the unfiltered list again. It's the single most annoying thing on the web and it comes from the same root cause.

The fix isn't "make every combination a page"

This is where it goes wrong in the other direction, and it's a worse failure than the first one.

Three filters with ten values each is a thousand combinations. Add a sort order and you've got several thousand near-identical pages, most of them thin, many of them empty. That's the faceted navigation explosion, and it wastes crawl budget on a site that had a handful of pages worth indexing.

So the job is to choose. Promote the facets that people actually search for, and leave the rest as query parameters that don't get indexed.

A rule that has held up for us:

• One dimension gets a page. Brand, category, city, era. These match real searches and are worth writing for.
• Two dimensions get a page only where the demand is real. "Brand plus model" usually is. "Brand plus price band plus colour" almost never is.
• Everything else stays a query parameter, with a canonical pointing back at the one-dimension page it belongs to.

The important half of that is the last line. Query parameters are fine. Query parameters that generate indexable duplicates of a page you already have are the problem, and a canonical tag is how you say which one counts.

A promoted facet has to earn it

A filtered grid with the same heading as the page above it isn't a page, it's a view. If you're going to make a facet indexable, it needs its own title, its own H1, and a couple of paragraphs that are actually about that thing.

That sounds like a lot of writing, and it is, which is exactly why you promote ten facets rather than a thousand. On a specialist car catalogue the ones worth promoting are what a buyer actually searches: the marque, the era, roughly what they are prepared to spend. Each of those has something specific to say on a page of its own. A colour filter does not, and it stays a parameter.

The same mistake wearing different clothes

Once you've seen it, it turns up everywhere:

• "Load more" buttons where results two through ten only exist after a click. Paginate with real URLs, or render everything if the list is short enough.
• Tabbed content where each tab's contents are generated on demand. That's the rendering version of this problem, and it's worth keeping the two separate in your head: that one is about whether the text is in the HTML, this one is about whether the view has an address.
• Maps and store locators where every location is a pin on a canvas and none of them is a page. "Plumber in Streetsville" can't match a pin.
• Modal detail views that show a product over the top of the list without changing the URL.

The check takes ten seconds. Use your own site the way a customer would, watch the address bar, and notice every point where the content changes and the URL doesn't. Each one of those is something you built that nobody outside the browser can reach.

What nobody can tell you

There is no clean before-and-after traffic chart for this, and you should be wary of anyone showing you one. Sites that get it right tend to get it right at launch, so there is no earlier version to measure against. Sites that fix it later almost always ship several other changes in the same release, so the number belongs to all of them.

What can be said plainly is structural: a filter that's a URL is a page that can be linked to, crawled, shared, ranked and cited. A filter that's component state is none of those things. That holds whether or not somebody can attribute a percentage to it.

Faceted browsing is one of the places where the front-end decision and the search outcome are the same decision, which is most of the reason we do web design and development and AI SEO as one job rather than handing a finished site to somebody else to optimise. If you've got a catalogue, a directory or a listings site where the filters live in JavaScript, that's usually recoverable without a rebuild.