Другая ошибка google search console

Cправка — Search Console

Войти

Справка Google

• Справочный центр
• Сообщество
• Search Console
• Политика конфиденциальности
• Условия предоставления услуг
• Отправить отзыв

Тема отзыва

Информация в текущем разделе Справочного центра

Общие впечатления о Справочном центре Google

• Справочный центр
• Сообщество

Search Console

Регулярная проверка и оперативное устранение ошибок – залог эффективной работы сайта.

Автор: Джо Робисон (Joe Robison) – основатель и главный консультант SEO-агентства Green Flag Digital, эксперт Moz.

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

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

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

Категоризация ошибок сканирования

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

Самый быстрый путь к ошибкам сканирования – через панель управления в Search Console. Главная панель даёт общий обзор ситуации по сайту и включает три самых важных инструмента для управления им: «Ошибки сканирования», «Анализ поисковых запросов» и «Файлы Sitemap».

1. Ошибки сайта

Ошибки, которые содержатся в этом разделе, влияют на работу сайта в целом. Google предоставляет данные за последние 90 дней.

При наличии проблем, этот раздел будет выглядеть примерно так:

При отсутствии ошибок – так:

Как часто проверять наличие ошибок сайта?

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

Как минимум, проверять наличие ошибок сайта следует каждые 90 дней. Но лучше, всё же, делать это чаще.

A) Ошибки DNS

Что это такое?

Ошибки DNS (Domain Name System) могут повлечь за собой огромные проблемы для сайта. Поэтому они очень важны и всегда идут первыми.

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

Важны ли они?

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

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

Ошибки DNS, которые затрудняют Google доступ к сайту, нужно решать сразу.

Как устранить

1. Google рекомендует в первую очередь использовать инструмент «Просмотреть как Googlebot» в Search Console. Если нужно проверить статус соединения с DNS-сервером, можно использовать только функцию «Сканировать». Функция «Получить и отобразить» нужна, чтобы сравнить, как видят сайт Googlebot и пользователь.

1. Свяжитесь с DNS-провайдером. Если Google не может правильно просканировать и отобразить страницу, эту проблему нужно решить. Проверьте, не связана ли она с поставщиком услуг DNS.
2. Убедитесь, что сервер выдаёт код ошибки HTTP 404 («не найдено») или 500 («внутренняя ошибка сервера»). Эти коды ответа сервера более точны, чем ошибка DNS.

Другие инструменты

ISUP.me – позволяет сразу узнать, доступен ли сайт другим пользователям или же проблема только с вашей стороны.

Web-Sniffer.net – показывает текущий HTTP-запрос и заголовок ответа. Полезно использовать для пункта № 3, приведённого выше.

B) Ошибки сервера
Что это значит

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

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

Важны ли они?

Как и ошибки DNS, ошибки сервера решать нужно устранять же, как только информация о них появилась в Search Console. Это фундаментальные ошибки, которые вредят сайту в целом.

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

Как устранить

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

При наличии ошибок сервера Google рекомендует следующее:

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

Перед тем, как приступить к устранению ошибок сервера, следует определить их тип. В Google выделяют такие типы:

• Таймаут
• Усечённые заголовки
• Сброс подключения
• Усечённое тело ответа
• В подключении отказано
• Истекло время ожидания подключения
• Нет отклика

Как устранить все эти ошибки, можно узнать в Справке Search Console.

C) Ошибка доступа к файлу robots.txt

Эта ошибка означает, что Googlebot не удаётся получить файл robots.txt сайта.

Что это значит

Файл robots.txt нужен не всегда, а лишь в том случае, если нужно запретить Googlebot доступ к определённым страницам сайта.

В Справке Search Console говорится следующее:

«Файл robots.txt нужен только в том случае, если на вашем сайте есть содержание, которое не следует включать в индекс поисковых систем. Если вы хотите, чтобы поисковые системы индексировали все страницы вашего сайта, то вам не нужен файл robots.txt, даже пустой. Если файл robots.txt отсутствует, сервер возвратит код статуса 404 в ответ на запрос робота Googlebot, и процесс сканирования сайта будет продолжен. Это не вызовет никаких проблем».

