Best-practice URL structures with multiple filter combinations

[digitalcrc]

Hello,

We're putting together a large piece of content that will have some interactive filtering elements. There are two types of filters, topics and object types.

The architecture under the hood constrains us so that everything needs to be in URL parameters. If someone selects a single filter, this can look pretty clean:

www.domain.com/project?topic=firstTopic
or
www.domain.com/project?object=typeOne

The problems arise when people select multiple topics, potentially across two different filter types:

www.domain.com/project?topic=firstTopic-secondTopic-thirdTopic&object=typeOne-typeTwo

I've raised concerns around the structure in general, but it seems to be too late at this point so now I'm scratching my head thinking of how best to get these indexed. I have two main concerns:

1. A ton of near-duplicate content and hundreds of URLs being created and indexed with various filter combinations added
2. Over-reacting to the first point above and over-canonicalizing/no-indexing combination pages to the detriment of the content as a whole

Would the best approach be to index each single topic filter individually, and canonicalize any combinations to the 'view all' page? I don't have much experience with e-commerce SEO (which this problem seems to have the most in common with) so any advice is greatly appreciated.

Thanks!

[digitalcrc]

Thanks for the detailed answer Jonathan. What you suggested was definitely in line with my thinking - indexing just the single topics at most and trying to either noindex or canonicalize all the thousands of possible variations. I definitely agree that all those random combinations of topics/objects hold no real value and at best will eat up crawl budget unnecessarily.

I can make sure Google treats these parameters as URLs via Search Console, they're unique to this piece of content; and I think I can noindex all the random combinations of filters (hopefully).

I'm still waiting to hear more from the dev team but I have a feeling that I won't be able to change the format to subdirectories instead of differentiating everything with query parameters - not the ideal situation but I'll have to make do.

Anyways, thanks again for your thoughtful reply!

Josh

[Jonathan.Smith]

Google is supposed to disregard everything after the ? in the query string when indexing. However, I know at times query strings will get indexed if the content on the query stringed URL appears different enough to Google. So I would  agree with your motive to try to get these dynamic URLs simplified.

From what i have read on similar scenarios, and my first thought is, do these filtered view pages benefit searchers? Typically it benefits searchers to index maybe the category level of pages. In your instance, this may be the first topic. But once URLs start referencing very specific content that one user was filtering for, I would probably suggest a noIndex meta tag. There should be a scalable solution to this so you don't have to individual go into every filtered page possibility and add noIndex to the head.

If there is a specific filtered view you believe may benefit searches, or you have already seen a demand for, I would suggest making this a page using subfolders

www.domain.com/project/firstTopic/typeOne

and noIndexing all the crazy dynamically generated query string URLs. This should allow you to seize opportunities where you see search demand and alleviate any duplicate content risks.

If you don't want to noIndex, I would gauge the quality of these nitty gritty filtered pages, and if you see value in them, I would agree canonicalizing to the preceding category page sounds like a good solution.

I think this article does a good job explaining this. It suggests that if your filters are just narrowing content on the page rather than changing it, to noIndex or canonicalize (Although, the author does remind you that canonicalization is only a suggestion to Google and is not followed 100% of time for all scenarios).

I hope this helps, and if you don't see how these solutions would be implemented on your site, this issue may require some dev help.