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

Буржуйский сеошник Хуан Гонзалез Вилья обнаружил поданный 20 марта и одобренный 26 сентября 2023 года патент Google, который, как он полагает, лежит в основе SGE.

Обнаружению предшествовал целый квест. Хуан, читая документы, обнародованные во время антимонопольного процесса США против Google, увидел упоминание инженера по имени Стивен Бейкер. Его профиль в Linkedin указывал, что он работал в Google над разработкой SGE. А до этого работал над проектом Google WebAnswers вместе со Шринивасаном Венкатачари. И вот уже по этому Шринивасану Хуан и нашел патент, в котором тот указан в качестве одного из авторов.

Шерлок Холмс отдыхает.

Google объявил о прекращении с 8 января 2024 года работы инструмента ограничения скорости сканирования в Search Console.  Заявленная причина — инструмент устарел и очень редко использовался. Теперь самый быстрый способ снизить скорость сканирования — дать указание роботу Googlebot посредством ответов сервера.

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

На сеошном подфоруме Reddit задали вопрос - дает ли какое-либо преимущество при поиске по изображениям наличие данных EXIF у них. Гуглоид Джон Мюллер коротко и ёмко ответил: "Нет". Однако один из сеошников подверг его ответ сомнению и заявил, что по его опыту данные EXIF помогают лучше ранжироваться картинкам. 

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

Гуглоид Дэнни Салливан опубликовал презентацию своего выступления на конференции BrightonSEO online.

Основная мысль — не думайте о Google, думайте о пользователе.

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

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

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

Когнитивный диссонанс.

В Google Search Console появился новый отчет проверки файла robots.txt. Он показывает ошибки (например, отсутствие файла) и предупреждения (например, наличие в файле не учитываемых краулером Google строк). 

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

Пятничный вечер — самое время вспомнить, что накануне стукнуло 20 лет знаменитому апдейту Флорида Google. 

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

А всего лишь гуглоиды решили внедрить новый алгоритм Hilltop, приобретенный у одного индуса (работавшего, кстати, к тому времени в Google). 

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

А имя к алгоритму прилипло с легкой руки владельца WebmasterWorld Бретта Табке, который в эти дни проводил какую-то конференцию во Флориде.

Google обновил руководство для асессоров (Search Quality Raters Guidelines). Ничего радикально нового, просто отредактированы некоторые рекомендации (где-то упрощены, а где-то расширены) и примеры (добавлены новые и удалены устаревшие и избыточные). 

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

Google включил в документацию по заголовкам сниппетов рекомендацию не включать в тег <title> цену на авиабилеты. Основание - цены на авиабилеты очень динамичны, и пользователь, увидев в сниппете одну цену, может быть неприятно удивлен, перейдя на страницу и увидев там совсем другую.

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

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

Гуглоид Дэнни Салливан:

"У страницы есть noindex, но мы этого не видим, потому что robots.txt блокирует нам ее чтение".

Гуглоид Мартин Шплитт обозначил приемлемое значение среднего времени ответа сервера:

"Я бы сказал, что «чуть меньше полсекунды» в целом нормально".

Но если есть возможность ускориться, то посоветовал ускориться.

Вообще Google рекомендует придерживаться значения менее 200 миллисекунд.

Но мой взгляд, этот показатель намного важнее, чем всё семейство Core Web Vitals, и на него действительно стоит обращать пристальное внимание.

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

"Если вы «гонитесь за алгоритмами», вы отстаёте" - написано на слайде Дэнни Салливана.

Ага, попробуй не погнаться, будешь тусить на задворках SERP'а.

Вот интересно, а стал бы хоть кто-нибудь использовать микроразметку, если бы поисковики не делали из нее красивые сниппеты?

Какие ссылки следует отклонять с помощью иструмента Google Disavow Tools? Гуглоид Джон Мюллер полностью согласен со следующим утверждением:

