22 января 2019 г. – Google Help Hangout Notes

На этой неделе Джон находится в Нью-Йорке, в Нью-Йорке. К IRL присоединились слева направо Мартин Сплитт из команды Java Script в Google, Крис Лав, Лили Рэй, Мари Хейнс, Дэйв Минчала и Квасон Картер. На этой неделе было несколько отличных вопросов о Cloudfare, The QRG и The New Page Speed ​​Tool. Ссылка на видео и полную расшифровку можно найти ниже!

Cloudflare иногда блокирует робота Googlebot?

7:58

«Да, я не знаю, как это работает с Cloudflare на данный момент, но я знаю, что в прошлом они блокировали людей, которые подделывают Googlebot. Лягушка или что-то в этом роде. Вы говорите, что я использую пользовательский агент Googlebot, тогда они заблокируют это, потому что они могут сказать, что это незаконный робот Google. Мы можем это заблокировать. Но по большей части, я думаю, они достаточно практики, чтобы распознавать обычных роботов Googlebot и позволять им нормально сканировать».

Резюме: Иногда при тестировании может показаться, что Cloudflare блокирует робота Googlebot. Скорее всего, здесь происходит то, что Cloudflare блокирует людей, которые выдают себя за Googlebot. Таким образом, если вы используете такой инструмент, как Screaming Frog, и выбираете Googlebot в качестве пользовательского агента, вы не сможете сканировать сайты с помощью Cloudflare .

Могут ли неестественные ссылки по-прежнему вредить сайту алгоритмически? Если да, может ли помочь инструмент дезавуирования?

14:01

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

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

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

Резюме: если у вас есть ссылки, специально созданные для SEO, а их у вас много, они могут привести к тому, что алгоритмы Google не будут доверять всем вашим ссылкам. В таких случаях лучше дезавуировать.

Как алгоритмы Google измеряют EAT издателей?

33:40

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

Резюме: существует множество «мягких факторов качества», на которые обращает внимание Google. Посмотрите на вещи с точки зрения пользователя. Кроме того, авторская разметка может помочь Google лучше понять ситуацию.

Если что-то есть в Руководстве для оценщиков качества, разумно ли предположить, что Google хочет, чтобы это было отражено в их алгоритмах?

34:44

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

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

Существует ли схема, помогающая сайтам появляться выше в результатах голосового поиска?

36:10

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

Резюме: Пока еще не во всех географических точках используется голосовая разметка. Но это хорошее место для начала.

Несколько советов, как выиграть избранные сниппеты

38:03

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

Резюме: нет никакой разметки, которую вы можете добавить, чтобы получить избранный фрагмент. Но хорошее использование тегов h и обычных HTML-таблиц действительно может помочь.

Следует ли добавлять схему местоположения на все страницы?

50:47

Ответ 51:42 - Насколько я знаю, это просто домашняя страница. Я не знаю. Кто-нибудь из вас знает?

Ответ от Лиз 51:4 7 - Обычно это должна быть только одна страница с организационными и корпоративными. Это вообще рекомендация.

МАРТИН СПЛИТТ 52:00 - Я думаю, не имеет значения, какие... не так важно, какие страницы, точно так же, как не помещайте это на каждую страницу, которая у вас есть, я думаю, это более важная часть. Я думаю, это зависит от... если вы новостной сайт, вероятно, имеет смысл разместить его на странице контактов, или на странице «О нас», или что-то в этом роде. В то время как на веб-сайте магазина или ресторана, вероятно, можно разместить его на главной странице.

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

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

Почему новый инструмент PageSpeed ​​Insights, основанный на Lighthouse, намного жестче при оценке веб-сайтов?

53:05

Мари Хейнс: Это не мой вопрос, но чтобы дать некоторый контекст, новые данные Lighthouse для скорости страницы намного более жесткие, чем раньше были Page Speed ​​Insights. Таким образом, то, что имеет оценку около 80 в Page Speed ​​Insights, может быть красным 29 в Lighthouse. Так что это хороший вопрос. Может ли это быть причиной... потому что мы знаем, что на мобильных устройствах очень медленные сайты могут быть понижены в должности. Итак, хорошо ли, если мы скажем, знаете ли, что если вы оказались в минусе на тесте Маяка, что мы действительно должны улучшить ситуацию, потому что это может привести к понижению в должности, или есть отсечка?

