Many moons ago, I wrote a blog post about properly handling 404 (page not found) errors with ASP.NET. But an often overlooked and underused approach to error handling is the custom 500 error page. For those not familiar with a 500 error, it is the error that occurs when an exception is made. An exception could be anything from incorrect logic introduced into the code by the developer (not me of course) to malicious data entered by a user into a form field. If the developer chooses not to implement a custom 500 error page, the end user will be presented with an often very unpicturesque screen containing information about the exception. Often, this information can be very revealing and can give a hacker just the right amount of information they need to compromise your website.
The solution to all of this is to properly configure your web application to display a page that is more user-friendly, pleasing to the eyes and one that conveys a custom message to the end user. Read More
Best SEO practice dictates that duplicate content, the same content found on multiple pages of one domain, is widely frowned upon. Most of the time, duplicate content is unintentional, either due to a lack of knowledge of its destructive consequences or just out of blatant disregard.
That being said, there are times when you do need duplicate content on your website. Consider an ecommerce site, particularly a product catalog, for example.
In a product catalog, it is not uncommon for the same product to be associated with multiple categories. For this very reason you could possibly have the same content on multiple URLS…
http://domain.com/category/product.html * I want this to be indexed.
… which will all show the product details for one specific product. Now ideally we want search engines to only index one of those pages and ignore the other two. Fortunately, Google, Bing and a few other search engines, allow us to circumvent this problem rather easily by using the canonical link element. The canonical link element, which is put in the HEAD section of an HTML document, tells search engines the preferred location for a particular URL. So in order for the search engines to ignore two of the pages from our example above, and only pay attention to the page we want indexed, the following line can be added to both pages we do not want indexed:
<link rel="canonical" href="http://domain.com/category/product.html"/>
Now when the search engines visit the pages with that element, they will only consider its canonical location in their indexes. It should be noted however, that you should still avoid duplicate content at all costs, but there are some times when your application truly needs it, and for this, the canonical link element is perfect.
ASP.NET is notorious for generating some ugly markup in the HTML it generates. The idea behind search engine readability is to get the relevant content as close to the top of the HTML Source as possible.
One of the biggest culprits in terms of unnecessary code at the top of the page is ASP.NET’s VIEWSTATE. VIEWSTATE is ASP.NET’s way of making it easier for the programmer and end user to remember certain pieces of information about a page as it is being used. It does this via a hidden form field. The best way to minimize the amount of VIEWSTATE text that appears in the HTML source code is to disable it (it’s enabled by default) and only add it when you need it. Another technique for dealing with VIEWSTATE is to move it to the bottom of the HTML source code. A while back I wrote a blog post on how to achieve this:
A technology that ASP.NET employs that “makes things easier for the developer” and offers a rich end-user experience is the AJAX Control Toolkit. The AJAX Control Toolkit lets you quickly implement things such as modal dialogs (e.g., Lightbox), form field enhancements and partial page updates. The problem with using it is that it also adds an enormous amount of code to the HTML output. The best way to minimize this is to use an alternative to the Toolkit such as jQuery or MooTools. None of the code gets auto-generated in these libraries and the end result is usually nice clean HTML source code.
If you follow the above suggestions, you can greatly reduce the amount of unnecessary code in your HTML output. One of the key points to remember is that anything ASP.NET auto-generates, though great for you as a developer, probably isn’t that good for SEO.