Как добавить сайт в Google и ускорить индексацию

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

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

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

Неделя на индексацию нового сайта — цифра, которой нет в документации

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

Первая — про сканирование. Робот должен сначала загрузить страницу, и Google говорит, что это «может занять от нескольких дней до нескольких недель». Вторая — про индексацию уже просканированной страницы. Справка Search Console формулирует её так: «индексация обычно занимает около суток, но в некоторых случаях значительно дольше».

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

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

Что на самом деле значит «добавить сайт в Google»

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

То, что мы называем «добавить сайт в поисковую систему Google», на деле складывается из трёх вещей:

1. Открыть роботу доступ — чтобы сайт не был закрыт в robots.txt и не отдавал noindex на каждой странице.
2. Показать список страниц — картой сайта.
3. Получить обратную связь — подключить Search Console, чтобы видеть, что Google со всем этим сделал.

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

Search Console — «Домен» или «Префикс URL», и почему это не одно и то же

Первый выбор при добавлении сайта — тип ресурса. Именно на нём чаще всего и застревают.

Ресурс типа «Домен» охватывает все субдомены и оба протокола сразу. Подтвердить его можно только DNS-записью у регистратора: способы с HTML-файлом и метатегом для доменного ресурса не работают вообще. Это не сбой интерфейса, так задумано.

Ресурс с префиксом URL включает только адреса, которые начинаются с этого префикса. То есть https://site.com/ и http://site.com/ — два разных ресурса, и данные они будут собирать по отдельности. Зато подтвердить такой ресурс можно файлом, метатегом, через Google Analytics или Tag Manager.

Что из этого брать. Есть доступ к DNS — берите «Домен», он избавляет от зоопарка ресурсов. Доступа нет — берите префикс с тем протоколом и хостом, которые реально работают после редиректов.

Мелочь, о которой мало кто знает: данные для ресурса начинают собираться сразу после добавления, ещё до подтверждения права собственности. То есть промедление с DNS-записью статистики вас не лишает, вы просто пока её не видите. Отдельно существуют ещё и ресурсы для соцсетей, о них мы писали в материале про platform properties в Search Console.

Карта сайта — лимиты, lastmod и мёртвый ping

Карта сайта — это способ показать Google список URL, когда их много. Для отдельных адресов Google рекомендует инструмент проверки URL, для большого количества — именно sitemap.

Что стоит знать до того, как генерировать файл:

• Один файл — максимум 50 МБ в несжатом виде или 50 000 URL. Больше — делить на несколько файлов и собирать индексом карт.
• Кодировка только UTF-8, адреса абсолютные.
• lastmod имеет значение. Google подтвердил, что использует его как сигнал для планирования повторного сканирования уже известных URL. Но только если дата честная: поставить «сегодня» всем страницам разом — быстрый способ обесценить сигнал.
• Отчёт «Файлы Sitemap» показывает максимум 1000 отправленных карт. Отправить можно больше, увидеть нет.

И отдельная ловушка из старых инструкций. Многие гайды до сих пор советуют «пингануть Google после обновления карты» HTTP-запросом на специальный эндпоинт. Этот эндпоинт мёртв. Google объявил о его отключении в июне 2023 года, теперь запросы туда возвращают 404, а причину назвал откровенно: подавляющее большинство неаутентифицированных отправок оказалось спамом. Остались два рабочих способа — строка Sitemap: в robots.txt (их можно указывать сколько угодно, и они не привязаны к user-agent) и отправка через Search Console.

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

Запрос на переиндексацию и квота, чисел которой никто не знает

Для отдельной страницы работает инструмент проверки URL в Search Console. Он показывает состояние проиндексированной Google версии страницы и позволяет проверить, может ли URL вообще быть проиндексирован. Это самый быстрый способ понять, проблема в самой странице или в очереди.

Дальше — «Запрос на индексирование». И тут два факта, которые стоит принять сразу.

Первый: квота существует, но Google её чисел не публикует. В документации сказано, что квота на отправку отдельных URL есть; в справке Search Console — что для каждого ресурса действует суточный лимит проверок. Конкретных цифр нет нигде. Популярные в сети «10 URL в сутки» или «50 URL в сутки» — это фольклор, который кочует из блога в блог. Не планируйте работу вокруг чужих догадок.

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

Если страница не индексируется неделями, дело обычно не в кнопке, а в качестве или техническом состоянии страницы. Что именно проверять, расписано в материале про SEO-аудит сайтов.

Indexing API не проиндексирует вашу страницу

Примерно здесь в чужих гайдах появляется совет «используйте Indexing API, и страница будет в индексе за час». Это неправда, и опровергает её одно предложение документации.

Indexing API можно применять только к страницам с разметкой JobPosting или BroadcastEvent внутри VideoObject. То есть вакансии и прямые трансляции. Обычная статья блога, карточка товара, страница услуги под этот API не подпадают, и отправлять их туда бесполезно.

