5 марта 2019 г. — Google Help Hangout Notes

Мы присоединяемся к Джону Мюллеру в его доме в этой видеовстрече помощи веб-мастерам. У нас было несколько отличных вопросов о Page Speed, hreflang и обратных ссылках. Видео и полную транскрипцию можно найти после нашего летнего выпуска. Если вам это нравится, подпишитесь на нашу еженедельную рассылку! Мы резюмируем лучшие SEO-статьи недели в легко усваиваемых фрагментах.

Можете ли вы объяснить проблему с использованием json - ld через диспетчер тегов?

11:18

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

Резюме: Хотя можно использовать JSON-LD и другие структурированные данные через Диспетчер тегов Google, это не лучший подход. Чтобы Google извлек контент из Диспетчера тегов, он должен отобразить JavaScript. Обработайте скрипт из Диспетчера тегов и выведите запись, а затем индексируйте. Существуют простые способы предоставления структурированных данных непосредственно на странице, что упрощает работу с Google.

Как Google выбирает URL-адрес для отображения в поиске?

15:20

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

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

Стоит ли включать авторов в сообщения блога вместо обычного пользователя редактора?

17:38

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

Резюме: Да! Целевая страница автора — это способ показать EAT ваших авторов. Это также улучшит взаимодействие с пользователем в целом, в отличие от обычного «Редактора» или «Администратора».

Каковы рекомендации, если ваш пользовательский интерфейс может быть переведен на другие языки, но дополнительный контент, такой как пользовательский контент, остается на другом языке?

21:48

Это то, что происходит довольно часто, особенно для пользовательского контента. Так что, если у вас есть форум или блог или что-то еще, и люди комментируют на одном языке, но у вас есть настройки, чтобы пользовательский интерфейс мог переключаться на другие языки. Затем вы быстро столкнетесь с ситуацией, когда пользовательский интерфейс может быть на французском или немецком языке, но контент может по-прежнему быть на испанском, например, потому что все комментируют на испанском, и это, по сути, то, что вы можете обрабатывать несколькими способами. Таким образом, вы можете сказать, что моя каноническая версия — это испанская версия, и все точно так же, как испанская версия, это один из вариантов, который вы можете сделать. Вы можете использовать аннотации hreflang между этими версиями, чтобы сказать, что это самая французская версия моего контента, которую я могу предоставить. Основной контент не на французском языке, но пользовательский интерфейс на французском языке, поэтому пользователь, переходящий на страницу, сможет ориентироваться. мой сайт, это то, что вы могли бы сделать. И, по сути, это различные варианты, которые вы можете предоставить там, чтобы сообщить нам немного больше о ваших предпочтениях. С практической точки зрения это в конечном итоге больше зависит от вас в отношении того, как вы хотите показываться в поиске. Поэтому, если вы считаете, что французскому пользователю полезно зайти на ваш сайт и перейти на страницу с контентом на испанском языке и пользовательским интерфейсом на французском языке, а затем во что бы то ни стало использовать аннотации hreflang между этими версиями. Если вы считаете, что у пользователя во Франции вообще возникнут проблемы с навигацией по вашему сайту, если основной контент на испанском языке, даже если пользовательский интерфейс на французском языке, возможно, имеет смысл просто сохранить испанскую версию с испанским пользовательским интерфейсом в индексе. Так что в конечном итоге это зависит от вас, я думаю, что ни одно из этих решений не является идеальным. Иногда от того, насколько однороден ваш контент, немного зависит, насколько четко вы понимаете, какие языковые версии вы хотите проиндексировать и какие версии пользователи ожидают увидеть в результатах поиска. Так, например, если вы очень международный форум, и люди публикуют сообщения на самых разных языках, то, вероятно, сложно сказать, что вы хотите, чтобы была проиндексирована только эта версия пользовательского интерфейса, возможно, имеет смысл индексировать все версии пользовательского интерфейса. Обратной стороной индексации всех версий пользовательского интерфейса, конечно же, является увеличение количества ваших URL-адресов, которые внезапно появляются на вашем сайте. Таким образом, это означает, что нам нужно сканировать намного больше, и если это большой сайт с пользовательским контентом, это означает, что мы должны сканировать, с одной стороны, весь пользовательский контент, а затем мы должны сканировать все кратные ему для каждого отдельного языковая версия, которую я не знаю, полезна ли она, если это слишком много сканирования для вашего веб-сайта, если это препятствует быстрому появлению нового контента в результатах поиска. Это что-то еще, чтобы как-то взвесить там. Если вы просто говорите о нескольких тысячах статей, возможно, это не так важно.

