Ошибка переадресации google search console

Ошибки невыполнения перехода

Что такое ошибка «Переход не выполнен»

В этой категории перечислены URL, на которые робот Googlebot не смог перейти, а также указаны возможные причины. Некоторые из этих причин перечислены ниже.

Flash, JavaScript, активное содержание

Некоторые средства, используемые на сайте, такие как JavaScript, файлы cookie, идентификаторы сеансов, фреймы, DHTML или Flash, могут затруднять процесс его сканирования роботами поисковых систем. Выполните следующие проверки:

  • Используйте для проверки сайта текстовый браузер (например, Lynx), поскольку большинство поисковых систем видят сайт точно так же, как Lynx. Если вы не сможете просмотреть его целиком из-за таких элементов, как JavaScript, файлы cookie, идентификаторы сеансов, фреймы, DHTML или Flash, то и сканерам поисковых систем тоже будет нелегко его обработать.
  • Используйте инструмент Просмотреть как Googlebot, чтобы увидеть свой сайт в точности так, как его видит робот Googlebot.
  • Если вы используете динамические страницы (например, если в URL содержится символ «?»), следует иметь в виду, что не все сканеры поисковых систем сканируют динамические страницы так же успешно, как и статические. Мы рекомендуем использовать краткие значения параметров и не злоупотреблять ими. Если вы знаете, как используются параметры на вашем сайте, вы можете сообщить Google, как их следует обрабатывать.

Переадресация

  • Если на сайте постоянно используется переадресация с одних страниц на другие, убедитесь, что возвращается правильный код статуса HTTP (301 Окончательно перемещено).
  • По возможности используйте абсолютные ссылки вместо относительных. (Например, ссылаясь на другую страницу своего сайта, создавайте ссылку на www.example.ru/mypage.html, а не просто на mypage.html.)
  • Рекомендуется, чтобы на каждую страницу сайта вела хотя бы одна статическая текстовая ссылка. Уменьшайте число переадресаций, необходимых для перехода с одной страницы на другую.
  • Убедитесь, что переадресация указывает на правильные страницы! Некоторые страницы указывают сами на себя (ошибка циклической переадресации) или на недействительные URL.
  • Не включайте URL с переадресацией в файлы Sitemap.
  • Длина URL должна быть по возможности минимальной. Убедитесь, что в URL переадресации автоматически не добавляется дополнительная информация (например, идентификатор сеанса).
  • Убедитесь, что поисковые роботы могут сканировать ваш сайт без идентификаторов сеансов и без аргументов, которые позволяют отслеживать пути их передвижения по сайту.

Эта информация оказалась полезной?

Как можно улучшить эту статью?

