Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Quinta-feira, 15 de setembro de 2011
Os testes de usuários nos ensinaram que eles preferem ver o conteúdo inteiro em uma página "Ver tudo",
em vez de acessar uma lista dos componentes que mostra apenas parte das informações, com quebras de página arbitrárias
que fazem o usuário clicar em "próximo" e carregar outro URL.
Em geral, os usuários preferem a página "Ver tudo", e não o conteúdo paginado com quebras arbitrárias e pior
latência.
Portanto, para melhorar a experiência do usuário, quando detectamos que uma série de conteúdo (por exemplo,
page-1.html, page-2.html etc.) também tem uma versão de página única
(por exemplo, page-all.html), tentamos retorná-la
nos resultados da pesquisa. Caso o site tenha uma página "Ver tudo", não vai ser necessário realizar nenhuma ação.
Faremos isso em seu nome. Além disso, as propriedades de indexação, como links, serão consolidadas
das páginas do componente na série para a página "Ver tudo".
A latência alta pode fazer com que menos usuários prefiram a página "Ver tudo"
Curiosamente, os casos em que os usuários não preferiram a página "Ver tudo" eram correlacionados com uma alta
latência (por exemplo, quando a página demorava para carregar porque tinha muitas
imagens). Isso faz sentido, porque os usuários ficam
menos satisfeitos com resultados lentos.
Portanto, embora uma página "Ver tudo" seja normalmente recomendável, como webmaster, é importante equilibrar essa
preferência com o tempo de carregamento da página e a experiência geral do usuário.
Práticas recomendadas para uma série de conteúdo
Se o site incluir páginas "Ver tudo": nosso objetivo é detectar essa versão do
conteúdo e as páginas associadas, se disponíveis. Não é necessário fazer mais
nada. No entanto, se quiser deixar isso mais claro,
é possível incluir rel="canonical" das páginas do componente na página "Ver tudo". Assim você aumenta a
probabilidade de detectarmos a série de páginas de modo adequado.
rel="canonical" pode especificar o superconjunto do conteúdo (ou seja, a página "Ver tudo", page-all.html nesse caso) das mesmas informações em uma série de
URLs.
Por que isso funciona? No diagrama, page-2.html de uma série pode especificar
o destino canônico como page-all.html, porque page-all.html é um
superconjunto do conteúdo de page-2.html. Quando um usuário pesquisar um termo de consulta e
page-all.html estiver selecionado nos resultados da pesquisa, mesmo que a consulta tenha mais relação com
page-2.html, o usuário ainda verá as informações relevantes
de page-2.html em page-all.html.
Por outro lado, page-2.html não pode designar page-1.html como
canônico, porque o conteúdo de page-2.html não está incluído em
page-1.html. É possível que a consulta de pesquisa de um usuário seja relevante para o conteúdo em
page-2.html, mas se o URL canônico de page-2.html estiver definido como
page-1.html, o usuário poderá selecionar page-1.html nos resultados
da pesquisa e precisar navegar até uma página diferente
para chegar às informações desejadas. Essa é uma experiência ruim para o usuário e um resultado
inadequado para nós, além de talvez levar a um tráfego mal segmentado para seu site.
No entanto, se você quiser que a página "Ver tudo" não apareça nos resultados da pesquisa, faça o seguinte:
Confira se as páginas do componente na série não incluem rel="canonical" na
página "Ver tudo".
Marque a página "Ver tudo" como
noindex usando qualquer
um dos métodos padrão.
Se quiser exibir páginas individuais do componente (ou se a página "Ver tudo" não estiver disponível):
talvez uma ou ambas as situações abaixo se apliquem ao seu site:
A página "Ver tudo" não é recomendável como um resultado da pesquisa (por exemplo, o tempo de carregamento é muito alto ou a
navegação é difícil para os usuários).
Os usuários preferem a experiência de várias páginas e o direcionamento para uma página do componente nos resultados
da pesquisa, em vez da página "Ver tudo".
Nesse caso, é possível usar elementos HTML
rel="next" e rel="prev"
padrão para especificar uma relação entre as páginas dos componentes da série. Se isso
for feito de modo correto, o Google geralmente tentará:
consolidar as propriedades de indexação, como links, das páginas e dos URLs dos componentes;
direcionar os usuários para a página ou o URL mais relevante das páginas dos componentes. Geralmente, a página
mais relevante do conteúdo é a primeira, mas os algoritmos podem direcionar os usuários para uma
das páginas dos componentes na série.
É comum que os webmasters usem incorretamente rel="canonical" das páginas
dos componentes para a primeira página da série (por exemplo, page-2.html com
rel="canonical" para page-1.html). Não recomendamos essa
implementação, porque as páginas dos componentes não têm conteúdo duplicado. Usar
rel="next" e rel="prev" é muito mais apropriado.
Resumo
Como os usuários geralmente preferem a opção "Ver tudo" nos resultados da pesquisa, estamos nos
esforçando para detectar e exibir essa versão corretamente aos usuários. Se você tiver uma série de conteúdo,
não precisará fazer mais nada. Caso queira sugerir ao Google como exibir suas informações aos usuários,
faça o seguinte:
Para otimizar a página "Ver tudo", use rel="canonical" das páginas dos componentes
para a versão de página única.
Caso contrário, se a página "Ver tudo" não oferecer uma boa experiência do usuário no site, use os atributos
rel="next" e rel="prev"
como uma dica para o Google identificar a série de páginas e ainda mostrar a
página dos componentes nos resultados.
[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"]]
