8 февраля 2019 г. — Google Help Hangout Notes

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

Как Google интерпретирует страницу, если вместо <p> используются теги h?

4:34

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

Резюме: Это, вероятно, не имеет большого значения. Однако Джон подтвердил, что Google может использовать теги h, чтобы определить, какой контент на странице важен и о чем эта страница.

Почему Google иногда не соблюдает канонический синдицированный контент?

8:56

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

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

Всегда ли Google распознает разметку структурированных данных?

26:58

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

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

Всегда ли Google распознает разметку структурированных данных?

53:46

Я думаю, что это всегда немного сложно, обычно здесь задействованы два аспекта. Еще одна проблема, особенно с новыми веб-сайтами, где название веб-сайта или название компании больше похоже на общий запрос. Итак, если, например, название веб-сайта «Лучшие юристы в Питтсбурге» или что-то в этом роде. Тогда, с одной стороны, это может быть название компании, а с другой стороны, если бы кто-то ввел это в поиск, мы, вероятно, предположили бы, что они ищут не эту конкретную компанию, а информацию по этому запросу. . Так что это особенно с новыми компаниями, это то, что мы видим время от времени. Мы видим, что форумы или люди там говорят: «О, я не ранжируюсь по моему доменному имени», а затем их доменное имя что-то вроде «Я не знаю лучших VPN-провайдеров». Это не значит, что вы будете ранжироваться по этому запросу. Так что это одно, когда речь идет о сайтах, которые немного более устоялись, которые уже существуют, как правило, это скорее признак того, что мы просто больше не доверяем этому сайту. Таким образом, мы можем признать, что на самом деле люди ищут эту компанию, но мы чувствуем, что, возможно, сам веб-сайт компании не является наиболее релевантным результатом, может быть, мы чувствуем, что есть своего рода вспомогательная информация об этой компании, которая более важна, чем пользователи. сначала посмотрите, где это может привести к чему-то подобному. Обычно это скорее вопрос перетасовки вещей на первых одной или двух страницах в результатах поиска. Было бы очень редко, чтобы что-то подобное приводило к тому, что веб-сайт вообще не отображался на первых парах страниц результатов поиска. Я думаю, это то, что вы выделили там своим вопросом, и это то, о чем я думаю хорошо, даже если мы больше не доверяем этому веб-сайту, мы должны, по крайней мере, иметь его где-то в результатах поиска, потому что, если мы можем сказать что кто-то явно ищет этот веб-сайт, было бы плохой услугой для пользователя, если бы он вообще не показал его. Как и для общих запросов, можно утверждать, что, возможно, это не идеальный результат, но если мы можем сказать, что они действительно ищут этот веб-сайт, по крайней мере, мы должны дать пользователю возможность увидеть этот веб-сайт. Вот почему я взял это и сказал, что, может быть, нам следует улавливать это немного лучше, и я не знаю, правильно ли наши алгоритмы понимают, насколько надежным будет ваш веб-сайт. Я не знаю веб-сайт, поэтому мне трудно судить, но даже если мы думаем, что он вообще не заслуживает доверия, возможно, нам все же следует показать его где-нибудь в результатах поиска на первой странице. Еще одна вещь, на которую, возможно, стоит обратить внимание, если вы еще этого не сделали, — это взглянуть на руководящие принципы оценки качества, которые у нас есть, и там есть много информации о том, насколько можно доверять. Кое-что из этого стоит воспринимать с долей скептицизма. Мы не берем такого рода один на один и используем его в качестве фактора ранжирования, но там есть много идей, особенно когда вы говорите о теме. это своего рода юридический веб-сайт или медицинский веб-сайт, тогда имеет смысл показать пользователям, например, почему вы предоставляете эту информацию, почему они должны вам доверять.

Резюме: Если у вас есть новый бренд, в названии и URL которого есть ключевые слова, это не означает, что вы должны автоматически ранжироваться по этим ключевым словам. Однако, если алгоритмы Google не доверяют вашему сайту, он не будет хорошо ранжироваться. Джон указывает нам на Руководство по оценке качества для получения дополнительной информации. Наше примечание: здесь также есть полезная информация о том, как, по нашему мнению, недавние обновления алгоритма связаны с доверием.

