Suggestion: SEO-friendly layered navigation (facet landing pages)

[hirale]

The problem

Maho's layered navigation works fine, but the URLs it produces are query strings keyed by option IDs:

/t-shirts.html?color=45&size=12

Google mostly doesn't turn these into ranking pages — faceted navigation docs . Their words: crawlers "access a very large number of faceted navigation URLs before the crawlers' processes determine the URLs are in fact useless," and "if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs." So the ?color=45 form either gets ignored or quietly eats crawl budget. Either way you don't get a landing page for "black t-shirts" out of it.

Two routes, both with a catch.

1. Make a real category for the attribute value and assign every matching product to it:

/t-shirts/color/black.html   ← a category, backed by catalog_category_product rows

Clean URL, but now merchandising (categories) and faceting (filters) are tangled together. The tree bloats with a node per color × size × brand, membership drifts away from the attributes unless something keeps re-syncing it, and combinations don't scale.

2. Buy a third-party layered-nav SEO module. On M1 the usual ones are Amasty Improved Layered Navigation, Mirasvit Advanced SEO Suite (their SEO Filters feature), and Manadev SEO Layered Navigation Plus. They do the job, but they're built on the old Zend/Varien/prototype stack — not really aligned with where Maho is heading. And it's not a magic fix anyway: Google warns that directory-style facet URLs recreate the same duplicate-content mess if the filter order isn't stable, so a naive rewrite can make things worse.

The idea

What if Maho served the clean URL without creating a category or assigning any product — resolve the facet straight from the attribute at request time?

/t-shirts/color/black.html   ← resolved on the fly to a filtered catalog layer view

Categories own the taxonomy, attributes own the faceting, each gets its own URL space. And the things Google asks for in that same doc — stable filter order, no duplicate filters, a 404 when a combination has no results — become something the platform can guarantee, instead of something every store re-solves with a different module.

If this resonates, I'm happy to take a crack at it and open a PR — just wanted to float the idea here first before sinking time into it. And if someone's already chewing on this, even better, point me at it.

[fballiano]

Hi @hirale, did you check #482?

[hirale]

Nice, i am checking it.

[hirale]

Hi @fballiano,

PR #972 now includes a small, behavior-neutral seam so its defensive crawl controls and the facet landing-page work proposed here can coexist. Mage_Catalog_Helper_Category::isLayeredNavigationLandingPage() reads a registry flag, and when that flag is set the three controls from #972 all back off for the current request:

• NOINDEX
• canonical-to-base-category
• rel="nofollow" on filter links

So a future landing-page resolver only has to register the flag for its page to stay indexable — nothing in #972 needs to be reverted or reworked.

That leaves one open question: how should a store decide which facets are eligible to become indexable landing pages?

Rather than a global on/off switch, I'm leaning toward a per-attribute whitelist — a flag on the catalog attribute itself, alongside is_filterable (e.g. "Use in SEO URLs"). Merchants could curate a small set of high-value facets (color, brand, material…) while everything else stays query-string-based and subject to the existing NOINDEX behavior. This matches both the established Magento 1 extensions (Amasty, Mirasvit, Manadev) and Google's faceted-navigation guidance: index a limited set of valuable facets, suppress the rest, and avoid the combinatorial explosion you get when every attribute can generate indexable pages.

One important nuance: the whitelist alone isn't enough. A whitelisted attribute reached through a query-string URL (/shoes.html?color=45) must still be NOINDEX, since it duplicates the canonical clean URL. Only the clean form (/shoes/color/black.html) qualifies for exemption. So the resolver's condition becomes:

whitelisted attribute AND clean-URL request → register the landing-page flag.

A related question is how to handle combinations of whitelisted facets, e.g. /shoes/color/black/material/gold.html. My instinct is to default to single-facet landing pages only: the resolver sets the flag when exactly one whitelisted facet is active, and any second facet falls back to NOINDEX. That needs nothing extra in #972 — with the flag absent, the multi-facet page automatically gets the existing NOINDEX,FOLLOW + canonical-to-base treatment, so it's consolidated rather than indexed as a thin duplicate ("black gold shoes" has a fraction of the demand of "black shoes"). If specific combinations prove valuable, they could be whitelisted as explicit pairs later — with a canonical facet order enforced so /color/black/material/gold and /material/gold/color/black don't become two URLs for the same page.

Does this direction sound right to you — a per-attribute whitelist, single-facet by default — or would you prefer a different mechanism (a single global toggle, or a config field listing attribute codes)? I'd like to align on both the eligibility model and the combination policy before starting work on the resolver in #971.

[jparker1986]

Since switching to Maho, we have noticed a massive increase in our SEO Rankings on Google.