Как настроить drip-feed SpeedyIndex на 14 дней для 800 URL гостевых постов в одной задаче Google

Восемьсот URL гостевых постов не кладут в Google одним часовым сбросом. Drip-feed SpeedyIndex режет тот же список на дневные порции внутри одной задачи Pay-per-Result: 800 ÷ 14 ≈ 57 адресов в сутки. Краулер по-прежнему представляется как Googlebot Smartphone. Меняется календарь, не алгоритм Google. Поисковик сам решает, что хранить. Списывают 100 токенов за проиндексированный URL, а окно возврата по Google считают от последней дневной порции, не от клика «Создать».

Задача «как настроить drip-feed SpeedyIndex на 14 дней для 800 URL гостевых постов в одной задаче Google» — это расписание плюс чистый txt. Вставить все 800 в первый же день и назвать это drip-feed значит воспроизвести Standard. Включаете drip-feed, ставите 14 дней и только после проверки индексности убираете строки, которые Google уже отдаёт. Опциональная предпроверка снимает 404, 410, 451, блокировку robots/noindex и уже лежащие в индексе URL, чтобы они не попали в очередь.

Request indexing в Search Console на чужом доноре не открыть: площадку вы не подтверждаете. Поэтому и нужна сторонняя задача. Это не билет в топ и не обещание, что все 800 окажутся в индексе. Bing в SpeedyIndex — только чекер. Яндекс идёт отдельной задачей с перепроверкой на 15-й день.

Почему Standard на 800 гостевых постов схлопывается в часовой сброс

Миф звучит так: одна Google-задача на 800 гостевых постов «загонит их в индекс на этой неделе». Парный миф: drip-feed нужен только молодым доменам, а возрастной money-сайт спокойно проглотит 800 URL в понедельник.

Standard выпускает список короткой пачкой. Drip-feed в Pay-per-Result режет его на равные дневные доли: в API это drip_feed и drip_feed_days от 2 до 30, а число URL не меньше числа дней. Восемьсот адресов за 14 дней — выбор скорости для доноров, которых Googlebot видит как чужие страницы, не как ваш подтверждённый сайт. Справка Google про краулинговый бюджет крупных сайтов говорит про ёмкость обхода и спрос на обход у площадки, которую сканируют. URL гостевого поста живёт на бюджете издателя, не на вашем.

Drip-feed в SpeedyIndex — функция Google Pay-per-Result: переключатель в кабинете плюс число дней, либо те же флаги в API. Это не продукт Bing. Сводный отчёт по возврату закрывается через 7 дней после последней порции, не через 7 дней после «Создать». Проверка индексности не ставит URL в очередь. Отправка 404 — тикет издателю, не «промах индексации».

Гостевой пост уже оплачен: редактор, анкор, дата в отчёте. Если 80 из 800 отдают 404 или noindex, Standard всё равно поставит их в очередь. Токены за недоступный URL не возвращают. Если 200 адресов уже лежат в Google, вы повторно просите обойти хранимые документы. Предпроверка снимает этот расход. Сбросить 800 живых промахов за час иногда можно — и получить всплеск обхода на чужих хостах плюс клиента, который ждёт отчёт «на седьмой день от сегодня». На drip-feed седьмой день сводного Google-отчёта стартует после последней порции. Клиенту пишете: день 14 плюс 7.

«Четырнадцать дней на 800 гостевых постов — это суточный потолок, не приём затянуть сроки. Сначала проверьте список. Если 120 URL уже открываются в Google, эти 120 в drip не кладут. Мы списываем строку индекса, не клик. Токены за непроиндексированные Google-URL возвращаем на 7-й день после последней порции. Недоступный URL не возвращаем. Drip-feed работает только для Google. Индексатора Bing нет, гарантии 100% индекса нет.»

— команда SpeedyIndex

Проверки и предпроверка нужны живым 200-м страницам без noindex. Остальное чинит издатель.

Как 14 дней сдвигают часы возврата и отчёт клиенту

Линкбилдер продаёт дату, не настроение кабинета. Если в договоре стоит «отчёт по индексу через неделю», а задача идёт 14 дней порциями, вы обещаете документ, которого ещё нет. Порции ещё выходят. Сводная перепроверка Google не стартовала.

