Отчет о статусе AMP-страниц

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

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

Посмотреть отчет о статусе AMP-страниц

 

Учебный курс по Google Search Console: отчет о статусе AMP-страниц в Search Console

 

Что показано в отчете

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

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

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

На что следует обратить внимание

Вам стоит стремиться к следующим показателям:

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

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

Проблемы с AMP-страницей

В отчете доступны сведения не только по стандартным ошибкам. Дополнительные типы проблем (ошибок и предупреждений) на AMP-страницах описаны ниже.

Связанные с Google проблемы на AMP-страницах
Проблема Описание
Несоответствие контента: отсутствует встроенное видео На AMP-странице отсутствует встроенное видео, которое есть на канонической странице. Основной контент на канонических и соответствующих им AMP-страницах по возможности должен быть одинаковым. Наличие видео определяется по URL. Предупреждение появится, если на одно видео будут указывать два разных URL.
Размер изображения меньше рекомендуемого Структурированные данные на AMP-странице относятся к изображению, размер которого меньше рекомендуемого. Из-за этого при показе страницы в Google Поиске пользователям могут быть доступны не все функции AMP, а связанные с вашей страницей карточки в рекомендациях, вероятно, не будут показываться с большими изображениями. В результате могут снизиться посещаемость сайта и активность пользователей на нем. Чтобы устранить эту проблему, используйте изображение более крупного размера, которое будет соответствовать нашим рекомендациям.
Домен AMP-страницы не соответствует канонической версии AMP-страница и ее каноническая версия размещены в разных доменах. Пользователи мобильных устройств могут счесть ваш сайт подозрительным, увидев один домен в результатах поиска и другой при открытии AMP-страницы. Это не влияет на индексирование или рейтинг страницы.
URL не найден (404) Не удалось найти URL запрошенной AMP-страницы. Подробнее об устранении ошибок 404…
Ошибка сервера (5xx) При запросе AMP-страницы произошла неизвестная ошибка сервера с кодом 5xx. Подробнее…
Заблокировано в файле robots.txt В файле robots.txt роботу Googlebot запрещен доступ к URL запрошенной AMP-страницы. Если это не то, что вам нужно, найдите в файле robots.txt директиву с запретом доступа и удалите или измените ее.
Проблема при сканировании При сканировании AMP-страницы произошла неизвестная ошибка. Чтобы устранить неполадку, воспользуйтесь инструментом проверки URL. 
Приведенный URL относится не к AMP-странице Каноническая страница ссылается на страницу без функций AMP. Подробнее о том, как настроить ссылки с обычных страниц на их AMP-версии…
Приведенный URL относится к AMP-странице с переадресацией Каноническая страница ссылается на AMP-страницу, не связанную с ней. Так быть не должно. Подробнее о том, как настраивать ссылки на AMP-страницы с обычных…
Страница содержит директиву noindex Доступ к AMP-странице запрещен с помощью директивы noindex. В этом случае сканирование страницы роботами Google невозможно. Удалите директиву noindex или ссылку на страницу, доступ к которой запрещен.
Истек срок, заданный в параметре unavailable_after для страницы AMP-страница содержит метатег с директивой unavailable_after, указывающей на дату в прошлом, и больше не подходит для показа. Этот тег следует обновить или удалить.
Каноническая страница связана с неверным URL Каноническая страница ссылается на свою AMP-версию при помощи URL неверного формата. Подробнее о том, как правильно настроить ссылку на AMP-версию страницы…
Ошибка на канонической странице amp-story