"«Токсичные» обратные ссылки являются выдумкой стороннего поставщика инструментов SEO и не имеют прямого отношения к поисковым системам.

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

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

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

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

Моё мнение – париться по этому поводу не стоит, делайте, как вам удобнее. Хотя принцип "работает – не трогай", зараза, очень живучий. 😊

Майкрософт подал заявку на патент под названием "Классификация надежности веб-контента". Примечательно, что в методе отказались от оценки трафика в  пользу ссылок. Идея следующая. Сначала вручную размечается начальная выборка сайтов на надежные и ненадежные. Затем итеративно оцениваются все остальные сайты по принципу "Чем больше входящих ссылок из источников с высокой надежностью, тем выше оценка надежности" и аналогично для ссылок из источников с низкой надежностью. Однако, есть нюанс – предполагается, что источники с высокой надежностью ссылаются, в основном, также на сайты с высокой надежностью, а вот источники с низкой надежностью могут ссылаться, как на надежные, так и на ненадежные сайты. 

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

На SearchEngineLand вышел обзор семи внутренних документов Google, засвеченных в ходе антимонопольного разбирательства в американском суде. Документы, представляющие собой частично отредактированные слайды презентаций, датируются 2014-2020 годами. Ничего прорывного, но можно увидеть, например, официальное подтверждение того, что Google еще в 2016-м году учитывал в ранжировании  поведенческие факторы, такие как клики, скроллинг, движения мышью. 

Интересен посыл гуглоидам держать это в тайне:

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

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

Полезно для общего развития.

Гуглоиду Дэннии Салливану задали вопрос: "Используется ли непроиндексированный контент для оценки сайтов"? Насколько я понимаю, речь идет о просканированном, но запрещенном к индексации контенте (например, метатегом robots со значением noindex).

Ответ Дэнни:

 "Если мы не можем индексировать контент, нет, мы не можем его рассматривать".

А вот Яндекс вполне себе позволяет использовать запрещенный к индексации контент, например, в антиспаме.

В Блоге Google Search Central появился материал под заголовком "Вопросы и ответы об обновлениях Google Поиска" (пока что только на английском). 

В нем сообщается о старте 2023 November Core Update, а также о скором запуске очередного Reviews Update.

Кроме этого содержится краткий экскурс по докам Google, касающихся поиска.

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

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

На популярном буржуйском сайте о современных технологиях The Verge вышла довольно объемная и довольно скандальная статья о сеошниках под заголовком "Люди, которые разрушили Интернет".

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

Благородное буржуйское SEO-сообщество мгновенно закипело. Обзор этого кипежа публикует Барри Шварц у себя на SERoundTable.

Неоднократно упоминаемый в статье гуглоид Дэнни Салливан тоже не смог остаться в стороне и разродился обширным опусом в своем личном блоге, в котором звучит тезис, что SEO – это не спам, а действия, соответствующие рекомендациям поисковиков, которые могут помочь им лучше находить и понимать контент. И резонно недоумевает – если редакции The Verge так противны сеошники, то почему она содержит целый SEO-отдел?

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

Гуглоид Дэнни Салливан разродился целой программной речью по поводу текстового спама (keyword stuffing). Дело не в том, сколько раз слово повторяется на странице. А в том, насколько естественны эти повторы.

"Просто люди обычно так не пишут и не объясняют вещи. Скорее всего, это повторение, потому что кто-то думает: "Мне нужно часто повторять это полностью, чтобы Google действительно понял это". Нет, нам это нужно не так часто. У нас есть довольно хорошие способы анализировать язык и понимать значения и концепции. Лучший способ соответствовать этому - просто писать так, как вы писали бы для людей."

Так что мораль следующая: если будете писать, как сеошники, то повышаете риск попасть под санкции.

С сегодняшнего дня технологией Яндекс XML можно пользоваться только через новый сервис Yandex Search API.

Неожиданный бонус - в ночное время будет доступен free tier (нетарифицированное использование) в 1000 запросов в месяц.

