Одна из классических проблем в поисковой оптимизации: польза комплексных навигационных схем для пользователей и их проблематичность для поисковых машин. Многие вебмастера полагаются на теги вроде rel=canonical или настройки параметров в Инструментах для вебмастеров. Тем не менее, каждое потенциальное решение имеет свои ограничения. В сегодняшней статье я хочу рассказать, как можно использовать JavaScript для того, чтобы максимально эффективно решить проблему возникновения дублированного контента.

Я не буду приводить примеры кодировки, но я хочу показать вам, как это работает на концептуальном уровне.

Определение проблем многоаспектной навигации

Пользователям очень нравится заходить на сайт, на котором есть возможность сортировки продукции (например, от самой низкой цены к самой высокой) либо выбора определенного набора товаров по заданному параметру (например, от 60 долл. США). Обычно мы называем такую навигацию многоаспектной.

Но при этом многоаспектная навигация может создавать трудности для поисковых систем, т.к. они не хотят индексировать все варианты страниц в зависимости от заданных фильтров. Ведь в таком случае им придется столкнуться с огромным количеством страниц, которые не сильно отличаются друг от друга с точки зрения пользовательского интерфейса.

При этом теги rel=canonical и настройки параметров в Инструментах для вебмастеров имеют ряд ограничений. Например, тег rel=canonical рассматривается поисковой системой как рекомендация и может быть не принят ей во внимание, и даже если поисковая система учтет этот тег, она всё равно может продолжать анализировать и индексировать страницу вопреки рекомендации.

При создании многоаспектной навигации лучше использовать JSON или jQuery. В таком случае, новые страницы не создаются каждый раз, когда пользователь выбирает фильтр или порядок сортировки. Когда вы используете JSON или jQuery, весь этот процесс происходит на устройстве клиента, вообще не привлекая ваш веб-сервер.

Таким образом страница передается в бразуер, используемый пользователем для запроса страницы. Когда пользователь задает устанавливает фильтр данных, происходит следующее:

Когда пользователь изначально запрашивает одну их страниц вашего вебсайта с описанием товара, процесс выглядит примерно так: jQuery производит запрос JSON данных. Перевод: всё взаимодействие происходит внутри клиентского браузера и сортировщика или фильтра, установленного в нем. Проще говоря, вся система сортировки и фильтровки данных находится внутри кода на устройстве клиента, который был передан с исходным запросом страницы.

В результате не создается новых страниц, которые нужно было бы анализировать и индексировать поисковой системе – и никаких проблем с количеством обрабатываемых страниц и неэффективным использованием PageRank. Но существуют некоторые ограничения.

В частности, если ваш список товаров охватывает несколько страниц сайта, сортировка и фильтрация может быть произведена только с тем набором данных, который был передан в браузер пользователя с исходным запросом. Короче говоря, отсортировать можно только первую страницу товаров, а не по всему списку. Можно сделать так, чтобы первоначальный JSON объект данных содержал весь набор страниц, но это не здорово, если в итоге размер страницы слишком велик.

Чем Ajax вам может помочь

Теперь копнем немного глубже и посмотрим, как Ajax может помочь с сортировкой, фильтрацией И разбивкой по страницам. Предупреждаю: сейчас мы углубимся в некоторые технические детали, но я постараюсь выражаться предельно просто.

Работа Ajax выглядит следующим образом:

В этой структуре мы используем уровень Ajax для обмена информацией с веб-сервером. Допустим, у нас есть набор из 10 страниц, у пользователя на устройстве загружена только одна из десяти, и он запрашивает другой порядок сортировки товаров. Ajax запрашивает новые данные с веб-сервера, на котором располагается ваш сайт, аналогично использованию HTML-форм для передачи данных на сервер, за исключением того, что такая передача данных происходит асинхронно отдельным потоком.

Если вы не знаете, что это означает, объясняю: преимущество такой передачи данных заключается в том, что остальная часть страницы может полностью загружаться, т.к. процесс по захвату данных, которые будут отображаться с помощью Ajax, происходит параллельно. Речь идет о таких элементах сайта, как главное меню, ссылки на сопутствующие товары в нижней части страницы, и другие элементы. Всё это улучшает видимую производительность страницы.