Страница ссылается на страницу amp-story как на свою AMP-версию. Это запрещено, так как страница с компонентом amp-story сама по себе является канонической. Иными словами, в теге <rel="canonical"> должен быть указан ее же адрес и она не может быть AMP-версией другой страницы.
Модульный скрипт указан без альтернативного немодульного варианта (или наоборот) Тег <script type="module"> используется без связанного с ним тега <script nomodule async> или наоборот. Такие теги нужно указывать в паре, чтобы браузер мог считывать их независимо от того, поддерживает он или не поддерживает модульные скрипты.
В HTML-теге отсутствует URL Строка URL не заполнена. В выбранном HTML-теге должен содержаться атрибут с действительным адресом ресурса. Укажите в строке действительный URL.
Отсутствует или неверно указан атрибут, обязательный при использовании атрибута on Запрашиваемый атрибут отсутствует или задан неверно, однако он необходим для обработки атрибута on, который вы указали в том же теге.
За пределами блока <svg> обнаружен дочерний тег, который используется с тегом <svg> Тег, который вы разместили за пределами блока <svg>, должен быть включен в него.
Страница загружает несколько версий одного скрипта расширения Выбранная страница загружает сразу несколько версий одного и того же AMP-расширения. Чтобы исправить эту ошибку, удалите одну из версий скрипта.
Проблемы при использовании технологии Signed HTTP Exchange

Сведения о проблемах с AMP-страницами, на которых используется технология Signed HTTP Exchange (SXG), доступны в отчете о статусе AMP-страниц и отчете, который создается с помощью инструмента проверки URL.

Как получить информацию о проблемах при использовании SXG

Информацию о том, как SXG используется на AMP-странице, можно посмотреть разными способами:

  • В инструменте проверки URL выберите нужный пункт в разделе Сведения об AMP-версии.
  • В отчете о статусе AMP-страниц нажмите на URL в таблице с данными о выявленных проблемах.

Как узнать, используется ли на AMP-страницах технология SXG

Чтобы узнать, удалось ли системам Google обнаружить заголовки или полезную нагрузку SXG, выполните следующие действия:

  1. Проверьте URL AMP-страницы. Для этого используйте инструмент проверки URL или откройте отчет о статусе AMP-страниц и нажмите на значок проверки напротив нужного URL в таблице.
  2. На странице с результатами нажмите Изучить просканированную страницу, чтобы открыть боковую панель с дополнительной информацией.
  3. Откройте вкладку Подробнее.
  4. Статус в разделе HTTP-обмен с подписью показывает, удалось ли Google обнаружить на AMP-странице какие-либо компоненты, связанные с этой функцией.

Возможные проблемы при использовании SXG

Ниже перечислены проблемы, которые могут возникнуть, если на ваших AMP-страницах реализован протокол Signed HTTP Exchange.

Недействительный авторизованный обмен

HTTP-ответ Signed HTTP Exchange не соответствует требованиям Google AMP Cache. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Причины ошибки могут быть различными. Ниже перечислены некоторые из них.

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы применяете AMP Packager, выполните следующие действия:

Во время авторизованного обмена произошла ошибка анализа

HTTP-ответ содержит подпись, текст которой не соответствует требованиям Google AMP Cache. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Чтобы обнаружить и исправить ошибку, сделайте следующее:

  • Убедитесь, что в HTML не используется недопустимая кодировка UTF-8. Для $URL, содержащего ошибку, выполните команду curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null и проверьте, нет ли сообщений об ошибках, например Illegal input sequence (Недопустимая входная последовательность). Если ошибки есть, проверьте документ на правильность кодировки UTF-8. К проблемам могут приводить нелатинские буквы и символы пробела.
  • Проверьте, не содержит ли HTML используемый в кодировке Unicode символ NULL (U+0000), который приводит к ошибке анализа HTML.
  • Убедитесь, что код HTML не изменился после вызова transform -config NONE. Он может измениться по двум причинам:
    • При сериализации не применялся принтер AMP Packager. Если вы используете другой генератор SXG, то в нем должна использоваться библиотека transformer для AMP Packager.
    • Анализ HTML вызывает ошибку, обработка которой изменяет дерево синтаксического анализа. Зачастую к этому приводят недостающие или неправильно размещенные теги. К числу таких ошибок относятся алгоритм типа Adoption agency (Усыновление) и обработка конечного тега form. Обнаружить эти ошибки нелегко, но вы можете упростить их выявление с помощью валидатора HTML-разметки.
    • Что следует предпринять, если вы исключили приведенные выше причины:
      • Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.
      • Если вы применяете AMP Packager, действуйте следующим образом:
        • Убедитесь, что вы используете последнюю версию AMP Packager.
        • Если она у вас установлена, сообщите нам об ошибке в AMP Packager.