Правило простое. Standard на коротком уже проверенном списке: часы возврата считают от обработки пачки, отчёт клиенту — день 7. Drip-feed на 800 URL: порции идут две недели, сводный Google-отчёт — день 14 плюс 7. Путать эти часы дороже, чем сам режим. Клиент слышит «сервис сломался». Сломался календарь в брифе.

Второе правило не слабее первого. 800 ÷ 14 ≈ 57 — арифметика на полном списке. Предпроверка почти всегда режет хвост. Если после чекера и фильтров осталось 610 URL, в день уходит около 44. Клиенту говорите фактический суточный объём после очистки.

Третье правило: одна задача, один движок. Google drip-feed не пишет Яндекс и не пишет Bing. Яндекс закрывается на 15-й день и живёт отдельной задачей.

Регламент: одна Google-задача, 14 дней, наблюдаемый артефакт на каждом шаге

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

1. Заморозьте 800 href. Действие: выгрузите таблицу размещений. Инструмент: txt, один URL на строку. Настройка: схема, хост и путь без UTM, если трекинг не продавали. Наблюдаемый выход: 800 абсолютных строк. Когда: до любого чекера. Успех: каждая строка совпадает с проданным адресом. Провал: короткие ссылки рядом с финальными — сначала снимите редиректы.

2. Схлопните дубли. Действие: уберите близнецов после лёгкой нормализации. Инструмент: таблица или sort -u. Настройка: точное совпадение после политики HTTPS и слэша. Наблюдаемый выход: счётчик падает, если двойники были. Когда: сразу после заморозки. Успех: нет двух одинаковых строк. Провал: живы и http, и https — оставляете тот, что отвечает 200 в логе редиректов.

3. Снимите hop-лог с выборки и с поздних отказов. Действие: запросите заголовки с следованием редиректам. Инструмент: curl -I -L. Настройка: статус, location, x-robots-tag, финальный URL. Наблюдаемый выход: упорядоченный список прыжков. Когда: до оплаты Google-задачи. Успех: один 200 и нет noindex в заголовке. Провал: 404, 410, 451, 403 или петля — этот URL в drip не кладут. Токены за недоступный адрес не вернут.

4. Прогоните список по публичному индексу Google. Действие: массовая проверка точных URL. Инструмент: проверка индексации сайта в Google без подтверждения в Search Console, с чужими адресами. Настройка: движок Google, датированный экспорт. Наблюдаемый выход: колонка «в индексе / не в индексе» по каждой строке. Когда: после чистого листа, до drip-feed. Успех: уже лежащие в Google строки покидают очередь отправки. Провал: пустой site: принимаете за истину и снова отправляете то, что Google уже хранит. Проверка не ставит URL в очередь.

5. Выкиньте мёртвые и уже лежащие строки. Действие: уберите 404/410/451, robots или noindex и URL, которые Google уже отдаёт. Инструмент: опциональная предпроверка задачи плюс hop-лог. Настройка: все фильтры предпроверки включены. Наблюдаемый выход: более короткий список выживших. Когда: после чекера, до выбора дней. Успех: в очереди drip живые, индексируемые, отсутствующие в Google URL. Провал: предпроверку пропускаете, потом спорите про возврат на 404, которые в сделку Pay-per-Result не входили.

6. Проверьте, что 14 дней проходят правило API. Действие: посчитайте оставшиеся URL. Инструмент: wc -l или таблица. Настройка: drip_feed_days = 14; число URL не меньше 14; дни — целое от 2 до 30. Наблюдаемый выход: например, 680 ≥ 14. Когда: до создания задачи. Успех: календарь можно заполнить. Провал: осталось 10 URL — 14 дней не насилуйте; укоротите срок или поставьте короткий хвост в Standard. API отклонит drip, который не заполняет календарь.

7. Создайте одну Google-задачу drip-feed. Действие: загрузите очищенный txt или отправьте список через API. Инструмент: переключатель drip-feed в кабинете либо страница drip-feed индексации с drip_feed true и drip_feed_days 14. Настройка: движок Google; Pay-per-Result; Googlebot Smartphone; без подтверждения Search Console; чужие URL допустимы. Наблюдаемый выход: один task_id, около 57 URL в день, если выжили все 800, меньше — если предпроверка срезала список. Когда: после предпроверки. Успех: интерфейс показывает шаг в 14 дней. Провал: дни = 1, случайно выбран Standard, либо URL меньше 14.