Ответ 54:07. Таким образом, у нас нет однозначного сопоставления внешних инструментов и всего, что мы используем для социальных сетей. Да, из-за этого действительно трудно сказать, но в поиске мы пытаемся использовать сочетание фактических, что это такое, данных лабораторных испытаний, что-то вроде теста Lighthouse, и данных отчета Chrome UX, где, по сути, что мы измеряем то, что увидят пользователи веб-сайта.

МАРТИН СПЛИТТ 55:37 . Также важно отметить, что Lighthouse, например, специально измеряет 3G-соединение на срединном конце — или как телефон средней производительности, да. Таким образом, в основном, если вы используете недавний Apple McIntosh или недавний быстрый компьютер с Windows с действительно хорошим проводным соединением или действительно хорошим соединением Wi-Fi в вашем офисе, конечно, вы видите время загрузки в две секунды, но реальный пользователь со своим телефоном в дикой природе, вероятно, этого не видит. Так что это один из таких случаев, когда никогда не помешает сделать ваш сайт быстрее, но это очень, очень сложно сказать, как это будет выглядеть с внутренней точки зрения, поскольку мы используем очень конкретные показатели, которые не обязательно сопоставляют один с другим. один к тому, что выявляют инструменты... конечно, важно это исправить, потому что вы не хотите, чтобы ваши пользователи ждали на вашем сайте вечно. Это причинит тебе боль. Это навредит вашим пользователям. Это только повредит вам в поиске. Но я не плачу - я бы сказал, просто посмотрите на инструменты. Если инструменты говорят вам, что у вас все хорошо, то вам не следует слишком беспокоиться об этом. Если инструменты говорят вам, что вы на самом деле не очень хорошо работаете, то я думаю, что время, потраченное на выяснение того, почему оно говорит, например, если то, что оно говорит, актуально, оно потрачено впустую. Вам лучше подумать о том, чтобы сделать сайт быстрее.

Мобильная производительность — очень важный фактор для ваших пользователей, как и для всего остального. Поэтому я бы сказал, убедитесь, что ваш сайт хорошо работает в реальных условиях. Может быть, даже купить дешевый телефон и попробовать веб-сайт время от времени, и если... это то, что мне нравится делать, и я делал это до того, как присоединился к Google с командой разработчиков, с которой я работал. Я такой: смотри, ты хочешь использовать этот сайт на этом телефоне? Это было как, о, это ужасно. Я такой, ммм, да, так что, может быть, нам стоит что-то с этим сделать.

ДЖОН. В Chrome можно настроить и попробовать разные скорости соединения. Мобильный эмулятор. Я думаю, что это действительно хорошие вещи, на которые стоит обратить внимание, а также посмотреть на свою пользовательскую базу. Посмотрите на свои аналитические данные, если вы видите, что люди используют ваш веб-сайт только с iPhone высокого класса, тогда, возможно, это не такая проблема, как если вы видите, что люди подключаются к вашему сайту из случайных сельских соединений, которые медленные, и у них есть бюджетные устройства, то, возможно, это больше.

Резюме: Lighthouse измеряет скорость соединения 3G, поэтому большинство сайтов будут работать намного быстрее, чем указано здесь для большинства сеансов. Примечание. После того, как эта видеовстреча была завершена, Мартин продолжил, что это «первая содержательная краска», которая наиболее важна в отношении потенциального понижения рейтинга.

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

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

Видео и полная стенограмма

Вопрос 1:32. Мне интересно, есть ли у вас какие-либо дополнительные рекомендации или точки зрения на тестирование таким образом, чтобы SEO-специалисты могли быть более точными и более уверенными в отчетах для бизнеса. Мы попробовали эту штуку, и она произвела впечатление. И мы сделали это безошибочно, вроде того, что рекомендовал бы Google.

