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
Related
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.
When I view sites in other languages, their URLs either change to http://ru.wikipedia.org for example or http://somesite.com/ru/.
I think in first example they use third-level domain, in the second they use root subdirectory (folder).
So I am interested: is there any difference? how do these structures work and why do they exist?
I remember three reasons why I went away from the third-level domain solution:
You have to explicitly take care about cookies. They have to be set for the top-level domain to be shared between all domains.
Also you have to ensure that you are referencing all assets (images, css, javascript) absolutely to leverage browser caching.
It's just guessing (I'm not an expert in this area) but you are also influencing search engine relevancy as the third-level domains won't count in the second level domain that much.
ru.wikipedia.org - The 'ru' here is a subdomain. This acts as a redirect to another location. In most cases this is a subdirectory on the site, but it is also used to redirect to any other URL.
somesite.com/ru/ - The 'ru' here is usually a subdirectory, but it can also be a RESTful web service. Twitter is a good example of a RESTful web service (a subdirectory doesn't exist for each user, but the content is dynamically created at runtime).
Subdomains such as ru.wikipedia.org are usually used for subsites - such as the Russian version of Wikipedia.
In my first attempt at an MVC web application I have a fundamental question:
Suppose I have a webshop that has "articles". The administrator of the site will have to view, add, edit and possibly delete these articles, so I guess I could create routings/URLs like this:
/articles/view/
/articles/add
/articles/edit/3
But viewing articles is not just for the administrator of the site, but also for the visitors. The most obvious URL wouls also be /articles/view/. So what is the best practice way of differentiating between URLs for the administrator and for the visitors? (and IS there a best practice way?) Should I do this:
/maintenance/articles/view - for the administrator
/articles/view - for the visitors
Or is it better to serve them the same URL and give them a different view, based on whether or not they are logged in or not?? Are there any specific advantages to using one over the other,or is it just convention?
Thanks,
Erik
It kinda depends on how your site is structured.
If you have a strict distinction between CMS (for site maintenance ) and public page, then your routes, most likely, will have completely different routing schemes for each part. They might even be mapping two separate applications.
On the other hand. If you want to create administration interface, which is integrated into the public site ( something along the lines of Inplace Editors ) then you will be using exactly the same routing scheme as public page, and your authorization level ( are you a visitor or admin ) will be determined on serverside.
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/
What would be a good way to handle URLs on a website that offers multiple languages, but has one primary language (in my case, English).
What should be the address of the home page in English? http://example.com/? http://example.com/en/? http://example.com/english/? Other?
What should be the address of the home page in another language, say, German? http://example.com/german/? http://example.com/de/? http://example.com/deutsch/?
Would the use of language-specific subdomains be appropriate? What would you do and why?
It kind of depends on the structure of your site:
If every language is considered a completely different site, use sub-domains for the language.
This is because different sub-domains is considered different sites by many technologies. Wikipedia does this (http://de.wikipedia.org/) to separate content for different languages entirely.
I wouldn't recommend you to choose this option unless your site is very big.
If every language has its own structure, but is still considered to be versions of the same site, use a top-level "directory" for languages.
For the sake of consistency, I would say that you should also have one for the default language (and omitting it would cause a redirect to the appropriate structure.) I would recommend you to use /en/, /de/, etc. since it's short and concise, and also the standard way of indicating languages.
This is probably your best bet.
If the structure of the site is identical no matter what language it is, and only content on the pages changes depending on the language, you could also consider putting the language modifier as a parameter: /home?lang=en
Google does this, for example: http://www.google.com/search?hl=de&q=foo (they also separate languages by TLD, though.)
Away from the question of how the international URLs should be styled (as that has been covered adequately already)...
One thing that I would personally do is make the site's 'main' domain (i.e. http://example.com) redirect the user appropriately depending on the Accept-Language HTTP header passed by the browser. This is what google.com does, for example.
If you do this, however, make sure that it's possible to switch to another language easily - and save the settings via some other mechanism to allow persistent override (cookies!).
What should be the address of the home page
Would the use of language-specific subdomains be appropriate?
How you like it, doesn't really matter. Design it to be intuitive to the users.
Language names encrypted in URLs won't matter for SEO because nobody will be searching for "en", "de". The names of the products you're offering however will matter very much, because people will be searching for products like "gifts" or "geschenke".
I think that the better stylish solution is to use the address in the format http://yourdomain.com as the home page URL, and identify the localized web pages with ISO 639-1 language codes