Недопустимое значение заголовка header_name при авторизованном обмене

HTTP-ответ SXG содержит заголовок, не отвечающий требованиям к Google AMP Cache. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы применяете AMP Packager, выполните следующие действия:

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

В ответе SXG нет указанного заголовка, что противоречит спецификациям Signed HTTP Exchange и Google AMP Cache. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы применяете AMP Packager, выполните следующие действия:

Не удалось проанализировать заголовок подписи авторизованного обмена

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

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы применяете AMP Packager, выполните следующие действия:

Недействительный параметр parameter_name в заголовке подписи авторизованного обмена

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

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы применяете AMP Packager, выполните следующие действия:

Недопустимые даты авторизованного обмена

В ответе SXG заголовок подписи содержит недопустимое значение указанного параметра date или expires, что является нарушением спецификаций Signed HTTP Exchange или Google AMP Cache. В частности, подпись должна быть действительна при ее получении и на протяжении 4 или более дней после этого момента. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Ниже перечислены причины, по которым может возникать ошибка при использовании AMP Packager.

  • Убедитесь, что ваш обратный прокси-сервер не слишком долго сохраняет в кеше ответы SXG. Отправьте несколько запросов страницы с помощью команды curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' и проверьте параметр date=. Он должен иметь разные значения во всех ответах.
  • Убедитесь, что вы используете последнюю версию AMP Packager.
  • Если вы исключили все перечисленные выше причины, возможно, при работе AMP Packager возникла ошибка. Вы можете сообщить нам о ней.

Не удалось проанализировать цепочку сертификатов cert-url, на которую ссылается авторизованный обмен

В ответе SXG параметр cert-url отформатирован с нарушением требований. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы применяете AMP Packager, выполните следующие действия:

Недопустимая цепочка сертификатов cert-url, на которую ссылается авторизованный обмен

HTTP-ответ SXG содержит значение параметра cert-url, которое не соответствует спецификации Signed HTTP Exchange. В результате страница будет представлена пользователям без информации о подписи.

Как эта неполадка отразится на вашем сайте:

В средстве просмотра AMP страница будет показываться не с исходным URL, а с созданным Google.

Что следует предпринять:

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

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Если вы используете AMP Packager, изучите возможные причины, перечисленные ниже.

  • Убедитесь, что параметр CertFile не содержит полный список сертификатов конечного объекта и промежуточных сертификатов.
  • Убедитесь, что при запуске AMP Packager не использовался ключ -development или -invalidcert. В рабочем режиме AMP Packager проверяет несколько параметров сертификата.
  • Убедитесь, что ваш обратный прокси-сервер хранит в кеше URL /amppkg/cert/ не дольше, чем указано в параметре max-age.
  • Убедитесь, что ваш обратный прокси-сервер не изменяет заголовки кеша, поскольку вышестоящий прокси-сервер в таком случае может хранить их в кеше слишком долго. Для этого определите соответствующий URL /amppkg/cert/ в своем внутреннем домене упаковщика, вызовите его с заголовками ответа (например, с помощью команды curl -i) и сравните эти заголовки с теми, которые возвращает клиентский сервер.
  • Проверьте, содержит ли ваш сертификат параметр SCT. В частности, это можно сделать с помощью инструмента openssl x509. Если сертификата нет, обратитесь в свой центр сертификации.
  • Убедитесь, что вы используете последнюю версию AMP Packager.
  • Если вы исключили все перечисленные выше причины, возможно, при работе AMP Packager возникла ошибка. Вы можете сообщить нам о ней.

Не удалось проанализировать авторизованный обмен

В ответе SXG параметр content-type имеет значение application/signed-exchange;v=b3, но тело ответа извлечь не удалось. Возможные причины: несоответствие требованиям к типу или неправильная кодировка Merkle.