Ответ 3:20 . Итак, с моей точки зрения, я стараюсь отделять более технические вещи от качественных изменений. Так что все, что является чисто технической вещью, вы можете в значительной степени проверить, работает оно или нет. Дело не в том, работает это или нет, а в том, что многие из этих технических вещей, особенно когда вы смотрите на рендеринг или когда вы смотрите, может ли Google действительно проиндексировать этот контент, это то, что либо работает, либо нет. Трудности возникают во всем, о чем идет речь — это проиндексировано, но как это отображается в рейтингах? И я думаю, что для многих из них нет абсолютного способа действительно проверить это. Потому что, если вы протестируете это в изолированной ситуации, например, создадите тестовый сайт и настроите его с любыми рекомендациями, которые у вас есть, вы не можете предположить, что тестовый сайт будет работать так же, как обычный веб-сайт. Иногда бывают простые вещи, например, если это тестовая площадка, то, возможно, мы не будем делать полный рендеринг, потому что считаем, что нет смысла тратить столько времени на это и это, потому что, типа, никто не смотрит на это. Это никогда не отображается в результатах поиска, почему мы должны тратить столько ресурсов на это? Принимая во внимание, что если бы вы сделали это на обычном веб-сайте, это работало бы совсем по-другому. Так что это то, где у меня действительно нет четкого руководства о том, что вы должны делать или что вы не должны делать. Это больше похоже на то, когда вы смотрите на общие тенденции, когда вы видите, что веб-сайт появляется, на изменения в рейтинге, которые вы видите для этих запросов, и пытаетесь применить лучшие практики.

Вопрос 5:21 . Так что, может быть, если... конкретный пример, возможно, вы можете использовать его, чтобы... может быть, это было бы полезно, что-то вроде теста тега заголовка, верно? Если бы вы делали это... что, если вообще что-то, нам следует искать? Или есть что-то, на что можно обратить внимание — это связано с нашим тестом или это связано с чем-то, что изменилось в сервере, алгоритме, конкурентной динамике? [СМЕХ] Предполагая, что мы делаем другие вещи, чтобы посмотреть на эти внешние эффекты.

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

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

Вопрос 7:58 - У меня более прямой вопрос. Итак, вы знаете, что ряд наших сайтов используют Cloudflare, и мы заметили, что они напрямую блокируют робота Googlebot, верно? Но это не оказало большого влияния на наши рейтинги, на нашу видимость и так далее. Так что пытаемся понять, как вы, ребята, используете другого бота для обхода индекса напрямую вне робота Googlebot, и как мы должны думать об этом, когда CDN изо всех сил пытаются заблокировать бота?

Ответ 8:33 . Да, я не знаю, как это работает с Cloudflare на данный момент, но я знаю, что в прошлом они блокировали людей, которые подделывали Googlebot. Так что, если вы используете, например, свой собственный, я не знаю, Screaming Frog или что-то в этом роде — вы говорите, что я использую пользовательский агент Googlebot, тогда они заблокируют это, потому что они могут сказать, что это незаконный Googlebot. Мы можем заблокировать это. Но по большей части, я думаю, у них достаточно практики, чтобы распознавать обычных роботов Google и позволять им нормально сканировать.

Вопрос 9:02 - Да, было интересно. Потому что связались с кучей коллег из других агентств, и они повторяли подобные ситуации даже на своем сайте. Например, в Cloudflare был запрос в службу поддержки, который также блокировался, когда я просто пытался выполнить рендеринг напрямую с Googlebot или смартфона Googlebot.

Ответ 9:21 - Хорошо, да. Ну, у нас нет никаких обходных путей. Например, если веб-сайты блокируют нас, мы как бы застряли. Но обычно, если такая служба, как Cloudflare, блокирует нас по умолчанию, это влияет на многие веб-сайты. И мы бы это заметили. Мы, вероятно, обратились бы к Cloudflare по поводу чего-то подобного. Возможно, у них разные уровни обслуживания. Так что если вы на нижнем уровне, то это как бесплатный сервис, но у нас есть ограничение по количеству трафика. Не знаю, есть ли у них что-то подобное. Это то, что я видел у некоторых других хостеров, где, если у вас настроен бесплатный хостинг по умолчанию, то иногда они просто ограничивают трафик и блокируют вещи.

МАРТИН СПЛИТТ: Возможно, вы не сразу увидите это в статистике, исходя из вашего рейтинга и прочего. Потому что в основном, если у нас есть контент от вас, и в основном веб-сайт не... в зависимости от того, что в данном случае означает блокировка, потому что я этого не видел. И я управляю несколькими веб-сайтами за Cloudflare, и у меня не было никаких проблем. Но опять же, у меня нет гигантского веб-сайта и мне не нравится огромное количество трафика, потому что я пользуюсь бесплатным планом. Это... но если вы не обнаружите ошибку с нашей стороны, это... может быть, мы просто сохраняем контент, который мы видели в последний раз. И это просто хорошо ранжируется, и это нормально.

