I am developing an international web site - multiple countries, multiple languages. I am trying to create SEO friendly URLs.
For example the catalog consists of cartesian product Regions x Categories. A typical catalog url has 7 levels of hierarchy:
www.site.com/en/Catalog/Browse/10/28/London/Category1
The route format is as follows:
"/{culture}/{controller}/{action}/{regionId}/{branchId}/{region}/{branch}"
I have read somewhere that search engines give less relevance to pages deep in the site hierarchy (determined by number of slashes in path). Is this true? Does anybody have info on how much relevance do deep sites lose?
I have thought about simplifying the URLs (making them less deep) by using '-' and '+' as delimiters, so now I have routes like for example:
"/{culture}/friendlyActionPlusControllerName/{regionId}-{branchId}/{region}+{branch}"
ending up with urls still 4 levels deep in "folder" hierarchy.
www.site.com/en/services/10-28/London+Category1
Is using + and - in URLs considered a viable approach? Does this kind of shortening help in SEO? Does anyone see any options for me how to further simplify the URLs?
Additional note: Catalog is going to be the main source of search engine traffic. There are going to be a few content pages as well (with urls like www.site.com/en/Service1) but these two are going to be the only search traffic generators, so I would like to have them optimized as much as possible.
From my experience, I suggest you use the - (hyphenated). If you can keep the number of hyphens to 2 or 3, that is probably the safe route to take. Although I have seen people who go beyond that and it works just as well.
Basically I think if you do it in a way that is purely descriptive of the page content without going overboard, you're okay. However it should also be noted that the more keywords in your url's then the more diverse your page is going to be for Search Engines.
Also remember that keywords in the title, h1, meta data should all match up so the more you have the more difficult this is to manage.
I realise that this does not answer your question 100% and leads to more questions!
There is an open source project that implements shortening URL in aspnet mvc on codeplex, you can get it here:
http://miniurl.codeplex.com/
Related
I will develop tourist site about region. This site will consist of parts about cities in this region. Parts have same design and features. Home page of site will has information from all parts about all cities.
How do I design path structure of site? I saw that some sites for same purpose use prefixes like:
city.region.com
But another sites just add part to URL:
region.com/city
What is the best solution? (from SEO and Rails development points of view)
When you add a prefix to the site name, that is considered a subdomain. Subdomains are considered separate website so If SEO is a goal of yours, you will have a higher chance of showing up multiple times for a search.
On the other hand, I consider it a lot easier to add to the URL. This is the approach I would take, avoiding any premature optimization.
Source : http://www.ameravant.com/article/3398-subdomains-and-seo-pros-and-cons-of-subdomains-vs-subdirectories
How does MVC architecture based URLs aid search engines to optimize searches.
ASP.NET MVC urls follow different pattern compared with the web forms URL pattern. I see this listed as an advantage for search engines to obtain results. I am not able to understand how though.
There are questions on optimization but that is not what i am trying to ask.
this is pretty self-explanatory.
hxxp://www.yourdomain.com/buy/shoes/1337/all-stars/black/vintage
just works better than
hxxp://www.yourdomain.com/buy.aspx?id=1337&cat=5&variant=37
You don't really need an MVC framework to do this tough. URL rewrite can do a lot for you.
A well constructed MVC app will typically have a much more logical sitemap when you look at the urls on different levels.
So, this is both a technical and a SEO question.
Let's say you are developing an e-commerce site and the client requests that you maintain the category path in the structure of the URL. Example:
/electronics/video-games/ps3/nba2k13-p123774
How do you set up a route that will work for this and send things to the product controller regardless of the number of segments before the last segment? Example:
{arbitrary_cat_routes}/{name}-p{id}
Secondly, I understand wanting to get keywords in the URL, but is there a substantial benefit to this? I've heard that content closer to the root of the site receives some SEO preference. Doesn't buring it 3 directories deep wipe out the SEO benefit of having the keywords there?
The ASP.NET MVC routing does not support a catchall parameter anywhere in the URL just on the end. You would need to create a custom Route class that implements this functionality. This blog post summarizes how you would that. To answer your second question, I would avoid having category metadata in the URL, but I'm not super familiar with SEO.
What are some strategies for managing the url routing in a large (100+ controllers and growing) MVC project? Areas has been helpful, but their usefulness seems limited because they can't nest. As the project grows, I've noticed a few big pain points:
SEO-friendly routes (every seo route needs a special definition)
Redirection for legacy routes (need to 301 old urls to the updated equivalents)
Testing routes (is there something better than manual testing and lighter than selenium?)
Also, doesn't performance degrade as the number of routes increases? The way routes are defined suggests performance is at minimum O(n*k), where n is the number of defined routes and k is the length at the url.
A couple of questions to consider that may make this easier for you:
Is there shared functionality between the controllers?
Is there a way to create a generic pattern for your controller and use some of the events raised by a controller to provide generic functionality (i.e. pulling data from a DB in a consistent pattern)?
What is fundamentally different between each controller?
The reason for these questions is that I see a couple of potential solutions:
Assuming you're running on IIS 7 or better, then you could break your functionality into multiple MVC projects for each area. This becomes much easier with IIS 7 and higher (for deployments that is).
Assuming a consistent pattern of presenting your data, a generic controller or route could make this much easier, allowing you to collapse your controllers.
A base controller would allow sharing functionality while presenting the specialization you need for each individual controller.
All in all, I would recommend trying to break your code base into multiple MVC projects, based on purpose, to help establish that sense of sanity which seems to be slipping away as your project continues to grow.
URLs are a user interface, but they are also used to implement the site technically. Compare the following two URLs:
http://example.com/2012/my-article-name/
http://example.com/static/jquery.js
The first is a permalink; part of the "API" if you like. The second is just an addressing mechanism that makes the site work. I might decide to change the second one if I upgrade my site's backend, but I want the first to remain constant for as long as the content at that location exists.
So what are the conventions for indicating that a URL is to be considered part of the site's private technical implementation, rather than part of the public user interface? I've used one above (the word "static"). Another might be an underscore like this:
http://example.com/_/jquery.js
I'm looking for advice, best practice, etc. on this concept.
As far as I know, there is no standard convention for this. And even if there was, I wouldn't bother with it, because:
Who is going to view http://example.com/static/jquery.js?
JavaScript files and "files that make the site work", if you view them, don't display like regular webpages. Users can use that distinction that those files are part of the "technical implementation" of a site.
Visible URL's may be considered part of the user's interface. Just a few years ago, they needed to be unique for every piece of content in the website, or SEO would suffer. Today most search engines support the rel=canonical tag, but still it's a good practice to keep them constant and as logical for the user as possible.