Google объявил о завершении перехода на Mobile First Indexing.

Десктопный краулер признан устаревшим, и объем сканирования им будет максимально сокращаться. 

По факту имеем, что десктопная версия сайта для Google уже не имеет практически никакого значения.

Команда Google Search выпустила ролик из серии SafeSearch о страницах со "взрослым" контентом. Кроме того, что их следует маркировать с помощью мета-тега rating, размещать на отдельном поддомене или в отдельной подпапке, разрешить краулеру получать ваш видеоконтент и обеспечить ему доступ без возрастной верификации, есть еще один интересный момент.

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

Гуглоид Джон Мюллер объясняет чрезмерно пугливым сеошникам суть отчета о 404-х ошибках в Google Search Console. Это не свидетельство того, что на сайте что-то идет не так. Это не более чем напоминание для тех случаев, когда страница по логике владельца должна существовать, но краулер по какой-то причине получает по этому адресу 404, и это повод для того, чтоб эту проблему пофиксить. Если же страницы по данному адресу существовать не должно, то и париться не надо.

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

Максимум, что она может дать вам - это красивый сниппет. Это еще раз подтвердил гуглоид Дэнни Салливан в дискуссии в Твиттере. Причем, дважды.

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

Интересный момент из выступления Михаила Сливинского на круглом столе конференции Optimization'23. Алгоритмы фильтрации ботов в поиске и Метрике разные. Поэтому ориентироваться на Метрику, чтоб понять, сколько ботов отфильтровано в учёте поведенческих, нельзя. В поиске все сильно жёстче.

Буржуйская сеошница Мэри Хейнс проанализировала кучу сайтов, которых опустил последний Google Helpful Update и пришла к интересному выводу:

"Для многих сайтов, затронутых HCU:

Запрос: Как мне сделать x

Содержание:

Что такое х?

Как решить, подходит ли вам x

История х

...

Как сделать х"

И далее в комментах:

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

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

Google в лице Райана Леверинга на Google Search Central Live в Цюрихе объявил о поддержке объединения микроразметок  json-ld и chema.org. 

Райан поясняет, в чем именно новшество: "Теперь различные синтаксисы могут соединяться вместе. Таким образом, вы можете реализовать разметку Breadcrumb в  json-ld, но ссылаться на узел WebPage, который находится в микроданных".

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

Также Google решил немного подсластить пилюлю от прекращения поддержки в расширенных сниппетах структурированных данных типа FAQ и Event и уполномочил Райана Леверинга объявить о планах начать поддержку в расширенных сниппетах разметок DiscussionForumPosting и ProfilePage.

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

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

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

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

Гуглоиды подтвердили, что расширенные сниппеты для стуктурированных данных типа Event удалены из поисковой выдачи. Это сделал Райан Леверинг вчера на Google Search Central live SEO event (ирония судьбы 😊) в Цюрихе.

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

Любопытная статистика от сервиса Statcounter: в сентябре Яндекс отожрал у Google больше процента доли на европейском рынке и вышел на второе место, опередив Bing. 

Доля Яндекса увеличилась с 2,28% до 3,46%, а доля Google уменьшилась с 92,26% до 90,87%. Доли Bing, Yahoo! и DuckDuckGo при этом изменились незначительно.

На вопрос на форуме Reddit, может ли причиной падения органического трафика из поиска быть показатель Cumulative Layout Shift (CLS), Джон Мюллер коротко и ёмко ответил: "Нет".

Вот и всё, что вам нужно знать о влиянии показателей Core Web Vitals на ранжирование в Google.

Google объявил о поддержке разметки для объявлений о транспортных средствах, которая позволит сформировать красивый расширенный сниппет. 

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

В настоящее время вся эта красота доступна только в США. Будем надеяться, что в дальнейшем раскатают на другие страны.

