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

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

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

Диаграммы с данными о проблемах и эффективности принятых вами мер представлены на странице "Статус".

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

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

 

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

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

В идеале содержание отчета должно быть следующим:

Проблемы с 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-страницы.
Проблема при сканировании При сканировании 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-версией другой страницы.

Проблемы при использовании технологии 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, на которую ссылается авторизованный обмен

Ответ 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. Если ответ внутреннего упаковщика допустим по спецификации Signed HTTP Exchange, а ответ внешнего клиента – нет, возможно, клиент сконфигурирован неправильно.
  • Убедитесь, что вы используете последнюю версию 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. Изучите сведения в разделах "Резкий скачок числа ошибок" и "Отсутствие AMP-страниц" ниже.
  4. Чтобы открыть страницу с информацией об ошибке, нажмите на нужную строку в таблице.
    1. В окне с информацией об ошибках приведены примеры страниц, на которых были выявлены проблемы. Из-за ограничения в 1000 строк в этом окне могут быть перечислены не все подобные страницы. Зачастую при этом отсутствуют данные по некоторым случаям обнаружения той или иной ошибки.
    2. Если обнаружена ошибка синтаксиса, вы можете получить официальные сведения о правильном синтаксисе, нажав Подробнее...
    3. Чтобы проверить страницы, на которых обнаружены ошибки, нажмите на специальный значок. В результате проверки вы получите сведения обо всех ошибках (не только о текущей), а также увидите код, в котором выделены неполадки. Иногда в отчетах содержатся данные по ошибке, которая уже устранена на странице. Это связано с тем, что ещё не выполнялось сканирование страницы. В этом случае после устранения всех случаев возникновения неполадки следует выполнить проверку.
  5. Устраните проблему везде, где она выявлена на сайте, и убедитесь, что она больше не возникает.
  6. Вернитесь к странице со сведениями об ошибке и нажмите кнопку Проверить исправление. Проверка может занять некоторое время. Узнайте больше о том, как она осуществляется.
  7. Устраните все остальные неполадки.
  8. Когда неполадок не останется, изучите предупреждения, отключив фильтр, не допускающий их показа. Некоторые предупреждения зачастую связаны с отсутствием необязательной разметки структурированных данных, благодаря которой страницы с подходящим контентом могут показываться в результатах поиска с расширенными функциями.

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

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

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

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

Резкий скачок числа ошибок

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

  1. Заметив резкий рост числа ошибок, проверьте, не снизилось ли на аналогичную величину количество элементов с другим статусом.
  2. Если подобное снижение будет найдено, проверьте, относятся ли все страницы к одним и тем же URL.
  3. Если статус URL менялся, определите, какие внесенные вами изменения к этому привели.

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

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

Если AMP-страниц со статусами "Страница без ошибок", "Предупреждение" и "Ошибка" в отчете меньше, чем на сайте, попробуйте выполнить следующие действия:

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

Общие сведения о предупреждениях

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

О проверке сайтов

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

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

Проблема считается актуальной с момента, когда она была впервые выявлена на вашем сайте, и вплоть до 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 все равно сможет обнаружить все элементы с нарушениями на вашем сайте. Если при обычном сканировании окажется, что определенная проблема исправлена на всех страницах, где она раньше имела место, статус ее проверки в отчете будет изменен на "Отсутствует".

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

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

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

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

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

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

Страницы с ошибками, которые прошли проверку (помеченные как Нет ошибок) или стали недоступными (помеченные как Другое), повторно не проверяются. Они будут удалены из истории проверок после того, как вы нажмете "Провести повторную проверку".

История проверок

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

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

Статус проверки сайта на наличие проблемы

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

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

Статус проверки страниц на наличие проблемы

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

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

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

 

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

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

  • Названия некоторых ошибок слишком длинны и трудны для понимания.
  • Данные об ошибке могут попадать в таблицу не сразу после того, как они появились на диаграмме.
  • Если на вашем сайте очень много проблем (решенных или нет), то в отчете показываются только первые 200 в порядке убывания важности.
Эта информация оказалась полезной?
Как можно улучшить эту статью?