8. Смотрите суточные принятые счётчики, не фальшивый «день 7». Действие: записывайте, сколько URL ушло за сутки. Инструмент: отчёт задачи. Настройка: календарная дата плюс число. Наблюдаемый выход: ~57 в день при 800 выживших; меньше, если список урезали. Когда: каждое утро 14 дней. Успех: порции уходят по графику. Провал: волна 404 у издателя посреди drip — такие URL снимаете сразу. Не ждите возврата, который на недоступных строках не сработает.

9. Дождитесь последней порции плюс семь дней. Действие: не считайте календарный день 7 от создания задачи днём возврата. Инструмент: Google-отчёт Pay-per-Result. Настройка: 100 токенов за проиндексированный URL; автовозврат за чистый промах, если адрес был доступен. Наблюдаемый выход: проиндексировано, возвращено или исключено. Когда: день 14 плюс 7. Успех: лежащие в индексе строки списаны, чистые промахи возвращены, мёртвые ушли тикетами издателю. Провал: обещали отчёт на 7-й день от старта.

10. Перепроверьте выборку вне отчёта. Действие: вставьте 30 оставшихся URL в тот же чекер, что на шаге 4. Инструмент: проверка Google, точные href. Настройка: новая дата, без Search Console. Наблюдаемый выход: согласие с отчётом или зафиксированный лаг. Когда: после появления возвратов. Успех: отчёт и чекер сходятся. Провал: расхождение — пишете оба штампа. Оплаченный запрос — попытка обхода, не гарантия хранения.

Когда 14-дневная задача выглядит «зависшей», а календарь ещё честный

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

Возврат меньше ожидаемого часто значит другое: в txt проскочили уже лежащие в Google URL, и на перепроверке их списали как индекс. Их надо было снять на шаге 4.

В API поставили не то имя поля и получили задачу, похожую на Standard. Актуальные флаги v2 — drip_feed и drip_feed_days.

В кабинете drip выключен, 800 URL, режим Standard: вы собрали часовой сброс. Если ещё нужны 14 дней, задачу собираете заново на очищенном списке.

Отчёт на 8-й календарный день 14-дневного drip пустой — так и должно быть. Сводная перепроверка Google стартует после последней порции.

Токены не вернулись на 404 — ожидаемо. Недоступные URL стоят вне автовозврата. Чекер говорит «в индексе» — строку в повторный обход не кладёте. Bing «да» и Google «нет» — разные индексы; в Google-задачу идёт только живой промах Google.

Иллюстративные сценарии линкбилдинга на 800 гостевых постов

Иллюстративный сценарий — не реальный клиент. Агентство в пятницу залило 800 гостевых постов как Standard. В понедельник клиент спросил отчёт «на седьмой день». Сорок URL отдавали 404. Эти токены не вернулись. После предпроверки тот же хвост на 14 днях шёл бы примерно по 54 URL в сутки.

Иллюстративный сценарий — не реальный клиент. Фрилансер выставил drip_feed_days 14 на 800 строках и пообещал полный Google-отчёт через семь дней от старта. На 12-й день порции ещё уходили. Честное окно — последняя порция плюс семь. Клиент решил, что SpeedyIndex «завис».

Иллюстративный сценарий — не реальный клиент. Команда оставила в txt шестьдесят URL, которые Google уже открывал. Предпроверка сняла бы их. Drip потратил попытки обхода на хранимые документы, и клиенту пришлось объяснять списание 100 токенов.

Иллюстративная модель, не боевой лог и не реальный аккаунт:

800 href гостевых постов
    |
    +--> hop-лог / опциональная предпроверка
    |         --> снять 404, 410, 451, robots, noindex
    |         --> снять уже проиндексированные
    |         --> выжившие (пример: 610)
    |
    +--> одна Google-задача Pay-per-Result
              --> drip_feed true, drip_feed_days 14
              --> ~44 URL / день, если выжили 610
              --> последняя порция в день 14
              --> перепроверка Google: день 14 + 7
              --> 100 токенов за проиндексированный URL
              --> возврат за чистый доступный промах

Допустим, продано 800 постов на смешанных донорах, Search Console на площадках нет. После чекера и предпроверки осталось 610. 610 ÷ 14 ≈ 44 в день. Создаёте один Google drip на 14 дней. Клиенту обещаете отчёт после последней порции плюс 7, не фразу «610 в индексе на 14-й день». Это модель процесса, не замеренный кейс.