Буржуйская сеошница Мэри Хейнс предполагает, что в последнем обновлении Google helpful content были задействованы не только штрафы за низкое качество контента, но и бонусы за его полезность. По ее мнению, слишком много было зафиксировано "взлетов", чтобы объяснить это банальным снятием ранее наложенных штрафов.

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

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

Дэйви Альба из Bloomberg утверждает, что даже сотрудники Google ставят под сомнение полезность чат-бота Bard AI.

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

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

А руководитель отдела пользовательского опыта Bard Кэти Перл заявила: "Самая большая проблема, о которой я все еще думаю: чем действительно полезны программы LLM?" 

Как говорил дедушка Крылов, 

"Когда в товарищах согласья нет, На лад их дело не пойдет, И выйдет из него не дело, только мука." 😊

Любопытное исследование Глена Оллсопа из Detailed.com. Он проанализировал пару сотен тысяч контентных запросов на английском языке (типа "Where do...", "How should...", "Who is..." и т.п.) и обнаружил, что в 86,1% случаев первое место в органике занимают сайты крупных медиа-брендов (он их называет "цифровые голиафы"). 

Тройка лидеров - Youtube, Wikipedia и Amazon. 

Похоже, у независимых контентных сайтов немного шансов на получение англоязычного контентного поискового трафика. Хотя, впрочем, им и оставшихся 13,9% может быть вполне достаточно.

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

Буржуйский сеошник Гленн Гейб забдил, что запрещенный таким образом контент, используется в ответах SGE. Да еще и через Барри Шварца получил обескураживающий ответ от гулоидов. Оказывается, запрещение для Google-Extended через файл robots.txt вовсе не мешает SGE отображать ваш контент в ответе: "Вместо этого вам необходимо заблокировать SGE, полностью заблокировав Googlebot"

А вице-президентша-то не в курсе. 😁

Статья на SearchEngineJournal для чтения на досуге о значимости в алгоритме ранжирования Google такого фактора как наличие ключевых слов в URL страницы. Основной вывод – оптимизация URL адресов с целевыми ключевыми словами не дает никаких преимуществ для SEO. Любой потенциальный импульс настолько мал, что его невозможно обнаружить. 

С чем я полностью согласен. Любителям ЧПУ пища для размышлений.

Их нравы. 

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

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

Белые буржуйские сеошники страшно негодуют и жалуются гуглоидам.

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

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

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

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

Поучительная история для тех, кто считает, что сотрудники поисковых систем сами делают все правильно. 

После того, как обнаружилось, что на домене bard.google.com не запрещена к индексации папка /share/ с пользовательским контентом, сотрудники Google решили это дело исправить. Да так, что нарушили свои же собственные рекомендации, используя одновременно и Disallow в robots.txt, и мета-тег robots со значением noindex, что не ускользнуло от пытливого взгляда сеошников. Пришлось Дэнни Салливану делать хорошую мину при плохой игре:

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

Но тем не менее директиву Disallow: /share/ из файла https://bard.google.com/robots.txt убрали 😁

Оказывается, не все в курсе, что в содержимом директив файла robots.txt учитывается регистр букв.

Документация Яндекса: 

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

Документация Google:

"Правила в файле robots.txt указываются с учетом регистра."

Будьте внимательны.

Что произойдет, если вы укажете в HTTP-заголовке ответа сервера для страницы X-Robots-Tag: noindex, но при этом разместите в ее коде метатег 

<meta name="robots" content="INDEX,FOLLOW"/> ? Какая директива сильнее? 

Ответ: так как значения INDEX и FOLLOW - это значения по умолчанию, то краулер будет следовать директиве X-Robots-Tag: noindex

Гуглоид Гэри Ийеш решил заострить внимание публики на следующем моменте:

"Напомню, что если вы добавите для определенного пути одновременно и правило Disallow в файл robots.txt, и правило noindex для всех файлов этого пути, то сработает только Disallow, т.к. сканировать эти файлы запрещено."

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

