Часы работы SEO — 8 октября 2021 г.

Это краткое изложение самых интересных вопросов и ответов из рабочего дня Google SEO с Джоном Мюллером 8 октября 2021 года.

Количество проиндексированных страниц и авторитет сайта

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

Как сказал Джон: «Определенно не так, что если у вас проиндексировано больше страниц, мы думаем, что ваш веб-сайт лучше. […] Иногда имеет смысл проиндексировать много страниц. Иногда такие страницы полезны для такой индексации. Но это не показатель качества в отношении того, сколько страниц проиндексировано. И особенно если вы говорите о […] 1000, 2000, 5000 страниц, это довольно мало для наших систем в целом. И дело не в том, что мы бы сказали, что 5000 страниц лучше, чем 1000 страниц. Для нас это все вроде как, ну, это небольшой веб-сайт, и мы обходимся тем, что можем оттуда вытащить. И, конечно же, маленький сайт относителен. Это не то же самое, что сказать, что это нерелевантный веб-сайт. Он может быть небольшим, но все же может быть очень полезным [...]».

Оценка основной цели веб-сайта

10:03 «В прошлый раз мы говорили о некоторых проблемах с веб-сайтом […] — это веб-сайт электронной коммерции, где у нас есть информационные материалы и транзакционные материалы. […] Ваш совет заключался в том, чтобы немного разделить этот контент на страницы, ориентированные на транзакции, и страницы, ориентированные на информацию. Поэтому у меня есть еще один вопрос по этому поводу. Если у вас есть, скажем, веб-сайт электронной коммерции, и у вас есть огромный блог, или журнал, или что-то в этом роде, где у вас много информации, но это старый раздел. А с другой стороны, у вас есть все эти страницы товаров, категории и так далее. Таким образом, этот огромный блок с чисто информационным материалом придаст всему веб-сайту некий информационный оттенок или характер, чтобы Google сказал: «О, мы не уверены, что это […] что-то, где люди могут получить информацию, а не покупать что-то, или это эта оценка делается для каждой страницы?»

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

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

[…] Мы как бы должны смотреть на него постранично , а не говорить: «О, это исследовательский веб-сайт, потому что здесь есть некоторый исследовательский контент».

Перенаправление ссылок

13:21 «Мы видим, что люди ссылаются на […] нашу, скажем, подкатегорию страниц. И проблема в том, что […] наш контент приходит и уходит, а это значит, что иногда в некоторых категориях появляется больше контента. Иногда контент удаляется. Таким образом, подкатегории могут создаваться и исчезать. И мы видим кучу переходов по обратным ссылкам, потому что они ссылаются на подкатегории, которых больше не существует. У меня вопрос: можно ли перенаправлять […] эти ссылки в родительскую категорию. А если так, то как, например, с 302? Как временное перенаправление, потому что в будущем эта подкатегория может быть снова заполнена контентом, [...] это не постоянное перенаправление».

Джон ответил: «Поэтому, если мы увидим, что это происходит в большем масштабе, когда вы перенаправляете на родительский уровень, мы, вероятно, воспримем это как мягкую ошибку 404. […] И вместо кода 404 вы перенаправляете, и, возможно, это лучше для пользователей, но мы видим это как 404. […] Если с точки зрения пользователя перенаправление имеет смысл, то я бы просто пошел на это.

[…] Что касается 301 или 302, я не думаю, что это имеет значение, потому что мы либо будем рассматривать это как мягкий 404, либо мы будем рассматривать это как вопрос канонизации. Если это мягкая ошибка 404, то код не имеет значения. Если это вопрос канонизации, то все сводится к тому, какой URL мы показываем в результатах поиска. И обычно более высокий уровень в любом случае будет иметь более сильные сигналы, и мы сосредоточимся на более высоком уровне. Так что в данном случае не имеет значения, 301 это или 302.

[…] Если мы увидим это как программную ошибку 404, [...] мы замедлим сканирование этого конкретного URL-адреса, потому что здесь ничего нет […]. Если мы видим это как перенаправление […], нам не нужно сканировать его каждый день, потому что мы фокусируемся на основном URL-адресе. Поэтому я думаю, что в обоих этих случаях мы замедлим сканирование этого URL-адреса, пока не получим новые сигналы, которые говорят нам, что на самом деле это, возможно, снова что-то новое. […] Это было бы похоже на внутреннюю ссылку или файл карты сайта […]. И это будет более сильным знаком, чтобы мы снова ползли. Но я думаю, что замедление ползания будет одинаковым во всех этих случаях.

