График работы SEO, 25 февраля 2022 г.

Это краткое изложение самых интересных вопросов и ответов из Google SEO Office Hours с Джоном Мюллером 25 февраля 2022 года.

Отчет о ссылках в Search Console

05:41 «Был домен, на котором раньше был сайт, а потом […] его удалили. [Если] в какой-то момент появляется новый веб-сайт, то ссылки на старый веб-сайт больше не учитываются, что кажется довольно логичным. […] В Search Console я вижу по крайней мере одну ссылку от бывшего владельца, которая все еще там. Означает ли это, что эта ссылка по-прежнему будет учитываться, [если] Search Console […] покажет ее?»

Джон ответил: «Я не знаю, будет ли это учитываться, но важная часть с Search Console и отчетом о ссылках заключается в том , что мы пытаемся показать все известные нам ссылки на этот сайт. Это не признак того, что мы думаем, что это важные ссылки или что они учитываются. В частности, такие вещи, как ссылки nofollow, по-прежнему будут отображаться в списке, ссылки, которые мы игнорируем по другим причинам, также могут быть перечислены. Так что то, что она есть в списке, не означает, что это нерелевантная или полезная ссылка для сайта».  

Неконтекстные ссылки в футере и структура сайта

09:13 «Мы приобрели сайт с множеством внутренних ссылок в нижнем колонтитуле каждой страницы. Некоторые из этих ссылок не так актуальны. […] Может ли Google счесть это проблематичным, потому что ссылки не обязательно контекстные? […] Они просто перемешаны в нижнем колонтитуле и просто выбираются плагином. Мы боимся, что удаление их с сотен страниц может испортить структуру сайта».

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

Посмотрите на это с точки зрения: помогает ли это [...] придать контекст остальным страницам веб-сайта? Например, если у вас большой веб-сайт и практически каждая страница связана с любой другой страницей, там нет реального контекста, поэтому нам сложно понять, какова общая структура, какие из этих страниц важнее. Потому что если ты на все ссылаешься, то вроде все не важно. Это тот элемент, на который я бы обратил внимание. Находятся они в нижнем колонтитуле или нет , с моей точки зрения, это не имеет значения. Если они сгенерированы плагином или добавлены вручную, я не думаю, что это тоже имеет значение. Я бы остерегался со структурной точки зрения: есть ли смысл иметь эти ссылки? Некоторое количество перекрестных ссылок имеет смысл. Если у вас есть настройка, в которой у вас есть связанные страницы с перекрестными ссылками, это, с моей точки зрения, всегда имеет смысл. Экстремальные перекрестные ссылки, когда вы связываете каждую страницу с любой другой страницей, с моей точки зрения, не имеют смысла».

11:10 «[…] Если мы отключим плагин и все эти ссылки вдруг […] пропадут со страницы, это как-то повлияет на сайт? Или мы должны попытаться постепенно удалять ссылки с одной страницы за раз?»

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

Что бы я сделал, чтобы попытаться понять, какова текущая ситуация и каким будет следующий шаг, так это запустить поисковый робот на вашем веб-сайте. Многие сканеры веб-сайтов, которые там существуют, будут генерировать график того, как ваши страницы связаны друг с другом. Затем вы можете отключить плагин, возможно, на тестовой версии вашего веб-сайта, а может быть, даже на действующей версии на короткий период времени. Просканируйте еще раз, а затем сравните эти графики и посмотрите, может ли этот сканер все еще найти весь контент? Похоже, что там недостаточно перекрестных связей? Если это так, то это дает вам немного больше уверенности в том, что простое отключение плагина будет в порядке. С нашей точки зрения, не имеет значения, размещаются ли эти ссылки автоматически, плагином или с помощью машинного обучения. […] Это просто ссылки, которые мы находим на вашем сайте».

Является ли весь скрытый текст нарушением правил Google?

13:22 «Весь ли скрытый текст противоречит правилам для веб-мастеров? […] У нас есть некоторые элементы, которые мы включаем на несколько страниц вместе с внутренними идентификаторами для каждого элемента, поэтому эти идентификаторы ничего не значат для пользователей […], но мне, как оптимизатору, это может сделать мою жизнь намного проще. […]”

