Речь только о десктопной выдаче Google, страна или город. Проверка позиций сайта в гугл в кабинете SpeedyIndex (раздел Rank Tracker, запуск 2 ноября 2026) не снимает Яндекс, Bing, мобильную выдачу и YouTube. Если в отчёте для руководителя ждут ещё и Яндекс, это другой инструмент и другая строка бюджета. Здесь её нет.

Из чего строка вообще состоит

Один запуск по одному ключу — это не «проверка проекта» одной суммой. Цена всегда за ключ. Полная ставка при глубине Топ-10 — 4 токена за загруженную страницу выдачи. Если на первой странице есть AI Overview, эта первая страница стоит 8 токенов. До 2 декабря 2026 стартовая цена — 2 токена за ключ, а первая страница с ИИ-обзором — 4 токена. Формулировка, которая не устареет на следующий день после акции: от 4 токенов за ключ; до 2 декабря 2026 — 2 токена.

Страницы дальше первой (глубина Топ-30, Топ-50 или Топ-100) загружаются и оплачиваются, только пока сайт или конкурент из проекта не найден. Ключ на третьем месте не оплачивает десятую страницу. Ключ, которого нет до конца выбранной глубины, оплачивает загруженные страницы. Поэтому «Топ-100» в настройке — потолок, а не автоматический множитель на десять.

Токены списываются только за запущенные проверки и не сгорают. Месячного минимума нет. Подписка не нужна. Если она есть, она даёт +10% токенов, а не отдельный трекер. При регистрации — 100 токенов. Пакеты — от $5.

Четыре запуска или тридцать

Недельный ритм для небольшого списка — четыре запуска в месяц. Пример из расчёта кабинета: 100 ключей × 4 проверки при глубине Топ-10 без доплаты за ИИ-обзор = 1 600 токенов по полной цене и 800 по стартовой. Это и есть ответ на вопрос, как посчитать месячный бюджет съёма позиций google для одного региона и одной глубины.

Ежедневный запуск того же списка — около 30 проходов. Та же формула, другая середина: 100 × 30 × 4 = 12 000 токенов по полной цене Топ-10 и 6 000 до 2 декабря 2026. Для небольшого сайта это редко оправдано. Дневной ритм оставляют короткому тегу: бренд, запуск, дни после подтверждённого обновления ранжирования. Остальное — раз в неделю. Раз в месяц хватает визитке, которая почти не меняется. Графики в кабинете появляются со второй проверки, так что одиночный «снимок для бюджета» ещё не линия.

В таблице нет ИИ-обзора на первой странице и нет страниц глубже первой. Второй город — это второй проход, не скидка «те же ключи». Два устройства сюда не добавить: мобильную выдачу трекер не снимает.

Глубина, которая раздувает потолок

Топ-10 — одна страница. Топ-30 — до трёх, Топ-50 — до пяти, Топ-100 — до десяти. Потолок на 100 ключей и 4 запуска при Топ-100, если каждый раз грузятся все десять страниц, в десять раз выше строки 1 600. Таким потолок и остаётся, пока сайт или конкурент проекта не находятся раньше. Новый сайт, которого нет на первой странице, чаще доходит до этого потолка. Старый сайт на третьей позиции — почти никогда.

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

Доля ключей с ИИ-обзором на первой странице сдвигает только первую страницу: 8 вместо 4 по полному тарифу, 4 вместо 2 до 2 декабря. Не умножайте 8 на число страниц глубины. Следующие страницы — это обычная плата за загруженную страницу, 4 токена по полному тарифу.

Что в бюджет не входит

Видимость в процентах, средняя позиция, число ключей в Топ-3 и Топ-10, теги, целевые URL, расписание и экспорт — это содержимое отчёта, а не вторая шкала списания. До 10 конкурентов в проекте и вкладка сайтов, которые встречаются в выдаче по вашим ключам, тоже не отдельный тариф в этих правилах. Позиция в отчёте — органика. Ссылка в AI Overview показывается отдельно и позицией не считается. Сохранённая страница выдачи с подсветкой сайта нужна, чтобы цифру можно было сверить глазами. Она не добавляет токены сверх загруженных страниц.

Чужие абонентки в этот расчёт не подставляйте. Сравнивать можно модель: подписка берёт плату за месяц, включая недели без съёма; токены — за запуски. Актуальные ценники других сервисов меняются, и здесь им не место.

Яндекс в ту же формулу не встаёт. Трекер его не снимает. Если съём по Яндексу нужен, его считают в другом месте и не называют функцией Rank Tracker.

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

1. Выпишите ключи, по которым кто-то примет решение. Остальное в первый месяц не ставьте на расписание.
2. Зафиксируйте регион. Страна и город — разные серии, их нельзя усреднить.
3. Поставьте Топ-10, пока не нужно различать 40-е и 80-е места.
4. Назначьте 4 запуска, если смотрите список раз в неделю. Дневной тег — только короткий.
5. Умножьте ключи на запуски на 4 (или на 2 до 2 декабря 2026). Это база без ИИ-обзора.
6. Отдельно прикиньте долю первых страниц с AI Overview и вторую строку потолка по глубине.
7. Добавьте второй регион как ещё один такой же блок, а не как «плюс десять процентов».

Сто токенов при регистрации на стартовой цене Топ-10 закрывают первый проход по короткому списку. Дальше пакет от $5. Токены не сгорают, поэтому пауза в проекте не штрафуется: проверку просто не запускают.

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

Расписание не раздувает список само

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

Не поднимайте глубину «на всякий случай», если ключи и так на первой странице. Топ-100 на таком списке почти не меняет счёт и не меняет решение. Глубже имеет смысл там, где пустая ячейка Топ-10 уже не отвечает, пятнадцатое это место или шестидесятое. Такие ключи выносят в отдельный тег и гоняют реже основного списка.

Шесть языков интерфейса формулу не меняют. Русские подписи полей и английские — один и тот же запуск, одна и та же цена за ключ. Пауза в проекте по-прежнему ноль, пока кнопку запуска не нажали: тишина не тарифицируется.

Вопросы, которые обычно ломают смету

Можно ли сказать «за проверку», без «за ключ»?

Нет. Проверка одного ключа и проверка двухсот ключей стоят по-разному. В тексте и в смете оставляйте «за ключ».

Входит ли Яндекс в те же токены?

Нет. Этот трекер снимает только десктопный Google. Строка «ещё и Яндекс» — другой инструмент.

Почему второй месяц вдруг дороже первого?

Либо вырос список, либо добавился регион, либо глубина стала догружать страницы, потому что сайт перестал находиться на первой, либо на первой странице чаще встречается ИИ-обзор. Формула та же. Сверяйте четыре множителя, а не «тариф подняли».

Нужна ли подписка, чтобы снять позиции раз в неделю?

Нет. Хватает токенов. Подписка необязательна и даёт +10% токенов. Месяца без запусков в счёте нет.

Смета на этом и закрывается.

Telegram · Бот · X · Facebook · YouTube

Сообщение Месячный бюджет съёма: ключи, запуски и глубина появились сначала на SPEEDYINDEX.

Откуда данные

Команда SpeedyIndex через год проверила 15 389 ссылок, которые сама покупала у исполнителей на Fiverr и Kwork: профили, Web 2.0, крауд, статьи и PBN трёх уровней (Tier 1, Tier 2, Tier 3). 21 августа 2026 года каждый URL обошёл краулер с User-Agent Googlebot Smartphone, а 29 октября 2026 года все ссылки проверили на наличие в индексе Google через Google Index Checker SpeedyIndex (запросы site:URL и URL).

Отдельная часть исследования — таблица закрытых типов страниц. Для неё взяли по одной купленной ссылке с каждого из 4 512 сайтов и проверили три источника запрета: robots.txt, meta robots и заголовок X-Robots-Tag. Главные страницы проверили отдельно. Так видно, закрыт ли сайт целиком или только один тип страниц, например профили.

Закрытые от индексации страницы: 457 типов на 443 сайтах

Итог проверки выглядит так:

• 457 закрытых типов страниц на 443 сайтах;
• у 266 из этих сайтов главная открыта для индексации — закрыт только конкретный тип страниц;
• 1 829 типов страниц открыты;
• 308 типов проверить не удалось.

Ключевая цифра здесь — 266. На этих сайтах проверка главной показывает, что всё в порядке, хотя страница, на которой стоит ваша ссылка, закрыта. Классический пример — trello.com: главная открыта для индексации, а профили пользователей (trello.com/u/{id}) закрыты и в robots.txt, и через meta noindex. Такие ссылки при этом продают в пакетах.

Профили, файлы и посты: примеры из таблицы

Ниже — сайты из верхней части таблицы. Все они входят в топ-1 000 доменов, и со всех нам продавали ссылки.

Самое показательное в таблице — пары внутри одного домена. Посты по шаблону facebook.com/{id}/posts/{slug} в списке открытых, а посты по ссылкам вида web.facebook.com/share/p/{id}/ закрыты. На archive.org страницы web.archive.org/web/... открыты, а archive.org/details/{slug} с загруженными документами закрыты. Поэтому оценивать нужно не домен, а конкретный шаблон URL, по которому исполнитель размещает ссылку.

Почему «живая» ссылка всё равно не работает

Закрытые типы страниц — только часть проблемы. Из 15 389 купленных URL ответ HTTP 200 дали 4 750. Но код 200 ещё не значит, что страница может попасть в индекс: 15,7% из них закрыты noindex, а 32,4% имеют хотя бы один запрет индексации. Исполнитель показывает открывающуюся страницу, а Google видит на ней запрет.

По всей выборке с учётом всех сигналов закрыты от индекса 14,8% ссылок. Если смотреть на основную причину по каждому URL, meta robots noindex встретился у 547 ссылок (3,6%), Disallow в robots.txt — у 337 (2,2%), X-Robots-Tag: noindex — у 194 (1,3%).

Открытая страница тоже не гарантирует результата. Даже среди технически чистых URL (HTTP 200, без noindex, Disallow и чужого canonical) в индексе Google оказалось только 8,6%. На популярных площадках из пакетов картина ещё жёстче: Diigo — 0 из 124 URL в индексе, Pinterest — 0 из 54, Medium — 0 из 46, Google Sites — 7 из 77. Запрет индексации — первый фильтр, который отсекает ссылку сразу и навсегда, но не единственный.

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

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

