Автор: · 6 мин чтения · seo

Бэкдейтинг 11 блог-постов одной датой: почему так делать не надо

Опубликовал 11 готовых статей с одной датой. Через две недели понял, что выстрелил себе в ногу. Как поисковики ловят такую плотность и что я сделал, чтобы исправить.

В первый месяц нового сайта я хотел быстро набрать массу блог-публикаций. Написал «волну» из 21 статьи за два дня, опубликовал 9 апреля. Потом дописал ещё 11 и решил выкатить их одним днём - 17 апреля. Технически это было одно git commit && rsync. К концу апреля начал замечать, что соседние страницы стали попадать в Excluded в Яндексе. Через две недели вернулся и распределил даты по диапазону. История ниже.

Если коротко

  • Опубликовал 11 готовых постов одним днём с pubDate того же дня (17 апреля).
  • Через ~10 дней соседние страницы стали попадать в Excluded by noindex в Яндексе.
  • Не могу 100% доказать, что причина - именно плотность, потому что параллельно было много правок. Но временная корреляция чёткая.
  • Распределил pubDate по диапазону 20-30 апреля, обновил lastmod, пнул IndexNow. Excluded откатился за неделю.
  • Урок: 2-3 поста в неделю, максимум 1-3 в день. Не 11.

Зачем я вообще опубликовал 11 за раз

Логика была простая. У сайта было 6 системных страниц и 18 страниц услуг - стандартный набор для коммерческого сайта. Поисковикам этого мало: они любят сайты с глубоким контентом, FAQ, тематической экспертизой. Блог - самый дешёвый способ её показать.

Я сел писать. За неделю - 21 статья (волна 1, 9 апреля). Через неделю ещё 11 (волна 2, 17 апреля). Это были тематически разные статьи: гайды по типам уборок, разбор частых вопросов, статьи под локальные запросы. По 1500-3000 слов каждая. По уму надо было распределять их по календарю - пара в неделю, не больше пятёрки в день. Но я думал так: «лучше сразу влить весь контент, поисковики проиндексируют быстрее». Это была ошибка.

Что увидел Яндекс

Через 7 дней после второй волны я открыл Яндекс Вебмастер и посмотрел вкладку «Страницы в поиске». Картина:

  • В Searchable - 111 страниц
  • В Excluded by noindex - 56 страниц

Из этих 56 примерно 25 - это были блог-статьи. Остальные - старые версии URL и тестовые страницы, которые я сам исключил через Disallow в robots.txt. То есть из новых блог-постов уже половина была отбракована.

Открыл подробности - Яндекс показывает причину. У большинства написано «Документ не отвечает требованиям поисковой системы». Это абстрактное основание, без расшифровки. Иногда «дубль другого документа» - но дублей я физически не делал, контент уникальный.

Самое интересное - отбраковка была кластерная. Не случайные статьи из разных мест, а соседние по pubDate. Те самые 11 апреля + соседи из 9 апреля. Что-то в дате публикации тегало фильтры.

Гипотеза: плотность

Не могу однозначно доказать причинно-следственную связь, потому что в эти дни я параллельно крутил много правок: добавлял schema, чистил CLS, перебирал robots.txt. Может, в один из этих дней я случайно сломал что-то ещё. Но временно́е совпадение настолько чёткое, что я перебрал гипотезы и остановился на плотности публикаций.

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

Сигнал в моём случае выглядел так:

  • Сайт новый, домен зарегистрирован в марте
  • Первые две недели - статичный коммерческий сайт без блога
  • 9 апреля - 21 пост одной датой
  • 17 апреля - ещё 11 одной датой

Это паттерн контент-фабрики. Особенно если посмотреть на RSS-фид сайта на 17 апреля - там разом 32 свежих item с похожими H1 («Уборка квартиры X», «Уборка квартиры Y», «Уборка квартиры Z»). Любая система автоматизированной модерации увидит здесь подозрительный сигнал.

Что я сделал, чтобы исправить

Когда понял, что происходит - 28 апреля сел и переразмазал даты.

Шаг 1: переписал pubDate в frontmatter 11 статей второй волны. Вместо одного 2026-04-17 поставил даты в диапазоне 20-30 апреля, по одной на день:

# Было
---
pubDate: 2026-04-17
---

# Стало (разные у разных статей)
---
pubDate: 2026-04-22
---

Шаг 2: обновил updated: тоже, чтобы Яндекс увидел свежий timestamp. Не повторил pubDate, а поставил 2026-04-28 (сегодня).

Шаг 3: пересобрал sitemap. У меня lastmod берётся из filemtime() PHP-файлов, поэтому достаточно было пересохранить файлы и сгенерировать sitemap заново.

Шаг 4: отправил все 11 URL через IndexNow на Bing и Яндекс:

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json" \
  -d '{"host":"example.ru","key":"...","urlList":["...","..."]}'

Шаг 5: для надёжности отправил часть URL через Yandex Webmaster API /recrawl/queue (квота 620/сутки):

