Часы работы SEO — 24 декабря 2021 г.

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

Платный контент и маскировка

00:49 «Что касается платных данных с платным контентом. […] У нас есть веб-сайт. Мы сделали много статей, и все доступно для Google. И мы хотели бы добавить там платный доступ, но […] только […] показывать контент с платным доступом в Google с имеющимися фрагментами структурированных данных. Считается ли это маскировкой?

Итак, я проверяю, не Googlebot ли это, и только [затем] показываю […] структурированные данные — […] данные с платным доступом. Но тогда обычному пользователю […] я не показываю структурированные данные, это нормально?»

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

Возможные проблемы с индексацией

03:38 «Публикую качественный контент, отправил карту сайта и иногда запрашиваю индексацию в Google Search Console. Но у меня по-прежнему проблема с индексацией нового контента или он индексируется [с задержкой]. […] Это ошибка Google или новое обновление алгоритма?»

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

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

Обновление обзоров продуктов — затрагиваемые языки и страны

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

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

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

«С такого рода обновлениями мы пытаемся начать работу с одного языка или одного местоположения и посмотреть, что нам нужно настроить, а затем расширяемся оттуда. […] С чем-то, что больше связано с контентом, обычно требуется немного больше времени для расширения на разные языки […]».

Локализация страниц для англоязычных стран

17:53 «Знаете ли вы другие способы локализации одного и того же набора страниц для разных англоязычных стран? […] У нас есть несколько субдоменов с доменом верхнего уровня .jo, например, субдомены из Австралии, Новой Зеландии, и мы установили страну в бэкэнде JSA, а также используем hreflang на уровне страницы. […] Мы не смогли придумать какие-то другие способы помочь нам локализовать эти поддомены. Есть ли у вас хорошие методы или способы, которые мы можем улучшить?»

Вот как Джон рассуждал на эту тему:

«Я думаю, вы рассмотрели основные из них. Это геотаргетинг в Search Console и настройки hreflang.

Геотаргетинг работает на уровне подкаталога или поддомена, там все страницы.

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

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

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

Если у вас есть атрибут hreflang, на этих страницах мы по-прежнему будем использовать атрибут hreflang для отображения правильной версии URL-адреса. Но проиндексированный контент будет только из канонической версии, и все отчеты в Search Console будут относиться к канонической версии. Это иногда усложняет задачу, особенно если у вас большой веб-сайт […] с одинаковым контентом для разных стран».

Добавление динамического контента на страницы

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

Вот что ответил Джон:

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

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

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

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

Рендеринг и индексация файлов JavaScript

28:28 «Мой веб-сайт […] [использует] React с рендерингом на стороне клиента, […] когда мы отключаем JavaScript и браузер, моя страница совершенно пуста. Это может быть причиной более низкого рейтинга или, может быть, плохой работы веб-страницы?»

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

Индексация URL-адресов, созданных в результате поиска на веб-сайте

30:11 «Мы уже добавили окно поиска на наш веб-сайт , поэтому пользователь заходит на наш веб-сайт и выполняет поиск там, и для каждого поиска создается уникальный URL-адрес. Эти URL должны быть индексируемыми или нет ?»

Как сказал Джон: « Обычно нет. […] На это есть две основные причины.

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

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

SEO-сайты как YMYL

31:55 «Будет ли SEO-фирма классифицироваться как веб-сайт « Ваши деньги или ваша жизнь » или она связана только с веб-сайтами с медицинскими и финансовыми консультациями?»

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

Я бы порекомендовал здесь вместо того, чтобы слепо пытаться увидеть «Попадает ли этот тип веб-сайта в эту конкретную категорию?», [...] прочитать, откуда взялась эта категория, а именно Руководство по оценке качества, и понять немного больше. что Google пытается сделать с пониманием этих различных типов веб-сайтов . […] Это даст вам немного больше справочной информации о том, что на самом деле происходит […]».

Внедрение структурированных данных хлебных крошек