1. Попросите пример размещения. Нужен реальный URL профиля, файла или поста, который исполнитель уже создавал на этой площадке. Главная ничего не скажет: у 266 сайтов из таблицы она открыта при закрытом типе страниц.
2. Откройте robots.txt нужного хоста. Файл действует только для своего хоста, поэтому для web.facebook.com или sway.cloud.microsoft смотрите robots.txt именно поддомена. Найдите группу для Googlebot или User-agent: * и проверьте, нет ли Disallow, который покрывает путь вроде /u/, /scl/ или /share/.
3. Посмотрите meta robots в HTML. Ищите <meta name="robots" content="noindex"> или аналогичный тег для googlebot. Лучше получать страницу с User-Agent Googlebot Smartphone: ответ для робота и для браузера может отличаться.
4. Проверьте заголовки ответа. X-Robots-Tag: noindex не виден в коде страницы — только в HTTP-заголовках (вкладка Network в DevTools или curl -I).
5. Проверьте код ответа, редирект и canonical. Нужен чистый 200 без перенаправления, а canonical не должен указывать на другой URL.
6. Проверьте, есть ли в индексе страницы того же шаблона. Если ни одна страница вида site.com/u/... не находится по запросу site:, это сигнал, что Google такие страницы не берёт.

Учтите одну тонкость. Disallow в robots.txt запрещает сканирование, а noindex — индексирование. Google в документации о блокировке индексирования прямо пишет: чтобы правило noindex сработало, robots.txt не должен блокировать роботу доступ к странице, иначе робот его просто не увидит. Для покупателя ссылки вывод один: любой из этих запретов означает, что страница не участвует в ранжировании как источник ссылки.

Что говорят правила Google

Честно о главном. Согласно правилам Google в отношении спама, покупка или продажа ссылок, которые учитываются при ранжировании, относится к ссылочному спаму. Платные ссылки допустимы для рекламы и спонсорства, если у них указан атрибут rel=»nofollow» или rel=»sponsored». Мы не призываем покупать ссылки. Исследование показывает ещё и практическую сторону: значительная часть купленных ссылок через год просто не работает, а размещение на закрытом типе страниц не работает с первого дня.

Пределы исследования

• Данные — только наши собственные заказы: 12 350 ссылок с Fiverr, 2 886 с Kwork и 153 с других бирж. Другие исполнители и площадки могут давать иную картину.
• Два среза: обход 21 августа 2026 года и проверка индекса 29 октября 2026 года. Площадки меняют правила, и закрытый сегодня тип страниц может открыться позже или наоборот.
• Таблица типов строилась по одной купленной ссылке с каждого из 4 512 сайтов. На сайте могут быть и другие типы страниц с иным статусом; 308 типов проверить не удалось.
• Проверку Cloudflare на JavaScript мы не обходили: 1 832 URL считаются непроверенными, а не мёртвыми. По редиректам не переходили.
• Каждый URL отнесён к одной основной причине, поэтому доля закрытых с учётом всех сигналов (14,8%) выше, чем доля группы «Закрыты от индекса» (8,1%).

Коротко

Популярный домен не гарантирует, что страница с вашей ссылкой открыта для Google. В исследовании 457 типов страниц на 443 сайтах закрыты от индексации, и у 266 из них главная при этом открыта. Среди них — профили, загруженные файлы и посты. Перед оплатой проверяйте конкретный шаблон URL: robots.txt хоста, meta robots, X-Robots-Tag, код ответа, canonical и наличие таких страниц в индексе. После размещения повторяйте проверку через 3, 6 и 12 месяцев: запреты и удаления появляются и спустя время.

Сообщение Какие страницы популярных сайтов закрыты от индексации: профили, файлы и посты появились сначала на SPEEDYINDEX.

Почему Search Console больше не отвечает на вопрос «какое правило сработало»

Раньше в Search Console был отдельный инструмент проверки robots.txt: вставляешь путь, выбираешь робота, видишь подсвеченную строку. В конце 2023 года Google убрал его и запустил отчёт о файлах robots.txt. Отчёт полезен, но отвечает на другой вопрос: смог ли Google получить файл, когда он это сделал, какого размера файл и есть ли в нём ошибки разбора. Какое правило закрывает конкретный адрес, отчёт не показывает.

Для одного адреса на работающем сайте остаётся инструмент проверки URL: в разделе «Индексирование страниц» он покажет, разрешено ли сканирование. Но он работает только с уже опубликованными страницами вашего ресурса, по одной, и с той версией файла, которую Google успел закешировать. Черновик robots.txt им не проверить. Поэтому проверять правила нужно до выкладки, отдельным инструментом.

Как Google выбирает правило: пять пунктов, которые надо держать в голове

1. Одна группа на робота. Googlebot выполняет только ту группу, где указан самый конкретный подходящий user-agent. Если такой группы нет — группу User-agent: *. Группы с одним и тем же user-agent объединяются, а конкретная группа с общей * не складывается никогда.
2. Побеждает самое длинное правило. Из всех подошедших Allow и Disallow решает то, у которого длиннее путь. Порядок строк в файле значения не имеет.
3. При равной длине побеждает Allow. Google применяет наименее строгое из конфликтующих правил.
4. Два спецсимвола. * — любая последовательность символов, $ — конец адреса. Disallow: /*.pdf$ закроет /docs/a.pdf, но не /docs/a.pdf?v=2.
5. Регистр в путях важен. Disallow: /Catalog/ не закрывает /catalog/. А вот имена директив и user-agent регистр не учитывают.

Google поддерживает только четыре поля: user-agent, allow, disallow и sitemap. Crawl-delay, Host и Clean-param из шаблонов под Яндекс Googlebot просто игнорирует. Ещё одна граница — 500 КиБ: всё, что в файле дальше этого объёма, Google не читает.

Ищем правило, которое блокирует страницу: пример разбора

Возьмём файл интернет-магазина, где после выкладки Google начал сканировать тысячи страниц с фильтрами, хотя их «закрыли»:

User-agent: *
Disallow: /catalog/
Allow: /catalog/*/
Disallow: /*?filter=
Disallow: /*/print$

User-agent: Googlebot
Disallow: /search/
Disallow: /cart/

Разработчик рассуждал так: Disallow: /*?filter= закрывает фильтры, Disallow: /*/print$ — версии для печати, а Allow: /catalog/*/ длиннее, чем Disallow: /catalog/, поэтому разделы каталога открыты, а корень закрыт. Логика длины правил верная, но к Googlebot она не применяется вовсе. Ошибка в группах: когда в файл добавили блок User-agent: Googlebot для поиска и корзины, Googlebot перестал читать общую группу. Он выполняет только свой блок, поэтому для него открыто всё, кроме /search/ и /cart/: и фильтры, и печать, и корень каталога. Но и общая группа написана с ошибкой. Внутри каталога Allow: /catalog/*/ (11 символов) длиннее, чем Disallow: /*?filter= (10 символов) и Disallow: /*/print$ (9 символов), поэтому адрес /catalog/shoes/?filter=red по правилам Google открыт и для тех роботов, которые читают общую группу. Порядок строк здесь ничего не меняет.

Исправление в два шага. Первое — сделать запреты не короче разрешения: Disallow: /catalog/*?filter= и Disallow: /catalog/*/print$. Второе — повторить эти правила в группе Googlebot или убрать отдельный блок и перенести /search/ и /cart/ в User-agent: *.

Этот пример показывает главное: «на глаз» robots.txt читать нельзя. Нужно для каждого важного адреса выписать три вещи — какая группа применяется к роботу, какие правила этой группы подошли и какое из них длиннее. Именно так работает проверка robots.txt онлайн в бесплатном инструменте IndexFix Tools: вставляете текст файла или черновик, указываете робота (Googlebot, Googlebot-Image или любой другой) и список адресов, а инструмент для каждого адреса показывает «разрешено» или «закрыто» и строку, которая это решила. Сопоставление идёт в браузере, черновик никуда не отправляется.

Проверка robots.txt перед каждой выкладкой: порядок действий

1. Соберите контрольный список адресов. 15–30 URL: главная, по одному адресу из каждого шаблона (категория, карточка, статья, тег), страница с параметром, страница пагинации и несколько адресов, которые должны быть закрыты (корзина, поиск, личный кабинет). Список хранится рядом с проектом и меняется вместе со структурой сайта.
2. Сравните новую версию файла со старой. Любая строка, которая появилась или исчезла, — повод проверить список. Особенно опасны изменения в начале групп: новая строка User-agent может отрезать правила от общей группы.
3. Прогоните список через тестер для Googlebot и для общей группы. Нужный результат: все рабочие адреса «разрешено», служебные — «закрыто». Если адрес открыт или закрыт неожиданно, смотрите, какая строка сработала, а не какую вы «имели в виду».
4. Проверьте, не уехал ли на продакшен файл тестового стенда. Самая дорогая ошибка — Disallow: / со стенда. Её ловит любой адрес из контрольного списка.
5. После выкладки откройте отчёт о файлах robots.txt. Новая версия должна получить статус «Получено» без ошибок. Если правка срочная, запросите повторное сканирование файла из меню отчёта. Google обычно кеширует robots.txt до 24 часов, и повторный запрос не гарантирует мгновенного обхода открытых адресов.
6. Через несколько дней проверьте отчёт «Индексирование страниц». Рост причины «Доступ к URL заблокирован в файле robots.txt» по адресам, которые должны индексироваться, — сигнал, что правило шире задуманного.

Ответ сервера тоже часть проверки

Даже правильный файл не сработает, если сервер отдаёт его с ошибкой. Google читает код ответа так:

• 2xx — файл обрабатывается как есть;
• 3xx — Google проходит до пяти переадресаций, дальше считает, что файла нет;
• 4xx, кроме 429 — файла нет, ограничений на сканирование нет вообще;
• 5xx — первые 12 часов Google не сканирует сайт и пытается получить файл снова, затем до 30 дней пользуется последней удачной копией. Ошибки сети и тайм-ауты приравниваются к 5xx.

Отсюда два практических вывода. Закрывать сайт от сканирования ответом 401 или 403 на robots.txt бессмысленно: для Google это «файла нет». А нестабильный сервер, который время от времени отдаёт 503 на robots.txt, может на полдня остановить обход всего сайта.

Чего robots.txt не делает

