SEO Friendly Pagination: полное руководство по передовому опыту

1. Как пагинация может повредить SEO
2. Пагинация вызывает дублирующийся контент
3. Пагинация создает тонкий контент
4. Ранжирование сигналов пагинации
5. Нумерация страниц использует бюджет обхода
6. Управление пагинацией в соответствии с SEO Best Practices
7. Изменить заголовки страниц и мета-описания страниц
8. Не включать страницы в страницы XML
9. Обрабатывать параметры разбиения на страницы в консоли поиска Google
10. Неправильно понятые, устаревшие или просто неправильные SEO-решения для постраничного контента
11. Canonicalize для просмотра всех страниц
12. Канонизировать к первой странице
13. Noindex Paginated Pages
14. Пагинация и бесконечная прокрутка
15. Препятствовать или блокировать пагинацию сканирования
16. Отслеживание влияния KPI на нумерацию страниц

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

Для профессионалов SEO вопрос не в том , придется ли вам разбираться с нумерацией страниц, а в том, когда .

В определенный момент роста веб-сайтам необходимо разделить контент на ряд компонентных страниц для Пользовательский опыт (УБ).

Наша задача - помочь поисковым системам сканировать и понимать взаимосвязь между этими URL-адресами, чтобы они проиндексировали наиболее релевантную страницу.

С течением времени, лучшие SEO методы обработки нумерации страниц развивались. Попутно многие мифы представили себя как факты. Но больше не

Эта статья будет:

Как пагинация может повредить SEO

Вы, наверное, читали, что нумерация страниц вредна для SEO.

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

Давайте посмотрим на предполагаемое зло нумерации страниц и как преодолеть проблемы SEO, которые это может вызвать.

Пагинация вызывает дублирующийся контент

Исправьте, если разбиение на страницы было неправильно реализовано, например наличие страницы «Просмотреть все» и страниц с нумерацией страниц без правильного rel = canonical, или если вы создали страницу = 1 в дополнение к своей корневой странице.

Неправильно, если у вас есть SEO-дружественная нумерация страниц. Даже если ваши H1 и метатеги совпадают, фактическое содержание страницы отличается. Так что это не дублирование.

Пагинация создает тонкий контент

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

Неправильно, когда вы выражаете желание пользователя легко потреблять ваш контент выше доходов от баннерной рекламы или искусственно завышенных просмотров страниц. Положить UX-friendly количество контента на каждой странице.

Ранжирование сигналов пагинации

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

Неправильно, когда атрибуты ссылок rel = ”prev” и rel = ”next” используются на страницах с разбивкой по страницам, поэтому Google знает, как объединить сигналы ранжирования.

Нумерация страниц использует бюджет обхода

Исправьте, если вы разрешаете Google сканировать страницы, разбитые на страницы. И есть несколько случаев, когда вы хотели бы использовать этот бюджет.

Например, чтобы робот Googlebot перемещался по разбитым на страницы URL-адресам, чтобы объединить ранжирующие сигналы и достичь более глубоких страниц контента.

Часто неправильно, когда вы устанавливаете Google Search Console Обработка параметров разбиения на страницы для «Не сканировать» или запретить robots.txt, если вы хотите сохранить бюджет сканирования для более важных страниц.

Управление пагинацией в соответствии с SEO Best Practices

Используйте rel = ”next” & rel = ”prev” Атрибуты ссылки

Вы должны указать связь между URL-адресами компонентов в разбивке на страницы с атрибутами rel = ”next” и rel = ”prev”.

Google рекомендует эту опцию отмечая, что они воспринимают эту разметку как «сильный намек», что вы хотели бы, чтобы страницы рассматривались «как логическая последовательность, объединяя их свойства ссылок и обычно отправляя поисковиков на первую страницу».

Практически это означает, что rel = «next» / «prev» рассматриваются как сигналы, а не как директивы. Они не всегда будут препятствовать отображению страниц с разбивкой по страницам в результатах поиска. Но такое явление было бы редкостью.

Дополните rel = »next» / «prev» ссылкой на rel = «canonical», ссылающейся на себя. Таким образом, / category? Page = 4 должен относиться = "канонический" к / category? Page = 4.

Это рекомендуемый подход Google, так как нумерация страниц изменяет содержимое страницы, как и основная копия этой страницы.

Если в URL есть дополнительные параметры, включите их в ссылки rel = «prev» / «next», но не включайте их в rel = «canonical».

Например:

<link rel = "next" href = "https://www.example.com/category?page=2&order=newest" />

<link rel = "canonical" href = "https://www.example.com/category?page=2" />

Это будет указывать на четкую взаимосвязь между страницами, не посылая сигналы ранжирования на не относящиеся к SEO URL-адреса, основанные на параметрах, и предотвращая возможность дублирования контента.

Распространенные ошибки, которых следует избегать:

