SEO-блог Сергея Людкевича

Заслуживающая внимания статья на ресурсе  SearchEngineJournal о семантическом HTML-элементе <article>.

Основная мысль – непосредственно на ранжирование он не влияет, но может помочь поисковым машинам при парсинге страницы в понимании, где находится главный контент  (или "центральная часть"  в технических терминах Google), вхождения ключевиков в который получают наивысший весовой коэффициент. 

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

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

Гуглоид Джон Мюллер дает ему два совета: один плохой, а другой таки хороший.

Плохой совет – запретить карту сайта к индексации. Увы, удаление хорошо ранжирующейся страницы из индекса не сделает лучше ранжирование плохо ранжирующейся. Я часто слышу подобные советы в случаях, когда лучше ранжируется "не та" страница с сайта. Но делу такой совет поможет очень вряд ли. Гораздо полезнее было бы перенести контент "не той" страницы на новый URL, а со старого сделать редирект на посадочную. Тогда при склейке посадочной передались бы внешние факторы, в том числе и поведенческие. Которые могут быть весьма полезными, если на страницу были переходы из поисковой выдачи по рассматриваемому запросу.

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

Может ли микроразметка помочь попасть в быстрые ответы Google (они же featured snippets, они же выделенные описания), как это утверждают многие SEO эксперты?

 Обнаружил в Метрике у одного из проектов новую группу отчетов "Средние показатели по рынку". 

Выходит, эту группу отчетов запустили в бета-тестирование (судя по всему, с 1 августа), и этому проекту посчастливилось попасть в выборку. 

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

Две недели назад я рассказывал про поддержку имён сайтов в Google с помощью структурированных данных типа WebSite. 

Сегодня в блоге Google Search Central  анонсирована поддержка имен сайтов для поддоменов не только на мобильных устройствах, но и на декстопах. 

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

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

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

Очередной придуманный сеошным сервисом показатель объявлен гуглоидом Джоном Мюллером пустышкой. На этот раз досталось показателю text-to-HTML ratio (соотношение текста к HTML) из сервиса SEMRush. 

При ответе на вопрос об этом показателе на форуме Reddit Джон охарактеризовал его полезность для SEO как Zero. 

"Вы увидите больший эффект, если измените шрифт или цвет текста" – подытожил он.

Что ж, остается только согласиться.

Google внезапно удалил из англоязычной версии страницы документации об операторах Google Поиска информацию об операторе related:

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

Сам оператор related: пока еще работает. Но, похоже, eму осталось недолго, гуглоид Дэнни Салливан подтвердил, что оператор related: – всё.

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

Фабрис Канель, менеджер из Microsoft Bing, объясняет, что должен содержать правильный файл Sitemap - только адреса страниц с откликом 200 и желательно со значениями lastmod. 

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

Мораль такова, что не следует использовать файл Sitemap для того, чтобы сообщить поисковику о том, что страницы больше не существует (т.е. ее код состояния изменился с 200 на 3хх или 4хх), для этого есть другие инструменты.

 В октябре 2022 года Google анонсировал поддержку имён сайтов с помощью структурированных данных типа WebSite в мобильной выдаче. 

В марте 2023 года эта поддержка была замечена и в декстопной выдаче.

Однако что-то идет не так, и буржуйские сеошники жалуются на то, что данные для разметки имён сайта работают далеко не всегда. 

Гуглоид Дэнни Салливан пообещал все пофиксить в течение нескольких недель. Жаль только, что пока разметка имён сайта поддерживается только для на английского, французского, немецкого и японского языков. Ждем для русского. После того, как пофиксят баги )

Гуглоид Дэнни Салливан в своем Твиттере очень гордится тем, что за два десятилетия декларируемая парадигма Google "Делайте страницы для пользователей, а не для поисковых систем" ничуть не изменилась. 

Что полностью перекликается с незабвенным платонощукинским "Развивайте ваш сайт, и со временем..."

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

Еще один интересный вопрос с июльских Google SEO Office Hours.

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

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

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

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

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

Во время июльских Google SEO Office Hours гуглоид Гэри Ийеш развеял старую сеошную страшилку о том, что большое количество известных Googlebot'у страниц на сайте с кодами состояния 404 и 301 может негативно влиять на его ранжирование.

"404 коды состояния совершенно безвредны, как и 301", сказал Гэри. 

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

Поддомен всегда будет считаться частью сайта на домене 2-го уровня, утверждает  гуглоид Джон Мюллер в своем твиттере.

Это можно воспринимать, как рекомендацию делать подсайты для разных стран не на поддоменах, а на национальных доменах 2-го уровня (CCTLD - Country code top-level domain).

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