Вице-президент Google Дэниель Ромейн объявила о появлении нового краулера Google-Extended, который сканирует контент для использования в системах искусственного интеллекта. 

Так что, если не хотите, чтоб на вашем контенте обучались Bard и Vertex, запрещайте в файле robots.txt сканирование сайта для User-Agent: Google-Extended

По информации SearchEngineLand экс-гуглоид Эрик Леман, проработавший 17 лет инженером качества поиска, во время дачи показаний на антимонопольном процессе США против Google заявил:

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

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

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

Интересно, почему?

Буржуйский сеошник Патрик Стокс цитирует (немного перефразируя) слова Гэри Ийеша на конференции Pubcon: 

"Я не думаю, что большинство сайтов увидят большую пользу от работы над Core Web Vitals"

На заметку любителям во что бы то ни стало достичь 100% по всем показателям CWV.

Ну, и на закуску, самое, пожалуй, провокационное заявление Гэри Ийеша на конференции Pubcon Pro September 2023:

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

"Абсолютно возможно ранжироваться без ссылок" — сказал Ийеш, приводя пример страницы с нулевыми внутренними или внешними ссылками, о которой он знал, которая занимала первую позицию по запросу Porsche cars, и Google нашел эту страницу только через карту сайта. 

Контент продолжает оставаться сигналом ранжирования номер один.

"Без контента ранжирование в буквальном смысле невозможно. Если на вашей странице нет слов, она не будет ранжироваться. Каждый сайт будет иметь что-то свое в качестве 2-х или 3-х главных факторов ранжирования", — сказал Ийеш.

Когнитивный диссонанс в квадрате.

Еще один интересный ответ гуглоида Гэри Ийеша на вопросы на конференции Pubcon Pro September 2023:

"С точки зрения Google, было бы довольно глупо полагаться на теги H1-H6 для понимания порядка и иерархии контента.

Используйте теги H там, где это необходимо и где это имеет смысл".

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

Пожалуй, самый интересный ответ Гэри Ийеша на вопросы на конференции Pubcon Pro September 2023: 

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

Таким образом, если вы купили домен с истекшим сроком действия и попытались восстановить его (например, получив весь контент из Wayback Machine), вы будете по сути создавать сайт с нуля".

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

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

 На прошлой неделе гуглоид Гэри Ийеш выступил на конференции Pubcon Pro September 2023.

На SerchEngineLand опубликованы ответы на вопросы, которые Гэри задали во время выступления.

Начинаю разбирать самые, на мой взгляд, интересные:

Вопрос номер один. Использует ли Google данные о кликах пользователей при ранжировании?

"Технически да", — сказал Ийеш — "Это связано с тем, что исторические данные поиска являются частью RankBrain".

Интересная оговорка "технически". То есть данные о кликах используются, но признаваться в этом как-то некомильфо. Поэтому применяется добавка "технически", что создает впечатление, что используются как-то несерьезно, типа понарошку. 😁

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

Неужели появился способ закрывать от индексации определенные фрагменты контента на странице?

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

Полагаю, многие сеошники будут несколько разочарованы, узнав, что гуглоид Джон Мюллер, считает, что страницы с метой robots со значением noindex, follow не передают Pagerank, о чем он сегодня заявил в дискуссии на X. 

Раньше в этом вопросе все ссылались на Мэтта Каттса, который еще в нулевых заявлял, что noindex страницы могут накапливать и передавать PageRank.

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

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

В очередном, 64-м, выпуске подкаста Google Search Off the Record Джон Мюллер и Гэри Ийеш поговорили о качестве веб страниц.

Самое интересное – если краулер знает URL, но не спешит его сканировать, значит, он спрогнозировал, что, скорее всего, контент страницы – невысокого качества. 

Если просканировал, но не проиндексировал - значит он решил, что контент страницы невысокого качества.

А если на сайте много страниц невысокого качества, то, значит, и сам сайт невысокого качества. Дословно (Гэри Ийеш): 