Источник
  • Как проходит индексация в Google
  • Обнаружение
  • Сканирование
  • Индексация
  • Ранжирование
  • Как пользоваться Отчётом об индексировании в Google Search Console
  • Фильтры «Все обработанные страницы» vs «Все отправленные страницы»
  • Проверка статусов URL
  • Что учесть при использовании отчёта
  • Как часто смотреть Отчёт
  • Дополнительно: инструмент проверки URL
  • Статус «Ошибка»
  • Ошибка сервера (5xx)
  • Ошибка переадресации
  • Доступ к отправленному URL заблокирован в файле robots.txt
  • Страница, связанная с отправленным URL, содержит тег noindex
  • Отправленный URL возвращает ложную ошибку 404
  • Отправленный URL возвращает ошибку 401 (неавторизованный запрос)
  • Отправленный URL не найден (ошибка 404)
  • При отправке URL произошла ошибка 403
  • URL заблокирован из-за ошибки 4xx (ошибка клиента)
  • Статус «Без ошибок, есть предупреждения»
  • Проиндексировано, несмотря на блокировку в файле robots.txt
  • Страница проиндексирована без контента
  • Статус «Страница без ошибок»
  • Страница была отправлена в Google и проиндексирована
  • Страница проиндексирована, но её нет в файле Sitemap 
  • Статус «Исключено»
  • Индексирование страницы запрещено тегом noindex
  • Индексирование страницы запрещено с помощью инструмента удаления страниц
  • Заблокировано в файле robots.txt 
  • Страница не проиндексирована вследствие ошибки 401 (неавторизованный запрос)
  • Страница просканирована, но пока не проиндексирована
  • Обнаружена, не проиндексирована
  • Вариант страницы с тегом canonical
  • Страница является копией, канонический вариант не выбран пользователем
  • Страница является копией, канонические версии страницы, выбранные Google и пользователем, не совпадают
  • Не найдено (404)
  • Страница с переадресацией
  • Ложная ошибка 404
  • Страница является копией, отправленный URL не выбран в качестве канонического
  • Страница заблокирована из-за ошибки 403 (доступ запрещён)
  • URL заблокирован из-за ошибки 4xx (ошибка клиента)
  • Ключевые выводы

    • Подробный SEO-гайд по Отчёту об индексировании Google Search Console. Разберёмся, как проверить индексацию сайта с его помощью, как «читать» статусы URL, какие ошибки можно обнаружить и как их исправить.

    Перевод с сайта onely.com.

    В Отчёте вы можете получить данные о сканировании и индексации всех URL-адресов, которые Google смог обнаружить на вашем сайте. Он поможет отследить, добавлен ли сайт в индекс, и проинформирует о технических проблемах со сканированием и индексацией.

    Но перед тем, как говорить об Отчёте, вспомним все этапы индексации страницы в Google.

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

    Обнаружение

    Перед тем, как просканировать страницу, Google должен её обнаружить. Он может сделать это несколькими способами. 

    Наиболее распространённые — с помощью внутренних или внешних ссылок или через карту сайта (файл Sitemap.xml).

    Сканирование

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

    Главный аспект в этом вопросе — краулинговый бюджет, который представляет собой лимит времени и ресурсов, который поисковая система готова «потратить» на сканирование вашего сайта. 

    Что такое «краулинговый бюджет, как его проверить и оптимизировать

    Индексация

    В процессе индексации Google оценивает качество страницы и добавляет её в индекс — базу данных, где собраны все страницы, о которых «знает» Google.

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

    Даже если Google нашёл и просканировал страницу, это не означает, что она обязательно будет проиндексирована.

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

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

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

    Ранжирование

    Только проиндексированные страницы могут появиться в результатах поиска и ранжироваться.

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

    Теперь перейдём к Отчёту.

    Как пользоваться Отчётом об индексировании в Google Search Console

    Чтобы просмотреть Отчёт, авторизуйтесь в своём аккаунте Google Search Console. Затем в меню слева выберите «Покрытие» в секции «Индекс»:

    Как найти Отчёт об индексировании в Google Search Console

    Как найти Отчёт об индексировании в Google Search Console

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

    Статусы URL на странице Отчёта

    Статусы URL на странице Отчёта

    Вы увидите четыре статуса URL-адресов:

    • Ошибка — критическая проблема сканирования или индексации.
    • Без ошибок, есть предупреждения — URL-адреса проиндексированы, но содержат некоторые некритичные ошибки. 
    • Страница без ошибок — страницы проиндексированы корректно.
    • Исключено — страницы, которые не были проиндексированы из-за проблем (это самый важный раздел, на котором нужно сфокусироваться).

    Фильтры «Все обработанные страницы» vs «Все отправленные страницы»

    В верхнем углу вы можете отфильтровать, какие страницы хотите видеть:

    Фильтр отображаемых страниц

    Фильтр отображаемых страниц

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

    Фильтр «Все отправленные страницы» включает только URL-адреса, добавленные с помощью файла Sitemap.

    В чём разница?

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

    Как пример — URL с параметрами на сайтах eCommerce. Googlebot может найти их разными способами, но не в карте сайта.

    Так что когда открываете Отчёт, убедитесь, что смотрите нужные данные.

    Проверка статусов URL

    Чтобы увидеть подробную информацию о проблемах, обнаруженных для каждого статуса, посмотрите «Сведения» под графиком:

    Раздел «Сведения»

    Раздел «Сведения»

    Тут показан статус, тип проблемы и количество затронутых страниц. Обратите внимание на столбец «Проверка» — после исправления ошибки, вы можете попросить Google проверить URL повторно.

    Например, если кликнуть на первую строку со статусом «Предупреждение», то вверху появится кнопка «Проверить исправление»:

    Проверка исправлений

    Проверка исправлений

    Вы также можете увидеть динамику каждого статуса: увеличилось, уменьшилось или осталось на том же уровне количество URL-адресов в этом статусе.

    Если в «Сведениях» кликнуть на любой статус, вы увидите количество адресов, связанных с ним. Кроме того, вы сможете посмотреть, когда каждая страница была просканирована (но помните, что эта информация может быть неактуальна из-за задержек в обновлении отчётов). 

    Подробная информация о сканировании в Сведениях

    Подробная информация о сканировании в Сведениях

    Что учесть при использовании отчёта

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

    Как часто смотреть Отчёт

    Обычно достаточно делать это раз в месяц.

    Но если вы внесли значимые изменения на сайте, например, изменили макет страницы, структуру URL или сделали перенос сайта, мониторьте Отчёт чаще, чтобы вовремя поймать негативное влияние изменений.

    Рекомендую делать это хотя бы раз в неделю и обращать особое внимание на статус «Исключено». 

    Дополнительно: инструмент проверки URL

    В Search Console есть ещё один инструмент, который даст ценную информацию о сканировании и индексации страниц вашего сайта — Инструмент проверки URL.

    Он находится в самом верху страницы в GSC:

    Инструмент проверки URL

    Инструмент проверки URL

    Просто вставьте URL, который вы хотите проверить, в эту строку и увидите данные по нему. Например:

    Результат проверки URL

    Результат проверки URL

    Инструментом можно пользоваться для того, чтобы:

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

    Если в Отчёте об индексировании обнаружены какие-то проблемы со страницами, используйте Инструмент, чтобы тщательнее проверить их и понять, что именно нужно исправить. 

    Статус «Ошибка»

    Под этим статусом собраны URL, которые не были проиндексированы из-за ошибок.

    Если вы видите проблему с пометкой «Отправлено», то это может касаться только URL, которые были отправлены через карту сайту. Убедитесь, что в карте сайте содержатся только те страницы, которые вы действительно хотите проиндексировать.

    Ошибка сервера (5xx)

    Эта проблема говорит об ошибке сервера со статусом 5xx, например, 502 Bad Gateway или 503 Service Unavailable.

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

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

    Как исправить ошибки сервера — рекомендации Google

    Ошибка переадресации

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

    Ошибки переадресации могут указывать на такие проблемы:

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

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

    Доступ к отправленному URL заблокирован в файле robots.txt

    Эти страницы есть в файле Sitemap, но заблокированы в файле robots.txt. 

    Robots.txt — это файл, который содержит инструкции для поисковых роботов о том, как сканировать ваш сайт. Чтобы URL был проиндексирован, Google нужно для начала его просканировать. 

    Что делать. Если вы видите такую ошибку, перейдите в файл robots.txt и проверьте настройку директив. Убедитесь, что страницы не закрыты через noindex.

    Страница, связанная с отправленным URL, содержит тег noindex

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

    Что делать. Если страница должна быть проиндексирована, уберите noindex.

    Отправленный URL возвращает ложную ошибку 404

    Ложная ошибка 404 означает, что страница возвращает статус 200 OK, но её содержимое может указывать на ошибку. Например, страница пустая или содержит слишком мало контента.

    Что делать. Проверьте страницы с ошибками и посмотрите, есть ли возможность изменить контент или настроить редирект.  

    Отправленный URL возвращает ошибку 401 (неавторизованный запрос)

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

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

    Отправленный URL не найден (ошибка 404)

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

    Что делать. Если вы увидели эту проблему в отчёте, перейдите на затронутые страницы и проверьте, можете ли вы исправить ошибку. Например, настроить 301-й редирект на рабочую страницу. 

    Дополнительно убедитесь, что файл Sitemap не содержит URL, которые возвращают какой-либо другой код состояния HTTP кроме 200 OK. 

    При отправке URL произошла ошибка 403

    Код состояния 403 Forbidden означает, что сервер понимает запрос, но отказывается авторизовывать его. 

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

    URL заблокирован из-за ошибки 4xx (ошибка клиента)

    Страница может быть непроиндексирована из-за других ошибок 4xx, которые не описаны выше. 

    Что делать. Чтобы понять, о какой именно ошибке речь, используйте Инструмент проверки URL. Если устранить ошибку невозможно, уберите URL из карты сайта. 

    Статус «Без ошибок, есть предупреждения»

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

    Проиндексировано, несмотря на блокировку в файле robots.txt

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

    Что делать. Проверьте эти страницы. Если они всё же должны быть проиндексированы, то обновите файл robots.txt, чтобы Google получил к ним доступ. Если не должны — поищите ссылки, которые на них указывают. Если вы хотите, чтобы URL были просканированы, но не проиндексированы, добавьте директиву noindex.

    Страница проиндексирована без контента

    URL проиндексированы, но Google не смог прочитать их контент. Это может быть из-за таких проблем:

    • Клоакинг — маскировка контента, когда Googlebot и пользователи видят разный контент.
    • Страница пустая.
    • Google не может отобразить страницу.
    • Страница в формате, который Google не может проиндексировать.

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

    Статус «Страница без ошибок»

    Здесь показываются страницы, которые корректно проиндексированы. Но на эту часть Отчёта всё равно нужно обращать внимание, чтобы сюда не попали страницы, которые не должны были оказаться в индексе. Тут тоже есть два статуса.

    Страница была отправлена в Google и проиндексирована

    Это значит, что страницы отправлена через Sitemap и Google её проиндексировал.

    Страница проиндексирована, но её нет в файле Sitemap 

    Это значит, что страница проиндексирована даже несмотря на то, что её нет в Sitemap. Посмотрите, как Google нашёл эту страницу, через Инструмент проверки URL. 

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

    Статус «Исключено»

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

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

    Индексирование страницы запрещено тегом noindex

    Что делать. Тут то же самое — если страница и не должна быть проиндексирована, то всё в порядке. Если должна — удалите noindex. 

    Индексирование страницы запрещено с помощью инструмента удаления страниц

    У Google есть Инструмент удаления страниц. Как правило с его помощью Google удаляет страницы из индекса не навсегда. Через 90 дней они снова могут быть проиндексированы. 

    Что делать. Если вы хотите заблокировать страницу насовсем, вы можете удалить её, настроит редирект, внедрить авторизацию или закрыть от индексации с помощью тега noindex.

    Заблокировано в файле robots.txt 

    У Google есть Инструмент проверки файла robots.txt, где вы можете в этом убедиться. 

    Что делать. Если эти страницы и не должны быть в индексе, то всё в порядке. Если должны — обновите файл robots.txt.

    Помните, что блокировка в robots.txt — не стопроцентный вариант закрыть страницу от индексации. Google может проиндексировать её, например, если найдёт ссылку на другой странице. Чтобы страница точно не была проиндексирована, используйте директиву noindex. 

    Подробнее о блокировке индексирования при помощи директивы noindex

    Страница не проиндексирована вследствие ошибки 401 (неавторизованный запрос)

    Обычно это происходит на страницах, защищённых паролем. 

    Что делать. Если они и не должны быть проиндексированы, то ничего делать не нужно. Если вы не хотите, чтобы Google обнаруживал эти страницы, уберите существующие внутренние и внешние ссылки на них.

    Страница просканирована, но пока не проиндексирована

    Это значит, что страница «ждёт» решения. Для этого может быть несколько причин. Например, с URL нет проблем и вскоре он будет проиндексирован. 

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

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

    Что делать. Для начала убедитесь, что это не ошибка. Проверьте, действительно ли URL не проиндексирован, в Инструменте проверки URL или через инструмент «Индексация» в Анализе сайта в Топвизоре. Они показывают более свежие данные, чем Отчёт. 

    Как исправить ошибку, когда страница просканирована, но не проиндексирована (на английском)

    Обнаружена, не проиндексирована

    Это значит, что Google увидел страницу, например, в карте сайта, но ещё не просканировал её. В скором времени страница может быть просканирована.

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

    Что такое краулинговый бюджет и как его оптимизировать

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

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

    Вариант страницы с тегом canonical

    Эти URL — дубли канонической страницы, отмеченные правильным тегом, который указывает на основную страницу.

    Что делать. Ничего, вы всё сделали правильно.

    Страница является копией, канонический вариант не выбран пользователем

    Это значит, что Google не считает эти страницы каноническими. Посмотрите через Инструмент проверки URL какую страницу он считает канонической. 

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

    Страница является копией, канонические версии страницы, выбранные Google и пользователем, не совпадают

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

    Что делать. В этом случае может помочь объединение URL повторяющихся страниц.

    Как правильно настроить внутренние ссылки на сайте

    Не найдено (404)

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

    Что делать. Если вы и не хотели, чтобы Google индексировал страницу, то ничего делать не нужно. Другой вариант — поставить 301-й редирект на работающую страницу. 

    Страница с переадресацией

    Эта страница редиректит на другую страницу, поэтому не была проиндексирована. Обычно, такие страницы не требуют внимания.

    Что делать. Эти страницы и не должны быть проиндексированы, так что делать ничего не нужно.

    Для постоянного редиректа убедитесь, что вы настроили перенаправление на ближайшую альтернативную страницу, а не на Главную. Редирект страницы с 404 ошибкой на Главную может определять её как soft 404.

    @JohnMu what does Google do when a site redirects all its 404s to the homepage? Seeing more and more sites do this and it’s such an anti-pattern.

    — Joost de Valk (@jdevalk) January 7, 2019

    Yeah, it’s not a great practice (confuses users), and we mostly treat them as 404s anyway (they’re soft-404s), so there’s no upside. It’s not critically broken/bad, but additional complexity for no good reason — make a better 404 page instead.

    — ? John ? (@JohnMu) January 8, 2019

    Ложная ошибка 404

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

    Что делать. Для исправления проблемы вы можете:

    • Добавить или улучшить контент таких страниц.
    • Настроить 301-й редирект на ближайшую альтернативную страницу.
    • Настроить сервер, чтобы он возвращал правильный код ошибки 404 или 410.

    Страница является копией, отправленный URL не выбран в качестве канонического

    Эти страницы есть в Sitemap, но для них не выбрана каноническая страница. Google считает их дублями и канонизировал их другими страницами, которые определил самостоятельно. 

    Что делать. Выберите и добавьте канонические страницы для этих URL.

    Страница заблокирована из-за ошибки 403 (доступ запрещён)

    Что делать. Если Google не может получить доступ к URL, лучше закрыть их от индексации с помощью метатега noindex или файла robots.txt. 

    URL заблокирован из-за ошибки 4xx (ошибка клиента)

    Сервер столкнулся с ошибкой 4xx, которая не описана выше. 

    Гайд по ошибкам 4xx и способы их устранения (на английском)

    Попробуйте исправить ошибки или оставьте страницы как есть. 

    Ключевые выводы

    1. Проверяя данные в Отчёте помните, что не все страницы сайта должны быть просканированы и проиндексированы. 
    2. Закрыть от индексации некоторые страницы может быть так же важно, как и следить за тем, чтобы нужные страницы сайта индексировались корректно. 
    3. Отчёт об индексировании показывает как критичные ошибки, так и неважные, которые не обязательно требуют действий с вашей стороны.
    4. Регулярно проверяйте Отчёт, но только для того, чтобы убедиться, что всё идёт по плану. Исправляйте только те ошибки, которые не соответствуют вашей стратегии индексации.

    При переадресации выполняется переход по новому URL вместо исходного. Это указывает посетителям сайта и поисковым роботам Google на то, что страница была перемещена. Использовать переадресацию целесообразно в следующих случаях:

    • Вы перенесли свой сайт в другой домен и хотите, чтобы это вызвало как можно меньше проблем и неудобств.
    • Одинаковые разделы вашего сайта находятся на нескольких разных URL. Например, для главной страницы используются следующие варианты: https://example.com/home, http://home.example.com и https://www.example.com. Выберите один из них в качестве канонического и используйте переадресацию, чтобы перенаправлять на него трафик с других URL.
    • Вы собираетесь объединить два сайта и хотите, чтобы вместо страниц с устаревшими URL открывались актуальные страницы.
    • Вы удалили определенную страницу и хотите перенаправлять пользователей на другую.

    Типы переадресации

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

    • Постоянная переадресация: в результатах поиска показывается конечная страница.
    • Временная переадресация: в результатах поиска показывается исходная страница.

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

    Типы переадресации
    Постоянная

    Робот Googlebot переходит на другой URL, и алгоритм индексирования расценивает переадресацию как вескую причину считать конечную страницу канонической.

    HTTP 301 (moved permanently)

    Настраивается серверная переадресация.

    HTTP 308 (moved permanently)
    meta refresh (0 секунд)

    Настраивается переадресация meta refresh.
    HTTP refresh (0 секунд)
    Свойство location в JavaScript

    Настраивается переадресация с применением JavaScript.

    Crypto redirect – переадресация с помощью ссылки

    Ознакомьтесь с дополнительными сведениями о переадресации с помощью ссылки (crypto redirect).

    Временная

    Робот Googlebot переходит по новому URL, и алгоритм индексации интерпретирует это действие как недостаточно вескую причину считать конечную страницу канонической.

    HTTP 302 (found)

    Настраивается серверная переадресация.

    HTTP 303 (see other)
    HTTP 307 (temporary redirect)
    meta refresh (более 0 секунд)

    Настраивается переадресация meta refresh.
    HTTP refresh (более 0 секунд)

    Серверная переадресация

    Для настройки требуется доступ к файлам конфигурации сервера (например, к файлу .htaccess на языке Apache) или возможность задавать заголовки переадресации с помощью серверных скриптов (например, на языке PHP). Вы можете настроить на сервере как постоянную, так и временную переадресацию.

    Постоянная переадресация

    Если вы хотите, чтобы в результатах поиска показывался новый URL страницы, рекомендуем вам использовать постоянную серверную переадресацию. Это самый надежный способ направить поисковых роботов Google и пользователей на страницу с нужным адресом. Коды статуса 301 и 308 означают, что страница перемещена навсегда.

    Временная переадресация

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

    Инструкции по настройке

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

    Чтобы настроить постоянную переадресацию с помощью PHP, используйте функцию header(). До вызова этой функции не следует отправлять клиенту какие-либо данные. Пример: 

    header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();

    Пример кода PHP для настройки временной переадресации: 

    header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

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

    • Apache: ознакомьтесь с руководством по использованию файлов .htaccess, руководством по переопределению URL и информацией о модуле mod_alias на сайте Apache.
      C помощью модуля mod_alias можно настраивать простейшую переадресацию: 

      # Permanent redirect:
Redirect permanent "/old" "https://example.com/new"

# Temporary redirect:
Redirect temp "/two-old" "https://example.com/two-new"

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

      RewriteEngine on
# redirect the service page to a new page with a permanent redirect
RewriteRule   "^/service$"  "/about/service"  [R=301]

# redirect the service page to a new page with a temporary redirect
RewriteRule   "^/service$"  "/about/service"  [R]

    • nginx: ознакомьтесь с информацией о создании правил переопределения URL в блоге nginx. Как и при работе с Apache, переадресацию можно настраивать по-разному. Один из способов: 

      location = /service {
  # for a permanent redirect
  return 301 $scheme://example.com/about/service

  # for a temporary redirect
  return 302 $scheme://example.com/about/service
}

      Для более сложных случаев используйте директиву rewrite: 

      location = /service {
  # for a permanent redirect
  rewrite service?name=$1 ^service/offline/([a-z]+)/?$ permanent;

  # for a temporary redirect
  rewrite service?name=$1 ^service/offline/([a-z]+)/?$ redirect;
}
    • За информацией о других веб-серверах обращайтесь к обслуживающей их компании или хостинг-провайдеру. Вы также можете поискать нужное руководство в интернете. Пример запроса: «переадресация на сервере LiteSpeed».

    Если на вашей платформе нельзя настроить серверную переадресацию, рассмотрите в качестве альтернативы переадресацию meta refresh. Google различает два типа переадресации meta refresh:

    • Мгновенная переадресация meta refresh выполняется сразу при загрузке страницы в браузере. Система Google Поиска интерпретирует такую переадресацию meta refresh как постоянную.
    • Отложенная переадресация meta refresh выполняется через несколько секунд после загрузки страницы. Количество секунд указывает владелец сайта. Система Google Поиска интерпретирует такую переадресацию meta refresh как временную.

    Настроить переадресацию meta refresh можно в элементе <head> HTML-кода страницы или в HTTP-заголовке с помощью серверного кода. Пример мгновенной переадресации типа meta refresh, заданной в коде <head> HTML-страницы: 

    <!doctype html>
