Now that 2013 is almost over, we'd love to take a quick look back, and venture a glimpse into the future. Some of the important topics on our blog from 2013 were around mobile, internationalization, and search quality in general. Here are some of the most popular new posts from this year:

• Changes in rankings of smartphone search results
• Introducing "x-default hreflang" for international landing pages
• 5 common mistakes with rel=canonical
• A reminder about selling links that pass PageRank
• View manual webspam actions in Webmaster Tools
• The Webmaster Academy goes international
• We created a first steps cheat sheet for friends & family
• In-depth articles in search results
• Make the most of Search Queries in Webmaster Tools
• rel="author" frequently asked (advanced) questions
• Getting started with structured data
• Backlinks and reconsideration requests
• Making smartphone sites load fast
• Easier recovery for hacked sites
• So long, 2013, and thanks for all the fish

It's been a busy year here on the blog. We hope that our posts here have helped to make these - sometimes complex - topics a bit easier to understand. Is there anything you would have wanted more information about? Let us know in the comments!

Our Help Forum and office hours hangouts have also been a place for helpful, insightful, and sometimes controversial discussions. It's not always easy to find ways to improve websites, or to solve technical & usability issues that users post about, so we're extremely thankful to have such a fantastic group of Top Contributors that give advice and provide feedback there.

Where are we headed in 2014? Only time will tell, but I'm sure we'll see more information for the general webmaster, hard-core technical advice, ways to make mobile sites even better, rockin' Webmaster Tools updates, tips on securing your site & its connections, and more. Are you ready? Don't forget your towel & let's go!

On behalf of all the webmaster help forum guides, we wish you happy holidays & a great 2014.

Posted by Zineb Ait Bahajji and John Mueller, Webmaster Trends Analysts

Webmaster level: advanced

Just over a year ago we introduced a new API for website verification for Google services. In the spirit of keeping things simple and focusing our efforts, we've decided to deprecate the old verification API method on March 31st, 2014. The rest of the API will remain unchanged, this only affects the verification method. For more information about verification in general, please see our site verification Help Center article.

One advantage of upgrading to the new API for verification is that it uses the same client libraries as most other Google APIs, which simplifies integration with other apps and tools. Getting started is easy, especially if you're used to other Google APIs:

1. Download the Google API client library for your favorite programming language.
2. Learn about the Site Verification API and its methods.
3. Allow your users to authenticate with OAuth.
4. Start verifying!

If you can't wait to try it out and are a fan of command lines, here's a shortcut:

1. Download and install oacurl.
2. Authenticate with a Google Account:
   $ java -cp oacurl-1.2.0.jar com.google.oacurl.Login \
  --scope https://www.googleapis.com/auth/siteverification
3. Request the verification information:
   $ echo '{ "verificationMethod": "FILE", "site": {
 "identifier": "http://www.example.com",
 "type": "SITE" } }' | \
 java -cp oacurl-1.2.0.jar com.google.oacurl.Fetch \
 'https://www.googleapis.com/siteVerification/v1/token' \
 --content-type JSON -X=POST
4. Create & add the file to your website, then verify:
   $ echo '{ "site": { "identifier": "http://www.example.com",
"type": "SITE" } }' | \
java -cp oacurl-1.2.0.jar com.google.oacurl.Fetch \
'https://www.googleapis.com/siteVerification/v1/webResource?verificationMethod=FILE' \
--content-type JSON -X=POST
5. Done!

We hope this API will make it easier to implement Google site verification in your projects. Should you have any questions, feel free to comment here, or post in our Webmaster Help Forum.

Posted by John Mueller, fan of long command lines & Webmaster Trends Analyst

Webmaster level: all

Content on the Internet changes or disappears, and occasionally it's helpful to have search results for it updated quickly. Today we launched our improved public URL removal tool to make it easier to request updates based on changes on other people's websites. You can find it at https://www.google.com/webmasters/tools/removals

This tool is useful for removals on other peoples' websites. You could use this tool if a page has been removed completely, or if it was just changed and you need to have the snippet & cached page removed. If you're the webmaster of the site, then using the Webmaster Tools URL removal feature is faster & easier.

How to request a page be removed from search results

If the page itself was removed completely, you can request that it's removed from Google's search results. For this, it's important that the page returns the proper HTTP result code (403, 404, or 410), has a noindex robots meta tag, or is blocked by the robots.txt (blocking via robots.txt may not prevent indexing of the URL permanently). You can check the HTTP result code with a HTTP header checker. While we attempt to recognize "soft-404" errors, having the website use a clear response code is always preferred. Here's how to submit a page for removal:

1. Enter the URL of the page. As before, this needs to be the exact URL as indexed in our search results. Here's how to find the URL.
2. The analysis tool will confirm that the page is gone. Confirm the request to complete the submission.
3. There's no step three!
   

How to request a page's cache & snippet be removed from search results

If the page wasn't removed, you can also use this tool to let us know that a text on a page (such as a name) has been removed or changed. It'll remove the snippet & cached page in Google's search results until our systems have been able to reprocess the page completely (it won't affect title or ranking). In addition to the page's URL, you'll need at least one word that used to be on the page but is now removed. You can learn more about cache removals in our Help Center.

1. Enter the URL of the page which has changed. This needs to be the exact URL as indexed in our search results. Here's how to find the URL.
2. Confirm that the page has been updated or removed, and confirm that the cache & snippet are outdated (do not match the current content).
3. Now, enter a word that no longer appears on the live page, but which is still visible in the cache or snippet. See our previous blog post on removals for more details.

You can find out more about URL removals in our Help Center, as well as in our earlier blog posts on removing URLs & directories, removing & updating cached content, removing content you don't own, and tracking requests + what not to remove.

We hope these changes make it easier for you to submit removal requests! We welcome your feedback in our removals help forum category, where other users may also be able to help with more complicated removal issues.

