Running desktop and mobile versions of your site
One of the most common problems for webmasters who run both mobile and desktop versions of a site is that the mobile version of the site appears for users on a desktop computer, or that the desktop version of the site appears when someone accesses it on a mobile device. In dealing with this scenario, here are two viable options:

Redirect mobile users to the correct version
When a mobile user or crawler (like Googlebot-Mobile) accesses the desktop version of a URL, you can redirect them to the corresponding mobile version of the same page. Google notices the relationship between the two versions of the URL and displays the standard version for searches from desktops and the mobile version for mobile searches.

If you redirect users, please make sure that the content on the corresponding mobile/desktop URL matches as closely as possible (1). For example, if you run a shopping site and there's an access from a mobile phone to a desktop-version URL, make sure that the user is redirected to the mobile version of the page for the same product, and not to the homepage of the mobile version of the site. We occasionally find sites using this kind of redirect in an attempt to boost their search rankings, but this practice only results in a negative user experience, and so should be avoided at all costs.

(1) An example of redirecting a user to the mobile version of the URL when it's accessed from a mobile device. In this case, the content on both URLs needs to be as similar as possible.

On the other hand, when there's an access to a mobile-version URL from a desktop browser or by our web crawler, Googlebot, it's not necessary to redirect them to the desktop-version. For instance, Google doesn't automatically redirect desktop users from their mobile site to their desktop site; instead they include a link on the mobileversion page to the desktop version. These links are especially helpful when a mobile site doesn't provide the full functionality of the desktop version—users can easily navigate to the desktop-version if they prefer.

Switch content based on User-agent
Some sites have the same URL for both desktop and mobile content, but change their format according to User-agent. In other words, both mobile users and desktop users access the same URL (i.e. no redirects), but the content/format changes slightly according to the User-agent. In this case, the same URL will appear for both mobile search and desktop search, and desktop users can see a desktop version of the content while mobile users can see a mobile version of the content (2).

(2) Example of changing the format of a page based on the User-agent. In this case, the desktop user is supposed to see what Googlebot sees and the mobile user is supposed to see what Googlebot-mobile sees.

So what does "the page that the user sees" mean if you provide both versions with a URL? As I mentioned in the previous post, Google uses "Googlebot" for web search and "Googlebot-Mobile" for mobile search. To remain within our guidelines, you should serve the same content to Googlebot as a typical desktop user would see, and the same content to Googlebot-Mobile as you would to the browser on a typical mobile device. It's fine if the contents for Googlebot are different from those for Googlebot-Mobile.

One example of how you could be unintentionally detected as cloaking is if your site returns a message like "Please access from mobile phones" to desktop browsers, but then returns a full mobile version to both crawlers (so Googlebot receives the mobile version). In this case, the page which web search users see (e.g. "Please access from mobile phones") is different from the page which Googlebot crawls (e.g. "Welcome to my site"). Again, we detect cloaking because we want to serve users the same relevant content that Googlebot or Googlebot-Mobile crawled.

Configure mobile sites so that they can be indexed accurately
It seems the world is going mobile, with many people using mobile phones on a daily basis, and a large user base searching on Google’s mobile search page. However, as a webmaster, running a mobile site and tapping into the mobile search audience isn't easy. Mobile sites not only use a different format from normal desktop sites, but the management methods and expertise required are also quite different. This results in a variety of new challenges. While many mobile sites were designed with mobile viewing in mind, they weren’t designed to be search friendly.

Here are troubleshooting tips to help ensure that your site is properly crawled and indexed:

Verify that your mobile site is indexed by Google
If your web site doesn't show up in the results of a Google mobile search even using the site: operator, it may be that your site has one or both of the following issues:

1. Googlebot may not be able to find your site
Googlebot must crawl your site before it can be included in our search index. If you just created the site, we may not yet be aware of it. If that's the case, create a Mobile Sitemap and submit it to Google to inform us of the site’s existence. A Mobile Sitemap can be submitted using Google Webmaster Tools, just like a standard Sitemap.

2. Googlebot may not be able to access your site
Some mobile sites refuse access to anything but mobile phones, making it impossible for Googlebot to access the site, and therefore making the site unsearchable. Our crawler for mobile sites is "Googlebot-Mobile". If you'd like your site crawled, please allow any User-agent including "Googlebot-Mobile" to access your site (2). You should also be aware that Google may change its Useragent information at any time without notice, so we don't recommend checking whether the User-agent exactly matches "GooglebotMobile" (the current User-agent). Instead, check whether the Useragent header contains the string "Googlebot-Mobile". You can also use DNS Lookups to verify Googlebot.

(2) An example of a mobile site restricting any access from non-mobile devices. Please remember to allow access from user agents including “Googlebot-Mobile”.


