Проект: Slangbook.ru
Тип: информационный словарь
CMS: WordPress + ACF
Старт разработки: 2 апреля 2026 года
Стартовый объём: 100 опубликованных слов
Текущий объём: 5 122 слова
Основной канал роста: органический поиск
Ссылочное продвижение: покупные ссылки не использовались

За первые четыре месяца Slangbook.ru вырос со 100 словарных страниц до более чем 5 000. При этом классическое семантическое ядро заранее не собиралось: новые страницы добавлялись не только исходя из частотности запроса, но и как элементы общей структуры словаря.

На момент замера Google Search Console зафиксировал 947 кликов и 467 755 показов, а почти 90% кликов Google приходилось именно на страницы отдельных слов.

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

Что такое Slangbook.ru

Slangbook.ru — информационный сайт со страницами отдельных слов, выражений и терминов.

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

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

Кроме словарных карточек на сайте появились информационные статьи, в том числе по русскому языку. В мае было опубликовано 30 таких материалов, а сейчас их около 70.

Первоначально Slangbook создавался как площадка для тестирования SEO-механик. После появления первых посетителей стало понятно, что сама модель словаря способна генерировать поисковый спрос, и проект начали развивать как полноценный информационный ресурс.

Почему SEO словаря отличается от обычного контентного сайта

В классическом информационном проекте работа часто строится так:

запрос → частотность → кластер → статья → продвижение.

Для словаря эта модель работает не всегда.

У отдельного слова может быть совсем небольшой спрос. При этом оно может быть важно как часть общей предметной области:

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

Поэтому на Slangbook мы решили не оценивать каждую страницу исключительно через её индивидуальную частотность.

Если термин имеет самостоятельное значение и место в структуре словаря, его можно добавить даже при небольшом прогнозируемом поисковом спросе.

Это не означает, что любая массовая генерация страниц полезна для SEO. Google отдельно предупреждает о риске scaled content abuse, когда большое число страниц создаётся прежде всего ради манипуляции поисковой выдачей и не приносит дополнительной ценности пользователю. Для автоматически создаваемого контента Google рекомендует сохранять фокус на точности, качестве и полезности.

Поэтому задача Slangbook заключалась не просто в увеличении количества URL.

Нужно было построить связанный словарь, а не каталог однотипных SEO-заглушек.

Исходное состояние

Работа над проектом началась 2 апреля 2026 года.

Первые словарные страницы массово появились уже 9–10 апреля. На старте было опубликовано около 100 слов.

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

По данным Google Search Console:

Дата	Клики	Показы
12.04.2026	0	12
13.04.2026	0	16
14.04.2026	0	90
15.04.2026	2	275
16.04.2026	4	385
17.04.2026	6	463

Таким образом:

• первые показы появились через 10 дней после начала разработки;
• первые переходы из Google — через 13 дней.

Для молодого сайта без закупленного ссылочного это стало первым подтверждением самой гипотезы: даже страницы обычных слов способны получать поисковый спрос.

Место для скриншота: GSC, начало графика 12–17 апреля.

Главная SEO-задача

На старте у сайта не было практически ничего из того, что обычно облегчает продвижение крупного информационного проекта:

• истории домена как развитого контентного ресурса;
• большого существующего массива страниц;
• накопленных поисковых данных;
• развитого внешнего ссылочного профиля;
• готовой тематической структуры.

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

Поэтому задача формулировалась не как:

«занять первое место по нескольким главным запросам».

Она была другой:

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

Масштабирование семантики без классического СЯ

Отдельное большое семантическое ядро перед запуском не собиралось.

Первоначальная тысяча слов появилась скорее исследовательским способом: выбирались интересные термины из разных тематик.

Мы не проверяли частотность каждого слова перед его добавлением.

Это было сознательное решение.

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

После запуска список новых слов начал расширяться через уже опубликованные страницы.

AI-ассистент определяет в том числе:

• синонимы;
• антонимы;
• тематические связи.

Если найденного связанного слова на сайте ещё нет, оно может стать кандидатом для дальнейшего наполнения.

Получается цикл:

исходное слово
→ связанные сущности
→ новые кандидаты
→ новые страницы
→ новые связи
→ следующий слой словаря.

Мы не называем это доказанным фактором роста позиций существующих страниц. Но как механизм расширения структуры и внутренней перелинковки система работает фактически.

Архитектура словаря

Проект работает на WordPress.

Для собственной структуры используются ACF и дополнительные типы сущностей.

В архитектуре есть:

• слова;
• пословицы;
• словари;
• темы;
• буквы;
• обычные информационные статьи.