[…] Я думаю, что одних [обновлений] карт сайта, вероятно, недостаточно. Я бы действительно убедился, что внутренняя ссылка также понятна ».

Восстановление после обновлений ядра

18:34 «Итак, около года назад мы увидели значительное снижение трафика. После аудита […] все сигналы указывали на то, что сайт имеет проблемы с качеством сайта. Мы смогли решить эти проблемы к февралю этого года. И к июньскому обновлению ядра мы увидели некоторое увеличение. Но это все еще не тот уровень, на котором мы были до снижения около года назад. Итак, мой вопрос касается проблем с качеством сайта, если это так, то можно ли ожидать восстановления, или мы можем ожидать большего восстановления, если мы думаем, что устранили все выявленные проблемы […]?»

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

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

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

Ссылки в гостевых постах

28:24 «[…] Если [на веб-сайте есть] гостевой пост, и Google не знает, платный он или нет, как тогда Google определит, что [они должны] взять эту ссылку или сжечь эту ссылку? Каков ответ, чтобы мы были в безопасности со всех сторон?»

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

Цена продукта как фактор ранжирования

32:25 «Если есть два конкурирующих сайта электронной коммерции, которые продают один и тот же продукт — один веб-сайт предлагает продукт за 500 долларов, а другой — за 100 долларов, все сигналы SEO равны. Будет ли у менее дорогого веб-сайта больше шансов на ранжирование из-за такой разницы в цене на один и тот же продукт?».

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

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

Таким образом, с точки зрения веб-поиска, мы не принимаем во внимание цену. С точки зрения поиска продукта это возможно . И сложная часть, я думаю, как SEO, эти различные аспекты поиска часто объединяются на одной странице результатов поиска, где вы увидите обычные веб-результаты, и, возможно, вы увидите некоторые результаты продукта сбоку, или, может быть, вы увидите смесь этого [...]».

Перемещение URL-адресов между картами сайта

34:04 «Если у нас есть 200 файлов карты сайта, и от 20% до 30% URL-адресов каждую неделю перескакивают с одного файла на другой, насколько это может быть плохо? Или мы должны строго хранить наши URL-адреса в одном и том же файле навсегда?»

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

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

Мультирегиональный контент

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

Статьи сложные. Мы мало что можем отличить между мультирегиональными подкаталогами, кроме модулей со связанными ссылками, что заставляет нас беспокоиться о проблемах с дублированием контента. Как Google обрабатывает дублированный контент в новостном пространстве? […] Содержание остается прежним, но элементы шаблона другие. Должен ли быть только один канонический код на всех мультирегиональных веб-сайтах?»

Джон ответил: «[…] Похоже, это разные регионы в одной стране, и содержание на одном языке. […] Если это разные страны, то у вас есть аспект геотаргетинга, который играет роль, если это разные языки. Так что, если вы работаете, скажем, в Европе и освещаете Германию, Францию, Италию или что-то в этом роде, то у вас также есть разные языки.

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

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

Что касается категорий, разделов и домашних страниц, кажется, что это будет что-то, где контент будет более уникальным и более специфичным для отдельных регионов. И из-за этого я бы попытался просто разделить эти уровни индекса. Таким образом, если у вас есть пять разных региональных веб-сайтов, их домашняя страница, их разделы категорий, все они будут проиндексированы индивидуально. И сами новостные статьи будут привязаны к одному из этих разных регионов. Вот такой подход мы там рекомендуем […].

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

Перенаправление при перемещении сайта

44:34 «Что лучше всего предпринять, если вам нужно перенаправить 301 все URL-адреса на новый набор URL-адресов? Количество страниц будет больше миллиона, а вы хотите минимизировать эффект песочницы? Если есть эффект песочницы, то как долго он может длиться? Потеряем ли мы рейтинг, который, возможно, уже никогда не восстановим? Мы планируем сделать перенаправление один к одному и запросили пакетное перенаправление, но это невозможно, поэтому страницы, изображения, URL -адреса и т. д. должны будут перелистываться одновременно».