Verify that Google can recognize your mobile URLs
Once Googlebot-Mobile crawls your URLs, we then check for whether each URL is viewable on a mobile device. Pages we determine aren't viewable on a mobile phone won't be included in our mobile site index (although they may be included in the regular web index). This determination is based on a variety of factors, one of which is the "DTD (Doc Type Definition)" declaration. Check that your mobile-friendly URLs' DTD declaration is in an appropriate mobile format such as XHTML Mobile or Compact HTML (3). If it's in a compatible format, the page is eligible for the mobile search index. For more information, see the Mobile Webmaster Guidelines.

(3) An example of DTD for mobile devices.

Combat comment spam with "nofollow"
Setting the value of the "rel" attribute of a link to "nofollow" will tell Google that certain links on your site shouldn't be followed or pass your page' s reput ati on to the pages l i nked to. Nofollowing a link is adding rel="nofollow" inside of the link's anchor tag (1).

<a href="http://www.shadyseo.com" rel="nofollow">Comment spammer</a>

(1) If you or your site's users link to a site that you don't trust and/or you don't want
to pass your site's reputation, use nofollow.

When would this be useful? If your site has a blog with public commenting turned on, links within those comments could pass your reputation to pages that you may not be comfortable vouching for. Blog comment areas on pages are highly susceptible to comment spam (2). Nofollowing these user-added links ensures that you're not giving your page's hard-earned reputation to a spammy site.

(2) A comment spammer leaves a message on one of our blogs posts, hoping to get some of our site's reputation.

Automatically add "nofollow" to comment columns and message boards
Many blogging software packages automatically nofollow user comments, but those that don't can most likely be manually edited to do this. This advice also goes for other areas of your site that may involve user-generated content, such as guestbooks, forums, shoutboards, referrer listings, etc. If you're willing to vouch for links added by third parties (e.g. if a commenter is trusted on your site), then there's no need to use nofollow on links; however, linking to sites that Google considers spammy can affect the reputation of your own site. The Webmaster Help Center has more tips on avoiding comment spam, like using CAPTCHAs and turning on comment moderation (3).

(3) An example of a CAPTCHA used on Google's blog service, Blogger. It can present a challenge to try to ensure an actual person is leaving the comment.

About using "nofollow" for individual contents, whole pages, etc.
Another use of nofollow is when you're writing content and wish to reference a website, but don't want to pass your reputation on to it. For example, imagine that you're writing a blog post on the topic of comment spamming and you want to call out a site that recently comment spammed your blog. You want to warn others of the site, so you include the link to it in your content; however, you certainly don't want to give the site some of your reputation from your link. This would be a good time to use nofollow.

Lastly, if you're interested in nofollowing all of the links on a page, you can use "nofollow" in your robots meta tag, which is placed inside the <head> tag of that page's HTML (4). The Webmaster Central Blog provides a helpful post on using the robots meta tag. This method is written as <meta name="robots" content="nofollow">.

<html>
<head>
<title>Brandon's Baseball Cards - Buy Cards, Baseball News, Card Prices</title>
<meta name="description=" content="Brandon's Baseball Cards provides a large selection of vintage and modern baseball cards for sale. We also offer daily baseball news and events in">
<meta name="robots" content="nofollow">
</head>
<body>

Best Practices
Use more secure methods for sensitive content
You shouldn't feel comfortable using robots.txt to block sensitive or confidential material. One reason is that search engines could still reference the URLs you block (showing just the URL, no title or snippet) if there happen to be links to those URLs somewhere on the Internet (like referrer logs). Also, non-compliant or rogue search engines that don't acknowledge the Robots Exclusion Standard could disobey the instructions of your robots.txt. Finally, a curious user could examine the directories or subdirectories in your robots.txt file and guess the URL of the content that you don't want seen. Encrypting the content or password-protecting it with .htaccess are more secure alternatives.
Avoid:

• allowing search result-like pages to be crawled                                                                                   -  users dislike leaving one search result page and landing on another search result page that doesn't add significant value for them  
• allowing URLs created as a result of proxy services to be crawled

Restrict crawling where it's not needed with robots.txt
A "robots.txt" file tells search engines whether they can access and therefore crawl parts of your site (1). This file, which must be named "robots.txt", is placed in the root directory of your site (2).

User-agent: *
Disallow: /images/
Disallow: /search

1) All compliant search engine bots (denoted by the wildcard * symbol) shouldn't access and crawl the content under /images/ or any URL whose path begins with / search.
2) The address of our robots.txt file.

You may not want certain pages of your site crawled because they might not be useful to users if found in a search engine's search results. If you do want to prevent search engines from crawling your pages, Google Webmaster Tools has a friendly robots.txt generator to help you create this file. Note that if your site uses subdomains and you wi sh to have certai n pages not crawl ed on a parti cul ar subdomain, you'll have to create a separate robots.txt file for that subdomain. For more information on robots.txt, we suggest this
Webmaster Help Center guide on using robots.txt files .