"Если вы удалите низкокачественный контент с вашего сайта, то это радикально улучшит оставшуюся часть сайта".

Мотать на ус тем, кто считает, что кучи мусора, доступные для сканирования и индексации – это ничего страшного.

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

Одной возможностью сделать красивый сниппет стало меньше.

Вдобавок к прекращению поддержки расширенных сниппетов для структурированных данных How-To Google радикально ограничил поддержку расширенных сниппетов для структурированных данных FAQ. Согласно данным, приведенным SERoundTable, доля сайтов, для которых показываются подобные расширенные сниппеты упала почти до нуля, оставшись доступной только для известных, авторитетных ресурсов правительства и здравоохранения. 

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

Очередной сеошный миф развеян абсолютным чемпионом по развенчанию мифов гуглоидом Джоном Мюллером. На этот раз досталось оптимальной длине метатега description. Из одного сеошного мануала в другой кочуют цифры его оптимальной длины в 150-160 символов. 

"Мне жаль Вам это говорить, но все эти цифры выдуманы. Тот, кто рассказал вам их, вводит вас в заблуждение..." 

– ответил Джон на вопрос в соцсети Х.

От себя добавлю, что если учесть, что метатег description вообще не участвует в ранжировании (а только в формировании сниппета), то вообще весьма странно говорить о какой-то его оптимальной длине.

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

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

В документации Google по поисковым роботам и инструментам по сборам данных имела место опечатка в названии User-Agent робота сканера Google Inspection Tool – отсутствие знака ; (точка с запятой) в конце строки перед закрывающей скобкой. В Вебархиве последняя версия англоязычной страницы с опечаткой датирована 10 сентября этого года.

Сейчас в англоязычной версии документации опечатка исправлена. Корректная версия:

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;)

В русскоязычной версии опечатку пока не исправили.

Если кто использует эти юзер-агенты в файле robots.txt – приводите в соответствие.

Обозреватель SearchEngineLand Джеф Фергюссон в пух и прах раскритиковал пузомерку Domain Authority (DA) от Moz. 

Он ее сравнивает со статистическим показателем из оффлайна – "error metric" в бейсболе, который был введен для ранней версии игры, правила которой сильно отличались от современного варианта.

Такая же бесполезная и не имеющая отношения к текущей реальности.

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

Яндекс раскрыл формулу ранжирования! 

Правда, только в поисковой машине Яндекс Маркета:

"То, насколько высоко будет предложение в результатах поиска, складывается из нескольких факторов:

на 27,5% влияет релевантность — описание товара должно соответствовать запросу пользователя;

на 25,5% — персональные предпочтения пользователя, основанные на предыдущих покупках и поисковых запросах;

на 18% — цена товара: чем она ближе к минимальной на рынке, тем лучше;

на 17% — популярность товара среди покупателей: как часто этот товар заказывают, добавляют в корзину и в избранное, открывают и просматривают карточку товара;

на 12% — рейтинг товара, срок доставки и рейтинг магазина."

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

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

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

Дэнни Салливан написал на X по этому поводу следующее: 

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

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

И еще один интересный момент из сентябрьских Google Office Hours. 

Отвечая на вопрос о скроллджекинге, Джон Мюллер заметил: 

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

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

Интересный вопрос в сентябрьских Google SEO Office Hours: почему значения в отчете Google Search Console, полученном с помощью фильтра, могут превышать аналогичные значения в неотфильтрованном отчете?

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

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

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

Запрет в файле robots.txt запрещает сканирование, но не индексацию, и многих напрягает предупреждение в Google Search Console "Проиндексировано, несмотря на блокировку в файле robots.txt" (хотя это и не является ошибкой).

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

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

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

Выглядит весьма любопытно.

Наткнулся на интересный тред в Linkedin. Гуглоид Гэри Ийеш рассказал, в каком случае обработка запроса If-Modified-Since с отдачей кода состояния 304 Not Found может сослужить плохую службу:

1. Краулер запрашивает URL.

2. Сервер обнаруживает какую-то ошибку и отображает пустую страницу с кодом состояния 200 ОК.

3. Сканер считает это временной программной ошибкой и планирует повторное сканирование для проверки.

4. Поскольку сервер считает, что контент (который на самом деле не был предоставлен) не изменился, он возвращает код состояния 304 для данного URL (как того требует стандарт HTTP RFC 9110).

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

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

Получается, в идеале надо отслеживать случаи, когда размер ответа составляет 0 байт при коде состояния 200 OK, как предложил в комментариях другой гуглоид по имени Вивек Синха Анураг, и учитывать эту информацию при обработке запроса If-Modified-Since.

Барри Шварц из SERoundTable вдруг вытащил на божий свет январский пост гуглоида Джона Мюллера, в котором тот говорит об отсутствии эффекта от ключевых слов LSI. 

На вопрос в Твиттере, где лучше использовать LSI – в заголовках или в обычном тексте, Джон отвечает:

"Оба места одинаково полезны для размещения ключевых слов LSI... Оба не имеют никакого эффекта. Любой, кто говорит вам использовать ключевые слова LSI, неправ"

Опять таки соглашусь с Джоном. На мой взгляд, LSI – одна из самых больших профанаций, которая существует в сеошном мире.

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

У кого-то наблюдается что-то подобное?

"Техническое SEO не уходит, оно продолжает оставаться основой всего, что построено в открытой сети" 

– ответил гуглоид Джон Мюллер на заявления одного пользователя соцсети X, что техническое SEO теряет актуальность по сравнению с контентом. 

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

В Блоге Яндекса для вебмастеров появился анонс новых возможностей отчета "Мониторинг запросов" – добавлены сортировка и фильтр по спросу, а также а еще уточнены значения N/A и 0 в отчетах, чтоб было понятно, то ли пользователи не могут найти вас в выдаче по конкретному запросу, то ли статистика по нему просто не отображается в инструменте. 

Такая активность яндексоидов определенно радует.

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

На форуме Reddit натолкнулся на дискуссию по данной проблеме. Буржуйский товарищ вопрошает, является ли домен почтового ящика фактором ранжирования? Вездесущий гуглоид Джон Мюллер парирует вопросом на вопрос "С чего бы?" 

И действительно, с чего бы?

Яндекс активно развивает поиск по товарам (помним: нужно больше золота!) – в Блоге Яндекса для вебмастеров появилось сообщение о том, что информацию об условиях доставки теперь можно добавить прямо в интерфейсе сервиса Яндекс Вебмастер. 

Эх, эту бы активность – да на борьбу с накрутчиками ПФ в органике.

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

Перечислены варианты использования заимствованного контента, не попадающие под санкции:

"авторских (предоставленные производителем, создателем, организатором) описаний товаров, услуг, событий, организаций, компьютерных программ, инструкций к применению и руководств по эксплуатации; 

текстов литературных и фольклорных произведений, песен, анекдотов, цитат и афоризмов; 

текстов законов, указов и других нормативных актов, стандартов, шаблонов документов; 

своего текста из других источников (блогов, социальных сетей), пресс-релизов, опубликованных в других источниках; 

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

Последний пункт про дополнительную ценность определенно радует своей конкретикой 😊

 Какими только обрядами и ритуалами не обрастает сеошная практика. Один буржуйский сеошник на полном серьезе утверждает, что в URL страниц обязательно надо помещать папку с названием услуги (/services/) перед папкой с названием региона (/location/), т.е. структура URL обязательно должна быть в виде site/service/location/. 

Вездесущий гуглоид Джон Мюллер спешит развенчать этот абсурдный миф: 

"Что касается SEO, мы рассматриваем URL скорее как идентификаторы, за очень немногими исключениями".

Наткнулся на интересный (правда, прошлогодний) эксперимент по исследованию повторного сканирования краулерами Google страниц, отдающих ответы 404 и 410. 