Цифры 200 publish-запросов в сутки и 380 запросов в минуту, которые иногда цитируют как «лимиты индексации в Google», относятся именно к этому API, а не к Search Console. Google добавляет, что квота может как расти, так и уменьшаться в зависимости от качества документов, а попытки её обойти, в том числе несколькими аккаунтами, наказываются отзывом доступа. Все отправки проходят проверку на спам.

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

IndexNow — полезный протокол, который к Google отношения не имеет

IndexNow сообщает поисковым системам об изменении страницы одним запросом: до 10 000 URL за раз, с ключом из 8–128 шестнадцатеричных символов, который лежит в корне домена и подтверждает ваше право на него. URL, отправленные одной системе, автоматически передаются всем остальным участникам протокола.

Участники по FAQ самого протокола — Amazon, Bing, Naver, Seznam.cz, Yandex и Yep. Google в этом списке нет. Поэтому любой совет «включите IndexNow, чтобы ускорить индексацию в Google» ошибочен по определению.

Протокол от этого не становится ненужным. Для украинского бизнеса Bing — это ещё и трафик из Copilot, а сам IndexNow честно предупреждает, что мгновенной индексации не гарантирует, лишь повышает вероятность более быстрого обнаружения изменений. Просто считайте его работой с другими системами, а не с Google. Кстати, с видимостью в AI-ответах связана отдельная дисциплина, GEO-оптимизация, и она тоже не про Search Console.

Отдельно: суточную квоту на отправку URL в Bing мы не называем, потому что официальная справка с этим числом сейчас недоступна. Увидите такую цифру в чужой статье — спросите источник.

robots.txt и главная ошибка, из-за которой страницы исчезают

Файл robots.txt должен лежать в корневом каталоге, и его правила действуют только для того хоста, протокола и порта, где он размещён. Robots.txt на http://site.com не управляет роботом на https://site.com.

Три вещи, о которых почти никто не пишет:

• Лимит 500 KiB. Всё, что после него, Google просто игнорирует.
• Кеш до суток. Изменения в robots.txt действуют не мгновенно: Google обычно держит содержимое файла до 24 часов, а иногда дольше.
• Robots.txt не прячет страницу из поиска. Он управляет доступом сканеров к URL, и Google прямо пишет, что это не механизм сокрытия. Закрытая в robots.txt страница всё равно может попасть в индекс, если на неё ссылаются другие сайты.

А теперь самая дорогая ошибка, которой нет ни в одном из топовых гайдов.

Noindex под Disallow не сработает. Логика кажется безупречной: закрываем страницу в robots.txt и ставим на неё метатег noindex, двойная защита. На деле выходит ноль защиты. Чтобы noindex подействовал, страница не должна быть заблокирована в robots.txt и обязана оставаться доступной сканеру. Иначе робот никогда не увидит директиву, и страница может дальше показываться в результатах. Это записано в документации Google о noindex буквально.

Работает это так: как только Googlebot просканирует страницу и извлечёт тег или заголовок, Google убирает её из поиска полностью, независимо от того, сколько сайтов на неё ссылаются. Но для этого ему надо дать её прочитать.

Зеркальная версия той же ошибки убивает новые сайты. Стейджинг закрыли от индексации, сайт переехал в продакшн, Disallow: / или noindex в шаблоне остались. Сайт живой, красивый, быстрый — и невидимый. Первое, что стоит открыть после релиза, — это site.com/robots.txt и код главной страницы.

Порядок действий после запуска сайта

Что мы делаем на каждом релизе, в этой последовательности:

1. Проверяем robots.txt и метатеги. Нет Disallow: /, нет noindex в шаблоне. На выходе — сайт открыт для сканирования.
2. Добавляем ресурс в Search Console. Тип «Домен», если есть доступ к DNS. На выходе — подтверждённые права и начало сбора данных.
3. Генерируем карту сайта и указываем её в robots.txt. UTF-8, абсолютные URL, честный lastmod, деление на файлы, если URL больше 50 000. На выходе — у Google есть полный список страниц.
4. Отправляем карту через Search Console и проверяем отчёт на ошибки. На выходе — карта прочитана.
5. Просим просканировать ключевые страницы через инструмент проверки URL. По одному разу, без фанатизма.
6. Ждём и смотрим отчёты. Не кнопку нажимаем, а читаем причины исключения страниц из индекса.

Скорость загрузки на этом этапе тоже весит: медленный сайт сканируется хуже, а как это исправить, мы разбирали в материале про скорость сайта. А когда страницы в индексе уже есть, а позиций нет, начинается другая работа — поисковая оптимизация и доказательства экспертности, о которых мы писали в материале про E-E-A-T.

FAQ