<html>
  <head>
  <meta http-equiv="refresh" content="0; url=https://example.com/newlocation">
  <title>Example title</title>
  <!--...-->

    Пример эквивалентной переадресации, заданной в HTTP-заголовке с помощью серверного скрипта: 

    HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocation
...

    Чтобы выполнялась отложенная переадресация, которая считается временной, укажите нужное количество секунд в атрибуте content: 

    <!doctype html>
<html>
  <head>
  <meta http-equiv="refresh" content="5; url=https://example.com/newlocation">
  <title>Example title</title>
  <!--...-->

    Переадресация с помощью JavaScript-свойства location

    Система Google Поиска интерпретирует и выполняет код JavaScript после сканирования страницы, используя сервис отрисовки веб-страниц (Web Rendering Service).

    Чтобы настроить переадресацию такого типа, добавьте в раздел head HTML-страницы блок script и укажите конечный URL в качестве значения свойства location. Пример: 

    <!doctype html>
<html>
  <head>
    <script>
      window.location.href = "https://www.example.com/newlocation";
    </script>
    <title>Example title</title>
    <!--...-->

    Crypto redirect – переадресация с помощью ссылки

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

    <a href="https://newsite.example.com/newpage.html">We moved! Find the content on our new site!</a>

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

    Альтернативные URL

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

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

    Управление индексированием в Google Search Console — обзор всех возможностей

    Загрузка…

    Search Console — основной опорный инструмент для продвижения сайтов в Google (и не только). По функциональности консоль может уступать некоторым более продвинутым SEO-инструментам, но у нее есть три ключевых преимущества: она бесплатная, интуитивно понятная и самое важное – предоставляет данные прямо от Google. Через GSC, не опираясь на гипотезы, можно узнать, как алгоритмы оценивают ваш сайт, при этом все  рекомендации по улучшению технической части вебмастер получает напрямую от первого лица, т. е. Google. И в этом плане Search Console вряд ли когда-нибудь превзойдет какой-либо коммерческий SEO-инструмент.

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

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

    Работа с запросами, безусловно, важна для эффективного продвижения сайта в поиске, но семантика – далеко не все, на чем держится успех в SEO. Прежде чем страницы начнут ранжироваться по релевантным запросам, они должны быть правильно просканированы и проиндексированы поисковыми роботами. Это очень важный процесс, и здесь Google Search Console является самым надежным информатором и техническим помощником. В вебмастерке всегда можно узнать, какие из документов были проиндексированы, а какие нет, когда совершался последний обход сайта, на каких страницах есть проблемы и как их лучше всего устранить по мнению Google. Об этих и других функциях индексирования в GSC – рассказываем в представленном материале.

    Отслеживаем индексацию страниц и исправляем ошибки

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

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

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

    Чтобы проверить, имеются ли на сайте проблемы с индексацией, откройте Google Search Console и перейдите на вкладку Индекс → Покрытие – здесь будет доступен статус всех страниц сайта.

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

    Ошибки. Типичные проблемы и как их исправить

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

    Под графиком в разделе «Сведения» система уведомляет, какая именно проблема с индексированием присутствует на сайте, например:

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

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

    URL-адреса недоступны для индексирования 

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

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

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

    Неиндексируемая страница закрыта директивой noindex. Решение: удалить тег noindex из HTML-кода или из заголовка ответа HTTP X-Robots-Tag.

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

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

    URL возвращает ложную ошибку (soft 404). Такое происходит, когда страница физически существует (сервер помечает ее статусом OK), но Google решил, что URL имеет статус 404 (страница не найдена). Как правило, это происходит при отсутствии контента на странице (или его незначительности), а также из-за манипуляций с редиректами, когда внутренняя переадресация ведется на тематически НЕблизкую страницу. Решение: проверить страницу на предмет «тонкого» контента или нерелевантных редиректов.

    URL возвращает ошибку 401 (неавторизованный запрос). Это значит, что робот Google не может получить доступ к нужной странице из-за запрашиваемой авторизации. Решение: отменить требование авторизации либо разрешить Googlebot доступ к странице.

    URL возвращает ошибку 403. Googlebot выполняет вход на сервер, но ему не предоставлен доступ к контенту. Решение: если вы хотите, чтобы страница попала в индекс, откройте к ней доступ анонимным посетителям.

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

    Наличие ошибок переадресации

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

    Решение: проверьте URL на предмет некорректно работающих 301- или 302-редиректов и примите меры по их отладке.

    Подробнее по теме:
    FAQ по 301-редиректу. Как перенаправления соотносятся с SEO: настройка, отслеживание проблем, сценарии использования редиректов

    Проблемы на стороне хостера

    Ошибка 5xx возникает, когда поисковым роботам Google не удается получить доступ к серверу. Возможно, сервер вышел из строя, истекло время ожидания или он был недоступен, когда Googlebot проводил обход сайта (скорее всего, причина именно  в этом).
    Решение: проверьте URL с помощью инструмента «Проверка URL-адреса», отображается ли ошибка в настоящее время. Если сервер в порядке, отправьте страницу на переобход, в противном случае внимательно ознакомьтесь с тем, что предлагает Google для решения этой проблемы  или свяжитесь со своим хостинг-провайдером.

    Без ошибок, есть предупреждения

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

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

    Проиндексировано, несмотря на блокировку в файле robots.txt

    Это, пожалуй, самая распространенная причина, по которой страницы сайта попадают в желтую категорию проблем индексирования. Многие, как правило, еще неопытные вебмастера и SEO-специалисты ошибочно полагают, что robots.txt — это правильный механизм для сокрытия страниц от попадания в индекс Google. Это не так. Добавление директив в служебный файл robots.txt полностью не запрещает индексирование указанных URL. Вебмастера используют этот способ в основном, чтобы избежать лишних запросов со стороны краулеров и не перегружать сайт.

    Чтобы гарантированно исключить попадание нежелательных страниц в индекс, используют другие механизмы: добавление noindex в HTML-код страницы или настройку HTTP-заголовка X-Robots-Tag. Запреты в robots.txt поисковик же расценивает исключительно  как рекомендации: он не будет сканировать страницу, отклоненную в роботс, во время обхода сайта, но эта же страница может быть проиндексирована, если на нее ведут другие ссылки. Отсюда следует один очень важный момент: из-за запрета в robots.txt, страницы могут попадать в индекс в неполной версии, поскольку поисковые роботы смогли просканировать лишь отдельные фрагменты «закрытого» документа.

    Как решить такую проблему? В первую очередь следует внимательно изучить все «желтые» URL и определиться, нужно ли блокировать конкретную страницу или нет. Если вы уверены, что странице не место в индексе – ограничиваем к ней доступ поисковых ботов с помощью noindex или X-Robots-Tag. От страниц, не представляющих ценности ни для пользователей, ни для поисковых лучше избавиться вовсе. Как правильно удалять страницы из индекса Google и Яндекса без вреда для SEO – читайте в отдельной статье.

    Страница проиндексирована без контента

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

    Чтобы устранить эту проблему, необходимо внимательно ознакомиться со всеми рекомендациями в разделе «Покрытие» и внедрить предложенные правки. В некоторых случаях может потребоваться дополнительная проверка кода страницы, поскольку отчеты Search Console далеко не всегда способны обнаруживать недочеты, связанные с указанной проблемой. Более глубокий технический SEO-аудит, проведенный с использованием специальных программ, поможет обнаружить битые изображения или видео, повторяющиеся заголовки и метаописания, проблемы с локализацией и другие недочеты, из-за которых страницы могут индексироваться без контента.

    Исключено

    Google Search Console также уведомляет о страницах, которые не попали в индекс, но присутствуют на сайте. Эта информация отображается в красном блоке «Исключено».

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

    • обход страниц запрещен через noindex или X-Robots-Tag;
    • прописаны запрещающие директивы в файле robots.txt;
    •     страница является неканонической, т. е. дублем, правильно размеченным атрибутом rel=«canonical».

    Но иногда попадание страниц в блок «Исключено» может свидетельствовать о наличии технических проблем или недоработок, например:

    • страница не проиндексирована из-за неавторизованного запроса (ошибка 401), переноса в другое место или удаления (404), запрета доступа (403), ложной ошибки (soft 404);
    • присутствие на странице некорректно настроенного редиректа;
    •     страница является дублем, без указания канонического URL.
    • Google выбрал канонический вариант страницы не таким, как его указал вебмастер (соответственно, из индекса вылетели важные URL).

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

    Ускоряем индексирование приоритетных страниц

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

    Делайте запрос на переиндексацию каждый раз после публикации новой страницы или существенного обновления старого контента. Для этого нужно ввести исходный адрес в верхнее поле поиска Google Search Console и нажать Enter. Через несколько секунд система предоставит информацию о текущем статусе URL, после нужно нажать «Запросить индексирование».

    Инструмент быстро просканирует страницу на предмет проблем, и при отсутствии таковых добавит URL в очередь на приоритетный обход. Запрос на ускоренную индексацию или переобход большого количества страниц делают через отправку файла Sitemap (об этом – в следующем пункте).

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

    Оптимизируем индексацию с помощью Sitemap

    Карта сайта — это специальный файл (sitemap.xml), который размещают в корневой папке, чтобы помочь поисковым роботам Google лучше ориентироваться в структуре ресурса. В хml-файле содержится перечень всех URL сайта с информацией об их последнем обновлении и указанием, какие из страниц нужно сканировать в первую очередь. Таким образом хml-карта упрощает краулерам поиск URL для индексирования, выступая в роли вспомогательной навигации по сайту.

    Файл sitemap.xml можно создать одним из нескольких способов:

    • Написать вручную, в соответствии с правилами синтаксиса (сегодня почти никто так уже не делает).
    • Сгенерировать автоматически при помощи специальных программ или онлайн-сервисов.
    • Воспользоваться встроенным функционалом некоторых CMS (например, такая опция предусмотрена в Битрикс).
    • Сгенерировать и настроить XML-карту при помощи WP-плагинов (эта опция доступна в двух популярных SEO-плагинах: All in One SEO и Yoast).

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

    Чтобы передать созданную карту сайта в Search Console и/или проверить ее на наличие ошибок, достаточно перейти в раздел «Файлы Sitemap», ввести путь доступа к xml-файлу и нажать «Отправить».

    В плане технических требований файл Sitemap должен:

    • соответствовать правилам синтаксиса (ошибки в файле можно проверить специальными валидаторами);
    • иметь размер, не превышающий 50 МБ;
    • содержать не более 50 000 URL-адресов, а если количество URL на сайте превышает указанный лимит, необходимо добавить несколько файлов sitemap.xml.

    Без Sitemap содержимое сайта все равно будет попадать в индекс. В этом случае Google станет самостоятельно сканировать URL и проверять их на наличие обновлений, но он будет делать это так часто и в такой приоритетности URL, как посчитает нужным. Очевидно, что это не лучшим образом отразится на скорости индексирования важных страниц. В то же время возлагать на sitemap большие ожидания тоже не стоит. Карта сайта – это в первую очередь рекомендация, которую поисковик может брать во внимание, а может и не учитывать.

    Так ли важна карта сайта?

    С учетом всего вышесказанного может возникнуть вопрос: нужна ли вообще карта сайта? Ответ однозначный: да нужна. Хотя Google утверждает, что относительно небольшим сайтам (до 500 страниц) можно пренебречь Sitemap, этого лучше не делать. В первую очередь потому что любой молодой проект по умолчанию имеет слабый ссылочный профиль, а этот фактор важен в том числе и для краулеров. Поэтому, если на сайт ведет мало ссылок, его сложнее найти – отсюда проблемы с органической индексацией.

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

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

    Для каких сайтов Sitemap является обязательным

    Для некоторых проектов значимость карты сайтов не вызывает сомнений, в первую очередь это:

    • Ресурсы, у которых много страниц (500+ URL).
    • Сайты с большим архивом документов, иерархически не связанных друг с другом.
    • Крупные сайты с логичной, но сложноорганизованной структурой.
    • Площадки с большой долей мультимедийного контента (видео/изображения).
    • Часто обновляемые ресурсы (магазины, новостники и т. д.).

    Для указанной категории сайтов Sitemap является не только инструментом оптимизации индексирования, но и дополнительным источником информации о потенциальных проблемах. Чтобы обнаруживать возможные недочеты, связанные с индексированием, сканированием или дублированием контента, сравнивайте количество страниц, отправленных через файл Sitemap, с фактическим числом URL, проиндексированных в поиске Google.

    Отслеживаем индексирование AMP-страниц

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

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

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

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

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

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

    Источник

    Такой вопрос это нужно сделать или стоит переадресация?

    # BEGIN WP Rocket v3.8.5