Который показал, что страницы с ответом 404 сканируются повторно на 49,6% чаще, чем страницы с ответом 410. 

Получается, чисто с технической точки зрения будет более корректно отдавать 410, если вы не собираетесь размещать на данном URL в будущем индексируемый контент. 

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

P.S. Еще существует поверье, что страницы с ответом 410 быстрее вылетают из индекса, чем с 404. Но экспериментов, подтверждающих это, пока не встречал.

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

Однако ни одного файла с таким расширением в индексе пока не обнаружено.

Наткнулся на довольно старенькое, но весьма любопытное исследование от сервиса Ahrefs, посвященное выделенным описаниям (featured snippet) Google.

Моменты, которые мне показались интересными:

• Выделенные описания показывается у 12% поисковых запросов

• Выделенное описание (по сути "нулевая" позиция в поисковой выдаче) получает в среднем только примерно 8,6% кликов, в то время как страница, которая занимает место прямо под ним (1-я позиция), получает в среднем примерно 19,6% кликов. Если выделенного описания в выдаче нет, 1-я позиция получает в среднем примерно 26% всех кликов. Юзеры меньше доверяют примеси, чем органике?

• 30,9% выделенных описаний берутся с 1-го места выдачи, 99,58% – из топ-10.

• Корреляции числа бэклинков с попаданием в выделенный сниппет не обнаружено (оговорка – исследование проводилось без учета анкорного текста).

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

• Страница с наибольшим количеством выделенных сниппетов показывается по 4658 запросам

• Википедия – абсолютный лидер среди сайтов по числу выделенных описаний.

В блоге Google Search Central Blog вышел материал (пока что только на английском языке) в стиле научпоп под названием "Комедия ошибок", посвященный различным проблемам доступа краулера к вебсайтам (ошибки DNS, сетевые ошибки, ошибки сервера и клиента). 

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

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

1) поместить этот раздел в JavaScript, который запрещен для сканирования;

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

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

Вот такие "вредные советы" от гуглоида.

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

Если страница ссылается сама на себя, попадает ли анкор ссылки в ее анкор-лист? Гуглоид Джон Мюллер утверждает, что нет. 

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

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

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

У меня возникла следующая мысль по поводу наличия/отсутствия преференций в ранжировании Google для определенных доменных зон.

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

Так что в этом смысле старина Мюллер, может, и не кривит душой.

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

Так вот, спешу расставить все точки над "i" - никаким злорадством и плясками тут и не пахнет. 

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

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

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

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

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

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

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

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

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

Редактор Сёрча Оксана Мамчуева опубликовала () текст ответа Яндекса на вопрос по поводу массового наложения фильтра за малополезный контент и спам:

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

Получается, накрыли за вторконтент.

Весьма добротная статья буржуйской сеошницы Эбере Джонатан про всё, что связано с канонизацией страниц. 

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

В блоге Яндекса для вебмастеров появился анонс API для мониторинга запросов. 

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

Хорошая новость, но на фоне закрытия бесплатного сервиса Яндекс.XML как-то блекнет...

 Хинт от гуглоида Джона Мюллера:

 "Лучший способ полностью заблокировать трафик из поиска для определенных URL-адресов — отключить разрешение DNS для них. Обычно для того, чтобы увидеть результаты, требуется менее суток."

Лучшее средство от перхоти — гильотина 😂

Любопытная дискуссия на форуме Reddit о ссылках с Википедии.

Не смотря на известный факт, что исходящие ссылки с Википедии имеют атрибут rel=nofollow (что констатировал в дискуссии гуглоид Джон Мюллер), среди буржуйских сеошников находятся верящие в то, что эти ссылки работают. Вера адептов зиждется на том, что ради Википедии могли сделать исключение. Как будто сотрудники поисковиков не понимают, что ссылки оттуда тоже можно проспамить 😃

Заслуживающая внимания статья на ресурсе  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 - всё?