Как проверить, можно ли проиндексировать страницу

Адрес можно проиндексировать, если он отдаёт код 200, не перенаправляет, не содержит noindex ни в HTML, ни в заголовке X-Robots-Tag, не закрыт для Googlebot в robots.txt, а его canonical указывает на него самого. Если не выполнено хоть одно условие, Google этот адрес не проиндексирует, каким бы хорошим ни был текст. Индексируемая не значит проиндексированная, но это необходимый минимум.

Шесть проверок одним взглядом

1. Какой код ответа отдаёт адрес?

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

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://site.com/page/

В первой строке будет код. Нужен HTTP/2 200. 404 или 410 значит, что для Google страницы нет. 403 или 401 значит, что доступ закрыт, часто файрволом или защитой от ботов, которая ведёт себя с Googlebot иначе, чем с браузером. 5xx значит, что сервер сбоит.

Остерегайтесь «ложных 404»: страница отдаёт 200, но показывает «не найдено» или пустой список. По коду она проходит, но Google, скорее всего, сочтёт её страницей ошибки.

2. Есть ли редирект?

Если код 301, 302, 307 или 308, смотрите заголовок location. Чтобы увидеть всю цепочку:

curl -sIL https://site.com/page/ | grep -iE "^(HTTP|location)"

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

3. Есть ли noindex в HTML?

Найдите в коде страницы meta-тег robots:

curl -s https://site.com/page/ | grep -io '<meta[^>]*name="\(robots\|googlebot\)"[^>]*>'

Всё, где есть noindex, запрещает индексацию. Для Google действуют и name="robots", и name="googlebot". Частые виновники: SEO-плагин с включённым «попросить поисковые системы не индексировать сайт», настройки стенда, перенесённые на рабочий сайт, и шаблоны, которые закрывают noindex целые типы страниц.

Если сайт собирает страницы на JavaScript, посмотрите и отрисованный HTML в Search Console. Скрипт, который добавляет noindex после загрузки, тоже может заблокировать индексацию.

4. Есть ли noindex в HTTP-заголовках?

Это легко пропустить, потому что в коде страницы такого запрета никогда не видно:

curl -sI https://site.com/page/ | grep -i x-robots-tag

Если видите X-Robots-Tag: noindex, значит, сервер, правило CDN или плагин говорит Google не индексировать страницу. Часто его ставят намеренно для PDF или тестового домена, а потом он случайно остаётся включённым на весь сайт.

5. Разрешает ли robots.txt сканирование?

Откройте файл и прочитайте правила, которые относятся к Googlebot:

curl -s https://site.com/robots.txt

Что нужно знать, читая его:

• Google следует самой конкретной подходящей группе User-agent. Если есть группа User-agent: Googlebot, группа * к Googlebot не применяется вовсе.
• Правила работают по префиксу. Disallow: /blog закрывает /blog/, /blog-news/ и /blog.html.
• Если подходят и Allow, и Disallow, побеждает более длинное правило.
• * означает любую последовательность символов, $ обозначает конец адреса.

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

6. Куда указывает canonical?

Найдите canonical в HTML и в заголовках:

curl -s https://site.com/page/ | grep -io '<link[^>]*rel="canonical"[^>]*>'
curl -sI https://site.com/page/ | grep -i '^link:.*canonical'

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

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

Ваши проверки могут выглядеть чистыми, пока Googlebot видит другое. Следите за этим:

• Разные ответы в зависимости от user agent или IP. Некоторые файрволы пропускают ваш браузер и проверяют всё, что представилось Googlebot, или наоборот. Подмена user agent в curl не то же самое, что запрос с IP-адресов Google, поэтому подтверждайте результат проверкой на сайте в Search Console.
• Закэшированные ответы. CDN может отдавать старую версию со старым noindex или canonical. Посмотрите заголовки кэша и сбросьте кэш после правки.
• Слэш и регистр. /Page, /page и /page/ это разные адреса. Проверяйте ровно тот, что отправляете.
• Мобильная и десктопная версии. Google сканирует в основном как смартфон. Если мобильная версия прячет контент или ставит другие директивы, в счёт идёт именно она.
• Языковые версии. При hreflang каждая версия должна быть канонической сама для себя, а не для основного языка.

Короткий список можно проверить руками, прогнав его циклом в терминале:

while read u; do
  printf "%s  " "$u"
  curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$u"
done < urls.txt

Команда выведет код ответа и, если есть, адрес редиректа для каждой строки файла. Всё, что не 200 без редиректа, стоит разобрать до отправки.

Проверка в Search Console

Если у вас есть доступ к ресурсу, проверка URL делает почти всё это за раз. Нажмите «Проверить страницу на сайте», чтобы увидеть текущее состояние, а не результат последнего сканирования. Будет видно, доступна ли страница, разрешено ли индексирование, какой канонический адрес указали вы и какой выбрал Google, и отрисованный HTML. Одного она не умеет: проверять много адресов сразу.

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

Для целой карты сайта ручные команды не годятся. Десктопный краулер выгрузит коды ответа, директивы и canonical по всем адресам. Или отправьте список в @IndexForgeBot: он прогонит эти же шесть проверок по каждой ссылке как Googlebot, покажет, сколько прошло, и разложит остальные по причинам. Проверка бесплатна. Платите вы только $0.01 за ссылки, которые решите отправить на индексацию.

Индексируемая не значит проиндексированная

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

Чек-лист

• Код 200 при запросе от имени Googlebot
• Редиректа нет, или вы проверяете конечный адрес
• Нет noindex в meta robots и meta googlebot
• Нет noindex в X-Robots-Tag
• Путь открыт для Googlebot в robots.txt
• Canonical указывает ровно на этот адрес
• В отрисованном HTML есть основной контент

Частые вопросы

302 хуже 301 для индексации?

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

Мешает ли индексации nofollow на внутренних ссылках?

Нет, nofollow это не noindex. Но если на страницу ведут только nofollow-ссылки, у Google слабее путь к ней, поэтому внутри сайта ставьте обычные ссылки.

А если страница закрыта в robots.txt и при этом стоит noindex?

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

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

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

Чем проверка на сайте в Search Console отличается от curl?

Search Console делает запрос с настоящих адресов Google и показывает отрисованную страницу, то есть то, что действительно увидит Googlebot. curl быстрее и работает для любых сайтов, в том числе чужих, но видит только исходный ответ сервера и может получить не то, что получил бы робот Google. Для разовой проверки важной страницы надёжнее Search Console, для списков удобнее терминал.