Если вам нравятся такие вещи, вам понравится мой информационный бюллетень!

Моя команда и я каждую неделю сообщаем о последних обновлениях алгоритма Google, новостях и советах по SEO.

Полное видео и стенограмма

Примечание от Иоанна 0:33. Я просто хотел кратко поговорить об одном, прежде чем мы перейдем к вопросам. Как вы, наверное, заметили, мы сделали запись в блоге о консоли поиска, некоторых изменениях, которые появятся в консоли поиска. В прошлом году мы начали переходить на новую платформу в поисковой консоли, и для нас, для команды поисковой консоли, это то, над чем они работали в течение довольно долгого времени, и это то, что мы должны более или менее завершить к не позднее конца года. Поэтому наша цель в сообщении в блоге с некоторыми грядущими изменениями — убедиться, что мы проинформируем вас обо всех как можно раньше. Поэтому, когда что-то изменится или исчезнет таким образом, который, по нашему мнению, может повлиять на вас, мы хотим сообщить вам об этом как можно раньше. Я думаю, что изменения всегда немного хлопотны, особенно когда у вас есть процессы, которые работают довольно хорошо, и кто-то уходит и меняет инструменты или данные, предоставленные в инструментах, это всегда немного расстраивает. Таким образом, некоторые из этих изменений мы не можем избежать, некоторые из них, как мы думаем, мы должны были сделать в самом начале, когда мы начинали с поисковой консоли, зная, что теперь, если бы мы знали, то то, что мы знаем сейчас, похоже на каноническое изменение, о котором мы объявили. На этой неделе. Поэтому я понимаю, что иногда это немного разочаровывает, но мы надеемся, что у нас будет довольно хороший путь в будущем, и мы хотим действительно информировать вас заранее и позволить вам попробовать что-то заранее, чтобы вы не слишком удивлялись, когда что-то действительно меняется. У нас также есть много действительно классных вещей, и благодаря переходу на новую платформу и удалению некоторых старых функций у команды появляется гораздо больше времени, чтобы действительно двигаться вперед и создавать новые и модные вещи. Так что хорошо, что вы можете сделать там, если вы твердо уверены в определенных вещах, которые либо исчезают, либо отсутствуют, либо которые вы хотели бы видеть в новом инструменте, обязательно используйте функцию обратной связи в консоли поиска, а не просто перейдите там и скажите, что я действительно этого хочу, но лучше дайте нам некоторую информацию о том, что вы хотели бы увидеть от этого, например, чего вы пытаетесь достичь, используя эту новую функцию или имея то же самое, что и в старом. в новом, потому что предоставление нам немного дополнительной информации помогает нам понять, как нам нужно расставить приоритеты, это то, что мы, возможно, пропустили, что-то, о чем мы должны были подумать раньше. Это что-то, что, возможно, мы можем предложить лучший способ предоставить вам эту информацию или помочь вам сделать то, что мы использовали в старом инструменте. Поэтому не забудьте зайти в инструмент обратной связи, отправьте нам информацию, дайте нам отзыв о том, что, по вашему мнению, вы хотели бы видеть по-другому, некоторые из этих вещей мы сможем сделать, некоторые из них могут занять немного больше времени, потому что нам действительно нужно сначала убрать все эти старые вещи, которые мы накопили за эти годы, и перенести все на новую платформу. Так что для некоторых из них я люблю немного терпения, но это также нормально, чтобы сообщить нам устно, если есть что-то, что вы очень сильно чувствуете, так что не будьте слишком застенчивы.

Вопрос 4:34 - Мы нашли сайт одного из наших клиентов, в том, как они создали сайт, нет текста абзаца, все теги h1 h2 h3 h4. Таким образом, они используют тег заголовка 4 вместо тега P. В своем основном содержании веб-сайта они используют тег заголовка 4 для основного содержимого веб-сайта. Оказывает ли это какое-либо негативное влияние на их рейтинг?

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

Вопрос 7:03 - Мы продолжаем получать случайные неработающие ссылки в консоли поиска. Интересно, что мы должны там делать, перенаправлять их или оставлять как есть?

