Google поменял rel=prev/next и все сломали пагинацию

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

Давайте взглянем как мог выглядеть код для серии из трёх страниц.

Первая страница:

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

<link rel="next" href="https://website.com/page/2/>

Вторая страница:

Здесь обозначаются следующая и предыдущая страницы.

<link rel="next" href="https://website.com/page/3/>

<link rel="prev" href="https://website.com/page/1/>

Третья страница:

Это последняя страница, поэтому здесь нужно указать только предыдущую страницу.

<link rel="prev" href="https://website.com/page/2/>

Но в 2019‑м году в Google решили нам сообщить о том, что они больше не используют разметку rel=prev/next для обозначения пагинации. Даже хуже: оказалось что они не используют её уже несколько лет.

Весенняя чистка!

Мы оценили наши сигналы для индексирования и решили отказаться от rel=prev/next.
Исследования показывают, что пользователям больше нравится контент на одной страницу. Где возможно, старайтесь всё размещать на одной странице. Но для поиска Google работает и серии страниц из нескольких частей. Делайте так, как будет лучше для *ваших* пользователей! #springiscoming pic.twitter.com/hCODPoKgKp

— Google Webmasters (@googlewmc) March 21, 2019

Это изменение не повлияло на SEO. Если на сайте используется несколько блоков одинакового текста, вашему сайту это не навредит и никаких санкций за это не будет. Не стоит бояться такого дублированного контента. Google всё равно будет пытаться выбрать самый подходящий контент.

Поэтому вопрос в следующем: зачем что-то менять? И нужно ли что-то делать? Если да, то что?

В этом посте вы узнаете:

Давайте начнём с первого вопроса.

Почему Google перестал поддерживать rel=prev/next?

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

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

Учитывая это, скорее всего они перестали поддерживать rel=prev/next потому что научились лучше разбираться и им больше не нужна такая разметка.

Кроме rel=prev/next у Google есть несколько вариантов для распознавания страниц в серии. В основном, на всех сайтах это работает одинаково, поэтому Google может смотреть на:

• Заголовки
• Теги title (когда используется один и тот же заголовок, но с разными цифрами)
• Ссылки на странице (внутренние ссылки на подобные страницы из серии)

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

Почему уже было ясно что rel=prev/next не работает?

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

Ответ простой: узнать было невозможно. Если бы Google не сказал, мы бы и не узнали.

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

Стоит ли удалять rel=prev/next?

Нет.

Если на вашем сайте уже есть разметка rel=prev/next, не стоит её удалять. Google не единственный кому она нужна. Она всё ещё рекомендована W3C  и нужна для веб-доступности и для соответствия ADA. Некоторые браузеры используют её для предзагрузки. А некоторые поисковые системы, такие как Bing, всё ещё её используют.

Мы используем разметку rel prev/next для сканирования и понимания структуры сайта. На сегодняшний день мы не склеиваем страницы пагинации в индексе и не используем prev/next в ранжировании. https://t.co/ZwbSZkn3Jf

— Frédéric Dubut (@CoperniX) March 21, 2019

Допустимые способы разметки пагинации

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

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

Как люди вредят своим сайтам

Так выглядит привычный вариант пагинации, где сканируется каждая страница:

Но при внедрении пагинации люди часто повторяют одни и те же ошибки, которые вредят их сайтам:

• Каноникализируют первую страницу
• Остальные страницы закрывают от индексации
• Ставят ссылки в nofollow
• Запрещают сканирование

Давайте подробнее взглянем на каждую из ошибок и узнаем как их проверить на своём сайте.

Ошибка 1: Каноникализация первой страницы

В лучшем случае Google просто проигнорирует тег canonical. Если нет, то таким образом отрезаются пути сканирования остальных страниц и многие становятся страницами-сиротами. Из-за этого поисковым системам сложнее находить и индексировать ценный контент. Также прекращается передача PageRank на другие страницы.

Как проверить ошибки на своём сайте

Просканируйте сайт с помощью инструмента Аудит Сайта в Ahrefs. Перейдите в Page Explorer и примените следующие фильтры.

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

Ошибка 2: Запрет на индексацию

Если вы добавите noindex на страницы, они будут удалены из поиска. Страницы перестанут ранжироваться и PageRank не будет передаваться на них.

Ссылки на странице могут быть просканированы, но в будущем это может поменяться. Аналитик Google Webmaster Trends Джон Мюллер упоминал о том, что страницы с noindex могут в будущем восприниматься как nofollow, но пока непонятно когда это будет. Когда другого аналитика Webmaster Trends Гари Илша спросили об этом, он ответил что скорее всего страницы будут просканированы.

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

Как проверить эту ошибку на своём сайте

Просканируйте сайт в Сайт Аудите Ahrefs, затем перейдите в Page Explorer и примените следующие фильтры:

Если будут URL, которые совпадают с фильтром, удалите директиву noindex из мета тега robots или заголовка X‑Robots-Tag HTTP на странице.

Ошибка 3: Ссылки в nofollow

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

Как проверить эту ошибку на своём сайте

Просканируйте сайт в Сайт Аудите Ahrefs, затем перейдите в Page Explorer и примените следующие фильтры:

Если будут URL, которые совпадают с фильтром, кликните по колонке “No. of inlinks nofollow”.

Вы увидите оверлей, на котором показано где можно найти ссылки с nofollow на вашем сайте.

