Testing title tags: the problems

SERPs (search engine result pages) introduce many uncontrollable variables, such as Google’s penchant for showing different flavors of results, in different areas on the page, for different keyword searches. For example, a search for ‘riding boots’ shows Google Product Search results that can divert a customer from organic listings, star ratings that draw attention to search ads, and brand links to help users narrow their searches.

Notice how the singular “riding boot” and plural “riding boots” show the same page results, but slightly different related Stores results, and omits Product Search results.

If you’re really observant, you’ll notice the related Stores options are different too. Testing is difficult because you have no way of knowing how often these elements are shown or how they may be skewing your results. Not only that, but search positions are always in flux, and vary depending on the exactkeyword phrase queried, the user’s geolocation, whether the user is logged into a Google account (personalized to search history), the “freshness” of results at any given time, and perhaps even involves estimated page load speed and activities of one’s social graph. And did you know that search engines sometimes override your HTML and create their own title for you based on content on your page or what it thinks your page is about? Finally, the biggest hurdle is that even with Google’s own Website Optimizer tool, you cannot tell Google to show one title tag 50% of the time and another the rest. Google will only index your control page. Test versions are served after the referral, if applicable. This makes A/B testing individual pages’ title tags impossible. The only testing you *could* do is in aggregate.

Testing title tags: the workaround

Get Elastic reader Sander Daniels’ team at Thumbtack.com found a workaround to A/B testing title tags in aggregate, described in this case study. Using a home-grown testing platform in its ecommerce back end, the test ran for 7 days, Thumbtack split its URLs into 3 buckets, each containing thousands of URLs. The buckets consisted of a control and 2 challenging formats.

Control: Looking for the best [Service] in [City Name]? Challenger A: Get Free Quotes Today From [Service] In [City Name] Challenger B: [Service] in [City Name] – Get Free Quotes Today

To control for the uncontrollables in search, Thumbtack used the ratio of visits to its experimental titles compared to visits to pages in its control group. Rankings were also monitored, and there was no significant change during the test period. The test ran for 7 days, resulting in a 20-30% drop in traffic to its test groups. Traffic rebounded (for the most part) after reverting to the original title tags.

What to test in ecommerce title tags

If you’re bold enough to try a similar experiment (and have the technical judo chops), here are a few hypotheses you could explore:

• Keyword vs. store name at the beginning of the title
• Short vs. long, “keyword stuffed” titles
• Value proposition such as “Free shipping” or “largest selection of” at the beginning of the title
• “Shop” at the beginning of the title to differentiate from informational results such as Wikipedia articles and blog posts

Remember, to make it work:

• You need a fairly large sample size of URLs that you can experiment, and a tool to support it the test
• Your treatment versions must be tested against your control concurrently, not sequentially
• Allow enough clicks to accrue to reach a statistically significant result
• Understand what you are measuring – are search positions affected (for example, if your brand name at the beginning of the title affects your keyword relevance across the board)? Is traffic affected (can you estimate you are getting higher click through)? Are conversions affected (are you attracting the same quality of visitor)?
• And finally, revert title tags back to normal after the test is over to validate your results

Looking for help with ecommerce strategy? Contact the Elastic Path Research & Strategy team at consulting@elasticpath.com to learn how our ecommerce strategy services can improve your business results.

Seattle ski and snowboard shop evogear faced an “identity crisis.” Its online customer base knew it as evogear, while the Seatown locals’ pet name evo had better swagger. So the company decided to drop the “gear” – knowing full well the consequences.

Domain change best practices

SEO-savvy evo followed all the domain change best practices, including submitting site maps through webmaster tools and setting up 301 (permanent) redirects from every single evogear.com URL to its evo.com counterpart. (SEOmoz has a nice summary best practices in its SEO Guide: How to Properly Move Domains).

evo also did something not mentioned in the SEOmoz guide. evo reached out to a number of webmasters that had linked to evogear.com (including Get Elastic), informed them of the domain change and kindly requested an update to the link(s) to point to evo.com. Time consuming as it may be, this tactic helped search engines sort out the link graph faster, and opened the door for new linking opportunities (this post is an example).

Another reason to seek out direct links, even with 301 redirects, is a bit of “link juice” is lost through the redirect. All inbound links contribute to your Page Rank (some more than others), but a bit less juice multiplied over hundreds or thousands of links can be significant.

The road to recovery