Джон ответил: «Я не думаю, что это будет проблематично. Скрытый текст, с нашей точки зрения, более проблематичен, когда речь идет о том, чтобы обмануть поисковые системы в отношении того, что на самом деле находится на странице. Крайний пример: у вас есть страница об обуви, и там много скрытого текста об Олимпийских играх […], а затем вдруг ваша страница об обуви начинает ранжироваться по этим олимпийским терминам. Но когда пользователь уходит, об Олимпиаде ничего нет, и это было бы проблематично с нашей точки зрения.

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

Важность имен файлов изображений для ранжирования сайта

24:56 « Мы используем интеллектуального поставщика CDN, который заменяет имена файлов изображений уникальными номерами. Мы заметили, что все изображения имеют ошибку 404 в Search Console. Отключение CDN значительно ухудшит общую производительность сайта. Будет ли замещающий текст и подписи изображений достаточными для понимания Google без соответствующего имени файла, заголовка?»

По словам Джона, «здесь есть две вещи, на которые я хотел бы обратить внимание. С одной стороны, если это изображения, которые вам нужно проиндексировать в поиске изображений, то вам следует убедиться, что у вас есть стабильное имя файла для ваших изображений. Это самый важный элемент здесь.

Вы не упоминаете, что эти числа или эти URL-адреса меняются, но иногда эти CDN по существу предоставляют идентификатор на основе сеанса для каждого изображения. Если URL-адрес изображения меняется каждый раз, когда мы сканируем, то, по сути, мы никогда не сможем правильно проиндексировать эти изображения. В основном это связано с тем, что для изображений мы немного медленнее сканируем и индексируем. Итак, если мы видим изображение один раз и говорим, что должны его посмотреть, и пытаемся просканировать его снова на каком-то более позднем этапе, и к тому времени номер уже изменился, то мы удаляем это изображение из наших результатов поиска, из рейтинг изображения. По сути, мы скажем, что этого изображения, которое, как мы думали, было здесь, больше нет. Самая важная часть здесь — выяснить, заботитесь ли вы о поиске изображений? Если это так, вам нужно убедиться, что у вас есть стабильный URL-адрес для всех этих изображений. Неважно, число это или текст или что-то в этом роде. Просто должно быть стабильно. Это самая важная часть здесь.

Другая часть, о которой вы упомянули, — это альтернативный текст изображения и подписи, которые предполагают, что вас интересует веб-поиск, а не обязательно поиск изображений. Для веб-поиска нам не нужно иметь возможность сканировать и индексировать изображения, потому что мы, по сути, просматриваем сами веб-страницы. Так что такие вещи, как замещающий текст, любые подписи, заголовки на странице, все это способствует лучшему пониманию этой страницы. Для веб-поиска это все, что нам нужно. Если бы все изображения были, например, 404 все время или заблокированы robots.txt или веб-поиском, мы все равно относились бы к этой странице точно так же, как если бы мы могли проиндексировать все эти изображения. В самом поиске изображений мы должны иметь возможность индексировать эти изображения и понимать, что [существуют] стабильные URL-адреса, и понимать, как они связаны с остальной частью вашего сайта».

Таргетинг на две разные страницы с одним и тем же ключевым словом

29:36 «Одна [страница] — это страница функции, а другая — информационная часть об этой функции. Можно ли настроить таргетинг на одно и то же ключевое слово на этих двух разных страницах?»

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

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

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

Есть ли хорошее соотношение проиндексированных и неиндексированных страниц?

31:26 «Ущербно ли позициям страниц с высоким трафиком, скажем, 50% от общего числа страниц в домене, которые не индексируются или индексируются, но не получают трафика?»

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

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

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

Результаты поиска на веб-сайтах и ​​рейтинг

