Magento’s url_rewrite table grows fast because every product can get one rewrite per category it belongs to, per store view, plus a permanent redirect each time a URL key changes. On large catalogs that makes category saves slow. Adobe’s fix is the Generate “category/product” URL Rewrites setting, which keeps only canonical product URLs but deletes existing category paths.
That trade is the heart of this article. The setting can turn a category save that times out into one that finishes quickly, but it is global, it removes rewrites permanently, and it changes which URLs exist for search engines. Below is how the table grows, what each catalog SEO setting actually does, the problems large stores report, and a safe plan for changing course.
Why url_rewrite grows faster than your catalog
Magento resolves friendly storefront URLs through the url_rewrite table. Each row maps a request path, such as womens/tops/linen-shirt.html, to a target, such as a product view, for one store.
Three multipliers drive the row count:
- Category paths. A product assigned to a category can get a rewrite under that category’s path, and under parent category paths, in addition to its short URL. A product in several categories gets several rewrites.
- Store views. Rewrites are stored per store. Adobe’s product URL rewrite documentation notes that if you do not set a specific store view, “a rewrite is created for each view.” Ten store views means ten copies of each path.
- Redirect history. When Create Permanent Redirect for URLs if URL Key Changed is enabled, which is the default behavior, every URL key change leaves the old path in the table as a 301 redirect. Years of product renames accumulate.
A rough sizing formula is products × average category paths per product × store views, plus redirect history. The numbers get large quickly. A 2016 Magento community architecture proposal by Ivan Chepurnyi described a store with only 3,000 products and 200 categories producing a 600,000-record table. The README of an open source rewrite optimizer module, measured against Magento sample data with 189 visible products and 39 categories, reported product rewrites falling from 580 to 189 once category paths were removed.
Your own numbers will differ. Count them directly before deciding anything:
SELECT store_id, entity_type, COUNT(*) AS rows_count
FROM url_rewrite
GROUP BY store_id, entity_type
ORDER BY rows_count DESC;
The four catalog SEO settings that control rewrites
The settings live under Stores, Settings, Configuration, Catalog, Catalog, Search Engine Optimization. Adobe’s catalog configuration reference describes each one.
| Setting | Scope | What it does | Effect on url_rewrite |
|---|---|---|---|
| Use Categories Path for Product URLs | Store View | Includes category paths in product URLs on the storefront | Changes which URL is linked; Adobe warns it can create multiple URLs for one page |
| Create Permanent Redirect for URLs if URL Key Changed | Store View | Creates a 301 automatically when a URL key changes | Adds a row per changed key, per store |
| Generate “category/product” URL Rewrites | Global | Decides whether category/product rewrites are generated and saved | Turning it off removes category paths for products, the biggest reduction |
| Product URL Rewrite Scope | Store view or website | Generates product rewrites per store view or per website | Website scope can reduce duplicates across store views |
Two notes from Adobe’s documentation matter most:
- On Use Categories Path for Product URLs, Adobe warns that it “can cause multiple URLs to point to the same page, which might impact search rank.” If you use it, canonical tags need to be configured carefully.
- On Generate “category/product” URL Rewrites, Adobe notes that saving this data “can degrade performance,” and that changing the option “does not affect how product URLs are resolved,” because the system resolves product URLs regardless.
What happens when you save a category
Adobe’s automatic product redirects documentation explains the mechanism behind slow saves. When a category is saved, “all product and category rewrites are generated in real time and stored in database tables by default.” For categories with many assigned products, Adobe says this can cause “significant performance issues.”
This is why the problem appears suddenly. A store runs fine for years, then a merchandiser renames a top-level category or changes its URL key, and the save tries to regenerate rewrites for every product beneath it, in every store view. Reports from the community describe 504 gateway timeouts on category saves for very large categories, and an older GitHub issue described memory exhaustion when saving categories on a store with two store views, about 16,000 products, and 800 categories.
Adobe’s recommended fix in the same documentation is to skip generation of category/product URL rewrites, so that “product rewrites are generated only for the canonical product URL.”
The catch: turning it off is permanent
Adobe is direct about the cost. Disabling Generate “category/product” URL Rewrites “results in permanent removal of all existing category/product type URL rewrites, which cannot be restored.” It can also cause URL conflicts between categories and products that need manual URL key changes, and the admin shows a confirmation dialog before applying it.
In practice this means:
- Category-path product URLs stop resolving as rewrites. If those URLs are indexed, linked from email campaigns, or used in ads, they need a plan. Check whether they return the product, redirect, or 404 on a staging copy before touching production.
- You cannot undo it by switching back. Turning the setting on again regenerates rewrites going forward, but the removed rows and any custom history are gone. Back up the table first.
- It is global. Every website and store view is affected at once.
For most stores the right end state is still canonical-only product URLs. Short product URLs are easier to manage, avoid duplicate content, and keep the table small. The point is to get there deliberately.
Other rewrite problems at scale
Duplicate URL key errors. “URL key for specified store already exists” blocks category and product saves when two entities claim the same request path in one store. It is common after imports or when products and categories share names. Fix the URL key, not the error handler.
API changes that skip redirects. A GitHub issue on 2.4.6, magento/magento2#39632, reports that changing a product URL key through the REST API does not create the old-to-new 301 redirect that an admin save would. If a PIM or ERP updates URL keys over the API, old URLs can start returning 404 without anyone noticing. Monitor 404s after every sync that touches URL keys.
New store views without rewrites. Older issues report new store views getting no category rewrites until URL keys change, leaving system URLs such as catalog/category/view/id/... in navigation. After adding a store view, spot-check its URLs.
Redirect history that never ends. Old 301 rows are useful while external links and search engines still request the old paths. After a long period, many of them serve no traffic. Before pruning, check server logs or analytics for hits on those paths. Our guide to Magento database bloat covers the other tables that grow without limits; url_rewrite deserves the same scheduled review.
A safe plan for large catalogs
- Measure. Count rows by store and entity type, and record how long saves take for your largest categories.
- Decide on product URL format. If Use Categories Path for Product URLs is on, decide whether you need category paths at all. Most stores do not.
- Back up url_rewrite. Keep a full export so you can rebuild redirects for important old paths.
- Export indexed category-path URLs. Pull them from Search Console, analytics, ad platforms, and email templates. These are the URLs that need 301s if they stop resolving.
- Test on staging. Apply the setting on a copy of production, then crawl the exported URL list and record status codes.
- Create redirects for URLs that matter. Add custom 301 rewrites for paths with real traffic or backlinks.
- Apply in a quiet window. Flush caches, warm the most important pages, and confirm canonical tags point at the short URLs.
- Watch 404s for two to four weeks. Add redirects for anything with meaningful traffic that you missed.
- Regenerate the sitemap. Make sure it lists only canonical URLs. Our guide to XML sitemaps for large Magento catalogs covers the settings that matter.
Storefront themes do not change any of this. Luma, Hyva, and headless frontends all resolve URLs through the same backend table, so a Hyva migration is a good moment to clean up URL structure but does not do it for you. Our Magento 1 to Adobe Commerce SEO migration guide covers redirect mapping when URL structure changes more broadly.
Signs your rewrite setup needs attention
- Category saves take longer than a minute or time out.
- The url_rewrite table has many times more rows than you have products.
- Search Console reports duplicate pages without a user-selected canonical, with category-path product URLs.
- Product imports slow down sharply as the catalog grows.
- 404 reports show old product paths after PIM or ERP syncs.
If several apply, rewrite generation is likely costing you admin time and crawl budget at the same time.
Getting help
Bemeir is a Brooklyn ecommerce agency. Our Magento development services and Hyva development services cover catalog performance, technical SEO, and migrations for Magento Open Source and Adobe Commerce. We also work on Shopify development, Shopware development, and BigCommerce development, which handle URL structure in their own ways. Learn more about Bemeir, see our technology partners, or visit the Bemeir home page.
FAQ
Why is my Magento url_rewrite table so large?
Each product can get a rewrite for every category path it belongs to, in every store view, plus a 301 redirect each time its URL key changes. Those multipliers mean the table can be many times larger than the catalog. Count rows by store and entity type to see which multiplier dominates.
Why does saving a category take so long in Magento?
By default, saving a category regenerates product and category rewrites in real time and stores them in the database. Adobe notes this can cause significant performance issues for categories with many products, especially across many store views.
What does Generate “category/product” URL Rewrites do?
It controls whether Magento generates and stores rewrites that include category paths for products. Turning it off keeps only canonical product URL rewrites. Adobe warns that turning it off permanently removes existing category/product rewrites, which cannot be restored.
Will disabling category/product rewrites break my URLs?
Category-path product URLs can stop resolving, so any that are indexed or linked need redirects. Back up the url_rewrite table, export important old URLs, test on staging, and add 301 redirects for paths with real traffic before applying the change in production.
Does Hyva change how Magento URL rewrites work?
No. URL rewrites are resolved by the Magento backend, so Luma, Hyva, and headless storefronts all use the same url_rewrite table. A Hyva migration is a good time to review URL structure, but the settings and cleanup are the same.