Ответ 7:15 - Я не знаю, какие случайные неработающие ссылки вы видите там, что может быть чем-то, что можно опубликовать на форуме, чтобы получить совет, но в целом, если вы видите ссылку, указывающую на ваш веб-сайт, который не вообще не работает, тогда можно вернуть 404 для несуществующего URL. Именно для этого предназначен код состояния 404, и с этим хорошо работают наши системы. Так что если есть URL-адрес, который никогда не существовал, верните 404, это прекрасно. С другой стороны, если вы видите, что на ваш веб-сайт ведут ссылки, указывающие на другое место, вы можете догадаться, что они имели в виду, и, возможно, они просто имеют опечатку или лишнюю точку в конце или что-то в этом роде, тогда это может иметь смысл. для перенаправления, особенно когда вы видите, что люди переходят по этим ссылкам, потому что это похоже на то, что кто-то пытается порекомендовать ваш сайт, но не совсем правильно. Поэтому может иметь смысл перенаправить их на правильную страницу. Я думаю, что в обеих этих ситуациях вы также можете немного посмотреть на трафик через эти URL-адреса, если много людей переходят по этим URL-адресам, то это как-то обнадеживает, потому что люди хотят перейти на ваши страницы, тогда это может иметь смысл. выяснить, как определить, что имелось в виду под этой ссылкой и куда я мог ее указать, куда я мог перенаправить людей.

Вопрос 8:56. Какие факторы могут привести к тому, что часть контента, синдицированного на партнерском сайте, будет иметь высокий рейтинг. И это несмотря на то, что канонический настроен на исходный контент на моей стороне и находится там уже несколько месяцев. Это вопрос сайта, ниши или авторитета. Что мы могли там сделать?

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

Вопрос 11:24. Google сообщает о наших страницах продуктов с истекшим сроком действия как программную ошибку 404, поскольку эти URL-адреса перенаправляют на соответствующие альтернативные продукты с сообщением о том, что продукт, который они хотели, недоступен. Является ли перенаправление причиной ошибки 404 или содержимого страницы перенаправления?

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

Вопрос 12:32. Сколько времени требуется Google, чтобы распознать теги Hreflang? Возможно ли, что Google сначала индексирует из Швейцарии и показывает CH-версию веб-сайта под немецким TLD?

Ответ 13:02. Таким образом, мы на самом деле не индексируем в первую очередь контент из Швейцарии, наши поисковые роботы и наши системы больше расположены в США, чем в Швейцарии. Поэтому я не думаю, что мы будем отдавать предпочтение швейцарскому контенту над другим контентом, но то, что происходит со ссылками hrefLang, в целом представляет собой своего рода многоэтапный процесс. Сначала нам нужно просканировать и проиндексировать эти разные версии страницы. Затем мы должны проиндексировать их с тем же URL-адресом, который вы указали в разметке hreflang, а затем нам нужно иметь возможность следовать этой разметке hreflang между этими разными версиями страницы, и для этого нам также необходимо получить это подтверждение. . Так что это занимает немного больше времени, чем обычное сканирование и индексирование, мы должны как бы понять сеть между этими разными страницами, которые все должны быть частью этого набора страниц hreflang. Так что это то, что для нас, вероятно, нормально, я не знаю, может быть, в два-три раза дольше, чем мы просто сканируем и индексируем отдельную страницу, чтобы мы могли понять связь между версиями hreflang. Опять же, нет никакого предпочтения Швейцарии перед другими странами Европы. Я думаю, что это было бы хорошо только для меня лично с какой-то эгоистической точки зрения, но это не имело бы смысла в глобальном масштабе в целом. Мы стараемся относиться ко всем веб-сайтам одинаково. Так что только потому, что веб-сайт имеет версию CH, не означает, что он автоматически будет ранжироваться выше немецкой версии. Итак, другая вещь с hreflang заключается в том, что по большей части он не меняет рейтинг, а просто меняет URL-адреса.