Disallow запрещает сканирование, а не индексирование. Закрытую страницу Google не загружает, поэтому не видит на ней noindex, а сам адрес может остаться в выдаче, если на него ссылаются. Чтобы убрать страницу из поиска, откройте её для сканирования и поставьте noindex в метатеге или заголовке X-Robots-Tag. После того как вы открыли раздел, убедитесь, что адреса действительно вернулись в поиск: удобнее всего проверить индексацию сайта в Google списком, а не открывать каждый адрес в Search Console по одному.

FAQ

Где в Search Console проверить, какое правило robots.txt закрывает страницу?

Отдельного инструмента для этого больше нет. Отчёт о файлах robots.txt показывает, получен ли файл и есть ли в нём ошибки, а инструмент проверки URL — разрешено ли сканирование конкретного опубликованного адреса. Строку, которая сработала, показывает внешний тестер.

Если Allow и Disallow подходят к адресу одновременно, что победит?

Правило с более длинным путём. Если длина одинаковая — Allow.

Учитывает ли Google Crawl-delay и Host?

Нет. Google поддерживает только user-agent, allow, disallow и sitemap, остальные поля пропускает.

Как быстро Google увидит исправленный robots.txt?

Обычно в течение 24 часов — столько Google кеширует файл. Ускорить можно запросом повторного сканирования в отчёте о файлах robots.txt.

Можно ли закрыть страницу из поиска через robots.txt?

Нет. Robots.txt управляет сканированием. Для исключения из индекса нужен noindex, и страница при этом должна быть открыта для сканирования.

ИСТОЧНИКИ

• Как Google интерпретирует спецификацию robots.txt — Google Search Central: https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt?hl=ru
• Отчёт о файлах robots.txt — Справка Search Console: https://support.google.com/webmasters/answer/6062598?hl=ru

Сообщение Проверка robots.txt перед публикацией: как найти правило, которое блокирует страницу появились сначала на SPEEDYINDEX.

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

Как устроен ответ инструмента проверки URL

Инструмент проверки URL (URL Inspection tool) в Search Console работает в двух режимах, и путать их — главный источник ошибок при диагностике.

Первый режим — данные из индекса. Это ответ на вопрос «что Google знает об этом адресе прямо сейчас»: когда страницу сканировали в последний раз, каким роботом, разрешено ли сканирование и индексирование, какой URL Google считает каноническим. Все эти сведения относятся к последней просканированной версии, а не к тому, что лежит на сервере сегодня.

Второй режим — проверка опубликованной страницы, кнопка «Проверить страницу на сайте» (Test live URL). Здесь Google запрашивает страницу в реальном времени и отвечает, может ли он до неё добраться. Этот режим ничего не говорит о том, есть ли страница в индексе.

Ещё одно ограничение, которое стоит держать в голове: проверить можно только URL из открытого ресурса. Чужие страницы — например, сайты, где стоят ссылки на ваш проект, — инструмент не примет.

Четыре вердикта версии в индексе

Верхняя строка результата принимает одно из четырёх значений. Формулировки ниже — из русского интерфейса Search Console, в скобках оригинал.

«URL есть в индексе Google» (URL is on Google)

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

«URL есть в индексе Google, но есть проблемы» (URL is on Google, but has issues)

Страница в индексе, однако с ней связаны проблемы — чаще всего это ошибки структурированных данных или связанной AMP-версии. Из-за них страница может показываться без расширенных элементов, на которые рассчитывал владелец. Индексации это не мешает; что именно сломано, видно в разделе «Улучшения» под основным результатом.

«URL нет в индексе Google» (URL is not on Google)

Главный для этой статьи вердикт. Страница не показывается в поиске. Причина указана в разделе «Индексирование страниц» — ей посвящён следующий блок.

«URL содержит альтернативную версию страницы» (URL is an alternate version)

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

«URL нет в индексе Google»: читаем причину

После верхней строки раскройте раздел «Индексирование страниц». Там будет формулировка, совпадающая с причинами из отчёта об индексировании страниц. Сгруппировать их удобно по тому, где искать поломку.

URL неизвестен Google

Формулировка «Страница не проиндексирована: URL неизвестен Google» означает, что робот никогда не заходил по этому адресу. Google не нашёл на него ни одной ссылки и не видел его в sitemap. Проверьте, что адрес указан в sitemap без опечаток, что на него ведёт хотя бы одна внутренняя ссылка с проиндексированной страницы, и только после этого нажимайте «Запросить индексирование».

Ошибки доступа: 5xx, 404, ложная 404, 401 и 403

Причины вроде «Ошибка сервера (5xx)», «Не найдено (404)», «Ложная ошибка 404» и блокировок из-за 401/403 означают, что робот дошёл до адреса, но получил ответ, который нельзя индексировать. Поле «Получение страницы» в этом случае показывает «Ошибка». Здесь бесполезно запрашивать индексирование повторно: сначала нужно добиться стабильного ответа 200 для робота, причём именно для робота, а не для браузера под вашим логином.

Запреты: robots.txt и noindex

«Доступ к URL заблокирован в файле robots.txt» и «Страница содержит директиву noindex» — два разных механизма с разными последствиями. Если сканирование закрыто в robots.txt, поле «Индексирование разрешено?» всегда покажет «Да»: Google просто не может увидеть директиву noindex на странице, которую ему нельзя загрузить. Отсюда частая путаница — robots.txt не удаляет страницу из индекса; заблокированный адрес может остаться в выдаче без описания. Чтобы исключить страницу, нужен noindex или доступ по паролю, а для noindex сканирование должно быть открыто.

Переадресация и копии

«Страница с переадресацией» для неканонического URL — норма, а не ошибка: индексироваться будет конечный адрес. Важный нюанс инструмента: для версии в индексе он показывает данные по тому URL, который вы ввели, а не по цели редиректа. Поэтому проверять нужно финальный адрес цепочки. Причины «Страница является копией…» в двух вариантах говорят, что Google выбрал канонической другую страницу — сравните поля «Каноническая страница, выбранная пользователем» и «Каноническая страница, выбранная Google». Если они расходятся, ваш rel=canonical Google не убедил.

Просканирована или обнаружена, но пока не проиндексирована

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

Проверка опубликованной страницы: три вердикта и чего она не видит

Кнопка «Проверить страницу на сайте» запускает запрос к странице в реальном времени и возвращает один из трёх результатов:

• «URL доступен Google» (URL is available to Google) — страница не заблокирована, ошибок, препятствующих индексированию, нет;
• «URL доступен Google, но есть проблемы» (URL is available to Google, but has issues) — страница может быть проиндексирована, но есть проблемы, например, в структурированных данных;
• «URL недоступен Google» (URL is not available to Google) — серьёзная проблема, страница не сможет показываться в поиске.

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

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

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

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

1. Прочитайте причину в разделе «Индексирование страниц», а не верхнюю строку.
2. Разделите причины на технические (5xx, 404, robots.txt, noindex, редирект, копия) и «отложенные» (просканирована или обнаружена, но пока не проиндексирована).
3. Для технических причин исправьте ответ сервера, директивы или canonical и запустите «Проверить страницу на сайте». Добейтесь «URL доступен Google» и поля «Получение страницы: Успешно».
4. Только после этого нажимайте «Запросить индексирование». Число запросов за день ограничено, а отправка не гарантирует попадания в индекс; если нужно проиндексировать несколько страниц, Google рекомендует отправить sitemap.
5. Через некоторое время проверьте URL снова, переключившись на «Использовать данные из индекса Google»: поле «Последнее сканирование» покажет, заходил ли робот после правок.

Отдельно о Google Indexing API: он предназначен для страниц с вакансиями и трансляциями и для обычных страниц не подходит.

Когда одного инструмента Search Console мало

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

Для автоматизации внутри своего ресурса у Search Console есть URL Inspection API: метод urlInspection.index.inspect возвращает тот же вердикт и состояние покрытия, что и интерфейс, с лимитом 2000 запросов в день и 600 в минуту на ресурс. Чужие URL через него тоже проверить нельзя — адрес должен принадлежать ресурсу.

FAQ

Что значит «URL нет в индексе Google», если страница открывается в браузере?

Доступность в браузере и индексация — разные вещи. Робот мог получить другой ответ (например, 5xx под нагрузкой или 403 для его user-agent), наткнуться на noindex, быть заблокированным в robots.txt или просто ещё не принять решение. Ответ всегда в разделе «Индексирование страниц», а не в том, что видите вы.

Почему проверка опубликованной страницы зелёная, а в индексе страницы нет?

Проверка опубликованной страницы отвечает только на вопрос «может ли Google загрузить страницу сейчас». Она не проверяет ссылки, sitemap, качество, ручные меры и канонический выбор. Зелёный результат — необходимое условие, но не достаточное.

Сколько раз можно нажимать «Запросить индексирование»?

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

Как проверить страницу на чужом сайте?

В Search Console — никак: URL должен относиться к вашему ресурсу. Для чужих страниц используется внешняя проверка индексации по списку адресов.

Почему в результатах показан не тот URL, который был введён?

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

ИСТОЧНИКИ

• Инструмент проверки URL — Справка Search Console: https://support.google.com/webmasters/answer/9012289?hl=ru
• Отчёт об индексировании страниц — Справка Search Console: https://support.google.com/webmasters/answer/7440203?hl=ru
• URL Inspection API, метод inspect: https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect
• Лимиты API Search Console: https://developers.google.com/webmaster-tools/limits
• Редиректы и Google Поиск: https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Введение в robots.txt: https://developers.google.com/search/docs/crawling-indexing/robots/intro

Сообщение URL нет в Google — что значит в Search Console и что делать дальше появились сначала на SPEEDYINDEX.

Шаг 1. Зафиксируйте URL страницы-донора

Объект проверки — страница, на которой размещена ссылка (referring page), а не ваш сайт. Откройте страницу донора, дождитесь завершения всех редиректов и сохраните итоговый URL. Если браузер перешёл на другой адрес — запишите оба: исходный и финальный.

Шаг 2. Публичная проверка через оператор site:

Введите в поиске Google запрос вида site:полный-URL-страницы-донора. Результат интерпретируйте осторожно:

• Страница появилась — фиксируем «Наблюдается в публичном поиске» с датой проверки.
• Страница не появилась — фиксируем «Не наблюдается в публичном поиске». Это не равнозначно «не проиндексирована»: Google прямо указывает, что результаты site: могут быть неполными.