Ответ 12:09 - Да, поэтому я думаю, что в случае, подобном вашему, мы бы замедлили сканирование. И мы попытались бы сохранить контент, который мы можем получить, в индексе, и мы просто немного дольше сканировали бы его. Но это также означает, что если вы внесете изменения на свой веб-сайт, нам потребуется больше времени, чтобы их принять. Если нам придется значительно пересканировать что-то, например, я не знаю, AMP, или вы добавите что-то такое или это по всему сайту, то все это займет намного больше времени. Так что, если вы действительно регулярно видите, что мы не можем сканировать с помощью обычного робота Googlebot, то я обсужу это с хостом, чтобы мы могли видеть.

Вопрос 14:01 - Отлично. Итак , у меня есть вопрос об инструменте дезавуирования. Таким образом, мы все время получаем людей, которые хотят, чтобы мы проводили аудит ссылок. И начиная с Penguin 4.0, то есть в сентябре 2016 года, когда Гэри Иллиес сказал, и я думаю, вы тоже сказали, что Google довольно хорошо игнорирует неестественные ссылки. Поэтому в то время я думал, что нам не нужно использовать инструмент отклонения, чтобы просить Google игнорировать ссылки, которые они уже игнорируют, если только у вас не было ручных действий для неестественных ссылок. Таким образом, мы рекомендуем его только для сайтов, которые, знаете ли, активно создают ссылки, пытаются манипулировать вещами, вещами, которые являются неестественными ссылками. Но я думаю, что среди веб-мастеров так много путаницы, потому что я все время вижу, как люди берут кучу денег за аудит... чтобы дезавуировать ссылки, которые просто... Я знаю, что их игнорируют. Так что я был бы рад, если бы у нас было немного больше разъяснений. Так что, может быть, если я могу привести вам пример, например, если бы был владелец бизнеса, который несколько лет назад нанял SEO-компанию, и эта SEO-компания сделала кучу гостевых постов только для ссылок и, ну, вы знаете, что такое был среднего качества, если вы понимаете, что я имею в виду, не сверхспам, можем ли мы быть уверены, что Google игнорирует эти ссылки? Или мы должны пойти и дезавуировать?

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

Вопрос 16:43 - И я предполагаю, что вы, вероятно, не можете ответить на этот вопрос, но есть ли какой-нибудь способ, например, скажем, мы не получили ручного действия, или они не получили ручного действия. Могут ли эти ссылки повредить им алгоритмически? Потому что мы чувствуем, что видим некоторые улучшения на некоторых сайтах после дезавуирования. Итак, опять же, я знаю, что это всегда... это никогда не бывает черно-белым.

Ответ 17:03 - Это определенно может быть так. Итак, когда наши алгоритмы смотрят на это, они видят, о, здесь куча действительно плохих ссылок, тогда, возможно, они будут немного более осторожными в отношении ссылок в целом для веб-сайта. Так что, если вы очистите это, алгоритмы посмотрят на это и скажут: «О, это вроде как — все в порядке». Это не плохо.

Вопрос 17:24 . По-прежнему полезно дезавуировать только для предотвращения ручного действия, верно?

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

Вопрос 17:37 — Так что хорошо думать, как в Google — как кто-то из команды Google по борьбе со спамом просто думает, типа, знаете, если они увидят это, что они сделают, если сделают?

Ответ 17:47 - Да.

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

Ответ 18:22 - Да, я думаю, что для подавляющего большинства сайтов это нормальное сочетание вещей, когда вы как будто следовали какому-то плохому совету в прошлом, и как будто вы пошли дальше, и теперь все довольно естественно, тогда им действительно не нужно этого делать. Это своего рода цель всего этого, и именно поэтому инструмент отклонения не похож на основную функцию в Search Console. Вы как бы ищете это явно. Все это сделано специально, потому что для большинства сайтов вам действительно не нужно уделять много внимания ссылкам. Что мне нравится в инструменте дезавуирования, так это то, что если вы беспокоитесь об этом, вы все равно можете пойти туда и сказать: «Хорошо, я знаю, что есть несколько вещей, которые мы сделали за пару лет. назад, и я очень беспокоюсь об этом. Тогда дезавуировать их, с моей точки зрения, не проблема. Я бы не стал специально искать все это. Но если вы знаете об этом и действительно беспокоитесь об этом, то вы можете как-то позаботиться об этом.