Удалите атрибуты nofollow с этих ссылок, или удалите директиву в robots, запрещающую сканирование, либо в заголовке X‑Robots-Tag на странице.

Ошибка 4: Запрет на сканирование

Запретив сканирование страниц вы усложните поиск контента на сайте, ваши страницы станут страницами-сиротами и PageRank не будет передаваться дальше по сайту.

Как проверить эту ошибку на своём сайте

Проверьте файл robots.txt на наличие директив, блокирующих поисковые системы от сканирование страниц пагинации. Вот как они могут выглядеть:

User-agent: *
Disallow: /blog/page/

Удалите эти директивы из файла robots.txt.

Заключение

Если на вашем сайте уже настроена пагинация через rel=prev/next, не трогайте её. Нет смысла её менять. Вы можете сделать больше вреда, чем пользы.

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

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

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

Если вдруг кому-то нужна будет ссылка на оригинальную документацию, которая была удалена, то вот она.

Остались вопросы о rel=prev/next или пагинации? Напишите мне в Twitter.

Перевел Дмитрий Попов, владелец Affilimarketer.com

Постраничная верстка rel=«next|prev» / Хабр

Наряду с использование атрибута

rel=«canonical»

для указания поисковому боту на дублирование контента, теперь возможно использовать для HTML ссылок значение rel=“next” и rel=“prev” для обозначения положения текущей страницы в отношении соседних в рамках навигационного блока. В рамках веба встречаются различные варианты использования постраничной навигации — статья, разделенная на несколько страниц, либо категория товаров распределенных по нескольким страницам, либо ветка форума, разделенная на последовательность URL-ов. Теперь, включив rel=“next” и rel=“prev” в верстку страниц, мы можем указать Google:

• Создать консолидированный индекс страниц, чтобы ссылки не рассеивались между отдельными страницами page-1.html, page-2.html, и так далее
• При поиске направить пользователя на наиболее релевантную страницу среди всех остальных, например в начало статьи, разбитой на несколько страниц

Есть исключение при использовании rel=“next|prev” в том случае, если у вас реализована страница «Показать все», на которой, к примеру, показываются все товары категории без разбивки на страницы. В таком случае прочтите, пожалуйста,

эти рекомендации

.

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

Ваши действия

Вот три варианта:

1. Оставить все, как есть. Многостраничный контент встречается во всем Интернете, и Google будет продолжать прилагать все усилия, чтобы найти для пользователя лучший результат, независимо от того используете вы атрибут rel или нет.
2. Если у вас есть страница «Показать все», обратите внимание на наши рекомендации.
3. Указывать для Google атрибут rel. Это поможет системе более точно проиндексировать ваш контент и показывать пользователям наиболее релевантные страницы. Детали реализации ниже.

Использование rel=“next|prev”

Если вы предпочитаете последний вариант, давайте приступим! Допустим, у вас есть контент и он представлен следующим образом:

www.example.com/article?story=abc&page=1
www.example.com/article?story=abc&page=2
www.example.com/article?story=abc&page=3
www.example.com/article?story=abc&page=4

На первой странице, www.example.com/article?story=abc&page=1, вам необходимо включить в следующий блок:

<link rel="next" href="http://www.example.com/article?story=abc&page=2" />

На второй странице,

www.example.com/article?story=abc&page=2

:

<link rel="prev" href="http://www.example.com/article?story=abc&page=1" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3" />

На третьей странице,

www.example.com/article?story=abc&page=3

:

<link rel="prev" href="http://www.example.com/article?story=abc&page=2" />
<link rel="next" href="http://www.example.com/article?story=abc&page=4" />

А на последней странице,

www.example.com/article?story=abc&page=4

:

<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

Несколько замечаний:

• Первая страница содержит только rel=«next».
• Страница со второй до последней содержат и rel=«next», и rel=«prev».
• Последняя страница содержит только rel=«prev».
• Значения href могут быть либо относительным, либо абсолютным URL. И, если вы объявили base в документе, относительные пути будет просчитаны в соответствии с базовым URL.
• Разрешено использование значения rel=«previous» как альтернативы rel=”prev”.
• В случае не правильной разметки, Google продолжит индексировать ваш контент собственной эвристикой не опираясь на указанный rel.

Хорошей верстки, и интересных проектов!

Постраничная верстка rel=«next|prev» — SEO блог luckyman’a

Автор Игорь Градов На чтение 4 мин.

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

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

Включение rel=“next” и rel=“prev” в верстку поможет указать Google:

• Общий и постоянный индекс страниц, чтобы ссылки не рассеивались между отдельными страничками PAGEN_1=1, PAGEN_1=2 и т.д.
• Чтобы пользователи при поиске был направлен на наиболее релевантную страницу. Например, если текст разбит на несколько страниц – то направление будет на начало статьи.

Не подойдет использование артибута rel=“next|prev” для страниц, вроде «Показать всё», где обычно выводятся все товары определенной категории без разделения на несколько урлов.

В этом случае воспользуйтесь рекомендациями:

Страницы «Показать всё» важна и предпочтительна для интернет-покупателей, поэтому задача оптимизатора – сделать так, чтобы именно она была в результатах поиска, а не ряд страниц с тегами rel=“next|prev”. Если на вашем сайте такой страницы нет, можете использовать данный атрибут rel по вышеописанному методу.

Что делать?

Есть 3 варианта:

