I'm trying to generate SEO-friendly URLs for a set of exposed filters. For e.g.:

/analyst-relations/firm?related_firm=5072 would look like


one way I imagined doing it was by adding/updating/deleting this path programmatically to the path_alias table upon creation/modification/deletion of the relevant term or entity. However I seem to have misunderstood how path_alias works. I was able to successfully add the path /analyst-relations/firm?related_firm=5072 and the alias /analyst-relations/firm/forrester, but the exposed filter links still load like the former. Is the path_alias table not queried for all URLs? If not, is it possible to somehow 'attach' this path and alias to an entity?

EDIT: I'm using Better Exposed Filters to exposed the filters as links, so afaik there is no form submission

  • 2
    Wasting your time, the Google spider/crawler isn't going to fill out your exposed filter form and then index that.
    – No Sssweat
    Apr 30, 2020 at 20:59
  • Even if its misplaced, this is a project requirement so I don't have much of a choice
    – plambre
    Apr 30, 2020 at 21:01
  • 2
    Enjoy the pointless implementation, Changing url of exposed filter
    – No Sssweat
    Apr 30, 2020 at 21:09
  • I found this awhile back, was hoping something might have changed over the past 8 years
    – plambre
    Apr 30, 2020 at 21:13
  • 2
    Not to pile on or anything, but this is almost definitely a waste of time. The most up to date SEO advice, which hasn't changed for years in this case, is to add rel=nofollow to links that filter lists of content, and even meta canonical and noindex tags to the filtered pages themselves. This helps to avoid duplicate content penalties, and allows search engines to be more confident that they've chosen the "correct" (read: unfiltered) version of a page to show people. All of this makes the URL completely moot.
    – Clive
    May 1, 2020 at 8:10

1 Answer 1


While @Clive's comment is in most cases correct, from a SEO perspective it can make sense to expose certain filters as links and make them searchable through Google. Path aliases are implemented in AliasPathProcessor. Since the core alias lookup system can't handle query parameters and you can alias without a lookup table by querying the entity data directly, you could add your own path processor. Inbound you have to change the path to the internal path and add the query parameter to the request, outbound vice versa (but use $options to remove the query parameters because this is for all outgoing links, don't use the request).

  • Thanks @4k4 I'm exploring this now. Would this be an additional AliasPathProcessor that only runs on the URLs in question, or would this be a new AliasPathProcessor that extends and replaces the existing one? In the former case I imagine constructing and calling it in an EventSubscriber after matching on the request URI. Thoughts?
    – plambre
    May 6, 2020 at 20:02
  • No, you don't need to replace the core AliasPathProcessor, just add your own and catch paths you are interested in. It's not an event subscriber but a tagged service path_processor_inbound/path_processor_outbound. Check core.services.yml and you get the idea how to put the service in mymodule.services.yml.
    – 4uk4
    May 6, 2020 at 21:00
  • It appears I implements InboundPathProcessorInterface, OutboundPathProcessorInterface and add this in services.yml: ` tags: - { name: path_processor_inbound, priority: 100 } - { name: path_processor_outbound, priority: 300 }` Does that make sense 4k4? It appears to be firing on any page load now without explicitly executing it somewhere
    – plambre
    May 7, 2020 at 17:34
  • Yes, this is OK. Now you can check the path for /analyst-relations/firm/*, process the path and set the query parameter. Similar to PathProcessorFiles::processInbound
    – 4uk4
    May 7, 2020 at 18:38
  • So just to test i did this $request->query->set('related_firm',5366); but the page still 404's. My reasoning for this is because while the query is set, the pathInfo/request URI likely still needs to change (the correct Request would have a path of analyst-relations?related_firm=5366, not analyst-relations/firm/*?related_firm=5366) However $request = Request:Create(...) wont work because its not passed by reference. Any ideas on setting a new pathInfo/requestURI ?
    – plambre
    May 7, 2020 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.