Важна ли она?

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

При ежедневном обновлении сайта данная проблема перейдёт в разряд срочных. Если Googlebot не может загрузить файл robots.txt, сканирование будет отложено.Такой подход позволяет Google избежать индексирования URL, которые вы запретили сканировать.

Как устранить

Убедитесь, что файл robots.txt правильно настроен. Проверьте, какие страницы вы запретили сканировать.

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

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

Несмотря на то, что файл robots.txt содержит лишь несколько строк текста, он может иметь огромное влияние на сайт. Поэтому важно регулярно проверять его.

2. Ошибки URL

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

В Search Console проблемы этого рода разделены на несколько категорий – для десктопов, смартфонов и обычных телефонов. Для большинства сайтов этот раздел охватывает все известные проблемы.

Сходите с ума от количества ошибок? Пометьте все, как исправленные

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

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

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

A) Soft 404

«Мягкие» или ложные ошибки 404 появляются, если несуществующие страницы отдают код 200 («найдено») вместо 404 («не найдено»).

Что это означает

Появление на странице сообщения «404 Файл не найден» ещё не значит, что это страница 404.

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

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

Сервер в ответ на запрос несуществующей страницы должен возвращать код ответа 404 («не найдено») или 410 («удалено»).

На схеме ниже показано, как выглядят HTTP-запросы и ответы:

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

Ложные ошибки 404 также появляются, если на страницах настроен 301 редирект на нерелевантные URL, такие как главная страница.

Google говорит об ошибках soft 404 следующее:

«При возвращении для несуществующей страницы кода, отличного от 404 и 410, (или при перенаправлении на другую страницу, например на главную, вместо возвращения кода 404), возникают дополнительные проблемы».

Хотя здесь поисковик даёт некие ориентиры, до конца непонятно, в каких случаях переадресация с устаревшей страницы на главную допустима, а в каких – нет.

На практике, если вы переадресовываете большое количество страниц на главную, Google может интерпретировать эти редиректы как ложные ошибки 404, а не перенаправление 301.

При этом при переадресации устаревшей страницы на похожую регистрация «мягкой» ошибки 404 маловероятна.

Важны ли они?

Если URL, помеченные как soft 404, не являются критически важными для сайта и не «съедают» краулинговый бюджет сайта, тогда работу над ними можно отложить.

Если важные страницы сайта регистрируются как soft 404, необходимо исправить эти ошибки. Страницы товаров, категорий или генерации лидов не должны регистрироваться как soft 404,если это актуальные страницы. Уделите особое внимание тем страницам, которые приносят сайту доход.

Если у вас большое количество «мягких» ошибок 404 по отношению к общему объёму страниц на сайте, действовать нужно быстро. Наличие таких ошибок может съедать бюджет сканирования вашего сайта.

Как устранить

Несуществующие страницы:

• Убедитесь, что сервер возвращает код ответа HTTP 404 или 410, а не 200;
• Проверьте, чтобы с помощью 301 редиректа устаревшие страницы переадресовывались на релевантные, похожие страницы сайта;
• Не перенаправляйте большое количество устаревших страниц на главную страницу. Они должны возвращать ошибку 404 или переадресовываться на похожие страницы.

Актуальные страницы:

• Убедитесь, что страница содержит достаточное количество контента. Страницы с неинформативным содержимым могут расцениваться как ложные ошибки 404.
• Убедитесь, что контент на странице не обозначает её как страницу 404, если при этом возвращается код ответа сервера 200.

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

B) 404

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

Что это означает?

Этот вид ошибок сканирования чаще всего воспринимается неверно. Самой частой реакцией на них является страх.

При этом Google утверждает, что бояться таких ошибок не стоит:

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

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

В каких случаях ошибки 404 нужно исправлять, а в каких – можно игнорировать, не всегда понятно. Глава Moz Рэнд Фишкин в 2009 году предложил следующий полезный совет (и он до сих пор актуален):

«Сталкиваясь с ошибками 404, не стоит предпринимать никаких действий до тех пор, пока эти страницы:

• не получают важных ссылок с внешних источников;
• не получают значимого количества трафика;
• не имеют очевидного URL, который посетители/ссылки намерены достичь».

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