Как эта неполадка отразится на вашем сайте:

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

Что следует предпринять:

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Ниже перечислены причины, по которым может возникать ошибка при использовании AMP Packager.

  • Убедитесь, что ваш обратный прокси-сервер не изменяет ответы, полученные от AMP Packager. Для URL, содержащего ошибку, определите соответствующий URL /priv/doc в вашем внутреннем домене упаковщика и протестируйте его с использованием dump-signedexchange. Если ответ внутреннего упаковщика допустим по спецификации обмена с подписью, а ответ внешнего клиента – нет, то, возможно, клиент сконфигурирован неправильно.
  • Убедитесь, что вы используете последнюю версию AMP Packager.
  • Если вы исключили все перечисленные выше причины, возможно, при работе AMP Packager возникла ошибка. Вы можете сообщить нам о ней.

URL внутреннего процесса не совпадает с URL запроса для авторизованного обмена

Ответ SXG содержит параметр fallbackUrl, который отличается от URL запроса (они должны быть побайтово равны). Поэтому Google Поиск считает, что такой ответ не может соответствовать URL запроса.

Как эта неполадка отразится на вашем сайте:

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

Что следует предпринять:

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов. В таком случае можно изменить URL страницы, чтобы избежать сбоев при ее обработке распространенными синтаксическими анализаторами URL. Например, попробуйте не использовать закодированные со знаком "%" и зарезервированные символы, а также нестандартную кодировку строк запроса (например, при которой после символа ? не следуют параметры).

Ниже перечислены причины, по которым может возникать ошибка при использовании AMP Packager.

  • Проверьте, правильно ли переписывает URL ваш обратный клиентский сервер. Такие проблемы особенно часто возникают с URL, в которых используются закодированные с помощью знака "%" или зарезервированные символы. Например, в Nginx есть проблемы с директивами rewrite и proxy_pass. Для проверки отправьте несколько тестовых запросов клиенту и сравните их с URL, которые AMP Packager направляет на поток вывода stdout.
  • Убедитесь, что вы используете последнюю версию AMP Packager.
  • Если вы исключили все перечисленные выше причины, возможно, при работе AMP Packager возникла ошибка. Вы можете сообщить нам о ней.

Недопустимое значение заголовка header_name в HTTP-ответе авторизованного обмена

В ответе SXG параметр content-type имеет значение application/signed-exchange, но заголовки ответа оказались недопустимыми по другой причине. Например, в заголовке content-type может быть не указан параметр v=b3. В таком случае Google не сможет определить формат, а значит, тело ответа извлечь невозможно.

Как эта неполадка отразится на вашем сайте:

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

Что следует предпринять:

Если вы работаете с поставщиком услуг SXG, запросите поддержку у его специалистов.

Ниже перечислены причины, по которым может возникать ошибка при использовании AMP Packager.

  • Убедитесь, что ваш обратный клиентский сервер не изменяет заголовки content-type. Для URL, содержащего ошибку, определите соответствующий URL /priv/doc в вашем внутреннем домене упаковщика и получите его вместе с заголовками ответа (например, с curl -i). Если в ответах внутреннего упаковщика и внешнего клиента содержатся разные заголовки, это может быть причиной ошибки. Если вы обнаружили различия в любых заголовках, кроме content-type, сообщите об ошибке, сославшись на этот документ, чтобы мы обновили список требований.
  • Убедитесь, что вы используете последнюю версию AMP Packager.
  • Если вы исключили все перечисленные выше причины, возможно, при работе AMP Packager возникла ошибка. Вы можете сообщить нам о ней.

