График работы SEO, 4 марта 2022 г.

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

Тестирование разметки схемы в валидаторе schema.org и в Google Search Console

7:41 «Джон, мой первый вопрос: Google Search Console выдает ошибку […] в обязательном элементе структурированных данных. Но когда я проверяю то же самое на validator.schema.org, он не показывает никаких предупреждений или ошибок. Итак, первый вопрос: подходит ли этот сайт для проверки реализации AMP на веб-странице? […]“

Джон ответил: « Да, значит, эти инструменты тестирования предназначены для немного разных целей. Вероятно, поэтому вы видите эту разницу. Инструмент тестирования в schema.org больше связан с пониманием разметки schema.org в целом, в целом, на основе требований, которые есть у schema.org. А инструмент тестирования в Search Console ориентирован исключительно на то, что мы можем извлечь из структурированных данных и использовать для отображения в функции поиска. Так что это действительно сосредоточено на поисковой части этой истории. А в Поиске мы используем только небольшую часть разметки schema.org. И иногда у нас есть немного другие требования, которые, возможно, требуют определенного элемента больше, чем требует базовая разметка schema.org. И часто именно поэтому вы видите эту разницу. И валидатор schema.org предназначен для теоретической разметки, а валидатор Google действительно для практической стороны поиска Google. “

9:20 «[…] В принципе, это не ошибка. Это предупреждение в Search Console. И когда я проверяю детали в Search Console, он просто говорит, что вы делаете это неправильно. Так будет ли возможный способ [исправить проблему], или это должна выяснить моя команда разработчиков?

Джон объяснил: «Да, если это предупреждение, то я бы не беспокоился об этом. Это в основном просто говорит, что вы могли бы сделать что-то по-другому. […]. Что бы я сделал, если вы хотите выяснить, в чем именно разница, так это перепроверил бы документацию для поиска на сайте developments.google.com, где у нас есть все задокументированные структурированные данные и все обязательные и рекомендуемые поля. И, вероятно, это предупреждение вызывается одним из рекомендуемых или необязательных полей».

Причины, по которым страница может быть просканирована, но не проиндексирована

14:11 « По какой возможной причине […] некоторые страницы не были проиндексированы, хотя они сканировались несколько раз? ”

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

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

15:41 «[…] какие другие факторы [помимо уже упомянутых] могут привести к тому, что Googlebot решит, о, мы не хотим индексировать его в конце?»

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

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

Может ли удаление списков продуктов на сайте электронной коммерции поставить вас в невыгодное положение?

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

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

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

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

Важность внутренней ссылочной структуры

25:18 « Если у вас есть структурированные данные для настройки хлебных крошек, важны ли внутренние ссылки для SEO?»

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

Таким образом, только потому, что где-то на странице есть структурированные данные, я бы не рассматривал это как замену обычным внутренним ссылкам. Даже если в структурированных данных вы также предоставляете URL-адреса, мы не используем эти URL-адреса так же, как обычные внутренние ссылки на странице. Так что это определенно не тот случай, когда аннотации hreflang заменяют ссылки между версиями для разных стран, а аннотации хлебных крошек заменяют ссылки между разными уровнями веб-сайта. У вас действительно должны быть нормальные HTML-ссылки между различными частями вашего сайта. И, в идеале, у вас должен быть не просто базовый набор ссылок, а, скорее, вы должны смотреть на него со стратегической точки зрения и думать о том, что вас больше всего волнует, и как вы можете выделить это своими внутренними ссылками? ”

Несколько схем продуктов на странице со списком продуктов

29:50 « Можем ли мы для страницы со списком продуктов реализовать несколько схем продуктов на странице со списком продуктов? ”

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

Может ли пострадать ваш рейтинг, если вы создадите страницы на разных языках?

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

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

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

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

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

Различия в контенте между мобильной и десктопной версиями

34:20 « Если есть разница между контентом в мобильной и настольной версии, означает ли это, что Google накажет сайт и повлияет на рейтинг сайта, или это просто означает, что робот Googlebot может найти его в мобильной версии, но он выиграл не быть в состоянии ранжировать? ”

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

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

Можете ли вы разместить карту сайта в облаке?

46:20 « У нас есть действительно огромная страница с миллионами URL-адресов, и [...] карты сайта в настоящее время обновляются. И наша ИТ-команда рассматривает возможность хранения […] новых файлов карты сайта в нашем облачном сервисе. То есть с example.com/sitemaps на cloud.com/sitemaps. И нам интересно, это проблема, если мы храним карты сайта в облаке? И если это не проблема, мы должны также создать постоянную переадресацию для старого URL-адреса для этого example.com/sitemap, или как мы должны спланировать переезд? ”

Джон сказал: « Определенно возможно разместить файл карты сайта в другом месте. Есть два способа сделать это. Во-первых, если у вас есть оба этих домена, проверенных в Search Console, тогда это работает. Другой способ — отправить его с файлом robots.txt, где вы указываете «карту сайта:», а затем URL-адрес карты сайта. Это также может перейти в другой домен. […] Я бы также перенаправил старый файл карты сайта в новое место, просто чтобы быть чистым, но, вероятно, даже если вы просто удалите старый URL-адрес карты сайта и убедитесь, что новый правильно отправлен, тогда это должно просто работать.  

Что может быть немного сложно, так это то, что я не знаю, как Search Console покажет это непосредственно в пользовательском интерфейсе, в частности, если файл карты сайта находится в другом месте, если Search Console покажет информацию о карте сайта в отчете об индексации, Например. Но это проблема отчетности. Это не то, что зависит от функциональности файла карты сайта. На самом деле просто Search Console не показывает это должным образом. И, опять же, может быть, это так. Я просто не уверен на 100%. ”

Может ли история домена повлиять на ваш сайт?

49:40 «[…] Итак [во время предыдущих рабочих часов SEO ] мы задали этот вопрос о домене с историей в качестве поставщика услуг сопровождения. […] домен имеет долгую историю, потому что первый снимок этого веб-сайта датирован 1997 годом. […] мы перезапустили наш веб-сайт в июне прошлого года […]. И главная проблема, с которой мы сталкиваемся, […] заключается в том, что нас все еще помечают [как контент для взрослых]. И, кроме того, у нас есть эта проблема […] — просканировано, в настоящее время не проиндексировано. И мы пытаемся понять, может ли история домена повлиять на то, что у нас проблемы с индексацией. […] мы верим, что контент, который мы публикуем, хорошего качества. Это внутренняя ссылка, и мы пытаемся создать качественный сайт. В чем мы сейчас боремся, так это в производительности страницы, поэтому в данный момент мы занимаемся оптимизацией для этого. Но мы используем prerender.io , поэтому то, что мы показываем для Google, уже является предварительно обработанной версией. Так что, когда дело доходит до оценки Lighthouse, все в порядке. […] Что мы можем улучшить или искать, чтобы понять, почему нас не индексируют? Я также рад поделиться URL. “

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

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

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

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