Вопрос 19:27 . У меня есть вопрос об одном из наших клиентских веб-сайтов. Итак, у них есть клубы в... у них есть клубы в трех городах Нового Южного Уэльса. И у каждого клуба есть поддомен на сайте. Теперь, когда они добавляют любую страницу на свой веб-сайт, они создают страницу для каждого поддомена. Недавно они добавили страницу, посвященную деятельности их клуба, и они добавили эту страницу ко всем своим субдоменам. Таким образом, это означает, что все поддомены имеют одинаковый контент, за исключением того, что заголовок страницы отличается. Потому что, когда они добавляют к Сиднею, они добавляют название своего местоположения в тег title. Когда они добавляют его для Ньюкасла, они добавляют Ньюкасл в тег заголовка, но остальной контент на странице такой же. Будет ли это проблемой, потому что у них 50 субдоменов, и они создали 50 страниц с одинаковым содержанием, кроме названия?

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

Вопрос 21:44 . Как насчет создания одной страницы, а затем использования канонического URL-адреса для других страниц местоположения. Я просто хочу создать одну страницу, на которой мы будем рассказывать о своей деятельности, и я буду использовать ссылку в качестве канонического URL на другие страницы местоположения.

Ответ 22:10 - Местоположение - да. Я думаю, это может иметь смысл, потому что тогда вы снова комбинируете вещи. Тогда вы делаете одну сильную страницу, а не кучу разбавленных страниц.

Вопрос 22:20 - Потому что, когда кто-то посещает веб-сайт и выбирает свое местоположение, он автоматически перенаправляет этого человека на тот поддомен, для которого он указал свое определенное местоположение. Вот почему им нужна страница на этом субдомене. Вот почему, я думаю, если мы сохраним одну страницу и добавим канонический URL-адрес, это единственный вариант, который у нас есть на данный момент.

Ответ 23:08 - Хорошо, но я думаю, что если у вас есть отдельные страницы, которые вам нужны по каким-то техническим причинам на сайте, и вы ставите канонические, это хороший подход.

Вопрос 23:21 . Будет ли это похоже на то, что бизнес с несколькими франшизами в разных местах, по сути, с одним и тем же контентом для каждой франшизы, находится в другом городе или поселке, или где-то еще, и что-то вроде воронки, которая от вашего точку зрения обратно на одну страницу?

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

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

Ответ 24:57 - Это сложно. Я не думаю, что на данный момент у нас есть действительно четкие указания по этому поводу. Так что это то, где все эти различные методы могут иметь смысл. В общем, я стараюсь не использовать для этого robots.txt, потому что мы можем найти URL-адреса. Мы просто не знаем, что там. Поэтому, если вы действительно не видите проблем, вызывающих слишком большую нагрузку на сервер, я стараюсь использовать такие вещи, как no index, использовать rel canonical. Может быть, вы используете rel no-follow с внутренними ссылками на что-то вроде воронки, чтобы немного прояснить, что мы должны сканировать индекс, а не использовать robots.txt. Но что-то вроде решения о том, когда объединить вещи в страницу уровня индекса и когда заблокировать ее от индексации, когда мягко направить ее к одному каноническому URL-адресу, это иногда действительно сложно.

Вопрос 25:53. Потому что иногда канонические файлы игнорируются, если содержимое страницы слишком отличается.

Ответ 25:57 - Точно. Если контент отличается, то можно сказать, что это разные страницы. Мы не должны использовать канонический. В то время как вы могли бы сказать, ну, это действительно то, что я не хочу индексировать. Возможно, отсутствие индекса будет иметь больше смысла, чем канонический. Вы также можете комбинировать их оба. Мы не рекомендуем их комбинировать, потому что нам действительно сложно сказать, ну, что вы имеете в виду? Вы говорите, что это одно и то же, но один индексируемый, а другой нет, тогда они не одинаковы. Но я думаю, что в течение года у меня появятся четкие указания о том, что может сработать. Но особенно с действительно большими сайтами электронной коммерции, сканирование может быть довольно сложным.

