Google перенаправит отчеты со старой Search Console на новую


Содержание материала:

Что делать со старыми 404-ошибками в Google Search Console?

Здравствуйте, уважаемые читатели сайта Uspei.com. Все сайты со временем изменяются, меняются URL-адреса, вы добавляете новые 301 редиректы, которые со временем теряют свою актуальность или пропадают из-за удаления страниц. Иногда старые URL-адреса больше не нужны.

Эти URL-адреса возвращают 404 ошибку, поэтому они отображаются в Search Console как ошибки сканирования, но что это значит?

Когда нерабочий URL-адрес открывается, то сервер возвращает 404 ошибку. При проведении реструктуризации вашего сайта Google рекомендует перенаправить старые URL на новые и обновить ссылки, которые ведут на старые URL, чтобы напрямую указывать на новые.

Однако со временем вы можете отказаться от этих перенаправлений, возможно, из-за накладных расходов на обслуживание, или, может быть, вы забыли о них. Эти URL-адреса теперь висят у вас в Search Console с 404-ошибкой.

НИЧЕГО СТРАШНОГО!

  1. В логах сервера или статистике проверьте трафик на эти URL. Если нет трафика, это хорошо, значит, скорее всего, в интернете отсутствуют ссылки на эту страницу. Если трафик (переходы) есть — проверьте откуда они ведут и удалите эти ссылки, либо замените на другие, либо 301 редирект.
  2. В Search Console проверьте ссылки на эти URL-адреса. Для этого нажмите на любой из указанных url, после чего перейдите во вкладку «Ссылающиеся домены». Все url в этом списке ссылаются (или ссылались, до их удаления) на страницу с ошибкой 404, которую вы в данный момент изучаете. Если таких ссылок уже нет — это тоже хорошо. Если ссылки есть, то удалите их, если они уже не нужны, либо замените эти ссылки на другие, либо сделайте 301 редирект.

Это работает, если у вас 10-20 ошибок сканирования, но что, если у вас тысячи 404 ошибок? Вам поможет Search Console, которая сама определяет приоритет ошибок сканирования. Все url выстроены сверху вниз по убыванию важности проблемы (то есть чем выше, тем на url больше всего ссылок и проблема важнее).

Если верхние ошибки в отчете не имеют значения, вы можете быть уверены, что ниже в списке нет ничего более значимого.

Если исправлять нечего, то вы можете игнорировать эти ошибки. Если вы не хотите видеть 404-ошибки в панели, отметьте их как исправленные, как на скриншоте выше.

Напоминаю, что Search Console это только инструмент анализа, и все изменения нужно проводить на сайте.

До встречи! Успевайте всё и всегда на страницах блога Uspei.com

Помоги проекту — подпишись на наш Яндекс.Дзен канал!

Google переносит весь функционал старой Search Console в новую версию

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

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

Источник новости: Search Engine Roudtable

Старая Google Search Console больше не доступна

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

С этого момента, если вы попытаетесь получить доступ к старой домашней странице или панели мониторинга, вы будете перенаправлены на соответствующие страницы Консоли поиска.

Теперь вы можете получить доступ к устаревшим отчетам на данный момент в новой версии в разделе «устаревшие инструменты и отчеты», вот снимок экрана:

Въедливый анализ отчетов Google Search Console: о чем не пишут в справке

Если история браузера не врет, за неделю я изучил 300 с лишним отчетов в Google Search Console. Это при том, что часть рутинной аналитики у меня давным-давно автоматизирована, многие важные данные выгружаются по API.

Панели вебмастера Google просто приходится уделять повышенное внимание — там есть важная для SEO информация, которую не получить из других источников. К сожалению, статистику из SC далеко не всегда можно использовать сразу, без уточнений и дополнительных проверок. Разберем несколько показательных примеров, которые помогут лучше понять логику работы Search Console и корректно интерпретировать ее отчеты.

Почему данные Search Console могут быть неполными?

В справке перечислены некоторые причины:

  • Чтобы защитить конфиденциальность пользователей, в отчете «Анализ поисковых запросов» показаны не все данные. Например, мы можем не отслеживать запросы, введенные всего несколько раз или содержащие личную информацию.
  • Различия в статистике могут являться следствием дополнительной обработки данных (например, для исключения дубликатов и посещений роботов). Однако эти расхождения обычно незначительны.
  • В различных инструментах понятие «ключевые слова» определяется по-разному. Например, инструмент подбора ключевых слов в Google AdWords показывает общее количество запросов по ключевому слову, сделанных пользователями всего Интернета. В отчетах «Анализ поисковых запросов» указываются только те запросы, по которым ваши страницы показывалсь в результатах Google Поиска.
  • Статистика для веб-мастеров обновляется с некоторой задержкой, хотя мы и собираем ее непрерывно. Обычно данные обновляются в течение двух-трех дней.
  • Необходимо учитывать часовой пояс. Дневные показатели для отчета «Анализ поисковых запросов» отслеживаются по тихоокеанскому времени (PDT). Если в ваших системах веб-аналитики используется другой часовой пояс, число просмотров за день в них может отличаться. Например, в Google Analytics время указано по часовому поясу веб-мастера.

Больше всего статистика искажается из-за первого пункта. Практически все оптимизаторы сталкивались с ситуацией, когда консоль явно показывает не все поисковые запросы. Вот пример, найденный за пару минут:

Видим, что страница показывалась в выдаче и на нее были переходы, но в отчете нет ни одного поискового запроса. Впрочем, отсутствие информации по 9 показам — это ерунда. Недавно мне повстречался целый сайт, который месяцами получает вполне заметный трафик из Google — и имеет такую же девственно чистую таблицу поисковых запросов в Search Console.

Что еще может помешать правильно воспринимать отчеты?

Официальная справка объясняет только часть возникающих проблем. Есть более глобальная причина, по которой к целому ряду отчетов нужно относиться с осторожностью. Я попробую сформулировать ее коротко:

Рассмотрим совсем простой (на первый взгляд) вопрос.

Как определить количество проиндексированных в Google страниц?

Начинающие оптимизаторы применяют оператор «site:» (напоминаю: для оценки количества документов в индексе он вообще не предназначен).

Использовать данные Search Console более правильная идея. Вот только для начала не помешает разобраться, какую именно консоль использовать. На множестве сайтов показатели старой и новой панелей различаются.

Вот пример (обращаю внимание на всплывающую подсказку):

На одну и ту же дату старая панель показывает в два раза больше проиндексированных. Beta-версия SC отмечала вторую половину страниц как «Страница просканирована, но пока не проиндексирована».

Под графиком старой панели есть ссылка на справочный материал. Цитирую:

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

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

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