1. Ничего не менять. Сайты с многостраничным контентом в сети – далеко не редкость, и поисковые системы (в частности, Google) будет продолжать выискать для пользователей лучшие результаты, независимо от применения тега rel.
2. При наличии страницы «Показать всё» прислушайтесь к данным здесь рекомендациям.
3. Указать для Гугл атрибут rel, что поможет поисковику оптимальнее индексировать контент сайта и выдавать юзерам самые релевантные страницы.

Используем тег rel=“next|prev”

Если выбрали третий вариант, сделайте следующее.

Предположим, ваш контент выглядит примерно так:

• www.site.ru/article?story=abc
• www.site.ru/article?story=abc&page=2
• www.site.ru/article?story=abc&page=3
• www.site.ru/article?story=abc&page=4

Для первой страницы, www.site.ru/article?story=abc, включите в следующий блок это:

<link rel="next" href="http://www.site.ru/article?story=abc&page=2" />

Для второй страницы www.site.ru/article?story=abc&page=2:

<link rel="prev" href=" http://www.site.ru/article?story=abc" />

<link rel="next" href=" http://www.site.ru/article?story=abc&page=3" />

На 3-ей странице, www.site.ru /article?story=abc&page=3:

<link rel="prev" href="http://www.site.ru/article?story=abc&page=2" />

<link rel="next" href=" http://www.site.ru/article?story=abc&page=4" />

А на четвертой, последней странице, www.site.ru/article?story=abc&page=4:

<link rel="prev" href=" http://www.site.ru/article?story=abc&page=3" />

Обратите внимание:

• В первой странице содержится только rel=«next».
• Последующие страницы, кроме последней, содержат как rel=«next», так и rel=«prev».
• В последней странице используется только rel=«prev».
• Можно значение rel=”prev” заменять rel=«previous».
• Если разметка содержит ошибки, Google будет индексировать контент сайта, без учета указанного rel.
• HREF может быть в виде абсолютных и относительных ссылок. И если это указано в базе данных в документе, относительные URL будут просчитаны в соответствии с базовыми.

Insights from Google Crawling Behavior

В экосистеме, где домыслы и теории доминируют в дебатах, заявление Google от 21 марта о том, что теги rel next / prev больше не используются поисковой системой, вызвало виртуальную приливную волну.

Мы стали свидетелями обвала твитов, лавины вопросов и потока острых комментариев о самой известной поисковой системе.

Если бы SEO была фондовой биржей, это был бы еще один исторический крах.

Предыстория тегов Rel = Next / Prev

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

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

Следуя рекомендациям Google, стало стандартной передовой практикой в ​​SEO указывать следующую и предыдущую страницы серии с разбивкой на страницы на странице с помощью этих тегов.

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

Реклама

Продолжить чтение ниже

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

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

Илья Григорик, инженер по веб-производительности в Google, подчеркивает этот момент:

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

— Илья Григорик (@igrigorik) 22 марта 2019 г.

Ложная проблема разбивки на страницы

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

На мой взгляд, это вызывает другой вопрос и проливает свет на интересный элемент современного дизайна веб-сайтов.

Несмотря на то, что методы разработки изменились (в том числе некоторые, такие как JavaScript, что приводит к путанице и спорам), навигационное мышление осталось прежним. Это верно, говорим ли мы об онлайн-публикации или электронной коммерции.

Реклама

Продолжить чтение ниже

Это то, что я страстно осуждал, работая SEO-специалистом в веб-агентстве: почему менеджеры электронной коммерции все еще пытаются создать столько страниц продукта, сколько доступно атрибутов / вариантов одного продукта?

Это было и остается бессмысленным с моей точки зрения.

Сигналы индексирования продолжают играть роль, хотя разбиение на страницы больше не указывается явно. Можно утверждать, что нечто подобное происходит с rel = canonical.

Все больше и больше специалистов по SEO сообщают, что Google игнорирует объявленные ими канонические страницы, особенно когда контент не соответствует, и выбирает собственные.

Google, похоже, не полагается на сигналы индексации для обнаружения страниц продуктов.

Другие способы организации веб-сайта также имеют значительно большее значение, чем разбиение на страницы, как для SEO, так и для пользователей вашего веб-сайта, например:

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

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

О чем говорят данные

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

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

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

В этом случае я собираюсь посмотреть на посещения Google по всем URL за длительный период времени.

Реклама

Продолжить чтение ниже

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

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

Еще более интересно взглянуть на схему сканирования: какой URL просканируется первым и какие URL просканируются дальше?

Реклама

Продолжить чтение ниже

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

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

Мы также должны помнить, что Google — это не человек.

Реклама

Продолжить чтение ниже

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

Какие выводы можно сделать из поведения Google?

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

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

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

В ожидании дальнейшего изучения, если вас интересует rel pre / next и как определить вашу разбивку на страницы, вот мое предложение:

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

Реклама

Продолжить чтение ниже

Объявления Google и данные сканирования из журналов показывают, что поисковая система перестала использовать rel next / prev в качестве фактора индексации не для того, чтобы раздражать профессионалов SEO, а потому, что теперь она освоила разбиение на страницы на основе текущая логика навигации по сайту.

Дополнительные ресурсы:

---

Изображение предоставлено

Снимки экрана, сделанные автором, апрель 2019 г.

Как использовать теги Rel = Next / Rel = Previous. Глоссарий SEO

Что такое Rel = Prev и Rel = Next?

Эти функции были введены Google в сентябре 2011 года для решения проблемы дублирования контента. Rel = Prev и Rel = Next добавляются в HTML-код веб-сайта, чтобы поисковые системы знали, что определенная коллекция последовательных страниц должна быть проиндексирована вместе.

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

