Развилка архитектуры: единый портал vs сеть специализированных сайтов (часть 6)

#Развилка архитектуры: единый портал vs сеть специализированных сайтов — часть 6 из 13

Назначение и границы: Документ входит в блок G библиотеки материалов «Содействие» (Гомель). Тематический охват: Развилка архитектуры: единый портал vs сеть специализированных сайтов. Ответственная линия: корпус. Статус материала: есть проверенные пруфы — фрагментов 84, утверждений 580, проверенных 16.

#Утверждения темы

• [факт] [LG-127-C071]
• [факт] [LG-127-C072]
• [факт] [LG-127-C073]
• [факт] [LG-127-C074]
• [факт] [LG-127-C075]
• [факт] [LG-127-C076]
• [факт] [LG-127-C077]
• [факт] [LG-127-C078]
• [факт] [LG-127-C079]
• [факт] [LG-127-C080]
• [закон] подтверждено [LG-127-C081] [Пруф: support.google.com/analytics/answer/12979939]
• [закон] подтверждено [LG-127-C082] [Пруф: support.google.com/analytics/answer/12979939]
• [факт] [LG-127-C083]
• [закон] подтверждено [LG-127-C084] [Пруф: support.google.com/analytics/answer/12979939]
• [факт] [LG-189-C094]
• [факт] [LG-189-C095]
• [факт] [LG-189-C096]
• [факт] [LG-189-C097]
• [факт] [LG-189-C098]
• [факт] [LG-189-C099]
• мнение [LG-189-C100]
• [факт] [LG-191-C059]
• [факт] [LG-191-C060]
• [факт] [LG-191-C061]
• [факт] [LG-191-C062]
• [факт] [LG-191-C063]
• [факт] [LG-191-C174]
• [факт] [LG-191-C175]
• [факт] [LG-191-C176]
• [факт] [LG-211-C001]
• [факт] [LG-211-C002]
• [факт] [LG-211-C003]
• [факт] [LG-211-C004]
• [факт] [LG-211-C005]
• [факт] [LG-211-C006]
• [факт] [LG-211-C007]
• [факт] [LG-211-C008]
• [факт] [LG-211-C009]
• [факт] [LG-211-C010]
• [факт] [LG-211-C011]
• [закон] [LG-211-C012]
• [факт] [LG-211-C013]
• [факт] [LG-211-C014]
• [факт] [LG-211-C015]
• [факт] [LG-211-C016]
• [факт] [LG-211-C017]
• мнение [LG-211-C018]
• [факт] [NB-N13-C002]
• [факт] [NB-N13-C032]
• [факт] [NB-N13-C033]
• [факт] [NB-N13-C034]
• [факт] [PR-005-C015]

#Фрагменты корпуса темы

#[LG-127-F010] — LG-127, фрагмент 02, строки 33-42, тема «Когда Next.js может быть рациональнее для нашей команды»

#Когда Next.js может быть рациональнее для нашей команды

• Требуется существенная новая структура и повторяющиеся управляемые компоненты, а существующий дизайн все равно будет практически полностью переделан.
• Наша команда постоянно разрабатывает Next.js и способна показать рабочий процесс preview → проверка → выпуск → откат.
• Есть план регулярных изменений офферов, посадочных, форм, калькуляторов и интеграций, который проще обслуживать согласованным кодом, чем адаптировать существующую сборку.
• Заранее решены редактирование контента, хранение данных, обновления, мониторинг, доступы владельца и передача другому разработчику.
• До переноса известна карта ценных URL, план редиректов/сохранения адресов и критерии запуска.

Возможен промежуточный вариант: WordPress остается редакторской CMS, Next.js становится публичным frontend. Это сохраняет знакомый редактор, но добавляет две системы, синхронизацию и сложность кэша; для небольшого сервиса такая схема может оказаться избыточной. Само упоминание headless не делает предложение выгоднее.

#[LG-127-F011] — LG-127, фрагмент 02, строки 43-50, тема «Где уместна Tilda»

#Где уместна Tilda

Когда разработчика в модели обслуживания нет, сайт в основном состоит из стандартных посадочных и форм, а владельцу важно самостоятельно редактировать и публиковать страницы, SaaS-конструктор может уменьшить объем технической эксплуатации. При наличии работающего gomelritual.com на Tilda можно оценить его как существующий актив, прежде чем создавать еще одну реализацию.

