I would like to change the page names of a ASP.NET site to make them more meaningful and more SEO friendly. My new page names with be more descriptive (ex: My_SEO_Friendly_Page_Name.aspx) My question is, is it enough to change the page names for SEO or do I have to implement the URL rewrite.
What are the differences of one over the other?
I think either method workds.
home/blog/this_is_my_entry_page_title.aspx
or
home/blog/this_is_my_entry_page_title
You mainly want to do URL rewriting to avoid using query string parameters. So instead of:
home/products.aspx?qid=25
You would want to use:
home/products/Cell_Phone
Instead of My_SEO_Friendly_Page_Name.aspx use My-SEO-Friendly-Page-Name.aspx for better SEO.
Search engines consider _ (underscore) to be a character and (-) minus sign to be a word-break. More words - more keyword matches.
the result for SEO is the same, it's the implementation that's different.
when you implement url rewrite, any request to http://domain.com/My_SEO_Friendly_Page_Name.aspx will be served with e.g. http://domain.com/index.aspx?id=12 where the 12 refer to the page id in the database, and the page in question has the title 'My SEO Friendly Page Name'
so, this approach is more suitable to implement on large sites which store it's content in a database.
The search engines cannot tell the difference. So one method is not better than the other as far as SEO is concerned. If you implement Url Rewriting, IIS hides the fact My_SEO_Friendly_Page_Name.aspx actually gets mapped to Default.apx?id=1234. To the outside world, it is the same as a page named SEO_Friendly_Page_Name.aspx
If you can use .net 3.5 sp1, don't use rewrite. Use routing.
Routing with ASP.NET Web Forms
One issue you may have is if the existing pages are already indexed by the search engines, if you throw up a whole load of more pages which are in fact just the same then you have a lot of dupe content on your site. To avoid the dupe content a sitemap may help to some degree, you can instruct google to delete pages, or to ignore certain url parameters, which would then delete your old pages that use a url param, or you can get your app to http 301 the old pages to the new one.
You should use 301 redirects, if possible. You can do this in a .htaccess file, however for a large dynamic site it's probably better to use ASP to handle it.
So if you original page was index.aspx?page=52 then your index.aspx script would look up the ID of 52 in your database, find the appropriate "slug" or "alias", say My_SEO_Friendly_Page_Name and set the headers etc in ASP to redirect to that URL.
Related
I have an Episerver site with a JobDetailsPageController with a Index method that takes a jobId parameter and creates a view with some details about that job. The urls looks something like this: https://hostname/<root-depending-on-site-tree>/jobs/?jobid=44.
What I would like is having urls on the form .../jobs/manager-position-telco-44, essentiallly creating a slug of the job title and appending the id. I have done this in the past using standard ASP.NET MVC Attribute Routing on a non-Episerver site, but EpiServer has a routing of its own that I don't know too well and can't figure out.
Also, adding non-query strings after the slash consistently sends me (no surprise) to a 404 page, so I would need to somehow customise this behaviour. I need to use EpiServers standard routing to end up at the right "parent", but ignore the latter part (the pretty bit).
Is it possible to create such urls on a normal page in page tree in EpiServer? I do understand it is possible to create static routes, but this node can be moved around like any other page so I cannot avoid EpiServer.
Please see this blog post. What you're looking for is partial routing.
#johan is right, partial routing is one way of doing this. Just wanted to add other possible solutions that might or might not match your needs.
Import data as content
Instead of serving content dynamically, you could consider importing your job ads from whatever source you have directly in content tree as separate pages below particular root page. That would give you a lot benefits - pages would be cached, it would support multiple languages, editors would see content directly in EPiServer CMS, data could be adjusted manually, etc.
This would be a good solution if your data does not change often and you need to provide a way for editor to create a new job ad manually as well.
Implement you own content provider
Another way to serve your dynamic data to EPiServer is to write your own custom content provider. You can find documentation here: http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/7/Content-Providers/Content-Providers/
This solution requires more coding and is more complex, but it has some benefits as well. If one wanted, it would be possible to not just serve content from external data source, but also update that data by changing values directly in EPiServer UI.
Ok. I hope it's a right question and title.
I'm totally newbie to asp.net and c#. I've been searching the answer for days and got nothing. So i think this is the best place to ask this question.
this is my current URL
http://localhost:7474/mywebsite/ProductDetails.aspx?Category=CSR&artID=36&alias=support-for-central-jaya-and-yogyakarta-earthquake-disaster
I Want to make search engine friendly url. Can I make above URL to
http://localhost:7474/mywebsite/ProductDetails/CSR/36-support-for-central-jaya-and-yogyakarta-earthquake-disaster
FYI I'm not using MVC.
Yes, you can.
Take a look at RouteCollection.MapPageRoute for details but roughly you need the code below:
routes.MapPageRoute(
"ProductDetails",
"/ProductDetails/{Category}/{artID}/{alias}",
"~/ProductDetails.aspx");
However artId and alias cannot be in the same segment. They need to be separated by a slash (/).
The other difference is that you need to grab the parameter values from RouteData instead of querystring so instead of:
Request.QueryString["Category"]
you do:
Page.RouteData.Values["Category"]
ps: I did it from the top of my mind so it might not compile
May be you can try URL Rewriting. That would be an ideal choice to implement this with no code change at all. And use regular expression to extract values from the url to bounce the values to original aspx page.
http://www.iis.net/downloads/microsoft/url-rewrite
Yes, we can create search engine friendly URL using ASP.NET routing feature. This blog post have an example of URL routing -
http://newapputil.blogspot.in/2013/12/aspnet-40-web-forms-url-routing.html
I want to translate my ASP.NET website, just like microsoft does.
I want the urls to have /en-EN/ or /de-DE/
the problem is that my urls ar already routed URLs
How can I do this?
I found this http://blog.maartenballiauw.be/post/2010/01/26/Translating-routes-(ASPNET-MVC-and-Webforms).aspx
but I don't want to translate all the urls and this method seems to me too complex, with Views and Controllers.
I need mysite.com/en-EN/routedpage or mysite.com/de-DE/routedpage
The above example is for mvc, is your website in mvc?. You need to setup your website for culture specific setting, here is an article how to do that
http://www.ezzylearning.com/tutorial.aspx?tid=3477182
Also for further reading
http://www.codeproject.com/Articles/7998/Creating-multilingual-websites-Part-1
and
http://www.codeproject.com/Articles/8073/Create-multilingual-web-pages-very-easily
its very easy to setup
This is an important problem. You want the URL to have the language encoded in it for both SEO and usability purposes.
Two common solutions are:
1) Change the domain. fr.example.com or de.example.com. Then the routes don't need to be changed.
2) Use the # for the language code. Search engines nowadays will observe this. So, then you'd have www.example.com/#de or www.example.com/#fr
You can implement both of these solutions with www.SiteTran.com by simply pasting our javascript into your page and setting the sitetran_url_type variable to either:
var sitetran_url_type = 'sub.domain';
or
var sitetran_url_type = 'hash';
SiteTran is 100% free and is my company.
I'm developing bilingual ASP.NET Application and I want to know hat is the best way to store UICulture and Culture values all over the application?
Cookies.
Session.
QueryString.
Or something else.
Update:
I want to make the same ASPX form to be bilingual pages, what I've got an answers till now is to make a separate page and make it accessible by sub-domain, what I'm really doing now is using Session, but i want to now what is the best practice to user Resource file to make the page bilingual without creating another copy of it.
As often, it depends on your particular use case.
Most often however you'd probably want to have a different URL for each page and language in order to have it indexed properly by search engines. For example URL's like:
http://en-us.example.com/index.htm
http://www.example.com/en-us/index.htm
http://www.example.com/index.htm?l=en-us
I prefer the first 2 options.
Optionally, you could redirect the user based on their browser language when they first arrive on your site (but please make sure that the user still can browse the other languages).
Update: This doesn't mean you'll have to make as many versions of your site as you have languages.
If you have a subdomain for each language:
Point each subdomain to your site
In the codebehind of your pages, you override the InitializeCulture method (you may use a base class for all pages in order to keep it DRY)
Set the appropriate culture in the overridden InitializeCulture method
Create your resource files
Use the resources in your pages - the correct translation will be displayed depending on the culture.
If you decide not to use subdomains but include the culture name in your URL, you may use URL-rewriting to point to the same page from each URL.
Some code to get you started:
protected override void InitializeCulture() {
// Identify the culture and replace the hardcoded values below
// (Use Request.Url.xxx for example)
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en", false);
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US", false);
base.InitializeCulture();
}
You can always use URL re-writing to store the chosen cultural preference of the user. Not particularly sure how this is achieved in ASP.Net, but it's easy using the routing table in MVC.
To elucidate, your url would look something like this: http://example.org/en-gb/Action
As a solution, this removes the overhead of sessions, the possibility that someone has turned cookies off in the browser, and the unsightly QueryString that gets generated.
I'll try and get back with an example of how to do the url re-writing.
The best practice is to create sub-domains\separate site for each language with its own separate IIS website. This is particularly true for Asian languages where you will need double byte.
You will see this practice all over in yahoo, google, etc.:
http://www.google.cn/
http://es.yahoo.com/
Etc.
I am working in an ASP.NET mvc application. With regards to URL's I could see the Controller and action names in the address bar when user navigates between pages. Is there a way to hide them, such that the address bar always displays http://mywebsite.com without any action names or controller names suffixing them, or is there any other standard practices? Or is it ok to leave the URL as such which can contain action and controller suffixes?
Having the URL not change is very bad practice. Not only does it look confusing, but it makes it impossible to bookmark things, and copy and paste URLs.
Why would it not be OK to leave the descriptive names in the URL? (You are using descriptive names, aren't you?)
The url is supposed to be descriptive of the content.
http://www.mysite.com/ isn't descriptive of viewing product #22's details, however:
http://www.mysite.com/Products/Details/22 is. This is intended behaviour, you can obfuscate them a bit by messing with rotues but it's not wise as it makes your webpage harder to debug and is unneeded.
It's not so much of a security risk to expose controller/method names because you chose those names based on the functionality you want to expose to the user. There are many other security mechanisms in place to prevent them from messing with things, like user authentications, filters, etc...