Что они делают?

Rel = Prev и Rel = Next необходимы для контента, который не умещается на одной странице без продолжения страницы далеко ниже сгиба. Внизу каждой страницы есть кнопка «предыдущая» или «следующая». Вы перейдете либо к продолжению статьи, либо к предыдущей ее странице.

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

Пример тегов rel = prev и rel = next в коде:

Почему это важно для поисковой оптимизации?

Rel = Prev и Rel = Next позволяют Google легче понять, что именно он просматривает, и впоследствии направлять пользователей на наиболее релевантную страницу, которая обычно является первой страницей в серии.Если они не используются, может возникнуть ситуация, когда страница 2, 3 или 4 статьи будет иметь более высокий рейтинг в поиске Google, чем первая страница.

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

Google заявляет, что не использует rel = prev / next для разбивки на страницы • Yoast

Эдвин Тоонен

Эдвин — специалист по стратегическому контенту.Прежде чем присоединиться к Yoast, он провел годы, оттачивая свое мастерство в ведущем журнале по веб-дизайну Нидерландов.

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

rel = prev / next вообще и не использовала в течение многих лет. Это любопытно, потому что до недавнего времени они пропагандировали его использование.

Так о чем мы здесь говорим?

Веб-стандарт rel = prev / next был введен много-много лет назад, чтобы помочь определить отношения между частями URL-адресов или разными страницами. В 2011 году Google начал использовать эти ссылки в качестве надежных подсказок для поиска связанных страниц. Почти каждый сайт сейчас использует эти ссылки, чтобы дать эти подсказки. Yoast SEO автоматически добавляет эти ссылки для наших пользователей. Теперь выясняется, что Googlebot считается настолько «умным» в Google, что ему больше не нужна помощь.

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

Красиво и просто, правда? Хотя неясно, что означают изменения нумерации страниц для огромных сайтов электронной коммерции, например: удачи в попытках втиснуть 10 000 товаров на одну страницу с полным просмотром.

Старый совет

Совет Google по поводу его теперь удаленной страницы справки для веб-мастеров дал следующие три варианта обработки разбитого на страницы содержания:

Цитата:

• Ничего не делать.Контент с разбивкой на страницы очень распространен, и Google хорошо справляется с задачей, возвращая пользователям наиболее релевантные результаты, независимо от того, разделен ли контент на несколько страниц.
• Реализовать страницу «Просмотреть все». Поисковики обычно предпочитают просматривать всю статью или категорию на одной странице. Поэтому, если мы думаем, что это именно то, что ищет поисковик, мы стараемся отображать страницу «Просмотреть все» в результатах поиска. Вы также можете добавить ссылку rel = "canonical" на страницы компонентов, чтобы сообщить Google, что версия «Просмотреть все» — это версия, которую вы хотите отображать в результатах поиска.
• Используйте ссылки или заголовки rel = "next" и rel = "prev" , чтобы указать взаимосвязь между URL-адресами компонентов. Эта разметка дает Google четкий намек на то, что вы хотели бы, чтобы мы рассматривали эти страницы как логическую последовательность. , таким образом объединяя их свойства ссылок и обычно отправляя искателей на первую страницу.

Unquote.

Эта страница была доступна до начала этой недели, и просто удалять такую ​​страницу — не лучшая практика.Было бы гораздо разумнее обновить статью или показать уведомление о том, что что-то изменилось. Просто удалить его, даже не перенаправив на что-то еще полезное, кажется неуместным. На данный момент исходное сообщение в блоге, объявляющее об использовании rel = prev / next в Google, все еще доступно — с новым уведомлением вверху.

Что сейчас говорит Google?

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

Это, однако, не означает, что вам следует удалить все ссылки rel = prev / next , над реализацией которых вы так усердно работали.

Важно помнить, что это веб-стандарт и что помимо Google существуют и другие поисковые системы. Фредерик Дубут из Bing уже сказал, что они используют rel = prev / next в качестве подсказок для обнаружения страниц и понимания структуры сайта, но не для группировки страниц или их ранжирования.

Что теперь?

Пока мы ждем, пока осядет пыль и, может быть, посмотрим, не предложит ли Google новый способ обработки нумерации страниц, вот несколько вещей, о которых следует помнить:

Итак, пока оставим все как кажется наиболее разумным вариантом.Поскольку это стандарт W3C, а не просто то, что придумал Google, лучше его придерживаться. Однако сейчас — это — хорошее время, чтобы хорошенько взглянуть на структуру вашего сайта!

А что это значит для Yoast SEO?

Yoast SEO уже много лет занимается разбивкой на страницы для сайтов WordPress. Как я уже сказал, мы автоматически добавляем все, что нужно поисковым системам, чтобы понять, как все сочетается друг с другом, например, rel = prev / next и самодостаточный canonical.

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

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

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

Следите за обновлениями!

Google’s Advice on Pagination & Page Series Post rel = next и rel = prev

Как вы знаете, Google сообщил нам, что они только что поняли, что rel = next и rel = prev больше не поддерживаются в течение прошлого года или около того.Да, я знаю. Ну что теперь? Как вы гарантируете, что Google сможет найти ваш постраничный контент? Как сообщить Google, что серия страниц является частью набора? Сегодня утром Михай Апергис задал Джону Мюллеру несколько трудных вопросов на видеовстрече для веб-мастеров.