Tilda документирует подключение Метрики, события кнопок/попапов/форм и гибкие цели. Поэтому их наличие не является отличием Next. Tilda: подключение Метрики, Tilda: события и цели.

При исследовании найдена старая инструкция Tilda по A/B через Google Optimize. Использовать ее как текущую готовую инструкцию нельзя: Google Optimize закрыт 30 сентября 2023. Возможность разделить трафик между версиями остается архитектурно возможной, но актуальный инструмент и его работу нужно выбрать и проверить отдельно. Старая инструкция Tilda, официальное закрытие Optimize.

#[LG-189-F014] — LG-189, фрагмент 02, строки 11-20, тема «Основания для выбора платформы»

#Основания для выбора платформы

Сравнивать следует три конкретных варианта: исправить WordPress; развивать уже имеющийся сайт на Tilda; создать новую реализацию на основном домене. Сам по себе Next.js не гарантирует ни скорость, ни индексацию, ни удобство владельцу. Tilda тоже требует ответственного за содержание и аналитику.

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

До миграции нужны выгрузки обеих поисковых консолей по двум доменам, список посадочных и звонков, карта сохранения URL/редиректов и проверка после запуска. Google о миграциях.

Существующий gomelritual.com на Tilda остаётся действующим активом с другим телефоном и реквизитами ООО. Его нельзя отключать или перенаправлять без понимания вклада в обращения. Разные реквизиты могут отражать реальную структуру бизнеса; её следует уточнить.

#[LG-191-F013] — LG-191, фрагмент 02, строки 83-126, тема «Два сайта лучше превратить в один поисковый актив»

#Два сайта лучше превратить в один поисковый актив

Мой предварительный выбор — sodeystvie.by сделать главным доменом бренда.

Почему:

он совпадает с названием;

это локальный .by;

актуальная Яндекс-карточка уже привязана к нему;

новый номер также уже привязан к нему;

он имеет более широкую современную структуру страниц. citeturn14search14turn20search0

Но делать слепой redirect gomelritual.com → sodeystvie.by завтра я не рекомендую.

Сначала нужно выгрузить из Google Search Console / Яндекс Вебмастера по обоим доменам:

показы и клики за 16 месяцев;

запросы;

landing pages;

проиндексированные URL;

выбранные Google canonical;

ссылки;

конверсии/звонки, если есть аналитика.

Google рекомендует для duplicate/canonical проблем сначала смотреть, какую каноническую страницу фактически выбрала поисковая система, в том числе через URL Inspection. citeturn18search6

Если окажется, например, что gomelritual.com генерирует большую часть органических обращений и имеет сильный backlink profile, миграцию надо проводить аккуратно, URL-к-URL.

Но конечное состояние должно быть:

один бренд → одна организация → один основной телефон → один основной сайт → одна локальная сущность.

На старом домене при миграции — page-to-page 301 redirects, а не все страницы на homepage; новая sitemap; self-canonical на целевых страницах; обновление внутренних ссылок, Яндекс/Google-карточек и значимых внешних каталогов. Google рассматривает redirects и canonical как методы определения предпочтительной версии при дубликатах. citeturn18search3

#[LG-191-F057] — LG-191, фрагмент 05, строки 269-286, тема «Очередность внедрения»

#Очередность внедрения

Первые две недели — не дизайн, а санитарная операция.

Установить единственную юридически правильную сущность для каждого типа услуги; определить основной брендовый телефон; заменить старый номер во всех CTA и текстах; синхронизировать footer/header/contracts/maps/directories; проверить все формы; удалить шаблонный индексный мусор; определить роль gomelritual.com; поставить call tracking и зафиксировать baseline.

Следующие четыре–шесть недель — конверсия.

Новый первый экран; emergency flow; три–четыре понятных пакета; страница цены; блок «почему нам можно доверять»; реальные отзывы; mobile sticky call button; отдельные funnels «похороны / кремация / перевозка / памятники».

Далее — консолидация доменов и SEO.