Вопрос 15:12 - Недавно я изменил домен своего сайта с этого на другой с 301 переадресацией. Инициировано изменение адреса, я все еще вижу старые URL-адреса, и прошло более трех недель, это нормально? У меня были некоторые проблемы с 301, которые не были активны в течение недели после миграции, но теперь они активны. По некоторым запросам в результатах поиска отображаются как старый, так и новый сайт. Что я мог сделать здесь по-другому?

Ответ 15:46. Таким образом, перенаправление 301 — это действительно то, на что вам следует обратить внимание. Для нас важно, чтобы редирект 301 был постраничным. Таким образом, все старые страницы перенаправляются на одну и ту же страницу на новом веб-сайте. У нас есть все, что описано в нашей информации в Справочном центре для перемещений сайта, поэтому я бы дважды проверил это и как бы прошел шаг за шагом и URL-адрес, даже чтобы увидеть, что это действительно работает так, как должно работать. . Еще одна вещь, о которой следует помнить, это то, что мы сканируем и индексируем URL-адреса по отдельности. Таким образом, мы не сканируем весь веб-сайт сразу, а затем переключаемся, мы делаем это шаг за шагом, и некоторые из этих страниц сканируются и индексируются очень быстро в течение нескольких часов, некоторые из них требуют гораздо больше времени для повторного сканирования. просканированы и переиндексированы, и это может занять несколько месяцев. Так что это может сыграть свою роль и здесь, где, возможно, у нас просто не было возможности просканировать, проиндексировать и обработать перенаправление для всех этих страниц, так что некоторые из них мы видели только на старом веб-сайте. и некоторые, которые мы уже видели на новом. Это может сыграть свою роль и здесь, особенно если вы смотрите на период в три или четыре недели, и это было бы нормально, и, наконец, то, что также немного играет в этом, это то, что оптимизаторы и веб-мастера находят действительно запутанным. что даже после того, как мы обработали это перенаправление, если кто-то явно ищет старый URL-адрес, мы покажем им старый URL-адрес. Так что это немного сбивает с толку, наши системы пытаются быть полезными здесь и говорят, что мы знаем, что этот старый URL-адрес существовал раньше, и у нас есть новый контент, но мы покажем его вам, потому что, возможно, это то, что вы ищете. Так, например, если вы делаете запрос сайта для старого URL-адреса, даже, возможно, здесь после перемещения вашего сайта, мы все еще можем показать вам некоторые URL-адреса с вашего старого веб-сайта с запросом сайта, даже если мы уже обработали перенаправление для этих URL-адресов. . Поэтому, когда вы, например, измените имя своего сайта, вы увидите в запросе сайта старые URL-адреса с новым именем сайта, которое там упоминается, и, с нашей точки зрения, это работает так, как предполагалось, мы пытаемся помочь средний пользователь, который ищет URL. Для веб-мастера, который только что переместил сайт, это немного сбивает с толку. Так что я не знаю, будем ли мы что-то менять, но в целом я думаю, что это имеет смысл.

Вопрос 21:46 - Как поисковый бот Google рассматривает персонализацию веб-сайта? У нас есть новый уровень продукта, который веб-сайт позволяет персонализировать в зависимости от отраслевой принадлежности даже для одной компании, что позволяет нам действительно настраивать контент.

Ответ 22:12. Я думаю, что мы рассмотрели это в последний раз, но просто для того, чтобы дать быстрый ответ, важная часть заключается в том, что Googlebot в основном сканирует из США. Поэтому, если вы предоставляете разный контент в разные страны, робот Googlebot, вероятно, увидит только версию контента для США. Мы не сможем индексировать разные версии контента для разных местоположений. Поэтому, если есть что-то, что вы хотите проиндексировать, убедитесь, что оно находится в общей части вашего веб-сайта, чтобы робот Googlebot мог это подобрать. Вы можете использовать персонализацию, чтобы добавить дополнительную информацию по всей странице, но если вы хотите, чтобы что-то индексировалось, это должно быть в той части страницы, которая не связана с персонализацией.

Вопрос 22:59. Мне интересно, насколько очень низкая производительность в web.div влияет на ранжирование веб-сайта в Google?