Приоритизация и устранение неполадок

  1. В таблице Почему эти AMP-страницы недействительны посмотрите список критических проблем, обнаруженных на вашем сайте.
  2. Проанализируйте ошибки:
    • Выясните, не вызван ли рост общего числа ошибок одной причиной. Для этого поищите в таблице данные, которые свидетельствуют о скачке выявленных случаев одной проблемы.
    • Советуем сначала сосредоточиться на проблемах, которые встречаются на нескольких страницах (например, шаблонах с ошибками), а затем перейти к единичным неполадкам, относящимся лишь к отдельным страницам.
  3. Устраните ошибки. Нажмите на строку в таблице, чтобы перейти на страницу сведений об ошибке:
    1. Откроется раздел с примерами страниц, на которых была выявлена проблема. Из-за ограничения в 1000 строк в этом окне могут быть перечислены не все недавние случаи обнаружения проблемы, а также отсутствовать страницы, которые ещё не сканировались с момента ее появления.
    2. Нажмите Подробнее рядом с проблемой, чтобы открыть официальную документацию к ошибке.
    3. Нажмите на URL в списке примеров, чтобы выделить ошибку в коде страницы.
    4. Нажмите на значок проверки , чтобы выполнить тщательный анализ определенной страницы. В результате проверки вы получите сведения обо всех проблемах (не только о текущей), а также увидите код с выделенными ошибками. Если сканирование страницы давно не выполнялось, вы увидите уведомление о проблеме, касающееся только проиндексированной страницы. В этом случае отправьте запрос на индексирование опубликованной страницы.
    5. Устраните проблему на всех страницах сайта и убедитесь, что она больше не возникает.
  4. Устранив проблему, вернитесь на ее страницу сведений и запустите проверку, нажав кнопку Проверить исправление. Проверка может занять некоторое время. Узнайте больше о том, как она осуществляется.
  5. Устраните все остальные неполадки.
  6. Если общее число страниц с ошибками и без значительно ниже количества AMP-страниц на вашем сайте, изучите раздел Устранение неполадок, связанных с отсутствием AMP-страниц.
  7. Устранив критические ошибки, перейдите к незначительным проблемам. Некоторые незначительные проблемы, например отсутствие обновлений, могут стать критическими в будущем.

Как отправить сведения об ошибке другим пользователям

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

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

Данные из некоторых отчетов можно экспортировать, нажав кнопку скачивания . Экспортируются данные, которые представлены как на диаграммах, так и в таблицах. Значения, отмеченные в отчете символами "~" и "-" (недоступно/не является числом), в скачанном файле будут заменены на нули.

Устранение неполадок, связанных с отсутствием AMP-страниц

Если AMP-страниц (с ошибками и без) в отчете меньше, чем на сайте, воспользуйтесь нашими рекомендациями:

  • Убедитесь, что между канонической и соответствующей ей AMP-страницами корректно установлена связь.
  • Проверьте, не заблокирован ли файлом robots.txt или директивой noindex доступ к страницам в канонической и AMP-версии и не требуется ли вводить учетные данные для их просмотра.
  • Проверьте, проиндексирована ли каноническая страница.
    • Если найти каноническую версию удалось, проверьте, корректно ли она связана с ее AMP-версией.
    • Если каноническая версия не обнаружена, запросите ее индексирование.
  • В зависимости от способа, с помощью которого вы уведомили Google о новых страницах, на обнаружение и сканирование этих страниц может потребоваться несколько дней.
  • Некоторые AMP-страницы могут быть не указаны в этом отчете, но представлены в отчете об индексировании страниц. Это связано с тем, что отчет об индексировании страниц должен содержать как можно больше данных, позволяющих вам устранять перечисленные ошибки индексирования. В свою очередь, в отчете о статусе AMP-страниц представлена подробная информация об отдельных страницах, которая поможет в решении конкретных проблем с AMP-страницами на сайте. Узнать, проиндексирована ли та или иная AMP-страница, вам поможет инструмент проверки URL.
Проверка исправлений

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

Для чего это нужно

Советуем сообщить Google, что вы устранили все проблемы с определенным статусом. Это дает следующие преимущества:

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

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

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

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

