Taxonomy Facets Supports Faceted Navigation in Static Drupal Exports

Static Drupal exports can retain faceted navigation when each filter state is generated as a separate HTML page. Taxonomy Facets maintainer Dan Kantic explains the approach in a Medium post, while the module documentation describes how taxonomy selections are mapped to server-rendered URLs. Visitors follow ordinary links between pages produced before deployment rather than sending live filtering requests to Drupal. This can reduce the public application surface, but it does not make the wider hosting and delivery stack immune to compromise.

Taxonomy Facets builds its paths from unique taxonomy term aliases beneath a configurable base path, which defaults to /browse. It intersects selections across vocabularies, includes content tagged with descendants when a parent term is selected, and renders facet menus and contextual counts without client-side JavaScript. Each valid filter state receives a canonical URL, allowing the pages to remain crawlable, bookmarkable, and accessible without client-side state.

Static export is optional. The module can also provide server-rendered faceted navigation on a conventional live Drupal site without requiring JavaScript or Search API. Its optional Tome integration uses a separate export submodule to enumerate qualifying filter combinations and pager pages as static HTML files.

Export size is the main operational constraint because the number of possible pages rises as vocabularies and terms are added. The Tome integration provides max_depth and min_results settings for limiting how many filter combinations are exported. Kantic’s demonstration uses 150 recipes, six vocabularies, and 63 taxonomy terms, producing 40,210 facet pages and approximately 41,000 HTML files after pager and content pages are included. Those figures illustrate combinatorial growth rather than a general performance benchmark.

Drupal.org lists Taxonomy Facets 3.3.2, released on 16 July 2026, for Drupal 11 and 12. The project page states that the 3.x branch is a rewrite with different routes and configuration, so sites using the 1.x or 2.x branches must configure it afresh rather than upgrade in place.