Шаг 3. URL Inspection и граница доступа

URL Inspection в Search Console даёт данные об индексированной версии страницы, но проверяемый URL должен находиться в том свойстве Search Console, которое у вас открыто. Без доступа к домену-донору вы не можете получить эти данные — и не должны указывать в отчёте, что проводили «проверку через Search Console».

Пакетная проверка бэклинков

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

Итог

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

Сообщение Как проверить, проиндексирован ли бэклинк в Google появились сначала на SPEEDYINDEX.

Когда ссылка размещена на стороннем ресурсе, главный вопрос — видит ли её Google. Неиндексированный бэклинк не передаёт вес и не влияет на ранжирование. В этом руководстве разбираем шесть методов проверки и объясняем, когда применять каждый из них.

Почему индексация бэклинка важна

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

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

Шесть методов проверки

1. Оператор site: в Google

Простейший ручной метод. Введите в поисковую строку site:example.com/путь-к-странице. Если страница появляется в выдаче — она проиндексирована. Подходит для единичных проверок; для списков свыше 10–15 URL слишком медленный.

Ограничение: Google не всегда показывает страницу, даже если она в индексе. Оператор site: даёт ответ на вопрос «показывает ли Google эту страницу», а не строго «есть ли она в индексе».

2. Google Search Console → Проверка URL

Инструмент «Проверка URL» в Search Console показывает точный статус страницы в индексе Google. Работает только для страниц, к которым у вас есть доступ в GSC — то есть ваши собственные домены. Для чужих ссылочных страниц не подходит.

3. Кэш Google

Введите cache:example.com/страница или нажмите на три точки у результата поиска и выберите «Кэшированная версия». Наличие кэша подтверждает недавний обход страницы. Метод может ошибаться для страниц, кэш которых давно не обновлялся.

4. API Google Indexing

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

5. Сторонние SEO-инструменты

Ahrefs, Semrush и Majestic хранят собственные краулерные данные. Они показывают, нашёл ли их бот ссылку, но это не то же самое, что индексация в Google. Расхождение данных — норма.

6. Пакетная проверка через SpeedyIndex

Для аутрич-кампаний, когда нужно проверить сотни или тысячи URL, ручные методы нереалистичны. SpeedyIndex позволяет загрузить список URL и получить отчёт о статусе индексации каждого из них — без ограничений по числу доменов и без необходимости доступа к GSC донора.

Сравнительная таблица методов

Пошаговый процесс проверки для линкбилдеров

1. Соберите список URL. Экспортируйте из Ahrefs, Semrush или таблицы кампании все страницы-доноры.
2. Разделите по типу владения. Ваши страницы — проверяйте через GSC. Чужие — через site:, кэш или SpeedyIndex.
3. Для массовых проверок используйте SpeedyIndex. Загрузите CSV, получите отчёт с колонками: URL, статус, дата последнего обхода.
4. Отфильтруйте неиндексированные URL. Это приоритет для повторного контакта с донором или замены ссылки.
5. Проверьте причину. Noindex-тег, блокировка в robots.txt, тонкий контент или пенальти — у каждого случая разное решение.
6. Зафиксируйте результат. Обновите статус в CRM или таблице кампании с датой проверки.
7. Повторяйте проверку регулярно. Страницы могут выпасть из индекса спустя месяцы — плановая проверка раз в квартал сохраняет ценность портфеля.

Частые ошибки при проверке

Путать данные краулера с данными Google. Ahrefs и Semrush видят страницу своим ботом — это не означает, что Google тоже её видит и учитывает.

Проверять сразу после публикации. Дайте Google от 24 часов до 2 недель на обход новой страницы перед первой проверкой.

Считать отсутствие в site: подтверждением деиндексации. Оператор site: не отображает все страницы из индекса. Используйте несколько методов для подтверждения.

Что делать с неиндексированными бэклинками

Если страница не проиндексирована более 4–6 недель, стоит предпринять действия. Свяжитесь с владельцем ресурса и уточните, нет ли технических ограничений на странице. Проверьте robots.txt и мета-теги через view-source. Если проблема на стороне донора — запросите замену страницы или вернитесь к переговорам.

Для собственных страниц убедитесь, что URL добавлен в sitemap и sitemap отправлен в Google Search Console.

Итог

Проверка индексации бэклинков — обязательная часть поддержки ссылочного профиля. Для единичных URL достаточно оператора site:. Для больших кампаний пакетная проверка через SpeedyIndex экономит время и даёт структурированный отчёт по всему портфелю.

]]>

Сообщение Как проверить, проиндексирована ли ссылка в Google: полное руководство появились сначала на SPEEDYINDEX.

Слой текста: основа индексации PDF

Поисковый робот читает текст, а не картинку. PDF, созданный из сканов без распознавания, содержит только изображения страниц — слов в нём нет. Google умеет запускать OCR на таких файлах, но это ненадёжный резерв, а не основной путь. Яндекс в справке прямо указывает: у документа только из изображений обрабатываются первые три страницы, остальные остаются непрочитанными.

Проверить текстовый слой просто: откройте PDF, выделите мышью абзац и вставьте его в текстовый редактор. Если вместо связного текста — набор символов или пустая строка, документ нужно пересоздать с распознаванием. После OCR обязательно проверяйте результат вручную: таблицы, колонки, перевёрнутые страницы и сноски часто требуют отдельной правки порядка чтения.

Ограничения формата

Оба поисковика документируют ограничение по размеру: Яндекс индексирует PDF до 10 МБ, файл больше лимита не попадёт в поиск. Google читает первые 64 МБ PDF и отбрасывает всё, что дальше. Для обоих поисковиков безопаснее держаться в пределах 10 МБ. Файл, который превышает лимит, будет проигнорирован целиком или обрезан. Проверьте размер перед публикацией — сжать PDF без потери качества текста позволяет большинство инструментов экспорта.

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

Доступ робота к файлу

Правильный текст внутри файла бесполезен, если URL закрыт от скачивания. Проверьте три точки:

robots.txt. Если путь к PDF накрыт директивой Disallow, краулер не получит файл. Заодно это означает, что он не сможет прочитать HTTP-заголовок ответа — в том числе директиву noindex в X-Robots-Tag. Сначала убедитесь, что robots.txt разрешает путь.

Код ответа. Сервер должен отдавать HTTP 200 с типом содержимого application/pdf. Редирект 301/302 — не проблема, если конечный адрес тоже доступен и содержит правильный файл. Ответ 403 или 503 под ботом при 200 в браузере — антибот-защита: краулер до файла не добирается.

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

X-Robots-Tag: директива в HTTP-ответе

Внутри PDF-файла нет места для мета-тега robots. Вместо него поисковики читают HTTP-заголовок X-Robots-Tag, который сервер или CDN добавляет к ответу на запрос файла. Директива noindex в этом заголовке полностью запрещает файлу участвовать в выдаче:

X-Robots-Tag: noindex

Такой заголовок легко появляется после миграции или смены CDN-конфигурации и остаётся незамеченным, пока страница не пропадёт из индекса. Проверяйте заголовки ответа для URL файла отдельно — браузер их обычно не показывает.

Важный порядок: если robots.txt запрещает путь, краулер не загружает файл и не читает X-Robots-Tag. Сначала исправьте robots.txt, потом проверяйте заголовки.

Дубли URL и canonical

Один PDF, доступный по нескольким адресам — http и https, с www и без, с параметрами и без — создаёт проблему выбора канонического URL. Поисковик может выбрать не тот адрес, и тогда ваш вариант не попадёт в выдачу.

Для PDF предпочтительный адрес задаётся HTTP-заголовком в ответе дублирующей версии:

Link: <https://example.com/files/guide.pdf>; rel="canonical"

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

Статус «Обнаружена, не проиндексирована»

Это отдельный статус в Google Search Console, который означает: Google знает о URL, но ещё не скачивал страницу. Отличие от «просканирована, не проиндексирована» принципиальное: во втором случае краулер уже посещал адрес и отложил решение, в первом — ждёт своей очереди или не считает URL приоритетным.

Для PDF в статусе «Обнаружена» стандартная рекомендация — убедиться в наличии качественных входящих ссылок на файл и чёткого упоминания в карте сайта. Повторные отправки через Search Console ускоряют решение, но не меняют решение алгоритма о ценности страницы.

Ссылочный контекст вокруг PDF

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

Если PDF дублирует HTML-страницу, определитесь, какую версию хотите видеть в выдаче. Для PDF можно установить canonical на HTML-страницу через HTTP-заголовок — тогда в индекс попадёт HTML, а не файл. Убедитесь, что карта сайта и внутренние ссылки не противоречат этому выбору.

Как проверить индексацию списка PDF

Точечная проверка через инструмент проверки URL в Search Console показывает статус одного адреса и позволяет запросить повторное сканирование. Для списка документов ручная проверка неудобна: оператор site: в Google неполный, а оператор url: в Яндексе может не показывать все проиндексированные адреса.

Для массовой сверки пригодится проверка индексации в Google — загружаете список URL и получаете статус по каждому адресу с тайтлом, под которым страница находится в выдаче. Несовпадение тайтла с текущим заголовком документа означает, что в индексе лежит старая версия файла.

Чек-лист: порядок проверки

1. Текстовый слой — выделение абзаца должно давать читаемый текст.
2. Размер файла — не превышает 10 МБ.
3. robots.txt — путь к файлу не закрыт директивой Disallow.
4. HTTP-ответ — код 200, тип application/pdf, нет X-Robots-Tag: noindex.
5. Canonical — один предпочтительный URL, карта сайта и ссылки согласованы.
6. Ссылочный контекст — HTML-страница с описанием и ссылкой на файл.
7. Проверка статуса — Search Console или массовая сверка списка.

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

Нужно ли добавлять PDF в sitemap? Желательно — это сигнал поисковику, что файл важен. Тип содержимого для PDF в sitemap не требует специальных атрибутов, достаточно стандартного тега <loc>.

Влияет ли атрибут download у ссылки на индексацию? Нет. Атрибут download меняет поведение браузера, но не влияет на краулер — он скачивает URL напрямую.

Почему PDF пропал из выдачи после обновления? Проверьте, не появился ли X-Robots-Tag: noindex после деплоя. Также убедитесь, что URL не изменился и старая версия не осталась доступной — иначе поисковик мог переключиться на другой адрес.