Ответ 23:06 - Не знаю. Таким образом, web.dev — это действительно классный инструмент, который объединяет различные тесты, которые мы проводим в Lighthouse, и дает вам оценки по ним, а также как бы помогает вам в процессе улучшения этих оценок. Поэтому, когда дело доходит до скорости, вам нужно следить за вещами, которые вы могли бы попробовать, и с течением времени он отслеживает прогресс вашего веб-сайта и вроде того, как вы просматриваете другой контент, который есть в инструменте. Так что это то, что я считаю хорошей практикой, которую нужно пройти и отработать, но это также и то, чему стоит следовать, но это не означает, что они автоматически приведут к более высокому рейтингу. Точно так же, если у вас здесь низкие баллы, это не означает, что ваш сайт ужасно ранжируется, потому что он не следует лучшим практикам. Таким образом, есть своего рода аспект, с одной стороны, если ваш веб-сайт настолько плох, что мы вообще не можем правильно его проиндексировать, что может иметь место, например, с очень низким показателем SEO в маяке, когда мы не можем получить доступ к URL-адресам или на этой странице нет URL-адресов, и это просто оболочка JavaScript, для которой мы не можем обработать JavaScript. Что я могу серьезно повлиять на ваш SEO, но, с другой стороны, если ваш сайт немного медленный или не идеально оптимизирован, я не знаю, окажет ли это значительное влияние на ваш сайт. Поэтому я рекомендую вам ознакомиться с советами, которые даются в таких инструментах, как web.dev, и подумать о том, что вы можете реализовать, подумать о частях, которые, по вашему мнению, важны для вашего веб-сайта, с одной стороны, для поисковых систем, конечно, если вы спрашивая об этом здесь, с другой стороны, также и для ваших пользователей, потому что, в конечном счете, если вы делаете что-то, что улучшает жизнь ваших пользователей, это будет иметь своего рода долгосрочный эффект просачивания и на остальную часть вашего сайта.

Вопрос 26:58. Может ли Google решить, показывать ли информацию о структурированной организации данных.

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

Вопрос 28:31 - Вопрос относительно структуры веб-сайта и многоязычной мультирегиональной конфигурации. Следует ли мне беспокоиться о настройке параметров URL-адреса при разделении доменов по папкам на отдельные службы в консоли поиска.

Ответ 28:52 - Итак, я думаю, с одной стороны, я думаю, что это хорошо, что вы изучаете такие проблемы, с другой стороны, я немного беспокоюсь, что у вас будут разные конфигурации для веб-сайта по подкаталогу, потому что это звучит например, возможно, вы не делаете что-то чистое с конфигурационными параметрами URL в целом на веб-сайте. Так что здесь что-то есть, я не знаю, какой именно веб-сайт здесь, поэтому действительно трудно сказать, но похоже, что у вас есть разные параметры, которые означают разные вещи или которые можно игнорировать или которые не следует игнорировать в зависимости от индивидуальный вид подкаталога на вашем сайте. С одной стороны, это должно быть возможно, мы должны быть в состоянии справиться с этим, с другой стороны, если есть ситуации, когда мы можем полностью игнорировать отдельные параметры URL, а в других случаях, когда эти точно такие же параметры имеют решающее значение для контента, тогда это кажется например, когда наши алгоритмы могут запутаться и сказать, ну, нам всегда нужно сохранять эти параметры или нам никогда не нужно сохранять эти параметры, а затем вдруг часть вашего контента отсутствует или часть вашего контента индексируется несколько раз. Таким образом, использование инструмента параметров URL-адресов определенно помогает нам в подобном случае, но мне кажется, что, вероятно, было бы более разумно попытаться очистить эти параметры URL-адресов в целом и найти способ иметь согласованную структуру для URL-адресов ваших веб-сайтов, поэтому что алгоритмы не должны угадывать, что алгоритмы не должны вычислять, О, в этом конкретном пути этот параметр важен, а в этих других путях мы можем его игнорировать. Каждый раз, когда вы добавляете столько дополнительных сложностей к сканированию и индексированию веб-сайта, вы как бы сталкиваетесь с ситуацией, когда что-то может пойти не так. Таким образом, чем проще вы сможете сохранить его, чем чище вы сможете его сохранить, чем проще и чем проще вы сможете сохранить его в своей структуре URL-адреса, тем больше вероятность того, что мы сможем просканировать и проиндексировать этот сайт, не задумываясь дважды, и как всегда. есть и другие поисковые системы, у них нет инструмента настройки URL. Что данные, которые у нас есть, поэтому они не смогут их увидеть, и вы можете вызвать проблемы в этих других поисковых системах, или, возможно, это также играет роль в том, как ваш контент распространяется в социальных сетях. Так что все эти вещи как бы вступают в игру здесь. Моя общая рекомендация заключается в том, чтобы не тратить слишком много времени на то, чтобы настроить инструмент обработки параметров URL для всех этих различных подкаталогов, а потратить это время на размышления о том, что вы хотели бы иметь в качестве URL-адреса. структуру в долгосрочной перспективе и подумать о шагах, которые вам понадобятся, чтобы перейти к этой более чистой структуре URL.

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

