Transfer Domain Names

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Thursday, 15 September 2011

View-all in search results

Posted on 05:00 by Unknown
Webmaster level: Intermediate to Advanced

User testing has taught us that searchers much prefer the view-all, single-page version of content over a component page containing only a portion of the same information with arbitrary page breaks (which cause the user to click “next” and load another URL).


Searchers often prefer the view-all vs. paginated content with arbitrary page breaks and worse latency.

Therefore, to improve the user experience, when we detect that a content series (e.g. page-1.html, page-2.html, etc.) also contains a single-page version (e.g. page-all.html), we’re now making a larger effort to return the single-page version in search results. If your site has a view-all option, there’s nothing you need to do; we’ll work to do it on your behalf. Also, indexing properties, like links, will be consolidated from the component pages in the series to the view-all page.

However, high latency can make the view-all less preferred

Interestingly, the cases when users didn’t prefer the view-all page were correlated with high latency (e.g., when the view-all page took a while to load, say, because it contained many images). This makes sense because we know users are less satisfied with slow results. So while a view-all page is commonly desired, as a webmaster it’s important to balance this preference with the page’s load time and overall user experience.

Best practices for a series of content
  1. If your site includes view-all pages

    We aim to detect the view-all version of your content and, if available, its associated component pages. There’s nothing more you need to do! However, if you’d like to make it more explicit to us, you can include rel=”canonical” from your component pages to your view-all to increase the likelihood that we detect your series of pages appropriately.


    rel=”canonical” can specify the superset of content (i.e. the view-all page, in this case page-all.html) from the same information in a series of URLs.

    Why does this work?
In the diagram, page-2.html of a series may specify the canonical target as page-all.html because page-all.html is a superset of page-2.html's content. When a user searches for a query term and page-all.html is selected in search results, even if the query most related to page-2.html, we know the user will still see page-2.html’s relevant information within page-all.html.

On the other hand, page-2.html shouldn’t designate page-1.html as the canonical because page-2.html’s content isn’t included on page-1.html. It’s possible that a user’s search query is relevant to content on page-2.html, but if page-2.html’s canonical is set to page-1.html, the user could then select page-1.html in search results and find herself in a position where she has to further navigate to a different page to arrive at the desired information. That’s a poor experience for the user, a suboptimal result from us, and it could also bring poorly targeted traffic to your site.