evo flipped the switch on page-to-page 301 redirects on August 17, 2010. Through daily tracking using the site:search operator in Google, evo believes the re-indexation process took roughly 5 weeks. Rankings did sink about a week after implementing the redirects, which impacted organic visits. For about 3 months, organic traffic had decreased 30% from the previous year.

August was the right time to make a move, because ranking and search engine traffic made a recovery mid-November – just in time for Black Friday, and evo is back to beating last year’s numbers. Swales credits the link building effort for shortening the “time to heal.”

How do you find backlinks to your site?

There are numerous backlink checkers available. evo used Google Webmaster Tools and SEOMoz’s Open Site Explorer. Swales especially likes the SEOMoz tool because it assigns a ‘page authority’ which allowed evo to prioritize which link partners to contact first.

The takeaway

Changing domains has a major impact on SEO, and you should make the decision very carefully. If you can suffer short term for long term benefit, expect the entire process to take a minimum of 6 months, even up to a year. A bit of extra manpower (or womanpower) to retain direct backlinks can shorten this time, and help retain as much link credit as possible.

Examples of fly-out or mega menus

The most common form of JavaScript enabled menu is what designers call a “fly-out” or “mega” menu. Fly-outs can be seen on hundreds or even thousands of online retail sites.

The key features of this sort of menu are that:

1. Only top-level product or site categories are displayed by default
2. Sub-category information displays when a user hovers over a top-level label
3. All of the sub-categories are anchors, linking to very specific product category pages

Mega menus may also be used for “navandising” – including images or graphics that cross-sell or up-sell related products, services, or offers.

Benefits for shoppers

Some online retailers have a significant number of product offerings or variations across many product lines. While that variety is often a boon for shoppers and merchants alike, it can make finding specifically what you’re looking for something of a challenge. Fly-out menus make it easier to sort through available products.

SEO-friendly mega menus: it’s all in the code

It is true that JavaScript can be written in a way that hides anchor tags from some search engines. For example, if we built a mega menu that was added to the document object model by the JavaScript, some search engine bots might not be able to “see” the menu.

But most mega menus include all of the links and tags in the actual HTML markup, typically in the form of an unordered list. These lists are then hidden from view with a cascading style sheet (CSS), JavaScript, or a combination thereof.

For example, Aldo Shoes’ mega menu sub-categories are coded directly into the HTML, creating several rich, text-based links for search engine bots to spider and index:

In fact, the HTML for a mega menu can look surprisingly similar to the HTML for a site map, which most SEO pundits praise.

For more information on how to build an SEO-friendly JavaScript menu, check out my previous Get Elastic post, Build SEO-Friendly JavaScript Menus.

This post was contributed by our guest columnist Armando Roggio. Armando is a journalist, web designer, technologist and the site director for Ecommerce Developer.

They’re called sitelinks (according to Google), and they only appear for certain websites triggered by certain keywords. For the privileged sites that receive them, they give the search listing more prominence in search results and expose a bit more of what the site has to offer. But not every site earns sitelinks. According to Google: “If the structure of your site doesn’t allow our algorithms to find good sitelinks, or we don’t think that the sitelinks for your site are relevant for the user’s query, we won’t show them.”

The sitelinks that appear represent what Google thinks is important on your site.

But Google doesn’t always get it right, and may show links to pages you don’t want anyone to land on. For example, Victoria’s Secret’s sitelink titled “Victoria’s Secret Online Shop” actually leads to an account sign-out page.

The bad news for VS is that link probably gets high click through, and many have stumbled upon it already. The good news is VS can tell Google, through the Google Webmaster Tools console, to block that link from sitelinks. That frees up that spot for another link that would be of more value.

Go ahead and Google your own brand keywords (yourcompany.com, yourcompany, your company, your company’s product, etc). Check out each site link to verify that you actually want that link to show up. If you want to block any, just follow these directions (you’ll need to sign up with Google Webmaster Tools first)…

To block a sitelink, first ensure that you have verified ownership of the site. Then:

1. On the Webmaster Tools Home page, click the site you want.
2. Under Site configuration, click Sitelinks. If we have sitelinks information for your site, we’ll display a list of sitelinks.
3. Click Block next to the sitelink you want to remove. Please let us know why you want to block the sitelink – it will help us improve the way we generate and display sitelinks.

For more tricks you can do with Google Webmaster Tools, check out Are You Taking Advantage of Webmaster Tools? and SEO Health Checks – Regular Housekeeping Tasks for Your Website’s SEO.