Ответ 33:04. В общем, я думаю, что здесь происходит то, что по каким-то причинам наши алгоритмы считают, что эти страницы эквивалентны и что мы можем сложить их вместе, и поэтому мы выбираем каноническую страницу с одной из этих страниц, и она выглядит например, просмотр страниц вручную в браузере, что на самом деле это совершенно разные страницы, поэтому складывать их вместе не имеет смысла, поэтому выбор канонического из этого ресурса также не имеет смысла. Одна из вещей, которые я видел в прошлом, приводила к чему-то подобному, когда мы не могли правильно отобразить контент. Когда мы не можем на самом деле получить доступ к содержимому должным образом, когда мы в основном видим пустую страницу, мы говорим, ну, это то же самое, что и другая пустая страница, которую мы видели, может быть, мы можем сложить их вместе. Так что навскидку я бы взял это направление, чтобы подумать о том, как Google думает, что эти страницы эквивалентны, возможно ли, что, возможно, в тесте на удобство для мобильных устройств у них нет фактического контента. Может быть, я показываю межстраничное объявление для робота Googlebot, и только это межстраничное объявление индексируется, что здесь может происходить? У меня пока не было возможности подробно изучить это здесь, так что может быть, что-то подобное происходит с вашей стороны, может быть, что-то странное происходит с нашей стороны, и нам нужно это исправить, но это мило направления, которое я бы взял в случае, как это.

Вопрос 34:41. Я хочу немного лучше ориентироваться для своих клиентов на своем веб-сайте. Я хочу убедиться, что это не смутит Google. Я хотел бы настроить свою структуру URL-адресов так, чтобы домен, затем категория, а затем продукт в пути, или, может быть, я настроил его по-другому, что мне делать, какую структуру URL-адресов выбрать?

Ответ 35:13 - С нашей точки зрения, вы можете использовать любую структуру URL. Поэтому, если вы используете своего рода структуру подкаталога поддомена пути, это совершенно нормально, для нас важно, чтобы мы не убегали в бесконечные пространства. So if you use URL rewriting on your server that it's not the case that you can just add like the last item in your URL and just continue adding that multiple times and just it always shows the same content but it should be a clean URL structure where we can crawl from one URL to the other without getting lost in infinite spaces along the way. You can use your URL parameters if you want but if you do decide to use your URL parameters like I mentioned in one of the previous questions try to keep it within a reasonable bound. So that we don't again run off into infinite spaces where lots of URLs lead to the same content but whether or not you put the product first or the category first or you use an ID for the category or write out the category as text that's totally up to you. That doesn't have to be a line between your ecommerce site on your blog that can be completely different on both of these. So I think it's good to look at this but on the other hand I lose too much sleep over this and rather define the URL structure that works for you in the long run in particular one that you don't think you need to change in the future. So try not to get too narrow down and pick something that works for you, works for your website.

Question 37:43 - We're developing an application for angular Universal with some sections we want to change the appearance of the URLs in the browser but keep it the same on the server side. So for the server it would be luxury goods leather bags but the user would see just leather bags. Is there any problem with this in angular Universal using dynamic rendering?