Как начать проверку

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

  1. Устраните проблему везде, где она выявлена на сайте. Если вы пропустите хотя бы одно исправление, процесс проверки будет остановлен, как только Google это обнаружит.
  2. Откройте страницу сведений об устраненной проблеме. Нажмите на нужную строку в таблице.
    • ⚠️ Если вы выполнили фильтрацию отчета с помощью определенного файла Sitemap, будут проверены только элементы, которые были включены в этот файл на момент подачи запроса. Есть вероятность, что проверены будут не те элементы, которые вас интересуют.
  3. Нажмите Проверить исправление. Не нажимайте "Проверить исполнение" ещё раз, пока проверка не закончится (успешно или с ошибкой). Подробнее о том, как система Google проверяет исправления…
  4. Вы можете следить за тем, как продвигается проверка. Проверка обычно занимает около двух недель, однако в некоторых случаях требуется больше времени. По окончании вы получите уведомление о результатах.
  5. Если проверка завершилась с ошибкой, вы можете посмотреть, на какой именно странице возникает эта ошибка. Для этого нажмите Подробности на странице сведений о проблемах. Устраните проблему на странице, подтвердите исправления для всех URL со статусом Не проверено и снова запустите проверку.

При каких условиях проблема считается устраненной для определенного URL или раздела на сайте?

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

  • URL просканирован, и проблема на странице не обнаружена. Если нарушение было связано с тегом AMP, значит вы успешно внесли исправления или тег удален (если его не требуется использовать). При проверке будет показываться статус Нет ошибок.
  • Страница по какой-либо причине недоступна роботам Google (удалена, содержит метатег с директивой noindex, требует авторизации и т. д.). Для такого URL проблема тоже будет считаться решенной. При проверке статус изменится на Другое.

Срок актуальности проблем

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

Датой выявления проблемы считается момент, когда она первый раз была зарегистрирована в течение срока актуальности. Эта дата неизменна. Далее Search Console действует по следующему алгоритму:

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

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

  1. После того как вы нажмете Проверить исправление, Search Console сразу же обработает несколько страниц.
    • Если хотя бы на одной из них будет обнаружено нарушение, о котором идет речь, проверка закончится, а ее статус останется неизменным.
    • Если на выбранных страницах нарушение обнаружено не будет, процедура проверки продолжится, а ее статус изменится на Начато. При этом Search Console может выявить другие проблемы, не связанные с текущей, однако зарегистрирует их отдельно, а проверка продолжится.
  2. Search Console будет проверять список страниц, на которых была обнаружена проблема, а не весь сайт. Список обработанных URL хранится в истории проверок Search Console. Ее можно открыть на странице со сведениями о проблеме.
  3. При проверке URL происходит следующее:
    1. Если проблема не найдена, статус проверки страниц меняется на Нет нарушений. Если это первый URL в очереди на обработку, статус проверки сайта меняется на Ошибки исправлены.
    2. Если URL недоступен, статус проверки страниц на наличие ошибки приобретает значение Другое (это не статус ошибки).
    3. Если проблема по-прежнему присутствует, сайту назначается статус Найдены ошибки и проверка заканчивается. Если такое нарушение выявлено на новой странице, обнаруженной при обычном сканировании сайта, это расценивается как ещё один случай прежней проблемы.
  4. Когда система проверит все URL в очереди и убедится, что проблема устранена, статус изменится на Нет ошибок. Учтите, что при этом степень серьезности проблемы останется прежней (Ошибка или Предупреждение), однако количество затронутых элементов станет равным нулю.

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

Повторная проверка

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

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

  1. Откройте историю проверки, которая завершилась с ошибкой, и нажмите Подробности.
  2. Нажмите Начать новую проверку.
  3. Система заново проверит все URL со статусом Не проверено или Ошибка, а также обнаружит другие аналогичные проблемы, если они появились с момента последней проверки. URL со статусом Нет ошибок или Другое повторно проверяться не будут.
  4. Проверка обычно занимает около двух недель, однако в некоторых случаях требуется больше времени.

Как посмотреть ход процесса