Чем 14-дневный drip отличается от Standard и от четырнадцати мелких задач

Один 14-дневный drip на очищенных URL подходит, когда около 800 живых промахов нужно вести ~57 в сутки и закрыть одним отчётом. Дата клиенту: две недели отправок плюс семь дней. Если URL меньше 14, этот срок не ставят.

Standard на 800 строках годится для короткого уже проверенного списка. Очередь сбрасывается сразу, и 800 URL бьют по Google пачкой. На сотнях чужих гостевых постов этот режим не берут.

Четырнадцать отдельных Standard-задач по ~57 URL имеют смысл, только если человек обязан ставить паузу руками. Риск: 14 отчётов и 14 часов возврата. Когда один параметр drip_feed_days уже режет календарь, мельчить не нужно.

Инспекция URL в Search Console работает на площадках, которые вы подтвердили. На 800 чужих донорах чужой хост не открыть. IndexNow закрывает другой движок: квитанция Bing — не хранение Google, индексатора Bing нет.

Чекер — калитка. Предпроверка — вторая калитка. Drip-feed — календарь. Ни один из них не подменяет решение Google о хранении.

Как отвечать клиенту про 800 URL и 14 дней

Почему 14 дней, а не Standard? Восемьсот делить на 14 — около 57 URL в сутки. Standard заточен под короткую пачку. Drip-feed — ритм большого Google-списка.

Drip-feed кладёт все URL в Google? Нет. Хранение решает Google. Pay-per-Result возвращает токены за непроиндексированные Google-URL на 7-й день после нужной перепроверки, кроме недоступных строк.

Откуда стартует день 7 на 14-дневном drip? После последней дневной порции, затем семь дней. Не от создания задачи.

Можно ли так же капать Bing? Нет. Drip-feed — только Google Pay-per-Result. Bing в SpeedyIndex — чекер. Индексатора Bing нет.

Какие поля API ставят 14 дней? drip_feed true, drip_feed_days 14, число URL не меньше 14. Дни — целое от 2 до 30.

Нужна ли предпроверка на 800 гостевых постах? Да. 404/410/451, robots/noindex и уже проиндексированные строки снимаете до списания токенов.

Вернут ли токены, если донор отдал 403 или закрыл путь в robots? Нет. Недоступные URL стоят вне автовозврата.

Нужна ли Search Console на каждом доноре? Нет. Краулер представляется как Googlebot Smartphone. Чужие URL принимают без подтверждения площадки.

Что делать, если 200 из 800 уже в индексе? Снимаете их до задачи. Капаете остаток.

Яндекс кладут в эту же Google-задачу? Нет. Отдельная задача, перепроверка на 15-й день.

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

Большие списки гостевых постов будут приходить txt-файлами. Скрин часового сброса как «индексация готова» снова промахивается мимо окна отчёта и правила про мёртвый URL. 14-дневный drip плюс «последняя порция плюс 7» — дата, которую можно поставить в календарь.

Десять минут на старт: выгрузите лист гостевых постов, один URL на строку. Около 800 строк — делите на 14. Снимите выборку заголовков, уберите очевидные 404. Google-задачу drip-feed открывайте после чекера и предпроверки. Клиенту напишите день 14 плюс 7. Не обещайте, что каждый URL окажется в индексе.

Предыдущая заметка в этой серии: SpeedyIndex: lập chỉ mục Google và Yandex, trả theo kết quả. Сначала её, если пришли по соседнему хвосту.

О SpeedyIndex

SpeedyIndex продаёт запросы на обход по модели Pay-per-Result. Один проиндексированный URL стоит 100 токенов.

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

Режимы кампании — Standard и Drip-Feed. Drip-Feed работает только для Google в Pay-per-Result. Опциональная предпроверка отсекает ответы 404, 410 и 451, блокировку в robots или noindex и уже проиндексированные URL. В API флаги drip_feed и drip_feed_days (от 2 до 30). Число URL не меньше числа дней.

Краулер представляется как Googlebot Smartphone. Подтверждение в Search Console и Вебмастере не нужно. Чужие URL принимать можно. Bing доступен только как чекер. Индексатора Bing нет.

Новый аккаунт получает 200 пробных токенов. Решение об индексе принимает поисковая система. Оплаченный запрос — попытка обхода, не обещание позиций и не гарантия попадания в индекс.