However, if you strongly desire your view-all page not to appear in search results: 1) make sure the component pages in the series don’t include rel=”canonical” to the view-all page, and 2) mark the view-all page as “noindex” using any of the standard methods.
  • If you’d like to surface individual, component pages (or there’s no view-all available)

    It may be the case that one or both of the situations below apply to your site:

    • The view-all page is undesirable as a search result (e.g., load time too high or too difficult for users to navigate).
    • Your users prefer the multi-page experience and to be directed to a component page in search results, rather than the view-all page.

    If so, you can use standard HTML rel=”next” and rel=”prev” elements to specify a relationship between the component pages in your series of content. If done correctly, Google will generally strive to:

    • Consolidate indexing properties, such as links, between the component pages/URLs.
    • Send users to the most relevant page/URL from the component pages. Typically, the most relevant page is the first page of your content, but our algorithms may point users to one of the component pages in the series.

  • It’s not uncommon for webmasters to incorrectly use rel=”canonical” from component pages to the first page of their series (e.g. page-2.html with rel=”canonical” to page-1.html). We recommend against this implementation because the component pages don’t actually contain duplicate content. Using rel=”next” and rel=”prev” is far more appropriate.

    Summary

    Because users generally prefer the view-all option in search results, we’re making more of an effort to properly detect and serve this version to searchers. If you have a series of content, there’s nothing more you need to do. If you’d like to hint more to Google how best to serve users your information:
    1. To better optimize your view-all page, you can use rel=”canonical” from component pages to the single-page version; otherwise,
    2. If a view-all page doesn’t provide a good user experience for your site, you can use the rel=”next” and rel=”prev” attributes as a strong hint for Google to identify the series of pages and still surface a component page in results.

    Questions?

    As always, feel free to ask in our Webmaster Help Forum.

    Written by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team
    Email ThisBlogThis!Share to XShare to Facebook
    Posted in crawling and indexing, search results | No comments
    Newer Post Older Post Home

    0 comments:

    Post a Comment

    Subscribe to: Post Comments (Atom)

    Popular Posts

    • Switching to the new website verification API
      Webmaster level: advanced Just over a year ago we introduced a new API for website verification for Google services. In the spirit of keepi...
    • Structured Data dashboard: new markup error reports for easier debugging
      Since we launched the Structured Data dashboard last year, it has quickly become one of the most popular features in Webmaster Tools. We’ve...
    • "It's on Google! YAY!" - Getting webmaster help in our forum
      Webmaster level: all It's been a bit more than five years now that our Webmaster Help Forum has been up and running, helping webmasters...
    • Supporting rel="canonical" HTTP Headers
      Webmaster level: Advanced Based on your feedback, we’re happy to announce that Google web search now supports link rel="canonical"...
    • Getting started with structured data
      Webmaster level: All If Google understands your website’s content in a structured way, we can present that content more accurately and more ...
    • Responsive design – harnessing the power of media queries
      Webmaster Level: Intermediate / Advanced We love data, and spend a lot of time monitoring the analytics on our websites. Any web developer d...
    • Introducing the Structured Data Dashboard
      Webmaster level: All Structured data is becoming an increasingly important part of the web ecosystem. Google makes use of structured data in...
    • Tell us what you think!
      (Cross-posted on the Google Product Ideas Blog ) The Webmaster Central team does our best to support the webmaster community via Webmaster T...
    • Improving URL removals on third-party sites
      Webmaster level: all Content on the Internet changes or disappears, and occasionally it's helpful to have search results for it updated ...
    • Protect your site from spammers with reCAPTCHA
      Webmaster Level: All If you allow users to publish content on your website, from leaving comments to creating user profiles , you’ll likely...

    Categories

    • advanced
    • beginner
    • crawling and indexing
    • events
    • feedback and communication
    • general tips
    • hacked sites
    • hreflang
    • images
    • intermediate
    • localization
    • malware
    • mobile
    • performance
    • products and services
    • search results
    • sitemaps
    • structured data
    • url removals
    • verification
    • video
    • webmaster guidelines
    • webmaster tools

    Blog Archive

    • ►  2014 (2)
      • ►  January (2)
    • ►  2013 (35)
      • ►  December (6)
      • ►  November (1)
      • ►  October (2)
      • ►  September (2)
      • ►  August (4)
      • ►  July (2)
      • ►  June (4)
      • ►  May (3)
      • ►  April (2)
      • ►  March (6)
      • ►  February (2)
      • ►  January (1)
    • ►  2012 (55)
      • ►  December (3)
      • ►  November (1)
      • ►  October (5)
      • ►  September (2)
      • ►  August (5)
      • ►  July (5)
      • ►  June (6)
      • ►  May (7)
      • ►  April (7)
      • ►  March (6)
      • ►  February (2)
      • ►  January (6)
    • ▼  2011 (75)
      • ►  December (7)
      • ►  November (2)
      • ►  October (5)
      • ▼  September (8)
        • Work smarter, not harder, with site health
        • View-all in search results
        • Pagination with rel=“next” and rel=“prev”
        • Reconsideration requests get more transparent
        • Introducing: Application Rich Snippets
        • Îñţérñåţîöñåļîžåţîöñ
        • Recognizing Top Contributors in Google's Help Forums
        • PDFs in Google search results
      • ►  August (10)
      • ►  July (5)
      • ►  June (10)
      • ►  May (8)
      • ►  April (6)
      • ►  March (6)
      • ►  February (5)
      • ►  January (3)
    • ►  2010 (81)
      • ►  December (9)
      • ►  November (9)
      • ►  October (4)
      • ►  September (8)
      • ►  August (6)
      • ►  July (2)
      • ►  June (6)
      • ►  May (6)
      • ►  April (12)
      • ►  March (11)
      • ►  February (1)
      • ►  January (7)
    • ►  2009 (52)
      • ►  December (7)
      • ►  November (9)
      • ►  October (13)
      • ►  September (8)
      • ►  August (6)
      • ►  July (5)
      • ►  June (4)
    Powered by Blogger.

    About Me

    Unknown
    View my complete profile