Энни Кушинг из агентства SEER Interactive также предпочитает метод Фишкина и рекомендует следующее:

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

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

Важны ли они?

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

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

Как устранить

Если важные страницы возвращают ошибку 404, для её устранения выполните следующие шаги:

• Убедитесь, что в CMS страница опубликована, а не сохранена как черновик или удалена.
• Убедитесь, что URL с ошибкой 404 – нужная страница, а не один из её вариантов.
• Проверьте, отображается ли эта ошибка в www и не-www версиях сайта. Также проверьте http и https версии ресурса.
• Если вы хотите настроить переадресацию, убедитесь, что она будет вести на релевантную страницу.

Другими словами, если страница устарела, оживите её. Если вам это не нужно, настройте 301 редирект на подходящую страницу.

Как сделать так, чтобы устаревшие URL с ошибкой 404 не отображались в отчёте

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

Чтобы найти ссылки на страницы 404, нужно перейти в раздел «Ошибки сканирования» и выбрать «Ошибки URL»:

Затем кликните на URL, который вы хотите исправить.

В коде страницы найдите ссылку:

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

Кроме того, ссылки на устаревшие страницы могут содержаться в старых файлах Sitemap. В таком случае нужно настроить код ответа сервера 404 для этих файлов. Переадресовывать их на актуальную карту сайта не нужно.

C) Доступ запрещён

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

Что это означает

Ошибки «Доступ запрещен» могут возникнуть по следующим причинам:

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

Важны ли они?

Если заблокированные страницы важны, то наличие таких ошибок требует срочных действий.

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

Как исправить?

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

• уберите со страницы форму авторизации;
• проверьте настройки файла robots.txt и убедитесь, что он не блокирует Googlebot;
• используйте инструмент для проверки файла robots.txt. С его помощью вы сможете увидеть, как робот Googlebot будет интерпретировать содержание файла robots.txt;
• чтобы понять, как Googlebot видит ваш сайт, используйте инструмент «Просмотреть как Googlebot».

Просканируйте свой сайт с помощью Screaming Frog. Он покажет, требуется ли авторизация на страницах.

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

D) Ошибки невыполнения перехода
Что это означает

В этой категории перечислены URL, на которые робот Googlebot не смог перейти. Чаще всего такие ошибки связаны с использованием Flash, Javascript и редиректов на сайте.

Важны ли они?

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

Как устранить

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

Для проверки сайта на наличие подобных проблем Google рекомендует использовать текстовый браузер Lynx или инструмент «Просмотреть как Googlebot». Ещё один полезный инструмент – расширение User-Agent Switcher для Chrome.

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

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

• Проверьте цепочки редиректов. Если перенаправлений слишком много (больше 5), Googlebot не будет переходить по всей цепочке.
• При возможности обновите архитектуру сайта, чтобы на каждую его страницу вела хотя бы одна статическая текстовая ссылка. Минимизируйте количество редиректов.
• Не включайте URL с переадресацией в файл Sitemap. Включайте целевой URL.

Больше данных об ошибках можно получить с помощью Search Console API.

Другие инструменты

• Screaming Frog SEO Spider – отличный инструмент для сканирования сайта и выявления ошибок переадресации;
• Moz Pro Site Crawl;
• Raven Tools Site Auditor.

E) Ошибки сервера и ошибки DNS

В разделе «Ошибки URL» также могут отображаться ошибки сервера и ошибки DNS. Устранять их нужно теми же способами, которые описаны для раздела «Ошибки сайта».

Ниже – общая таблица по ошибкам URL, которую можно использовать в качестве памятки:

Заключение

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

Автор рекомендует всем вебмастерам ознакомиться со справочной документацией по Google Search Console. При появлении вопросов можно обратиться к следующим ресурсам:

• Webmaster Central Help Forum
• Webmaster Central FAQs: Crawling, indexing, & ranking
• Webmaster Central Blog
• Справочная статья об ошибках сканирования в Search Console

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

За последние годы Google Webmaster Tools существенно изменился. Изменилось даже название сервиса — Google Search Console. И теперь, когда Google Analytics не предоставляет данные о ключевых словах, приходится больше полагаться на Search Console.

