Distributors and retailers: URL architecture for a 50,000-SKU catalogue
Google writes that a URL structure that does not meet its requirements leads to inefficient crawling, with extremely high or nil crawl rates. On a 50,000-SKU catalogue, this decision is made before the addresses are generated. Afterwards, it costs a migration.
- Google states that if your URLs do not meet its requirements, it will likely crawl your site inefficiently, with extremely high or nil crawl rates.
- The decision that structures everything is the boundary between what belongs in the path and what belongs in a parameter.
- Facets, those stackable filters that narrow a product list, produce a combinatorial explosion. Six filters with five values generate tens of thousands of addresses for a single department.
- Google expects precise parameter encoding: an equals sign to separate pairs, an ampersand to add them.
- Rebuilding the architecture of an existing catalogue is a full migration, with its redirect plan and its risk. That is why the decision is made upstream.
On this page
What is the path-parameter boundary
The path-parameter boundary is the rule that determines what belongs in the path of an address and what belongs in a parameter. The path carries what durably identifies a piece of content and that you want indexed. The parameter carries what filters, sorts or personalizes a display without creating new content. Placing an element on the wrong side of this boundary is the most expensive decision on a large catalogue, because fixing it requires a migration.
What breaks at 50,000 SKUs
What follows is written for executives and managers of online stores whose catalogue exceeds a few tens of thousands of SKUs: distribution, hardware, parts, furniture, books. At two hundred products, none of these problems shows up.
With volume, it is not technical difficulty that grows: it is the search engine that can no longer crawl everything. It has a limited capacity for your site, and every worthless address it visits takes the place of a useful one.
Google is direct about the consequences of a bad structure. It states that a URL structure that does not meet its requirements will likely lead it to crawl the site inefficiently, which can include extremely high or nil crawl rates.
Both extremes are costly. An extremely high rate consumes your server resources and scatters the engine's attention across worthless addresses. A nil rate means your new products never enter the index, so they never sell through search.
The visible symptom is almost never crawling itself. It is an unusually long delay before a new product appears in search results, sometimes several weeks. On a catalogue that renews itself, that delay is a direct cost: you pay for advertising to sell what organic search should have carried.
The boundary between path and parameter
It is the decision that structures everything else, and it is made in one meeting.
The path carries what durably identifies. The category, the subcategory, the product. These are distinct pieces of content that you want indexed, shared and linked. A path is readable, stable, and it does not change when a customer changes a filter.
The parameter carries what filters, sorts or personalizes. The selected colour, the display order, pagination, the campaign a visitor came from. These are views of the same content, not new content.
| Element | Path or parameter | Why |
|---|---|---|
| Category and subcategory | Path | Distinct content with its own search demand |
| Product | Path | Final destination, shared and linked |
| Brand | Path if it has demand, otherwise parameter | Often searched by name |
| Attribute filter | Parameter | A view of existing content, unless demand is proven |
| Sort and pagination | Parameter | Creates no new content |
| Session identifier | Neither one | Carried by a cookie, the file the site places in the browser, never by the address |
The middle line is the one worth debating. An attribute filter sometimes deserves to move into the path, when the combination has real search demand: "waterproof work boot" is one example, "size-10 work boot" is not. The logic is the same as the distinct-page threshold treated in our article on product variants.
The combinatorial explosion of facets
Faceted navigation is the mechanism that turns a reasonable catalogue into a maze for a crawler.
Take a department with six filters offering five values each. The number of combinations reaches 15,625 addresses, and that calculation still ignores the order in which the filters are applied and the sort options. Multiply by the number of departments and you get millions of addresses for a few tens of thousands of products.
None of these addresses produces revenue of its own. They all present subsets of content that is already accessible, and they consume the crawl capacity your product pages never get.
The answer comes down to three decisions. Choose the handful of combinations that have real search demand and give them their own path. Leave the others as parameters. And actively block the crawling of those parameter combinations, rather than hoping the engine ignores them on its own.
Google reinforced its recommendations on this point in 2025, folding into its main documentation on URL structure guidance that previously sat in a blog post on faceted navigation.
Google's requirements
The official documentation states concrete rules, easy to check and often broken by platforms.
Follow IETF STD 66, the technical standard that fixes how web addresses are written. Characters defined as reserved must be percent-encoded. A French-language catalogue with badly encoded accents produces addresses the engine treats differently from what you believe.
Do not use fragments to change content. Google states that it generally does not support URL fragments. If a filter changes the content after a hash sign, that content does not exist for the engine. The documentation recommends the History API instead, a browser feature that changes the displayed address without reloading the page.
Use standard parameter encoding. An equals sign to separate key-value pairs, an ampersand to add parameters. Brackets and colons are explicitly presented as the approach to avoid.
Carry session identifiers in a cookie. A session identifier in the address creates a unique address per visitor, which multiplies the space to crawl with nothing in return.
The second point surprises many technical teams: a filter implemented with a hash sign works perfectly for the user and simply does not exist for the engine.
Stability beats elegance
An address that never changes is worth more than a perfect address.
Many teams want to include in the path everything that describes the product: category, subcategory, brand, line, manufacturer model. The result is elegant but fragile: every catalogue reorganization breaks thousands of addresses and requires redirects.
A hierarchy of two or three levels is enough in nearly every case. Beyond that, you are encoding into the address a commercial structure that will change.
Two practical rules. Never put in the path information that can change without the product changing: price, stock, a promotion, an internal classification. And avoid making a product's address depend on its position in the tree, otherwise moving a department becomes a migration.
Design for the reorganization to come: it will happen, and its cost will depend entirely on this choice.
What a rebuild costs
The cost of a rebuild is the argument that justifies taking the time upstream.
Redoing the architecture of an existing catalogue is not a fix, it is a migration. You have to establish the mapping between every old address and its new one, produce the redirect plan, test, deploy, then watch indexing for several months.
On a 50,000-SKU catalogue, count on the order of 720 hours across analysis, mapping, execution, testing and monitoring. At $120 an hour, that is about $86,400, not counting the traffic lost during the transition period.
The same decision made before generating the catalogue costs a few hours of meetings. It is the most lopsided ratio in the whole technical domain, and that is why this question belongs in the quote for an eCommerce project rather than being left to the platform.
Four questions get settled in a meeting, before the first line of code.
Which filter combinations have real search demand, verified rather than assumed? Those are the only ones that deserve a path.
How many levels of hierarchy does your catalogue really require, and which ones are stable over five years?
Which parameters exist on your site today, all sources included, including those added by tracking tools? That list is almost always longer than the team believes, and every forgotten parameter costs crawling.
And which rule will block the crawling of worthless combinations, decided at the same time as the structure rather than after the problem shows up?
What to settle before ordering a catalogue
These five questions determine the project's cost and its lifespan. Answering them after launch amounts to financing a migration.
- How many addresses does your site generate today, for how many real products?
- Which parameters exist on your site, including those added by your tracking tools?
- Which filter combinations have verified search demand, not assumed?
- How much time passes between adding a product and its appearance in search results?
- If the current structure forces a migration, who decides when, and on what budget?
The answer that holds up gives a ratio of addresses to products and an indexing delay in days. A vague answer talks about SEO best practices. A vendor who delivers a catalogue without having settled the boundary between path and parameter sells you a platform and leaves you the migration.
Measuring your real address space and settling that boundary before committing to development is part of what we deliver in a paid audit.
What you keep in house: the decision on the boundary between path and parameter, the hierarchy retained, and the trade-off between a costly migration now and a structure that ages badly. What gets delegated: counting addresses and parameters, verifying demand per combination, the redirect plan, testing and indexing follow-up. A business that settles this question in a meeting before generating its catalogue never revisits it. A business that lets the platform decide pays for a migration three years later, on a catalogue that has grown.
The overall view of search is in a complete guide for SMBs and large companies.
Building a catalogue that stays fast and findable as it grows is at the heart of the Attract customers with SEO and AI goal.
Your catalogue exceeds several tens of thousands of SKUs? See our work in eCommerce.
Frequently asked questions about URL architecture
Should the category go in the product's address?
It is a trade-off between readability and stability. Including the category makes the address clearer, but the address breaks as soon as a product changes department. On a catalogue that reorganizes regularly, a product address independent of the tree avoids thousands of redirects. On a stable catalogue, readability wins.
Do parameters hurt SEO?
Not in themselves. What hurts is their uncontrolled multiplication, which creates an address space the engine crawls at the expense of your useful pages. Google asks for precise encoding, an equals sign to separate pairs and an ampersand to add them, and recommends limiting worthless parameters such as session identifiers.
How many levels of hierarchy do you need?
Two or three are enough in nearly every case. Beyond that, you are encoding into the address a commercial structure that will change, and every reorganization becomes a migration. The question to ask is not how many levels describe today's catalogue, but how many will still be valid in five years.
Is a filter implemented with a hash sign a problem?
Yes, and it is the point that surprises technical teams the most. Google states that it generally does not support URL fragments to change content. A filter that works perfectly for the user can therefore be completely invisible to the engine. The documentation recommends using the History API rather than a fragment.
How do you know if your structure is a problem?
Measure the delay between adding a product and its appearance in results. If it exceeds several weeks on an active catalogue, your crawl capacity is being consumed elsewhere. Also compare the number of addresses the engine knows to the number of real products: a ratio above five deserves a review.
Can you fix it without redoing the site?
Partially. Blocking the crawl of parameter combinations and fixing the encoding can be done without a migration and settle a good share of the wasted crawl. Moving an element from the path to a parameter, or the reverse, changes addresses and constitutes a migration with its redirect plan. That second category is the costly one.
- Google Search Central, URL structure best practices for Google Search, official documentation, accessed July 2026. Source of the mention of extremely high or nil crawl rates, the IETF STD 66 standard, the treatment of URL fragments and the expected parameter encoding.
- Google Search Central, What is URL canonicalization, official documentation, accessed July 2026.
- Falia working framework, arithmetic of the combinatorial explosion and of the cost of an architecture rebuild. Volumes and amounts are explicit scenarios, to be redone with your catalogue and your rates.
Geneviève puts the strategy for your engagement into action. She leads all our web development projects: Shopify, WordPress and the new ways of building a site with AI. She manages our team of developers and translates your business needs into technical language. She runs your organic search (SEO), your visibility in AI answers (GEO) and your site's conversion rate optimization (CRO). Her work is at the heart of three goals: Attract customers with SEO and AI, Improve your site's conversion, and Strengthen your visibility in AI answers. With Gabriel, she also builds the landing pages for your advertising campaigns. She writes mainly about SEO, AI visibility and web design.
About Falia →
SEO
Paid advertising
Conversion
AI visibility
Web design