Коли бізнес запускає сайт, корпоративну пошту і виходить одразу на кілька мов або ринків, проблема зазвичай не в окремому домені чи окремій скриньці. Проблема в тому, щоб усе це працювало як одна система. Саме таке завдання стояло в цьому проекті для компанії AA ENERGOBUD.
Потрібно було зібрати в єдину логіку домени, корпоративну пошту в Google Workspace, DNS-записи, хостинг і майбутній мультимовний сайт на WordPress. Один домен мав стати основою для корпоративної пошти та англомовної версії сайту, інший для польської версії. На практиці це означало не просто підключити другий домен, а побудувати технічну основу, яка буде стабільно працювати на старті і не вимагатиме переробки після запуску.
Вихідна ситуація
На старті у проекті було два домени, зареєстровані в OVH (перегляньте нашу публікацію “Як обрати реєстратора доменного імені”). Для основного домену вже використовувався Google Workspace: було створено основну корпоративну скриньку, налаштовано додаткові адреси та виконано базову верифікацію.
Далі з’явилося наступне завдання: другий домен потрібно було підключити так, щоб він коректно працював і для поштової логіки, і для польської мовної версії сайту. Паралельно потрібно було підготувати одну WordPress-інсталяцію до роботи на двох доменах через WPML: англійська версія на .com, польська на .pl.
Це вже не окреме налаштування пошти і не окреме налаштування сайту. Це інфраструктурна задача, у якій пошта, домени, DNS, хостинг і SEO напряму впливають одне на одне.
Що потрібно було вирішити
У межах проекту потрібно було підключити другий домен як alias domain у Google Workspace, зберегти коректну роботу корпоративних адрес на двох доменах, перевірити й скоригувати DNS-записи, налаштувати базову поштову автентифікацію через SPF, DKIM і DMARC, додати другий домен у cPanel на спільний document root, підготувати одну WordPress-інсталяцію до мультимовної роботи на двох доменах і закласти правильну технічну основу для подальшого SEO.
У чому була реальна складність
На перший погляд такі задачі здаються простими: додати домен, підключити пошту, направити сайт. Але на практиці найбільше проблем виникає саме на стику систем.
Якщо другий домен підключити без узгодження з поштовою логікою, частина листів може не доходити або працювати нестабільно. Якщо cPanel починає обробляти пошту локально, а не передавати її в Google Workspace, це створює проблеми в маршрутизації. Якщо багатомовний сайт на двох доменах налаштувати без чіткої логіки, виникають дублікати сторінок, проблеми з індексацією і зайві SEO-ризики.
Іншими словами, тут важливо було не просто все підключити, а зробити так, щоб домени, пошта і сайт працювали узгоджено.
Що було зроблено
Аудит доменів і DNS
Почали з перевірки DNS-зони обох доменів. Потрібно було чітко відокремити записи, які відповідають за сайт, від записів, що відповідають за пошту, і зрозуміти, чи немає змішаних налаштувань від різних сервісів.
На цьому етапі було закладено базову логіку: обидва домени повинні вести на сайт, але пошта має залишатися під контролем Google Workspace, а не локального хостингу.
Перевірка Google Workspace і підключення другого домену
Для основного домену було підтверджено чинну конфігурацію Google Workspace. Далі другий домен було підготовлено як alias domain, щоб поштові адреси на ньому працювали в межах тієї ж корпоративної структури.
Це дало змогу уникнути зайвих окремих акаунтів там, де достатньо правильно налаштованих аліасів і доменної логіки. Для бізнесу це означає простіше адміністрування, зрозумілішу структуру пошти і менше зайвих витрат.
Коригування SPF і перевірка поштової логіки
Окремо було переглянуто SPF-записи. Це одна з тих зон, де помилка може бути непомітною на старті, але згодом проявитися через погану доставку листів або потрапляння в spam.
Було узгоджено логіку відправлення пошти так, щоб домени працювали в одній моделі з корпоративною поштою і не конфліктували між собою.
Підготовка DKIM і DMARC
Після цього було підготовлено поштову автентифікацію на рівні DKIM і DMARC. Це важливо не лише для технічної доставки листів, а й для довіри до домену, стабільної роботи корпоративної пошти та коректної відправки повідомлень із сайту.
На практиці саме ці речі часто визначають, чи лист виглядає для поштових сервісів надійним, чи викликає підозру.
Додавання другого домену в cPanel
Щоб не створювати два окремих сайти, другий домен було додано в cPanel на shared document root. Це означає, що обидва домени фізично обслуговують одну WordPress-інсталяцію.
Для бізнесу це вигідніше й зручніше: одна система керування, один комплект шаблонів і плагінів, простіша підтримка і менше ризику технічного розходження між мовними версіями.
Підготовка WordPress і WPML до роботи на двох доменах
На рівні WordPress було підготовлено модель, у якій одна інсталяція обслуговує дві мовні версії через WPML. Англомовна версія була закріплена за одним доменом, польська за іншим.
Це важливий момент, тому що правильна мовна структура на старті дозволяє надалі спокійно розвивати сайт, не повертаючись до базової архітектури.
Перевірка базової SEO-логіки
Оскільки різні домени для різних мов напряму впливають на індексацію, було також враховано SEO-логіку. Йшлося про те, щоб уникнути дублювання сторінок, помилок у canonical і нечіткої мовної прив’язки.
У підсумку було підготовлено структуру, придатну для подальшого розвитку без технічного боргу вже на старті.
Які ризики вдалося зняти
Один з найбільших ризиків у таких проектах це ситуація, коли другий домен підключений до сайту, але не узгоджений із реальною поштовою логікою. У результаті листи можуть працювати частково або нестабільно.
Ще один поширений ризик це конфлікт між Google Workspace і локальною поштою хостингу. Якщо це не проконтролювати, частина повідомлень може оброблятися не там, де очікується.
Окремо були враховані ризики, пов’язані з SPF, DKIM і DMARC, а також із мультимовністю на різних доменах. Саме тут часто закладаються проблеми, які стають помітними вже після запуску сайту.
Що було критично важливо
У цьому проекті важливо було не розбивати задачу на окремі дрібні налаштування. Пошта, домени, хостинг і WordPress тут напряму залежать одне від одного.
Не менш важливо було зберегти одну WordPress-інсталяцію замість двох окремих сайтів. Це спрощує підтримку, знижує технічне навантаження і дає стабільнішу модель на майбутнє.
Також критично важливо було правильно розподілити ролі доменів: один як основа для англомовної версії і корпоративної пошти, другий як домен для польської версії сайту. Саме така структура створює керовану основу і для бізнесу, і для SEO.
Результат
У підсумку для будівельної компанії з міжнародною діяльністю було підготовлено не набір розрізнених налаштувань, а єдину технічну модель. Одна WordPress-інсталяція працює для двох мовних версій, два домени виконують різні ролі в межах одного проекту, корпоративна пошта зберігає централізовану логіку, а поштова автентифікація підготовлена для коректної доставки листів.
Для бізнесу це означає передбачуваність, менше технічних ризиків і нормальну основу для запуску сайту, комунікації з клієнтами та подальшого масштабування.
Що отримав клієнт на виході
На виході клієнт отримав зрозумілу і масштабовану систему, у якій сайт, домени і пошта не суперечать одне одному. Було створено основу для мультимовного WordPress-сайту, централізованої корпоративної пошти і подальшого технічного розвитку без необхідності все перебудовувати після запуску.
Цінність цього проекту полягала не лише в самих налаштуваннях, а в тому, що всі рішення були прийняті як частина однієї логіки, придатної для стабільної роботи в майбутньому.
У цьому кейсі завдання полягало не просто в тому, щоб підключити ще один домен або налаштувати кілька поштових адрес. Потрібно було зібрати єдину робочу основу, в якій пошта, домени, хостинг і сайт підтримують одне одного, а не створюють зайві точки ризику.
Саме такий підхід дозволяє бізнесу стартувати не з тимчасовим рішенням, а з нормально підготовленою технічною базою.
Потрібно правильно зібрати домени, корпоративну пошту і сайт в одну робочу систему? Зверніться до нас. Допоможемо підготувати технічну основу без зайвих переробок у майбутньому.