Второе наблюдение важнее. Google прямым текстом пишет о том, что нахождение страницы в индексе — не бинарный признак. Проще говоря, есть не просто страницы в индексе и страницы не в индексе. Есть несколько разных вариантов.

Если посмотреть на отчет новой консоли вместе с вкладкой «исключено», то может показаться, что ситуация полностью ясна: старый отчет вроде бы должен объединять данные отчетов «Страница без ошибок» и «Страница просканирована, но пока не проиндексирована».

Увы, все не так просто.

Со второй попытки нахожу сайт, где:

  • 2,82 тыс. страниц в статусе «пока не проиндексирована»;
  • 1,15 тыс. страниц в статусе «без ошибок»;
  • 2,9 тыс. страниц в индексе согласно старой версии.

Изучаем статус «Страница просканирована, но пока не проиндексирована» подробнее

Проблема несоответствия показателей в разных версиях Search Console давно уже меня интересовала. Я внимательно наблюдал за несколькими сайтами, где были страницы в статусе «пока не проиндексирована».

3 июля я выгрузил 1000 страниц, которые показывались в этом статусе и проверил их нахождение в поиске с помощью оператора info:. Из 1000 url не найденными оказалось только 5 штук.

Сегодня консоль показывает следующую картину:

Спустя 11 дней большая часть этих страниц поменяла статус на «без ошибок».

Значит ли это, что возможность быть найденной с помощью оператора info: — это один из этапов индексации? Сложно сказать. Зато очевидно, возможность быть найденной с помощью оператора info: и полноценное присутствие в поиске — разные вещи. По крайней мере согласно логике Search Console. Можем ли мы ей доверять? Давайте посмотрим.

Возьмем другой сайт и изучим результаты отчета «просканирована, но пока не проиндексирована» более детально. Откроем отчет и сделаем очень простую вещь: сравним результаты двух предлагаемых проверок:

Не составило труда найти 33 страницы, для которых:

  • «Просмотреть в поиске» (применение оператора info:) позволяет найти url.
  • «Проверить url» сигнализирует, что URL нет в индексе Google.

В то же время встречаются и такие, где info также не дает результата.

Мы получили еще одно подтверждение наличия разных этапов индексирования и/или разных степеней присутствия страницы в индексе Google. Пойдем дальше.

Посмотрим, как ранжируются эти страницы. Берем их title и забиваем в поиск. Результаты такие:

  • В одном случае 2 позиция.
  • В другом 20-я.
  • В 31 случае сайт не найден в ТОП-100.

Любопытно, что заключение поисковой фразы (напоминаю, это title документа) в кавычки только ухудшает результат: та же самая страница ищется на 2 месте, все остальные — за пределами ТОП-100.

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

На закуску разберем еще один отчет.

Насколько точны данные о последнем сканировании страницы?

Обнаружив такие явные расхождения в плане статуса страниц я усомнился и в других данных. В первую очередь меня заинтересовала дата последнего сканирования документа роботом. Знать ее весьма полезно для ряда аналитических задач.

На экспериментальном сайте нашелся 1 url, длительное время находящийся в статусе «Обнаружена, не проиндексирована». Для этого ресурса меня есть полный access.log за все время его существования.

Если кто-то не в курсе, то следить за роботами в логах — одно из моих любимых развлечений. Частенько оно приносит пользу.

Search Console говорит, что робот вообще не посещал эту страницу.

Согласно лог-файлу, Googlebot посещал эту страницу 5 раз, последний — 24 января. Разумеется, я проверил IP визита через обратный DNS-запрос, робот действительно принадлежал Google.

Любопытно посмотреть заодно, что это за страница на самом деле. Это url, отдающий 404-ю ошибку. Он был удален с сайта и исключен из системы навигации, но остался в карте сайта (sitemap.xml). Так вот, робот Google действительно ни разу его не посещал с момента удаления из навигации. Еще одно подтверждение моего наблюдения, что роль sitemap.xml для Google сильно преувеличивают.

Конечно, единичный пример мало что доказывает. Посмотрим на страницы другого сайта.

Для страницы с датой последнего сканирования 26 мая в лог-файле были найдены следующие строки (оставил самое важное — дату и User-agent робота):

Таким образом, в логах зарегистрировано еще 3 визита робота после 26 мая.

Топ-пост этого месяца:  В Telegram появился инструмент для создания опросов

Обращает на себя внимание тот факт, что первый из них очень близок по времени к дате к зарегистрированному в консоли. Возможно из-за этого (а также из-за отсутствия изменений в документе) он не учитывается.

С двумя другими не отображаемыми в SC ситуация интереснее. Легко видеть, что это заходы десктопного робота. 3 июля (то есть уже после всех заходов) пришло письмо о переводе сайта на mobile-first индекс. Если предположить, что в Console отображаются только визиты Googlebot, обеспечивающие обновление индекса, то получается, что отсутствие письма «Mobile-first indexing enabled for» вовсе не означает, что для сайта не используется мобильный индекс.

Впрочем, все это только предположения. Зато можно с уверенностью сказать что Search Console не дает полной картины сканирования сайта роботом.

Основные выводы и зачем вообще нужно знать о нюансах Search Console

  1. Данные в Search Console зачастую являются неполными (Google сам об этом говорит).
  2. Причины искажений — желание защитить конфиденциальность пользователей, сложность и секретность поискового алгоритма, задержки в обновлении.
  3. Страница может быть представлена в поиске по-разному. Документы в статусе «пока не проиндексирована» зачастую находятся в с помощью оператора info:, однако испытывают существенные проблемы в ранжировании. Проверка индексации с помощью info: не позволяет отделять полноценно «работающие» страницы от тех, кто по факту не способен давать трафик из Google.
  4. Страницы, указанные только в sitemap.xml и не являющиеся акцепторами ссылок могут длительное время не посещаться роботом.
  5. Дата последнего сканирования, указанная в beta-версии Search Console, часто не учитывает ряд визитов Googlebot на страницу.

Как это все применять на практике? На самом деле странный вопрос — если уж вы дочитали до конца и не заснули, то должны знать пару-тройку вариантов (как минимум). Намекну для тех кто схитрил и просто пролистал до конца: например, имеет смысл поискать другие способы проверки индексации. Они есть.

Самое главное, что нужно понимать про неполноту и задержки в обновлении данных Search Console:

  • это проблема в плане ежедневной аналитики и большинства экспериментов, так как приходится перепроверять данные и привлекать дополнительные их источники, что замедляет процесс.
  • это возможность для изучения принципов, по которым работает Google. Нестыковки вроде описанных выше — отличная отправная точка для исследований.