Вопрос 26:46. Итак, есть сценарий, который я недавно пытался выяснить с парой моих клиентов. Мы пытаемся выяснить, почему мы не можем по существу выбросить сайт, который все еще использует HTTP и выглядит более или менее заброшенным, потому что страница давно не обновлялась, а контент старый, устаревший и, как правило, вроде тонкий, и поэтому у меня есть пара теорий по этому поводу. Частично это, я думаю, может быть, это было в индексе так долго, что вы все как бы создали фактор доверия с ними. And it's kind of hard to unseat them. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Вопрос 42:29 - Речь шла о сайтах туристических агентств для путешествий. Мы выбираем внутренний поиск, чтобы отображать динамический контент, например, 10 самых дешевых отелей в городе поиска, хорошо? Таким образом, фрейм страницы загружается мгновенно. Но 10 самых дешевых результатов поиска отелей загружаются динамически примерно через 30 секунд с момента выполнения поиска, потому что веб-сайт должен выполнить этот поиск в конце, а затем сравнить и уточнить результаты, чтобы вывести для искателя список 10 самых дешевых отелей. отели. Поэтому для их перечисления требуется немного времени. Так что прямо сейчас Googlebot видит только фон страницы. Затем эти 10 пустых заполнителей были там, где результаты будут загружаться чуть позже после выполнения внутреннего поиска. Так как это тенденция для туристических веб-сайтов предоставлять как можно более свежую и точную информацию, я думаю, что Google делает с этим. Конечно, мы можем перечислить некоторый статический контент на этих страницах, как это делают все другие веб-сайты для Google, если можно так сказать. Но это противоречит цели того, что большинство пользователей хотят видеть сейчас, свежего и дешевого.

Ответ 44:00 - Значит, если он там не загружается, то мы не можем его проиндексировать. Но обычно это больше связано с тем, что мы не можем обработать JavaScript или, возможно, заблокированы от фактического доступа к содержимому там. Так что это то, что вы можете сделать так, чтобы это сработало. Это не по замыслу, что это никогда не сработает. Так что это то, где вы можете копаться в деталях, используя такие вещи, как тест для мобильных устройств, чтобы увидеть, есть ли ошибки JavaScript, если что-то заблокировано, и как бы уточнить это оттуда. Так что это не невозможно, но требует некоторой работы.

Вопрос 44:42 - Джон, я копаюсь в этом, чтобы убедиться, что Google ничего не блокирует. Единственное, что мы хотим, чтобы Google сделал, это немного подождал, пока динамический контент загрузится на страницы, понимаете? Это следующий шаг, если можно так сказать, потому что, хотя эта страница не похожа на бесконечную прокрутку, скажем, Facebook, это страница с ограниченными 10 результатами. Так что это конечно. Это ограничено. Дело в том, что Google должен немного подождать динамического контента. Я только даю вам пример. Но я уверен, что есть много других примеров в дикой природе. И поскольку это тенденция к тому, что люди видят динамический контент, потому что они каким-то образом сортируют вещи, и времени они тратят все меньше и меньше — люди проводят все меньше и меньше времени на веб-сайтах, и они хотят как можно быстрее найти отличные результаты, если можно так сказать. Мне было интересно, если вы, ребята, смотрите на это улучшение.

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

МАРТИН СПЛИТТ : Да. Я собирался сказать, что мы видим много динамического контента, который индексируется без проблем, даже если он использует JavaScript и прочее. Так что, если время истекло, у вас может возникнуть проблема с продолжительностью поиска, и это может отразиться и в других местах. Мы довольно долго ждем, пока контент закончится.

Вопрос 46:48 - Можете ли вы... вы можете назвать мне временные рамки? Сколько вы ждете?

