gr33njj.dev
Back
seocontentstatic-siteinfrastructure2026-07-21

Контекст

skangar-landing начинался как обычный лендинг для строительной компании — сделал, сдал, готово. Спустя время стало понятно: для реального объёма трафика одной страницы физически недостаточно. Десятки городов и районов, куда компания реально возит и монтирует конструкции, и десятки поисковых запросов, которые лендинг не мог закрыть в принципе — просто потому, что «продающая страница» и «страница под конкретный запрос из конкретного города» это разные задачи.

Масштаб задачи

Лендинг нужно было дорастить до content-инфраструктуры, не сломав то, что уже работало:

  • посадочные страницы под 75 городов и районов Краснодарского края и соседних регионов — не шаблонные клоны, а с региональной спецификой (грунты, ветровые нагрузки, локальная экономика — где-то виноградарство, где-то рисоводство, где-то порт)
  • раздел «База знаний» — 13 статей с кластерной перелинковкой и глоссарий на 37 терминов, выросший органически вместе со статьями
  • навигацию и структуру сайта пришлось пересобирать вокруг этого нового объёма, а не пристраивать сбоку

Сборка кода

Всё держалось на общем Python-генераторе: один page_shell(), переиспользуемые хелперы для схем и хлебных крошек, единый шаблон для 75 городских страниц с точечной заменой региональных данных. Дублирование в лоб — плохая идея на таком масштабе, поэтому общие куски (шапка, футер, вёрстка FAQ) были вынесены в шаред-код с самого начала.

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

Хороший процесс держится не на инструменте, а на дисциплине проверки — инструмент можно потерять, привычку проверять каждый деплой — нет.

Технические моменты

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

  • поддомен нового города требует правки сразу в двух местах nginx-конфига — списка server_name и отдельного map $host $city_dir. Забыл про второе — полдня отладки 404 на ровном месте, хотя nginx честно матчил домен.
  • rsync с несколькими каталогами-источниками в одной команде без разбора схлопывает их в общий каталог назначения. Один неаккуратный деплой временно похоронил главную страницу сайта под страницей словаря терминов.
  • баннеры для статей приходили с разными исходными пропорциями — форс-ресайз в одну сетку размеров тихо исказил бы часть картинок, если не проверять пропорции каждой отдельно.

SEO

  • Article / FAQPage / BreadcrumbList JSON-LD на каждой странице базы знаний
  • уникальный og:image на каждую статью вместо одной общей картинки на весь сайт
  • статьи писались не «про тему вообще», а под конкретные формулировки из Google Search Console — с расчётом сверить показы и клики через несколько недель после публикации
  • внутренняя перелинковка не для галочки: каждая новая статья осознанно ссылается на 4–6 уже опубликованных, формируя кластер, а не разрозненный список текстов

Результат

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

Вывод

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