37:49 «Я пытаюсь убедиться, что наш рейтинг SEO не пострадает, пока мы разворачиваем новую страницу результатов поиска. […] Наши поиски могут дать 10 000 результатов и иметь функции фильтрации и сортировки. Как Google обрабатывает эти страницы результатов поиска на веб-сайтах [и] как эти результаты поиска влияют на общий рейтинг веб-сайта? Достаточно ли просто отправить карты сайта для ранжирования, или нам следует принять дополнительные меры, чтобы помочь роботу Googlebot собирать доступные URL-адреса?»

Джон ответил: «[…] Я бы не стал полагаться на карты сайта , чтобы найти все страницы вашего сайта. Карта сайта должна быть способом предоставить дополнительную информацию о вашем сайте. Это не должно быть основным способом предоставления информации [о] вашем веб-сайте. Так что, в частности, внутренние ссылки очень важны, и вы должны следить за ними и следить за тем, чтобы, как бы вы ни настраивали, когда кто-то сканирует ваш сайт, они могли найти весь ваш контент, а не полагаться на карту сайта. файл, чтобы получить все эти вещи.

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

Другая особенность страниц результатов поиска заключается в том, что люди могут вводить что угодно и что-то искать, а ваш сайт должен выполнять всю работу по созданию всего этого. Это может легко привести к бесконечному количеству URL-адресов, которые теоретически можно найти на вашем веб-сайте, потому что люди могут искать разными способами. И поскольку это создает этот набор бесконечных страниц на вашем веб-сайте, это то, что мы пытаемся препятствовать, когда мы говорим либо установить для этих страниц результатов поиска значение noindex , либо использовать robots.txt , чтобы заблокировать сканирование этих страниц результатов поиска, чтобы мы могли ориентируйтесь на нормальную структуру сайта и нормальную внутреннюю перелинковку. Я думаю, что это основные аспекты там.

Если вы действительно хотите, чтобы ваши страницы результатов поиска были проиндексированы, то я бы посоветовал убедиться, что, с одной стороны, у вас есть один основной порядок сортировки и настройки фильтрации, настроенные как канонические. Поэтому, если вы решите предоставлять свои страницы по релевантности, то если у вас есть фильтр сортировки по цене вверх или вниз, я бы установил rel="canonical" этих фильтров в ваш основной порядок сортировки. Точно так же для фильтрации я бы, возможно, удалил фильтр с rel="canonical". Делая это, убедитесь, что мы можем больше сосредоточиться на основной версии страниц и правильно их сканировать, а не отвлекаться на все эти варианты страниц результатов поиска.

Еще одна вещь, на которую я бы обратил внимание, это то, что вы создаете какой-то список разрешений или [...] систему на своем сайте в отношении типа поисковых запросов, которые вы хотите разрешить индексировать или сканировать. Например, если кто-то заходит на ваш веб-сайт и ищет «Канадские фармацевтические препараты» или что-то в этом роде, а вы не являетесь фармацевтическим веб-сайтом, вы, вероятно, не хотите, чтобы эта страница поиска была проиндексирована. Даже если у вас нет доступных продуктов, соответствующих этому запросу, вы, вероятно, не хотите, чтобы он индексировался. Таким образом , наличие списка разрешенных поисковых запросов, которые вы разрешаете индексировать, значительно упрощает эту задачу . Убедитесь, что вы случайно не столкнетесь со спамом, когда кто-то спамит ваши результаты поиска, а затем вам придется очистить миллионы проиндексированных страниц и каким-то образом избавиться от них».

Обновление Page Experience на рабочем столе по сравнению с ранжированием

42:20 « Посещаемость моего веб-сайта упала из-за плохой работы Core Web Vitals. Теперь я вернулся на правильный путь, но узнал, что обновление Page Experience теперь медленно развертывается для настольных компьютеров. Каково ранжирование Page Experience для настольных компьютеров и насколько оно важно по сравнению с другими сигналами ранжирования?»