Резюме: вы можете выбрать одну языковую версию в качестве канонической или добавить аннотации hreflang между этими языковыми версиями.

Должен ли я отклонять большое количество случайных URL-адресов, ведущих на мой сайт?

27:58

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

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

Насколько важна скорость страницы для Google?

42:30

Какова текущая политика? Таким образом, скорость имеет большое значение для нас и оказывает большое влияние на пользователей, так что лично я отношусь к этому очень серьезно, и я думаю, что хорошая часть скорости заключается в том, что существуют различные инструменты, которые дают вам довольно объективные показатели. над которым вы действительно можете работать. Что касается многих из нас или других проблем, связанных с SEO, например, я не знаю, качество их контента, например, скорость — это то, что вполне измеримо и над чем вы можете поработать, и это также должно быть то, что мы использовали, является прямым следствием поведения ваших пользователей на вашем веб-сайте. Так что это не просто то, что с точки зрения Google, как мы говорим, скорость важна, это трекер рейтинга, но это то, что вы увидите непосредственно, когда пользователи зайдут на ваш сайт, и вашему сайту внезапно потребуется на пару секунд больше времени для загрузки этих пользователей. будут реагировать совершенно по-разному на вашем веб-сайте, и у вас будет больше проблем с преобразованием их в клиентов, как бы вы ни определяли клиентов на своем веб-сайте.

Резюме: скорость чрезвычайно важна, когда речь идет о Google. Это одна из метрик, которую легко отследить и на которую легко воздействовать. Существуют отличные инструменты, которые дают отличное представление о том, как работает ваш сайт и что вы можете сделать, чтобы увеличить скорость страницы.

Если я заплачу за Google Ads, мой рейтинг улучшится или ухудшится?

47:24

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

Резюме: Google Ads не влияет на органическое ранжирование.

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

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

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

Вопрос 1:14. Две недели назад наш сайт за одну ночь потерял 94% трафика Google. Учитывая стабильный поисковый трафик за последние 20 лет и отсутствие серьезных изменений, мы предполагаем, что что-то техническое может совместно использовать IPS или SSL через CDN, например облачные тарифы, что приведет к значительному падению трафика с алгоритмической точки зрения. Мы копнули глубже и обнаружили несколько сайтов с крайне опасным контентом на том же IP-адресе. Мы можем изменить нашу тему и получить специальный сертификат, но мы все равно будем в пробке, что здесь может происходить?

Ответ 2:01 - Но в целом тот факт, что другие сайты размещены на том же IP-адресе, не является причиной для беспокойства. Так, в частности, с более крупными хостерами общие IP-адреса довольно распространены, а общие IP-адреса CDN чрезвычайно распространены. И это то, что меняется, потому что у многих CDN есть конечные точки в разных странах, и они как бы делят эти конечные точки с разными веб-сайтами, которые там активны. Таким образом, по сути, пользователь и Германия могут видеть разные IP-адреса, например, по сравнению с пользователем в США, но в целом это чрезвычайно распространенная практика совместного использования IP-адресов, и это не будет проблемой. В то время это было что-то, что иногда было очень полезно узнавать даты и хозяев. Где, если бы мы увидели один IP-адрес и 9000 сайтов со статическими адресами, и все они были заспамлены, и если бы на одном хосте было два других сайта, нам было бы сложно понять, действительно ли эти два сайта полностью отдельных сайтов по сравнению с этими 9000 других сайтов. Это своего рода сложная ситуация для алгоритмов. Но в большинстве случаев, подобных этому, мы увидим смесь всех видов разных сайтов, таких как разные сайты на разных языках для разных стран с разными целевыми пользователями, некоторые спам-сайты, некоторые не спам-сайты на одном и том же IP-адресе, и все это прекрасно. . Так что это не было бы причиной для нас говорить, ну, например, потому что на этом IP-адресе есть один сайт со спамом, что это будет проблемой. Так что я не знаю конкретно, что случилось с этим веб-сайтом, я смотрю на то, что в целом также вид того, что наш веб-сайт хорошо работал в поиске в течение стольких лет, прежде чем я склонен говорить, что это хорошо для вашего сайт, но это не обязательно то, что мы всегда будем держать его таким.

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

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

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

