In this session, the speakers repeatedly discussed issues on duplicate content and URL redirecting, URL renaming, and best practices in making your URLs search engine friendly. There’s a bunch of technical discussion on .htaccess rewrite modes and http status codes, whew. (Note to self: Get more air time with the developers). The panel is moderated by Detlev Johnson of SearchReturn.

Nathan Buggia of Live Search is up first. He discusses the difference between a sub-domain and a sub-folder. He says to use whatever works in your site architecture, it doesn’t matter which one you use.

HTTP Status Codes: 200 – Everything’s okay, you got the domain that you’re looking for. 404 – File not found. 301 – File has been moved permanently (this is probably SEOs most favorite status code). 302 – File is moved temporarily somewhere else. He does not recommend using 301s. He uses 302s more. (Hmm. I didn’t exactly get why he said this.)

Robots are set on a sitewide level. However, microsoft.com/robots.txt does not apply to technet.microsoft.com.

There are lots of duplicate content scenarios. This happens when there is more than one URL for the same content. Create a few simple rules that will remove duplicate URLS by 301 redirecting all variations to the shortest one. Sitemaps are great tools for search engines. He doesn’t recommend using a crawler in creating sitemaps. Create your sitemaps manually, and from scratch.

Navneet Virk is up next. He starts discussing the major SEO components: Content, Code, and Technical Architecture / CMS / Backend. Zoom in to URLs, when you talk about optimized URLs, it means:

• Accessible by search crawlers
• Targeted towards the keywords
• Readable by SEs and users
• Unique for content
• Relevant in terms of domain and sub-domains as well as directory nomenclature

Content Management Systems, if you don’t configure, generate complex URL structures that will become an issue. Some of the approaches we take if we want to make our URLs search engine friendly are: (1) Page Element Approach — leveraging certain elements on the page to construct optimized URL; and (2) Record Name Approach — Irrelevant parameter names do not provide any relevance information or value to the URL.

A vanity URL is a domain name (or URL), typically created by a company to point to a specific product or advertising campaign microsite or section. Vanity URLs, however, also present the risk of content duplication penalties.

He presents different issues in tracking parameters in the URL, and how to resolve them. (And I have to take a rest room break — blame it on the afternoon juju. BRB.)

Stephen Spencer of Netconcepts is up stage when I got back. He starts with the familiar Subdomains vs Subdirectories issue — Matt Cutts says they’d essentially treat them as the same.

You shouldn’t treat subdomains as a means of creating tons of easy thin-content microsites. They’re being viewed as subdirectories. Yes, use them for managing your website and doing load balancing. No, don’t use them purely for SEO reasons.

Microsites can be bad for your SEO if overly numerous or if they contain substantial amounts of duplicate content (merely changing the UI doesn’t count). Microsites can also be beneficial in terms of demographic targeting and focused keyword targeting. (i.e. stayinghealthy.com vs stayinghealthy.metlife.com)

Keywords in URLs are beneficial in Google regardless of whether it is in filename/directory/subdirectory.  The closer the keyword(s) are to the root domain name, apparently the more weight they will lend. Now just because a keyword is bolded in the SERP doesn’t mean it’s given extra weight in the ranking algo.

As far as word separators in the URLs, hyphens are the best, and are preferred over underscores. URL stability is important, i.e. an annually recurring feature, like a holiday gift buying guide, should have a stable URL and keep it for next year’s user. This way, all links to this stable URL will accumulate through the years. Otherwise, link juice earned over time is not carried over to future years’ editions.

He discusses URL rewriting next. He talks about a bunch of .htaccess rewrite jibberish *checks SMX Handbook* — oh hai, there you are in the handbook, I skip blogging this nao. :)

Sean Suchter, VP of Engineering at Yahoo!, in the house. He discusses URL structures that perform better on Yahoo! Search. He suggests using canonical URLs for internal linking purposes. Avoid case sensitivity and use lower case. A site should avoid using large numbers of subdomains. Large numbers of subdomains will get the harshest penalty even if there’s nothing else wrong with your site.

Base on stats, short URLs get clicked on 2x as often as long URLs (given that the position rank is equal). Participants spend more time viewing the long URL, but less time viewing the entire listing. Long URL distracts the searcher from viewing the listing’s title and description.

Examples of bad URLs: TheExpertsExchange.com can be mistaken as TheExpertSexChange.com!!; or TherapistFinder.com which can be read as TheRapistFinder.com, LOL.

Jeff Cox, Software Engineer of Google, closes the session with his presentation.

Google wants to index only one copy of every page, it also means better user experience. A URL is a duplicate if it contains the same content as another URL, and it is a redirect to another URL.

In selecting canonicals, we want to pick the best URL to show our users. Selection is influenced by pagerank, sitemap information (www vs non-www), URL length (shorter is better), redirect status, meta noindex tags, etc.

Some of the guidelines and suggestions from a Googler: You will NOT be penalized for having duplicate content (hmm). But Google would like to index just one, so if, say, you get links to both pages with the same content, you split your link juice to the two URLs. Use redirects correctly. Set your preferred domain via Webmaster Tools. Dynamic URLs are fine, but the shorter and more readable the URL, the better.

In Q&A, Nathan Buggia corrects his earlier statement. He meant he uses 301 more than 302. Ohkaaay. At least he got that one cleared. :)