Prompotolok.ru — коммерческий B2B-каталог потолочных решений и комплектующих с региональным продвижением.

Когда проект пришёл к нам в мае 2026 года, это уже был крупный действующий сайт: около 500 товаров, 165 SEO-посадочных, 23 региональные версии и накопленная за годы техническая история.

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

В результате к моменту нашего подключения SEO-задача выглядела не как:

собрать семантику → написать тексты → оптимизировать метатеги.

Сначала нужно было привести в управляемое состояние сам сайт.

Только в истории обхода Яндекса на основном домене находилось более 50 тысяч уникальных URL. Почти 49 тысяч из них содержали query-параметры. К этому добавлялись старые фильтры, canonical, редиректы, пагинация, технические адреса и региональная структура.

Масштаб проекта делал ручной подход практически неприменимым.

Поэтому SEO постепенно превратилось в систему из четырёх связанных направлений:

SEO-стратегия → архитектура каталога → WordPress-разработка → автоматизация.

Проект в цифрах

Параметр	На старте / в ходе работ
Регионов	23
Товаров на старте	около 500
SEO-посадочных на старте	165
Уникальных URL в истории обхода основного домена	более 50 тыс.
Query URL	почти 49 тыс.
Новая SEO-структура	более 14 тыс. базовых посадочных
Созданных правил редиректов	более 50 тыс.
Товаров на текущем этапе	более 560
Собственных шаблонов сайта	около 30
Performance mobile главной	47 → 96
LCP в лабораторном mobile-тесте	8,3 → 2,1 с

---

С какой точки начинали

Проект попал к нам 7 мая 2026 года.

Сначала мы провели первичный технический аудит и оценили объём работ. Фактическая разработка началась 12 мая.

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

С 12 по 28 мая основной задачей была перестройка самого сайта.

Только после её завершения, с 1 июня, начался отдельный системный этап SEO-продвижения в Яндексе.

Хронология проекта

Дата	Этап
7 мая	получили проект, провели первичный аудит
12 мая	начали техническую переработку
12–28 мая	пересобрали сайт и каталог
1 июня	начали системную SEO-работу с Яндексом
начало июля	подключили IndexNow
вторая половина июля	получили доступы ко всем региональным свойствам Яндекс Вебмастера
31 июля	перенесли проект на VPS
август	начали отдельный активный этап работы с Google

Почему сначала пришлось переписать сайт

На момент начала работ проект использовал WordPress + WooCommerce.

При этом классическая ecommerce-модель бизнесу не требовалась. На сайте не было полноценного процесса покупки с личным кабинетом и стандартным checkout.

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

На старой версии одновременно работали:

• WooCommerce;
• WoodMart;
• WPBakery;
• фильтры каталога;
• SEO-плагины;
• отдельные решения для schema.org;
• плагины редиректов;
• кеширование;
• кастомные плагины;
• код нескольких предыдущих разработчиков.

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

На фронтенде одновременно загружались ресурсы WoodMart, WPBakery, WooCommerce Blocks, jQuery, WooCommerce add-to-cart, Font Awesome и другие зависимости.

При большом каталоге это означало сразу несколько проблем:

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

Что сделали вместо очередной оптимизации старой темы

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

За две недели технического этапа:

• убрали WooCommerce;
• отказались от WoodMart;
• полностью убрали WPBakery;
• отказались от page builder;
• переписали frontend;
• переработали JavaScript;
• сделали собственные шаблоны страниц;
• перевели шрифты на локальное подключение;
• добавили preload шрифтов;
• начали массовый перевод изображений в WebP;
• переработали каталог;
• перенесли необходимые функции в собственную реализацию.

Сейчас сайт состоит примерно из 30 специализированных шаблонов.

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

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

После пересборки сайта начался второй уровень сложности — URL

Технический аудит самого WordPress был только началом.

После этого мы выгрузили данные Яндекс Вебмастера и историю обхода основного домена.

Объём оказался следующим.

История обхода Яндекса