# Use UTF-8 encoding for anything served text/plain or text/html
AddDefaultCharset UTF-8
# Force UTF-8 for a number of file formats
<IfModule mod_mime.c>
AddCharset UTF-8 .atom .css .js .json .rss .vtt .xml
</IfModule>
# FileETag None is not enough for every server.
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
# Since we’re sending far-future expires, we don’t need ETags for static content.
# developer.yahoo.com/performance/rules.html#etags
FileETag None
<IfModule mod_alias.c>
<FilesMatch ".(html|htm|rtf|rtx|txt|xsd|xsl|xml)$">
<IfModule mod_headers.c>
Header set X-Powered-By "WP Rocket/3.8.5"
Header unset Pragma
Header append Cache-Control "public"
Header unset Last-Modified
</IfModule>
</FilesMatch>
<FilesMatch ".(css|htc|js|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$">
<IfModule mod_headers.c>
Header unset Pragma
Header append Cache-Control "public"
</IfModule>
</FilesMatch>
</IfModule>
# Expires headers (for better cache control)
<IfModule mod_expires.c>
	ExpiresActive on
	ExpiresDefault                              "access plus 1 month"
	# cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
	ExpiresByType text/cache-manifest           "access plus 0 seconds"
	# Your document html
	ExpiresByType text/html                     "access plus 0 seconds"
	# Data
	ExpiresByType text/xml                      "access plus 0 seconds"
	ExpiresByType application/xml               "access plus 0 seconds"
	ExpiresByType application/json              "access plus 0 seconds"
	# Feed
	ExpiresByType application/rss+xml           "access plus 1 hour"
	ExpiresByType application/atom+xml          "access plus 1 hour"
	# Favicon (cannot be renamed)
	ExpiresByType image/x-icon                  "access plus 1 week"
	# Media: images, video, audio
	ExpiresByType image/gif                     "access plus 4 months"
	ExpiresByType image/png                     "access plus 4 months"
	ExpiresByType image/jpeg                    "access plus 4 months"
	ExpiresByType image/webp                    "access plus 4 months"
	ExpiresByType video/ogg                     "access plus 4 months"
	ExpiresByType audio/ogg                     "access plus 4 months"
	ExpiresByType video/mp4                     "access plus 4 months"
	ExpiresByType video/webm                    "access plus 4 months"
	# HTC files  (css3pie)
	ExpiresByType text/x-component              "access plus 1 month"
	# Webfonts
	ExpiresByType font/ttf                      "access plus 4 months"
	ExpiresByType font/otf                      "access plus 4 months"
	ExpiresByType font/woff                     "access plus 4 months"
	ExpiresByType font/woff2                    "access plus 4 months"
	ExpiresByType image/svg+xml                 "access plus 1 month"
	ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
	# CSS and JavaScript
	ExpiresByType text/css                      "access plus 1 year"
	ExpiresByType application/javascript        "access plus 1 year"
