Неделя 138. Удалили 568 статей, чтобы вырасти
Разбор этой статьи
Эту тему разобрали в подкасте. Слушай параллельно с чтением.
В марте 2026 наш блог насчитывал 578 статей. К концу недели 138 их осталось 10. Мы удалили 98% контента - собственными руками, без давления Google, без штрафных санкций. Через полтора месяца после этого органический трафик начал расти.
Я Дмитрий Дьяконов, основатель Botseller AI. Это третий выпуск серии «Ретроспектива» - бортжурнал в прошлое. Если вы читали предыдущие выпуски, то знаете: на неделе 140 мы опубликовали 38 статей за 7 дней, на неделе 139 - провели SEO-марафон из 42 коммитов. Сегодня - неделя 138, с которой всё началось. Неделя, когда мы поняли: прежде чем строить, нужно снести.
Наследство, которое тянуло на дно
Сайт Botseller пережил несколько эпох. Была эпоха WordPress - с 2023 года на домене копился контент «для SEO» старой школы: генерические тексты по 300-500 слов, написанные ради ключевых слов. «Что такое чат-бот», «10 причин автоматизировать бизнес», «Как выбрать CRM» - сотни статей, которые не читал никто, включая нас самих.
К марту 2026 картина выглядела так:
- 578 статей в блоге
- Из них с ненулевым трафиком за последние 12 месяцев: меньше 20
- Средняя длина статьи: 400 слов
- Статей с хотя бы одним внешним бэклинком: единицы
- Конверсий из блога: ноль
При этом сайт уже переехал на Next.js, продукт развивался, а лендинг выглядел современно. Но блог оставался кладбищем контента. И это кладбище не просто лежало мёртвым грузом - оно активно вредило.
Почему плохой контент топит весь сайт, а не только себя
Ключевой сдвиг в SEO произошёл, когда Google выкатил Helpful Content Update и влил его в основной алгоритм. Главное изменение: оценка полезности контента стала сайтвайд-сигналом. Это значит, что Google оценивает не каждую страницу в вакууме, а репутацию домена целиком.
Механика простая и жестокая. Если на сайте 578 страниц и 550 из них - тонкий генерический контент, классификатор помечает весь домен как «сайт с преимущественно бесполезным контентом». И тогда даже ваши хорошие статьи ранжируются хуже, чем могли бы. Zombie-страницы кусают живых.
Есть и вторая механика - crawl budget. Поисковый бот выделяет каждому сайту лимит страниц на переобход. Когда 95% этого лимита уходит на мёртвые статьи 2023 года, новые качественные страницы ждут индексации неделями.
И третья - каннибализация. Пятнадцать старых статей «про чат-ботов» конкурируют между собой и с одной новой хорошей статьёй. Google не понимает, какую показывать, и в итоге не показывает толком ни одной.
Вывод, к которому мы пришли на неделе 138: контент-стратегия начинается не с написания. Она начинается с удаления.
Фреймворк Content Pruning: как решить, что удалять
Дальше - самое практичное, что есть в этой статье. Фреймворк, по которому мы принимали решение по каждой из 578 статей. Забирайте и применяйте.
Шаг 1. Выгрузите полный список URL. Три источника: Google Search Console (все страницы с показами), sitemap.xml, и выгрузка из CMS. Сведите в одну таблицу - у нас получилось 578 строк.
Шаг 2. Соберите метрики по каждой странице. Четыре колонки: клики за 12 месяцев (Search Console), показы за 12 месяцев, внешние бэклинки (Ahrefs, Serpstat или бесплатный Search Console → Ссылки), конверсии (если настроена аналитика целей).
Шаг 3. Прогоните каждую страницу через матрицу решений:
| Трафик | Бэклинки | Качество текста | Решение |
|---|---|---|---|
| Есть | Любые | Хорошее | Оставить, обновить дату |
| Есть | Любые | Слабое | Переписать, сохранив URL |
| Нет | Есть | Любое | Объединить с сильной статьёй + 301 |
| Нет | Нет | Есть потенциал (живой интент) | Переписать полностью |
| Нет | Нет | Тонкий генерик | Удалить с кодом 410 |
Шаг 4. Используйте 410 Gone, а не 404. Это важная техническая деталь. Код 404 говорит Google «страница не найдена, возможно временно» - и бот продолжает возвращаться месяцами. Код 410 говорит «страница удалена навсегда» - и Google выкидывает её из индекса в разы быстрее, освобождая crawl budget.
Шаг 5. Обновите sitemap и отправьте на переобход. Sitemap должен содержать только живые страницы. После чистки отправьте его заново в Search Console и Яндекс.Вебмастер.
Шаг 6. Замерьте результат через 4-8 недель. Раньше не имеет смысла: Google нужно время, чтобы переиндексировать сайт и пересчитать сайтвайд-сигналы.
По этой матрице из 578 статей у нас выжили 10. Ещё около 15 тем ушли в бэклог на полное переписывание - они вернулись на сайт позже, уже как части кластерной структуры недели 140.
Страх, который останавливает всех
Знаю, о чём вы думаете: «Удалить 568 страниц? А вдруг трафик упадёт?»
Мы боялись того же. Поэтому перед удалением проверили: сколько трафика приносят эти 568 статей суммарно. Ответ: меньше 3% органики. Пятьсот шестьдесят восемь страниц давали три процента посетителей - и при этом тянули вниз оценку всего домена.
Психологически удалять контент тяжело. Каждая статья - это когда-то потраченные деньги на копирайтера. Кажется, что удаляешь «актив». Но контент, который не приносит ни трафика, ни ссылок, ни конверсий - не актив. Это пассив, который ежедневно снижает рейтинг вашего домена в глазах поисковика.
Фаундерский вывод, который я вынес из этой недели: сентиментальность к легаси - самый дорогой вид сентиментальности. Это касается не только контента. Старый код, старые фичи, старые процессы - всё, что не работает на цель, работает против неё, потому что потребляет ресурс: crawl budget, время разработчиков, внимание команды.
Performance-спринт: с нуля до 87 на мобилке
Параллельно с чисткой контента мы взялись за производительность. Стартовая точка была унизительной: Lighthouse Desktop 54, Mobile - 0. Ноль. Мобильная версия сайта фактически не работала: слайды грузились все сразу, LCP уходил за 10 секунд, контент дёргался при скролле.
Что сделали за неделю:
LazyMount и ленивый рендеринг слайдов. Лендинг Botseller построен на полноэкранных слайдах. Раньше все слайды рендерились при загрузке страницы - десятки компонентов, сотни DOM-узлов, вся графика разом. Теперь рендерятся только видимый слайд и его соседи. Остальные монтируются при приближении.
LCP-оптимизация. Largest Contentful Paint - метрика, которая измеряет, когда пользователь видит основной контент. Приоритетная загрузка hero-изображения, preload критических шрифтов, отложенная загрузка всего остального.
Фикс дёрганья на мобилке. Классическая ошибка: высота вьюпорта в мобильных браузерах меняется при скролле (адресная строка прячется), и контент прыгает. Решение - фиксированная высота через dvh и стабильные размеры контейнеров.
Полная переработка мобильной версии. Не адаптация десктопа, а отдельная логика: другая навигация, другие отступы, другой порядок блоков.
Результат недели: Desktop 96-99, Mobile 85-87. С нуля.
Здесь второй практический вывод: performance - это не «оптимизация», это функциональность. Сайт с Lighthouse Mobile 0 - это сайт, которого нет для половины аудитории. И для Google, который с 2021 года ранжирует по mobile-first индексу.
Hub & Spoke: блог становится двигателем трафика
Третье решение недели 138 - архитектурное. До этого структура сайта была классической для SaaS: лендинг, страницы решений (/solutions/*), блог как приложение. Проблема: страницы решений дублировали друг друга, размывали семантику и не приносили трафик.
Мы перешли на модель Hub & Spoke: убрали страницы solutions полностью, а блог сделали главным двигателем органического трафика. Лендинг - конверсия. Блог - охват. Каждая статья (spoke) ведёт на тематический хаб или напрямую на лендинг. Позже эта логика выросла в кластерную структуру с pillar-статьями вроде обзора конструкторов ботов и отраслевых spoke-статей.
Именно это решение сделало возможной контент-машину недели 140: когда блог - центр SEO-стратегии, инвестиции в него оправданы. Кстати, те 22 битые ссылки на /solutions/*, которые мы чинили на неделе 139 - это как раз хвост этого переезда. Ретроспектива в обратном порядке иногда показывает и цену решений: снос архитектуры всегда оставляет осколки.
H1 как инструмент: выбор заголовка по данным
Микро-урок недели, который я до сих пор рассказываю знакомым фаундерам. Мы меняли H1 главной страницы дважды за неделю - и оба раза не по вкусовщине, а по данным.
Сначала H1 содержал «AI-ассистент» - таргетинг B2B-выдачи, где этот термин доминирует. Потом проверили частотность через Wordstat: запрос «ИИ-бот» имеет 95 838 показов в месяц против заметно меньших у «AI-ассистента». Переписали H1 под «ИИ-бот», а «AI-ассистент» оставили в meta title вторым ключом.
Правило, которое из этого родилось: H1 - не место для креатива. H1 - это самый частотный запрос, точно описывающий продукт. Креатив живёт в подзаголовке.
Параллельно: WABA-рассылки в продукте
Пока сайт переживал большую чистку, продуктовая команда выкатила WABA шаблонные рассылки - отправку утверждённых WhatsApp-шаблонов по базе клиентов прямо из CRM.
Технически это был синхронный релиз в пяти репозиториях за один день: ядро CRM, API платформы, фронтенд, воркеры рассылок и вебхук-сервис. Новый тип мессенджера в системе, 5-шаговый wizard с маппингом переменных шаблона на поля CRM, per-bot credentials для работы с несколькими WhatsApp-номерами.
Для бизнеса это значило: клиенты Botseller получили легальный канал массовых WhatsApp-рассылок через официальный Business API - без риска бана, который висит над серыми схемами. Подробнее про этот механизм мы писали в статьях про WhatsApp Business API и продажи в WhatsApp.
Заодно в биллинге появилась таблица пополнений баланса через Prodamus, а для Авито-клиентов - отдельное представление данных. Мелочи, из которых складывается зрелость продукта.
Был - стал: до и после недели 138
| Метрика | До (22 марта) | После (29 марта) |
|---|---|---|
| Статей в блоге | 578 | 10 |
| Lighthouse Desktop | 54 | 96-99 |
| Lighthouse Mobile | 0 | 85-87 |
| SEO-score (внутренний аудит) | 74 | 90+ |
| Страницы /solutions | Есть | Удалены (Hub & Spoke) |
| Страница /about с E-E-A-T | Нет | Есть |
| WABA-рассылки в продукте | Нет | Релиз в 5 репо |
Цифры недели 138
| Метрика | Значение |
|---|---|
| Статей удалено | 568 |
| Статей осталось | 10 |
| Доля удалённого контента | 98% |
| Трафик, который давали удалённые статьи | менее 3% |
| Lighthouse Mobile: рост | 0 → 85-87 |
| Коммитов в sitebs | 35 |
| Коммитов в продукт (WABA + биллинг) | 40 |
| Технических SEO-проблем исправлено | 13 |
Урок: рост начинается с вычитания
Главный вывод недели 138 - и, пожалуй, самый переносимый урок всей ретроспективы: прежде чем прибавлять, вычтите.
Мы могли пойти привычным путём: писать новые статьи поверх старых. 578 плюс 38 новых - 616 статей, звучит солидно. Но новый контент лёг бы на заражённый фундамент: сайтвайд-классификатор Google продолжил бы оценивать домен по массе тонкого легаси, crawl budget продолжил бы утекать на мёртвые страницы, и эффект от новых статей мы бы увидели через год, если вообще увидели бы.
Вместо этого - последовательность, которую теперь видно целиком в трёх выпусках ретроспективы:
- Неделя 138: снос. Удалить всё, что тянет вниз. Починить производительность. Определить архитектуру.
- Неделя 139: фундамент. Schema.org, SSR, оптимизация, AI-readiness.
- Неделя 140: строительство. 38 статей на чистой, быстрой, размеченной площадке.
Эта последовательность - не про SEO. Это универсальный паттерн работы с легаси в любой системе: коде, продукте, процессах, контенте. Сначала вычитание, потом сложение. В обратном порядке не работает: новые усилия тонут в старом балласте.
Если у вашего сайта есть история - WordPress-прошлое, старый блог, сотни страниц «для SEO» из 2020-х - начните с аудита по фреймворку выше. Может оказаться, что лучшая контент-инвестиция этого квартала - не написать ни одной новой статьи, а удалить триста старых.
А если хотите увидеть, что мы построили на расчищенном фундаменте - посмотрите быстрый старт Botseller или почитайте, как устроен наш ИИ-бот под капотом.
В следующем выпуске ретроспективы - неделя 137: последняя неделя «до» - как выглядела рутина стартапа, который ещё не знал, что через месяц станет контент-машиной.
Это серия «Ретроспектива Botseller» - путешествие от первого коммита до рабочего продукта. Читайте в любом порядке. Подписывайтесь на Telegram-канал, чтобы не пропустить новые выпуски.
FAQ
Что такое content pruning и зачем он нужен?
Content pruning - целенаправленное удаление или переработка страниц сайта, которые не приносят трафика, ссылок и конверсий. После Helpful Content Update Google оценивает качество домена сайтвайд: масса слабых страниц снижает ранжирование даже хороших. Прунинг убирает этот балласт.
Не упадёт ли трафик после удаления сотен страниц?
Сначала проверьте, сколько трафика реально дают кандидаты на удаление. В нашем случае 568 статей давали меньше 3% органики. Если страница приносит трафик - её не удаляют, а обновляют или объединяют. Удаляют только то, что не работает: тонкий контент без кликов, ссылок и конверсий.
Почему для удалённых страниц лучше отдавать 410, а не 404?
Код 404 означает «не найдено, возможно временно» - Google продолжает переобходить такие URL месяцами, тратя crawl budget. Код 410 означает «удалено навсегда» - страница выпадает из индекса заметно быстрее, и бот перестаёт к ней возвращаться.
Как понять, какие страницы удалять, а какие переписывать?
Работает матрица из четырёх факторов: трафик за 12 месяцев, внешние бэклинки, качество текста и живость поискового интента. Есть трафик - оставить или обновить. Нет трафика, но есть бэклинки - объединить с сильной статьёй через 301. Нет ничего, но тема востребована - переписать. Нет ничего и тема мёртвая - удалить с 410.
Сколько ждать эффекта от content pruning?
Реалистичный срок - 4-8 недель: Google нужно переобойти сайт, выкинуть удалённые URL из индекса и пересчитать сайтвайд-сигналы качества. В нашем случае рост органики стал заметен через полтора месяца, вместе с эффектом от новых статей.
Влияет ли скорость сайта на SEO так же сильно, как контент?
Это разные уровни одной воронки. Core Web Vitals - фактор ранжирования, но слабее контентных сигналов. Однако Lighthouse Mobile 0 - это не «медленный сайт», а нерабочий: Google с 2021 года индексирует mobile-first, и мёртвая мобильная версия обнуляет остальные усилия.
Что делать со страницами услуг при переходе на модель Hub & Spoke?
Проверить каждую по той же матрице. Страницы решений часто дублируют друг друга и каннибализируют семантику. Если они не приносят трафика - их содержимое логичнее объединить в тематические статьи-хабы, а конверсию сосредоточить на главной. Не забудьте про редиректы и чистку внутренних ссылок - битые ссылки на удалённые разделы придётся чинить потом.