Here’s an example regarding canonical URLs and duplicate content:

Directory form, www.google.com/product(/)
www.google.com/product (canonical), try version:
www.google.com/product/

with: suboptimal behavior when trailing slash added
* includes product main pages in directory form without a trailing slash

200 status code given when slash added to Google Products’ canonical URL, Sept. 2009:

Avoid multiple URLs that serve the same content. From the example above, the good news is that visitors will reach the content no matter which version of the URL they choose. This is because a “200 OK” status code is given for both URLs. The bad news is that each of these URLs will get crawled and indexed by search engines, creating duplicate content. Search engines will have a tougher time deciding which URL is the canonical. Also, each URL will have its own reputation. Using a 301 on www.google.com/products/ will consolidate this valuable reputation so that the canonical can rank to its fullest.

404 status code given when slash added to Google Finance’s canonical URL, Sept. 2009:

Prevent 404s. A lot of visitors will try to reach Google Finance with the URL finance.google.com/. Many others will try www.google.com/finance, but a large number will also try www.google.com/ finance/, which leads them to an unhelpful 404 page. Some visitors will assume that the service is down (“Why wouldn’t www.google.com/finance/ work?”). Others might try another form of the URL, but say, “I never know which URL to choose for Google’s products!” Think of the most common URLs that visitors might try in order to reach your product, then 301 redirect these to the canonical URL. This will prevent a lot of frustration for users who access your product by typing the URL in their browser’s address bar.

404 page shown when slash added to Google Finance’s canonical URL, Sept. 2009:

To see the whole shebang, download the SEO Report Card < here.

The difference between an effective JavaScript menu—that helps  visitors easily navigate the site and helps search engine spiders index it—and one that hides content can be as simple as how the JavaScript is written and implemented. So why is this the case?

JavaScript Is A Client-Side Language

As you probably know, JavaScript is an object-based scripting language that primarily runs in the client, which is typically a web browser. Because the heavy lifting is done on the client-side, JavaScript can add a level of interactively that is often hard to match with other scripting languages or programming choices—even updating a page’s content right in the client. It is for this very reason that asynchronous JavaScript and XML (AJAX) has become so popular in the past couple of years.

But being a client-side language also means that it is possible to write JavaScript in such a way that search engine spiders, which are typically very-basic clients, cannot interpret the script or find the content and links it includes.

When JavaScript Goes Bad

For example, here is a short bit of code that will produce a super simple HTML page, which is completely invisible to most search engine spiders.

<!DOCTYPE html>

<html lang=”en”>

<head>

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

<title>Some Title</title>

<script type=”text/javascript”>

document.write(“This Is Not SEO-friendly JavaScript”);

</script>

</head>

<body>

</body>

</html>

Notice that there is absolutely nothing between the opening and closing body tags. All of the content is trapped inside of the JavaScript in the document head.

The resulting web page would display the phrase “This Is Not SEO-friendly JavaScript” to visitors with JavaScript enabled, but visitors that did not have it enabled and search engine spiders would almost certainly see nothing at all. Blank white space.

Inline JavaScript Can Be Even Worse

As if the example above was not bad enough, there are worse ways to implement JavaScript, where search engine optimization (SEO) is concerned. Perhaps, the best examples of how not to code JavaScript come from Jeremy Keith’s 2006 XTech presentation, Hijax: Progressive Enhancement with AJAX. Keith is actually encouraging the separation of site content, presentation, and behavior in a way that focuses first on developing good content and then presenting that content to users. In the process of explaining what to do, he shows us what not to do, too. These examples are Keith’s. The explanations mine.

Example One: Inline JavaScript Pseudo-Protocol

<a href=”javascript:window.open(‘help.html’)”>contextual help</a>

In a browser with JavaScript enabled, example one would produce a link that opened a new page, help.html, in a new window. Unfortunately, for a search engine spider, the link would almost certainly lead to nowhere. Sorry, Google won’t be indexing help.html today.

Example Two: Inline JavaScript that Creates A Pointless Link

<a href=”#” onclick=”window.open(‘help.html’); return false;”>contextual help</a>

Again, a JavaScript-enabled browser would get a link which opens help.html, but again search engine spiders and users whose browser does not support JavaScript cannot get to help.html at all.

Example Three: Inline JavaScript that Uses the Document Object Model (DOM)

<a href=”help.html” onclick=”window.open(this.getAttribute(‘href’)); return false;”>contextual help</a>