There are a handful of other ways to prevent content appearing in search results, such as adding "NOINDEX" to your robots meta tag, using .htaccess to password protect directories, and using Google Webmaster Tools to remove content that has already been crawled. Google engineer Matt Cutts walks through the caveats of each URL blocking method in a helpful video.

Best Practices
Use more secure methods for sensitive content
You shouldn't feel comfortable using robots.txt to block sensitive or confidential material. One reason is that search engines could still reference the URLs you block (showing just the URL, no title or snippet) if there happen to be links to those URLs somewhere on the Internet (like referrer logs). Also, non-compliant or rogue search engines that don't acknowledge the Robots Exclusion Standard could disobey the instructions of your robots.txt. Finally, a curious user could examine the directories or subdirectories in your robots.txt file and guess the URL of the content that you don't want seen. Encrypting the content or password-protecting it with .htaccess are more secure alternatives.
Avoid:

• allowing search result-like pages to be crawled                                                                                   -  users dislike leaving one search result page and landing on another search result page that doesn't add significant value for them  
• allowing URLs created as a result of proxy services to be crawled

Use heading tags to emphasize important text
Heading tags (not to be confused with the <head> HTML tag or HTTP headers) are used to present structure on the page to users. There are six sizes of heading tags, beginning with <h1>, the most important, and ending with <h6>, the least important (1).

</head>
<body>
<h1>Brandon's Baseball Cards</h1>
<h2>News - Treasure Trove of Baseball Cards Found in Old Barn</h2>
<p>A man who recently purchased a farm house was pleasantly surprised ... dollars worth of vintage baseball cards in the barn. The cards were ... in news papers and were thought to be in near-mint condition. After ... the cards to his grandson instead of selling them.</p>

(1) On a page containing a news story, we might put the name of our site into an <h1> tag and the topic of the story into an <h2> tag.

Since heading tags typically make text contained in them larger than normal text on the page, this is a visual cue to users that this text is important and could help them understand something about the type of content underneath the heading text. Multiple heading sizes used in order create a hierarchical structure for your content, making it easier for users to navigate through your document.

Imagine you're writing an outline
Similar to writing an outline for a large paper, put some thought into what the main points and subpoints of the content on the page will be and decide where to use heading tags appropriately.
Avoid:

• placing text in heading tags that wouldn't be helpful in defining the structure of the page  
• using heading tags where other tags like <em> and <strong> may be more appropriate  
• erratically moving from one heading tag size to another

Use headings sparingly across the page
Use heading tags where it makes sense. Too many heading tags on a page can make it hard for users to scan the content and determine where one topic ends and another begins.
Avoid:

• excessively using heading tags throughout the page  
• putting all of the page's text into a heading tag  
• using heading tags only for styling text and not presenting structure

Image-related information can be provided for by using the "alt" attribute
Images may seem like a straightforward component of your site, but you can optimize your use of them. All images can have a distinct filename and "alt" attribute, both of which you should take advantage of. The "alt" attribute allows you to specify alternative text for the image if it cannot be displayed for some reason (1).

(1) Our image wasn't displayed to the user for some reason, but at least the alt text was.

Why use this attribute? If a user is viewing your site on a browser that doesn't support images, or is using alternative technologies, such as a screen reader,  the contents of the al t attri bute provi de information about the picture.

Another reason is that if you're using an image as a link, the alt text for that image will be treated similarly to the anchor text of a text link. However, we don't recommend using too many images for links in your site's navigation when text links could serve the same purpose. Lastly, optimizing your image filenames and alt text makes it easier for image search projects like Google Image Search to better understand your images.

Store files in specialized directories and manage them using common file formats
Instead of having image files spread out in numerous directories and subdirectories across your domain, consider consolidating your images into a single directory (e.g. brandonsbaseballcards.com/ images/). This simplifies the path to your images.

Use commonly supported filetypes - Most browsers support JPEG, GIF, PNG, and BMP image formats. It's also a good idea to have the extension of your filename match with the filetype.

Use brief, but descriptive filenames and alt text
Like many of the other parts of the page targeted for optimization, filenames and alt text (for ASCII languages) are best when they're short, but descriptive.
Avoid:

• using generic filenames like "image1.jpg", "pic.gif", "1.jpg" when possible—some sites with thousands    of images might consider automating the naming of images  
• writing extremely lengthy filenames  
• stuffing keywords into alt text or copying and pasting entire sentences

Supply alt text when using images as links
If you do decide to use an image as a link, filling out its alt text helps Google understand more about the page you're linking to. Imagine that you're writing anchor text for a text link.
Avoid:

• writing excessively long alt text that would be considered spammy  
• using only image links for your site's navigation

Supply an Image Sitemap file
An Image Sitemap file can provide Googlebot with more information about the images found on your site. Its structure is similar to the XML Sitemap file for your web pages.