МАРТИН СПЛИТТ : Это очень, очень сложно, потому что в основном... так что дело в том, что причина, по которой мы не можем дать вам временные рамки, заключается в том, что время... и это будет звучать очень странно, и потерпите меня секунду. . Время в рендеринге Googlebots особенное и не обязательно следует принципам Эйнштейна. [СМЕХ] Так что я мало что могу сказать. Что я могу сказать, так это то, что если сеть занята и сеть является узким местом, мы, вероятно, ждем, но мы ждем только так долго. Так что, если вы возьмете минуту или 30 секунд, то мы, вероятно, уложимся в промежутки времени. Но нет ничего сложного... если я скажу вам 10 секунд, это может сработать, а может и не сработать. Если я скажу вам 30 секунд, это может сработать, а может и не сработать. Так что я бы предпочел не называть число. Что я хотел бы сказать, постарайтесь получить его как можно быстрее. И если вы не можете получить это быстро, попробуйте что-то вроде кэширования результатов поиска, чтобы поиск стал более или менее оперативным, или выдача результатов на странице становилась все более и более... более или менее мгновенной. Или попробуйте динамический рендеринг на своей стороне, это может быть обходным путем. Что вы также можете попробовать, так это попытаться разместить его на стороне сервера и, по сути, попытаться сгенерировать как можно больше контента за первый проход. Это также приносит пользу вашим пользователям, особенно если они работают в медленных сетях. Так что да. Извините, у меня нет простого ответа, но время в роботе Googlebot пугает.

Ответ 49:29. Думаю, это зависит от того, что на самом деле делает веб-сайт. Одна из сложностей, связанных со скоростью рендеринга, заключается в том, что мы можем кэшировать множество вещей, отправленных с сервера, больше, чем в браузере, потому что мы можем использовать наш индекс для многих из этих вещей. Поэтому иногда, если JavaScript кэшируется на нашей стороне, нам не нужно его извлекать. Затем, если вы снова сравните время, оно не будет соответствовать тому, что видит пользователь. Он не будет соответствовать тому, что вы видите на webpagetest.org. Так что это действительно сложно, и в тех частях, где мы знаем, что это займет больше времени, мы будем немного терпеливее. Но это затрудняет тестирование. Вот почему у нас сейчас есть все эти инструменты тестирования, которые показывают как можно больше ошибок, чтобы можно было понять, типа, не работает ли это вообще? Иногда это работает и где иногда возникают проблемы?

Вопрос 50:29 . Имеет ли значение порядок URL-адресов в картах сайта XML для очень крупных веб-сайтов?

Ответ 50:34 - Нет. Нам все равно. Это файл XML. Подтягиваем все данные. Обрабатываем все сразу.

Вопрос 50:44 - Тогда как насчет параметра приоритета в картах сайта?

Ответ 50:47 - Мы этим вообще не пользуемся. Итак, вначале мы подумали, что это может быть полезно, чтобы выяснить, как часто мы должны сканировать страницы. Но оказывается, если спросить у вебмастеров, они типа все в приоритете. Это самое важное. И то же самое, я думаю, с частотой изменений в картах сайта, где мы также замечаем, что люди говорят нам, что что-то постоянно меняется, но последнее обновление было в прошлом году. Таким образом, если у вас есть частота изменений и дата, мы все равно получим эту информацию по дате. Таким образом, мы игнорируем частоту изменений.
Вопрос 51:35. Следует ли добавлять корпоративную схему только на домашнюю страницу, страницу контактов или на все страницы?

Ответ 51:42 - Насколько я знаю, это просто домашняя страница. Я не знаю. Кто-нибудь из вас знает?

Ответ от Лиз 51:4 7 - Обычно это должна быть только одна страница с организационными и корпоративными. Это вообще рекомендация.

МАРТИН СПЛИТТ 52:00 - Я думаю, не имеет значения, какие... не так важно, какие страницы, точно так же, как не помещайте это на каждую страницу, которая у вас есть, я думаю, это более важная часть. Я думаю, это зависит от... если вы новостной сайт, вероятно, имеет смысл разместить его на странице контактов, или на странице «О нас», или что-то в этом роде. В то время как на веб-сайте магазина или ресторана, вероятно, можно разместить его на главной странице.