curl -X POST "https://api.webmaster.yandex.net/v4/user/<user-id>/hosts/<host-id>/recrawl/queue" \
  -H "Authorization: OAuth $TOKEN" \
  -d '{"url":"https://example.ru/blog/..."}'

Что произошло после фикса

Excluded начал откатываться. Через 5 дней после правки в Searchable вернулись 12 страниц из 25, ещё через 5 - ещё 9. К 5 мая в Excluded осталось 1-2 поста (и то это были служебные, не блог).

Точные цифры есть в статье «50 дней SEO» - там общая динамика Searchable / Excluded и трюки с переобходом через API. По бэкдейтингу - это та самая история про «не публикуйте пачкой».

Если бы делал заново

Сценарий 1: один человек пишет «волну» из 20 статей за неделю.

Готовите все 20 заранее. Публикуете по 2-3 в день в течение 7-10 дней. Каждый день - разные даты pubDate. RSS-фид сайта обновляется ровным потоком. Поисковики видят паттерн «активный блог», а не «контент-фабрика».

Сценарий 2: блог давно мёртв, надо оживить.

Бывает, что блог не публиковался полгода-год, и надо заполнить пустоту. Тогда можно действительно бэкдейтить - но не все статьи одной датой, а разнести по календарю с шагом 5-10 дней. Например, 8 готовых статей за период «3 месяца назад → сегодня» - это выглядит как «человек публикует раз в две недели, не дотягивает до regular cadence, но активен».

Сценарий 3: один день - один пост, никакого расписания.

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

Контрольные индикаторы

Чтобы поймать аномалию раньше, чем поисковики:

  • График Searchable / Excluded в Яндекс Вебмастер. Если Excluded растёт после публикации волны - это сигнал.
  • Sitemap-индекс и lastmod. Сайт со здоровой динамикой публикаций имеет lastmod, размазанные по календарю. Все одинаковые lastmod - красный флаг.
  • RSS-фид. Если в нём 10+ свежих item с одинаковой <pubDate>, переразметьте.

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

Целиком кейс по 50 дням SEO в B2B-клининге - в статье «50 дней SEO в B2B-клининге». Эта история про бэкдейтинг - один из эпизодов оттуда.

Если вы планируете запуск блога или нужно вылечить уже сложившийся паттерн - пишите в Telegram @dimik90. По услугам:

Близкое по теме: CLS 0.377 → 0.002 за день, антиспам форм без капчи.

Вопрос-ответ

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

Что такое бэкдейтинг и почему он работает с одного места?
Бэкдейтинг - это когда статья пишется сегодня, но публикуется с датой задним числом (например, неделю назад). Технически - просто значение поля pubDate в frontmatter MD-файла. Это позволяет «закрыть пустоту» в архиве: если у вас полгода ничего не выходило, можно дописать несколько постов и расставить их по разным датам, чтобы блог не выглядел заброшенным. Работает с одного места - потому что вы контролируете и контент, и систему публикации.
Поисковики правда видят разницу между «опубликовано вчера» и «опубликовано в один день 11 постов»?
Да. Они видят дату из sitemap (lastmod), дату публикации из schema BlogPosting, дату из meta og:article:published_time. Все три обычно одинаковы. Если 11 постов имеют одинаковый pubDate, это входит в SERP-датасет поисковика как кластер с одинаковым timestamp. Когда сайт молодой и до этого публиковал по 2-3 поста в неделю, внезапные 11 в один день - это аномалия. Поисковики уже несколько лет используют такие сигналы как часть spam detection.
Что произошло после моих 11 постов одной датой?
Один из кластеров статей попал в Excluded by noindex в Яндексе. Не все 11, а штук 5-6 из соседних страниц. Я не могу однозначно утверждать, что причина - именно бэкдейтинг, потому что параллельно было много других правок. Но временная корреляция указывает на это: в день публикации 11 постов и следующие три дня заметно вырос процент Excluded. Через две недели я распределил pubDate по диапазону 20-30 апреля - Excluded начал откатываться.
Какой темп публикаций нормальный для нового блога?
В моих метриках работает 2-3 статьи в неделю. Это даёт ровный поток, поисковики видят паттерн «человек пишет регулярно». В первый месяц можно пушнуть «волну» из 10-20 статей за пару недель, чтобы быстро набрать базу. Но я бы распределял эту волну по дням, а не по часам. Минимум - один пост в день, максимум - три. Больше - это сигнал «контент-фабрика», а не «реальный автор».
Можно ли исправить ошибку задним числом, как я это сделал?
Я перепрописал pubDate в frontmatter всех 11 статей, обновил lastmod в sitemap (он автоматически берётся из filemtime PHP-файлов), и пнул IndexNow на каждом URL чтобы переобновить дату в индексе. В sitemap появились разные даты, Яндекс и Google перечитали страницы. В целом сработало - Excluded откатился через 5-7 дней. Но это не идеальный фикс: исходный сигнал «11 в один день» поисковики увидели и могли запомнить. Лучше с самого начала публиковать ровно.

Оцените статью

Дальше

← Все записи