Несколько сайтов на одном аккаунте Beget: настройка без ошибок

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

В этом руководстве разберём правильную схему для Beget: как создать отдельный сайт в панели, привязать домен, дождаться DNS, выпустить SSL, установить WordPress и проверить изоляцию. Команды подходят и для диагностики других хостингов с похожей структурой каталогов.

Что означает «несколько сайтов на одном аккаунте»

Аккаунт хостинга — это общий лимит процессора, памяти, диска, процессов и баз данных. Внутри аккаунта можно создать несколько независимых директорий сайтов. По документации Beget, у каждого нового сайта появляется собственный каталог с поддиректорией public_html, а к одной директории можно прикрепить один или несколько доменов.

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

Рекомендуемая структура

~/company.ru/public_html/
~/docs.company.ru/public_html/
~/project-two.ru/public_html/
~/staging-project.ru/public_html/

Каждый домен направляется только в свой public_html. Не создавайте второй WordPress внутри каталога первого сайта вроде company.ru/public_html/project-two: ошибка в правилах перенаправления или плагине первого проекта может затронуть второй.

Подготовка: что проверить до создания сайта

1. Количество сайтов, доменов и баз данных, разрешённое текущим тарифом.
2. Свободное место с запасом под архивы, журналы и временные файлы.
3. Версию PHP и обязательные расширения каждого проекта.
4. Пиковую нагрузку: импорт товаров, резервное копирование и cron могут запускаться одновременно.
5. Кто управляет DNS и когда истекает регистрация каждого домена.

Если один сайт уже регулярно упирается в лимиты CPU или процессов, добавление ещё нескольких проектов увеличит число ошибок 502/504 и время ответа. В таком случае сначала оцените перенос тяжёлого проекта на VPS. С базовой схемой развёртывания поможет руководство по деплою Docker-приложения на VPS.

Шаг 1. Создайте отдельный сайт в панели Beget

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

После создания проверьте структуру через файловый менеджер либо SSH:

pwd
find ~ -maxdepth 2 -type d -name public_html -print
du -sh ~/company.ru ~/project-two.ru 2>/dev/null

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

Шаг 2. Добавьте и привяжите домен

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

При использовании DNS Beget убедитесь, что у регистратора указаны актуальные NS-серверы из панели. Если DNS обслуживает сторонний провайдер, создайте записи согласно данным аккаунта. Основные варианты:

• A — домен указывает на IPv4-адрес хостинга;
• AAAA — домен указывает на IPv6, если он назначен и обслуживается;
• CNAME — поддомен является псевдонимом другого имени;
• MX, SPF, DKIM и DMARC — отвечают за почту и не должны бездумно копироваться между проектами.

Подробнее о типах записей и диагностике читайте в материале «DNS простыми словами: записи, dig и диагностика ошибок».

Проверка DNS до установки WordPress

dig +short company.ru A
dig +short www.company.ru A
dig company.ru NS +short
dig company.ru CAA +short

Ответ A должен содержать IP нужного хостинга. NS должны соответствовать выбранному DNS-провайдеру. Запись CAA, если она существует, должна разрешать центру сертификации выпуск сертификата. Распространение изменений зависит от TTL и кэшей: повторные клики в панели не ускоряют делегирование.

Шаг 3. Выпустите отдельный SSL-сертификат

После того как домен стабильно указывает на хостинг, закажите в панели бесплатный сертификат Let’s Encrypt для домена и нужных поддоменов. Не включайте принудительный редирект на HTTPS до успешного выпуска: иначе диагностика ошибочной DNS-записи станет сложнее.

Проверить сертификат можно без браузера:

curl -I https://company.ru/
openssl s_client -connect company.ru:443 -servername company.ru </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -issuer -dates

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

Шаг 4. Создайте отдельную базу данных

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

Практичная схема имён:

site_company_prod
site_docs_prod
site_project2_prod

Пароли должны быть уникальными. Не копируйте готовый wp-config.php между сайтами без замены реквизитов базы, ключей безопасности и префикса таблиц. Конфигурацию храните только в каталоге нужного проекта и не вставляйте реальные пароли в тикеты, статьи или общие чаты.