Вопросы и ответы начинаются на 14:35 видео. Я выложу расшифровку стенограммы и вставлю ниже. Но чтобы сделать это быстро, поскольку это примерно 10 минут видео, я опубликую основные моменты из раздела вопросов и ответов:

• Просто продолжайте делать то, что вы делаете, с разбивкой на страницы.
• Если до сих пор у вас не было проблем, значит, все, что вы делали, работает.
• Google не поддерживал их
лет
• Google только что понял, что они не поддерживали их годами.
• Google немедленно захотел сообщить сообществу, что они это узнали.
• Таким образом, Google не будет указывать людям делать «отчасти ненужные». Я полагаю, что здесь Джон имеет в виду отсутствие необходимости сообщать Google о объединении страниц в набор.
• Ничего не нужно менять.
• Это точно не тот случай, когда вам нужно удалить всю пагинацию
• То же, не тот случай, что нужно и сделать одну гигантскую страницу.
• Но вам нужно убедиться, что страницы с разбивкой на страницы могут стоять сами по себе.
• Используйте сторонние инструменты, чтобы узнать, есть ли проблемы со сканированием для доступа к подробным страницам продуктов.

Вот видео, встраиваемое в момент начала:

Вот расшифровка:

ВОПРОС: Раз уж мы говорим об индексировании вашего, ну, сообщение Google о rel next rel prev удаляется.Было много разговоров о том, как Google упомянул, что вариант использования его для статей в нескольких частях, что не всегда так, что rel next rel prev может использоваться в этом сценарии, по крайней мере, по моему опыту, он в основном используется, особенно на сайтах электронной коммерции с категориями с разбивкой на страницы. Что будет, если rel next rel prev будет удален, что будет лучше всего сделать с категориями страниц разбивки на страницы и тому подобным?

ОТВЕТ: Я бы просто сделал их как обычно, как вы это делаете сейчас.Так что, я думаю, это то, что мы хотели донести, и я думаю, что мы не смогли это сделать так гладко. Но, по сути, это уже довольно долгое время, когда мы не используем rel next ‘и rel previous, это то, что мы только недавно осознали, когда обсуждали вещи с командой. И, по сути, по большей части я редко видел, чтобы какие-либо SEO-специалисты сталкивались с проблемами с разбивкой на страницы. Так что, если разбивка на страницы работает для вас сейчас, значит, вы все делаете правильно.Как будто там ничего не нужно менять. Это определенно не тот случай, когда вам нужно удалить всю разбивку на страницы и сделать одну гигантскую страницу. По сути, вы разбиваете на страницы так, как это имеет смысл. Вы связываете версии с разбивкой на страницы, и у вас есть следующая и прямая обратные ссылки, у некоторых людей есть ссылки перехода, которые, по их словам, похожи на пять или десять страниц дальше. Это зависит от того, сколько контента вам нужно для разбивки на страницы.

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

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

ВОПРОС: Требуется ли вам что-нибудь еще для того, чтобы веб-мастера могли указать вам в том направлении, что это набор, например, страницы, такие как серия нумерации страниц, возможно, параметр страницы или что-то в этом роде. оценить, является ли это частью набора страниц, скажем, той же категории?

ОТВЕТ: Не очень.Я имею в виду, что мы используем внутренние ссылки. Что по большей части проясняет ситуацию.

Еще одна вещь, которую можно упомянуть в отношении rel next и rel previous, — это то, что использует не только Google. То, что мы его не используем, не означает, что вы должны уйти и вырвать его, потому что это вызовет проблемы, это определенно не вызовет проблем для Google. Некоторые браузеры используют его, например, для предварительной выборки, другие поисковые системы могут использовать его, вы можете использовать его для других целей.Это часть спецификации HTML, поэтому это не похоже на то, что что-то сломает. Так что дело не в том, что вам нужно его оторвать, и это вызовет проблемы, иначе вы можете оставить его там и продолжать использовать, просто мы не используем его для индексации.

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

ОТВЕТ: Это их дело. Я думаю, иногда имеет смысл использовать отсутствие индекса. Иногда имеет смысл отфильтровать фильтры и параметры сортировки в противном случае. Вы можете использовать инструмент обработки параметров URL в консоли поиска, чтобы рассказать нам больше о том, как вы хотите, чтобы эти страницы сканировались.

Я думаю, что особенно в отношении электронной коммерции я бы порекомендовал попробовать кое-что с локальным поисковым роботом. Так что такие инструменты, как Screaming Frog, как Deep Crawl.Я не знаю, как они все называются. Но есть много действительно хороших инструментов, которые будут сканировать ваш сайт и сообщать вам, как вы можете найти все страницы продуктов. И это очень важная часть для нас, особенно для сайтов электронной коммерции, что мы можем перейти на эти страницы списков и каким-то образом обнаружить все отдельные страницы продуктов. И вы можете помочь в этом, связав связанные продукты, например, связав отдельные продукты и разные категории — все, что помогает. Но если нам, например, нужно перейти на страницу 25 связанного списка, чтобы найти те продукты, которые будут для нас действительно сложными.Я уверен, что это то, о чем я думаю, особенно в последние пару лет, есть несколько действительно потрясающих инструментов. Там, где определенно имеет смысл протестировать свой веб-сайт, особенно если у вас есть сайт электронной коммерции, и вы беспокоитесь о разбиении на страницы и фильтрации, например, Googlebot теряется в море бесконечных URL-адресов или Googlebot может его найти.