39:56 «Когда дело доходит до структурированных данных хлебных крошек, должны ли они быть точно такими же, как хлебные крошки, которые посетитель увидит на странице? Иногда я вижу сжатую версию хлебных крошек на странице, в то время как структурированные данные представляют собой полный путь хлебных крошек. Оба варианта приемлемы?»

Как сказал Джон: «[…] Мы пытаемся распознать, видны ли структурированные данные на странице или нет. И если это не […], мы должны выяснить «Есть ли смысл показывать это в результатах поиска? ”

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

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

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

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

Перевод только некоторых страниц на веб-сайте

44:00 «У нас есть сайт с менее чем 300 индексными страницами, все на английском языке. Мы хотим перевести примерно половину этих страниц на испанский язык, которые будут размещены в подкаталоге того же домена, например /ES, и помечены как альтернативные языковые версии англоязычного контента. Можно ли переводить только часть содержимого страницы, или мы должны перевести все, чтобы точно отражать английский веб-сайт и иметь наилучшие шансы на ранжирование в других местах?»

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

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

Бюджет сканирования и автоматически сгенерированные URL-адреса

46:12 «Веб-сайт, о котором я говорю, — это веб-сайт WordPress. Он автоматически генерирует несколько нежелательных URL-адресов. […] есть ли способ остановить поисковый робот, чтобы узнать эти URL-адреса? Я знаю, что могу «не индексировать», и все эти URL-адреса не индексируются. Но затем я вижу их в консоли поиска в разделе «Исключенные». […] Это новостной веб-сайт, у нас есть тысячи URL-адресов. […] Повлияет ли это на краулинговый бюджет?»

Джон спросил о размере веб-сайта, и ему сказали, что он составляет от 5 000 до 10 000 URL-адресов.

Учитывая это, Джон сказал: « Я бы не стал беспокоиться о краулинговом бюджете. […] Мы можем просканировать такое количество страниц довольно быстро, обычно в течение нескольких дней. Другая вещь […] заключается в том, что «noindex» — это метатег на странице. Мы должны просканировать страницу, чтобы увидеть метатег, а это значит, что вы не можете избежать того, что мы проверяем страницы «без индекса». […] Если мы видим, что на странице есть «noindex», то обычно со временем мы сканируем эти страницы реже. Мы по-прежнему будем перепроверять время от времени, но мы не будем проверять так много, как обычную страницу, которая в противном случае проиндексирована. Другой подход — использовать robots.txt. С помощью файла robots.txt вы можете полностью заблокировать сканирование этих страниц. Недостатком является то, что иногда в результатах поиска может быть проиндексирован сам URL, а не контент на странице […]».

Джон также привел следующий пример:

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

Джон также добавил: « С практической точки зрения «noindex» и robots.txt были бы в некотором роде эквивалентны. […] Этот контент, вероятно, не появится в результатах поиска, и нам все равно придется его сканировать, если есть «noindex», но цифры настолько малы, что они не имеют большого значения. Мы все еще можем проиндексировать его с помощью URL-адреса, если они заблокированы файлом robots.txt […]».

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

Сканирование URL с параметрами

54:25 «В наших лог-файлах мы видим, а также подтверждаем, что это робот Googlebot через IEP, много обходов от обычного бота к URL-адресам параметров UTM, Google Display и универсальным кампаниям приложений. […] Мы не видим никаких ссылок на эти URL-адреса. […] У вас есть идеи, где и почему это может происходить?»

Джон ответил, что «Единственное место, где с помощью робота Googlebot мы также сканируем страницы, которые вы указываете в рекламных кампаниях […], — это поиск товаров. Если у вас настроен фид поиска товаров или фид Merchant Center […], мы также просканируем эти страницы для робота Googlebot, чтобы убедиться, что мы можем подобрать их для Merchant Center. Если у вас там есть URL-адреса с тегами, [...] мы сохраним эти URL-адреса с тегами и переобработаем их.

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

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