사용자 테스트 결과 검색 사용자는 임의의 페이지 나누기가 적용된 콘텐츠의 일부만 포함하는 구성요소 페이지(이 경우 사용자는 '다음'을 클릭하고 다른 URL을 로드해야 함)보다 같은 정보를 담은 모두 보기, 단일 페이지 버전을 훨씬 더 선호했습니다.
검색 사용자는 페이지를 임의로 나누고 지연 시간이 더 긴, 페이지로 나눈 콘텐츠보다 모두 보기 페이지를 더 선호할 때가 많습니다.
따라서 Google에서는 사용자 환경을 개선하기 위해 콘텐츠 시리즈(예: page-1.html, page-2.html 등)에 단일 페이지 버전(예: page-all.html)도 포함된 것이 감지되면 검색결과에서 단일 페이지 버전을 표시하고자 더욱 노력하고 있습니다. 사이트에 모두 보기 옵션이 있다면 별도의 작업을 하지 않아도 됩니다. Google에서 대신 처리해 드립니다. 링크와 같은 색인 생성 속성도 시리즈의 구성요소 페이지에서 모두 보기 페이지로 통합됩니다.
지연 시간이 길면 모두 보기 선호도가 떨어질 수 있습니다
흥미롭게도 사용자가 모두 보기 페이지를 선호하지 않는 경우는 긴 지연 시간과 관계가 있었습니다(예: 여러 이미지가 포함되어 있어 모두 보기 페이지를 로드하는 데 시간이 오래 걸리는 경우). 검색결과가 늦게 나오면 사용자 만족도가 저하된다는 점을 고려할 때 이해가 됩니다.
그러므로 일반적으로는 모두 보기 페이지가 선호되지만, 웹마스터는 이 환경설정과 페이지 로드 시간 및 전반적인 사용자 환경 사이에서 균형을 잡아야 합니다.
콘텐츠 시리즈 권장사항
사이트에 모두 보기 페이지가 포함된 경우: Google에서는 콘텐츠의 모두 보기 버전 및 연결된 구성요소 페이지(있는 경우)를 감지하려고 합니다. 개발자는 별도의 작업을 하지 않아도 됩니다. 그러나 좀 더 명시적으로 의사를 표현하려는 경우 구성요소 페이지에서 모두 보기 페이지로 rel="canonical"을 포함하여 Google에서 일련의 페이지를 올바르게 감지할 가능성을 높일 수 있습니다.
rel="canonical"은 일련의 URL에 있는 동일한 정보에서 콘텐츠의 상위 집합(모두 보기 페이지, 이 경우에는 page-all.html)을 지정할 수 있습니다.
이 방법이 가능한 이유는 무엇일까요? 다이어그램에서 시리즈의 page-2.html은 표준 타겟을 page-all.html로 지정할 수 있습니다. page-all.html이 page-2.html 콘텐츠의 상위 집합이기 때문입니다. 사용자가 검색어를 검색하고 검색결과에서 page-all.html을 선택하면 검색어와 가장 관련성 높은 페이지가 page-2.html이더라도 사용자에게는 여전히 page-all.html 내에서 page-2.html의 관련 정보가 표시됩니다.
반면 page-2.html은 page-1.html을 표준으로 지정하면 안 됩니다. page-2.html의 콘텐츠가 page-1.html에 포함되지 않기 때문입니다. 사용자의 검색어가 page-2.html의 콘텐츠와 관련이 있을 수 있지만 page-2.html의 표준이 page-1.html로 설정되어 있으면 사용자가 검색결과에서 page-1.html을 선택한 뒤에 원하는 정보를 얻으려면 다른 페이지로 또 이동해야 한다는 사실을 알게 될 수 있습니다. 이는 사용자 환경이 만족스럽지 않은 것이고 Google이 제공하고자 하는 최선의 검색결과도 아니며 사이트에 제대로 타겟팅되지 않은 트래픽을 유도할 수도 있습니다.
그럼에도 불구하고 검색결과에 모두 보기 페이지가 표시되지 않게 하려면 다음을 실행하세요.
시리즈의 구성요소 페이지에 모두 보기 페이지로의 rel="canonical"이 포함되어 있지 않은지 확인합니다.
개별 구성요소 페이지를 표시하려는 경우(또는 사용 가능한 모두 보기가 없는 경우): 아래 상황 중 하나 또는 둘 다 해당되는 사이트라면 그럴 수 있습니다.
모두 보기 페이지가 검색결과로 바람직하지 않습니다(예: 로드 시간이 너무 길거나 사용자가 탐색하기 너무 어려움).
사용자가 다중 페이지 환경을 선호하며 검색결과에서 모두 보기 페이지가 아닌 구성요소 페이지로 안내되기를 바랍니다.
이 경우 표준 HTML rel="next" 및 rel="prev" 요소를 사용하여 콘텐츠 시리즈에서 구성요소 페이지 간의 관계를 지정할 수 있습니다. 올바르게 완료되면 Google에서는 일반적으로 다음을 실행합니다.
구성요소 페이지/URL 사이에 링크와 같은 색인 생성 속성을 통합합니다.
구성요소 페이지에서 가장 관련성 높은 페이지/URL로 사용자를 보냅니다. 일반적으로 가장 관련성 높은 페이지는 콘텐츠의 첫 번째 페이지이지만 Google 알고리즘을 통해 사용자는 시리즈의 구성요소 페이지 중 하나로 연결될 수 있습니다.
웹마스터가 구성요소 페이지에서 시리즈의 첫 번째 페이지(예: rel="canonical"을 page-1.html로 설정한 page-2.html)로 rel="canonical"을 잘못 사용하는 경우가 종종 발생합니다. 이 구현은 사용하지 않는 것이 좋습니다. 구성요소 페이지에 실제로 중복 콘텐츠가 포함되어 있지 않기 때문입니다. rel="next"와 rel="prev"를 사용하는 것이 훨씬 더 적절합니다.
요약
사용자는 일반적으로 검색결과에서 모두 보기 옵션을 선호하므로 Google에서는 이 버전을 적절히 감지하여 검색 사용자에게 제공하고자 더욱 노력하고 있습니다. 콘텐츠 시리즈가 있다면 별도로 작업을 더 하지 않아도 됩니다. 사용자에게 정보를 제공하는 최적의 방법을 Google에 더 많이 알려주려면 다음을 실행하세요.
모두 보기 페이지를 더욱 효과적으로 최적화하려면 구성요소 페이지에서 단일 페이지 버전으로 rel="canonical"을 사용하면 됩니다.
모두 보기 페이지가 사이트에서 바람직한 사용자 환경을 제공하지 않는 경우, Google이 일련의 페이지를 식별하고 검색결과에 계속해서 구성요소 페이지를 표시하도록 rel="next" 및 rel="prev" 속성을 강력한 힌트로 사용할 수 있습니다.
[null,null,[],[[["\u003cp\u003eGoogle prioritizes showing single-page, "view-all" content in search results for a better user experience, consolidating indexing properties from component pages.\u003c/p\u003e\n"],["\u003cp\u003eWhen "view-all" pages have high latency, Google might show individual component pages instead to ensure faster loading times.\u003c/p\u003e\n"],["\u003cp\u003eWebmasters with "view-all" pages can use \u003ccode\u003erel="canonical"\u003c/code\u003e from component pages to the "view-all" page to aid Google's detection and indexing.\u003c/p\u003e\n"],["\u003cp\u003eIf "view-all" is unsuitable, use \u003ccode\u003erel="next"\u003c/code\u003e and \u003ccode\u003erel="prev"\u003c/code\u003e on component pages to indicate the series and potentially surface individual pages in search results.\u003c/p\u003e\n"]]],["Webmasters with content series should prioritize user experience by offering a \"view-all\" page. When detected, this version will be favored in search results. To aid this, use `rel=\"canonical\"` from component pages to the \"view-all\". If a \"view-all\" is not suitable, use `rel=\"next\"` and `rel=\"prev\"` between component pages. High latency on a view-all page can be detrimental. If the desire is for individual pages, ensure the \"view-all\" isn't canonicalized, and it can be noindexed.\n"],null,["# View-all in search results\n\nThursday, September 15, 2011\n| It's been a while since we published this blog post. Some of the information may be outdated (for example, some images may be missing, and some links may not work anymore). `rel=prev/next` is not an indexing signal anymore.\n\n\nUser testing has taught us that searchers much prefer the view-all, single-page version of content\nover a component page containing only a portion of the same information with arbitrary page breaks\n(which cause the user to click \"next\" and load another URL).\nSearchers often prefer the view-all vs. paginated content with arbitrary page breaks and worse latency.\n\n\nTherefore, to improve the user experience, when we detect that a content series (for example,\n`page-1.html`, `page-2.html`, etc.) also contains a single-page version\n(for example, `page-all.html`), we're now making a larger effort to return the single-page\nversion in search results. If your site has a view-all option, there's nothing you need to do;\nwe'll work to do it on your behalf. Also, indexing properties, like links, will be consolidated\nfrom the component pages in the series to the view-all page.\n\nHigh latency can make the view-all less preferred\n-------------------------------------------------\n\n\nInterestingly, the cases when users didn't prefer the view-all page were correlated with high\nlatency (for example, when the view-all page took a while to load, say, because it contained many\nimages). This makes sense because we know users are\n[less satisfied with slow results](https://googleresearch.blogspot.com/2009/06/speed-matters.html).\nSo while a view-all page is commonly desired, as a webmaster it's important to balance this\npreference with the page's load time and overall user experience.\n\nBest practices for a series of content\n--------------------------------------\n\n1.\n **If your site includes view-all pages:** We aim to detect the view-all version of your\n content and, if available, its associated component pages. There's nothing more you need to\n do! However, if you'd like to make it more explicit to us, you can include\n `rel=\"canonical\"` from your component pages to your view-all to increase the\n likelihood that we detect your series of pages appropriately.\n\n `rel=\"canonical\"` can specify the superset of content (that is, the view-all page, in this case `page-all.html`) from the same information in a series of URLs.\n\n\n *Why does this work?* In the diagram, `page-2.html` of a series may specify\n the canonical target as `page-all.html` because `page-all.html` is a\n superset of `page-2.html`'s content. When a user searches for a query term and\n `page-all.html` is selected in search results, even if the query most related to\n `page-2.html`, we know the user will still see `page-2.html`'s relevant\n information within `page-all.html`.\n\n\n On the other hand, `page-2.html` shouldn't designate `page-1.html` as\n the canonical because `page-2.html`'s content isn't included on\n `page-1.html`. It's possible that a user's search query is relevant to content on\n `page-2.html`, but if `page-2.html`'s canonical is set to\n `page-1.html`, the user could then select `page-1.html` in search\n results and find herself in a position where she has to further navigate to a different page\n to arrive at the desired information. That's a poor experience for the user, a suboptimal\n result from us, and it could also bring poorly targeted traffic to your site.\n\n\n However, if you strongly desire your view-all page not to appear in search results:\n 1. Make sure the component pages in the series don't include `rel=\"canonical\"` to the view-all page, and\n 2. Mark the view-all page as [`noindex`](/search/docs/crawling-indexing/block-indexing) using any of the standard methods.\n2.\n **If you'd like to surface individual, component pages (or there's no view-all available)**:\n It may be the case that one or both of the situations below apply to your site:\n\n - The view-all page is undesirable as a search result (for example, load time too high or too difficult for users to navigate).\n - Your users prefer the multi-page experience and to be directed to a component page in search results, rather than the view-all page.\n\n\n If so, you can use standard HTML\n [`rel=\"next\"` and `rel=\"prev\"` elements](/search/blog/2011/09/pagination-with-relnext-and-relprev)\n to specify a relationship between the component pages in your series of content. If done\n correctly, Google will generally strive to:\n - Consolidate indexing properties, such as links, between the component pages/URLs.\n - 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.\n\n\nIt's not uncommon for webmasters to incorrectly use `rel=\"canonical\"` from component\npages to the first page of their series (for example, `page-2.html` with\n`rel=\"canonical\"` to `page-1.html`). We recommend against this\nimplementation because the component pages don't actually contain duplicate content. Using\n`rel=\"next\"` and `rel=\"prev\"` is far more appropriate.\n\nSummary\n-------\n\n\nBecause users generally prefer the view-all option in search results, we're making more of an\neffort to properly detect and serve this version to searchers. If you have a series of content,\nthere's nothing more you need to do. If you'd like to hint more to Google how best to serve users\nyour information:\n\n1. To better optimize your view-all page, you can use `rel=\"canonical\"` from component pages to the single-page version; otherwise,\n2. If a view-all page doesn't provide a good user experience for your site, you can use the [`rel=\"next\"` and `rel=\"prev\"`](/search/blog/2011/09/pagination-with-relnext-and-relprev) attributes as a strong hint for Google to identify the series of pages and still surface a component page in results.\n\n\nAs always, you can ask questions in our\n[Webmaster Help Forum](https://support.google.com/webmasters/community/).\n\n\nWritten by Benjia Li and Joachim Kupke, Software Engineers, Indexing Team"]]