Чтобы увидеть ход текущей проверки или, если она завершена, историю последней проверки, выполните следующие действия:

  1. Откройте страницу сведений о проблеме. Для этого нажмите на строку проблемы на главной странице отчета.
  2. Чтобы открыть страницу сведений о проверке для вашего запроса, нажмите Подробности.
    • В таблице будет показан статус проверки для каждого URL в запросе.
    • Статус элемента применяется для конкретной проблемы, которую вы рассматриваете. На одной и той же странице одни проблемы могут иметь статус Подтверждено, а другие – Ошибка, Не проверено или Другое.
    • В отчетах о статусе AMP-страниц и индексировании страниц записи в истории проверок группируются по URL.
    • В отчете о расширенных результатах и об удобстве для мобильных записи группируются по URL и элементам структурированных данных (согласно значению элемента name).
Статус запроса проверки

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

  • Не начато. Один или несколько экземпляров проблемы ни разу не были включены в запрос проверки.
    Дальнейшие действия
    1. Нажмите на описание проблемы и ознакомьтесь с подробными сведениями о ней. Проанализируйте страницы, где она обнаружена.
    2. Нажмите Подробнее на странице со сведениями о проблеме, чтобы узнать, какое правило было нарушено.
    3. Выберите пример строки URL в таблице, чтобы получить подробную информацию о проблеме на соответствующей странице.
    4. Устраните нарушение на всех страницах и нажмите Проверить исправление, чтобы мы просканировали их заново. Проверка обычно занимает около двух недель, однако в некоторых случаях требуется больше времени.
  • Начато. Вы начали проверку, и проблема не обнаружена на новых страницах.
    Что следует предпринять. Следите за уведомлениями от Google, в которых вы найдете инструкции, если от вас будут требоваться какие-либо действия.
  • Ошибки исправлены. Вы начали проверку, и проблема исправлена на страницах, где она ранее была обнаружена.
    Что следует предпринять. Следите за уведомлениями Google о ходе проверки, в которых могут содержаться новые инструкции для вас.
  • Нет ошибок. Проблема устранена на всех страницах, где она ранее была обнаружена (или прежние URL больше не доступны). Этот статус может появиться только в том случае, если вы ранее нажимали Проверить исправление. Если проблемы на страницах исчезают без запроса повторной проверки с вашей стороны, статус изменяется на "Отсутствует".
    Что следует предпринять. От вас не требуется никаких действий.
  • Отсутствует. Мы обнаружили, что все страницы, где ранее наблюдалась проблема, исправлены, хотя вы ни разу не запрашивали проверку.
    Что следует предпринять. От вас не требуется никаких действий.
  • Есть ошибки. Проблема до сих пор наблюдается на некоторых страницах. Этот статус может появиться в том случае, если ранее вы нажимали Проверить.
    Что следует предпринять. Устраните нарушение и запросите повторную проверку.
Статусы проверки для отдельных случаев

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

  • Не проверено. Проблема находится в очереди на проверку. В ходе последней проверки выяснилось, что она не устранена.
  • Нет ошибок (не во всех отчетах). Мы проверили страницу на наличие проблемы и выяснили, что нарушение больше не наблюдается. Такой статус может появиться, только если вы запрашивали обработку именно этой страницы, нажав кнопку Проверить.
  • Есть ошибки. Мы проверили страницу на наличие проблемы и выяснили, что нарушение по-прежнему наблюдается. Такой статус может появиться, только если вы запрашивали обработку именно этой страницы, нажав кнопку Проверить.
  • Другое (не во всех отчетах). У Google нет доступа к странице или элементу структурированных данных, где выявлена проблема. Этот вариант аналогичен статусу Нет ошибок.

Обратите внимание, что у одного и того же URL может быть разный статус применительно к разным нарушениям. К примеру, если на одной и той же странице встречается проблема А и проблема Б, то первой может быть назначен статус Нет ошибок, а второй – Не проверено.

 

Известные проблемы

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

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

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

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

Требуется помощь?

Попробуйте следующее:

Опубликовать на справочном форуме Получите ответы от участников сообщества
true
Не знакомы с Search Console?

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

Поиск
Очистить поле поиска
Закрыть поиск
Главное меню
14449391621281592830
true
Поиск по Справочному центру
true
true
true
true
true
83844
false
false