Вопрос 11:18 . Можете ли вы объяснить проблему с использованием json-ld через диспетчер тегов? Диспетчер тегов используется для проверки консоли поиска и, возможно, аналитики, поэтому, безусловно, он достаточно стабилен.

Ответ 11:33. Я думаю, что то, о чем мы говорили, довольно много раз, а также о множестве этих тусовок, и есть новые сообщения в блогах, написанные об этом от разных людей, включая Барри. Но, по сути, это восходит к тому, что для того, чтобы мы могли извлекать контент из диспетчера тегов, нам нужно иметь возможность отображать JavaScript, обрабатывать файлы сценариев из диспетчера тегов и выводить туда запись, а также включать сторону индексации. Так что это всегда требует много работы для наших систем и не всегда то, что мы делаем для всех страниц, в частности, когда мы видим, что в противном случае страница была бы одинаковой, тогда нашим системам довольно сложно обосновать это. нам также нужно обработать весь этот JavaScript. И вдобавок ко всему, многие инструменты тестирования не обрабатывают диспетчер тегов и не выводят их, поэтому инструментам действительно сложно подтвердить, что эта разметка работает правильно. Для его обработки в поиске требуется больше времени, он может быть немного ненадежным, и вы действительно не знаете точно, что он индексирует, например, в любой момент времени. Итак, это все причины, по которым я, с моей точки зрения, могу использовать диспетчер тегов для чего-либо еще. Его также можно использовать для этого, а также для JsonLD для структурированных данных в поиске, но стоит просто помнить, что это не лучший подход для особенно структурированных данных в поиске. Это гораздо более простые способы предоставления структурных данных непосредственно на веб-странице, что упрощает обслуживание, упрощает отслеживание и тестирование всего этого. Вот что я бы порекомендовал сделать, я не говорю, что вы не можете использовать диспетчер тегов здесь для этого, вы, безусловно, можете его использовать, и мы постараемся сделать все возможное, чтобы подобрать и использовать его и тому подобное, но это не так. тот же уровень скорости и гибкости, безопасности, когда дело доходит до фактического предоставления структурных данных непосредственно на страницах.

Вопрос 14:00. Клиент выполнил миграцию HTTPS, переместив его с помощью 302 вместо 301. Нужно ли ему изменить это на 301? Сколько времени понадобится Google, чтобы понять, что это постоянное перенаправление?

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

Вопрос 15:20. Наши галереи изображений имеют уникальный URL-адрес для изображения, например /gallery/image1 или /image2 или /image 3, и мы хотим добавить галерею /view all и использовать его в качестве канонического URL-адреса, но у нас нет этой ссылки. где-нибудь на сайте мы можем это сделать? Нужно ли, чтобы все представления были видны читателю?

Ответ 15:46. Таким образом, это относится к общему вопросу о том, как Google выбирает URL-адрес для отображения в поиске, и, с одной стороны, в этом случае есть такой аспект, как целевая страница для изображения 1, имеющая относительный канонический набор просмотр всей страницы будет означать, что эти страницы не эквивалентны. Так что это своего рода удача или промах, мы бы взяли и использовали этот канонический вообще, это, я думаю, один аспект, о котором следует помнить. Еще одна вещь, которую следует иметь в виду, это то, что даже когда мы понимаем, что эти страницы можно рассматривать как эквивалентные, мы должны использовать несколько факторов, чтобы определить, какая из этих страниц является фактической канонической. Так что для этого мы используем rel canonical, мы используем редиректы, если у нас есть что-то. Мы используем внутренние внешние ссылки, мы используем такие вещи, как карты сайта, ссылки hreflang, все это помогло нам понять, какой из этих URL-адресов является тем, который мы должны показывать, и является ли указанный вами канонический URL-адрес тем, который вы никогда не используете в остальных вашего веб-сайта, то, скорее всего, мы скажем, что сделать эту ссылку канонической было ошибкой веб-мастера, на самом деле это не имелось в виду, и, возможно, нам придется выбрать другой URL-адрес в качестве канонического. Итак, я предполагаю, что здесь произойдет следующее: либо мы проигнорируем rel canonical, потому что это не одно и то же, либо мы вместо этого выберем одну из других существующих страниц, потому что это одна из страниц, которая сильно связана внутри веб-сайт. Так что я не думаю, что эта конкретная настройка будет полезна в вашем случае.