Еще от Google на этом:

Генеральная уборка!

По мере того, как мы оценивали наши сигналы индексации, мы решили исключить rel = prev / next.
Исследования показывают, что пользователям нравится одностраничный контент, стремитесь к этому, когда это возможно, но многостраничный контент также подходит для поиска Google. Знайте и делайте то, что лучше всего для * ваших * пользователей! #springiscoming pic.twitter.com/hCODPoKgKp

— Google Webmasters (@googlewmc) 21 марта 2019 г.

Нет.

— Гэри «鯨 理» Иллис (@methode) 21 марта 2019 г.

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

— 🍌 John 🍌 (@JohnMu) 21 марта 2019 г.

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

— 🍌 John 🍌 (@JohnMu) 21 марта 2019 г.

Управление параметрами в порядке — мы используем его в первую очередь для сканирования.

— 🍌 John 🍌 (@JohnMu) 21 марта 2019 г.

Обсуждение на форуме в Твиттере.

Как проводить аудит rel = «next» & rel = «prev» Атрибуты разбивки на страницы для SEO

Как проводить аудит rel = «next» и rel = «prev» с помощью SEO Spider

Атрибуты разбиения на страницы rel = «next» и rel = «prev» используются для обозначения взаимосвязи между URL-адресами компонентов в разбитом на страницы ряду с поисковыми системами.Они помогают объединить свойства индексации в последовательности и направляют пользователей на наиболее релевантный URL-адрес в этой последовательности.

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

Несмотря на то, что это относительно простая концепция, очень часто веб-сайты неправильно используют атрибуты нумерации страниц. 21 марта 2019 года Google объявил, что они долгое время не использовали rel = «next» и rel = «prev» при индексировании, другие поисковые системы, такие как Bing (который также поддерживает Yahoo), по-прежнему используют его в качестве подсказки. для открытия и понимания структуры сайта.

Из этого туториала Вы узнаете, как использовать Screaming Frog SEO Spider для быстрой и эффективной проверки реализации нумерации страниц rel = «next» и rel = «prev». SEO Spider будет сканировать атрибуты пагинации, сообщать об их настройке и распространенных ошибках.

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

1) Выберите «Сканировать» и «Сохранить» в разделе «Конфигурация»> «Паук».

«Конфигурация» SEO Spider доступна в меню верхнего уровня.

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

2) Сканирование веб-сайта

Откройте SEO Spider, введите или скопируйте веб-сайт, который вы хотите сканировать, в поле «Введите URL-адрес для паука» и нажмите «Начать».

Будет сканироваться веб-сайт и атрибуты rel = «next» и rel = «prev».

Теперь возьмите кофе и подождите, пока индикатор выполнения не достигнет 100% и сканирование завершится.

3) Просмотр вкладки разбивки на страницы

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

На вкладке «Разбивка на страницы» есть 10 фильтров (как показано на рисунке ниже), которые помогут вам понять реализацию атрибута разбиения на страницы и выявить типичные проблемы с разбивкой на страницы.

8 из 10 фильтров доступны для просмотра сразу во время или в конце сканирования. Фильтры «Несвязанные URL разбиения на страницы» и «Цикл разбиения на страницы» требуют вычисления в конце сканирования с помощью сообщения «Анализ сканирования», чтобы они были заполнены данными (подробнее об этом чуть позже).

На правой панели «Обзор» отображается сообщение «(Требуется анализ сканирования)» для этого фильтра, который требует заполнения данных после анализа сканирования.

4) Нажмите «Анализ сканирования> Начать», чтобы заполнить фильтры разбивки на страницы.

Чтобы заполнить фильтры «Несвязанные URL разбиения на страницы» и «Цикл разбиения на страницы», вам просто нужно нажать кнопку, чтобы начать анализ сканирования.

Однако, если вы ранее настроили «Анализ сканирования», вы можете дважды проверить в разделе «Анализ сканирования> Настроить», что отмечена галочка «Пагинация».

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

Когда анализ сканирования будет завершен, индикатор выполнения «анализа» будет на 100%, и фильтры больше не будут отображать сообщение «(Требуется анализ сканирования)».

5) Нажмите «Разбивка на страницы» и просмотрите заполненные фильтры

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

Собранные данные разбиения на страницы можно затем просмотреть в столбцах, чтобы убедиться, что реализация соответствует требованиям. Вы можете фильтровать по следующему параметру —