Показатель	Значение
Всего строк	50 451
Уникальных URL	50 422
Query URL	48 920
URL с мусорными параметрами	48 705
Ошибки 4xx / 5xx	233
Редиректы	586
Технические URL	284

Отдельно встречались тысячи адресов:

• add-to-cart;
• фильтровых URL;
• shop_view;
• per_page;
• per_row;
• других GET-параметров;
• старых SEO-фильтров;
• страниц пагинации.

В архиве Яндекс Вебмастера на контрольной точке также находилось более 10 тысяч проблемных URL, включая более 9 тысяч со статусом NOT CANONICAL.

Масштаб уже не позволял разбирать такие данные как обычный список ошибок.

Нужно было построить правила обработки целых классов URL.

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

Большая часть старых адресов действительно была техническим мусором.

Но не все.

За годы работы фильтры сайта успели сформировать URL, которые описывали реальные товарные комбинации:

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

Например, один старый URL мог соответствовать:

кассетным потолкам конкретного бренда из определённого материала.

Если перенаправить его просто на общую категорию «Кассетные потолки», технически 301 будет настроен.

Но смысл старого адреса станет значительно шире.

При десятках тысяч URL такая миграция означала бы массовое снижение точности посадочных.

Поэтому вместо единого правила:

старый URL → категория

мы начали восстанавливать смысл старой структуры.

История Яндекса стала основой новой SEO-архитектуры

При создании основной массы новых SEO-посадочных мы использовали:

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

То есть новая архитектура строилась не как математическая генерация всех возможных сочетаний характеристик.

Основой стала фактическая URL-история сайта.

Например:

/kassetnye-potolki/product-material-mineral-fiber/product-product-ceramaguard/

или:

/grilyato/product-vid-grilyato-zhalyuzi/product-vysota-profilya-40mm/

Такие URL уже отражают семантическую структуру:

категория → характеристика → значение → характеристика → значение.

Какие параметры участвуют в SEO-посадочных

В зависимости от товарной группы используются:

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

Это даёт огромный потенциальный набор комбинаций.

Но далеко не каждая из них превращается в страницу.

Как решали, создавать страницу или нет

Для новой SEO-посадочной должны выполняться три основных условия:

1. Под комбинацию существуют товары.
2. У комбинации есть самостоятельный семантический смысл.
3. Она не создаёт очевидный дубль существующего интента.

Если товаров нет, пустая страница не создаётся.

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

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

Каталог и поисковую структуру разделили

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

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

Мы разделили сущности.

Теперь:

каталог нужен для навигации пользователя;

бренды являются отдельной сущностью;

SEO-посадочные существуют для самостоятельных поисковых интентов.

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

Как восстанавливали старые URL

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

Упрощённо система работает так:

старый URL

↓

определяем его тип

↓

выделяем категорию и характеристики

↓

ищем существующую SEO-посадочную

↓

если она есть — настраиваем 301

↓

если посадочной нет, но есть товары и смысл — создаём новую

↓

если комбинация слишком узкая — ищем более широкую цель

↓

если сущность удалена окончательно — 410

Разные виды URL обрабатываются отдельно.

Например:

• карточки товара;
• технические параметры;
• категорийные URL;
• SEO-фильтры;
• служебные страницы.

Это снижает риск ситуации, когда технический параметр товара ошибочно превращается в поисковую посадочную.

Более 50 тысяч правил редиректов

За первые два месяца работы было создано более 50 тысяч правил обработки старых URL.

Количество редиректов заметно превышает количество SEO-посадочных.

Причина — нормализация.

Одна новая страница может стать конечной точкой для:

• старого GET URL;
• старого Premmerce URL;
• URL с лишним техническим префиксом;
• старой пагинации;
• нескольких вариантов одних и тех же фильтров.

Получается модель:

несколько старых адресов → одна каноническая поисковая сущность.

Это уменьшает количество вариантов одного и того же контента и постепенно переводит историческую структуру в новую систему URL.

Старые SEO-посадочные не пришлось уничтожать

На момент начала работ уже существовало 165 SEO-посадочных.

Мы сохранили их и встроили в новую архитектуру.

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

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