Страница слова может быть связана сразу с несколькими другими элементами системы.

Вместо плоской структуры:

слово → текст

получается граф:

слово
↕ синонимы
↕ антонимы
↕ омонимы
→ тема
→ словарь
→ другие слова темы
→ статьи.

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

Как работали со страницами под НЧ-запросы

Мы не пытались заранее определить, какие из нескольких тысяч терминов обязательно принесут трафик.

Страница создаётся даже для низкочастотного термина, если он нужен в структуре словаря.

Дальше фактический поисковый спрос определяют поисковые системы.

Это важное отличие от стандартного подхода:

не прогнозировать трафик для каждой страницы → построить тематически связанный массив → смотреть реальные данные GSC.

Результат показал, что модель действительно генерирует распределённый long tail.

В выгрузке первых 1 000 URL Google Search Console:

• 929 URL относятся к /word/;
• они получили 851 клик;
• получили 391 311 показов;
• как минимум 440 различных словарных страниц уже получили хотя бы один переход.

Всего сайт получил 947 кликов.

Следовательно, на страницы слов приходится:

851 / 947 = 89,9% всех кликов Google.

То есть трафик проекта не сконцентрировался исключительно на главной или нескольких статьях. Он действительно распределяется по словарному массиву.

Место для диаграммы: 89,9% Google-кликов → /word/.

Как не превращать массовый словарь в thin content

Для этого проекта мы бы не стали заявлять, что «полностью решили проблему thin content». Google не предоставляет такого статуса, а сам факт индексации страницы не является доказательством её высокого качества.

Но были заложены ограничения, которые не позволяют свести автоматизацию к схеме:

ключ → два предложения → публикация.

Контент создаётся AI-агентом, который предварительно работает с информацией по слову.

Если достаточной информации о термине нет, страница не публикуется.

Карточка слова может включать:

• краткое определение;
• расширенное значение;
• разные значения;
• примеры;
• происхождение;
• синонимы;
• антонимы;
• омонимы;
• тематические связи;
• связанные материалы.

Например, публичная карточка игрового значения «дым» содержит не только определение, но и сценарии использования и примеры.

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

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

Метатеги и шаблонизация

Когда количество URL измеряется тысячами, вручную вести SEO Title, Description и технические параметры каждой страницы практически невозможно.

В теме Slangbook реализована собственная работа с:

• SEO Title;
• Description;
• canonical;
• метаданными отдельных записей;
• метаданными таксономий;
• пагинацией.

Для словарных страниц также используется структурированное описание сущности через schema.org.

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

Внутренняя перелинковка

Перелинковка — один из ключевых элементов проекта.

Синонимы и антонимы подбираются AI-ассистентом.

При этом связанная сущность необязательно должна быть опубликована в этот же момент.

Если слово появится позже, связь может быть активирована после его публикации.

Также предусмотрены обратные связи.

Например, если система связывает две сущности, можно формировать навигацию не только:

A → B,

но и:

B → A.

Дополнительно используются:

• другие слова из той же темы;
• связи через словарь;
• тематические статьи.

Жёсткого глобального лимита на количество таких связей сейчас нет.

С точки зрения Google здесь важен не сам объём ссылок, а чтобы ссылки были обычными crawlable-ссылками и имели понятный контекст.

Что сделали со статьями

Одних карточек слов недостаточно для покрытия всех типов информационного интента.

Поэтому параллельно развивается обычный информационный раздел.

В мае было опубликовано 30 статей по русскому языку, сейчас их около 70.

Статьи связываются со словарной частью через темы и словари.

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

Эта же модель потенциально применима не только к словарному сайту.

Например, на игровом проекте это может быть:

игра → персонаж → предмет → механика → термин → гайд.

На техническом:

технология → компонент → термин → характеристика → ошибка → инструкция.

Смысл не в том, чтобы добавить раздел /wiki/ ради SEO, а в том, чтобы отдельно описывать реальные сущности предметной области и строить между ними навигацию.

Техническое SEO WordPress

Массовое SEO здесь потребовало не только настройки метатегов.

С самого начала проект размещался на VPS и оптимизировался под большое число однотипных публичных страниц.

В теме и дополнительных модулях реализованы:

• свои шаблоны словарных страниц;
• работа с canonical;
• SEO-метатеги;
• schema.org;
• sitemap index;
• отдельные sitemap для разных типов контента;
• разделение слов по sitemap примерно по 1 000 URL;
• автоматизация тем и словарей;
• алиасы;
• система обратных связей;
• очередь публикации.

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

Скорость массового шаблона

Мы отдельно проверяли не только главную, но и типовую страницу слова.