</IfModule>
# Gzip compression
<IfModule mod_deflate.c>
# Active compression
SetOutputFilter DEFLATE
# Force deflate for mangled headers
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)s*,?s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
# Don’t compress images and other uncompressible content
SetEnvIfNoCase Request_URI 
.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g|mp4|webm|webp|pdf)$ no-gzip dont-vary
</IfModule>
</IfModule>
# Compress all output labeled with one of the following MIME-types
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE application/atom+xml 
		                          application/javascript 
		                          application/json 
		                          application/rss+xml 
		                          application/vnd.ms-fontobject 
		                          application/x-font-ttf 
		                          application/xhtml+xml 
		                          application/xml 
		                          font/opentype 
		                          image/svg+xml 
		                          image/x-icon 
		                          text/css 
		                          text/html 
		                          text/plain 
		                          text/x-component 
		                          text/xml
</IfModule>
<IfModule mod_headers.c>
Header append Vary: Accept-Encoding
</IfModule>
</IfModule>
# END WP Rocket
# BEGIN WP Hide & Security Enhancer
<IfModule mod_rewrite.c> 
RewriteEngine On 
RewriteBase / 
#WriteCheckString:1614091674_63237
RewriteRule .* - [E=HTTP_MOD_REWRITE:On]
RewriteRule ^usasooju/(.+) /wp-content/themes/houzez/$1 [L,QSA]
RewriteRule ^xuthoalr/(.+) /wp-content/plugins/$1 [L,QSA]
RewriteRule ^oastoops/(.+) /wp-includes/$1 [L,QSA]
RewriteRule ^eglyroat/(.+) /wp-content/uploads/$1 [L,QSA]
RewriteRule ^eceeksyp.php /wp-comments-post.php [L,QSA]
RewriteRule ^fynoomog/(.+) /wp-content/$1 [L,QSA]
</IfModule> 
# END WP Hide & Security Enhancer
<IfModule mod_rewrite.c>
  RewriteEngine On
  # Check if browser supports WebP images
  RewriteCond %{HTTP_ACCEPT} image/webp
  # Check if WebP replacement image exists
  RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
  # Serve WebP image instead
  RewriteRule (.+).(jpe?g|png)$ $1.webp [T=image/webp,E=REQUEST_image]
</IfModule>
<IfModule mod_headers.c>
  # Vary: Accept for all the requests to jpeg and png
  Header append Vary Accept env=REQUEST_image
</IfModule>
<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>
# BEGIN WordPress
# Директивы (строки) между `BEGIN WordPress` и `END WordPress`
# созданы автоматически и подлежат изменению только через фильтры WordPress.
# Сделанные вручную изменения между этими маркерами будут перезаписаны.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
# MalCare WAF
<Files ".user.ini">
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
  Order deny,allow
  Deny from all