Example three is the first code snippet to at least offer something to search engine spiders. This link will work for SEO, but it is still not ideal. Rather we would like to see something like this:

Example Four: No Inline JavaScript

<a href=”help.html”>contextual help</a>

This example includes no JavaScript at all. Search engine spiders, which love HTML, can index it easily, and we can still get the exact same effect by writing an external JavaScript that references this element.

function doPopups() {

if (document.getElementsByTagName) {

var links = document.getElementsByTagName(“a”);

for (var i=0; i < links.length; i++) {

if (links[i].className.match(“help”)) {

links[i].onclick = function() {

window.open(this.getAttribute(“href”));

return false;

};

}

}

}

}

Start With the HTML and Modify It With an External JavaScript

From an SEO and best practices perspective the proper way to integrate JavaScript into a website is by using external or isolated scripts that constitute a behavior layer.

To really bring this point home, I’ll show you how to create an SEO-friendly JavaScript menu using HTML, CSS, and the jQuery  library. I’ll start with the content and add the functionality as we go, focusing on why this method is best for SEO.

Figure One: The Site We Will Be Building

The left-hand navigation on this site takes advantage of the jQuery accordion widget.  From a user standpoint, it neatly categorizes the site content, and allows a shopper to get more information about a particular category when she wants it.

To get this site up and running, I start by coding the HTML.

<!DOCTYPE html>

<html lang=”en”>

<head>

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

<title>SEO-Friendly JavaScript Menu Example — Get Elastic</title>

</head>

<body>

<div>

<div>

<h1>Example Website</h1>

</div><!–end header–>

<!– Accordion –>

<div>

<div>

<h3><a href=”section1.html”>Section 1</a></h3>

<div>

<ul>

<li><a href=”someurl.com”>List item one</a></li>

<li><a href=”someurl.com”>List item two</a></li>

<li><a href=”someurl.com”>List item three</a></li>

</ul>

</div>

<h3><a href=”section2.html”>Section 2</a></h3>

<div>

<ul>

<li><a href=”someurl.com”>List item one</a></li>

<li><a href=”someurl.com”>List item two</a></li>

<li><a href=”someurl.com”>List item three</a></li>

</ul>

</div>

<h3><a href=”section3.html”>Section 3</a></h3>

<div>

<ul>

<li><a href=”someurl.com”>List item one</a></li>

<li><a href=”someurl.com”>List item two</a></li>

<li><a href=”someurl.com”>List item three</a></li>

</ul>

</div>

<h3><a href=”section4.html”>Section 4</a></h3>

<div>

<ul>

<li><a href=”someurl.com”>List item one</a></li>

<li><a href=”someurl.com”>List item two</a></li>

<li><a href=”someurl.com”>List item three</a></li>

</ul>

</div>

<h3><a href=”section5.html”>Section 5</a></h3>

<div>

<ul>

<li><a href=”someurl.com”>List item one</a></li>

<li><a href=”someurl.com”>List item two</a></li>

<li><a href=”someurl.com”>List item three</a></li>

</ul>

</div>

</div>

</div>

<div>

<img src=”images/hero.jpg” alt=”50% off on all pumps” />

</div><!–end main–>

<div>

&copy Armando Roggio 2010, all rights reserved, etc.

</div><!–end footer–>

</div><!–end Wrapper–>

</body>

</html>

The code should look very simple and very straightforward. It is just HTML, the sort of stuff that search engine spiders love. We’ve also taken care to provide a title, for SEO purposes, and make use of h1 and h3 tags, which can help search engines understand what’s important on a page. You will notice that I even added some alternate text to my image.

Furthermore, all of the links, all of the content is readily available to a search engine spider. This site is ready to be indexed.

Next Add Style

With the site content in place, it is time to style it. I’ll use two separate CSS files for this presentation layer. The first file, jquery-ui-1.7.2.custom.css, is the jQuery UI file I downloaded from the jQuery site. It styles the dynamic classes that our JavaScript will add to the site in the client. The second file, style.css, is my home grown CSS that styles the other page elements.

Both CSS files are in a CSS folder and can be called into our document by adding two familiar lines of code to our page. The CSS is SEO neutral, so provided that I don’t do anything sneaky, like trying to cloak content from user, this should have no effect on how easy or difficult the page is to index.

<link rel=”stylesheet” href=”css/smoothness/jquery-ui-1.7.2.custom.css” type=”text/css”/>