Вопрос 17:38. Что вы порекомендуете сайтам с большим количеством контента, который они хотят предоставить для других языков и стран, но пока они перевели только интерфейс, а не основной контент.

Ответ 17:55. Это то, что происходит довольно часто, особенно с пользовательским контентом. Так что, если у вас есть форум или блог или что-то еще, и люди комментируют на одном языке, но у вас есть настройки, чтобы пользовательский интерфейс мог переключаться на другие языки. Затем вы быстро столкнетесь с ситуацией, когда пользовательский интерфейс может быть на французском или немецком языке, но контент может по-прежнему быть на испанском, например, потому что все комментируют на испанском, и это, по сути, то, что вы можете обрабатывать несколькими способами. Таким образом, вы можете сказать, что моя каноническая версия — это испанская версия, и все точно так же, как испанская версия, это один из вариантов, который вы можете сделать. Вы можете использовать аннотации hreflang между этими версиями, чтобы сказать, что это самая французская версия моего контента, которую я могу предоставить. Основной контент не на французском языке, но пользовательский интерфейс на французском языке, поэтому пользователь, переходящий на страницу, сможет ориентироваться. мой сайт, это то, что вы могли бы сделать. И, по сути, это различные варианты, которые вы можете предоставить там, чтобы сообщить нам немного больше о ваших предпочтениях. С практической точки зрения это в конечном итоге больше зависит от вас в отношении того, как вы хотите показываться в поиске. Поэтому, если вы считаете, что французскому пользователю полезно зайти на ваш сайт и перейти на страницу с контентом на испанском языке и пользовательским интерфейсом на французском языке, а затем во что бы то ни стало использовать аннотации hreflang между этими версиями. Если вы считаете, что у пользователя во Франции вообще возникнут проблемы с навигацией по вашему сайту, если основной контент на испанском языке, даже если пользовательский интерфейс на французском языке, возможно, имеет смысл просто сохранить испанскую версию с испанским пользовательским интерфейсом в индексе. Так что в конечном итоге это зависит от вас, я думаю, что ни одно из этих решений не является идеальным. Иногда от того, насколько однороден ваш контент, немного зависит, насколько четко вы понимаете, какие языковые версии вы хотите проиндексировать и какие версии пользователи ожидают увидеть в результатах поиска. Так, например, если вы очень международный форум, и люди публикуют сообщения на самых разных языках, то, вероятно, сложно сказать, что вы хотите, чтобы была проиндексирована только эта версия пользовательского интерфейса, возможно, имеет смысл индексировать все версии пользовательского интерфейса. Обратной стороной индексации всех версий пользовательского интерфейса, конечно же, является увеличение количества ваших URL-адресов, которые внезапно появляются на вашем сайте. Таким образом, это означает, что нам нужно сканировать намного больше, и если это большой сайт с пользовательским контентом, это означает, что мы должны сканировать, с одной стороны, весь пользовательский контент, а затем мы должны сканировать все кратные ему для каждого отдельного языковая версия, которую я не знаю, полезна ли она, если это слишком много сканирования для вашего веб-сайта, если это препятствует быстрому появлению нового контента в результатах поиска. Это что-то еще, чтобы как-то взвесить там. Если вы просто говорите о нескольких тысячах статей, возможно, это не так важно.

Вопрос 21:25. У нас есть блог, работающий вместе с нашим веб-сайтом электронной коммерции, поскольку с самого начала сообщения в блоге были помечены как написанные обычным пользователем редактора. Глядя на рекомендации по качеству и EAT, мы хотели бы заменить editor на настоящее имя автора сообщения. Является ли такая операция положительной или она потенциально может видеть спам?

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

Вопрос 22:58. Разметка Schema с настольной версией и версией amp, нормально ли, если версия для настольного компьютера реализована с использованием микроданных, а версия amp использует json-ld?

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

Вопрос 24:19. Что касается отображения скрытого контента: нет, это нормально. Служба поддержки Google упомянула, что белый фон, белый шрифт или нулевой размер шрифта будут противоречить рекомендациям, но как насчет отображения: нет?

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

Вопрос 25:55. После ручных действий со ссылками, как долго Google обрабатывает домен после того, как запрос на пересмотр был принят, но не восстановил свой потенциальный рейтинг в трафике?

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

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

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