Для /word/dym/ Lighthouse на 12 августа показал:

Mobile

Метрика	Значение
Performance	100
FCP	0,9 с
LCP	1,2 с
TBT	0 мс
CLS	0
Speed Index	0,9 с

Desktop

Метрика	Значение
Performance	100
FCP	0,3 с
LCP	0,3 с
TBT	0 мс
CLS	0
Speed Index	0,4 с

В отчёте GSC Core Web Vitals:

• 132 мобильных URL — Good;
• URL «Needs improvement» — 0;
• URL «Poor» — 0.

Место для двух скриншотов: Lighthouse mobile + desktop страницы слова.

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

Индексация нескольких тысяч URL

На момент замера Google Search Console показывал:

• 4 653 проиндексированных URL;
• 649 непроиндексированных.

Всего Google знал о 5 302 URL.

Доля проиндексированных:

4 653 / 5 302 = 87,8%.

Причины исключения:

Причина	URL
Обнаружена, не проиндексирована	482
Просканирована, но пока не проиндексирована	139
404	20
Duplicate / canonical	5
robots.txt	2
другая 4xx	1

Особенно показателен первый статус.

Из 482 URL в группе «Обнаружена, не проиндексирована» 481 URL — страницы слов.

То есть при ускорении публикации появляется заметный хвост новых словарных страниц, о которых Google уже знает, но которые ещё не прошли полный процесс обработки.

Здесь мы намеренно не используем громкую формулировку «сайту не хватает crawl budget». Специальное руководство Google по crawl budget в первую очередь относится к намного более крупным сайтам. Для Slangbook корректнее говорить о скорости discovery, crawling и indexing растущего массива URL.

Место для скриншота: GSC «4 653 проиндексировано / 649 не проиндексировано».

IndexNow и ускорение обнаружения страниц

На проекте используется собственный WordPress-плагин Findex for IndexNow.

Плагин опубликован в официальном каталоге WordPress.org и позволяет отправлять новые и обновлённые URL в Яндекс и Bing через IndexNow, автоматически работать с опубликованным контентом, отправлять URL вручную, собирать адреса из sitemap и вести журнал отправок.

Важно разделять механизмы:

• для Google основным массовым способом обнаружения остаются внутренние ссылки и sitemap;
• IndexNow используется для поддерживающих его поисковых систем.

То есть в кейсе мы не будем писать, что IndexNow ускоряет индексацию Google.

Автоматизация публикации

К 5 000 страницам невозможно относиться как к 5 000 независимым редакционным задачам.

Поэтому для Slangbook был построен собственный конвейер.

Упрощённо он выглядит так:

список кандидатов
↓
очередь
↓
собственный софт + ZennoPoster
↓
AI-агент исследует термин
↓
формируются данные карточки
↓
подбираются синонимы и антонимы
↓
назначаются темы и словари
↓
проверяется существование слова
↓
при недостатке данных публикация отменяется
↓
WordPress получает запись
↓
запись ставится в публикационную очередь.

С августа задан темп:

100 слов в сутки.

В технической реализации интервал составляет примерно:

14 минут 24 секунды между публикациями.

Это сделано не для того, чтобы объявить такой интервал «SEO-фактором». Задача проще: не публиковать одномоментно огромный массив и иметь управляемую очередь развития проекта.

Автоматизация не заканчивается публикацией

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

Для Slangbook был сделан отдельный механизм обработки:

• тем;
• словарей;
• букв;
• алиасов;
• неизвестных значений;
• обратных связей.

В результате ручная работа не масштабируется линейно вместе с количеством страниц.

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

Это принципиально для проекта.

При росте со 100 до 5 000+ слов объём ручной работы не вырос в 50 раз.

Оптимизация аналитики

Для Яндекс Метрики используется ещё один собственный WordPress-плагин — Vagizov Metrika Loader.

Он позволяет подключать счётчик и выбирать режим его загрузки, включая загрузку после пользовательского взаимодействия или с задержкой. В официальном каталоге WordPress отдельно указано, что это компромисс между производительностью и полнотой аналитики: чем позже загружается счётчик, тем выше риск не зафиксировать очень короткие визиты.

Для информационного сайта это особенно актуально.

Пользователь словаря иногда может:

1. открыть страницу;
2. увидеть определение;
3. получить нужный ответ;
4. уйти через несколько секунд.

Поэтому короткая сессия сама по себе не доказывает неудовлетворённость пользователя.

Результаты Google

На текущем этапе основной массив доказательной аналитики получен из Google Search Console.

Суммарно:

