Saturday, April 21, 2012

Search Engine Optimization Vs. Search Engine Marketing

By Simplifying The WEB

SEO and SEM are two terms that are commonly bandied about by webmasters. Sometimes it seems as if the two terms are used almost interchangeably. But is there a difference, and if so, what is it?

In fact, there is a difference. SEO stands for Search Engine Optimization. It refers to anything you do to your page to make it more search engine friendly. SEM stands for Search Engine Marketing. It forms a sort of umbrella term that can refer to anything you do to get your page ranked higher in search engines, from search engine optimization to requesting backlinks to submitting your URL to search engines.

It's important to know the difference between the two when you're shopping for SEO or SEM services. If the company doesn't specify what services it offers as part of its "SEM Package," then don't hesitate to ask. And don't hand over any money until you know! Some companies may mean nothing more than submitting your website's URL to a few search engines, and you can do that yourself.

Whenever possible, get a list of specific things they plan to do to help surfers find your website. Will they submit your URL to search engines? Get a list of the search engines they plan to submit it to. ("Yahoo!, Google, and 100's More!" doesn't count.) Will they keyword optimize your site? Be sure to ask if they include META and ALT tags.

Ultimately, whether a company uses "SEO" or "SEM" doesn't matter as much as what services they offer. Ideally, SEM would be more valuable than SEO, because it would include SEO as well as other marketing strategies. But this is not always the case. As we've noted before, it can be simply a code for "stick your URL is a few search engines and be done with it." Look for reputable websites, and ask for specific services they offer. Once you've done your homework, you will be able to make an informed decision between SEO and SEM and march forward proudly, knowing that you truly got the best value for your money.

About the Author: For more information visit Orange County Website Design Search Engine Optimization Orange County SEO Simplifying The WEB

Source: www.isnare.com
Permanent Link: http://www.isnare.com/?aid=153274&ca=Internet

Thursday, April 12, 2012

Registration for W3C Online Course on Mobile Web Best Practices; Early Bird Rate Through 23 April

W3C is pleased to announce that registration is now open for the next edition of the most popular W3C online training course, Mobile Web 1: Best Practices. The 6-week course begins 30 April 2012. It will help Web designers and content producers who are already familiar with the desktop world to become familiar with the Web as delivered on mobile devices. It is based entirely on W3C standards, particularly the Mobile Web Best Practices. Along with the course description, read comments from past students and what they have achieved. An early bird rate of €195 is available until 23 April 2012; after that date the full price is €225 so register now

W3C Workshop: The Multilingual Web – Linked Open Data and Multi­lingual­Web-LT Requirements

 Workshop on Linked Open Data and Multi­lingual­Web-LT Requirements, 11-13 June in Dublin, Ireland. Organized by the MultilingualWeb-LT Working Group, the purpose of this workshop is two-fold: first, to discuss the intersection between Linked Open Data and Multilingual Technologies, and second, to discuss Requirements of the W3C MultilingualWeb-LT Working Group. Participation is free. We welcome participation from both speakers and non-speaking attendees. However, whereas future MultilingualWeb workshops will continue the wide-ranging format of previous MultilingualWeb events, and will aim again at a larger audience, attendees for this workshop are required to participate actively in discussions and will need to submit a position statement for the workshop registration. There are limited spaces available. Learn more about Internationalization at W3C.

Last Call: Authoring Tool Accessibility Guidelines (ATAG) 2.0 and Implementing ATAG 2.0

The Authoring Tool Accessibility Guidelines Working Group has published an updated Last Call Working Draft of Authoring Tool Accessibility Guidelines (ATAG) 2.0 and a Working Draft of Implementing ATAG 2.0. ATAG defines how authoring tools should help developers produce accessible web content that conforms to Web Content Accessibility Guidelines (WCAG) 2.0. It also defines how to make authoring tools accessible so that people with disabilities can use them. Comment deadline is 5 June 2012. Learn more in ATAG 2.0 Last Call Working Draft published and read about the Web Accessibility Initiative (WAI).

CSS Variables Module Level 1 Draft Published

The Cascading Style Sheets (CSS) Working Group has published the First Public Working Draft of CSS Variables Module Level 1. CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. This module contains the features of CSS level 3 relating to variables. It includes and extends the functionality of CSS level 2, which builds on CSS level 1. The main extensions compared to level 2 are the introduction of the variable as a new primitive value type that is accepted by all properties. Learn more about the Style Activity.

Efficient XML Interchange (EXI) Profile Draft Published

The Efficient XML Interchange Working Group has published a second Public Working Draft of Efficient XML Interchange (EXI) Profile. This document describes a profile of the EXI 1.0 specification for devices with limited memory capacities. Learn more about the Extensible Markup Language (XML) Activity.

Wednesday, April 11, 2012

Differences Between IIS URL Rewriting and ASP.NET Routing

There are the following main conceptual differences between IIS URL rewriting and ASP.NET routing:
  1. URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL rewriting module does not know which handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
  2. ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing module knows about the handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.
In addition to these conceptual differences, there are the following functional differences between IIS URL rewriting and ASP.NET routing:
  1. The IIS URL Rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
  2. The IIS URL Rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file name extensions or the application must be configured to use "*" handler mapping in IIS.
  3. The IIS URL Rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
  4. In addition to rewriting, the URL Rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform these tasks.
  5. The URL Rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.

Which Option Should You Use?

What does all this information mean if you need to choose a technology to enable clean URLs for your Web applications? In this section, we explain how to make this choice.
If your Web application is built by using anything except ASP.NET, use the IIS URL Rewrite module. Otherwise, the rules are:
  1. If you are developing a new ASP.NET Web application that uses either ASP.NET MVC or ASP.NET Dynamic Data technologies, use ASP.NET routing. Your application will benefit from native support for clean URLs, including generation of clean URLs for the links in your Web pages. Note that ASP.NET routing does not support standard Web Forms applications yet, although there are plans to support it in the future.
  2. If you already have a legacy ASP.NET Web application and do not want to change it, use the URL Rewrite module. The URL Rewrite module lets you translate search engine-friendly URLs into a format that your application currently uses. Also, it lets you create redirect rules that can be used to redirect search engine crawlers to clean URLs.
In practice, however, the choice does not have to be either/or. The technologies can be used together and can complement each other. In the following sections, we outline some scenarios where you can use ASP.NET routing and IIS URL rewriting together.

Related posts:

Differences Between IIS URL Rewriting and ASP.NET Routing
SEO with ASP.NET 4.0 Framework

Books
Professional Search Engine Optimization with ASP.NET: A Developer's Guide to SEO (Wrox Professional Guides)
Professional IIS 7 and ASP.NET Integrated Programming
Leveraging httpModules for Better ASP.NET applications (Wrox Briefs)
Ultra-Fast ASP.NET: Build Ultra-Fast and Ultra-Scalable web sites using ASP.NET and SQL Server
Beginning DotNetNuke Skinning and Design (Programmer to Programmer)

Friday, April 6, 2012

Rewrite URL-Implement URL Rewriting in ASP.NET

Reference articles:
  • Tip/Trick: Url Rewriting with ASP.NET by Scott Guthrie - Examines four approaches: 1) Use Request.PathInfo Parameters Instead of QueryStrings; 2) Using an HttpModule to Perform URL Rewriting; 3) Using an HttpModule to Perform Extension-Less URL Rewriting with IIS7; 4) ISAPIRewrite to enable Extension-less URL Rewriting for IIS5 and IIS6; also discusses how to handle ASP.NET postbacks correctly with URL rewriting.
  • URL Rewriting by Salman (CSharpFriends) - simple implementation of URL rewriting logic within the Application_BeginRequest() method of the Global.asax file.
  • Rewrite.NET - A URL Rewriting Engine for .NET by Robert Chartier (15Seconds.com). Solution steps:
    • Create the HttpModule to process the web request and rewrite the URL
    • Add the handler in Web.config
    • Create a configuration section in Web.config to define URL mapping rules
    • Add extensibility by creating a rules engine interface
    • Write class or classes to implement rules engine interface
    • Add code to the HttpModule to dynamically load the desired rules from Web.config
  • URL Rewriting in ASP.NET by Scott Mitchell (MSDN) - examines how to implement URL rewriting in a HTTP module; also explains how to handle postbacks.
  • URL Rewriting with ASP.NET by Richard Birkby (CodeProject) - shows how legacy ASP sites can be upgraded to ASP.NET, while maintaining links from search engines. Solution steps:
    • Create the configuration section in Web.config for defining URL mapping rules
    • Write the configuration section handler class, incorporating the URL rewriting logic
    • Create a call to handler in Global.asax in Application_BeginRequest() method
    • Compile the code and install the rewriter assembly in the Global Assembly Cache (GAC)
    • Configure IIS to map non- .aspx files to the ASP.NET ISAPI extension 

Related posts:

Differences Between IIS URL Rewriting and ASP.NET Routing 
SEO with ASP.NET 4.0 Framework

Related Resources