Помогает ли ускоренная индексация? Для документов, которые технически доступны, но зависли в очереди, ускоренная отправка сокращает время ожидания. SpeedyIndex работает со страницами и документами — загрузите список URL и проверьте, изменился ли статус на следующей сверке.

Сообщение Почему PDF не индексируется в Google и Яндексе: полный разбор причин появились сначала на SPEEDYINDEX.

Как работали такие чекеры

Схема одна и та же: скрипт отправляет запрос site:domain.com/page в Custom Search JSON API и, если результат непустой, считает страницу проиндексированной. Бесплатно — 100 запросов в день, дальше 5 долларов за 1 000 запросов и потолок 10 000 запросов в сутки. Список из 50 000 ссылок такой чекер перебирал рабочую неделю, а точность оставалась спорной: выдача CSE никогда не совпадала с обычным поиском один в один.

Что нужно от замены

• Пакетный вход: тысячи URL одним запросом, а не один запрос на ссылку.
• Готовый вердикт по каждому URL — в индексе или нет, — без разбора списка результатов.
• Понятная цена за URL без суточного лимита, растягивающего задачу на дни.
• Статический ключ в заголовке, чтобы проверка жила в cron или CI.

Перевод на SpeedyIndex API

У проверки индексации в Google от SpeedyIndex есть REST-интерфейс. Основные вызовы по официальной документации (en.speedyindex.com/api.php):

Авторизация — один заголовок Authorization: <API-ключ>; ключ выдаётся в личном кабинете или Telegram-боте. Баланс чекера отдельный от токенов индексации; актуальная стоимость проверки — на странице инструмента.

Практически миграция сводится к замене одной функции: вместо цикла из site:-запросов — один вызов create на пакет ссылок, ожидание и один fullreport. Рабочий скрипт на Python с обработкой ошибок и записью результатов в два файла опубликован в разборе миграции с Custom Search API на английском.

Что учесть

• API отдаёт факт наличия URL в индексе на момент проверки; причины выпадения из индекса он не объясняет — для этого нужны Search Console и аудит донора.
• Задача обрабатывается асинхронно: опрашивайте статус, а не ждите мгновенного ответа.
• Не откладывайте на декабрь: после 1 января 2027 старые скрипты начнут возвращать ошибки, а не пустые результаты, и мониторинг индексации ссылок остановится молча.

Если ссылки после проверки оказались вне индекса, их можно сразу отправить на ускоренную индексацию в SpeedyIndex тем же API — задачи чекера и индексатора живут в одном кабинете.

Сообщение Google Custom Search JSON API закрывается 1 января 2027: чем заменить проверку индексации по API появились сначала на SPEEDYINDEX.

Кратко о том «как проверить индексацию обратных ссылок»: соберите список URL доноров, снимите с каждого HTTP-статус и директивы, прогоните список через массовый чекер индексации, сверьте результат с отчётом «Ссылки» в Search Console, а тех доноров, которых в индексе нет, отправьте на индексацию и дождитесь отчёта на 7-й день. По отдельности ни одна из этих проверок ничего не доказывает — ответ даёт только вся последовательность целиком.

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

Почему «ссылка стоит» и «ссылка работает» — разные события

Миф: разместили, увидели в браузере, оплатили — значит, ссылка передаёт вес. В 2010-х это почти работало: Google индексировал агрессивно, форумные и профильные страницы залетали в индекс за пару дней, а проверка сводилась к оператору site:. Публикация 2011 года на alaev.info с проверкой 340 постовых ссылок показательна тем, что автор уже тогда проверял не ссылки, а страницы-доноры на индексацию — и делал это вручную.

Переосмысление пришло вместе с выборочной индексацией. Статус «Страница просканирована, но пока не проиндексирована» в Search Console стал обычным делом для страниц с минимумом контента, а форумные ветки, каталоги и профили — первыми кандидатами на вылет. Ссылка на такой странице формально есть, а для алгоритма её нет.

Доказательство лежит в официальной документации. Справка Google по отчёту «Ссылки» в Search Console прямо говорит: отчёт включает ссылки, которые Google нашёл когда-либо, и часть из них уже могла исчезнуть вместе со страницей; итоговые цифры над таблицами могут не учитывать непроиндексированные страницы; пометку nofollow отчёт не показывает (Справка Search Console, статья «Отчёт о ссылках»). То есть даже единственный официальный источник данных о беклинках не отвечает на вопрос «донор в индексе?».

Документация Google по оператору site: предупреждает: оператор не обязан возвращать все URL, проиндексированные под указанным префиксом, и без дополнительного запроса не ранжирует результаты (developers.google.com, раздел Search operators, страница про site:).