</IfModule>
</Files>
# END MalCare WAF
# BEGIN EXPIRES 
<IfModule mod_expires.c>
ExpiresActive On 
ExpiresDefault "access plus 6 month"
ExpiresByType text/css "access plus 6 month" 
ExpiresByType text/plain "access plus 6 month"
ExpiresByType image/gif "access plus 6 month"
ExpiresByType image/png "access plus 6 month" 
ExpiresByType image/jpeg "access plus 6 month" 
ExpiresByType application/x-javascript "access plus 6 month"
ExpiresByType application/javascript "access plus 6 month"
ExpiresByType application/x-icon "access plus 6 month" 
</IfModule>  
# END EXPIRES

    Источник

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

    Ошибка страницы с переадресацией может быть вызвана следующими ситуациями:

    • Вы перевели свой сайт на премиум-план. Переадресация выполняется с вашего бесплатного URL-адреса Wix на ваш собственный домен.
    • Вы настроили 301 редирект страниц в Менеджере переадресации URL.
    • Переадресация выполняется с HTTP-версии URL-адреса вашего сайта на HTTPS-версию.
    • Переадресация выполняется с https://mydomain.com версии URL вашего сайта на версию https://www.mydomain.com.

    В этих случаях это нормально и не повлияет на рейтинг вашего сайта.

    Источник
  • Как проходит индексация в Google
  • Обнаружение
  • Сканирование
  • Индексация
  • Ранжирование
  • Как пользоваться Отчётом об индексировании в Google Search Console
  • Фильтры «Все обработанные страницы» vs «Все отправленные страницы»
  • Проверка статусов URL
  • Что учесть при использовании отчёта
  • Как часто смотреть Отчёт
  • Дополнительно: инструмент проверки URL
  • Статус «Ошибка»
  • Ошибка сервера (5xx)
  • Ошибка переадресации
  • Доступ к отправленному URL заблокирован в файле robots.txt
  • Страница, связанная с отправленным URL, содержит тег noindex
  • Отправленный URL возвращает ложную ошибку 404
  • Отправленный URL возвращает ошибку 401 (неавторизованный запрос)
  • Отправленный URL не найден (ошибка 404)
  • При отправке URL произошла ошибка 403
  • URL заблокирован из-за ошибки 4xx (ошибка клиента)
  • Статус «Без ошибок, есть предупреждения»
  • Проиндексировано, несмотря на блокировку в файле robots.txt
  • Страница проиндексирована без контента
  • Статус «Страница без ошибок»
  • Страница была отправлена в Google и проиндексирована
  • Страница проиндексирована, но её нет в файле Sitemap 
  • Статус «Исключено»
  • Индексирование страницы запрещено тегом noindex
  • Индексирование страницы запрещено с помощью инструмента удаления страниц
  • Заблокировано в файле robots.txt 
  • Страница не проиндексирована вследствие ошибки 401 (неавторизованный запрос)
  • Страница просканирована, но пока не проиндексирована
  • Обнаружена, не проиндексирована
  • Вариант страницы с тегом canonical
  • Страница является копией, канонический вариант не выбран пользователем
  • Страница является копией, канонические версии страницы, выбранные Google и пользователем, не совпадают
  • Не найдено (404)
  • Страница с переадресацией
  • Ложная ошибка 404
  • Страница является копией, отправленный URL не выбран в качестве канонического
  • Страница заблокирована из-за ошибки 403 (доступ запрещён)
  • URL заблокирован из-за ошибки 4xx (ошибка клиента)
  • Ключевые выводы

    • Подробный SEO-гайд по Отчёту об индексировании Google Search Console. Разберёмся, как проверить индексацию сайта с его помощью, как «читать» статусы URL, какие ошибки можно обнаружить и как их исправить.

    Перевод с сайта onely.com.

    В Отчёте вы можете получить данные о сканировании и индексации всех URL-адресов, которые Google смог обнаружить на вашем сайте. Он поможет отследить, добавлен ли сайт в индекс, и проинформирует о технических проблемах со сканированием и индексацией.

    Но перед тем, как говорить об Отчёте, вспомним все этапы индексации страницы в Google.

    Как проходит индексация в Google

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

    Обнаружение

    Перед тем, как просканировать страницу, Google должен её обнаружить. Он может сделать это несколькими способами. 

    Наиболее распространённые — с помощью внутренних или внешних ссылок или через карту сайта (файл Sitemap.xml).

    Сканирование

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

    Главный аспект в этом вопросе — краулинговый бюджет, который представляет собой лимит времени и ресурсов, который поисковая система готова «потратить» на сканирование вашего сайта. 

    Что такое «краулинговый бюджет, как его проверить и оптимизировать

    Индексация

    В процессе индексации Google оценивает качество страницы и добавляет её в индекс — базу данных, где собраны все страницы, о которых «знает» Google.

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

    Даже если Google нашёл и просканировал страницу, это не означает, что она обязательно будет проиндексирована.

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

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

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

    Ранжирование

    Только проиндексированные страницы могут появиться в результатах поиска и ранжироваться.

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

    Теперь перейдём к Отчёту.

    Как пользоваться Отчётом об индексировании в Google Search Console

    Чтобы просмотреть Отчёт, авторизуйтесь в своём аккаунте Google Search Console. Затем в меню слева выберите «Покрытие» в секции «Индекс»:

    Как найти Отчёт об индексировании в Google Search Console

    Как найти Отчёт об индексировании в Google Search Console

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

    Статусы URL на странице Отчёта

    Статусы URL на странице Отчёта

    Вы увидите четыре статуса URL-адресов:

    • Ошибка — критическая проблема сканирования или индексации.
    • Без ошибок, есть предупреждения — URL-адреса проиндексированы, но содержат некоторые некритичные ошибки. 
    • Страница без ошибок — страницы проиндексированы корректно.
    • Исключено — страницы, которые не были проиндексированы из-за проблем (это самый важный раздел, на котором нужно сфокусироваться).

    Фильтры «Все обработанные страницы» vs «Все отправленные страницы»

    В верхнем углу вы можете отфильтровать, какие страницы хотите видеть:

    Фильтр отображаемых страниц

    Фильтр отображаемых страниц

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

    Фильтр «Все отправленные страницы» включает только URL-адреса, добавленные с помощью файла Sitemap.

    В чём разница?

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

    Как пример — URL с параметрами на сайтах eCommerce. Googlebot может найти их разными способами, но не в карте сайта.

    Так что когда открываете Отчёт, убедитесь, что смотрите нужные данные.

    Проверка статусов URL

    Чтобы увидеть подробную информацию о проблемах, обнаруженных для каждого статуса, посмотрите «Сведения» под графиком:

    Раздел «Сведения»

    Раздел «Сведения»

    Тут показан статус, тип проблемы и количество затронутых страниц. Обратите внимание на столбец «Проверка» — после исправления ошибки, вы можете попросить Google проверить URL повторно.

    Например, если кликнуть на первую строку со статусом «Предупреждение», то вверху появится кнопка «Проверить исправление»:

    Проверка исправлений

    Проверка исправлений

    Вы также можете увидеть динамику каждого статуса: увеличилось, уменьшилось или осталось на том же уровне количество URL-адресов в этом статусе.

    Если в «Сведениях» кликнуть на любой статус, вы увидите количество адресов, связанных с ним. Кроме того, вы сможете посмотреть, когда каждая страница была просканирована (но помните, что эта информация может быть неактуальна из-за задержек в обновлении отчётов). 

    Подробная информация о сканировании в Сведениях

    Подробная информация о сканировании в Сведениях

    Что учесть при использовании отчёта

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

    Как часто смотреть Отчёт

    Обычно достаточно делать это раз в месяц.

    Но если вы внесли значимые изменения на сайте, например, изменили макет страницы, структуру URL или сделали перенос сайта, мониторьте Отчёт чаще, чтобы вовремя поймать негативное влияние изменений.

    Рекомендую делать это хотя бы раз в неделю и обращать особое внимание на статус «Исключено». 

    Дополнительно: инструмент проверки URL

    В Search Console есть ещё один инструмент, который даст ценную информацию о сканировании и индексации страниц вашего сайта — Инструмент проверки URL.

    Он находится в самом верху страницы в GSC:

    Инструмент проверки URL

    Инструмент проверки URL

    Просто вставьте URL, который вы хотите проверить, в эту строку и увидите данные по нему. Например:

    Результат проверки URL

    Результат проверки URL

    Инструментом можно пользоваться для того, чтобы:

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

    Если в Отчёте об индексировании обнаружены какие-то проблемы со страницами, используйте Инструмент, чтобы тщательнее проверить их и понять, что именно нужно исправить. 

    Статус «Ошибка»

    Под этим статусом собраны URL, которые не были проиндексированы из-за ошибок.

    Если вы видите проблему с пометкой «Отправлено», то это может касаться только URL, которые были отправлены через карту сайту. Убедитесь, что в карте сайте содержатся только те страницы, которые вы действительно хотите проиндексировать.

    Ошибка сервера (5xx)

    Эта проблема говорит об ошибке сервера со статусом 5xx, например, 502 Bad Gateway или 503 Service Unavailable.

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

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

    Как исправить ошибки сервера — рекомендации Google

    Ошибка переадресации

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

    Ошибки переадресации могут указывать на такие проблемы:

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

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

    Доступ к отправленному URL заблокирован в файле robots.txt

    Эти страницы есть в файле Sitemap, но заблокированы в файле robots.txt. 

    Robots.txt — это файл, который содержит инструкции для поисковых роботов о том, как сканировать ваш сайт. Чтобы URL был проиндексирован, Google нужно для начала его просканировать. 

    Что делать. Если вы видите такую ошибку, перейдите в файл robots.txt и проверьте настройку директив. Убедитесь, что страницы не закрыты через noindex.

    Страница, связанная с отправленным URL, содержит тег noindex

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

    Что делать. Если страница должна быть проиндексирована, уберите noindex.

    Отправленный URL возвращает ложную ошибку 404

    Ложная ошибка 404 означает, что страница возвращает статус 200 OK, но её содержимое может указывать на ошибку. Например, страница пустая или содержит слишком мало контента.

    Что делать. Проверьте страницы с ошибками и посмотрите, есть ли возможность изменить контент или настроить редирект.  

    Отправленный URL возвращает ошибку 401 (неавторизованный запрос)

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

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

    Отправленный URL не найден (ошибка 404)

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

    Что делать. Если вы увидели эту проблему в отчёте, перейдите на затронутые страницы и проверьте, можете ли вы исправить ошибку. Например, настроить 301-й редирект на рабочую страницу. 

    Дополнительно убедитесь, что файл Sitemap не содержит URL, которые возвращают какой-либо другой код состояния HTTP кроме 200 OK. 

    При отправке URL произошла ошибка 403

    Код состояния 403 Forbidden означает, что сервер понимает запрос, но отказывается авторизовывать его. 

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

    URL заблокирован из-за ошибки 4xx (ошибка клиента)

    Страница может быть непроиндексирована из-за других ошибок 4xx, которые не описаны выше. 

    Что делать. Чтобы понять, о какой именно ошибке речь, используйте Инструмент проверки URL. Если устранить ошибку невозможно, уберите URL из карты сайта. 

    Статус «Без ошибок, есть предупреждения»

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

    Проиндексировано, несмотря на блокировку в файле robots.txt

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

    Что делать. Проверьте эти страницы. Если они всё же должны быть проиндексированы, то обновите файл robots.txt, чтобы Google получил к ним доступ. Если не должны — поищите ссылки, которые на них указывают. Если вы хотите, чтобы URL были просканированы, но не проиндексированы, добавьте директиву noindex.

    Страница проиндексирована без контента

    URL проиндексированы, но Google не смог прочитать их контент. Это может быть из-за таких проблем:

    • Клоакинг — маскировка контента, когда Googlebot и пользователи видят разный контент.
    • Страница пустая.
    • Google не может отобразить страницу.
    • Страница в формате, который Google не может проиндексировать.

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

    Статус «Страница без ошибок»

    Здесь показываются страницы, которые корректно проиндексированы. Но на эту часть Отчёта всё равно нужно обращать внимание, чтобы сюда не попали страницы, которые не должны были оказаться в индексе. Тут тоже есть два статуса.

    Страница была отправлена в Google и проиндексирована

    Это значит, что страницы отправлена через Sitemap и Google её проиндексировал.

    Страница проиндексирована, но её нет в файле Sitemap 

    Это значит, что страница проиндексирована даже несмотря на то, что её нет в Sitemap. Посмотрите, как Google нашёл эту страницу, через Инструмент проверки URL. 

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

    Статус «Исключено»

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

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

    Индексирование страницы запрещено тегом noindex

    Что делать. Тут то же самое — если страница и не должна быть проиндексирована, то всё в порядке. Если должна — удалите noindex. 

    Индексирование страницы запрещено с помощью инструмента удаления страниц

    У Google есть Инструмент удаления страниц. Как правило с его помощью Google удаляет страницы из индекса не навсегда. Через 90 дней они снова могут быть проиндексированы. 

    Что делать. Если вы хотите заблокировать страницу насовсем, вы можете удалить её, настроит редирект, внедрить авторизацию или закрыть от индексации с помощью тега noindex.

    Заблокировано в файле robots.txt 

    У Google есть Инструмент проверки файла robots.txt, где вы можете в этом убедиться. 

    Что делать. Если эти страницы и не должны быть в индексе, то всё в порядке. Если должны — обновите файл robots.txt.

    Помните, что блокировка в robots.txt — не стопроцентный вариант закрыть страницу от индексации. Google может проиндексировать её, например, если найдёт ссылку на другой странице. Чтобы страница точно не была проиндексирована, используйте директиву noindex. 

    Подробнее о блокировке индексирования при помощи директивы noindex

    Страница не проиндексирована вследствие ошибки 401 (неавторизованный запрос)

    Обычно это происходит на страницах, защищённых паролем. 

    Что делать. Если они и не должны быть проиндексированы, то ничего делать не нужно. Если вы не хотите, чтобы Google обнаруживал эти страницы, уберите существующие внутренние и внешние ссылки на них.

    Страница просканирована, но пока не проиндексирована

    Это значит, что страница «ждёт» решения. Для этого может быть несколько причин. Например, с URL нет проблем и вскоре он будет проиндексирован. 

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

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

    Что делать. Для начала убедитесь, что это не ошибка. Проверьте, действительно ли URL не проиндексирован, в Инструменте проверки URL или через инструмент «Индексация» в Анализе сайта в Топвизоре. Они показывают более свежие данные, чем Отчёт. 

    Как исправить ошибку, когда страница просканирована, но не проиндексирована (на английском)

    Обнаружена, не проиндексирована

    Это значит, что Google увидел страницу, например, в карте сайта, но ещё не просканировал её. В скором времени страница может быть просканирована.

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

    Что такое краулинговый бюджет и как его оптимизировать

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

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

    Вариант страницы с тегом canonical

    Эти URL — дубли канонической страницы, отмеченные правильным тегом, который указывает на основную страницу.

    Что делать. Ничего, вы всё сделали правильно.

    Страница является копией, канонический вариант не выбран пользователем

    Это значит, что Google не считает эти страницы каноническими. Посмотрите через Инструмент проверки URL какую страницу он считает канонической. 

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

    Страница является копией, канонические версии страницы, выбранные Google и пользователем, не совпадают

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

    Что делать. В этом случае может помочь объединение URL повторяющихся страниц.

    Как правильно настроить внутренние ссылки на сайте

    Не найдено (404)

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

    Что делать. Если вы и не хотели, чтобы Google индексировал страницу, то ничего делать не нужно. Другой вариант — поставить 301-й редирект на работающую страницу. 

    Страница с переадресацией

    Эта страница редиректит на другую страницу, поэтому не была проиндексирована. Обычно, такие страницы не требуют внимания.

    Что делать. Эти страницы и не должны быть проиндексированы, так что делать ничего не нужно.

    Для постоянного редиректа убедитесь, что вы настроили перенаправление на ближайшую альтернативную страницу, а не на Главную. Редирект страницы с 404 ошибкой на Главную может определять её как soft 404.

    @JohnMu what does Google do when a site redirects all its 404s to the homepage? Seeing more and more sites do this and it’s such an anti-pattern.

    — Joost de Valk (@jdevalk) January 7, 2019

    Yeah, it’s not a great practice (confuses users), and we mostly treat them as 404s anyway (they’re soft-404s), so there’s no upside. It’s not critically broken/bad, but additional complexity for no good reason — make a better 404 page instead.

    — ? John ? (@JohnMu) January 8, 2019

    Ложная ошибка 404

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

    Что делать. Для исправления проблемы вы можете:

    • Добавить или улучшить контент таких страниц.
    • Настроить 301-й редирект на ближайшую альтернативную страницу.
    • Настроить сервер, чтобы он возвращал правильный код ошибки 404 или 410.

    Страница является копией, отправленный URL не выбран в качестве канонического

    Эти страницы есть в Sitemap, но для них не выбрана каноническая страница. Google считает их дублями и канонизировал их другими страницами, которые определил самостоятельно. 

    Что делать. Выберите и добавьте канонические страницы для этих URL.

    Страница заблокирована из-за ошибки 403 (доступ запрещён)

    Что делать. Если Google не может получить доступ к URL, лучше закрыть их от индексации с помощью метатега noindex или файла robots.txt. 

    URL заблокирован из-за ошибки 4xx (ошибка клиента)

    Сервер столкнулся с ошибкой 4xx, которая не описана выше. 

    Гайд по ошибкам 4xx и способы их устранения (на английском)

    Попробуйте исправить ошибки или оставьте страницы как есть. 

    Ключевые выводы

    1. Проверяя данные в Отчёте помните, что не все страницы сайта должны быть просканированы и проиндексированы. 
    2. Закрыть от индексации некоторые страницы может быть так же важно, как и следить за тем, чтобы нужные страницы сайта индексировались корректно. 
    3. Отчёт об индексировании показывает как критичные ошибки, так и неважные, которые не обязательно требуют действий с вашей стороны.
    4. Регулярно проверяйте Отчёт, но только для того, чтобы убедиться, что всё идёт по плану. Исправляйте только те ошибки, которые не соответствуют вашей стратегии индексации.
    Источник

    Понравилась статья? Поделить с друзьями:
  • Ошибка первого рода математическая статистика
  • Ошибка первой лямбды шевроле круз
  • Ошибка первого рода заключается в том что будет
  • Ошибка первой лямбды мазда 3
  • Ошибка первого рода возникает при