<link rel=”stylesheet” href=”css/style.css”  type=”text/css” media=”screen” />

Add Interactivity With JavaScript

Our content and presentation layers are in place and neatly separated. Search engine spiders have clear and clean access to the HTML, and our site is a good candidate for indexing, so it’s time to add some JavaScript for functionality.

We are going to need three separate JavaScripts, including the jQuery library, the jQuery UI, and some JavaScript to call our widget into action.

I downloaded the jQuery library and the UI file from the jQuery site. I added these files to the site hierarchy, and called them into or HTML with some familiar code.

<script src=”js/jquery-1.3.2.min.js” type=”text/javascript”/></script>

<script src=”js/jquery-ui-1.7.2.custom.min.js” type=”text/javascript”/></script>

External JavaScripts can, of course, be added in the head, but to follow the most recent trends in site development, I am going to place the JavaScript just above the closing body tag, ensuring that all of the site content is loaded before my scripts come into play.

The final bit of JavaScript I need looks like this:

$(function(){

// Accordion

$(“#accordion”).accordion({ header: “h3″, event: “mouseover” });

});

I write this code in a file called accordion.js, and call this file into the HTML page just like the jQuery files.

<script src=”js/accordion.js”/></script>

Summing Up

It is possible to use JavaScript to add interactivity to your sites and creating a good user experience without compromising your site’s SEO. The key is to write your JavaScript in such a way that your HTML holds all of the links and content on one layer, while your JavaScript manages the interactivity on a separate (usually external) behavior layer.

If you’re interested, you can download the source files for this post < here.

This post was contributed by our guest columnist Armando Roggio. Armando is a journalist, web designer, technologist and the site director for Ecommerce Developer.

For several years, there has been tension in the web design and development community regarding search engine optimization (SEO) and the use of Adobe Flash for site content and applications. Flash naysayers have and still do argue that you should almost never use the platform if you care at all about search engine performance and site traffic. Meanwhile, Flash aficionados argue that the user experience is more important than Google experience.

So which is it? Who’s right? In this post, I am going to:

1. Explain why both naysayers and aficionados make valid points
2. Describe the state of Flash indexability, and
3. Share several Flash development best practices that you can begin using in your projects right away.

All told, I hope this post eases tension and encourages more developers to consider using the powerful Adobe Flash platform in a way that is good for both users and spiders.

Naysayers vs. Aficionados

Both sides in the Flash SEO debate make good points and have good intentions.

On the one hand, developers and designers concerned about site traffic and getting found on search engine results pages are very focused on site success. Websites, in general, and ecommerce websites, in particular, are built to attract site visitors. In online retailing, these site visitors are shoppers and customers whose purchases are the company’s fundamental focus. If no one finds a website, it is of little use.

Acknowledging that getting potential customers to a store is vital, Flash advocates often emphasize that it is user experience that converts a site visitor into a store customer. As an example, we know that customers often buy from those company’s they most trust, and a 2003 Stanford University study of 2,440 people found that site aesthetics was the single most important factor in conveying site, and therefore, company credibility.

Furthermore, site interactivity such as hover effects, draggable elements and the like can convey professionalism as users imagine that these advanced features require a more sophisticated company to support them. The Flash platform simply allows developers greater flexibility in site design than would be possible in HTML alone. That flexibility in turn allows for more appealing site aesthetics and more engaging site interactivity, including advanced merchandising techniques, video presentation, and non-product content.
Ultimately, websites are for people, so it is user experience that should be our first concern. We want to present good site content in a way that is easy for human users to access and understand.

In HTML, we use a framework of tags like title, h1, or p to organize content in a way that is best for human users. Over time, the software engineers at companies like Google and Microsoft have discovered how to programmatically recognize content structures that organize web content in a human readable and usable way. Having recognized these useful structures—as well as the value of backlinks—search engines tend to deliver results from pages that are thus organized.

After the fact, SEO practitioners monitor search engine behavior and test theories to determine which structures and links search engine algorithms favor. With data in hand these SEO practitioners then instruct their clients to emulate these useful structures and linking strategies.

Put another way, search engine algorithms trail actual user experience, and SEO trails search engine algorithms. Here we find the crux of the problem, those that say we should avoid using Flash for SEO’s sake are encouraging us to follow user experience trends of the past, and those that encourage us to develop rich Internet experiences are asking us to lead.

We need to find a middle ground. If we get too far behind the latest design trends, we are not really focusing on providing good customer experience and conversion will suffer. If we get too far ahead of search engine indexing capabilities, we do risk losing potential traffic.

The State of Flash Indexability

So where is this middle path? What is the current, up-to-the-moment state of Flash indexability, and what can you do to incorporate Flash for the user’s sake while making content readily available for search engine spiders—your virtual users?

Google, and presumably other leading search engines, can index SWF content, execute server calls to retrieve external files for indexing, and in some cases, link back to the proper state in the Flash movie where the content originated.

This is important since the two main issues related to indexing Flash—or similar rich Internet applications (RIAs)—have to do with (a) finding content and (b) linking to content.

In the past, search engine spiders could not see inside of a SWF. It was a black box. But thanks to collaboration between search companies and Adobe, virtual users operating on servers can now, in fact, access textual and other content inside of a SWF file. Need proof? Run this search on Google right now, filetype:swf + “comic books.”

Google announced the capability in its blog on June 30, 2008. An Adobe announcement the next day summed up the change.

“Until now it has been extremely challenging to search the millions of RIAs and dynamic content on the web, so we are leading the charge in improving search of content that runs in Adobe Flash Player,” said David Wadhwani, general manager and vice president of the Platform Business Unit at Adobe. “We are initially working with Google and Yahoo! to significantly improve search of this rich content on the web, and we intend to broaden the availability of this capability to benefit all content publishers, developers and end users.”

“Google has been working hard to improve how we can read and discover SWF files,” said Bill Coughran, senior vice president of engineering at Google. “Through our recent collaboration with Adobe, we now help website owners that choose to design sites with Adobe Flash software by indexing this content better. Improving how we crawl dynamic content will ultimately enhance the search experience for our users.”

“Designers and web developers have long been frustrated that search engines couldn’t better access the information within their content created with Flash technology. It’s great to see Adobe and the search engines working directly together to improve the situation,” said Danny Sullivan, editor-in-chief of SearchEngineLand.com. “The changes should help unlock information that’s previously been ‘invisible’ and will likely result in a better experience for searchers.”

That was 18 months ago, and you can bet that Adobe, Yahoo!, and Google have not been resting on their laurels.

In fact on June 18, 2009, Google announced that it could load external Flash resources, including text, HTML, XML, additional SWFs, and more. This feature means that you can create a Flash application that draws its content from a structured and external XML document.

This was an important advancement, because it is a best practice to separate content layers from presentation and behavior layers (i.e. Flash). Remember that Flash Player does not actually make calls to a network stack for external resources, rather it relies on its host to make these calls for it. When Flash Player loads on your web browser it is your browser that requests any associated XML files, text files, or the like. And when Flash Player for Search (Google and Yahoo!’s special player for indexing content) is hosted by a search engine spider, it relies on that host to make these requests. As of this past summer, Google can and does retrieve this external files.

“That’s really important for search though because think of how many SWFs that are out there on the web,” explained Justin Everett-Church, a senior product manager for designer/developer relations at Adobe in a December 2009 interview. “[Search engines] are able to search and index these amazingly fast, and the way they have to do that is actually whenever a request is made, they can go out and cache that data, so it’s available very, very quickly, and they may even just say, ‘We’ll wait until we get all the data,’ and then rerun all the searches to make sure that it’s all there. You can’t really work in the same sort of go out and wait for a piece of content every time you need it just because it is an automated process.”

But once a search engine finds content, it may still have trouble linking to that content.

Flash content is fluid content. It does not adhere to the single page paradigm, so it is possible that particular states or frames will not necessarily have a unique URL. Without a unique URL, search engines that wish to link back to the content must link to the beginning of the Flash file or at least to a nearby state.

“This is the same problem you encounter with AJAX-based pages, “ wrote SEO experts Eric Enge, Stephan Spencer, Rand Fishkin, and Jessie C. Stricchiola in their October 2009 book, The Art of SEO. “You could have unique frames, movies within movies, and so on that appear to be completely unique portions of the Flash site, yet there’s often no way to link to these individual elements.”

But not all is lost.

A technique called deep linking, allows Flash developers to provide specific URLs for specific states in the application or page.

“If you are building your applications in Flex, you can [link directly to content] — a lot of our components are already pre-configured to work with navigation management. So, for example, in a Flex application, if you’ve got things like tabs, you can click between various tabs and you can then see a URL change and use the Back and Next button. That can certainly be enabled and disabled. I believe the default is enabled, but for people that are not using Flex, there’s actually a lot of really good libraries out there like SWFAddress that have been built by the community to address the same thing,” said Everett-Church.

The system is not perfect, since even with links in place search engines face some challenges with using these links. But it is feasible to offer both human and virtual users a way to link back to particular content in the SWF.
To summarize this section, Google, and presumably other leading search engines, can:

• Index SWF content
• Execute server calls to retrieve external files for indexing
• And, in some cases, link back to the proper state in the Flash movie

Flash Development Best Practices for SEO

Given search engine capabilities plus a desire to both make site content indexable and to create good user experiences, there are some best practices that will help ensure search engines and people alike are getting the most out of your Flash applications.

• Use external XML or text files. XML offers search engines a structured and semantic format for indexing site content. And it makes it easier to implement multi-language versions of an application. By keeping your content layer separate from your presentation layer you’ll have a better overall application.
• Create Unique URLs for Important Sections. “Creating unique URLs for important sections of your SWF file, based on the keywords for which you want to optimize, will help search engines navigate into your SWF application and provide targeted results for the most relevant content,” wrote SEO expert Damien Bianchi, in a March 2009 article. To create these unique links, you may want to employ SWFAddress or UrlKit.
• Use the HTML noscript Tag. It can be a good idea to put important site or application content in side of HTML noscript tags, which effectively puts your content into a search engine spider’s favorite language. If you are using external XML, files, you can even load the content dynamically on the server-side.
• Use XSL When Feasible. XSL can define XML formatting and presentation, so you can use it to single XML source to control both Flash content and HTML content, like navigation. You’ll make the entire site’s content searchable and you will be using an effective site development strategy.

This post was contributed by our guest columnist Armando Roggio. Armando is a journalist, web designer, technologist and the site director for Ecommerce Developer.

Do you think Google search results will ever return different results based on the device (PC or smart phone) that the person is using? i.e – if a person is using an iPhone, and searched for widgets, will widget websites written for smart phones do better in the results list?

If a person was to rewrite their website to make it smart phone friendly, do you think the best approach is to:

1. Use device detection (detect whether the user is on a PC or mobile phone) and display the same URL’s differently (EX -site1.com/page1.html)
2. Use a sub-domain of the original website ( EX – mobi.site1.com/page1.html )
3. Use new URL’s on the same website (EX – site1.com/page2.html
4. Create a brand new website (EX – site2.com/page1.html

How do you think these scenarios will affect SEO?

This is a multi-faceted question, so let’s answer it step-by-step:

Do Search Engines Deliver Different Results to Mobile Phones?

Yes. There is a separate algorithm (at least with Google) for mobile search:

Google has a patent that describes how a mobile algorithm could show results based on the users location, the time of day and their previous history. For example if you opened up Google at lunchtime it would display a list of phone numbers for your favourite local pubs before you even had to search for anything.

Opening up Google in the same location at midnight would bring up a list of local taxi firms and pizza shops, again without you having to search for anything.

Mobile algorithms are going to become more and more behavioural based as Google extracts more data from our mobile search habits. The key to ranking well in these algorithms is going to be very similar to the current online methods of ranking in Google Local.

- Patrick Altoft, Branded3 and Blogstorm.co.uk

Do Search Engines Favor .mobi Sites over .com?

No, Google displays a mix of results (mobile versions and regular versions) through mobile search. In the past you could switch between its mobile-site-only index and blended results, but apparently this ended in 2007.

As mentioned, Google Mobile Search has its own algorithm which is rumored to favor local searches (based on wi-fi location, GPS and cell ID location) and current content (right-now searches like news and local business listings vs. Wikipedia entries, for example). It may also involve mobile search user-behavior data (click through rates and time on site) to determine relevance (bounces due to poor user experience, for example).

What’s the Best Approach to Optimizing Your Site for Mobile?

“Is .mobi dead?” was a hot topic at Search Engine Strategies San Jose this summer, and thanks to livebloggers like Bruce Clay’s Lisa Barone and Search Engine Roundtable’s Carolyn Shelby, we have online summaries of Cindy Krum of Blue Moon Works‘ 4 alternatives for marketers confused about how to approach the mobile Internet.

To recap, here are the pros and cons of each option:

1. Do Nothing (Transcoding)

Always an option, and a good choice if your site already renders well on mobile phones. Test your site using the “Big 3″ engines – Google, Yahoo and MSN, and on different smartphones (older phones vs. newer phones, etc). “If it’s reasonably legible, it’s probably not worth the extra effort.” You can 301 (permanent) redirect your .mobi domain (if you have one) in this case.

Pros: Faster and cheaper.
Cons: Transcoding only works when your site is accessed through search. If someone clicks on a link through email, for example, the user experience may not be as good. Plus, URLs get messed up by transcoding so it’s harder for users to bookmark your URLs and you won’t get backlink credit.

2. Create Mobile-Only Pages

Design mobile-specific that are narrower, have less functionality, simpler navigation and smaller images. Redirect visitors to the mobile version based on device detection. Requires a subdomain like m.site.com or site.mobi.

Pros: Simply update code that already exists.
Cons: Your homepage needs to “work” on mobile browsers anyway, and an extra click is required to access your mobile version. It’s also double the maintenance – an update on your .com requires an update on your m.site.com or site.mobi (whatever you’re using).

3. Create a Mobile/Traditional Hybrid

Use your existing content, but create a CSS version for mobile (or multiple CSS designs for different mobile browsers).

Pros: Simply add another style sheet. No duplicate content problem because it’s just rendered differently as the browser pulls the sheet automatically.
Cons: No guarantee the browser will pull the right style sheet. And lots of work if you’re not already using CSS.

4. Use Dynamic Mobile Pages

Combine your content database with user agent (desktop vs. mobile) detection to transcode the site on-the-fly. You can target devices based on make, model and operating system.

Pros: Best option if you want to offer the best user experience and leverage your SEO efforts.
Cons: Expensive, requires custom coding. Also a short term solution since you need to re-do it with every new software release and new make/models of devices. More difficult to implement.

What Are the Implications for SEO?

Whenever you have duplicate content (a .com version and a .mobi copy, for example) you risk splitting your back links which can affect your SEO. (Plus you have to maintain and promote 2 sites). If you opt to ditch your .mobi version, make sure you do a 301 redirect from .mobi to your regular domain so you combine back link credit.

There are also no tools to check your mobile rankings, so from an SEO reporting standpoint, there’s a lot of gruntwork to keep track of it (not that I think this really matters).

Because Google exhibits no preference for a mobile version vs. a transcoded version, your decision needs to be made based upon how it currently renders on various mobile devices, the monetary and human resources you have today and in the future, and the importance of mobile to your business right now.

Final Things to Think About

I asked some SEO friends what their preference is, and here’s what they have to say:

Personally, I’d use device detection to display the same URLs differently on smart phones. Most people using smart phones will still use Google, Yahoo, or MSN search – not mobile search engines! This means the most relevant pages of a web site will be found, not those most appropriate for the device. So, even if you create new pages, sub-domains, or even sites for different devices, those aren’t likely to be the pages found in the search results … the existing site pages are –relevance over device type.

Longer term as Google continues to incorporate user behavior patterns into the reordering of search results, it will begin to consider the source of the search as well (ie. mobile device or desktop). Pages showing more favorable user behavior stats in response to search queries on mobile devices will begin to rank better for future searches from mobile devices. This of course means, device detection becomes much more important yet! SEOs will then have to worry a great deal more about managing devise specific user behavior, and not just user behavior in general.

- Jeff Quipp, Search Engine People

The number of websites out there that have a true mobile version of their websites is completely
insignificant. If Google or any search engine, were to start giving that small handful of sites a boost it would damage their relevancy.

If you are dead set on moving forward with a mobile version of your website, give you users the option to go back to the standard version of your website if they choose to. Most mobile websites are stripped down and lack features of the regular site. My iPhone will render your regular site so let me go there if I want.

- Todd Friesen, Range Online Media

Also consider that the most common use of the mobile web is email. When you send retail email offers, there’s a good chance your recipients are receiving them through their mobile devices. Having a link to a mobile version of your email creative and your online store may be effective, since once a message is opened, if it’s not bookmarked or marked as unread – it may be forgotten (unless it’s really remarkable).

Another consideration is what is the primary reason customers access your site? If you’re a pureplay online-only retailer, you might want to design your mobile site like Amazon – with a search box front and center. If you’re Target, it may be more helpful to link to a store locator or flyer.

To learn more about mobile commerce for retailers, do catch our on-demand webinar with Bill Mirabito of B2C Partners: Holiday Wish List for Mobile Commerce.