Гуглоид Мартин Шплитт в твиттере Google Search Central подтвердил таки очевидную для грамотных сеошников вещь - оператор site: не выдает полный список проиндексированных страниц. 

Спрашивается - и какой толк в таком операторе? )

Минутка ликбеза. Мало кто знает, что именно означает опция "Точное соответствие" в расширенных результатах поиска Google, часто путая ее с поиском по точной фразе. 

В недрах блога Google есть запись 12-летней давности, которая раскрывает значение этой опции. Итак, это результаты поиска без различного "улучшайзинга", такого как: 

1) автоматическое исправление опечаток, 

2) персонализации, 

3) добавления синонимов ключевых слов запроса, 

4) добавления результатов по схожим запросам, 

5) добавления других словоформ ключевых слов запроса, 

6) игнорирования некоторых слов запроса.  

Иногда бывает полезно сравнить.

Гуглоид Джон Мюллер - чемпион по развенчанию сеошных мифов. Очередной миф о том, что 302-й редирект для ранжирования чем-то хуже 301-го - был развенчан на днях на форуме Reddit по SEO. Если коротко, то "302 redirects are fine".

Несколькими днями позже, уже в Твиттере, Джон добавил к ним 307-й и 308-й. "Вы не потеряете PageRank", заверил он. Всем последователям секты свидетелей утечки Пейджранка на заметку.

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

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

Гуглоид Джон Мюллер на днях в очередной раз повторил, что количество слэшей в URL страницы (т.н. "глубина структуры") не имеет значения. 

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

Хотя последней на моей памяти поисковой машиной, которая это учитывала, была AltaVista еще в начале нулевых.

Что же касается Яндекса, то в англоязычном докладе "Quality biased Ranking for Queries with Commercial Intent" на конференции WWW 2013 яндексоиды упоминали фактор коммерческого ранжирования "Average depth of the URL path". Однако, принято считать, что здесь подразумевается ссылочная структура, а не число слэшей в URL.

Прочел вчера поучительную историю о том, как один товарищ вынес блог интернет магазина из подпапки /blog/ на поддомен blog.sitename.ru и получил грустные результаты в Яндексе - траффик катастрофически упал. 

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

Встретилась дискуссия по поводу того, является ли символ знака подчеркивания в URL разделителем слов для поисковиков.

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

Первым под руку попался сайт a-ivanov.ru, движок которого формирует URL, содержащие строку "show_post". С помощью оператора inurl проверяем находятся ли эти страницы по ключевику show.

В Яндексе всё прекрасно находится:

А вот в Google - нет:

Находится только по полному ключевику show_post:

Таким образом, видим, что Яндекс считает знак подчеркивания разделителем в URL, а Google - нет. Впрочем, он и не рекомендует его использовать в URL.

Гуглоид Гэри Ийеш рассказал, как Google обрабатывает экзотический ответ сервера с кодом 103 Early Hints.

А никак. Googlebot проигнорирует такой ответ и будет ждать более подходящего (например, 200 ОК), который должен последовать за ним.

По словам Гэри, Googlebot не поддерживает экспериментальные HTTP фичи, и как только код 103 лишится статуса "экспериментальный", то он станет поддерживать его.

Что же касается Яндекса, то в его справочнике по кодам статуса HTTP код 103 не упоминается.

Гуглоид Джон Мюллер развенчивает очередной сеошный миф. 

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

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

 13 апреля 2023 года Google анонсировал изменение в правилах представления иконок видеороликов в сниппетах. Теперь иконки видео показываются только в том случае, если видео является основным контентом на странице.

Гэри Ийеш на июньских SEO office hours пояснил, что это значит: видео не обязательно должно быть первым элементом на странице, но оно должно быть "перед вашим лицом" ("in your face").

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

 Хинт от гуглоида Гэри Ийеша на июньских SEO office hours. 

Если в поисковой выдаче у вашего сайта показывается два результата (Гэри называет это "host group"), то неплохо будет консолидировать эти две страницы, назначив одну из них канонической для другой, если есть такая возможность.

На мой взгляд, хороший совет по крайней мере по двум причинам:

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

2) Не будет происходить каннибализации кликов по поиске.

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

 На форуме по техническому SEO Reddit один юзер пожаловался, что сервис Semrush пометил ссылку с Github как токсичную.

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

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

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

Гуглоид Джон Мюллер в дискуссии на форуме Reddit  не рекомендует выбирать для продвижения домены в дешевых доменных зонах, перегруженных спамом:

"From an SEO POV, I would just not pick a TLD that's super-cheap and over-run with spam."

Выглядит так, что "плохое окружение" ("bad neighborhood") касается и доменных зон.

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