• Содержит разбиение на страницы — URL-адрес имеет атрибут rel = «next» и / или rel = «prev», указывающий, что он является частью серии, разбитой на страницы.
• Первая страница — URL имеет только атрибут rel = «next», указывающий, что это первая страница в серии, разбитой на страницы. Прокручивать эти URL-адреса легко и полезно, чтобы убедиться, что они правильно размещены на родительской странице в серии.
• 2+ страницы с разбивкой на страницы — URL содержит rel = «prev», означающий, что это не первая страница в серии, а страница с разбивкой на страницы. Опять же, полезно прокручивать эти URL-адреса и следить за тем, чтобы под этим фильтром появлялись только страницы с разбивкой на страницы.
• URL-адрес разбивки на страницы не в теге привязки — URL-адрес, содержащийся в одном или обоих атрибутах rel = «next» и rel = «prev» страницы, не обнаруживается как гиперссылка в элементе привязки HTML на странице. сам. Страницы с разбивкой на страницы должны быть связаны с обычными ссылками, чтобы пользователи могли щелкнуть и перейти к следующей странице в серии.Они также позволяют Google сканировать от страницы к странице, а PageRank перемещаться между страницами в серии. Аналитик Google Webmaster Trends Джон Мюллер порекомендовал правильные HTML-ссылки для нумерации страниц, а также во время видеовстречи в Центре веб-мастеров Google.
• URL разбиения на страницы, отличный от 200 — URL-адреса, содержащиеся в атрибутах rel = «next» и rel = «prev», не отвечают кодом состояния 200 «OK». Это может включать URL-адреса, заблокированные файлом robots.txt, отсутствие ответов, 3XX (перенаправления), 4XX (ошибки клиента) или 5XX (ошибки сервера).URL-адреса пагинации должны быть доступными для сканирования и индексации, поэтому URL-адреса, отличные от 200, рассматриваются как ошибки и игнорируются поисковыми системами. URL-адреса, не относящиеся к 200 страницам, могут быть экспортированы массово с помощью экспорта «Отчеты> Разбивка на страницы> URL-адреса не-200».
• Несвязанный URL-адрес разбиения на страницы — URL-адрес, содержащийся в атрибутах rel = «next» и rel = «prev», не связан на веб-сайте. Атрибуты разбивки на страницы могут не передавать PageRank, как традиционный элемент привязки, поэтому это может быть признаком проблемы с внутренними ссылками или URL-адресами, содержащимися в атрибуте разбиения на страницы.Несвязанные URL разбиения на страницы можно экспортировать массово с помощью экспорта «Отчеты> Пагинация на страницы> Несвязанные URL разбиения на страницы».
• Не индексируется — URL с разбивкой на страницы не индексируется. Как правило, все они должны быть индексируемыми, если только не задан набор страниц «просмотреть все» или есть дополнительные параметры в URL-адресах пагинации, и они требуют канонизации для одного URL-адреса. Одна из наиболее распространенных ошибок — это канонизация страниц с разбивкой на страницы 2+ на первую страницу в серии. Google не рекомендует эту реализацию, поскольку страницы компонентов фактически не содержат повторяющегося содержания.Другой распространенной ошибкой является использование «noindex», что может означать, что Google полностью удаляет разбитые на страницы URL-адреса из индекса и прекращает переход по исходящим ссылкам с этих страниц, что может быть проблемой для продуктов на этих страницах. Этот фильтр поможет выявить эти распространенные проблемы настройки.
• Множественные URL-адреса для пагинации — На странице есть несколько атрибутов rel = «next» и rel = «prev» (когда не должно быть больше одного атрибута rel = «next» или rel = «prev»). Это может означать, что они игнорируются поисковыми системами.
• Цикл разбиения на страницы — Это покажет URL-адреса, которые имеют атрибуты rel = «next» и rel = «prev», которые возвращаются к ранее встреченному URL-адресу. Опять же, это может означать, что выраженные серии нумерации страниц просто игнорируются поисковыми системами.
• Ошибка последовательности — показывает URL-адреса с ошибкой в ​​последовательности элементов HTML-ссылок rel = «next» и rel = «prev». Эта проверка гарантирует, что URL-адреса, содержащиеся в элементах ссылки rel = «next» и rel = «prev» HTML, отвечают взаимностью и подтверждают свою взаимосвязь в серии.

6) Используйте «Отчеты> Разбиение на страницы> X» Экспорт для массового экспорта исходных URL-адресов и ошибок

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

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

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

Дополнительная поддержка

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

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

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

Rel = «предыдущая / следующая» | SEO вопросы и ответы

Оба являются директивами для Google .Все ссылки rel = являются директивами, включая hreflang, alternate / mobile, AMP, prev / next

Это не обязательно использовать канонический тег в дополнение к любому из других « rel = » ссылок на семейство

Канонический тег сообщает Google: « Я не являюсь настоящей версией этой страницы, я неканонический. Для канонической версии страницы, пожалуйста, следуйте этому каноническому тегу. Не индексируйте меня вообще, проиндексируйте канонический целевой URL

При разбивке на страницы назад / следующие ссылки говорят в Google: « Я являюсь основной версией этой страницы или одним из других URL-адресов, разбитых на страницы.Знаете ли вы, что если вы перейдете по этой ссылке — вы сможете найти и проиндексировать больше страниц содержания, если хотите «

Итак, проблема , которую вы создаете , используя оба, — это , создающий следующий диалог с Google:

1.) « Привет, Google. Перейдите по этой ссылке, чтобы проиндексировать URL-адреса с разбивкой на страницы, если они содержат полезное содержание на »

.

* Google переходит на разбитый на страницы URL

2.) « ЧТО ТЫ ЗДЕСЬ Гугл !? Я не каноничен, вернитесь туда, откуда пришли #buildawall »

* Google возвращается к URL без разбивки на страницы

3.) « Привет, Google. Перейдите по этой ссылке, чтобы проиндексировать URL-адреса с разбивкой на страницы, если они содержат полезное содержание на »

.

* Google переходит на разбитый на страницы URL

4.) « ЧТО ТЫ ЗДЕСЬ Гугл !? Я не каноничен, вернитесь туда, откуда пришли »

* Google возвращается к URL без разбивки на страницы

… и т. Д.

Как видите, сбивает с толку указывать Google сканировать и индексировать URL-адреса с помощью одного тега, а затем запрещать им делать это с помощью другого .Все ваши факторы индексации (канонические теги, другие ссылки rel, теги роботов, HTTP-заголовок X-Robots, карта сайта, файлы robots.txt) должны рассказывать ОДНУ, логическую историю (а не разные истории, которые напрямую противоречат друг другу)