Джон Мюллер, Google, в выпуске Ask Googlebot (2021, цитируется по Search Engine Journal : запрос site: «не предназначен быть полным и не годится для диагностики».

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

Что теряет бизнес, когда доноры висят вне индекса

Тезис: непроиндексированный донор — это оплаченная ссылка с нулевым эффектом. Бюджет на гостевой пост, крауд или аутрич списан, а ссылочный профиль в глазах алгоритма не изменился. По отраслевым оценкам линкбилдеров, доля доноров, которые не попадают в индекс без дополнительных действий, обычно лежит в диапазоне 20–40 % для крауд-ссылок и профилей и заметно ниже для гостевых постов на живых медиа (оценка, не измерение).

Антитезис: часть доноров индексируется сама через 2–6 недель. Это верно для сайтов с регулярным обходом; для «тонких» форумных страниц третьего уровня вложенности ожидание чаще заканчивается ничем.

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

Команда SpeedyIndex: «Клиенты часто присылают нам список ссылок с вопросом „почему не выросли позиции». Мы просим прогнать те же URL через чекер индексации — и в типичной выгрузке треть доноров ни разу не была в индексе Google. Не потому, что ссылки плохие. Потому, что их никто не проверял после размещения».

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

Десять шагов: от списка доноров до отчёта на 7 день

Шаг 1. Нормализуйте список доноров. Выгрузите URL страниц-доноров из отчёта биржи, таблицы аутрича или экспорта Ahrefs в одну колонку таблицы. Приведите каждый адрес к абсолютному виду с протоколом, без #якорей и без UTM-параметров, которые добавил трекер биржи.

Смотрите результат сразу: одна строка — один URL, дубли http/https и www/без www схлопнуты. Если в списке остались адреса вида site.ru/thread?page=3#post-1234, чекер проверит страницу целиком, а якорь только запутает сверку — режьте до ?page=3.

Шаг 2. Снимите код ответа под мобильным Googlebot. В терминале выполните запрос с заголовком User-Agent мобильного краулера:

curl -sI -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://donor.example/thread/123

В норме — HTTP/2 200 без заголовка X-Robots-Tag: noindex.

Проблема: бывает трёх видов.

301 или 302 с полем Location означает, что в индекс пойдёт конечный URL, а не тот, который вы оплатили, — берите адрес из Location и начинайте шаг заново с него.

403 или 503 только под ботом при 200 в браузере — антибот-защита хостинга: донор недоступен для краулера, и ссылка не будет прочитана.

404 или 410 — страница удалена; в кампанию по индексации такой URL не кладут, а идут к владельцу площадки.

Шаг 3. Проверьте директивы индексации донора. Скачайте HTML и отфильтруйте мета-роботс, затем откройте robots.txt площадки:

curl -sL https://donor.example/thread/123 | grep -io '<meta[^>]*name="robots"[^>]*>'
curl -s https://donor.example/robots.txt | grep -i -B1 -A5 "Googlebot\|User-agent: \*"

В норме — grep вернул пустоту или content="index, follow", а в robots.txt нет Disallow, накрывающего путь донора.

Проблема: возможны два тревожных сценария

content="noindex" в мета-теге или в заголовке X-Robots-Tag — страница не будет проиндексирована ни при каких условиях, пока владелец не снимет директиву; Disallow: /thread/ в robots.txt — краулер не скачает HTML и не увидит вашу ссылку, даже если сам URL мелькнёт в выдаче без описания.

Оба случая — не «попробуем отправить», а «пишем вебмастеру или меняем донора». Для списка из сотен URL те же проверки делает бесплатный noindex-чекер.

Шаг 4. Найдите канонический адрес. В том же скачанном HTML найдите тег <link rel="canonical">.

В норме — href совпадает с URL донора с точностью до слеша.

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

Шаг 5. Убедитесь, что тег ссылки есть в сыром HTML. Отфильтруйте скачанную страницу по вашему домену:

curl -sL https://donor.example/thread/123 | grep -io '<a [^>]*href="[^"]*vash-sait\.ru[^"]*"[^>]*>'

В норме — строка с тегом <a href="https://vash-sait.ru/..."> и её атрибутами. Обратите внимание на rel: nofollow, ugc или sponsored не мешают индексации донора, но меняют то, как Google трактует ссылку.

Проблема — пустой вывод при том, что в браузере ссылка видна: её дорисовывает JavaScript, и без рендеринга краулер её не найдёт.

Или — ссылку удалили или заменили модераторы. Массово это проверяет инструмент «Проверка наличия ссылок» на blog.speedyindex.com.

Шаг 6. Сделайте точечную проверку операторами. Для Google введите site: с полным URL донора и одним словом из его заголовка — документация Google описывает именно такую форму как способ узнать, проиндексирован ли конкретный URL по термину.

Для Яндекса используйте url:donor.example/thread/123.

В норме — сниппет донора в выдаче.

Проблема — пустая выдача. И здесь главная ловушка: пустой site: — сигнал, а не приговор. Тот же документ Google оговаривает, что оператор возвращает не все проиндексированные URL. Поэтому одиночный минус переносим в шаг 7, а не в таблицу «не в индексе».

Шаг 7. Прогоните список через массовый чекер индексации. Загрузите нормализованный список в проверку индексации страниц в Google — тот же инструмент есть для Bing и Яндекса.

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

В норме — статус «проиндексирован» и тайтл, совпадающий с заголовком донора.

Проблема — «не проиндексирован» у URL, которые прошли шаги 2–5. С этим списком переходите к шагу 9.

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

Шаг 8. Сверьтесь с отчётом «Ссылки» в Search Console. В своём ресурсе откройте «Ссылки» → «Внешние ссылки» → «Экспорт» → срез «Последние ссылки». Смотрите через 1–3 дня после размещения, потом на 14-й день.

В норме — URL донора в выгрузке с датой обнаружения: Google видел страницу и нашёл на ней ссылку.

Проблема — донора нет. Но читайте этот отчёт с двумя поправками из документации: в нём остаются ссылки со страниц, которые уже могли выпасть из индекса, и он не показывает nofollow. Значит, присутствие в отчёте подтверждает обнаружение, а не текущий индекс. Отсутствие не означает, что донора нет в индексе — отчёт отстаёт на дни, а 21 мая 2026 года, по данным Search Engine Roundtable, он и вовсе показывал нули или резкое падение у массы сайтов, пока Google не подставил цифры недельной давности. Проверку URL для донора применить нельзя: инструмент проверки URL работает только для страниц вашего подтверждённого ресурса.

Шаг 9. Отправьте непроиндексированных доноров на индексацию. Список из шага 7 загрузите задачей в кабинет SpeedyIndex: режим Standard для пакета до 100 000 URL списком или файлом, Drip-Feed — если хотите растянуть отправку по дням для молодой сетки.

Включите предварительную проверку: она отсечёт 404/410/451, страницы под robots.txt и noindex, медиафайлы и уже проиндексированные URL, чтобы токены не сгорели на мусоре. Перед запуском вы увидите диалог подтверждения с итоговым списанием.

Смотрите отчёт на 7 день для Google и на 15 день для Яндекса.

В норме— URL в разделе проиндексированных с тайтлом страницы.

Проблема — URL в разделе непроиндексированных или с ошибкой «Страница просканирована, но пока не проиндексирована»; токены за него вернулись на баланс по модели Pay-per-Result. Такой донор после чистого прохода шагов 2–5 и отправки — кандидат на замену: вопрос уже не в доставке краулера, а в том, что алгоритм не считает страницу достойной индекса.

Шаг 10. Поставьте повторную сверку на 30-й день. Доноры выпадают из индекса: модераторы чистят ветки, площадки меняют структуру, малосодержательные страницы не переживают повторную оценку и выпадают из индекса.

Прогоните тот же список через массовую проверку беклинков — она покажет DA, Spam Score, анкор и атрибут dofollow/nofollow/sponsored/ugc по каждому донору — и повторите шаг 7. Смотрите на 30-й день и далее ежемесячно.

В норме — две выгрузки совпадают или расходятся на пару процентов.

Проблема — донор, который был в индексе, из него ушёл; возвращайтесь к шагу 2 именно для него, потому что чаще всего причина — новый редирект или noindex, а не решение алгоритма.

Способ проверки для какой задачи

Четыре ловушки, которые портят сверку

Ловушка 1: строка в Ahrefs или Semrush равна индексу Google.

Факт: сторонние краулеры строят собственный индекс ссылок.

Связь: они видят страницу, когда обходят её сами, независимо от Google.

Утверждение линкбилдера: «ссылка появилась в Ahrefs, значит, всё работает».

Опровержение: наличие в базе стороннего сервиса говорит о том, что его бот нашёл тег <a>, и ничего не говорит о решении Google. Статус индекса Google снимают только у Google — оператором или чекером, который парсит выдачу.

Ловушка 2: пустой site: — донор не в индексе.

Факт: документация Google называет оператор неполным.

Связь: пустая выдача по одному URL может быть свойством оператора, а не индекса.

Утверждение: «проверил site: — ноль, донор мёртв».

Опровержение: одиночный минус подтверждают вторым методом; расхождения между site: и реальным индексом — норма, о которой Google говорит открыто.

Ловушка 3: донор есть в отчёте «Ссылки» GSC — значит, ссылка учтена.

Факт: справка отчёта прямо пишет, что в нём остаются ссылки со страниц, которые могли исчезнуть.

Связь: отчёт накапливает историю, а не отражает текущее состояние индекса.

Утверждение: «Google видит ссылку, дальше можно не проверять».

Опровержение: отчёт подтверждает, что ссылка была обнаружена. Что с донором сегодня — покажет только свежая проверка индекса.

Ловушка 4: nofollow — причина неиндексации донора.

Факт: атрибут rel="nofollow" относится к ссылке, а не к странице.

Связь: страница с nofollow-ссылками индексируется так же, как любая другая.

Утверждение: «донор не в индексе, потому что ссылка nofollow».

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

Три ситуации из практики

1 сценарий — не реальный клиент.

Линкбилдер агентства закупает 120 крауд-ссылок на форумах и в комментариях. Через две недели site: показывает пустоту по половине URL. Массовая проверка возвращает 71 проиндексированный из 120. Разница между ручной и массовой проверкой — 11 URL, которые оператор просто не показал.

Вывод: одиночный site: завышает потери.

2 сценарий — не реальный клиент.

Владелец интернет-магазина получил 15 гостевых постов. Все 200, все без noindex. Пять не в индексе через месяц. Проверка canonical показала: на трёх площадках канонический адрес ведёт на первую страницу категории, где ссылки нет.

Вывод: 200 и noindex — не полный чеклист; canonical проверяют отдельно.

3 сценарий — не реальный клиент.

Арбитражник ведёт сетку сателлитов и отправляет 400 URL Tier-2 на индексацию без предварительной проверки. Отчёт дня 7: 190 проиндексированных, 150 непроиндексированных, 60 с ошибками, среди них — редиректы на удалённые страницы. Токены за 210 URL вернулись, но неделя потеряна.

Вывод: предварительная проверка стоит меньше недели ожидания.

Условный пример: как B2B-сервис проверяет 300 доноров в месяц

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

Ниша и контекст. Команда из двух человек ведёт аутрич и крауд для англоязычного SaaS. Ежемесячно появляется около 300 новых доноров: 60–80 гостевых постов, остальное — профили, каталоги, комментарии и Tier-2 на собственных сателлитах.

До. Проверка индексации — выборочная, site: по 20–30 адресам раз в месяц. Оценка доли доноров вне индекса — «где-то треть», без списка. Бюджет на замену неработающих ссылок не заложен, потому что неработающие не выявлены.

Действия. Список из 300 URL нормализован по шагу 1.

Скрипт на curl снял коды и директивы по шагам 2–5: примерно 8–12 % URL отсеяны как редиректы на другой адрес, noindex или страницы под Disallow. Оставшиеся прошли массовую проверку индекса. Не проиндексированные отправлены на индексацию с предварительной проверкой в режиме Drip-Feed на 5 дней. Отчёт на 7 день разобран, повторная сверка поставлена на 30-й день.

После. До отправки в индексе находилось 55–65 % доноров, после отчёта дня 7 — 80–90 %. Доля, за которую токены вернулись, — 10–20 %; эти доноры помечены на замену. Что пошло не так: 14 URL на одной форумной площадке проиндексировались, а через три недели выпали — площадка включила noindex для веток без ответов.

Таким образом: шаг 10 обязателен, а не опционален.

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

«Обнаружена, не проиндексирована» у донора: что этот статус значит на самом деле

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

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

Если донор после отправки перешёл из «обнаружена» в «просканирована, но пока не проиндексирована» — это движение вперёд, а не отказ: страница скачана и ждёт решения алгоритма. Если же и через 30 дней статус не меняется, донор уходит в список на замену по шагу 10.

Ответы на частые вопросы

В: Как проверить, проиндексирована ли обратная ссылка, если у меня нет доступа к сайту донора?
О: Доступ не нужен. Проверяют публичный URL донора: код ответа, директивы, canonical, тег ссылки в HTML и статус в индексе через оператор или массовый чекер.

В: Проверка индексации ссылок в Яндексе отличается от Google?
О: Оператор другой — url: вместо site:, сроки другие — отчёт по отправке приходит на 15-й день вместо 7-го. Логика технических проверок одинаковая. Обход по счётчикам Метрики донору не поможет: он работает только для сайта с вашим счётчиком.

В: Индексация беклинков в Google — сколько ждать после размещения, прежде чем считать донора проблемным?
О: Для живых медиа обычно 1–3 недели, для тонких форумных страниц срок может уходить в бесконечность (отраслевая оценка). Практичная граница — 14 дней, после которых донор идёт в отправку.

В: Почему ссылка не индексируется, хотя страница отдаёт 200?
О: 200 — только первое условие. Дальше проверяют noindex в мета-теге и заголовке X-Robots-Tag, Disallow в robots.txt, canonical на другой адрес и то, что ссылка есть в сыром HTML, а не только после JavaScript.

В: Оператор site: для проверки индексации — можно ли ему доверять?
О: Положительному результату — да. Отрицательному — только после подтверждения вторым методом: сама документация Google называет выдачу оператора неполной.

В: Массовая проверка индексации ссылок — чем она отличается от отчёта «Ссылки» в Search Console?
О: Чекер снимает текущий статус донора в индексе и тайтл. Отчёт GSC показывает, что Google когда-либо обнаружил ссылку, и оставляет в списке даже страницы, которые могли исчезнуть.

В: Можно ли проверить индексацию донора через инструмент проверки URL в Search Console?
О: Нет. Инструмент принимает только адреса вашего подтверждённого ресурса; чужой URL он не проверит.

В: Что делать, если донор отправлен на индексацию, а на день 7 его всё равно нет в индексе?
О: Токены за него возвращаются, а сам донор после чистого прохода технических проверок — кандидат на замену. Решение о включении страницы в индекс принимает алгоритм, и повторные отправки редко его меняют.

Что изменится к 2028-му и что сделать сейчас

Факт: Google индексирует выборочно и открыто называет свои диагностические инструменты неполными; отчёт «Ссылки» ломается и отстаёт.

Категоризация: линкбилдер живёт в мире трёх источников — собственных технических проверок, парсинга выдачи и отчётов сервисов индексации, — и ни один из них не заменяет другие.

Оценка: к 2027–2028 году проверка доноров уйдёт в API-first сценарии, где список URL проверяется, отправляется и пересверяется по расписанию без ручных site:; это наше информированное мнение, а не измеренный тренд.

План на 10 минут: выгрузите последние 50 доноров в таблицу, снимите коды ответа одной командой curl, загрузите список в чекер индексации и посмотрите, сколько из них Google на самом деле видит.

Не проиндексированные после шагов 2–5 отправляйте на индексацию с предварительной проверкой и ждите отчёт на 7 день.

На что влияет SpeedyIndex и на что не влияет никто

Проверка индексации ссылок и отправка доноров в SpeedyIndex не требуют подтверждения сайта в Search Console или Яндекс Вебмастере: сервис принимает любые сторонние URL — беклинки, гостевые посты, крауд, PBN, Tier-2 и Tier-3.

Модель оплаты — Pay-per-Result: токены списываются только за успешно проиндексированные ссылки, 1 проиндексированный URL стоит 100 токенов.

Проверку сервис проводит на 7-й день для Google и на 15-й для Яндекса; токены за непроиндексированные URL возвращаются на баланс автоматически.

Отчёт по задаче разделяет URL на проиндексированные, непроиндексированные и с ошибками индексации — например, «Страница просканирована, но пока не проиндексирована», — и показывает тайтлы проиндексированных страниц. Опция предварительной проверки отсекает 404/410/451, страницы под robots.txt и noindex, медиафайлы и уже проиндексированные адреса до списания токенов.

Работать можно из веб-кабинета, Telegram-бота, расширения Chrome или через API для разработчиков. Бесплатные инструменты — извлечение URL из Sitemap XML, проверка редиректов, noindex, 404 и 5xx. Новым пользователям начисляется 200 бесплатных токенов.

Чего сервис не делает: не обещает 100 % индексации и не влияет на решение алгоритма. Если донор прошёл технические проверки и всё равно не попал в индекс на 7 день, это ответ поисковой системы, а не сбой процесса.

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

Сообщение Ссылка стоит, а страница-донор не в индексе: как проверить индексацию обратных ссылок появились сначала на SPEEDYINDEX.

Звучит просто. На практике заметная часть списков, которые к нам приходят (оценка команды), собрана по принципу «скачал карту, отправил всё». Внутри — пагинация, страницы с 301, товары, снятые с продажи год назад, и разделы, которые сам же владелец закрыл noindex. Каждый такой адрес — либо отказ поисковика, либо впустую потраченные токены и лимиты.

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

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

Готовый список убирает ваши ошибки. Ошибки поисковика он не отменяет.

Sitemap — это не список к индексации, а сырьё для него

Миф: «положил URL в sitemap — поисковик обязан его проиндексировать». Это не так, и Google говорит об этом прямо. Sitemap — рекомендация о том, какие страницы вы считаете важными; сканировать и индексировать их поисковик не обязан.

Пересказ справки Google «Build and submit a sitemap» (Search Central, обновление 2026): один файл карты — не больше 50 000 URL и 50 МБ без сжатия, для больших сайтов используется sitemap index; в карте перечисляются только канонические адреса; значения <priority> и <changefreq> Google игнорирует, а <lastmod> учитывает, только если дата стабильно и проверяемо соответствует реальному изменению страницы.

Точнее смотреть на карту сайта иначе: это заявка, а не приказ. Сгенерировал её плагин CMS, и он же положил туда всё, до чего дотянулся: архивы по датам, страницы авторов, фильтры каталога, черновики с noindex. Доказательство — в любом отчёте GSC «Страницы»: секция «Не проиндексированы» с причинами «Страница с переадресацией», «Не найдено (404)», «Исключена тегом noindex» почти всегда наполнена адресами именно из sitemap.

Отсюда и порядок работы: раз sitemap — сырьё, его просеивают. Сначала выгрузить, потом отфильтровать, потом проверить, что из оставшегося уже в индексе.

Во что обходится список без фильтра

Тезис: каждый лишний URL в задаче на индексацию — прямые потери. У любого сервиса индексации есть цена за адрес, у Google Indexing API — суточная квота, у Яндекс Вебмастера — дневной лимит переобхода. Отправили 1 000 адресов, из которых 300 отдают 404 или закрыты noindex, — треть квоты сгорела ни на что.

Антитезис: «У меня Pay-per-Result, за непроиндексированное вернут токены — зачем фильтровать?» Возврат закрывает финансовую сторону, но не временну́ю: отчёт замусорен ошибками, и в статистике «сколько реально зашло» вы не отличите отказ поисковика от собственных 404.

Команда SpeedyIndex: «Самый частый вопрос в поддержке — „почему из 2 000 ссылок в индекс попало 400″. Когда мы открываем задачу, в 6 случаях из 10 (внутренняя оценка команды, не измеренная статистика) половина списка ещё до отправки была нежизнеспособна: редиректы на другие адреса, снятые страницы, дубли с параметрами. Пре-чек их отсёк, но человек этого не заметил и решил, что индексация „не работает»».

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

Девять шагов: от sitemap до файла, который можно отправлять

Шаг 1. Выгрузите адреса из sitemap и посчитайте их. Откройте карту в браузере и определите, что перед вами: <urlset> со страницами или <sitemapindex>, который ссылается на дочерние карты.

Инструмент — бесплатный парсер XML-карты сайта: вставляете адрес карты, получаете текстовый список по одному URL в строке. Кто работает в терминале — одна команда:

curl -s https://site.ru/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' > raw.txt
wc -l raw.txt

Если это sitemap index, grep вернёт адреса дочерних карт, а не страниц — каждую раскрывайте отдельно, сжатые .xml.gz — через gunzip -c.

Что вы увидите: файл raw.txt и число строк из wc -l. Смотрите сразу.

Успех — число строк равно числу <loc> в карте (или сумме по дочерним картам), внутри нет тегов и пустых строк.

Провал — ноль строк или ошибка XML в браузере: карта отдаёт HTML-заглушку, 404 или неэкранированный &. Тогда чините карту, дальше идти не с чем.

Шаг 2. Нормализуйте список. Уберите дубли, разнобой протокола и хоста, хвосты параметров. Инструмент — sort -u и grep:

sort -u raw.txt > clean.txt
wc -l clean.txt
grep -c '^http://' clean.txt
grep -c '?' clean.txt

Настройка: если сайт живёт на https:// без www, в списке не должно быть ни одного http:// и ни одного www. — приведите sed-заменой.

Что вы увидите: три числа. Смотрите сразу.

Успех — строк стало меньше или столько же, http:// — ноль, адресов с ? — ноль или только те, где параметр создаёт отдельную страницу (пагинация, если она канонична).

Провал — в карте смешаны хосты: значит, генератор берёт адреса из разных источников, и чекер индексации потом посчитает www и без www разными страницами. Сначала решите, какой хост канонический, потом двигайтесь дальше.

Шаг 3. Прогоните коды ответа — без автоследования редиректов.

Инструмент — бесплатные чекеры 404 и 5xx или curl с мобильным User-Agent, потому что сканирует Googlebot Smartphone:

while read u; do
  curl -s -o /dev/null -A 'Mozilla/5.0 (Linux; Android 10; Mobile)' -w "%{http_code} $u %{redirect_url}\n" "$u"
done < clean.txt > codes.txt

Настройка — без ключа -L: вам нужен код первого ответа, а не конечного. Наблюдаемый выход: codes.txt со строкой «код, URL, адрес редиректа». Смотрите сразу; строки с 5xx перепроверьте через час — сервер мог быть перегружен.

Успех — 200 и пустое поле редиректа.

Провал делится на четыре диагноза с разными действиями: 404/410 — в отдельный файл и вон из sitemap; 301/302 — в список кладём конечный адрес из третьего столбца, а исходный выбрасываем (301 — это не «почти 200», для индексации существует только конечный URL); 5xx — отложить до стабильного ответа; 403 при 200 в браузере — антибот-фильтр режет запросы без cookies, поисковый краулер получит то же самое, разбирайтесь с файрволом.

Шаг 4. Отловите soft 404. Код 200 — ещё не признак живой страницы: снятый товар или удалённая запись часто отдают 200 и текст «ничего не найдено».

Инструмент — curl и размер ответа:

while read u; do printf '%s %s\n' "$(curl -s "$u" | wc -c)" "$u"; done < ok.txt | sort -n | head -30

Настройка: ok.txt — только адреса с 200 из шага 3. Наблюдаемый выход: 30 самых коротких страниц по байтам. Смотрите сразу.

Успех — самые короткие страницы всё равно содержат основной контент (откройте три-четыре руками).

Провал — в начале списка страницы весом в шаблон: заголовок «Не найдено», пустой каталог, «Товар снят с продажи». Это soft 404: из списка убираем, а на сайте либо отдаём честный 404/410, либо возвращаем контент. GSC такие страницы позже покажет как «Ошибка soft 404», и лучше найти их раньше отчёта.

Шаг 5. Проверьте noindex — и сразу robots.txt.

Инструмент — бесплатный чекер noindex или две строки curl: одна на заголовок X-Robots-Tag, другая на мета-тег:

curl -sI "$u" | grep -i 'x-robots-tag'
curl -s "$u" | grep -io '<meta[^>]*name="robots"[^>]*>'

Что вы увидите: строка с noindex/none либо пустой вывод. Смотрите сразу.

Успех — вывод пуст по обеим проверкам.

Провал — есть noindex: адрес из списка убираем; если директива стоит по ошибке, снимаем её и ждём переобхода, а не отправляем «пока так».

Граничный случай, который ломает этот шаг: путь закрыт Disallow в robots.txt. Тогда чекер честно скажет «noindex нет», но поисковику это не поможет — по справке Google о блокировке индексирования директива noindex работает только на странице, доступной для сканирования; закрытый robots.txt адрес Googlebot не откроет и noindex не увидит. Поэтому отдельно откройте https://site.ru/robots.txt и сверьте правила Disallow с путями из списка. Закрытые адреса в задачу не идут, пока правило не снято.

Шаг 6. Сверьте canonical. Страница может отдавать 200 и при этом указывать каноническим другой адрес — поисковик проиндексирует тот, другой.

Инструмент — curl и grep:

curl -s "$u" | grep -io '<link[^>]*rel="canonical"[^>]*>'

Что вы увидите: тег с href. Смотрите сразу.

Успех — href побайтно совпадает с проверяемым URL.

Провал — href ведёт на другой адрес: в список кладём канонический (после того как он сам прошёл шаги 3–5), исходный выбрасываем. href на другой хост или на http:// — возвращайтесь к шагу 2, у сайта нерешённый вопрос с зеркалом.

Шаг 7. Отделите уже проиндексированное. Сюда доходит список из адресов с 200, без noindex, с совпадающим canonical. Теперь его делят надвое.

Инструмент — массовая проверка индексации в Google по файлу (для Яндекса и Bing — отдельные режимы) либо «Проверка URL» в Search Console для контрольной выборки: GSC проверяет по одному адресу и только на подтверждённом сайте, для сотен строк не годится.

Настройка: загрузите файл, выберите поисковик.

Что вы увидите: постатусный список «в индексе / не в индексе» с экспортом. Смотрите после завершения проверки — минуты.

Успех — два файла: indexed.txt и to-index.txt.

Провал — расхождения. site: в поиске не нашёл, а чекер говорит «в индексе»: верьте чекеру, site: показывает не всё. Чекер говорит «не в индексе», а в GSC статус «Проиндексирована»: страница могла быть проиндексирована под каноническим адресом — сверьте поле «Канонический URL, выбранный Google» в «Проверке URL».

Шаг 8. Соберите задачу и отправьте только to-index.txt. Параллельно вычистите из sitemap всё, что отсеялось на шагах 3–6: карта, в которой лежат 404 и noindex, каждым переобходом напоминает поисковику о ваших ошибках.

Инструмент — веб-кабинет SpeedyIndex или Telegram-бот: новая задача, файл со списком.

Настройка: режим Standard для разовой отправки (до 100 000 адресов файлом) или Drip-Feed, если адреса должны уходить порциями по часам и дням; включите предварительную проверку ссылок — она страхует от того, что вы всё-таки пропустили (404/410/451, noindex, robots.txt, медиафайлы, уже проиндексированные URL), и токены за отсечённые адреса не сгорают.

Что вы увидите: диалог подтверждения с числом URL и итоговым списанием. Смотрите до нажатия «Отправить».

Успех — число URL в диалоге равно числу строк в to-index.txt.

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

Шаг 9. Прочитайте отчёт, а не общий процент.

Инструмент — отчёт задачи в кабинете и, для своего сайта, отчёт «Страницы» в GSC либо «Страницы в поиске» в Яндекс Вебмастере. Когда смотреть: день 7 для Google, день 15 для Яндекса.

Что вы увидите: три группы — проиндексированные (с тайтлами страниц), непроиндексированные, ошибки индексации вида «Страница просканирована, но пока не проиндексирована»; токены за непроиндексированные адреса вернулись на баланс.

Успех — в группе «непроиндексированные» нет адресов с 404, редиректами и noindex: раз список был чистый, каждый невход — решение алгоритма.

Провал — статус «просканирована, но не проиндексирована» у большой доли: это не сбой пайплайна и не повод сразу переотправлять.

Проверьте контент, дубли по смыслу и внутренние ссылки, дайте странице 2–3 недели и повторите проверку индекса.

Чем выгружать и проверять: пять способов и их пределы

Где ломается пайплайн: четыре типовых сбоя

Sitemap index выгружен как список страниц.

Факт: у сайтов от нескольких тысяч страниц CMS обычно отдаёт sitemap.xml как индекс дочерних карт.

Связь: grep по <loc> честно даёт 5–20 адресов — адреса карт.

Утверждение: «у нас в sitemap всего 12 страниц».

Опровержение: откройте любой из адресов — это ещё один XML; пайплайн стартует заново с каждой дочерней карты.

Редиректы посчитаны за живые страницы.

Факт: curl -L и большинство браузерных проверок показывают конечный 200.

Связь: в список попадает исходный адрес с 301.

Утверждение: «страница отвечает 200, всё хорошо».

Опровержение: для индексации существует конечный URL, исходный поисковик пометит как «Страница с переадресацией» и в индекс не возьмёт. В список идёт третий столбец из шага 3, а не первый.

Чекер noindex сказал «чисто», а GSC — «Заблокировано в robots.txt».

Факт: путь закрыт Disallow.

Связь: Googlebot страницу не открывал, содержимое <head> не читал.

Утверждение: «noindex нет, значит, индексируемо».

Опровержение: по справке Google директивы на странице работают только там, куда краулер может зайти; статус в GSC покажет именно блокировку robots.txt, а не noindex. Проверка robots.txt — обязательный спутник шага 5, а не «если время останется».

Отправлено 2 000, в индекс вошло 400 — «сервис не работает».

Факт: отчёт день 7 показывает 400 проиндексированных, остальное — непроиндексировано или «просканирована, но не проиндексирована».

Связь: список не проходил шаги 3–7.

Утверждение: «индексация не сработала».

Опровержение: разложите непроиндексированные по кодам и директивам — по опыту поддержки (оценка команды, не измеренная статистика) от трети до половины адресов нежизнеспособны ещё до отправки. Оставшийся отказ — вопрос к страницам, и решается он на сайте.

Иллюстративная модель: каталог на 8 000 адресов после переезда

Иллюстративная модель на основе типичных условий для команды из e-commerce; цифры — диапазоны и допущения, не измеренные результаты реального клиента.

Контекст. Интернет-магазин переехал на новую CMS. Sitemap — индекс из шести дочерних карт, суммарно около 8 000 адресов. Задача: понять, что отправлять на индексацию.

До. Список выгружен «как есть» и отправлен целиком. По ощущениям команды в индекс зашла «примерно половина», отчёт замусорен: сотни 404 по снятым товарам, 301 со старых адресов на новые, фильтры каталога с параметрами. Где отказ поисковика, а где собственный мусор, неясно.

Действия. Раскрыты все шесть карт; после sort -u и приведения хоста список сжимается на 10–15 % (оценка: дубли с www и параметрами). Без -L видны 301 — заменены конечными адресами; 404 удалены из карт; заглушки снятых товаров с 200 отловлены по размеру; категории под Disallow от старой CMS открыты до отправки. Массовая проверка делит остаток на «в индексе» и «к отправке», в задачу уходит только второй файл с включённой предварительной проверкой.

После. Список к отправке сократился примерно до 40–60 % от исходных 8 000 (диапазон, не измерение). На день 7 среди непроиндексированных нет ни одного 404 и редиректа — только страницы, по которым вопрос к контенту. Смоделированный провал: одна дочерняя карта была .xml.gz, первый прогон её пропустил; заметили по расхождению числа строк с числом <loc> в index-файле. Урок: считать строки на каждом шаге.

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

Вопросы, которые остаются после чек-листа

В: Как выгрузить все URL из sitemap, если это sitemap index?

О: Сначала соберите адреса дочерних карт из <sitemapindex>, затем прогоните парсер или curl по каждой из них и склейте результат. Сжатые карты .xml.gz разворачивайте gunzip -c. Итоговое число строк должно сходиться с суммой <loc> по всем дочерним картам.

В: Нужно ли удалять из sitemap страницы с 404?

О: Да. По справке Google в карте перечисляются только канонические рабочие адреса; 404, 410 и редиректы в ней — шум, который каждый переобход тратит зря. Удаляйте из карты и не кладите в список к отправке.

В: Как проверить noindex по списку URL массово?

О: Бесплатным чекером noindex по файлу или curl: заголовок X-Robots-Tag через -I, мета-тег robots — через grep по HTML. И отдельно сверьте пути с Disallow в robots.txt — иначе проверка noindex даёт ложное «чисто».

В: Как массово проверить индексацию страниц в Google перед отправкой?

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

В: Что делать со статусом «Просканирована, но пока не проиндексирована» в отчёте?

О: Не переотправлять сразу. Если список был чистый, это решение алгоритма о странице: проверьте контент, дубли по смыслу, внутренние ссылки, дайте 2–3 недели и повторите проверку индекса. Повторная отправка без правок расходует лимиты ещё раз.

Куда движется подготовка списков и что можно сделать за 10 минут

Факт: отправка на индексацию уходит в API и пакетные задачи — Indexing API с квотами, IndexNow, API сервисов индексации.

Категоризация: чем быстрее сама отправка, тем дороже мусор в списке — квота сгорает за секунды.

Оценка: наше информированное мнение на 2026–2028 — фильтр по кодам, директивам и статусу в индексе станет обязательным слоем перед любым API-вызовом, а не «хорошей практикой».

План на 10 минут: откройте свой sitemap.xml, определите, urlset это или index, выгрузите адреса и посчитайте строки. Затем grep -c '^http://' и grep -c '?'. Два числа отличных от нуля — и вы уже нашли, с чего начинать. Останется прогнать коды ответа и разделить список тем же инструментом массовой проверки индексации, что в шаге 7: он работает по любым доменам и без прав в Search Console.

Что SpeedyIndex делает с вашим списком и где заканчивается его зона ответственности

Что нужно на входе. Список адресов: текстовый файл или строки в кабинете, до 100 000 URL в режиме Standard. Подтверждать права на домен в GSC или Вебмастере не нужно — принимаются любые сторонние адреса: беклинки, гостевые посты, PBN, крауд, Tier-2/3.

Что сервис проверяет до списания. Опция предварительной проверки ссылок отсекает HTTP 404/410/451, страницы под robots.txt и noindex, медиафайлы и уже проиндексированные URL. Токены за отсечённые адреса не сгорают. Бесплатные инструменты — парсер XML-карты, чекеры редиректов, noindex, 404 и 5xx — закрывают шаги 1, 3 и 5 этой статьи без входа в кабинет.

Как считаются деньги. Модель Pay-per-Result: токены списываются только за проиндексированные ссылки, 1 проиндексированный URL — 100 токенов. Проверка на 7-й день для Google и на 15-й для Яндекса; за непроиндексированные адреса токены автоматически возвращаются на баланс. Новым пользователям — 200 бесплатных токенов на пробу.

Что вы получаете на выходе. Отчёт день 7 / день 15: проиндексированные страницы с тайтлами, непроиндексированные, ошибки вида «Страница просканирована, но пока не проиндексирована». Режим Drip-Feed растягивает отправку по часам и дням, если нужен ровный темп; интерфейсы — веб-кабинет, Telegram-бот, расширение Chrome и API [API-DOC: детали эндпоинтов только из приложенной документации].

Чего сервис не гарантирует. Индексацию. Краулер — Googlebot Smartphone, отправка и проверка — на нашей стороне, решение — на стороне алгоритма. Чистый список из этой статьи повышает долю адресов, за которые вообще есть смысл платить; остальное решает поисковик.

Сообщение Готовим список URL к индексации: выгружаем из sitemap, убираем 404 и noindex, проверяем индекс появились сначала на SPEEDYINDEX.