Когда пользователь выбирает другой порядок сортировки, код регистрирует обработчика события для указанного объекта данных (например, HTML-элемента или другого DOM-объекта), а затем производит действие. Браузер производит действие отдельным потоком, чтобы в нужный момент запустить событие в основном потоке. Всё это происходит без необходимости полностью обновлять страницу. Обновляется только контент, загружаемый через Ajax.

Говоря простым языком, это означает, что мы можем обновить порядок сортировки товаров на странице без повторного запроса всей страницы, изменения URL, даже если речь идет о пронумерованной последовательности страниц. Это является большим преимуществом, т.к. весь процесс занимает гораздо меньше времени, чем повторная загрузка страницы, а поисковой системе становится понятно, что вы не пытаетесь пополнить индекс новой страницей.

Кроме того, весь процесс совершается в рамках одной объектной модели документов (DOM), которую можно представить как базовую структуру документов, отражающую их форму.

Как Google обращается с таким видом передачи данных

У вас может возникнуть вопрос, будет ли Google загружать все варианты этих страниц под одним и тем же URL-адресом, и понравится ли это ему.

У меня возник тот же вопрос, и вот, что мне удалось выяснить:

Я: У меня есть вопрос об использовании JSON и jQuery для выполнения разного вида запросов и фильтрации данных под одним и тем же URL –адресом. Например, пользователь выбирает критерий для сортировки, но при этом контент сортируется на странице сайта клиента. В этом случае новый URL-адрес не создается. Это эффективный способ канонизации контента, т.к. каждый вариант страницы – это строгое подмножество.

Кроме того, с этим подходом связан еще один интересный момент – разбивка по страницам. Представим, что у вас 10 страниц с товарами, а пользователь задает сортировку. Для обеспечения сортировки/фильтрации по всем 10ти страницам вы используете Ajax, так что весь процесс опять же осуществляется на одной URL.

Получается, что если мы находимся на странице 1, и пользователь делает сортировку, ее результат он видит на той же самой странице. При этом если пользователь переходит на вторую страницу списка, она открывается под тем же URL. Практически получается, что мы берем 10 страниц и выдаем их всех под одним URL-адресом. В результате можно делать сортировку/фильтрацию/разбивку по страницам без использования мета-тегов canonical, noindex, prev/next, или robots.txt.

Если это не проблема для Google, единственным минусом этого метода является то, что разбивка по страницам остается невидимой для Google. Оцените, насколько это хорошая идея?

GaryIllyes: Если вы используете только 1 URL, и пользователи могут осуществлять сортировку контента в рамках одного URL, у нас будет отображаться только контент, заданный по умолчанию.

Если у вас нет информации о разбивке по страницам, это не проблема, за исключением того, что мы не сможем увидеть контент других страниц, который не содержится в HTML-коде первоначально загруженной страницы. Смысл тегов rel-prev/nex в том, чтобы направить сигналы от дочерних страниц (стр. 2,3, 4 и т.д) к группе страниц как набору страниц или к просмотру всей страницы, если страница одна. Если вы хотите, чтобы все разбитые по страницам версии отображались в рамках одного URL, это будет равносильно тому, как если бы все сигналы стекались в один, нежели распределялись по нескольким URL.

Вывод

Надо понимать, что Google придумал теги вроде rel=canonical, NoIndex, rel=prev/next и т.п. как раз для того, чтобы сократить количество анализируемых и индексируемых страниц и сосредоточить внимание на новый страницах. Использование Ajax/JSON/jQuery позволяет делать это просто и элегантно.

На большинстве коммерческих сайтов есть множество различных «аспектов», по которым пользователь может захотеть отсортировать продукцию. С помощью Ajax это можно сделать без создания новых страниц. Конечный пользователь полностью контролирует сортировку контента, при этом поисковым машинам не приходится тратить время на лишние страницы, а сигналы для ранжирования (такие, как ссылки) фокусируются на одной странице, там, где они и должны быть.

Обратной стороной метода является то, что Google не видит весь контент в момент разбивки по страницам. Если контент разносится по страницам примерно одинаково, особых беспокойств у владельцев сайтов это вызывать не должно. Но если на дополнительных страницах контент серьезно отличается от других, такой метод может не подойти.

Описанное решение требует определенных знаний в области Javascript кодирования, но не очень глубоких. Воспользовавшись предложенным методом, вы избежите проблем с тегами и их ограничениями, тем более, что эти теги далеко не всегда эффективны.