Answer 38:08- So just from from a practical point of view Googlebot doesn't care what you do on the server you can track that however you want on your server. The important part for us is that we have separate URLs for separate pages that we have links that Googlebot can click on that are in kind of a elements with an href pointing to a URL that we can follow and that we can access these URLs without any history is with them. So if we take one URL from your website we can copy and paste it into an incognito browser and it should be able to load that content and if it loads that content if you have proper links between those pages then from our point of view how you handle that on your server is totally up to you. Using angular Universal with dynamic rendering or if you have something of your own that you set up that's all totally up to you that's not something that we would care about. It's not something we would even see because we see the HTML that you serve us and the URLs that you serve us.

Question 39:18 - My website fetches individual web pages which are not interlinked through an API but no links are displayed through clicks. It has a search box where every individual page shows search results is Google is successfully crawling all links as valid via sitemap does Google see this is a valid practice because links and millions will harm rankings or increase ranking.

Question 39:48 - So there are lots of aspects in this question where I say this sounds kind of iffy there is some things that sound kind of ok. So if Google is already indexing these pages then something is working out right. In general I I'd be careful to avoid setting up a situation where normal website navigation doesn't work. So we should be able to crawl from one URL to any other URL on your website just by following the links on the page. If that's not possible then we lose a lot of context. So if we're only seeing these URLs through your sitemap file then we don't really know how these URLs are related to each other and it makes it really hard for us to be able to understand how relevant is this piece of content in the context of your website, in the context of the whole web. So that's that's one thing to kind of watch out for and the other thing to watch out for. The other thing too watch out for I think is if you're talking about millions of pages that you're generating through an API with a search box and just so many of those via sitemap files. I may be kind of cautious there with regards to the quality of the content that you're providing there. So in particular if you have like product feeds if you're using RSS feeds to generate these pages, if you're doing anything to automatically pull content from other websites or from other sources and just kind of republishing that on your site then that's something where I could imagine our quality algorithms maybe not being so happy with that. Similarly if this is all really completely republished from other web sites I could imagine the web spam team taking a look at that as well and saying well why should we even index any of this content because we already have all of the content indexed from from the original sources. Like what is the value that your website is providing that the rest of the web is not providing. So that's one thing to kind of watch out for. I don't want to kind of suggest that your website is spammy I haven't seen your website but it is something that we do see a lot and it's something where as a developer you go, oh I have all of these sources and I can create code therefore I can combine all of these sources and create HTML pages and now have a really large website without doing a lot of work, and that's really tempting and lots of people do that, lots of people also buy frameworks that do this for you but it doesn't mean that you're creating a good website. It doesn't mean that you're creating something that Google will look at and say oh this is just what we've been waiting for we will index it and ranked it number one for all of these queries. So it might mean that it looks like very little work in the beginning because you could just combine all of these things but in the end you spend all this time working on your website when actually you're not providing anything of value then you end up starting over again and trying to create something new again. So it looks tempting to save a lot of work in the beginning but in the long run you basically lose that time. So it might make more sense to figure out how can you provide significant value of your own on your website in a way that isn't available from other sites.

Question 43:34 - We're facing an issue where lots of resources couldn't load through the to the same page not getting rendered in the snapshot for Googlebot while debugging these issues we couldn't find a solution and Google is marking them as other error. What could that be?