Шаг 5. Установите WordPress и закрепите адрес

Загрузите файлы только в public_html созданного сайта, подключите отдельную базу и завершите установку. Если WordPress устанавливается впервые, используйте подробную инструкцию по установке и настройке WordPress.

После входа в административную панель проверьте в разделе общих настроек:

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

Для защиты от случайного редактирования PHP через админку можно добавить в wp-config.php до строки завершения редактирования:

define('DISALLOW_FILE_EDIT', true);

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

Права файлов: безопасная базовая проверка

Не назначайте рекурсивно права 777. Для типовой установки WordPress отправной точкой служат 755 для каталогов и 644 для файлов. Перед массовым изменением уточните требования конкретного хостинга и сделайте резервную копию.

cd ~/company.ru/public_html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 640 wp-config.php

Последняя команда допустима, только если веб-процесс сохраняет возможность читать конфигурацию. Если после неё сайт выдаёт ошибку, верните значение, рекомендованное поддержкой хостинга. Никогда не запускайте такие команды из домашнего каталога без предварительного pwd.

Изоляция сайтов внутри одного аккаунта

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

• уникальные пароли WordPress, базы данных и почтовых ящиков;
• отдельный администратор для каждого сайта;
• минимальный набор плагинов и удаление неиспользуемых тем;
• обновления ядра, тем и расширений;
• SFTP или SSH вместо незашифрованного FTP, когда это доступно;
• раздельные резервные копии с проверкой восстановления;
• уведомления о превышении нагрузки и окончании доменов.

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

Резервное копирование без общей точки отказа

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

Пример ручной проверки объёма перед резервированием:

du -sh ~/company.ru/public_html
find ~/company.ru/public_html/wp-content/uploads -type f | wc -l
find ~/company.ru/public_html -type f -mtime -7 | wc -l

Храните хотя бы одну копию вне основного хостинга. Раз в квартал восстанавливайте сайт во временную директорию и проверяйте вход, формы, изображения, cron и отправку почты. Наличие архива без теста восстановления не доказывает, что резервная копия рабочая.

Как развести cron и тяжёлые операции

Несколько WordPress-сайтов могут одновременно запускать wp-cron.php, резервное копирование, генерацию изображений и обновление каталогов. На общем лимите это создаёт короткие, но заметные пики.

Разнесите задачи по времени: например, первый сайт запускает обслуживание в 02:10, второй — в 02:35, третий — в 03:00. До изменения механизма WordPress Cron убедитесь, что системное расписание действительно создано: отключение встроенного запуска без замены остановит публикации, письма и плановые операции.

Проверка после подключения нового сайта

curl -I http://company.ru/
curl -I https://company.ru/
curl -sS https://company.ru/wp-json/ -o /dev/null -w '%{http_code}n'
curl -sS https://company.ru/robots.txt
curl -sS https://company.ru/sitemap_index.xml -o /dev/null -w '%{http_code}n'

Проверьте, что HTTP перенаправляется на один канонический HTTPS-адрес, главная страница возвращает ожидаемый код, REST API не показывает системную ошибку, а robots.txt и sitemap доступны после открытия сайта для индексации. Затем протестируйте форму обратной связи и восстановление пароля.

Когда одного аккаунта уже недостаточно

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

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

Для небольших информационных сайтов shared-хостинг остаётся простым и экономичным вариантом. Для приложений с контейнерами сравните требования с материалом об установке кластера k3s на Linux.

Краткий чек-лист

• Для каждого проекта создан отдельный сайт и public_html.
• Домен направлен в правильную директорию.
• Записи A/AAAA, NS и CAA проверены через dig.
• SSL выпущен для всех используемых имён.
• У каждого WordPress собственная база и уникальный пользователь.
• Нет каталогов и файлов с правами 777.
• Резервная копия хранится вне аккаунта и проходит тест восстановления.
• Тяжёлые cron-задачи разведены по времени.
• Настроены отдельные события мониторинга для каждого домена.

Официальные источники

• Beget: управление сайтами.
• Beget: домены, поддомены и SSL.
• WordPress: Hardening WordPress.

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

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