По словам Джона, «как и на мобильных устройствах, фактор ранжирования Page Experience — это, по сути, то, что дает нам немного дополнительной информации [об] этих разных страницах, которые могут отображаться в результатах поиска. В ситуациях, когда у нас есть [...] четкое намерение из запроса, когда мы можем понять, что они действительно хотят сделать это с этим веб-сайтом, тогда, с этой точки зрения, мы можем уменьшить использование Page Experience в качестве фактора ранжирования. С другой стороны, если весь контент на странице результатов поиска очень похож, то, вероятно, использование Page Experience помогает немного понять, какие из них являются быстрыми страницами или разумными страницами с точки зрения взаимодействия с пользователем, а какие из них менее подходящие страницы для отображения в результатах поиска. Эта ситуация помогает нам там.

Что касается настольного развертывания, я полагаю, что это будет более медленное развертывание снова в течение примерно месяца, что означает, что вы не увидите сильного эффекта от одного дня к другому, а скорее увидите, что эффект в течение определенного периода времени. Вы также уже видели это в Search Console в отчетах Page Experience и Core Web Vitals. Например, вы уже видели бы, что на рабочем столе все красное, и вам нужно сосредоточиться на этом. С этой точки зрения, с изменением рейтинга настольных компьютеров, как и с мобильными, я бы не ожидал резкого скачка результатов поиска от одного дня к другому, когда мы это внедряем. В лучшем случае, если дела с вашим сайтом действительно плохи, вы увидите постепенное падение».

Неиндексированный переведенный контент

53:15 « Я работаю над большим многоязычным сайтом. В апреле прошлого года […] весь наш переведенный контент переместился из категории «Действительный» в категорию «Исключено, просканировано» — в настоящее время не индексируется и остается с апреля. […] Поскольку это произошло сразу, мы подумали, что, возможно, на нашей стороне произошли какие-то системные изменения. […] Мы очистили наши hreflangs, canonical, параметры URL-адресов, ручные действия и все другие инструменты, перечисленные на сайте developments.google.com/search. […] Я не знаю, что случилось и что делать дальше, чтобы попытаться решить проблему, но я хотел бы вернуть наш переведенный контент в индекс».

Джон ответил: «[…] Я думаю, [это] иногда сложно, [если] у вас есть параметр в конце с кодом языка. […] С нашей точки зрения, что может случиться, так это то, что когда мы осознаем, что там много этих параметров, которые ведут к одному и тому же контенту, тогда наши системы могут застрять в ситуации, ну, может быть, этот параметр не очень полезно, и мы должны игнорировать его. Для меня это звучит очень похоже на то, что что-то около этой линии произошло. Частично вы можете помочь в этом с помощью инструмента «Параметры URL » в Search Console, чтобы убедиться, что этот параметр установлен. Я хочу, чтобы все было проиндексировано. Частично то, что вы также можете сделать, это, возможно, просканировать часть вашего веб-сайта […] локальным поисковым роботом, чтобы увидеть, какие URL-адреса параметров на самом деле подбираются, а затем дважды проверить, действительно ли эти страницы содержат полезный контент для этих языков.  

В частности, […] обычная [вещь], которую я видел на сайтах, может быть, у вас […] все языки связаны, и японская версия говорит, что у нас нет японской версии, вместо этого есть наша английская, тогда наши системы могли бы сказать, ну, японская версия такая же, как английская версия ‒ может быть, есть какие-то другие языки, такие же, как английская версия. Мы должны игнорировать это. Иногда это ссылки внутри веб-сайта, иногда это также внешние ссылки, люди, которые ссылаются на ваш сайт. Если параметр находится в конце вашего URL-адреса, то очень часто к параметру также прилагается некоторый мусор. И если мы просканируем все эти URL-адреса с этим мусором и скажем, ну, это недопустимый язык, вот английская версия, то это снова усилит ту петлю, когда системы говорят, ну, может быть, этот параметр не так уж и полезен. Более чистый подход был бы, если бы у вас были какие-то мусорные параметры для перенаправления на более чистые или, может быть, даже для отображения страницы 404 и сказать, ну, мы не знаем, о чем вы говорите с этим URL, и чисто сделать уверены, что какие бы URL-адреса мы ни нашли, мы получим полезный контент, который не совпадает с другим контентом, который мы уже видели».