Routing and URL Configuration
AspDotNetStorefront uses the dynamic routing capabilities of ASP.NET MVC to allow a new level of control over your URLs. Out of the box, you have access to two controls which have a massive impact on how customers, search engines, and other clients see your site. It's important that you understand what these controls do and the impact changing them has on your site, and on search engine results.
What is ASP.NET Routing?
ASP.NET Routing provides the capability to map arbitrary URL's to resources. This is a major leap in control compared to Web Forms. With Web Forms (versions prior to 10.x.x), a URL typically matched one-to-one with a resource on disk, such as an .aspx page. If you wanted to change the URL, you either had to rename the page or set up a URL rewrite rule. With routing, you can instead set up an additional route that maps a new URL to that page. If you remove the old route, the original URL would stop working.
On the surface, routing seems very similar to URL rewriting. The critical difference is that routing maps URLs to handlers, where as URL rewrites map URLs to other URLs that are handled elsewhere. This is important, because in MVC, there are no longer pages or files on disk that can be accessed by a URL. Instead there are classes, called "controllers", with one or more methods, called "actions". Routing is the glue between URLs and controller actions. MVC doesn't work without routing because there is no means for a URL to map to code running in memory.
How Does AspDotNetStorefront Use Routing?
Because AspDotNetStorefront is an MVC application, routing is intrinsic. Every "page" that a user sees is mapped to a URL via a route. These routes are defined in code and are part of the compiled DLLs.
AspDotNetStorefront ships with two different routing schemes: one with new, modern style URLs and one with URLs which match most AspDotNetStorefront URLs from version 18.104.22.168.
The legacy routing scheme looks like previous versions of AspDotNetStorefront:
The modern routing scheme uses the controller, action, and identifier to build a URL without an extension:
For a more comprehensive list of new URLs vs old URLs see Mvc Link Reference.
How Can AspDotNetStorefront's Routing Be Configured?
Routing can be controlled with two new GlobalConfig Parameters: "UrlMode" and "EnableSeNameOnlyUrls". These parameters affect how URLs are generated and recognized.
"UrlMode" has three options: Modern Only, Legacy Only, and Modern with Legacy 301 Redirects.
AspDotNetStorefront will always recognize modern-style URLs, regardless of the UrlMode setting. When "Modern only" is selected, only modern URLs will be generated and recognized. This mode is intended for new stores and is the default scheme moving forward.
In "Legacy Only" mode, AspDotNetStorefront will recognize and generate common URLs like it did in version 9.x. Note that modern URLs will be generated for resources that didn't have a corresponding page in 9.x. This mode is the default for upgraded stores. It exists to provide the greatest compatibility with existing URLs.
If you want to move your store from legacy URLs to modern URLs, use the "Modern with Legacy 301 Redirects" mode. This mode allows AspDotNetStorefront to recognize the legacy URL scheme, but it will always reply with a 301 redirect to the corresponding modern URL. This will allow existing links to continue working while moving all of your content forward to the new URL style.
Here's a table that summarizes what kinds of URLs are recognized and generated with each mode:
|URL Mode||Recognizes Modern URL's||Generates Modern URL's||Recognizes Legacy URL's||Generates Legacy URL's|
|Modern with Legacy 301 Redirects||✓||✓||✓**||
* Legacy Only mode will generate modern URLs if there is no corresponding legacy URL
** Modern with Legacy 301 Redirects mode will always recognize legacy URL's, but it rewrites them to the corresponding modern URL with a 301 redirect
The other GlobalConfig parameter that controls routing is "EnableSeNameOnlyUrls". If EnableSeNameOnlyUrls is set to "false", products and entities will include their ID number in generated URL's. If EnableSeNameOnlyUrls is set to "true", products and entities will not include an ID number in generated URL's.
|EnableSeNameOnlyUrls Enabled||EnableSeNameOnlyUrls Disabled|
Note that the EnableSeNameOnlyUrls setting has no effect when the "UrlMode" GlobalConfig parameter is set to "Legacy Only".
For this feature to work correctly, every product and entity must have an SE Name, and that SE Name must be unique within that entity. You must ensure that:
Every product and entity has the SEName field populated in the database. This field will always be populated when a product or entity is created or edited within the admin console, but may not be populated if products or entities are being directly inserted into the database. If a product or entity does not have an SEName in the database, then it will never be reachable via SEName-only URLs.
Every product's SEName must be unique among all products. The same is true for every category's SEName among all categories, manufacturer SENames among manufacturers, and so forth. If an SEName is not unique among its type, then only the first record with that SEName will be reachable via SEName-only URLs.
To help you verify your data, you can run the "SEName Report" in the admin console. It will inform you if you have missing or non-unique SE Names in your store data.
When Is It Safe to Change My Routing scheme?
Routing schemes should be changed carefully and infrequently. Generally, you should decide before going live what routing scheme you will use. For new stores, you should use the "Modern Only" URL mode. For upgrading stores, you should test the "Modern with Legacy 301 Redirects" mode, which will allow existing links to your site to work while moving your forward in to the new style. If the modern URL's are undesirable or you find that the 301 redirects cause problems, you can use the "Legacy Only" mode. Be aware that this is provided for backwards compatibility and may be deprecated in the future.