Второй пункт особенно актуален сейчас, когда параллельно существуют две Search Console с внушительным разнообразием данных. Ловите момент!

Гайд: Google Search Console в работе SEO-специалиста

Поделиться этим постом

Google Search Console (Google Webmaster Tool) — неотъемлемый инструмент SEO-оптимизатора, работающего с любой поисковой системой. GSC находит десятки технических ошибок, которые мешают продвижению в поисковиках, а также помогает получить статистику по запросам и найти недооптимизированные страницы с низким CTR.

Важно помнить, что консоль — просто инструмент, который подсказывает слабые места. Показатели лучше анализировать параллельно с данными, полученными из парсера или логов (если ищете дубли метаданных, страницы не в индексе и прочее), а также из других сервисов аналитики. Игнорировать гугл вебмастер тулс не стоит, чтобы не упустить критические ошибки, которые повлияют на место в поисковой выдаче.

В этом посте я рассмотрю отчёты Google Search Console (как старой, так и новой версии) и расскажу, как они помогают в работе SEO-оптимизатора.

1. Отчёты первостепенной важности

1.1. Отчёт об эффективности

Этот отчёт один из наиболее важных для SEO-специалиста.

  1. Запросы, по которым пользователи переходят на сайт или по которым есть показы в Google, их среднюю позицию и процент кликабельности (CTR);
  2. Страницы с аналогичными параметрами;
  3. Страны проживания пользователей;
  4. Устройства;
  5. Вид в поиске, по которому осуществляются переходы или есть показы.

С помощью отчёта об эффективности SEO-оптимизатор может:

  • Провести анализ динамики трафика или показов на сайте;
  • Найти слабые места в оптимизации;
  • Выделить запросы, по которым снизился или вырос трафик;
  • Выяснить, поступает ли трафик с Google Images или Google Video;
  • Найти страницы с низким CTR (для повышения привлекательности в выдаче);
  • Выяснить, какой процент пользователей просмаривает сайт с мобильных устройств, а какой с десктопных.

Тут важно уточнить, что полагаться только на данные GSC не стоит, так как информация не всегда точная. Для примера покажу график кликов/показов и его общие данные при фильтрации по запросу. После 19 августа Google исключил редкие запросы из суммированных данных, потому картина может очень отличаться от реальной.

Показатель средней позиции — тоже сомнительная величина, если смотреть на общую картину. Например, поставив фильтрацию по стране, мы видим, насколько сильно разнятся данные.

Для приближённых к действительности показателей следует отдельно анализировать каждый интересующий запрос и страницу.

Для этого используют плагин «Search Analytics for Sheets». Его неоспоримый плюс — выгружает не 1000 запросов-страниц, а гораздо больше. Как показывает практическое применение этого дополнения, оно всё равно не выгружает всю аналитику, а только рандомное число (от чего зависит — пока непонятно). Это может быть 12 000, может 18 000, а может и 7 000. Выгрузив два отчёта по срезам (например, за две недели) и сравнив их, вы получаете полноценную картину того, как изменились клики и показы по странице или запросу. Подробнее о том, как установить и использовать этот плагин, читайте в посте.

1.2. Отчёт «Покрытие» в Google Search Console

Для SEO-оптимизатора крайне важно, чтобы все продвигаемые страницы находились в индексе поисковика. В обновлении Google Search Console представлен детализированный отчёт об индексации страниц, поделённый на 4 большие категории:

  • «Ошибки» — такие страницы не будут проиндексированы; сюда попадают страницы, закрытые в , с 5хх или 4хх ответом сервера или длинной цепочкой редиректов. Следите, чтобы в эту группу не попали важные для продвижения страницы.
  • «Предупреждения» — сюда попадают страницы, которые закрыты в robots.txt, но Google продолжает их индексировать. Такие страницы мешают продвижению (создавая дубли основных), если видите подобное — используйте или X-Robots-Tag для исключения ненужных страниц.
  • «Страницы без ошибок» — полезный отчёт, который помогает определить, какие страницы, не указанные в Sitemap, попадают в индекс поисковика, и на что тратится краулинговый бюджет (важно для больших сайтов-пациентов).