В старом Webmaster Tools отсутствовали, в частности, разделы «Search Analytics» и «Links to Your Site». И хотя мы никогда не будем полностью довольны инструментами Google, все же эти сервисы предоставляют полезную информацию (время от времени) для эффективного SEO продвижения сайта.

Ошибки сканирования сайтов (Crawl Errors)

Одно из изменений, произошедших в последние годы в Search Console — интерфейс ошибок (Crawl Errors). Поисковая консоль включает в себя два главных раздела: Site Errors и URL Errors. Категоризация ошибок таким образом выглядит достаточно наглядно — ведь важно различать ошибки на уровне сайта и ошибки на уровне страницы.

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

1) Ошибки сайта

В разделе Site Errors показаны общие ошибки веб-сайта за последние 90 дней.

Если вы производили определенную активность за последние 90 дней, это будет выглядеть так:

Если за последние 90 дней у вас не было ошибок, вы увидите следующее:

Ошибки должны проверяться как минимум каждые 90 дней. Регулярные проверки — это лучший вариант.

A) Ошибки DNS

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

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

DNS является важным аспектом, т.к. это первое, что открывает доступ к сайту.

Google рекомендует использовать инструмент Fetch as Google. Также можно проконсультироваться насчет возможного наличия проблем у DNS-провайдера. И убедиться в том, что сервер высвечивает код ошибок 404 или 500.

Другие полезные инструменты:

• ISUP.me
• Web-Sniffer.net

Б) Ошибки сервера

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

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

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

Прежде, чем переходить к устранению серверных ошибок, необходимо установить характер ошибки:

• Истечение времени ожидания (Timeout)
• Усеченные заголовки (Truncated headers)
• Обрыв соединения (Connection reset)
• Усеченный отклик (Truncated response)
• Отказано в соединении (Connection refused)
• Не удалось установить соединение (Connect failed)
• Истечение времени ожидания соединения (Connect timeout)
• Нет отклика (No response)

В) Ошибки доступа к файлу robots.txt

Это значит, что Googlebot не может извлечь ваш файл robots.txt, расположенный по адресу [вашдомен.com]/robots.txt.

Search Console help:

«Файл robots.txt нужен лишь в том случае, если на сайте присутствует определенный контент, который вы бы хотели добавить в индекс поисковых систем. Если хотите, чтобы поисковые системы индексировали весь контент сайта, файл robots.txt не нужен».

Это важный аспект. Для небольших веб-сайтов, которые нечасто обновляются, устранение данной ошибки не требует такой уж безотлагательности. Файл robots.txt более важен для сайтов, которые ежедневно публикуют новый контент.

Если Googlebot не может загрузить ваш robots.txt, Google не будет сканировать сайт, а равно и индексировать новые страницы и изменения. Это может привести к существенным проблемам в продвижении сайта под Google.

Важно проверить конфигурации файла robots.txt и страницы, доступные для сканирования Googlebot. Убедиться, что линия «Disallow: /» отсутствует, за исключением ситуаций, когда по определенным причинам вы не хотите, чтобы сайт появлялся в поисковых результатах.

Лучше вообще обойтись без robots.txt. Если файла robots.txt нет, тогда Google будет сканировать сайт как обычно. Если файл содержит ошибки, Google приостановит сканирование, до тех пор пока ошибки не будут исправлены.

2) Ошибки URL

Ошибки URL влияют только на отдельные страницы сайта, а не на сайт в целом.

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

Совет: если ошибок слишком много, и вам надоело их исправлять, просто отметьте все как исправленные.

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

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

A) Программные ошибки 404 (Soft 404)

Программная ошибка 404 (или т.н. «мягкая ошибка» Soft 404) — это когда страница высвечивает 200 (найдена), вместо 404 (не найдена).

И тот факт, что страница 404 выглядит как 404, еще не значит, что все и на самом деле так.

«Если на странице появляется сообщение «404 Файл не найден», это не означает, что это страница 404. Если на клетке с жирафом висит табличка «собака», это не значит, что в клетке действительно собака», — support.google.com.

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

«Обратная сторона» страницы 404 — это видимый для веб-паука код ответа HTTP.