Answer 43:51 - So this is also a fairly common question what is essentially happening here is we're making a trade-off between a testing tool and the actual indexing and within the testing tool we try to get information as quickly as possible directly from your server but at the same time we also want to give you an answer fairly reasonably quickly so that you can see what is happening. What what tends to happen here is if you have a lot of resources on your pages that need to be loaded in order for your page to load then it could happen that our systems essentially timeout and we try to fetch all of these embedded resources but we don't have enough time because we want to provide an answer to you as quickly as possible. So you end up seeing these embedded resources not being pulled and you see an error in the live rendering of the page like that. When it comes to indexing our systems are quite a bit more complex though we cache a lot of these resources. So if we try to index an HTML page we'll know all of these CSS files we've seen before we can just pull them out of our cache we don't have to fetch them again we can render those pages normally and that just works. One thing you can do or maybe they're two you can do to to kind of help improve that for the testing tool and for users in general. On the one hand you can reduce the number of embedded resources that are required on your pages. So instead of having a hundred CSS files you've you kind of throw them into the tool you create one CSS file out of that that's one thing that you can do that makes sense for both users and for search engines. You can do that for JavaScript as well you can minify the JavaScript you can combine things and kind of make packages rather than individual files I think that's a good approach. The other thing is if you're seeing this happening for your pages and you don't have a lot of embedded content then that's kind of a hint that your server is a bit slow and that we can't kind of fetch enough content from your server to actually make this work. So that might be a chance to look at your server your network connectivity and to think about what you can do to make that a little bit faster so that these tools don't time out so that it's also faster for users as well. So in both of these cases the net effect is that users will mostly be seeing the speed improvement but the side effect will also be that you'll be able to use these tools a little bit better because they tend not to time out as much.

So what what I would do there is try to use some other tools to figure out is this really a problem on your side somehow that things are a little bit slow or is this something just on Google side that we we tend not to have as much time to fetch all of these individual resources so what you could do is use the the chrome developer tools what is it the network tab that you have there and to figure out like how many of these resources are being loaded how long does it take you can use webpagetest.org it also creates a kind of a waterfall diagram for your content also listing the the time that it takes for those test URLs and the size of the resources that were to return and by using those two you can kind of figure out is is it the case that it just takes 20 seconds to load my page with all of the embedded content with all of the high resolution images or is it the case that these testing tools say my page loads in 3 or 4 seconds with all of the embedded content therefore it's probably more an issue on Google side I don't have to worry about it.

Question 53:46 - I've noticed as a result of the last several updates that have been coined the the medic update. I've seen some websites that no longer show on the first page of search results for their own company, for their own brand, and I was wondering why in general what would that be?

Answer 54:35 - I think that's that's always a bit tricky there usually are two aspects that are involved there. One is more an issue especially with newer websites where the website name or the company name is more like a generic query. So if for example the the website's name is “ Best Lawyers in Pittsburgh” or something like that. Then on the one hand that might be the company name, on the other hand if someone were to type that into search, we would probably assume that they're not looking for that specific company but rather they're looking for information for that query. So that's especially with newer companies that's something that we see every now and then. We see that the forums or people there saying, oh I'm not ranking for my domain name, and then their domain name is something like I don't know best VPN providers.com it's like well, it's a domain name but it doesn't mean that you will rank for for that query. So that's one thing when it comes to sites that are a little bit more established that are out there already usually it's more a sign that we just don't really trust that website as much anymore. So that's something where we might recognize that actually people are searching for this company but we feel maybe the company website itself is not the most relevant result here, maybe we feel that there is kind of auxiliary information about that company which is more important that users see first where which could result in something like this happening. Usually that that's more a matter of things kind of shuffling around on the first one or two pages in the search results. It would be really rare that that's something like that would result in a website not showing up at all the first couple pages of the search results. I think that's that's kind of what you highlighted there with your question and that's something where I think well, even if we didn't trust this website as much anymore then we should at least have it somewhere in the search results because if we can tell that someone is explicitly looking for that website it would be a disservice for the user to not show it at all. Like for maybe for generic queries one could argue maybe it's not the perfect result but if we can tell that they're really looking for that website at least we should give the user a chance to see that website as well. So that's kind of why I took that and said well maybe we should be catching this a little bit better and II don't know if our algorithms are correctly kind of understanding how trustworthy your website there would be. I don't know the website so that's really hard for me to judge but even if we think that it wasn't trustworthy at all maybe we should still show it somewhere in the search results on the first page. The other thing to maybe look at if you haven't done so already is look at look at the quality rater guidelines that we have and there's a lot of information about kind of trustworthiness in there. Some of that is worth taking with a grain of salt it's not that we take that kind of one-to-one and use that as a ranking factor but there there are a lot of ideas in there especially when you're talking about a topic that's a kind of legal website or medical website then it does make sense to show users like why are you providing this information why should they trust you.