Если эти страницы не приносят трафик и не нужны в поиске, их закрывают от индексации.

  • «Исключено» — спорный статус для страниц, так как многие из них при проверке находятся в индексе Google (особенно это касается страниц «Страница просканирована, но пока не проиндексирована» и «Обнаружена, не проиндексирована»). Отчёт не остаётся пустым, поскольку туда попадают страницы с настроенным «canonical», страницы с 3хх редиректом и другие. Интересный тип исключения — «Страница является копией. Канонические версии страницы, выбранные Google и пользователем, не совпадают». Не игнорируйте эту проблему. Тут показано несовершенство поисковых алгоритмов. При ручной проверке выясняется, что поисковик склеивает, например, две страницы разных карточек товара. Ещё этот статус помогает выявить ошибку отсутствия редиректа со страницы со слешем на ту же без него (или наоборот).
  • Возможность смотреть статус покрытия сайта по отдельным Sitemap — однозначный плюс для SEO-оптимизатора в новой версии GSC, например, раздробив карту сайта по 1 000 URL в каждой. Таким образом, вы не упустите страницы, которые скрываются из-за ограничений отображения количества строк в консоли.

    К отчёту «Покрытие», как и отчёту об «Эффективности», стоит относиться как к подсказкам, а не доказанной истине. Перепроверить полученную информацию можно с помощью инструмента Netpeak Checker, узнав, сколько страниц проиндексировано на сайте:

    • Запускаем сканирование сайта, выбираем пункт «Google SERP: URL».
    • Значение в колонке «Индексация» показывает, проиндексирован ли сайт.
    • В колонке «Проиндексировано» отражается количество страниц сайта в индексе.

    Ещё один момент в этом отчёте GSC, на который не стоит полагаться — дата последнего сканирования. Только лог-файлы покажут достоверную информацию о посещении Googlebot-ом определённой страницы. При сравнении дат в GSC и лог-файлах видно, что они могут сильно отличаться.

    Отчёт «Покрытие» помогает SEO-специалисту обнаружить проблемы технического характера на сайте:

    • проблемы работы сервера (5хх ошибки);
    • страницы с 4хх ответом сервера;
    • бесконечные редиректы;
    • страницы, по ошибке закрытые от индексации;
    • страницы, закрытые в robots.txt, но попавшие в индекс;
    • дубликаты и мусорные страницы, на которые тратится краулинговый бюджет или которые находятся в индексе;
    • важные для продвижения страницы, не попавшие в индекс.

    1.3. Отчёты об «Удобстве для мобильных» и «AMP-страницах»

    В эру Mobile-First-Index для продвижения в Google важно следить за оптимизацией страниц под мобильные устройства.

    В этих отчётах видны ошибки, которые стоит исправить для корректного отображения на смартфонах.

    2. Функция «Проверка URL» в новой Google Search Console

    Одна из фич, которых не хватало в старой Google Search Console — проверка URL. Просто отправьте URL на проверку с помощью этой функции, если нужно быстро проверить одну страницу: в индексе или нет; если не в индексе, то почему; когда было последнее сканирование ботом и каким (десктопным или мобильным); как обнаружена страница..

    3. Отчёты в старой GSC, которые всё ещё нужны

    Эти вкладки всё ещё не перенесены из старого инструмента в новый, но менее полезными не становятся. Рассмотрю отчёты, о которых не стоит забывать SEO-специалисту.

    3.1. Оптимизация HTML

    Этот отчёт сигнализирует SEO-оптимизатору об отсутствующих, коротких, повторяющихся или длинных метаданных без сканирования сайта парсерами.

    3.2. Структурированные данные

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

    3.3. Таргетинг по странам и языкам

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

    3.4. Инструмент проверки файла robots.txt

    Как и Яндекс.Вебмастер, Google Search Console помогает протестировать файл robots.txt перед загрузкой на сайт и узнать:

    • Не будут ли закрыты от индексации важные страницы;
    • Корректно ли указаны директивы.

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

    Подводим итоги

    Google Search Console — помощник как опытного, так и начинающего SEO-оптимизатора, который указывает на слабые стороны сайта-пациента.

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

    • Первым делом, увидев резкую просадку в Google, необходимо обратиться к вкладке «Меры, принятые вручную».
    • Увидев просадку по одной странице, стоит анализировать запросы, по которым перестал поступать трафик.
    • Заметив в выдаче нецелевую страницу, нужно запустить «Проверку URL».

    Всё это можно выполнить в инструменте Google Search Console. Расскажите в комментариях, как вы используете GSC в SEO-оптимизации 😉

    Новая версия Google Search Console – обзор доступных инструментов. Январь 2020

    Мы планировали сделать обзор новой версии Google Search Console, когда её обновление будет полностью закончено, и в новой панели будут доступны все инструменты. Но прошёл уже год с тех пор, как новая версия Google Search Console стала доступна пользователям. А обновление Google до сих пор не завершил. К нам поступает много вопросов по новой версии. Регулярно возникают вопросы по статье с обзором старой версии, часть замечаний которой уже не актуальны.

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

    Меню ресурсов

    Все добавленные в панель ресурсы отображаются в левом верхнем углу. Здесь вы можете переключаться между доменами, если в панель их добавлено несколько.

    В конце меню ресурсов находится кнопка «Добавить ресурс».

    Добавление сайта

    После нажатия на кнопку появится окно, в котором вам предложат добавить ваш ресурс. В названии употребляется «ресурс», так как в панель можно добавить не только сайт, но и приложение.

    Будьте внимательны, добавляя url вашего сайта. Важно указать правильный адрес www или без, http или https, наличие на конце «/» – всё это важно. Подробнее в Справке: «Как добавить сайт в Search Console».

    После добавления ресурса нужно подтвердить права. Сделайте это одним из предложенных способов:

    • размещение файла HTML на сервере;
    • провайдер доменных имён;
    • тег HTML;
    • код отслеживания Google Аналитики;
    • фрагмент-контейнер Диспетчера тегов Google.

    Подтвердить ресурс можно одновременно несколькими способами.

    Для сайтов, созданных на платформе Google и blogger.com, проверка проходит автоматически.

    Детально про подтверждение в Справке.

    Поддержки указания, какая версия приоритетная: с www или без – в новой панели нет. Если вы правильно настроили 301 переадресацию и сайт доступен только по одной из версий, то добавлять вторую версию в панель не нужно.

    Если по каким-то причинам сайт доступен по разным версиям www и без www (не настроен редирект), то нужно указать приоритетный домен в старой версии Search Console.

    Обзор

    Это фактически первая страница новой консоли, на которой представлены основные отчёты. Каких-то своих отчётов, которых нет в других вкладках, тут нет.

    Сейчас на вкладке отображаются отчёты «Эффективность», «Покрытие», «Улучшения».

    Эффективность

    Очень важный и объёмный отчёт. Фактически именно он показывает, как проект представлен в Google, по каким фразам он виден, по каким есть переходы и на какие страницы, с каких устройств и т. д. Данные представлены за 16 месяцев, поэтому можно отслеживать динамику как сайта в целом, так и отдельных сегментов.

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

    В вашем распоряжении несколько уровней фильтрации отчётов.

    Верхние фильтры

    Изначально стоит фильтрация по дате и типу поиска. Вы можете менять эти фильтры, но не можете их убрать (что логично). К уже постоянным фильтрам можно добавить фильтры по «Запросам», «Страницам», «Странам», «Устройствам», «Тип поиска», «Вид в поиске» (последний показывается, только если есть расширенные результаты или AMP-страницы).

    Сравнение данных

    Во всех фильтрах доступна возможность сравнения, что очень удобно при анализе данных.

    Диаграмма

    Далее расположена диаграмма, которая визуализирует данные. На диаграмме можно отобразить данные по количеству кликов, показов, среднее значение CTR, средней позиции.

    Данные и фильтры второго уровня

    Выбрав нужные нам фильтры в верхней строке, спускаемся ниже и в блоке под диаграммой видим вкладки с данными, которые совпадают с дополнительными фильтрами в начале отчёта.

    Здесь мы можем использовать дополнительные фильтры для отображаемых данных.

    Несколько примеров отчётов, которые можно получить во вкладке «Эффективность», подготовили в отдельной статье . Рекомендуем посмотреть и попробовать на своих проектах, это поможет быстрее освоить новую панель.

    Экспортировать данные

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

    В заключение этого пункта небольшая ложка дёгтя. Отчёт не даёт точных данных. Одна из причин: часть информации Google скрывает.

    В справке есть информация о том, как подсчитать количество анонимных запросов, но данные опять-таки будут приблизительными.

    Интересная статья по теме актуальности данных в Google Search Console: «Въедливый анализ отчетов Google Search Console: о чем не пишут в справке».

    Проверка URL

    Удобный и важный инструмент, который позволяет оценить текущее состояние конкретного URL в индексе и на сайте, а также отправить страницу на индексацию или переиндексацию.

    А) Проверка страницы в индексе

    В инструменте проверки URL можно узнать:

    • дату последнего сканирования и какой робот выполнил его;
    • как Google обнаружил страницу;
    • сведения о канонических URL;
    • информацию о блокировке;
    • о наличии URL в индексе Google;
    • информацию из раздела «Улучшение».
    Топ-пост этого месяца:  Курс по PHP программированию

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

    Б) Проверка страницы на сайте

    После того как выполнена проверка страницы в индексе, можно выполнить проверку на сайте.

    Страница будет проверена по тем же параметрам, что и страница в индексе.

    После проверки у вас будет две вкладки (показали на скриншоте ниже), переключаясь между которыми, можно смотреть, всё ли исправлено.

    Запросить индексирование


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

    Нюансов в работе инструмента много, поэтому будет полезно почитать официальную справку.

    Покрытие (Отчёт об индексировании)

    Этот инструмент – барометр технического состояния и индексации сайта. Анализируя отчёты в этой вкладке, можно выявить многие проблемы проекта.

    А) Список вкладок

    В отчёте есть следующие вкладки: «Ошибка», «Без ошибок, есть предупреждения», «Страница без ошибок», «Исключено».

    Важно проверять не только первые два отчёта, но и смотреть на страницы без ошибок, а также на исключённые страницы.

    Поясним на примерах:

    • В отчёте «Страница без ошибок» могут отображаться страницы с типом «Страница проиндексирована, но её нет в файле Sitemap». Если это нужная страница, то почему её нет в карте сайта?
    • В тип страниц «Страница отправлена и проиндексирована» могли попасть страницы, которые вы совсем не хотите видеть в индексе, например, страницы сортировки.

    Тем более нужно просматривать отчёт «Исключено»:

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

    Б) Диаграмма

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

    Также тут появляются пометки об изменениях на сайте и в самом Google.

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

    В колонке «Проверка» отображается статус проверки, если она была запущена. В колонке тенденция можно увидеть мини-график по динамике количества страниц данного типа.

    Г) Чтобы отправить страницы на проверку, нужно перейти по ссылке с названием проблемы к списку страниц, где она была обнаружена.

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

    Фильтрация по файлам Sitemap

    В отчёте вы можете выбрать, какие данные хотите посмотреть. Это могут быть:

    • все обработанные Google страницы;
    • только страницы, отправленные на индексацию;
    • страницы из отдельной карты сайта.

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

    Файлы Sitemap

    В этой вкладке вы можете добавить новую карту сайта, узнать какие карты сайта были обработаны, есть ли в них ошибки.

    Для проектов, у которых много карт, предусмотрена фильтрация данных.

    Если вы увидели ошибку, то можно сразу перейти в отчёт «Покрытие» и посмотреть причину возникшей проблемы.

    Удобство для мобильных

    По своей структуре отчёт похож на «Покрытие». Только тут два типа информации: «Ошибка» и «Страница без ошибок». Анализ это значительно упрощает. Есть ошибки – исправляем и отправляем на проверку. Google рекомендует начинать с проблем, затронувших большее число страниц. С учётом перевода сайтов на Mobile-first indexing, ошибок в этом отчёте у сайтов, претендующих на высокие позиции, быть не должно.

    Меры, принятые вручную

    Как понятно из названия, тут отображается информация о ручных санкциях сайта. Лучше всего, чтобы эта вкладка была пустой. Ссылка для любопытных и тех, кому не повезло: «Отчёт о мерах, принятых вручную».

    Ссылки

    В новой панели объединена информация о внешних и внутренних ссылках. Отчёт разбит на две колонки. Вверху отчёта сразу же находится кнопка, позволяющая выгрузить список ссылок.

    Каждый отчёт содержит возможность фильтрации данных и экспорта до 1000 строк.

    Страницы, на которые чаще всего ссылаются

    В отчёте вы можете не просто увидеть, сколько сайтов/ссылок есть у страницы. Но и получить больше информации. Увидеть, какие именно сайты ссылаются на страницу, а затем посмотреть список страниц, где стоят ссылки на конкретную страницу. Очень удобно, чтобы понимать, кто сослался на твой проект.

    К этому отчёту ещё бы прикрутить возможность не отображать отклонённые ссылки (Disavow Links Tool), чтобы упростить поиск ядовитых ссылок. Представители Google, Вы меня слышите? ��

    Сайты, ссылающиеся чаще всего

    Здесь также есть возможность не просто посмотреть список сайтов, но и увидеть все страницы, на которые они ссылаются, а затем посмотреть, на каких именно страницах стоят внешние ссылки.

    Самые распространённые тексты ссылок

    В этом отчёте информации меньше. Одинаковые тексты объединяются без показа, сколько раз они использовались. Судить о частоте использования анкоров можно только по рейтингу. У самой частотной фразы рейтинг «1».

    Страницы, на которые есть много внутренних ссылок

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

    Приведём примечания Google, которые помогут вам лучше понимать данные отчёта по ссылкам.

    Настройки

    В настройках сейчас есть только:

    • информация о подтверждении прав;
    • возможность добавлять и удалять пользователей.

    Что-то новое в эти возможности не добавлялось.

    Пока ещё в новой панели Google Search Console есть кнопка перехода к старой версии.

    Заключение

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

    Специализируюсь на продвижении коммерческих сайтов. Разрабатываю стратегии для интернет-магазинов и агрегаторов. Умею выжимать максимум трафика в любой тематике.

    Руковожу SEO-процессами внутренних проектов SiteClinic. Обучаю молодых специалистов команды.

    Любимая цитата: Хорошо смеётся тот, кто смеётся из ТОПа

    Оцените мою статью:

    (8 оценок, среднее: 4,50 из 5)

    Новый интерфейс Google Search Console вышел из беты

    Новости от Google: новая версия Search Console вышла из беты и теперь установлена по умолчанию для всех пользователей сервиса.

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

    В Google Search Console вы можете ознакомиться с данными по:

    • количеству проиндексированных и отображаемых в поиске страниц;
    • наличию нарушений на сайте, которые могут стать причиной для занижения его позиций;
    • подробными данные о количестве кликов, показах, CTR и списком ключевых слов, по которым переходили пользователи;
    • наличию структурированных данных (микроразметки) и ошибках в них;
    • проблемам сканирования страниц ресурса;
    • количеству внутренних и внешних ссылок;
    • удобству просмотра на мобильных устройствах;
    • настройке геотаргетинга.

    В панели присутствуют инструменты для определения наличия на сайте файлов sitemap.xml и robots.txt, а также проверки их содержимого.

    Что изменилось?

    В новой версии Search Console реализовали следующие улучшения:

    1. Данные о поисковом трафике можно просматривать за 16 месяцев вместо прежних трех.
    2. Объединили 2 отчета в один: ссылки на ваш сайт и внутренние и повысили точность подсчета ссылок:
    3. Новый интерфейс оптимизирован для мобильных устройств.
    4. Представили подробные сведения о конкретных страницах. К этой информации относятся канонические URL, статус индексирования, удобство для мобильных устройств.
    5. Реализовали инструменты, которые позволяют отслеживать сканирование ваших веб-страниц, исправлять связанные с этим ошибки и отправлять запросы на повторное индексирование.
    6. Доступны усовершенствованные отчеты:
      Старая версия отчета Новая версия отчета Сравнение
      Анализ поисковых запросов Эффективность В новом отчете представлены данные за 16 месяцев, а работать с ним стало удобнее.
      Полезные подсказки Отчеты о статусе расширенных результатов Новые отчеты содержат подробную информацию, которая обеспечивает устранение ошибок, и позволяют с легкостью отправлять запросы повторного сканирования.
      Ссылки на ваш сайт
      Внутренние ссылки
      Ссылки Мы объединили два старых отчета в один новый и повысили точность подсчета ссылок.
      Статус индексирования Отчет об индексировании В новом отчете есть все данные из старого, а также подробная информация о статусе в индексе Google.
      Отчет по файлам Sitemap Отчет по файлам Sitemap Данные в отчете остались прежними, но мы улучшили его оформление. Старый отчет поддерживает тестирование файла Sitemap без его отправки, а новый – нет.
      Accelerated Mobile Pages Отчет о статусе AMP-страниц В новом отчете добавлены новые типы ошибок, по которым можно просматривать сведения, а также реализована отправка запроса на повторное сканирование.
      Меры, принятые вручную Меры, принятые вручную В новом варианте отчета приводится история действий, выполненных вручную, включая сведения об отправленных запросах на проверку и результатах проверок.
      Сканер Google для сайтов Инструмент проверки URL В инструменте проверки URL можно посмотреть информацию о версии URL, включенной в индекс, и версии, доступной онлайн, а также отправить запрос на сканирование. Добавлены сведения о канонических URL, блокировках noindex и nocrawl и наличии URL в индексе Google.
      Удобство просмотра на мобильных устройствах Удобство просмотра на мобильных устройствах Данные в отчете остались прежними, но работать с ним стало более удобно. Также мы добавили возможность отправлять запрос на повторное сканирование страницы после того, как на ней будут исправлены проблемы с просмотром на мобильных устройствах.
      Ранее такого отчета не существовало Проверка URL Содержит подробную информацию о ваших страницах, включенных в индекс Google в настоящее время или ранее. Примеры таких данных: последнее время сканирования, канонические URL, блокировка с помощью директивы noindex и файла robots.txt и т. д. Также в интерфейсе этого отчета можно протестировать страницу, доступную онлайн, на пригодность к сканированию.

    Чего не было раньше?

    Функция «Live test» в инструменте проверки URL

    Обновленный инструмент позволяет проводить проверки URL в режиме реального времени. Теперь пользователи смогут не только анализировать проиндексированные страницы, но и понимать, что Google видит на данный момент.
    Хотите повысить трафик на сайте за счет анализа данных Google Search Console? Оставьте заявку и получите стратегию от команды Inweb.

    Если вы нашли ошибку, выделите участок текста и нажмите Ctrl + Enter или воспользуйтесь ссылкой , чтобы сообщить нам.

    Миграция без жертв: технический чеклист для переезда сайта на новый домен

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

    Если малейшее упоминание грядущего переезда вызывает у вас дрожь и неумолимое желание уехать на край света, предварительно выбросив ноутбук в окно, наш чеклист по переезду предназначен именно для вас 🙂

    1. Создание бэкапа

    Как бы внимательно вы ни подошли к переезду, лучше перестрахуйтесь и сделайте бекап всех файлов сайта и баз данных при помощи встроенных инструментов на сервере или внешних дополнительных инструментов.

    2. Знакомство с историей нового домена

    Этот пункт имеет особое значение для тех, кто ещё только задумывается о переезде и «прощупывает почву», а также тех, кто купил домен не глядя. Есть ряд причин, по которым вам стоит отнестись к прошлому своего нового домена с особым вниманием:

    1. Если прошлый владелец умудрился схлопотать бан от поисковых систем, вам с ним бороться будет крайне сложно.
    2. На сайт могут вести разного рода бэклинки, которые вам необходимо будет учесть и перенаправить. Причём, бэклинки могут быть как качественные, так и наоборот. Просматривая список обратных ссылок, ведущих на домен, вы можете увидеть нормальные органические бэклинки или же явный спам. К тому же, у каждого из ссылающихся доменов будут отличаться показатели трастовости и авторитетности, исходя из которых можно делать выводы о качестве сайтов.
    3. Если домен уже использовался до вас, а его тематика во многом пересекается с вашей, воспользуйтесь ситуацией по максимуму. Поставьте редиректы со старых страниц этого домена на релевантные новые страницы своего сайта, которые будут доступны по новым адресам после переезда. Так вы сможете бесплатно получить качественные беклинки и дополнительную долю реферального трафика.

    3. Создание временной страницы для отображения во время переезда

    Если вы приобрели для переезда домен «с историей» и на него уже ведут какие-то ссылки, рекомендуем поставить на нём временную «заглушку» — страницу с просьбой вернуться позже или ссылками на другие информационные каналы вашей компании. Она должна показываться абсолютно всем пользователям, которые попадут на одну из страниц нового домена до окончания технических работ. Вы можете даже добавить таймер обратного отсчёта, если уже наметили точную дату релиза сайта на новом домене. Крайне важно, чтобы эта страница отдавала код ответа 503 Service Unavailable.

    Пример «заглушки» на GitHub

    4. Выгрузка полного списка страниц и настройка редиректов

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

    4.1. Сбор списка страниц сайта при помощи краулера

    Для сбора и выгрузки списка видимых страниц сайта вы можете воспользоваться любым удобным вам десктопным краулером (в рамках данной статьи я буду описывать процедуры на примере Netpeak Spider). Просто запустите краулинг по всему сайту с учётом всех поддоменов и каталогов, предварительно отключив в настройках учёт инструкций по индексации, а также выбрав минимальный набор анализируемых параметров.

    К тому же, подобная проверка позволит выявить и ликвидировать уже на новом домене все проблемы по части кодов ответа сервера — все неработающие ссылки, редиректы с кодом ответа, отличным от 301, и так далее.

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

    4.2. Сбор списка страниц при помощи сервисов по мониторингу бэклинков

    Это можно сделать при помощи «Анализа ссылок» в Serpstat, инструмента «Сайт эксплорер» в Ahrefs, а также ряда других подобных им сервисов. Выбор будет зависеть от ваших личных предпочтений.

    Топ-пост этого месяца:  Секреты работы с CMS WordPress. Работа с БД. Простые решения без плагинов.

    4.3. Предварительная чистка списка

    Выгрузив список ссылок внутренних и внешних ссылок сайта, выполните несколько простых шагов, которые предотвратят появление ряда серьёзных ошибок уже на новом домене:

    1. Убедитесь, что в списке страниц для переезда нет полных дублей страниц, доступных по разным адресам. Вы можете обнаружить их, сканируя страницы списка со включённым анализом хеша страницы и хеша текста. Если вы обнаружите на старом домене дубли, у которых есть внешние беклинки, рекомендуется настроить редирект со всех дублей на одну новую каноническую страницу. Лучше позаботиться об устранении дублей сразу же на этом этапе, не дожидаясь финальной проверки на ошибки.
    2. Проверьте все ссылки на внешние площадки, которые имеются на вашем сайте: при возможности замените на актуальные, либо удалите вовсе.
    3. Выясните, есть ли на сайте ссылки, которые ведут на более недоступные внутренние страницы. Если они имеются только на вашем сайте, а беклинки на них никто не ставил, уберите и замените их при переносе на новый домен. Если же эти найденные недействительные адреса значатся в списке бекликов, учтите их при переезде и выставьте редирект на максимально релевантную страницу.

    4.4. Настройка серверной переадресации

    Полученные обоими способами списки необходимо совместить в одну таблицу, исключив дубликаты, и прописать соответствующие адреса для редиректов на новый домен. Для переадресации следует использовать 301 серверный редирект, который настраивается при помощи файла .htaccess. И проще всего это будет сделать при условии идентичных имён у старых и новых страниц (old.com/page-about-seo и new.com/page-about.seo).

    Код, отвечающий за переадресацию на уровне сервера, будет иметь примерно такой вид:

    Также не забудьте при написании кода для редиректов в .htaccess учесть переадресацию на основное зеркало сайта — с префиксом www. или без него, с протоколом HTTP и HTTPS.

    5. Создание карты сайта

    После создания всех необходимых страниц на новом домене вам предстоит следующий шаг — создание карты сайта.

    Всего насчитывается 6 видов карт, из которых чаще всего используются три — базовая XML Sitemap для всех страниц сайта, Image Sitemap для изображений и HTML Sitemap, основная задача которой — упростить навигацию внутри сайта для пользователей. Первая создаётся для абсолютно всех типов сайтов, вторая — для сайтов с большим количеством графического контента, который также может приносить трафик из поиска по картинкам.

    Для создания карты вы можете использовать несколько инструментов:

    1. Встроенный функционал используемой вами CMS или дополнительные внешние плагины для неё.
    2. Онлайн-генераторы карт сайта (XML Sitemap Generator, XML-Sitemaps.com, Check Domains и другие).
    3. Специальные скрипты для автоматической генерации карт сайта.
    4. Десктопные инструменты (InSpyder) и краулеры со встроенным генератором файлов Sitemap (Netpeak Spider, к примеру)

    После создания и размещения карты в корневом каталоге сайта не забудьте указать её адрес в директиве Sitemap файла robots.txt.

    6. Подготовка нового файла robots.txt

    Перед релизом нового сайта и снятием «заглушки» обязательно позаботьтесь о грамотном составлении файла robots.txt. Один из способов проверить правильность указанных инструкций по индексации — воспользоваться функцией «Виртуальный robots.txt» в Netpeak Spider.

    С его помощью вы можете загрузить в программу составленные вами инструкции для поисковых роботов без изменения реального файла robots.txt, а затем взглянуть на сайт «глазами поисковиков». Это позволит понять, не оказались ли какие-то из важных страниц закрыты от индексации, и наоборот.

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

    7. Настройка атрибута rel=canonical

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

    8. Уведомление поисковых систем о переезде

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

    8.1. Смена адреса в Google Search Console

    Для смены адреса в GSC вам сперва нужно зарегистрировать новый сайт, а затем зайти в настройки старого домена и выбрать «Изменение адреса».

    Выберите новый домен из выпадающего списка и пройдитесь по всем пунктам чеклиста Google Search Console. После этого вы подтвердите отправку запроса на смену адреса.

    8.2. Смена адреса в Яндекс.Вебмастер

    В панели для вебмастеров поисковой системы Яндекс процедура переезда выполняется почти аналогичным образом. Вы можете без труда указать новый адрес в разделе «Индексирование» → «Переезд сайта». Желательно (но не обязательно), чтобы к этому моменту новый домен уже был зарегистрирован в вашем аккаунте «Вебмастера».

    8.3. Смена адреса в Google Analytics

    Для смены адреса в настройках Google Analytics зайдите в раздел с настройками и выберите «Настройки аккаунта» → «Настройки ресурса». В этом разделе вы найдёте поле «URL по умолчанию», в котором необходимо будет указать новый адрес.

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

    8.4. Смена адреса в Яндекс.Метрике

    Для изменения домена в аккаунте Яндекс.Метрики зайдите в раздел «Настройка» и на вкладке «Сводка» пропишите новый адрес сайта.

    9. Проверка кодов отслеживания

    10. Финальная проверка на ошибки

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

    10.1. Проверка страниц со старого домена

    После успешного переноса контента и настройки переадресации со старого домена на новый обязательно запустите сканирование по списку старых URL. Это необходимо для проверки редиректов, а также поиска возможных битых ссылок и перенаправлений с некорректным кодом ответа (допусти́м только 301 Moved Permanently).

    В рамках проверки краулер покажет, нет ли на сайте:

    • цепочек редиректов,
    • не 301 редиректов,
    • битых редиректов.

    10.2. Проверка страниц на новом домене

    Эту проверку вы аналогичным образом можете провести с помощью десктопного краулера. Желательно, чтобы на сайте вообще не оказалось ошибок высокой и средней критичности, но особенно важно убедиться, что на нём нет следующих проблем:

      Некорректные коды ответа сервера.
      На сайте может быть только 3 варианта кодов ответа: 200 OK, 301 Moved Permanently и 200 OK & Canonicalized. Четвёртого, пятого и шестого не дано. Все прочие коды, включая все 4хх и 5хх, будут свидетельствовать об ошибках в настройках сайта и препятствовать его индексации поисковиками. Исключения составляют лишь страницы с кодами 200 OK & Disallowed и 200 OK & Noindex / Nofollow, которые должны присутствовать на сайте, но не должны попадать в индекс.

  • Дубликаты.
    Если уж вам приходится осуществлять в процессе переезда масштабные технические работы, то рекомендуем не откладывать в долгий ящик исправление старых технических ошибок и сделать всё «одним махом». К их числу относятся все существующие виды дубликатов: дубли страниц, текстового содержимого, H1, Title и Description.
  • Отсутствующие метаданные.
    Наверняка у вас были веские причины для переноса сайта на новый домен, и, скорее всего, среди них значится улучшение позиций сайта в органике и повышение CTR. Чтобы ваши усилия не были напрасными, убедитесь, что в сниппете будет красоваться не только обновлённый URL, но и корректный Title с грамотно прописанным Description.
  • Ошибки в карте сайта.
    Как говорится, shit happens, а потому ошибки могут обнаружиться даже в карте сайта. Их наличие может пагубно сказаться на индексации сайта поисковыми роботами, особенно если у вас сайт-гигант с десятками тысяч страниц. Чтобы проверить карту, в списке встроенных инструментов Netpeak Spider выберите «Валидатор XML Sitemap» и укажите адрес карты для проверки.
  • Коротко о главном

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

    Google перенаправит отчеты со старой Search Console на новую

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

    Нажав кнопку «Принять и продолжить», вы соглашаетесь с Политики конфиденциальности

    Мы запустили рейтинг зарплат интернет-маркетологов! Прими участие в анонимном опросе.

    How-to – Читать 11 минут – 14 марта 2020

    В инструментах Google Search Console и Яндекс.Вебмастер есть все необходимое, чтобы проверить сайт. Отчеты о статистике сканирования web-ресурса, количество показов и кликов, средняя позиция в поиске.

    В отчетах сканирования вы можете обнаружить ошибки. Также дается краткое объяснение для вебмастера: отчего они появились, как их решать.

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

    Желательно кроме консолей проверять сайт другими средствами сканирования и аудирования сайта.

    Google делит ошибки на 2 типа:

    • ошибки сайта — появляются, если бот не может обойти весь ресурс;
    • ошибки URL — говорят о проблеме с отдельными страницами.

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

    DNS, или Domain Name System. DNS — это система доменных имен, данные которой используются роботами при посещении ресурсов. Если возникают ошибки DNS, значит, поисковик не может связаться с сайтом, а пользователи его найти и открыть.

    Google не сразу сообщает об ошибке: он может пару раз вернуться, и, если попытки будут неудачны, выдаст сообщение в консоли.

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

    Нужно ответственно подходить к выбору хостинг-провайдера — он должен обеспечивать бесперебойную работу в любой ситуации.

    Ошибки сервера также необходимо устранять в первую очередь. Если в настоящий момент веб-сайт работает (проверьте через сканер Google, который будет доступен до марта 2020), а в консоли появилось сообщение об ошибке, возможно, она была выявлена ранее.

    Задача вебмастера — убедиться, что ситуация не повторится. Если в новой версии консоли не появится аналог данного инструмента, используйте программы-сканеры. Например, Netpeak Spider.

    Что может случиться?

      таймаут — случается, если истекло время ожидания соединения, код ошибки 408;

    усеченные заголовки — робот подключился, но не полностью получил заголовки ответа сервера, код ошибки 304;

    сброс подключения — запрос обработан сервером, но бот не успел получить результат, код ошибки 205;

    усеченное тело ответа — получен не полностью из-за преждевременного отключения, код ошибки 206;

    сбой подключения — возникает, если CDN или сеть доставки контента не может подключиться к веб-серверам, код ошибки 522. Другими словами, компьютер не может подключиться к серверу;

    отсутствие отклика означает, что сервер или прокси-сервер не получил ответ от вышестоящего сервера, чтобы завершить свой запрос, код ошибки 504;

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

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

    Появляется, когда файл недоступен для поискового робота. Ошибка «недоступно» возникает в случае, когда брандмауэр блокирует Google. Если ее не решать, сканирование будет откладываться.

    Корневой документ robots.txt для веб-ресурса создают с целью прописать директивы и закрыть посещение поисковых роботов к техническим web-страницам и другим страницам, которые не содержат полезной и уникальной информации. А также скорректировать процесс сканирования и предоставить путь к карте sitemap для лучшего обхода.

    Данный файл дает возможность снизить количество запросов к вашему серверу, соответственно, нагрузку.

    Для решения проблемы достаточно проверить, правильно ли настроен robots.txt:

    • указаны ли правильно разделы и документы, которые запрещено обрабатывать;
    • доступен ли файл или отдает 404 ответ сервера.

    Появляются, когда Googlebot не смог обработать отдельные страницы из-за неправильных редиректов (цепочки бесконечные редиректов; перенаправлений на битые страницы), закрытия в robots.txt, ошибки необновленной sitemap.xml. Отчет можно получить в Search Console. Для этого перейдите в раздел Покрытие из главного меню, как показано на скриншоте выше.

    Устранять подобные неполадки проще: при их анализе можно посмотреть конкретные страницы, с которыми возникли проблемы.

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

    Ошибка «Soft 404». Когда возникает:

      cтраница, которая была удалена, не возвращает код ответа HTTP 404 по требованию пользователя или бота;

    несуществующая страница перенаправляет пользователей на нерелевантную страницу. Например, если поставили редирект с категории велосипеды на категорию мотоциклы;

    когда страница пустая, на ней нет контента.

    Чтобы устранить ошибки, следует:

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

    Ошибка 404. Она возникает, когда робот сканировал несуществующую страницу, потому что на нее ссылались в других документах, в том числе из sitemap.xml. Есть внутренние и внешние 404 ошибки:

    • если ссылка на удаленную страницу стоит внутри сайта, то разработчики могут ее убрать сами;
    • если ссылка стоит извне, разработчики вместе с SEO-специалистом или контент-менеджером могут настроить 301 редирект в файле .htaccess, чтобы передать ее ссылочный вес на какую-либо релевантную страницу.


    Доступ запрещен.
    Возникает, когда у робота нет доступа к URL. Например, в файле robots.txt использованы директивы — запрет на сканирование всего ресурса или отдельных каталогов, разделов. Либо хостер заблокировал доступ к сайту.

    Чтобы устранить проблему, достаточно убрать причину, препятствующую доступу:

    Старая Google Search Console больше не доступна

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

    С этого момента, если вы попытаетесь получить доступ к старой домашней странице или панели мониторинга, вы будете перенаправлены на соответствующие страницы Консоли поиска.

    Теперь вы можете получить доступ к устаревшим отчетам на данный момент в новой версии в разделе «устаревшие инструменты и отчеты», вот снимок экрана:

    Добавить комментарий