Как выросла структура посадочных

За первые месяцы новая SEO-система выросла до более 14 тысяч базовых посадочных.

Одна такая страница может объединять:

• категорию;
• бренд;
• одну или несколько характеристик;
• соответствующий ассортимент;
• SEO-контент;
• внутренние связи.

Региональный слой применяется уже поверх базовой страницы.

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

Как устроена SEO-посадочная

Страница содержит не только товарную сетку и короткий SEO-абзац.

В структуре используются:

• основной текст;
• H2-разделы;
• списки;
• таблицы;
• FAQ;
• товарная выдача;
• внутренняя перелинковка.

Например, текст может отдельно раскрывать:

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

Изображениями страницы служат реальные товары из текущей выборки.

Как масштабировали производство контента

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

Для этого используется связка:

AI-ассистент + собственный генератор + ZennoPoster.

Автоматизация включается после определения самой SEO-сущности.

То есть сначала система знает:

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

И только потом генерируется контент.

Так техническая логика страницы не зависит от решения AI.

Перелинковку пришлось автоматизировать вместе с генерацией

Массовое создание посадочных сразу создаёт вторую задачу:

как не получить тысячи страниц-сирот?

Страница, которая существует только в sitemap, остаётся слабым элементом внутренней структуры.

Поэтому перелинковка строится автоматически через связанные ID.

Это создаёт контролируемый граф внутренних переходов между:

• товарами;
• категориями;
• посадочными;
• связанными сущностями.

Для товаров визуальные рекомендации и SEO-перелинковка разделены.

Случайное появление карточки в карусели не считается достаточным основанием считать страницу нормально встроенной в структуру.

От /page/2/ отказались полностью

При тысячах посадочных классическая пагинация могла создать ещё один крупный слой URL.

Например:

/page/2/

/page/3/

/page/4/

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

Поэтому от индексируемой пагинации отказались.

Первая выборка товаров загружается вместе со страницей.

Следующие товары подгружаются через AJAX.

Для пользователя каталог продолжает работать как обычный длинный листинг, но отдельные /page/N/ больше не нужны.

Старые пагинационные SEO-адреса переводятся на базовые страницы.

Как устроено региональное масштабирование

Все 23 региона работают на общей кодовой базе и общем каталоге.

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

У региональных страниц собственные canonical.

Для каждого host также формируются соответствующие sitemap и robots.

Это позволяет управлять общей SEO-системой централизованно, а не поддерживать десятки независимых WordPress-сайтов.

Sitemap и robots тоже пришлось вынести в собственную систему

Стандартной карты сайта для такой архитектуры оказалось недостаточно.

Sitemap должен учитывать:

• текущий host;
• обычные страницы;
• товары;
• категории;
• SEO-посадочные;
• изменения структуры.

Поэтому используется собственный host-aware генератор sitemap.

При изменении контента карты могут пересобираться автоматически.

Robots также работает с актуальной картой текущего host.

Переобход Яндекса превратился в очередь

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

Вручную отправлять такой объём через Вебмастер невозможно.

Поэтому сделали собственную очередь работы с API Яндекс Вебмастера.

Принцип:

создана страница → очередь

страница изменена → снова очередь

получаем доступную квоту → отправляем URL

квота закончилась → оставшиеся URL ждут следующего цикла

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

На переобход отправляется только готовая структура

Сам факт существования старого URL ещё не означает, что его нужно немедленно показывать Яндексу повторно.

Перед переобходом проверяется:

• существует ли целевая посадочная;
• настроен ли корректный редирект;
• готов ли чистый конечный URL.

Получается последовательность:

сначала исправление → потом переобход.

Это намного эффективнее, чем повторно отправлять поисковому роботу те же технические адреса, которые ещё не приведены в порядок.

IndexNow подключили в начале июля

Для новых SEO-посадочных дополнительно подключили IndexNow.

Его задача — быстрее сообщать о появлении новых URL.

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

Google потребовал отдельного подхода

К августу отдельный пласт работ начался с Google.