Если вы укажете на веб-страницу с помощью любого метода индексации (ссылки rel, ссылки карты сайта), то не оборачивайтесь и не говорите: на самом деле нет, я передумал, я не хочу, чтобы эта страница проиндексировалась (с помощью ‘canonicalling’, что URL в другом месте). Если вы не хотите, чтобы страница индексировалась, то даже не указывайте на нее с помощью других методов индексации

A) Если вы хотите, чтобы эти URL-адреса были проиндексированы Google:

1) Имейте в виду, что при использовании rel prev / next Google будет знать, что это URL-адреса для пагинации, и не будет их сильно взвешивать.Однако, если Google решит, что какой-то контент с разбивкой на страницы очень полезен, он может принять решение о ранжировании таких URL-адресов

.

2) Если вы этого хотите, удалите канонические теги и оставьте rel = prev / next deployment as-is

B) Если вы не хотите, чтобы эти URL-адреса индексировались Google:

1) Это всего лишь директива, Google может игнорировать ее, но она будет намного эффективнее, так как вы не будете противоречить себе

2) Полностью удалите атрибут rel = prev / next из разбитых на страницы URL.Оставьте канонический тег на месте, а также добавьте мета-тег без индекса к URL-адресам с разбивкой на страницы

Имейте в виду, что только потому, что вы блокируете Google от индексации URL-адресов с разбивкой на страницы, не обязательно означает, что URL-адреса без разбивки на страницы будут ранжироваться в том же месте (с той же мощностью), что и URL-адреса с разбивкой на страницы (что будет быть, в основном потеряны из рейтингов). Вам может повезти в этой области, а может и не повезти (в зависимости от сходства содержания обоих URL-адресов, в зависимости от того, является ли предполагаемая причина Google для ранжирования этого URL-адреса сильно зависит от части контента, которая существует только в варианте URL-адреса с разбивкой на страницы)

Мой совет? Не поддавайтесь контролю и используйте вариант (B). Вместо этого используйте вариант (A) . Бесплатный трафик — это бесплатный трафик, не сомневайтесь в этом

SEO: уроки, извлеченные из идентификатора разбивки на страницы «rel = prev / next»

от Google

Специалисты по поисковой оптимизации были застигнуты врасплох на этой неделе, когда Google признал, что не использовал свой идентификатор нумерации страниц «в течение нескольких лет». Признание усиливает требование, чтобы специалисты по SEO были гибкими и сосредоточивались на том, что действительно важно.

Что такое rel = prev / next?

Изначально разработанная для упрощения индексации многостраничных приложений, rel = prev / next сообщила Google, что страницы отдельных категорий не должны отображаться отдельно в результатах поиска.

Pagination создает копии первой страницы, только с разными продуктами. Однако было бы бессмысленно направлять поисковика на страницу 2, 12 или 22 вашего ассортимента товаров. Потребители должны попасть на первую страницу, чтобы увидеть все продукты.

Разметка, скажем, страницы 3 списка категорий для «samplesite.com»:

На снимке экрана ниже показано rel = prev / next для страницы 3 категории «Конверсия» Практической электронной торговли.

Practical Ecommerce использует rel = prev / next на страницах категорий. Этот пример — страница 3 категории «Конверсия». Щелкните изображение, чтобы увеличить.

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

Это была идея.

В 2012 году Bing также заявил, что поддерживает rel = prev / next, что означает, что Yahoo тоже. Представитель Bing Фредерик Дубю указал в Твиттере на этой неделе, что он все еще используется для «обнаружения страниц и понимания структуры сайта», но не в качестве метода объединения страниц.

Отн. = Предыдущая / следующая Снято с производства

21 марта 2019 г. аналитик Google Webmaster Trends Джон Мюллер, источник надежной технической информации о SEO, подтвердил в Twitter, что «мы вообще не используем link-rel-next / prev.”

Одна интересная часть этого разоблачения заключается в том, что rel = prev / next было создано Google. В 2011 году Google представил его как способ уменьшить количество дублированного контента и помочь сосредоточить свое сканирование на ключевых областях.

В течение последних восьми лет использование rel = prev / next было обычной практикой. SEO-специалисты использовали ценные ресурсы для реализации и тестирования этого требования, ресурсы, которые, как мы теперь знаем, могли быть потрачены на другие проекты.

На самом деле, Мюллер описал rel = prev / next как полезную тактику на видеовстрече Google Webmaster Central 19 марта, за два дня до того, как он отменил сообщение в Twitter.Вскоре после этого Google удалил свой справочный документ, а сообщение в блоге Webmaster Central 2011 было помечено как недействительное.

Таким образом, Google посоветовал веб-мастерам сделать что-то для его алгоритмического использования, прекратил его использовать и ничего нам не сообщил. Мы потратили ресурсы, продолжая внедрять то, что они создали и от чего отказались.

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

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

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

Что делать

Поскольку Bing по-прежнему использует rel = prev / next, оставьте его на своем сайте.Но я бы не стал тратить много времени на его внедрение заново.

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

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

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

Это требует времени и непрерывного образования. Прочтите авторитетные источники, такие как Search Engine Land и Search Engine Journal. Обратите внимание на исследования огромного количества сайтов и рейтингов.

Критически оценивайте источник и надежность любого совета, который вы читаете.

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

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

.