График работы SEO, 7 января 2022 г.

Опубликовано: 2022-01-11

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

Содержимое скрыть
1 Может ли согласованность постов в блоге влиять на сканирование и ранжирование?
2 Влияют ли теги hreflang на рейтинг сайта?
3 Данные Google Chrome и рейтинг
4 функции SERP и ранжирование
5 строк JavaScript против краулингового бюджета
6 Теги Nofollow и noindex
7 Проблемы с индексацией страницы
8 Уровень посещаемости статьи
9 Повышение уникальности контента по сравнению с ранжированием

Может ли согласованность постов в блоге влиять на сканирование и ранжирование?

03:28 «У меня есть блог, в котором я публикую почти одну статью каждый день, и [там] другой человек [отправляет] об одной статье в неделю. Что касается согласованности, […] повлияет ли это на частоту сканирования моего веб-сайта Google или […] эта согласованность как-то связана с рейтингом?»

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

05:27 «Когда я публиковал по одной статье каждый день, я видел, что Google сканировал мой сайт почти каждый день. […] Но когда я стал непоследовательным, я увидел, что Google пересекает сайт раз в два дня или реже. Это факт?»

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

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

Влияют ли теги hreflang на рейтинг сайта?

09:47 «У меня есть один веб-сайт, [который] очень хорошо работает на определенном языке. Затем я решил создать англоязычную версию этого веб-сайта, чтобы ориентироваться на людей в новом домене. Должен ли я добавить тег hreflang для соединения этих двух отдельных доменов или оставить его в покое, чтобы Google сам разобрался? Могут ли эти теги hreflang повлиять на производительность моего сайта?»

Джон ответил: «Hreflang используется для каждой страницы, поэтому это имеет смысл только в том случае, если у вас есть эквивалентные страницы на других языках или для других стран. Это не то, что делает «весь веб-сайт». Поэтому, если у вас есть несколько страниц с эквивалентными версиями, использование атрибута hreflang — хороший способ связать их. Что происходит с hreflang, так это то, что ранжирование остается прежним, но мы пытаемся заменить URL-адрес на наиболее подходящий. Таким образом, если кто-то ищет название вашего веб-сайта, а у нас есть английская и французская версии, то, если мы сможем сказать, что пользователь находится во Франции или выполняет поиск на французском языке, мы попытаемся показать французскую версию домашней страницы. Это работает в одних и тех же [и] разных областях».

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

Данные Google Chrome и рейтинг

12:39 « Какие данные Google Chrome собирает у пользователей для ранжирования?»

Джон сказал: « Я не думаю, что мы используем что-либо из Google Chrome для ранжирования. Единственное, что происходит с Chrome, — это отчет Page Experience. Мы используем данные отчета об опыте использования Chrome , которые представляют собой сводные данные о том, что пользователи видели, когда они заходили на веб-сайт, в частности, в отношении взаимодействия со страницей».

Джон также заверил, что Google не использует данные Google Analytics для ранжирования, но такие показатели, как показатель отказов или время на странице, «иногда полезны для просмотра владельцами сайтов, но это не означает, что они полезны для поиска». использовать."

Особенности SERP и ранжирование

27:56 «Поскольку количество функций в результатах поиска увеличивается, мне интересно, включает ли консоль поиска Google ранжирование, например, пакеты карт Google или люди также спрашивают, в таких показателях, как средняя позиция и клики, и т. д. , Если нет, то как лучше всего узнать, находится ли мой сайт в рейтинге по этим различным характеристикам?»

Джон ответил: «По большей части да, мы включаем все это в данные отчета об эффективности в Search Console. Каждый раз, когда мы показываем URL-адрес вашего веб-сайта в результатах поиска, мы показываем это как показ для этого веб-сайта [и] запроса.

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

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

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

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

Строки JavaScript и краулинговый бюджет

30:32 «Мы видим, что каждая строка JavaScript, начинающаяся с косой черты, интерпретируется как URL-адрес, и за ней следует Googlebot. Иногда URL-адрес недействителен, и мы видим различные ошибки сканирования в Search Console. Есть ли официальная рекомендация о том, как использовать nofollow для таких URL-адресов? Раньше мы разбивали строки на две или более частей. Могут ли миллионы страниц с такими строками негативно сказаться на краулинговом бюджете?»

Джон ответил: «Когда дело доходит до сканирования, мы расставляем приоритеты по-разному, и все эти случайные открытия URL-адресов, с которыми мы сталкиваемся, когда ваш URL-адрес упоминается в тексте или файле JavaScript […], как правило, довольно низки. список. Поэтому, если у нас есть что-то важное, что мы распознаем на вашем веб-сайте, какие-либо новые страницы, на которые вы ссылаетесь, на какой-либо новый контент, который вы создали, мы расставим приоритеты в первую очередь. Затем, если у нас будет время, мы также пройдемся по всем этим случайным упоминаниям URL, которые мы обнаружили. Так что с точки зрения краулингового бюджета это обычно не проблема.

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

Что касается nofollowing этих URL-адресов, вы не можете сделать это в файлах JavaScript. Мы пытаемся распознавать URL-адреса в JavaScript, потому что иногда URL-адреса упоминаются только в JavaScript. Однако вы можете поместить эти URL-адреса в файл JavaScript, который заблокирован robots.txt. И если URL-адрес заблокирован robots.txt, мы не сможем увидеть файл JavaScript и не увидим эти URL-адреса. Так что, если это критично [...], вы можете использовать robots.txt, чтобы заблокировать этот файл JavaScript.

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

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

Теги nofollow и noindex

34:46 «Можно ли использовать rel=»nofollow» как «noindex»? Например, когда я публикую статью на своем веб-сайте и на каждой странице, где упоминается эта статья, я буду использовать rel="nofollow" в URL-адресе этой статьи».

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

В частности, что касается нового контента в Интернете, [...] мы также иногда используем [rel="nofollow"] для обнаружения URL-адресов. Итак, с одной стороны, мы можем увидеть эту ссылку без [и с] nofollow, и все равно смотреть на нее. Если вы не хотите, чтобы страница индексировалась, убедитесь, что она не проиндексирована».

Проблемы с индексацией страницы

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

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

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

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

Уровень посещаемости статьи

37:44 «Я собираюсь обрезать часть контента на своем сайте. Слабый трафик — один из критериев. Какой вы считаете минимально приемлемым уровнем трафика для сохранения статьи?»

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

Увеличение уникальности контента по сравнению с ранжированием

43:35 «Значительное увеличение общей уникальности контента сайта не влияет на рейтинг сайта и его видимость в результатах поиска? Тогда не стоит ли бороться с кражей контента?»

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

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