Здесь сложность выросла по двум причинам.

Первая — объём исторических URL.

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

Вторая — ограничения Google Search Console.

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

Поэтому полную картину приходится восстанавливать по совокупности:

• собственных аудитов;
• структуры сайта;
• URL-паттернов;
• данных Search Console.

На таком масштабе ручные таблицы перестали работать

Пока URL несколько сотен, значительную часть работы можно вести в Excel.

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

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

Основные модули

Инструмент	Задача
Sitemap + Robots	управление картами сайта
Redirect Manager	301 / 410 и аудит правил
Recovery	восстановление исторических URL
История обхода Яндекса	анализ фактического поведения робота
Архив Вебмастера	анализ статусов индексирования
Recrawl Queue	очередь API переобхода
Duplicate Audit	дубли Title, Description, H1, canonical
Content Audit	контент и ACF
Crawl Budget Audit	технический обход
Structure Audit	анализ шаблонов
Controlled Linking	внутренняя перелинковка

Это внутренний инструментарий, который адаптируется под конкретную структуру проекта.

Crawl Budget стал отдельным объектом контроля

При десятках тысяч исторических адресов недостаточно знать:

какие URL находятся в индексе?

Нужно понимать:

на что поисковый робот продолжает расходовать обход?

Для этого отдельно анализируются:

• query URL;
• 404;
• редиректы;
• цепочки 301;
• внутренние ссылки на технические адреса;
• расхождения с sitemap;
• повторно обходящиеся мусорные URL.

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

Поэтому исправляется не только ответ сервера, но и источник появления URL внутри сайта.

Дубли и потенциальная каннибализация

При тысячах посадочных дубли нужно искать программно.

Отдельный аудит проверяет:

• Title;
• Description;
• H1;
• canonical;
• похожие страницы;
• похожий контент;
• посадочные с пересекающейся структурой.

Это не означает автоматическое удаление похожих страниц.

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

Что происходит с товаром после снятия с производства

Для каталога это отдельная SEO-задача.

Карточка товара может годами находиться в поиске, получать ссылки и трафик.

Поэтому прекращение производства модели не приводит к автоматическому удалению страницы.

Карточка сохраняет:

• URL;
• характеристики;
• описание;
• изображения;
• цену, если она заполнена;
• связанные товары.

Меняется коммерческое состояние страницы.

Вместо количества, корзины и быстрого заказа пользователь видит:

«Товар снят с производства».

В Product schema также передаётся состояние Discontinued.

Страница продолжает отвечать на запрос о конкретной модели и одновременно ведёт пользователя дальше к актуальному ассортименту.

Производительность: с 47 до 96 на mobile

Перестройка архитектуры заметно изменила и технические показатели главной страницы.

PageSpeed mobile

Показатель	До	После
Performance	47	96
FCP	5,5 с	1,5 с
LCP	8,3 с	2,1 с
TBT	430 мс	50 мс
CLS	0,001	0
Speed Index	8,4 с	4,3 с
Accessibility	82	100
SEO	92	100

Это лабораторные мобильные замеры PageSpeed.

Здесь важен не только итоговый балл, а объём изменений, который за ним стоит.

Что именно поменяли в производительности

Комплекс работ включал:

• отказ от WooCommerce;
• отказ от тяжёлой темы;
• удаление page builder;
• переписывание JavaScript;
• специализированные шаблоны;
• локальные шрифты;
• preload;
• WebP;
• оптимизацию LCP-изображений;
• сокращение лишних frontend-зависимостей.

Для ключевых изображений также используется отдельная логика загрузки: фиксированные размеры, loading="eager" и повышенный fetchpriority.

То есть производительность стала следствием архитектурного упрощения, а не настройки ещё одного кеширующего плагина.

Почему сайт переехал на VPS

По мере роста SEO-системы увеличивался и серверный объём работы.

К этому моменту одновременно существовали:

• тысячи посадочных;
• более 50 тысяч правил редиректов;
• фоновые очереди;
• генерация sitemap;
• собственные аудиты;
• API-интеграции;
• серверный кеш.