• 947 кликов;
• 467 755 показов;
• CTR — около 0,2%;
• средняя позиция — 12,4.

Чтобы не сравнивать перекрывающиеся интервалы, взяли два одинаковых независимых периода по 28 дней.

Период	Клики	Показы
12.04–09.05	86	38 069
13.07–09.08	350	191 815
Изменение	+307%	+404%

Первый период приходится на запуск молодого сайта, поэтому эти проценты нельзя интерпретировать как результат одной конкретной SEO-доработки.

Они показывают другое:

по мере развития проекта поисковая видимость и органические переходы росли вместе с расширением словарного массива.

При этом 89,9% всех кликов Google приходилось именно на /word/.

Место для главного скриншота кейса: граф GSC за весь период.

Что происходит в Яндексе

По Яндекс Метрике за период с 1 апреля по 11 августа:

• 2 365 визитов всего;
• 2 151 посетитель;
• 3 434 просмотра;
• 1 175 визитов из поисковых систем;
• среднее время — 57 секунд;
• глубина просмотра — 1,45;
• отказы — 57%.

Однако 1 175 визитов нельзя назвать трафиком из Яндекса: показатель объединяет все поисковые системы.

Поэтому отдельный рост Яндекса в этот кейс сейчас не приписываем.

IndexNow для Яндекса и Bing подключён через Findex, но его наличие также не является доказательством, что конкретный рост вызван именно отправкой URL.

Ошибка первой архитектуры: омонимы

В начале проекта разные значения одинакового слова планировалось размещать на отдельных URL.

Поэтому в старом массиве появились пары вроде:

• /word/dym/;
• /word/dym-2/;
• /word/pan/;
• /word/pan-2/;
• /word/chek/;
• /word/chek-2/.

Публично обе версии «дыма» существуют и сейчас: одна описывает игровой термин, другая — обычное значение.

Позже подход изменили.

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

Старые страницы пока не объединяем и массовую карту 301 не строим.

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

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

Что получилось: было → стало

Показатель	На старте	Август 2026
Опубликованные слова	100	5 122
Статьи	практически отсутствовали	около 70
Google показы	первые 12	467 755 суммарно
Google клики	первые 2	947 суммарно
Клики за сопоставимый 28-дневный период	86	350
Показы за 28 дней	38 069	191 815
URL в индексе Google	—	4 653
Ручное обслуживание автоматизации	—	около 1 часа в неделю
Темп новых слов	вручную / стартовый массив	100 в сутки

Главное здесь даже не рост числа страниц с 100 до 5 122.

Главный результат:

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

Что этот эксперимент показал

Первоначально Slangbook был SEO-экспериментом.

Через несколько месяцев стало понятно, что сама модель имеет более широкое применение.

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

Можно строить отдельный справочный слой.

Для игрового сайта:

игры → механики → герои → предметы → термины → гайды.

Для технического проекта:

оборудование → компоненты → характеристики → технологии → термины → инструкции.

Для профессионального сайта:

услуга → технология → материал → термин → проблема → решение.

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

Поэтому такая архитектура имеет смысл только тогда, когда сущности действительно нужны пользователю и связаны с основной тематикой проекта.

Что делаем сейчас

Проект находится не в финальной точке.

Сейчас продолжаются:

• публикация новых слов;
• расширение связей через синонимы и антонимы;
• работа с алиасами;
• развитие тематических словарей;
• развитие статей;
• наблюдение за индексированием;
• анализ запросов и страниц через GSC.

Текущая цель проекта — не подключить рекламу как можно раньше.

Монетизацию пока сознательно не запускаем.

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

Выводы

Slangbook.ru начинался не как готовый большой словарь, а как SEO-эксперимент со 100 опубликованными словами.

За несколько месяцев он вырос до 5 122 слов, причём расширение контента, классификация, перелинковка и публикационная очередь в значительной степени автоматизированы.

При этом:

• покупные ссылки не использовались;
• классическое СЯ перед запуском не собиралось;
• частотность каждого слова не является обязательным фильтром;
• первые показы Google появились через 10 дней после начала разработки;
• первые клики — через 13 дней;
• сайт получил 467 755 показов и 947 кликов Google;
• 89,9% этих кликов пришлись на словарные страницы;
• Google проиндексировал 4 653 из 5 302 известных ему URL;
• типовая страница слова показывает Lighthouse Performance 100;
• новые слова публикуются со скоростью около 100 страниц в сутки;
• ручное обслуживание автоматизированной структуры занимает примерно час в неделю.

Для нас главный вывод этого проекта не в том, что «надо генерировать тысячи страниц».

Он другой:

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

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