Posted by John Mueller, Webmaster Trends Analyst

Since we launched the Structured Data dashboard last year, it has quickly become one of the most popular features in Webmaster Tools. We’ve been working to expand it and make it even easier to debug issues so that you can see how Google understands the marked-up content on your site.

Starting today, you can see items with errors in the Structured Data dashboard. This new feature is a result of a collaboration with webmasters, whom we invited in June to>register as early testers of markup error reporting in Webmaster Tools. We’ve incorporated their feedback to improve the functionality of the Structured Data dashboard.

An “item” here represents one top-level structured data element (nested items are not counted) tagged in the HTML code. They are grouped by data type and ordered by number of errors:

We’ve added a separate scale for the errors on the right side of the graph in the dashboard, so you can compare items and errors over time. This can be useful to spot connections between changes you may have made on your site and markup errors that are appearing (or disappearing!).

Our data pipelines have also been updated for more comprehensive reporting, so you may initially see fewer data points in the chronological graph.

How to debug markup implementation errors

1. To investigate an issue with a specific content type, click on it and we’ll show you the markup errors we’ve found for that type. You can see all of them at once, or filter by error type using the tabs at the top:



2. Check to see if the markup meets the implementation guidelines for each content type. In our example case (events markup), some of the items are missing a startDate or name property. We also surface missing properties for nested content types (e.g. a review item inside a product item) — in this case, this is the lowprice property.
3. Click on URLs in the table to see details about what markup we’ve detected when we crawled the page last and what’s missing. You’ll can also use the “Test live data” button to test your markup in the Structured Data Testing Tool. Often when checking a bunch of URLs, you’re likely to spot a common issue that you can solve with a single change (e.g. by adjusting a setting or template in your content management system).



4. Fix the issues and test the new implementation in the Structured Data Testing Tool. After the pages are recrawled and reprocessed, the changes will be reflected in the Structured Data dashboard.

We hope this new feature helps you manage the structured data markup on your site better. We will continue to add more error types in the coming months. Meanwhile, we look forward to your comments and questions here or in the dedicated Structured Data section of the Webmaster Help forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Webmaster Level: Intermediate to Advanced

Unsure where to begin improving your smartphone website? Wondering how to prioritize all the advice? We just published a checklist to help provide an efficient approach to mobile website improvement. Several topics in the checklist link to a relevant business case or study, other topics include a video explaining how to make data from Google Analytics and Webmaster Tools actionable during the improvement process. Copied below are shortened sections of the full checklist. Please let us know if there’s more you’d like to see, or if you have additional topics for us to include.

Step 1: Stop frustrating your customers

• Remove cumbersome extra windows from all mobile user-agents | Google recommendation, Article
  • JavaScript pop-ups that can be difficult to close.
  • Overlays, especially to download apps (instead consider a banner such as iOS 6+ Smart App Banners or equivalent, side navigation, email marketing, etc.).
  • Survey requests prior to task completion.


