Wyświetlanie wszystkiego w wynikach wyszukiwania

Czwartek, 15 września 2011 r.

Testy wykazały, że w wielu przypadkach użytkownicy wolą zobaczyć całą treść na jednej stronie, a nie oglądać strony składowe zawierające tylko część informacji z arbitralnym podziałem materiału (co zmusza użytkownika do kliknięcia „dalej” i wczytania kolejnego adresu URL).

Przykład preferowanych wyników wyszukiwania w przypadku treści podzielonych na strony
Użytkownicy często wolą treści umieszczone na jednej stronie zamiast podzielonych na strony z arbitralnym podziałem materiału i dłuższym czasem oczekiwania na wczytanie.

Dlatego gdy wykryjemy, że seria treści (np. page-1.html, page-2.html itd.) uwzględnia też wersję jednostronicową (np. page-all.html), w wynikach wyszukiwania postaramy się zwrócić właśnie tę wersję, aby zwiększyć komfort użytkowników. Jeśli Twoja witryna ma opcję wyświetlania wszystkiego, nie musisz podejmować żadnych działań. Zrobimy to za Ciebie. Poza tym skonsolidujemy właściwości indeksowania (takie jak linki) ze stron składowych w serii w jedną stronę z całą zawartością.

Długi czas oczekiwania może zniechęcić do przeglądania stron zawierających całą treść

Co ciekawe, sytuacje, w których użytkownicy nie preferowali strony obejmującej całą treść, wynikały z opóźnienia (np. gdy wczytywanie takiej strony zajmowało więcej czasu, bo np. zawierała wiele obrazów). Ma to sens, ponieważ wiemy, że użytkownicy nie są zadowoleni, gdy wyniki wyświetlają się powoli. Choć użytkownicy zazwyczaj wolą strony zawierające całą treść, webmasterzy powinni wziąć pod uwagę czas wczytywania strony i ogólną wygodę użytkowników.

Sprawdzone metody dotyczące rozbudowanych treści

  1. Jeśli masz w swojej witrynie strony obejmujące całą zawartość: naszym celem jest wykrycie wszystkich wersji Twoich treści i powiązanych stron składowych, o ile są one dostępne. Nie musisz robić nic więcej. Jeśli jednak chcesz ułatwić nam rozpoznanie treści, możesz dodać znacznik rel="canonical" ze stron składowych do strony z całą zawartością, aby zwiększyć prawdopodobieństwo, że prawidłowo zidentyfikujemy sekwencję stron.

    Diagram implementacji tagu rel-canonical w przypadku serii treści
    Tag rel="canonical" może określać nadrzędny materiał (czyli stronę z całą zawartością, w tym przypadku page-all.html) w stosunku do tych samych informacji, które znajdują się pod kilkoma adresami URL.

    Dlaczego to działa? Na diagramie element page-2.html serii może określać kanoniczną wartość docelową jako page-all.html, bo page-all.html jest elementem nadrzędnym w stosunku do elementu page-2.html. Gdy użytkownik wyszukuje określone hasło i w wynikach wyszukiwania zostanie wybrany element page-all.html, to nawet wtedy, gdy zapytanie najbardziej pasuje do elementu page-2.html, wiemy, że użytkownik i tak zobaczy odpowiednie treści ze strony page-2.html na stronie page-all.html.

    Z drugiej strony element page-2.html nie powinien wskazywać elementu page-1.html jako strony kanonicznej, bo treść strony page-1.html nie obejmuje zawartości strony page-2.html. Możliwe, że hasło wyszukiwane przez użytkownika pasuje do treści na stronie page-2.html, ale jeśli strona kanoniczna elementu page-2.html jest ustawiona na page-1.html, użytkownik może w wynikach wyszukiwania wybrać page-1.html, skąd musi przejść na inną stronę, aby dotrzeć do poszukiwanych informacji. To rozwiązanie jest niewygodne dla użytkownika i niefortunne z naszego punktu widzenia. Może też skutkować słabą jakością ruchu przychodzącego do Twojej witryny.

    Jeśli jednak zdecydowanie nie chcesz, aby strona z całą zawartością pojawiała się w wynikach wyszukiwania:

    1. Upewnij się, że strony składające się na serię nie zawierają tagu rel="canonical" wskazującego stronę z całą zawartością.
    2. Oznacz stronę obejmującą wszystkie treści jako noindex, korzystając ze standardowych metod.

  2. Jeśli chcesz, aby wyświetlały się poszczególne strony składowe (lub strona z całą zawartością jest niedostępna), może to wynikać z tych przyczyn:

    • Wyświetlenie strony z całą zawartością w wynikach wyszukiwania jest niewskazane (np. z powodu zbyt długiego czasu wczytywania lub zbyt skomplikowanej nawigacji).
    • Użytkownicy preferują dostęp do wielu stron i przekierowanie na stronę składową wyświetloną w wynikach wyszukiwania zamiast strony z całą zawartością.

    W takim przypadku możesz użyć standardowych elementów HTML rel="next" i rel="prev", aby określić relację między stronami składającymi się na serię. Jeśli zrobisz to poprawnie, postaramy się:

    • skonsolidować właściwości indeksowania (np. linki) ze składowych stron/adresów URL;
    • odsyłać użytkowników na najtrafniejszą stronę / pod najbardziej odpowiedni adres URL spośród stron składowych. Zwykle najtrafniejszą stroną jest pierwsza strona zawartości, ale nasze algorytmy mogą skierować użytkowników na jedną ze stron składających się na serię.

Zdarza się, że webmasterzy nieprawidłowo używają tagu rel="canonical" przekierowującego ze stron składowych na pierwszą stronę serii (np. page-2.html z elementem rel="canonical" przekierowuje na stronę page-1.html). Odradzamy taką implementację, bo strony składowe w rzeczywistości nie zawierają powielonych treści. Znacznie lepiej użyć znaczników rel="next" i rel="prev".

Podsumowanie

Użytkownicy zwykle preferują strony z całą zawartością w wynikach wyszukiwania, dlatego dokładamy wszelkich starań, aby poprawnie wykryć i udostępnić im tę wersję. Jeśli masz serię materiałów, nie musisz nic robić. Jeśli chcesz przekazać Google więcej informacji o tym, jak najlepiej wyświetlać informacje użytkownikom:

  1. Aby lepiej zoptymalizować stronę z całą zawartością, możesz użyć tagu rel="canonical" przekierowującego ze stron składowych do wersji jednostronicowej.
  2. Jeśli strona zawierająca wszystkie treści nie zapewnia użytkownikom wygody, możesz użyć atrybutów rel="next" i rel="prev", aby wyraźnie wskazać Google, że jest to seria materiałów i w wynikach wyszukiwania powinna się pojawić strona składowa.

Jak zwykle, jeśli masz jakieś pytania, możesz je zadać na Forum pomocy dla webmasterów.

Autorzy: Benjia Li i Joachim Kupke, Software Engineers, zespół ds. indeksowania