• Размещение атрибутов ссылки в содержимом <body>. Они поддерживаются только поисковыми системами в разделе <head> вашего HTML.
• Добавление ссылки rel = ”prev” на первую страницу (также называемую корневой страницей) в серии или ссылку rel = ”next” на последнюю. Для всех других страниц в цепочке должны присутствовать оба атрибута ссылки.
• Остерегайтесь канонического URL вашей корневой страницы. Скорее всего, на? Page = 2, rel = prev должна ссылаться на каноническую, а не на? Page = 1.

Код <head> серии из четырех страниц будет выглядеть примерно так:

• Один тег пагинации на корневой странице, указывающий на следующую страницу в серии.
  • <link rel = "next" href = "https://www.example.com/category?page=2 ″>
  • <link rel = "canonical" href = "https://www.example.com/category">
• Два тега нумерации страниц на странице 2.
  • <link rel = "prev" href = "https://www.example.com/category">
  • <link rel = "next" href = "https://www.example.com/category?page=3 ″>
  • <link rel = "canonical" href = "https://www.example.com/category?page=2">
• Два тега нумерации страниц на странице 3.
  • <link rel = "prev" href = "https://www.example.com/category?page=2 ″>
  • <link rel = "next" href = "https://www.example.com/category?page=4 ″>
  • <link rel = "canonical" href = "https://www.example.com/category?page=3">
• Один тег нумерации страниц на странице 4, последняя страница в постраничной серии.
  • <link rel = "prev" href = "https://www.example.com/category?page=3">
  • <link rel = "canonical" href = "https://www.example.com/category?page=4">

Изменить заголовки страниц и мета-описания страниц

Хотя атрибуты rel = «next» и rel = «prev» должны в большинстве случаев побуждать Google возвращать корневую страницу в поисковой выдаче, вы можете дополнительно поощрять это и предотвращать предупреждения «Duplicate meta description» или «Duplicate title tags» в консоли поиска Google с легкой модификацией вашего кода.

Если корневая страница имеет формулу:

Последовательные постраничные страницы могут иметь формулу:

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

Не включать страницы в страницы XML

Хотя rel = ”next” / “prev” URL-адреса нумерации страниц технически индексируются, они не являются приоритетом SEO для расходования бюджета на обход.

Как таковые, они не принадлежат вашей карте сайта XML.

Обрабатывать параметры разбиения на страницы в консоли поиска Google

Если у вас есть выбор, запустите пагинацию с помощью параметра, а не статического URL. Например:

example.com/category?page=2 over example.com/category/page-2

Затем вы можете настроить параметр в консоли поиска Google на «Paginates» и в любое время изменить сигнал на Google для сканирования «Каждый URL» или «Нет URL» в зависимости от того, как вы хотите использовать свой бюджет сканирования. Разработчик не нужен!

Неправильно понятые, устаревшие или просто неправильные SEO-решения для постраничного контента

Ничего не делать

Google говорит, что они «хорошо работают, возвращая наиболее релевантные результаты пользователям, независимо от того, разделено ли содержимое на несколько страниц», и рекомендует вам справиться с нумерацией страниц, ничего не делая.

Хотя в этом утверждении есть доля правды, ничего не делая, вы играете с вашим SEO.

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

Canonicalize для просмотра всех страниц

Последний вариант, рекомендованный Google, это страница Просмотреть все. Эта версия должна содержать все содержимое страницы компонента в одном URL.

Кроме того, все страницы с нумерацией страниц должны относиться к каноническому на странице «Просмотреть все», чтобы объединить сигналы ранжирования.

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

Таким образом, если у вашей серии с нумерацией страниц есть альтернативная версия Просмотреть все, которая предлагает лучший пользовательский опыт, Google предпочтет эту страницу для включения в результаты поиска, а не соответствующую страницу сегмента цепочки нумерации страниц.

В связи с этим возникает вопрос - почему у вас страницы в первую очередь разбиты на страницы?

Давайте сделаем это просто.

Если вы можете предоставить свой контент по одному URL-адресу, предлагая при этом хороший пользовательский опыт, нет нужды в нумерации страниц или в версии «Просмотреть все».

Если вы, например, не можете, страница категории с тысячами товаров будет смехотворно большой и займет слишком много времени для загрузки, тогда разбейте на страницы с помощью rel = »next» / «prev». «Просмотреть все» - не лучший вариант, поскольку он не обеспечит хорошее взаимодействие с пользователем.

Использование как rel = »next» / «prev», так и версии «Просмотреть все» не дает четкого мандата Google и приведет к путанице сканеров.

Не делай этого.

Канонизировать к первой странице

Распространенной ошибкой является указание rel = ”canonical” из всех разбитых на страницы результатов на корневую страницу серии.

