Creating Readable URLs in ASP.NET Web Pages (Razor) Sites
This article describes routing in an ASP.NET Web Pages (Razor) website, and how this lets you use URLs that are more readable and better for SEO.
What you'll learn:
- How ASP.NET uses routing to let you use more readable and searchable URLs.
Software versions used in the tutorial
- ASP.NET Web Pages (Razor) 3
This tutorial also works with ASP.NET Web Pages 2.
The URLs for the pages in your site can have an impact on how well the site works. A URL that's "friendly" can make it easier for people to use the site. It can also help with search-engine optimization (SEO) for the site. ASP.NET websites include the ability to use friendly URLs automatically.
ASP.NET lets you create meaningful URLs that describe user actions instead of just pointing to a file on the server. Consider these URLs for a fictional blog:
Compare those URLs to the following ones:
In the first pair, a user would have to know that the blog is displayed using the blog.cshtml page, and would then have to construct a query string that gets the right category or date range. The second set of examples is much easier to comprehend and create.
The URLs for the first example also point directly to a specific file (blog.cshtml). If for some reason the blog were moved to another folder on the server, or if the blog were rewritten to use a different page, the links would be wrong. The second set of URLs doesn't point to a specific page, so even if the blog implementation or location changes, the URLs would still be valid.
In ASP.NET Web Pages, you can create friendlier URLs like those in the above examples because ASP.NET uses routing. Routing creates logical mapping from a URL to a page (or pages) that can fulfill the request. Because the mapping is logical (not physical, to a specific file), routing provides great flexibility in how you define the URLs for your site.
How Routing Works
When ASP.NET processes a request, it reads the URL to determine how to route it. ASP.NET tries to match individual segments of the URL to files on disk, going from left to right. If there's a match, anything remaining in the URL is passed to the page as path information.
Imagine that someone makes a request using this URL:
The search goes like this:
- Is there a file with the path and name of /a/b/c.cshtml? If so, run that page and pass no information to it. Otherwise ...
Is there a file with the path and name of /a/b.cshtml? If so, run
that page and pass the value
cto it. Otherwise …
- Is there a file with the path and name of /a.cshtml? If so, run that page and pass the
If the search found no exact matches for .cshtml files in their specified folders, ASP.NET continues looking for these files in turn:
- /a/b/c/default.cshtml (no path information).
- /a/b/c/index.cshtml (no path information).
Note To be clear, requests for specific pages (that is, requests that include the .cshtml filename extension) work just like you'd expect. A request like http://www.contoso.com/a/b.cshtml will run the page b.cshtml just fine.
Inside a page, you can get the path information via the page's
UrlData property, which is a dictionary. Imagine that you have a file named
ViewCustomers.cshtml and your site gets this request:
As described in the rules above, the request will go to your page. Inside the page, you can use code like the following to get and display the path information (in this case, the value "1000"):
<!DOCTYPE html> <html> <head> <title>URLData</title> </head> <body> Customer ID: @UrlData.ToString() </body> </html>
Note Because routing doesn't involve complete file names, there can be ambiguity if you have pages that have the same name but different file-name extensions (for example, MyPage.cshtml and MyPage.html). In order to avoid problems with routing, it's best to make sure that you don't have pages in your site whose names differ only in their extension.
WebMatrix - URLs, UrlData and Routing for SEO. This blog entry by Mike Brind provides some additional details on how routing works in ASP.NET Web Pages.
This article was originally created on February 17, 2014