Причина объяснена на другой странице документации (русскоязычной версии у нее нет): 

"The canonical link element is not recommended for those who wish to avoid duplication by syndication partners, because the pages are often very different. The most effective solution is for partners to block indexing of your content."

Получается, кроссдоменные директивы canonical в Google - всё? 

Обнаружился баг в инструменте "Проверка ответа сервера" сервиса Яндекс Вебмастер. Если для проверки выбирать по умолчанию Основной робот Яндекса Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots), то проверять приходит не он, а Робот Яндекс Вебмастера Mozilla/5.0 (compatible; YandexWebmaster/2.0; +http://yandex.com/bots).

Будьте внимательны, если вы дифференцируете отдачу содержимого страниц своего сайта по User agent.

Кстати, в Google следует принимать во внимание, что в случае проверки страницы на сайте инструментом "Проверка URL" в Google Search Console проверять страницу придет не Googlebot Smartphone или Desktop, а робот Google Inspection Tool.

Варианты полных строк его User agent для мобильных устройств и десктопов можно найти на странице англоязычной версии документации по поисковым роботам Google Search Central (в русскоязычной версии этой информации пока нет):

Mobile

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Google-InspectionTool/1.0)

Desktop

Mozilla/5.0 (compatible; Google-InspectionTool/1.0)

С каждым годом функционал языка запросов Яндекса становится все беднее.

Старый добрый оператор url: тоже стал привирать.

В связке с символом * (Цитата из Яндекс Справки: "Чтобы найти все документы, адреса которых начинаются с заданного значения, поставьте в конце URL символ *") он теперь показывает явно не все, что есть в индексе. Грусть-печаль.

Гуглоид Джон Мюллер развенчивает очередной сеошный миф о том, что некорректно выставленная дата в заголовке Last-Modified отклика сервера (в частности, всегда текущая) может негативно влиять на ранжирование.

Честно говоря, не понимаю, откуда подобные мифы берутся, но Джон вот где-то сумел найти )

Собственно, имеет значение не столько само содержимое заголовка Last-Modified, сколько, какой код ответа сервер отдает на запрос If-Modified-Since. По идее здесь может быть только одно влияние на ранжирование - если контент страницы изменился с даты указанной в запросе, а сервер будет отдавать 304, а не 200, то эти изменения просто не учтутся.

Между тем, интересная ведь штука получается - можно сделать контент для ботов, дать ему быстренько проиндексироваться, а затем разместить контент для людей, и отдавать 304 на все запросы от ботов If-Modified-Since. В итоге в индексе висит версия для ботов, люди получают версию для людей.

С одной стороны, вроде очень похоже на клоакинг, а с другой - всего лишь некорректная обработка запроса If-Modified-Since.

Тем, кто опасается, что некорректная микроразметка может негативно повлиять на ранжирование, гуглоид Gary Illyes во время майских Google SEO office-hours дал однозначный ответ: нет.

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

Так что алерты в Google Search Console об ошибках в микроразметке на странице не являются причиной ее плохого ранжирования.

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

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

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

К тому же персонализацию можно легко отключить.

Сделать это можно двумя способами:

1) В настройках - как это сделать, описано в Google Справке

2) С помощью get-параметра &pws=0, который нужно добавить к URL страницы выдачи.

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

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

Для Яндекса это &mode=text , для Google это &strip=1.

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

Не знаю, откуда растут ноги у подобных опасений, но явление довольно таки массовое. Возможно, причина в том, что и в Яндекс Вебмастере, и в Google Search Console страницы с откликом 404 имеют "токсичный" статус исключенных из индекса, и это воспринимается, как негативный сигнал.

Между тем, количество известных поисковику страниц, исключенных из индекса из-за отклика 404, негативного влияния на ранжирование других страниц сайта не оказывает. 

В качестве пруфа можно откопать в недрах блога Центра Search Console древнюю статью, чтоб убедиться, что "ошибки 404 – это нормальное явление".

Обнаружил, что Яндекс изменил своё отношение к запрещенным в файле robots.txt страницам.

На странице Яндекс Справки "Использование файла robots.txt" появилось примечание:

"Ограниченные в robots.txt страницы могут участвовать в поиске Яндекса. Чтобы удалить страницы из поиска, укажите директиву noindex в HTML-коде страницы или настройте HTTP-заголовок."

А на странице "Как удалить страницы из поиска" в описании способа удаления "Запрет в файле robots.txt" вместо фразы 

"Робот прекращает обращаться к странице в течение суток."

появилась фраза

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

Таким образом Яндекс в данном вопросе перенял позицию Google. Надеюсь, что так же, как и Google, сканировать запрещенные в robots.txt страницы Яндекс все-таки не будет.

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

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