Переезд на VPS позволил перенести массив редиректов с уровня WordPress на уровень веб-сервера.

Это особенно важно при большом количестве старых URL.

Вместо:

Nginx → PHP → WordPress → поиск правила → 301

часть запросов можно завершить значительно раньше:

Nginx → 301

Дополнительно было настроено серверное кеширование.

То есть серверная инфраструктура стала частью SEO-архитектуры.

Первый результат после перестройки

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

По отношению к маю:

Метрика поискового трафика	Динамика
Визиты из поиска	около +16%
Посетители из поиска	около +24%
Просмотры из поиска	рост

При этом общий трафик сайта за тот же период снизился из-за динамики других источников.

Поисковый канал двигался отдельно от общего трафика.

Это первая измеримая точка нового этапа проекта.

Ссылочное продвижение поставили на паузу

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

На первом этапе дальнейшую закупку остановили.

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

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

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

Что менялось уже по ходу работы

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

Генерация посадочных

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

Редиректы

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

Региональное SEO

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

Каннибализация

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

Было → стало

Было	Стало
WooCommerce в каталоге без полноценной ecommerce-модели	собственная каталожная реализация
WoodMart + WPBakery	около 30 собственных шаблонов
внешний Google Fonts	локальные WOFF2 + preload
несколько пересекающихся SEO-механизмов	единый собственный SEO-контур
десятки тысяч исторических URL	классификация и управляемая маршрутизация
GET-фильтры	нормализованные SEO-посадочные
массовый редирект на категории	сопоставление с релевантными целями
/page/N/	AJAX-подгрузка
ручной переобход	API-очередь
ручные выгрузки	собственные аудиторы
сотни страниц без нормальных входящих связей	контролируемая перелинковка
удаление товара как возможный тупик	отдельный lifecycle снятого товара
Performance 47	Performance 96
LCP 8,3 с	LCP 2,1 с
SEO как набор отдельных работ	SEO как управляемая техническая система

Что оказалось самым сложным

Самая сложная часть проекта — не генерация тысяч страниц.

Главная сложность была в одновременной работе с двумя противоположными задачами.

С одной стороны, нужно было убрать огромный технический хвост:

• GET-параметры;
• дубли;
• лишнюю пагинацию;
• старые редиректы;
• crawl traps.

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

Часть старых URL соответствовала реальному товарному спросу и уже участвовала в поисковой структуре.

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

исторический URL

↓

классификация

↓

определение его семантики

↓

поиск существующей цели

↓

при необходимости создание посадочной

↓

редирект

↓

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

↓

sitemap

↓

переобход

При десятках тысяч URL каждый этап должен работать системно.

Текущее состояние проекта

Сейчас Prompotolok.ru — это уже не каталог, в котором SEO существует поверх WordPress как набор независимых плагинов.

SEO встроено в архитектуру проекта.

Система управляет:

• тысячами посадочных;
• десятками тысяч исторических маршрутов;
• региональными версиями;
• sitemap;
• robots;
• canonical;
• переобходом;
• внутренними связями;
• техническим состоянием контента;
• дублями;
• crawl budget;
• жизненным циклом товарных страниц.

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

Вывод

На Prompotolok.ru граница между SEO и разработкой исчезла довольно быстро.

Пока сайт небольшой, специалист действительно может многое сделать вручную:

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

На региональном каталоге с тысячами посадочных и десятками тысяч исторических URL тот же подход перестаёт масштабироваться.

Нужно управлять уже не отдельными страницами, а правилами всей системы.

Для каждого класса URL нужно понимать:

• должен ли он существовать;
• какая страница является основной;
• куда должен вести старый адрес;
• нужен ли отдельный поисковый интент;
• есть ли под него товары;
• как страница попадёт во внутреннюю структуру;
• как она попадёт в sitemap;
• когда поисковику нужно показать её повторно.

Именно поэтому основной результат этой работы — не само количество созданных посадочных.

Мы перестроили архитектуру так, чтобы дальнейшее масштабирование SEO не приводило к такому же масштабированию технического долга.