At this scale a bad rule repeats hundreds of times: it lengthens paths to key categories, weakens internal connections and makes regional pages harder to control.
Implemented
Catalog as a graph: categories, products and semantic connections
In a catalog of roughly 1,000 categories, the problem was not a few links but the rules themselves: unnecessary depth, weak connections between related sections, product-page dead ends and rigid regional logic. We changed the catalog architecture as a system.
Case at a glanceInitiated the SEO architecture changes: requirements for depth, semantic linking, Product → Listing links, breadcrumbs and regional indexability.
Affected paths were shortened by up to two hierarchy levels; the catalog gained semantic links, Product → Listing links, richer breadcrumbs, and controlled regional activation. Listing pages can use up to ~20 contextual linking blocks depending on context.
Before
Category→Intermediate groups→Product
After
Category→Contextual links→Product ↔ relevant listings
The catalog stops being just a tree: related commercial pages gain direct paths between each other.
In a large catalog, one bad rule repeats hundreds of times
That is why architecture matters more than a few hand-made links. Depth, breadcrumbs, Product → Listing connections and regional indexability are governed by rules that propagate across the catalog. Changing them alters how users and search engines move through roughly a thousand categories, not just a handful of pages.
Key decision04
Five parts of the solution
The project was not simply “add more internal links.”
Catalog depth
Remove unnecessary intermediate levels on affected paths.
Semantic linking
Connect related categories, tags and listings across the static tree.
Product → Listing
Let product pages link back to relevant commercial clusters.
Breadcrumbs
Use them as structural navigation and linking.
Regional pages
Make city-page indexability configurable rather than automatic.
What had to change
Intermediate groups can help a menu without deserving a separate search landing, while commercially related pages can live in different branches.
Why the catalog tree is not the search architecture
Taxonomy, navigation path and indexable URL space are connected but separate layers.
Tree only
Extra levels and weak cross-branch relationships.
Tree + contextual graph
Shallower paths, semantic connections and product-to-listing links.
How links were chosen
Search relationships, internal catalog semantics and competitor structures were used to identify links that help users continue the decision journey.
Regional SEO became configuration
Regional landings are enabled only where demand, commercial coverage and standalone value justify them, with explicit canonical/indexability rules.
Regional SEO became a controlled configuration
City indexability no longer has to be a rigid consequence of URL structure. Activation can follow demand and commercial value.
~90%: baseline set
The capital and main regional centers form the standard activation layer.
~9%: expansion
Additional major cities are enabled as a managed second layer.
~1%: unique cases
Rare configurations remain exceptions instead of triggering a full automatically generated city matrix.
Demand-driven navigation
Among roughly 25 quick filters, the first 15 can be prioritized by observed demand so navigation follows actual user interest.
Context & measurement
- Context
- Large e-commerce catalog · production work
- Scale / period
- ~1,000 categories · up to 2 levels shallower on affected paths
What to measure next
Useful next measures are crawl depth, internal-link distribution and product-to-listing usage.
Catalog architecture
Facing a similar challenge?
Tell me where SEO is blocked by product, engineering or data.