• Provide device-appropriate functionality
  • Remove features that require plugins or videos not available on a user's device (e.g., Adobe Flash isn't playable on an iPhone or on Android versions 4.1 and higher). | Business case
  • Serve tablet users the desktop version (or if available, the tablet version). | Study
  • Check that full desktop experience is accessible on mobile phones, and if selected, remains in full desktop version for duration of the session (i.e., user isn't required to select "desktop version" after every page load). | Study


• Correct high traffic, poor user-experience mobile pages
  
  
  
  How to correct high-traffic, poor user-experience mobile pages with data from Google Analytics bounce rate and events (slides)


• Make quick fixes in performance (and continue if behind competition) | Business case



How to make quick fixes in mobile site performance and compare your site to the competition (slides)

To see all topics in “Stop frustrating your customers,” please see the full Checklist for mobile website improvement.

Step 2: Facilitate task completion

• Optimize crawling, indexing, and the searcher experience | Business case
  
  • Unblock resources (CSS, JavaScript) that are robots.txt disallowed.
  • Implement search-engine best practices given your mobile implementation:
    • Responsive design: Be sure to include CSS @media query.
    • Separate mobile site: Add rel=alternate media and rel=canonical, as well as Vary: User-Agent HTTP Header which helps Google implement Skip Redirect.
    • Dynamic serving: Include Vary: User-Agent HTTP header.
  
  
• Optimize popular mobile persona workflows for your site
  
  
  How to optimize popular mobile workflows using Google Webmaster Tools and Google Analytics (slides)

Step Three: Convert customers into fans!

• Consider search integration points with mobile apps | Announcement, Information


• Brainstorm new ways to provide value
  • Build for mobile behavior, such as the in-store shopper. | Business case
  • Leverage smartphone GPS, camera, accelerometer.
  • Increase sharing or social behavior. | Business case
  • Consider intuitive/fun tactile functionality with swiping, shaking, tapping.

Written by Maile Ohye, Developer Programs Tech Lead

Webmaster level: all

Some smartphone-optimized websites are misconfigured in that they don't show searchers the information they were seeking. For example, smartphone users are shown an error page or get redirected to an irrelevant page, but desktop users are shown the content they wanted. Some of these problems, detected by Googlebot as crawl errors, significantly hurt your website's user experience and are the basis of some of our recently-announced ranking changes for smartphone search results.

Starting today, you can use the expanded Crawl Errors feature in Webmaster Tools to help identify pages on your sites that show these types of problems. We're introducing a new Smartphone errors tab where we share pages we've identified with errors only found with Googlebot for smartphones.

Some of the errors we share include:

• Server errors: A server error is when Googlebot got an HTTP error status code when it crawled the page.

• Not found errors and soft 404s: A page can show a "not found" message to Googlebot, either by returning an HTTP 404 status code or when the page is detected as a soft error page.

• Faulty redirects: A faulty redirect is a smartphone-specific error that occurs when a desktop page redirects smartphone users to a page that is not relevant to their query. A typical example is when all pages on the desktop site redirect smartphone users to the homepage of the smartphone-optimized site.

• Blocked URLs: A blocked URL is when the site's robots.txt explicitly disallows crawling by Googlebot for smartphones. Typically, such smartphone-specific robots.txt disallow directives are erroneous. You should investigate your server configuration if you see blocked URLs reported in Webmaster Tools.

Fixing any issues shown in Webmaster Tools can make your site better for users and help our algorithms better index your content. You can learn more about how to build smartphone websites and how to fix common errors. As always, please ask in our forums if you have any questions.

Posted by Pierre Far, Webmaster Trends Analyst

Webmaster Level: Intermediate

Wondering how to begin creating an organic search strategy at your company? What’s a good way to integrate your company’s various online components, such as the website, blog, or YouTube channel? Perhaps we can help! In under fifteen minutes, I outline a strategic approach to SEO for a mock company, Webmaster Central, where I pretend to be the SEO managing the Webmaster Central Blog.

Fifteen-minute video to help your create the SEO strategy at your company

The video covers these high-level topics (and you can skip to the exact portion of the video that might be of interest):

Creating a SEO strategy

• Using Webmaster Central as mock company
• Building an SEO strategy
1. Understand searcher persona workflow
2. Determine company and website goals
3. Audit your site to best reach your audience
4. Execute and make improvements
• Overcoming obstacles

Feel free to reference the slides as well.

Written by Maile Ohye, Developer Programs Tech Lead

Webmaster Level: Advanced

Searchers on smartphones experience many speed bumps that can slow them down. For example, any time they need to change context from a web page to an app, or vice versa, users are likely to encounter redirects, pop-up dialogs, and extra swipes and taps. Wouldn't it be cool if you could give your users the choice of viewing your content either on the website or via your app, both straight from Google's search results?
Today, we’re happy to announce a new capability of Google Search, called app indexing, that uses the expertise of webmasters to help create a seamless user experience across websites and mobile apps.
Just like it crawls and indexes websites, Googlebot can now index content in your Android app. Webmasters will be able to indicate which app content you'd like Google to index in the same way you do for webpages today — through your existing Sitemap file and through Webmaster Tools. If both the webpage and the app contents are successfully indexed, Google will then try to show deep links to your app straight in our search results when we think they’re relevant for the user’s query and if the user has the app installed. When users tap on these deep links, your app will launch and take them directly to the content they need. Here’s an example of a search for home listings in Mountain View:

We’re currently testing app indexing with an initial group of developers. Deep links for these applications will start to appear in Google search results for signed-in users on Android in the US in a few weeks. If you are interested in enabling indexing for your Android app, it’s easy to get started:

1. Let us know that you’re interested. We’re working hard to bring this functionality to more websites and apps in the near future.
2. Enable deep linking within your app.
3. Provide information about alternate app URIs, either in the Sitemaps file or in a link element in pages of your site.

For more details on implementation and for information on how to sign up, visit our developer site. As always, if you have any questions, please ask in the mobile section of our webmaster forum.


Posted by Lawrence Chang, Product Manager

Webmaster Level: All

We know that as a site owner, discovering your site is hacked with spam or malware is stressful, and trying to clean it up under a time constraint can be very challenging. We’ve been working to make recovery even easier and streamline the cleaning process — we notify webmasters when the software they’re running on their site is out of date, and we’ve set up a dedicated help portal for hacked sites with detailed articles explaining each step of the process to recovery, including videos.
Today, we’re happy to introduce a new feature in Webmaster Tools called Security Issues.
As a verified site owner, you’ll be able to:

• Find more information about the security issues on your site, in one place.
• Pinpoint the problem faster with detailed code snippets.
• Request review for all issues in one go through the new simpified process.

Find more information about the security issues on your site, in one place
Now, when we’ve detected your site may have been hacked with spam or with malware, we’ll show you everything in the same place for easy reference. Information that was previously available in the Malware section of Webmaster Tools, as well as new information about spam inserted by hackers, is now available in Security Issues. On the Security Issues main page, you’ll see the type of hacking, sample URLs if available, and the date when we last detected the issue.

Pinpoint the problem faster with detailed code snippets
Whenever possible, we’ll try to show you HTML and JavaScript code snippets from the hacked URLs and list recommended actions to help you clean up the specific type of hacking we’ve identified.

Request review for all issues in one go
We’ve also simplified requesting a review. Once you’ve cleaned your site and closed the security holes, you can request a review for all issues with one click of a button straight from the Security Issues page.

If you need more help, our updated and expanded help for hacked sites portal is now available in 22 languages. Let us know what you think in the comments here or at the Webmaster Help Forum.


Posted by Meenali Rungta, Webspam Team and Hadas Fester, Webmaster Tools Team

Webmaster Level: Intermediate to Advanced

We filmed a video providing more details about expanding your site to more languages or country-based language variations. The video covers details about rel=”alternate” hreflang and potential implementation on your multilingual and/or multinational site.

Video and slides on expanding your site to more languages

You can watch the entire video or skip to the relevant sections:

• Potential search issues with international sites
• Questions to ask within your company before beginning international expansion
• International site use cases
• rel=”alternate” hreflang and hreflang=”x-default”: details and implementation
• Best practices

Additional resources on hreflang include:

• Webmaster Help Center article on rel=”alternate” hreflang and hreflang=”x-default”
• More blog posts
• Working with multilingual sites
• Working with multiregional sites
• New markup for multilingual content
• Introducing "x-default hreflang” for international landing pages"
• Webmaster discussion forum FAQ on internationalization
• Webmaster discussion forum for internationalization (review answers or post your own question!)

Good luck as you expand your site to more languages!

Written by Maile Ohye, Developer Programs Tech Lead

Webmaster level: intermediate

In recent years, our free Webmaster Tools product has provided roughly 100,000 backlinks when you click the "Download more sample links" button. Until now, we've selected those links primarily by lexicographical order. That meant that for some sites, you didn't get as complete of a picture of the site's backlinks because the link data skewed toward the beginning of the alphabet.

Based on feedback from the webmaster community, we're improving how we select these backlinks to give sites a fuller picture of their backlink profile. The most significant improvement you'll see is that most of the links are now sampled uniformly from the full spectrum of backlinks rather than alphabetically. You're also more likely to get example links from different top-level domains (TLDs) as well as from different domain names. The new links you see will still be sorted alphabetically.

Starting soon, when you download your data, you'll notice a much broader, more diverse cross-section of links. Site owners looking for insights into who recommends their content will now have a better overview of those links, and those working on cleaning up any bad linking practices will find it easier to see where to spend their time and effort.

Thanks for the feedback, and we'll keep working to provide helpful data and resources in Webmaster Tools. As always, please ask in our forums if you have any questions.

Posted by Yinnon Haviv, Software Engineer, Webmaster Tools Team

Webmaster Level: Intermediate to Advanced

Using authorship helps searchers discover great information by highlighting content from authors who they might find interesting. If you’re an author, signing up for authorship will help users recognize content that you’ve written. Additionally, searchers can click the byline to see more articles you’ve authored or to follow you on Google+. It’s that simple! Well, except for several advanced questions that we’d like to help answer...

Authorship featured in search results from one of my favorite authors, John Mueller


Clicking the author’s byline in search results can reveal more articles and a Google+ profile

Recent authorship questions

1. What kind of pages can be used with authorship?

Good question! You can increase the likelihood that we show authorship for your site by only using authorship markup on pages that meet these criteria:

• The URL/page contains a single article (or subsequent versions of the article) or single piece of content, by the same author. This means that the page isn’t a list of articles or an updating feed. If the author frequently switches on the page, then the annotation is no longer helpful to searchers and is less likely to be featured.
• The URL/page consists primarily of content written by the author.
• Showing a clear byline on the page, stating the author wrote the article and using the same name as used on their Google+ profile.

2. Can I use a company mascot as an author and have authorship annotation in search results? For my pest control business, I’d like to write as the “Pied Piper.”

You’re free to write articles in the manner you prefer -- your users may really like the Pied Piper idea. However, for authorship annotation in search results, Google prefers to feature a human who wrote the content. By doing so, authorship annotation better indicates that a search result is the perspective of a person, and this helps add credibility for searchers.

Again, because currently we want to feature people, link authorship markup to an individual’s profile rather than linking to a company’s Google+ Page.

3. If I use authorship on articles available in different languages, such as
example.com/en/article1.html for English and
example.com/fr/article1.html for the French translation,
should I link to two separate author/Google+ profiles written in each language?

In your scenario, both articles:
example.com/en/article1.html
and
example.com/fr/article1.html
should link to the same Google+ profile in the author’s language of choice.

4. Is it possible to add two authors for one article?

In the current search user interface, we only support one author per article, blog post, etc. We’re still experimenting to find the optimal outcome for searchers when more than one author is specified.

5. How can I prevent Google from showing authorship?

The fastest way to prevent authorship annotation is to make the author’s Google+ profile not discoverable in search results. Otherwise, if you still want to keep your profile in search results, then you can remove any profile or contributor links to the website, or remove the markup so that it no longer connects with your profile.

6. What’s the difference between rel=author vs rel=publisher?

rel=publisher helps a business create a shared identity by linking the business’ website (often from the homepage) to the business’ Google+ Page. rel=author helps individuals (authors!) associate their individual articles from a URL or website to their Google+ profile. While rel=author and rel=publisher are both link relationships, they’re actually completely independent of one another.

7. Can I use authorship on my site’s property listings or product pages since one of my employees has customized the description?

Authorship annotation is useful to searchers because it signals that a page conveys a real person’s perspective or analysis on a topic. Since property listings and product pages are less perspective/analysis oriented, we discourage using authorship in these cases. However, an article about products that provides helpful commentary, such as, “Camera X vs. Camera Y: Faceoff in the Arizona Desert” could have authorship.

If you have additional questions, don’t forget to check out (and even post your question if you don’t see it covered :) in the Webmaster Forum.

Written by Maile Ohye, Developer Programs Tech Lead

Webmaster level: Intermediate

Users tell us they use smartphones to search online because it’s quick and convenient, but today’s average mobile page typically takes more than 7 seconds to load. Wouldn’t it be great if mobile pages loaded in under one second? Today we’re announcing new guidelines and an updated PageSpeed Insights tool to help webmasters optimize their mobile pages for best rendering performance.

Prioritizing above-the-fold content

Research shows that users’ flow is interrupted if pages take longer than one second to load. To deliver the best experience and keep the visitor engaged, our guidelines focus on rendering some content, known as the above-the-fold content, to users in one second (or less!) while the rest of the page continues to load and render in the background. The above-the-fold HTML, CSS, and JS is known as the critical rendering path.

We can achieve sub-second rendering of the above-the-fold content on mobile networks by applying the following best practices:

• Server must render the response (< 200 ms)
• Number of redirects should be minimized
• Number of roundtrips to first render should be minimized
• Avoid external blocking JavaScript and CSS in above-the-fold content
• Reserve time for browser layout and rendering (200 ms)
• Optimize JavaScript execution and rendering time

These are explained in more details in the mobile-specific help pages, and, when you’re ready, you can test your pages and the improvements you make using the PageSpeed Insights
tool.

As always, if you have any questions or feedback, please post in our discussion group.

Posted by Bryan McQuade, Software Engineer, and Pierre Far, Webmaster Trends Analyst

Webmaster level: All

We strive to keep spam out of our users’ search results. This includes both improving our webspam algorithms as well as taking manual action for violations of our quality guidelines. Many webmasters want to see if their sites are affected by a manual webspam action, so today we’re introducing a new feature that should help. The manual action viewer in Webmaster Tools shows information about actions taken by the manual webspam team that directly affect that site’s ranking in Google’s web search results. To try it out, go to Webmaster Tools and click on the “Manual Actions” link under “Search Traffic."

You’ll probably see a message that says, “No manual webspam actions found.” A recent analysis of our index showed that well under 2% of domains we've seen are manually removed for webspam. If you see this message, then your site doesn't have a manual removal or direct demotion for webspam reasons.

If your site is in the very small fraction that do have a manual spam action, chances are we’ve already notified you in Webmaster Tools. We’ll keep sending those notifications, but now you can also do a live check against our internal webspam systems. Here’s what it would look like if Google had taken manual action on a specific section of a site for "User-generated spam":

In this hypothetical example, there isn’t a site-wide match, but there is a “partial match." A partial match means the action applies only to a specific section of a site. In this case, the webmaster has a problem with other people leaving spam on mattcutts.com/forum/. By fixing this common issue, the webmaster can not only help restore his forum's rankings on Google, but also improve the experience for his users. Clicking the "Learn more" link will offer new resources for troubleshooting.

Once you’ve corrected any violations of Google’s quality guidelines, the next step is to request reconsideration. With this new feature, you'll find a simpler and more streamlined reconsideration request process. Now, when you visit the reconsideration request page, you’ll be able to check your site for manual actions, and then request reconsideration only if there’s a manual action applied to your site. If you do have a webspam issue to address, you can do so directly from the Manual Actions page by clicking "Request a review."

The manual action viewer delivers on a popular feature request. We hope it reassures the vast majority of webmasters who have nothing to worry about. For the small number of people who have real webspam issues to address, we hope this new information helps speed up the troubleshooting. If you have questions, come find us in the Webmaster Help Forum or stop by our Office Hours.

Update (12:50pm PT, August 9th): Unfortunately we've hit a snag during our feature deployment, so it will be another couple days before the feature is available to everyone. We will post another update once the feature is fully rolled out.

Update (10:30am PT, August 12th): The feature is now fully rolled out.

Posted by Matt Cutts, Distinguished Engineer

Note: The information in this post is outdated. Rel=prev/next is not an indexing signal anymore.

Webmaster level: all

Users often turn to Google to answer a quick question, but research suggests that up to 10% of users’ daily information needs involve learning about a broad topic. That’s why today we’re introducing new search results to help users find in-depth articles.

These results are ranked algorithmically based on many signals that look for high-quality, in-depth content. You can help our algorithms understand your pages better by following these recommendations:

• use schema.org “article” markup,
  
• provide authorship markup,
  
• rel=next and rel=prev for paginated articles (also watch out for common rel=canonical mistakes),
  
• provide information about your organization’s logo,
  
• and of course, create compelling in-depth content.
  

Following these best practices along with our webmaster guidelines helps our systems to better understand your website’s content, and improves the chances of it appearing in this new set of search results.

The in-depth articles feature is rolling out now on google.com in English. For more information, check out our help center article, and feel free to post in the comments in our forums.

Posted by Pandu Nayak, Member of Technical Staff

Webmaster level: All

Our quality guidelines prohibit manipulative or deceptive behavior, and this stance has remained unchanged since the guidelines were first published over a decade ago. Recently, we’ve seen some user complaints about a deceptive technique which inserts new pages into users’ browsing histories. When users click the "back" button on their browser, they land on a new page that they've never visited before. Users coming from a search results page may think that they’re going back to their search results. Instead, they’re taken to a page that looks similar, but is actually entirely advertisements:

To protect our users, we may take action on, including removal of, sites which violate our quality guidelines, including for inserting deceptive or manipulative pages into a user's browser history. As always, if you believe your site has been impacted by a manual spam action and is no longer violating our guidelines, you can let us know by requesting reconsideration.

Posted by Michael Wyszomierski, Search Quality Team

Webmaster level: All

Today we’re unveiling a shiny new navigation in Webmaster Tools. The update will make the features you already use easier to find, as well as unveil some exciting additions.

Navigation reflects how search works

We’ve organized the Webmaster Tools features in groups that match the stages of search:

• Crawl: see information about how we discover and crawl your content. Here you will find crawl stats, crawl errors, any URLs you’ve blocked from crawling, Sitemaps, URL parameters, and the Fetch as Google feature.
  
• Google Index: keep track of how many of your pages are in Google’s index and how we understand their content: you can monitor the overall indexed counts for your site (Index Status), see what keywords we’ve found on your pages (Content Keywords), or request to remove URLs from the search results.
• Search Traffic: check how your pages are doing in the search results — how people find your site (Search Queries), who’s recommended your site (Links to Your Site), and see a sample of pages from your site that have incoming links from other internal pages.
• Search Appearance: mark up your pages to help Google understand your content better during indexing and potentially influence how your pages appear in our search results. This includes the Structured Data dashboard, Data Highlighter, Sitelinks, and HTML Improvements.

Account-level administrative tasks now accessible from the Settings menu

Account-level admin tasks such as setting User permissions, Site Settings, and Change of Address are now grouped under the gear icon in the top right corner so they’re always accessible to you:

This is the list of items as visible to site owners, “full” or “restricted” users will see a subset of these options. For example, if you're a “restricted” user for a site, the "Users & Site Owners" menu item will not appear.

New Search Appearance pop-up

Beginner webmasters will appreciate the new Search Appearance pop-up, which can be used to visualize how your site may appear in search and learn more about the content or structure changes that may help to influence each element:

To access the pop-up window, click on the question mark icon next to the Search Appearance menu in the side navigation.

It includes the essential search result elements like title, snippet and URL, as well as optional elements such as sitelinks, breadcrumbs, search within a site, event and product rich snippets, and authorship information.

We hope the new navigation makes it easier for you to make the most of Webmaster Tools. As always, if you have additional questions, feel free to post in the Webmaster Help Forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Webmaster level: all

We're now offering webmasters an easy and free way to collect feedback from your website visitors with website satisfaction surveys. All you have to do is paste a small snippet of code in the HTML for your website and this will load a discreet satisfaction survey in the lower right hand corner of your website. Google automatically aggregates and analyzes responses, providing the data back to you through a simple online interface.

Users will be asked to complete a four-question satisfaction survey. Surveys will run until they have received 500 responses and will start again after 30 days so you can track responses over time. This is currently limited to US English visitors on non-mobile devices. The default questions are free and you can customize questions for just $0.01 per response or $5.00 for 500 responses.

Survey Setup and Code Placement Tips To set up the survey code, you'll need to have access to the source code for your website.

1. Sign into Google Consumer Surveys for website satisfaction to find the code snippet.
2. You have the option to enter the website name and URL, survey timing, and survey frequency.
3. Click on the “Activate survey” button when ready.
4. Once you find the code snippet on top of the setup page, copy and paste it into your web page, just before the closing </head> tag. If your website uses templates to generate pages, enter it just before the closing </head> tag in the file that contains the <head> section.

If  you have any questions, please read our Help Center article to learn more.

Posted by Marisa Currie-Rose

Webmaster level: advanced

When talking to site owners on Google Webmaster Forums we come across questions on reconsideration requests and how to handle backlink-related issues. Here are some common questions, along with our recommendations.

When should I file a reconsideration request?

If your site violates our Google Quality Guidelines or did in the past, a manual spam action may be applied to your site to prevent spam in our search results. You may learn about this violation from a notification in Google Webmaster Tools, or perhaps from someone else such as a previous owner or SEO of the site. To get this manual action revoked, first make sure that your site no longer violates the quality guidelines. After you've done that, it's time to file a reconsideration request.

Should I file a reconsideration request if I think my site is affected by an algorithmic change?

Reconsideration requests are intended for sites with manual spam actions. If your site’s visibility has been solely affected by an algorithmic change, there's no manual action to be revoked, and therefore no need to file a reconsideration request. If you're unsure if it's an algorithmic change or a manual action, and have found issues that you have resolved, then submitting a reconsideration request is fine.

How can I assess the quality of a site’s backlinks?

The links to your site section of Google Webmaster Tools is a great starting point for an investigation as it shows a significant amount of your site’s inbound links. If you know that you ran an SEO campaign during a particular period of time, downloading the latest links can come handy in slicing links created at that time. Using the links found in Google Webmaster Tools, we recommend looking for patterns that point to general issues that are worth resolving. For example, spammy blog comments, auto generated forum posts or text advertisements with links that pass PageRank are likely to be seen as unnatural links and would violate Google’s quality guidelines. For individual examples and hands-on advice we recommend getting help of peers and expert webmasters on the Google Webmaster Forum.

How do I clean a bad backlink profile?

Make sure to identify poor links first, then make a strong effort to get them either removed or nofollowed. Then use the Disavow Links Tool to deal with remaining unnatural backlinks. We recommend using domain-wide operator for sites with a complicated URL structure, very obvious spam sites, such as gibberish content sites or low quality sites with content that shows no editorial value. See our video on common mistakes when using the disavow tool for more information.

How much information do I need to provide?

Detailed documentation submitted along with a reconsideration request can contribute to its success, as it demonstrates the efforts made by the webmaster and helps Googlers with their investigation. If you are including a link to a shared document, make sure that it’s accessible to anyone with the link.

How long does it take to process reconsideration requests?

Reconsideration requests for sites affected by a manual spam action are investigated by a Googler. We strive to respond in a timely manner, normally within just a few days. However, the volume of incoming reconsideration requests can vary considerably, hence we don't provide a guaranteed turnaround time.

What are the possible outcomes of a reconsideration request?

Upon submitting a reconsideration request, you will first receive an automated confirmation in Google Webmaster Tools. After your request is processed, we'll send you another message to let you know the outcome of the request. In most cases, this message will either inform you that the manual action has been revoked or that your site still violates our quality guidelines.

Where can I get more guidance?

For more information on reconsideration requests, please visit our Help Center. And as always, the Google Webmaster Forum is a great place for further discussions as well as seeking more advice from experienced webmasters and Google guides.

Written by Kaspar Szymanski and Uli Lutz, Search Quality Team

Webmaster level: Intermediate

If you use Google Tag Manager to add and update your site tags, now you can quickly and easily verify ownership of your site in Webmaster Tools using the container snippet code.

Here’s how it’s done:

1. On the Webmaster Tools home page, click Manage site for the site you’d like to verify, then select Verify this site. If you haven’t added the site yet, you can click the Add a site button in the top right corner.

To do this, you must have "View, Edit, and Manage" account level permissions in Google Tag Manager.

2. On the Verification page, select Google Tag Manager as the verification method and follow the steps on your screen.

3. Click Verify.

And you’re done!

If you’ve got any questions about this verification method, drop by the Webmaster Help Forum.

Posted by Mariya Moeva, Webmaster Trends Analyst

Webmaster level: Intermediate

Smartphone users are a significant and fast growing segment of Internet users, and at Google we want them to experience the full richness of the web. As part of our efforts to improve the mobile web, we published our recommendations and the most common configuration mistakes.

Avoiding these mistakes helps your smartphone users engage with your site fully and helps searchers find what they're looking for faster. To improve the search experience for smartphone users and address their pain points, we plan to roll out several ranking changes in the near future that address sites that are misconfigured for smartphone users.

Let's now look at two of the most common mistakes and how to fix them.

Faulty redirects

Some websites use separate URLs to serve desktop and smartphone users. A faulty redirect is when a desktop page redirects smartphone users to an irrelevant page on the smartphone-optimized website. A typical example is when all pages on the desktop site redirect smartphone users to the homepage of the smartphone-optimized site. For example, in the figure below, the redirects shown as red arrows are considered faulty:

This kind of redirect disrupts a user's workflow and may lead them to stop using the site and go elsewhere. Even if the user doesn't abandon the site, irrelevant redirects add more work for them to handle, which is particularly troublesome when they're on slow mobile networks. These faulty redirects frustrate users whether they're looking for a webpage, video, or something else, and our ranking changes will affect many types of searches.

Avoiding irrelevant redirects is very easy: Simply redirect smartphone users from a desktop page to its equivalent smartphone-optimized page. If the content doesn't exist in a smartphone-friendly format, showing the desktop content is better than redirecting to an irrelevant page.

We have more tips about redirects, and be sure to read our recommendations for having separate URLs for desktop and smartphone users.

Smartphone-only errors

Some sites serve content to desktop users accessing a URL but show an error page to smartphone users. There are many scenarios where smartphone-only errors are seen. Some common ones are:

• If you recognize a user is visiting a desktop page from a mobile device and you have an equivalent smartphone-friendly page at a different URL, redirect them to that URL instead of serving a 404 or a soft 404 page.

• Make sure that the smartphone-friendly page itself is not an error page. If your content is not available in a smartphone-friendly format, serve the desktop page instead. Showing the content the user was looking for is a much better experience than showing an error page.

• Incorrectly handling Googlebot-Mobile. A typical mistake is when Googlebot-Mobile for smartphones is incorrectly redirected to the website optimized for feature phones which, in turn, redirects Googlebot-Mobile for smartphones back to desktop site. This results in infinite redirect loop, which we recognize as error.

  Avoiding this mistake is easy: All Googlebot-Mobile user-agents identify themselves as specific mobile devices, and you should treat these Googlebot user-agents exactly like you would treat these devices. For example, Googlebot-Mobile for smartphones currently identifies itself as an iPhone and you should serve it the same response an iPhone user would get.

• Unplayable videos on smartphone devices. Many websites embed videos in a way that works well on desktops but is unplayable on smartphone devices. For example, if content requires Adobe Flash, it won't be playable on an iPhone or on Android versions 4.1 and higher.

Although we covered only two types of mistakes here, it's important for webmasters to focus on avoiding all of the common smartphone website misconfigurations. Try to test your site on as many different mobile devices and operating systems, or their emulators, as possible, including testing the videos included on your site. Doing so will improve the mobile web, make your users happy, and allow searchers to experience your content fully.

As always, please ask in our forums if you have any questions.

By Yoshikiyo Kato, Software Engineer, on behalf of Mobile Search team, and Pierre Far, Webmaster Trends Analyst

Note from the editors: After previously looking into various ways to handle internationalization for Google’s web-search, here’s a post from Google Web Studio team members with tips for web developers.

Many websites exist in more than one language, and more and more websites are made available for more than one language. Yet, building a website for more than one language doesn’t simply mean translation, or localization (L10N), and that’s it. It requires a few more things, all of which are related to internationalization (I18N). In this post we share a few tips for international websites.

1. Make pages I18N-ready in the markup, not the style sheets

Language and directionality are inherent to the contents of the document. If possible you should hence always use markup, not style sheets, for internationalization purposes. Use @lang and @dir, at least on the html element:

<html lang="ar" dir="rtl">

Avoid coming up with your own solutions like special classes or IDs.

As for I18N in style sheets, you can’t always rely on CSS: The CSS spec defines that conforming user agents may ignore properties like direction or unicode-bidi. (For XML, the situation changes again. XML doesn’t offer special internationalization markup, so here it’s advisable to use CSS.)

2. Use one style sheet for all locales

Instead of creating separate style sheets for LTR and RTL directionality, or even each language, bundle everything in one style sheet. That makes your internationalization rules much easier to understand and maintain.

So instead of embedding an alternative style sheet like

<link href="default.rtl.css" rel="stylesheet">

just use your existing

<link href="default.css" rel="stylesheet">

When taking this approach you’ll need to complement existing CSS rules by their international counterparts:

3. Use the [dir='rtl'] attribute selector

Since we recommend to stick with the style sheet you have (tip #2), you need a different way of selecting elements you need to style differently for the other directionality. As RTL contents require specific markup (tip #1), this should be easy: For most modern browsers, we can simply use [dir='rtl'].

Here’s an example:

aside {
 float: right;
 margin: 0 0 1em 1em;
}

[dir='rtl'] aside {
 float: left;
 margin: 0 1em 1em 0; 
}

4. Use the :lang() pseudo class

To target documents of a particular language, use the :lang() pseudo class. (Note that we’re talking documents here, not text snippets, as targeting snippets of a particular language makes things a little more complex.)

For example, if you discover that bold formatting doesn’t work very well for Chinese documents (which indeed it does not), use the following:

:lang(zh) strong,
:lang(zh) b {
 font-weight: normal;
 color: #900;
}

5. Mirror left- and right-related values

When working with both LTR and RTL contents it’s important to mirror all the values that change directionality. Among the properties to watch out for is everything related to borders, margins, and paddings, but also position-related properties, float, or text-align.

For example, what’s text-align: left in LTR needs to be text-align: right in RTL.

There are tools to make it easy to “flip” directionality. One of them is CSSJanus, though it has been written for the “separate style sheet” realm, not the “same style sheet” one.

6. Keep an eye on the details

Watch out for the following items:

• Images designed for left or right, like arrows or backgrounds, light sources in box-shadow and text-shadow values, and JavaScript positioning and animations: These may require being swapped and accommodated for in the opposite directionality.
  
• Font sizes and fonts, especially for non-Latin alphabets: Depending on the script and font, the default font size may be too small. Consider tweaking the size and, if necessary, the font.
  
• CSS specificity: When using the [dir='rtl'] (or [dir='ltr']) hook (tip #2), you’re using a selector of higher specificity. This can lead to issues. Just have an eye out, and adjust accordingly.
  

If you have any questions or feedback, check the Internationalization Webmaster Help Forum, or leave your comments here.

Written by Jens O. Meiert and Tony Ruscoe, Tech Leads, Google Web Studio

Webmaster level: All

If Google understands your website’s content in a structured way, we can present that content more accurately and more attractively to Google users. For example, our algorithms can enhance your search results with “rich snippets” when we understand that your page is a structured product listing, event, recipe, review, or similar. We can also feature your data in Knowledge Graph panels or in Google Now cards, helping to spread the word about your content.

Today we’re excited to announce two features that make it simpler than ever before to participate in structured data features. The first is an expansion of Data Highlighter to seven new types of structured data. The second is a brand new tool, the Structured Data Markup Helper.

Support for Products, Businesses, Reviews and more in Data Highlighter

Data Highlighter launched in December 2012 as a point-and-click tool for teaching Google the pattern of structured data about events on your website — without even having to edit your site’s HTML. Now, you can also use Data Highlighter to teach us about many other kinds of structured data on your site: products, local businesses, articles, software applications, movies, restaurants, and TV episodes. Update: You can see the full list of schemas supported in Data Highlighter here.

To get started, visit Webmaster Tools, select your site, click the "Optimization" link in the left sidebar, and click "Data Highlighter". You’ll be prompted to enter the URL of a typically structured page on your site (for example, a product or event’s detail page) and “tag” its key fields with your mouse.



The tagging process takes about 5 minutes for a single page, or about 15 minutes for a pattern of consistently formatted pages. At the end of the process, you’ll have the chance to verify Google’s understanding of your structured data and, if it’s correct, “publish” it to Google. Then, as your site is recrawled over time, your site will become eligible for enhanced displays of information like prices, reviews, and ratings right in the Google search results.

New Structured Data Markup Helper tool

While Data Highlighter is a great way to quickly teach Google about your site’s structured data without having to edit your HTML, it’s ultimately preferable to embed structured data markup directly into your web pages, so your structured content is available to everyone. To assist web authors with that task, we’re happy to announce a new tool: the Structured Data Markup Helper.

Like in Data Highlighter, you start by submitting a web page (URL or HTML source) and using your mouse to “tag” the key properties of the relevant data type. When you’re done, the Structured Data Markup Helper generates sample HTML code with microdata markup included. This code can be downloaded and used as a guide as you implement structured data on your website.



The Structured Data Markup Helper supports a subset of data types, including all the types supported by Data Highlighter as well as several types used for embedding structured data in Gmail. Consult schema.org for complete schema documentation.

We hope these two tools make it easier for all websites to participate in Google’s growing suite of structured data features! As always, please post in our forums if you have any questions or feedback.

Posted by Justin Boyan, Product Manager

Webmaster level: all

Today, we’re launching support for the schema.org markup for organization logos, a way to connect your site with an iconic image. We want you to be able to specify which image we use as your logo in Google search results.

Using schema.org Organization markup, you can indicate to our algorithms the location of your preferred logo. For example, a business whose homepage is www.example.com can add the following markup using visible on-page elements on their homepage:

<div itemscope itemtype="http://schema.org/Organization">
  <a itemprop="url" href="http://www.example.com/">Home</a>
  <img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

Update 21 October 2014: You can also use any other supported syntax such as this JSON-LD code:

<script type="application/ld+json">
      {
      "@context": "http://schema.org/",
      "@type": "Organization",
      "url": "http://www.example.com/",
      "logo": "http://www.example.com/logo.png"
      }
    </script>

This example indicates to Google that this image is designated as the organization’s logo image for the homepage also included in the markup, and, where possible, may be used in Google search results. Markup like this is a strong signal to our algorithms to show this image in preference over others, for example when we show Knowledge Graph on the right hand side based on users’ queries.

As always, please ask us in the Webmaster Help Forum if you have any questions.

Posted by RJ Ryan, Google Engineer

Webmaster Level: All

The homepages of multinational and multilingual websites are sometimes configured to point visitors to localized pages, either via redirects or by changing the content to reflect the user’s language. Today we’ll introduce a new rel-alternate-hreflang annotation that the webmaster can use to specify such homepages that is supported by both Google and Yandex.

To see this in action, let’s look at an example. The website example.com has content that targets users around the world as follows:

• http://example.com/en-gb: For English-speaking users in the UK
• http://example.com/en-us: For English-speaking users in the USA
• http://example.com/en-au: For English-speaking users in Australia
• http://example.com/: The homepage shows users a country selector and is the default page for users worldwide

In this case, the webmaster can annotate this cluster of pages using rel-alternate-hreflang using Sitemaps or using HTML link tags like this:

<link rel="alternate" href="http://example.com/en-gb" hreflang="en-gb" />
<link rel="alternate" href="http://example.com/en-us" hreflang="en-us" />
<link rel="alternate" href="http://example.com/en-au" hreflang="en-au" />
<link rel="alternate" href="http://example.com/" hreflang="x-default" />

The new x-default hreflang attribute value signals to our algorithms that this page doesn’t target any specific language or locale and is the default page when no other page is better suited. For example, it would be the page our algorithms try to show French-speaking searchers worldwide or English-speaking searchers on google.ca.

The same annotation applies for homepages that dynamically alter their contents based on a user’s perceived geolocation or the Accept-Language headers. The x-default hreflang value signals to our algorithms that such a page doesn’t target a specific language or locale.

As always, if you have any questions or feedback, please tell us in the Internationalization Webmaster Help Forum.

Posted by Pierre Far, Webmaster Trends Analyst