Но вот подобные идеи насчет внутренних - считаю, мягко говоря, некомпететными и не имеющими под собой никаких оснований. Ну, и старина Джон Мюллер подтверждает: 

“We don’t really differentiate there.

So if like, things are linked in your footer of the page and they’re linked from across the whole website then from our point of view you have those links from across your whole website.

It’s not the case that we would say, Oh, like links in a footer have less weight or are not as useful we will ignore them or anything like that.

So from that point of view, when it comes to links we essentially just see them as links on a page.”

Рекомендации Google и Яндекса в этом вопросе существенно разнятся.

И если Google позволяет просто напрямую сопоставить старые и новые URL и настроить 301-й редирект (другие виды редиректов не рекомендуются), то Яндекс требует двойной редирект:

"Установите на сервере редирект с HTTP-кодами 301 или 302. Перенаправление должно вести со страниц старого сайта на аналогичные страницы нового — который должен участвовать в поиске.

Если у сайта изменились доменное имя и названия каталогов, то нужно установить двойной редирект. Например, адрес страницы http://сайт.рф/стр/ изменился на http://example.ru/page/. Тогда перенаправление должно работать следующим образом:

http://сайт.рф/стр/ -> http://example.ru/стр/ -> http://example.ru/page/ "

Получается, что для того, чтобы корректно переехать в обоих поисковиках, надо использовать схему Яндекса с двойным 301-м редиректом. 

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

 Важная вещь, о которой часто забывают.

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

1) Количеством входящих ссылок.

2) Длиной самой короткой цепочкой ссылок от главной страницы (чем короче, тем лучше).

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

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

Совершенствуйте рубрикаторы, делайте более плотную перекрестную перелинковку. 

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

Страница, на которую ссылается только одна 100500-ая страница пагинации - не нужна никому, ни поисковикам, ни пользователям. Большое количество таких страниц на сайте говорит о том, что и сам сайт никому не нужен )

Даже если адепты модного "силосования" пытаются вас убедить в обратном.

Всякий раз, когда натыкаюсь на подобное, хочется сказать "И эти люди запрещают нам ковыряться в носу?" 

А как же незабвенное "Мы стараемся не индексировать или не ранжировать высоко: ... Страницы с результатами поиска по сайту или результатами отбора товаров, услуг, других объектов по условиям, если они мало информативны и мало полезны для пользователей."? 

И ведь таких результатов собственного поиска в собственном индексе - миллионы.

Мысли про пагинацию. Индексировать или не индексировать?

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

Сделать это можно двумя способами:

1) Директива canonical со всех страниц пагинации на первую страницу.

2) Мета robots со значением noindex, follow для страниц пагинации кроме первой.

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

Закрывать пагинацию от индексации в robots.txt с помощью директив Disallow или Clean-param (в Яндексе, если пагинация задается get-параметром в URL) категорически не рекомендую.

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

Интересно изменение заголовка страницы с "Make your links crawlable" на "SEO Link Best Practices for Google".

Среди прочего показался любопытным следующий момент:

As a fallback, Google can use the title attribute as anchor text if the <a> element is for some reason empty.

<a href="https://example.com/ghost-pepper-recipe" title="how to pickle ghost peppers"></a>

Честно говоря, не совсем понимаю, по каким причинам содержимое тега <a> можно оставлять пустым. Ведь в этом случае ссылка будет не видна пользователю. И еще более странным видится то, что в этом случае вполне легально содержимое атрибута title будет считаться анкором такой невидимой ссылки.

Еще один любопытный момент - плохими  обозначены так называемые "безанкорные" ссылки, которыми сеошники так любят "разбавлять" анкор-файлы:

Bad (too generic):

<a href="https://example.com">Click here</a> to learn more.

<a href="https://example.com">Read more</a>.

Learn more about our cheese on our <a href="https://example.com">website</a>.

We have an <a href="https://example.com">article</a> that provides more background on how the cheese is made.

А хорошими ссылками обозначены как-раз таки акорные, главное, чтоб были не слишком длинные.

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

Меж тем давным-давно уже ходит байка про бывшего сотрудника Гугла, заявившего, что аж с 2006-го года классический алгоритм PageRank заменен на некий более экономный в расчетах. Что в общем-то вполне логично. Но так как новой формулы никто не знает, то многие предпочитают верить в старую )

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

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

Здесь все зависит от того, что считать геонезависимостью. Независимость выдачи по запросу от региона пользователя или вообще от какого-либо региона. 

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

Да и сам Яндекс в своей статье "Поиск с учётом  региона" особо оговаривает случай, когда город указан в запросе, в подразделе о результатах регионального поиска, т.е. геозависимых.