Google рекомендует: «Настроить веб-сайт так, чтобы при запросе несуществующих страниц возвращался код ответа 404 (страница не найдена) или 410 (страница удалена)».

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

«При возвращении кода для несуществующей страницы, отличного от 404 и 410, (или при перенаправлении на другую страницу, например на главную, вместо возвращения кода 404), могут возникнуть дополнительные проблемы».

Когда множество страниц перенаправляется на главную, Google рассматривает эти страницы как soft 404, а не как 301.

Для страниц, которых больше не существует:

• Удостоверьтесь, что при запросе несуществующих страниц возвращается код ответа 404 (страница не найдена) или 410 (страница удалена), а не 200 (успешный запрос).
• Сделайте перенаправление (301) для каждой старой страницы на соответствующую страницу сайта.
• Не перенаправляйте большое количество «мертвых» страниц на главную. Они должны быть 404, или перенаправляться на похожие страницы.

Для рабочих страниц:

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

Б) 404

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

Google сообщает, что «В общем, ошибки 404 не влияют на рейтинг сайта в Google, поэтому их можно смело игнорировать».

Но если это важная страница, игнорировать ошибку 404 нельзя.

Совет Рэнда Фишкина:

«Если страница:

а) Не получает важные ссылки от внешних источников,

а) Посещаемость страницы невысока,

в) И/или у нее нет заметного URL-адреса, на который посетители могут заходить,

Тогда можно оставить страницу как 404».

Если важные страницы высвечиваются как 404:

1. Удостоверьтесь, что опубликованная страница из вашей CMS не находится в режиме черновика и не удалена.
2. Проверьте, появляется ли эта ошибка на версиях сайта с www или без www, http или https.  

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

Как сделать, чтобы старые 404 не показывались в отчете о сканировании

Если 404 URL не важен, просто игнорируйте его, как советует Google. Но чтобы ошибок не было видно в отчете, придется проделать дополнительную работу. Google показывает только ошибки 404, если ваш сайт или внешний сайт ведут на страницу 404.

Найти ссылки, ведущие на страницу 404, можно так: Crawl Errors > URL Errors.

Затем кликните URL, который хотите исправить

Искомая ссылка быстрее найдется в исходом коде страницы:

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

В) Отказ в доступе (Access denied)

Отказ в доступе означает, что Googlebot не может сканировать страницу.

Причины:

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

Ошибка, сходная с soft и 404. Если блокируемая страница важна и должна индексироваться, тогда требуется незамедлительное вмешательство. Если нет — можно игнорировать подобные ошибки.

Для исправления понадобится устранить элементы, блокирующие доступ Googlebot:

• Уберите вход по логину (логин на странице или всплывающее окно) для страниц, которые нужны для индексации
• Убедитесь, что в файле robots.txt содержатся страницы, которые Googlebot не должен сканировать
• Используйте Fetch as Google, чтобы узнать, как Googlebot сканирует ваш сайт
• Просканируйте сайт с помощью инструмента Screaming Frog

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

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

 В «Google Search Console» есть штука называемая «Mobile-Friendly Test tool«, на результаты которой опирается гугл решая индексировать ли страницу или нет.

Относительно с недавних (с конца 2016-го года) пор гугл ударился в «Mobile-first Indexing», а потому теперь рейтинг страницы и позиция в поисковой выдаче напрямую зависит от степени её оптимизированости под мобильные устройства:

Подготовка к индексированию с приоритетом мобильного контента

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

Проблемы Mobile-Friendly Test tool

Главная проблема с «Mobile-Friendly Test tool» в том, что работает оно криво и косо, что проявляется в ничем не обоснованных ошибках типа:

При этом, а ни изменение размера шрифта, ни расстояние между элементами не решают проблему.

 В правой части окна результатов проверки «Mobile-Friendly Test tool» можно видеть «Проблемы при загрузке страницы. Подробнее», кликнув на «Подробнее» нашему взору откроются «Данные о ходе загрузки страницы»:

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

Изображение — Другая ошибка

Данный глюк, а это именно глюк, в «Mobile-Friendly Test tool» существует довольно давно, выполоскал мозги многим СЕО-пропихаторам и вызвал множественные холивары на просторах Интернетов:

Гугл не видит большинство картинок на сайте — Cправка — Search Console

…

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

Уже более года обещают пофиксить данный инструмент.

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

Так вот, проверка страницы в «Mobile-Friendly Test tool» и одновременный анализ лог-файлов сервера показал, что выдавая «Другая ошибка» по изображениям, — в отрезок времени с начала проверки и до момента завершения эти самые изображения никем, включая робота гугла, не запрашивались, записей о превышении лимитов на подключения не наблюдалось.

По неизвестным причинам аналогичные глюки могут быть с другими типами, например «Скрипт Другая ошибка».

Сообщения из консоли JavaScript

Ещё один глюкодром «Mobile-Friendly Test tool«.

Uncaught TypeError: $(...).tooltip is not a function at HTMLDocument.<anonymous> ...

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

Другие глюки

«Mobile-Friendly Test tool» может засыпать также и другим бредом в стиле «preloaded using link preload but not used«:

The resource /…/*.min.js was preloaded using link preload but not used within a few seconds from the window’s load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.

Глюкам «Mobile-Friendly Test tool» нет счёта, потому перечислить их все не представляется возможным.

Выводы

Выводы думаю здесь очевидны:

1. «Mobile-Friendly Test tool» — совсем не «Friendly» и как «Test tool» рассматриваться не может;
2. От этой байды у многих не по праву страдает посещаемость;
3. Гуглу очевидно многие лета плевать на «кривожопость» ихней системы оценки сайтов на оптимизированость под мобильные устройства.

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

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

Особую ненависть испытываю ко всем сайтам, а вернее их разработчикам/админам, которые используют «рэкаптчу» и обхожу такие сайты стороной. ИМХО иногда нет иной возможности выйти в сеть кроме как через ТОР, а пришибленная «рэкаптча» кроме своей жуткой «кумарности» ещё довольно часто тупо и наглухо блокирует ТОР сети.

В последние 2-3 года поиск от гугла превратился в глюкодромное, рэкаптчей мозгвыносящее … лала-ла-лала-ла. А теперь все вместе: Гугло х.йло! Лала-ла-лала-ла.

Как проходит индексация в 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 Search Console

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просто вставьте 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 из всех трех блоков в отчете.

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

Но иногда сообщения об ошибках могут показаться непонятными, а ошибки невозможно исправить — однако это не так!

Убедитесь, что вы исправили все ошибки Search Console с помощью приведенных ниже руководств, а затем внимательно посмотрите на свой рейтинг Google PageSpeed ​​Insights, чтобы ваш сайт был максимально оптимизирован и поднялся в результатах Google.

Категории проблем поиска Google для решения

• Проблемы покрытия
• Основные проблемы с видами в Интернете
• Проблемы с мобильным удобством использования
  
• Проблемы с усилителями
• Улучшения проблемы

Решение проблем с покрытием Google Search Console

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

Решение проблем с ошибкой сервера (5xx)

Ошибка сервера консоли поиска (5xx) обычно означает, что сервер не был доступен во время проверки ботом Google.

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

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

Решение проблем с ошибкой перенаправления

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

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

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

Решение проблемы со сканированием отправленного URL

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

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

В этом случае убедитесь, что вы используете лучший дешевый веб-хостинг, который будет достаточно быстрым, чтобы ответить вовремя, и что ваш веб-сайт оптимизирован для оптимальной оценки  Google PageSpeed ​​Insights   и что вы становитесь зеленым, если это возможно, например, используя Система Site Speed ​​Accelerator, чтобы сделать ваш сайт достаточно быстрым.

Решение проблем с Core Web Vitals в Google Search Console

Решение проблемы с LCP Core web Vitals: более 4 с (мобильный)

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

Значение LCP: Самая большая содержательная краска

Самый простой способ решить эту проблему — убедиться, что ваша оценка  Google PageSpeed ​​Insights   имеет зеленый цвет и что время загрузки вашей страницы как можно быстрее, путем внедрения всех лучших практик скорости Интернета, таких как отложенная загрузка изображений, оптимизация Javascript и CSS, и многое другое.

Чтобы все эти вещи были применены на вашем веб-сайте и прошли проверку Core Web Vitals LCP, самым быстрым и надежным решением является внедрение Site Speed ​​Accelerator, который решит все эти проблемы — и даже больше — от вашего имени, и также реализуйте любую будущую оптимизацию, которая возникнет.

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

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

Решение этих проблем гарантирует, что ваш сайт получит столько мобильного трафика, сколько он того заслуживает!

Решение проблемы с текстом, слишком мелким для чтения

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

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

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

Решение проблемы с неустановленным окном просмотра

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

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

Обычно это можно решить, вставив эту стандартную инструкцию CSS в вашу основную таблицу стилей:

<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1" />

Решение проблемы слишком близких друг к другу интерактивных элементов

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

Единственный способ решить эту проблему — дважды проверить отображение веб-сайта на мобильном устройстве либо прямо в браузере (мобильный режим: CTRL + M в Mozilla Firefox и CTRL + Shift + I в Google Chrome), либо на мобильном устройстве.

Затем, чтобы отделить элементы друг от друга, вам придется либо настроить таблицу стилей дизайна, если вы знаете, как это сделать, либо изменить тему веб-сайта, если вы используете CMS, такую ​​как решение для ведения блогов WordPress.

Справка Search Console — интерактивные элементы расположены слишком близко друг к другу

Решение проблемы с контентом шире экрана

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

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

Содержание справки Search Console шире экрана

Решение проблемы Viewport, не установленной на ширину устройства

Эта проблема аналогична проблеме «Viewport not set» и может быть решена, как описано выше, путем добавления простой строки инструкции в вашу таблицу стилей CSS.

Для области просмотра справки Search Console не задано значение ширина устройства

Решение проблем с AMP в Google Search Console

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

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

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

Решение ссылочного URL AMP не является AMP

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

Значение AMP: ускоренные мобильные страницы

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

Устранение атрибута Disallowed или значения атрибута, присутствующего в теге HTML.

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

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

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

Решение проблемы Тег img следует заменить на эквивалентный тег amp-img.

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

Устранение присутствия запрещенного тега.

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

Пример запрещенного тега в AMP: tbody

Решение тега сценария компонента AMP присутствует, но не используется.

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

При решении HTML-тега AMP отсутствуют атрибуты макета.

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

Убедитесь, что весь обязательный контент и атрибуты AMP присутствуют в вашем коде HTMl.

Решение проблемы со сканированием

Что касается стандартных страниц, сканирование Google не может добраться до вашей страницы. Убедитесь, что хост вашего веб-сайта работает должным образом, что ваш сайт не отключен и что ваша оценка  Google PageSpeed ​​Insights   достаточно хороша для обеспечения своевременной загрузки данных с любого другого сервера или посетителя.

Решение проблемы Документ слишком сложен.

Это происходит, когда ваш DOM слишком длинный, а это означает, что ваш HTML-документ включает слишком много элементов и слишком много подэлементов.

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

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

Решение Обязательный атрибут отсутствует в теге HTML.

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

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

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

Для решения тега A на этой странице требуется тег сценария компонента AMP, который отсутствует.

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

Документация по AMP Accelerated Mobile Pages

Решение Custom JavaScript не разрешено.

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

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

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

Исправлено: пользовательский JavaScript не разрешен AMP, Google Search Console

Решение ошибки сервера (5xx)

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

Solving the Google Search Console Улучшения проблемы

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

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

Решение вопросов улучшения видео

Решение пропущенных проблем с описанием поля

Эта проблема означает, что схема videoObject Schema Markup для ваших встроенных видеороликов не заполнена должным образом, так как описание является обязательным для любого видео, включенного на веб -странице.

Если вы включаете видео на свои веб -страницы, которые автоматически внедряют на ваш веб -сайт внешней службой, такой как %%* ezoic* Video Player%другом Поля правильно заполнены.

Часто Задаваемые Вопросы

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

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

Сканирование (краулинг) — это процесс обхода страниц и ресурсов сайта роботами поисковых систем для дальнейшей индексации. На странице собраны ответы Google касающиеся сканирования сайтов.