Некоторые плохо информированные SEO-специалисты предлагают это как способ консолидации полномочий на множестве страниц до корневой страницы, но это не нужно, если у вас есть атрибуты rel = ”next” и rel = ”prev”.

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

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

Вы не хотите, чтобы страницы с подробным содержимым выпадали из индекса из-за плохой обработки нумерации страниц.

Гугл ясно по требованию. Каждая страница в постраничной серии должна иметь каноническую ссылку на себя, если только вы не используете страницу «Просмотреть все».

Неправильно используйте rel = canonical, и скорее всего робот Google просто проигнорирует ваш сигнал.

Noindex Paginated Pages

Классическим методом решения проблем с нумерацией страниц был тег noindex роботов, который предотвращает индексацию контента с нумерацией страниц поисковыми системами.

Использование только тега noindex для разбивки на страницы приведет к тому, что сигналы ранжирования страниц вашего компонента не будут консолидированы. Явно уступает SEO в использовании rel = »next» / «prev».

Но так как метод rel = »next» / «prev» позволяет поисковым системам индексировать страницы разбиения на страницы, я также видел, как некоторые SEO-специалисты рекомендовали добавить «дополнительную безопасность» с помощью тега noindex.

Это не нужно. Только в редких случаях Google решит вернуть постраничную страницу в поисковой выдаче. Преимущества в лучшем случае теоретические.

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

Пагинация и бесконечная прокрутка

Более новая форма обработки страниц - бесконечная прокрутка, при которой содержимое предварительно выбирается и добавляется непосредственно на текущую страницу пользователя по мере его прокрутки вниз.

Пользователи могут оценить это, но Googlebot? Не так много.

Робот Googlebot не эмулирует поведение, такое как прокрутка вниз страницы или щелчок, чтобы загрузить больше. То есть без помощи поисковые системы не могут эффективно сканировать весь ваш контент.

Чтобы быть SEO-дружественным, преобразуйте свою страницу бесконечной прокрутки в эквивалентную постраничную серию, доступную даже с отключенным JavaScript.

Когда пользователь выполняет прокрутку, используйте JavaScript, чтобы адаптировать URL-адрес в адресной строке к разбивке на страницы компонента.

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

По сути, вы все еще применяете лучшие рекомендации SEO, рекомендованные выше, вы просто добавляете дополнительные функции взаимодействия с пользователем.

Препятствовать или блокировать пагинацию сканирования

Некоторые SEO-профессионалы рекомендуют вообще избегать проблемы с разбивкой по страницам, просто не давая Google сканировать разбитые на страницы URL-адреса.

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

Есть три способа сделать это:

• Грязный путь : добавьте nofollow ко всем ссылкам, которые указывают на страницы, разбитые на страницы.
• Более чистый способ : используйте robots.txt disallow.
• Способ, не требующий разработки : установите для параметра paginated page значение «Paginates», чтобы Google сканировал «No URLs» в консоли поиска Google.

Используя один из этих методов, чтобы воспрепятствовать поисковым системам сканировать разбитые на страницы URL-адреса, вы:

• Остановите поисковые системы от консолидации ранжирования сигналов страниц.
• Предотвратите передачу внутренних ссылок со страниц с нумерацией страниц на целевые страницы контента.
• Помешать Google найти целевые страницы.

Очевидным преимуществом является то, что вы экономите на бюджете сканирования.

Здесь нет ясного правильного или неправильного. Вы должны решить, что является приоритетным для вашего сайта.

Лично, если бы я расставил приоритеты в бюджете сканирования, я бы сделал это, используя обработку разбивки на страницы в Google Search Console, так как она имеет оптимальную гибкость, чтобы передумать.

Отслеживание влияния KPI на нумерацию страниц

Итак, теперь вы знаете, что делать, как вы отслеживаете эффект оптимизации разбивки на страницы?

Во-первых, соберите данные тестов, чтобы понять, как ваша текущая обработка страниц влияет на SEO.

Источники для KPI могут включать:

• Файлы журнала сервера для количества постраничных обходов страниц.
• Сайт: оператор поиска (например, site: example.com inurl: page), чтобы понять, сколько страниц с нумерацией страниц проиндексировано Google.
• Google Search Console Search Analytics Отчет фильтруется по страницам, содержащим нумерацию страниц, чтобы понять количество показов.
• Отчет по целевой странице Google Analytics фильтруется по разбитым на страницы URL-адресам для понимания поведения на месте.

Если вы столкнулись с проблемой поиска поисковых систем для поиска страниц вашего сайта, возможно, вы захотите изменить нумерацию ссылок ,

После того, как вы запустите свою лучшую практику обработки пагинаций, еще раз проверьте эти источники данных, чтобы измерить успех ваших усилий.

Больше SEO ресурсов:

Кредиты изображений

Главное изображение: Создано автором, октябрь 2018
In-Post Images / Скриншоты: Создано / Автор: октябрь 2018 г.