ОТ ИОАННА 52:20. Я также думаю, что в данном случае это не так важно для нас, потому что нам нужно иметь возможность найти его где-нибудь, например, на домашней странице или странице контактов. Но если он есть где-то еще, для нас это ничего не меняет. Таким образом, важно не сравнивать его с разметкой отзывов, когда мы иногда видим, как люди ставят отзыв о компании на всех страницах веб-сайта в надежде получить звезды и результаты поиска для каждой страницы на своем сайте. И это было бы плохо для нас. Но контактная информация, если она у вас есть, это... Я не вижу в этом проблемы.
Вопрос 53:05 . Тест скорости веб-сайта Google, который мы использовали, зафиксировал очень медленное время загрузки страницы, но независимые тесты, которые мы провели с коллегами за границей, показали очень быстрое время загрузки страницы. Влияет ли эта ложная запись на рейтинг нашего сайта в алгоритме Google?

Мари Хейнс: Это не мой вопрос, но чтобы дать некоторый контекст, новые данные Lighthouse для скорости страницы намного более жесткие, чем раньше были Page Speed ​​Insights. Таким образом, то, что имеет оценку около 80 в Page Speed ​​Insights, может быть красным 29 в Lighthouse. Так что это хороший вопрос. Может ли это быть причиной... потому что мы знаем, что на мобильных устройствах очень медленные сайты могут быть понижены в должности. Итак, хорошо ли, если мы скажем, знаете ли, что если вы оказались в минусе на тесте Маяка, что мы действительно должны улучшить ситуацию, потому что это может привести к понижению в должности, или есть отсечка?

Ответ 54:07. Таким образом, у нас нет однозначного сопоставления внешних инструментов и всего, что мы используем для социальных сетей. Да, из-за этого действительно трудно сказать, но в поиске мы пытаемся использовать сочетание фактических, что это такое, данных лабораторных испытаний, что-то вроде теста Lighthouse, и данных отчета Chrome UX, где, по сути, что мы измеряем то, что увидят пользователи веб-сайта.

МАРТИН СПЛИТТ 55:37 . Также важно отметить, что Lighthouse, например, специально измеряет 3G-соединение на срединном конце — или как телефон средней производительности, да. Таким образом, в основном, если вы используете недавний Apple McIntosh или недавний быстрый компьютер с Windows с действительно хорошим проводным соединением или действительно хорошим соединением Wi-Fi в вашем офисе, конечно, вы видите время загрузки в две секунды, но реальный пользователь со своим телефоном в дикой природе, вероятно, этого не видит. Так что это один из таких случаев, когда никогда не помешает сделать ваш сайт быстрее, но это очень, очень сложно сказать, как это будет выглядеть с внутренней точки зрения, поскольку мы используем очень конкретные показатели, которые не обязательно сопоставляют один с другим. один к тому, что выявляют инструменты... конечно, важно это исправить, потому что вы не хотите, чтобы ваши пользователи ждали на вашем сайте вечно. Это причинит тебе боль. Это навредит вашим пользователям. Это только повредит вам в поиске. Но я не плачу - я бы сказал, просто посмотрите на инструменты. Если инструменты говорят вам, что у вас все хорошо, то вам не следует слишком беспокоиться об этом. Если инструменты говорят вам, что вы на самом деле не очень хорошо работаете, то я думаю, что время, потраченное на выяснение того, почему оно говорит, например, если то, что оно говорит, актуально, оно потрачено впустую. Вам лучше подумать о том, чтобы сделать сайт быстрее.

Мобильная производительность — очень важный фактор для ваших пользователей, как и для всего остального. Поэтому я бы сказал, убедитесь, что ваш сайт хорошо работает в реальных условиях. Может быть, даже купить дешевый телефон и попробовать веб-сайт время от времени, и если... это то, что мне нравится делать, и я делал это до того, как присоединился к Google с командой разработчиков, с которой я работал. Я такой: смотри, ты хочешь использовать этот сайт на этом телефоне? Это было как, о, это ужасно. Я такой, ммм, да, так что, может быть, нам стоит что-то с этим сделать.

ДЖОН. В Chrome можно настроить и попробовать разные скорости соединения. Мобильный эмулятор. Я думаю, что это действительно хорошие вещи, на которые стоит обратить внимание, а также посмотреть на свою пользовательскую базу. Посмотрите на свои аналитические данные, если вы видите, что люди используют ваш веб-сайт только с iPhone высокого класса, тогда, возможно, это не такая проблема, как если вы видите, что люди подключаются к вашему сайту из случайных сельских соединений, которые медленные, и у них есть бюджетные устройства, то, возможно, это больше.