Как сказал Джон: «Для меня это похоже на традиционную ситуацию с перемещением сайта. Вы переходите с одного домена на другой и перенаправляете все URL-адреса со своего старого сайта на новый, и нам приходится иметь дело с этим […]. Когда дело доходит до перемещения сайта, с нашей стороны определенно не существует ничего определяемого как эффект песочницы . Поэтому, если вам нужно переместить сайт, сделайте это и перенаправьте все свои страницы. Часто самый простой подход — просто перенаправить все страницы сразу. Наши системы также немного настроены на это, чтобы попытаться распознать это. Поэтому , когда мы видим, что веб-сайт начинает перенаправлять все страницы на другой веб-сайт, мы пытаемся обработать это немного быстрее , чтобы мы могли как можно быстрее обработать это перемещение сайта. И это точно не тот случай, когда мы скажем: «О, они делают перенос сайта, поэтому мы будем тормозить […]».

API и краулинговый бюджет

46:13 «У меня есть веб-сайт, который подключается к API на стороне клиента для получения данных. Включены ли эти URL в бюджет сканирования? Если вы запретите эти URL-адреса, […] это создаст какие-либо проблемы?»

«[…] Если эти API включаются при отображении страницы, то да, они будут включены в сканирование и будут учитываться в вашем краулинговом бюджете в основном потому, что нам нужно сканировать эти URL-адреса для отображения страницы. Вы можете заблокировать их с помощью robots.txt, если предпочитаете, чтобы они не сканировались и не использовались во время рендеринга. Полностью зависит от вас, если вы предпочитаете делать это. Особенно, если у вас есть API, обслуживание которого обходится дорого или требует много ресурсов, то иногда это имеет смысл.

Думаю, сложная часть заключается в том, что если вы запретите сканирование конечной точки вашего API, мы не сможем использовать какие-либо данные о возвратах API для индексации. Поэтому, если содержимое вашей страницы поступает исключительно из API, и вы запрещаете сканирование API, у нас не будет этого контакта. […] Если API просто делает что-то дополнительное к странице, например, рисует карту или […] изображение числовой таблицы, которая есть у вас на странице, […] тогда, возможно, не имеет значения, является ли это содержимое не включены в индексацию. Другое дело, что иногда нетривиально работает страница, когда API заблокирован. В частности, если вы используете JavaScript, а вызовы API заблокированы из-за robots.txt, вам нужно как-то обработать это исключение. И в зависимости от того, как вы внедряете JavaScript на страницу, что вы делаете с API, вам нужно убедиться, что он все еще работает. Поэтому, если этот вызов API не работает, а затем остальная часть страницы полностью прерывается, мы не можем много индексировать, потому что нечего рендерить.

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

JavaScript и кеш Google

49:36 «Итак, две страницы происходят из одного домена. URL-адрес немного отличается, он является частью той же структуры каталогов. И […] они генерируются NextJS. Итак, NextJS — это фреймворк для реагирования на стороне сервера. И они индексируются, но одну страницу я вижу в кеше гугла, а второй страницы нет в кеше гугла. И я вижу один и тот же шаблон независимо от того, как я генерирую страницу […]. Большинство моих страниц находятся в кеше Google, но теперь я беспокоюсь, потому что в настоящее время я перехожу со своего технологического стека на основе Java, который генерирует все эти страницы, на Google NextJS. […] Когда я занимался отладкой, я обнаружил, что это также проблема старого стека Java, который мы использовали.

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

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

[…] Страница кеша не является отображаемой страницей. По сути, это просто HTML-файл, который мы запросили, и его копия. И если файл HTML что-то показывает, это нормально. Если он использует JavaScript, а JavaScript не запускается, потому что это страница кеша, это тоже нормально. Вы просто не видите его на странице кеша. Поэтому, если страница кеша не отображается, я бы не стал об этом беспокоиться. Это не признак какой-либо проблемы. И часто […] вы не можете контролировать, есть страница кеша или нет. Я бы просто проигнорировал это».

https://www.youtube.com/watch?v=Vd0rEQrwHDc