Полная URL-карта; Search Console/Яндекс Вебмастер; 301; canonical; sitemap; structured data; title/H1/meta; внутренние ссылки; чистка thin/duplicate pages; региональные страницы с настоящей локальной ценностью. Google рекомендует явно задавать предпочтительные страницы при очень похожем содержимом и использовать структурированные бизнес-данные для лучшего понимания организации. citeturn18search3turn18search1turn18search4

Следующие три–шесть месяцев — новый рынок вокруг существующего бизнеса.

Запустить remote concierge; «могила под присмотром»; CRM для памятников и ухода с отдельным согласием; пилот прижизненного планирования после юридической проверки; расширять региональные страницы только туда, где реально обеспечиваются сроки и сервис.

#[LG-211-F002] — LG-211, фрагмент 01, строки 3-17, тема «Принято для каркаса»

#Принято для каркаса

Каждый проект — README и статический index.html. Общий styles.css лежит рядом; разделять на независимые репозитории пока не нужно. Отдельные домены для четырёх направлений не назначены: сначала отдельные посадочные страницы, потом решение по трафику и обслуживанию.

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

#[LG-211-F003] — LG-211, фрагмент 01, строки 18-26, тема «Порядок сборки реального сайта»

#Порядок сборки реального сайта

1. Подтвердить юрлицо, телефоны и состав услуг. Получить фотографии, реальные сметы, сроки и ответственных.
2. Быстро собрать срочный лендинг: телефон, помощь, состав заказа, подтверждение доверия. Учёт источника обращения.
3. Общий сайт: главная, услуги, компания, контакты, полезная информация. Без пустого товарного каталога.
4. Кремация и перевозка: отдельные сценарии и расчёт.
5. Памятники / уход: модели, кейсы, материалы и заявки на замер.
6. Перенести проверенный контент по URL-таблице; затем наращивать каталог и редакционную работу.

#[LG-211-F004] — LG-211, фрагмент 01, строки 27-32, тема «Старый сайт нельзя свести к одному URL вслепую»

#Старый сайт нельзя свести к одному URL вслепую

Сначала сопоставить адреса из migration-map.md с трафиком из Метрики / Search Console / Вебмастера. Полезные старые услуги, товары и статьи получают эквивалентную страницу и индивидуальный 301 после проверки. Не отправлять сотни несвязанных URL на главную. Каркас лендинга не меняет текущие сайты и не выполняет редиректы.

Дубли товаров объединять по идентификатору Tilda и модели, а не по количеству URL. Новости о старых пособиях и акциях отделять от актуальной справочной страницы. Пустые и служебные страницы решать отдельно. Все предлагаемые назначения в migration-map.md — черновик, не готовый файл для сервера.

#[NB-N13-F001] — NB-N13, фрагмент 01, строки 1-11, тема «Раздел 1»

---

title: Веб-архитектура ритейла note_id: fd9e0cf5-2656-4b5b-9188-55d3a83d17f6 updated: "2026-11-08T19:13:01.000Z" notebook_id: 342fc68c-9933-40cd-a89b-c3fc700fbda2 fetched: "2026-11-10T01:11:09Z"

---

На основе нашего стратегического плана и аудита ритуального рынка Гомеля разработана обновленная архитектура двух сайтов, которая полностью исключает риск аффилиат-фильтра и склейки в Google и Яндексе [1, 2]. Сайты строго разведены по юридическим лицам, физическим адресам, номерам телефонов, сценариям поведения пользователя и типам трафика [2].

---

#[NB-N13-F005] — NB-N13, фрагмент 01, строки 143-149, тема «План внедрения и технические правила»

#План внедрения и технические правила

1. Технический развод площадок: Сайты размещаются на независимых хостингах (Tilda для gomelritual.com и автономный VPS для WordPress sodeystvie.by), используют разные шаблоны, шрифты и фавиконы, имеют раздельные счетчики веб-аналитики [43, 44].
2. Маршрутизация обращений: Телефоны подключаются через динамический коллтрекинг, что позволяет диспетчерам сразу видеть, с какого сайта (быстрый конвертер или центральный хаб) поступает звонок, и применять соответствующий скрипт диалога [31, 45].

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

#[PR-005-F006] — PR-005, фрагмент 02, строки 22-23, тема «2. Мульти-сайт: как это устроено у живых бизнесов»

#2. Мульти-сайт: как это устроено у живых бизнесов