Как безопасно разместить несколько сайтов: отдельные каталоги, базы и доступы, границы изоляции shared, план восстановления и перенос одного проекта без остальных.
Что в действительности означает «несколько сайтов в тарифе»
Число сайтов в пакете обычно описывает возможность подключить несколько проектов в одном аккаунте. Это не подтверждение отдельных системных пользователей, независимых ресурсов или полной защиты одного проекта от другого. Два разных домена могут использовать одного владельца файлов, общие квоты и один управляющий доступ. Начните с выяснения этой модели, а не с количества свободных слотов.
Для сайтов одной компании общий аккаунт иногда удобен: единая оплата, один ответственный и похожее окружение. Для независимых заказчиков последствия компрометации, ошибки исполнителя или блокировки аккаунта могут затронуть сразу несколько организаций. Поэтому решение о совместном размещении должно учитывать принадлежность данных и договорённости о сопровождении, а не только экономию.
Разделите три вида независимости
Независимость адресов означает, что сайт открывается по своему домену. Независимость доступа — что один исполнитель не может читать файлы и базу другого проекта. Независимость эксплуатации — что резервирование, перенос, лимиты и изменение окружения одного сайта не ломают соседние. Эти свойства проверяют отдельно; наличие первого не доказывает два остальных.
Инвентаризация: каталог, база, почта и фоновые задания
Перед подключением очередного домена составьте карту существующих проектов. Для каждого нужны корневой каталог, база, пользователь базы, версия PHP, назначение почтовых ящиков и планировщик. В примерах ниже example.com и example.net используются как документальные имена, а не как ваши рабочие адреса. Названия каталогов также иллюстративны.
| Проект | Файлы | База и пользователь | Окружение / задачи |
|---|---|---|---|
| example.com | Отдельный каталог проекта A | Отдельная БД A, права только на неё | Собственная запись PHP и расписания |
| example.net | Отдельный каталог проекта B | Отдельная БД B, права только на неё | Проверяемая независимость настроек |
| Общие сервисы | Только явно согласованные компоненты | Без общего привилегированного пароля сайтов | Ответственный и границы общей квоты |
Проверьте фактическое назначение доменов в панели. Новый домен, случайно направленный в каталог существующего сайта, может показать чужой проект или попасть под его правила перенаправления. Не устанавливайте CMS поверх уже используемых файлов. Сначала создайте пустой отдельный каталог, затем сверьте путь назначения и только после этого выполняйте установку.
Выдайте отдельные доступы и проверьте их границы
У разработчика проекта A должен быть доступ только к согласованной области. Отдельный логин SFTP или файлового менеджера полезен лишь тогда, когда он действительно ограничен нужным каталогом и операциями. Название учётной записи не доказывает такую границу. Проверьте разрешённое чтение, запись и попытку перехода к соседнему проекту в согласованной учебной среде.
- Создайте отдельный тестовый доступ штатным механизмом панели. Не используйте единственную учётную запись владельца.
- Проверьте работу в разрешённом каталоге: просмотр, загрузку и изменение тестового файла.
- Проверьте, доступны ли соседние корни, архивы и конфигурационные файлы. Ограничение оценивается по результату, а не по подписи поля.
- Отдельно проверьте доступ к базе: пользователь сайта не должен получать права на несвязанные базы.
- Отзовите тестовый доступ и убедитесь, что вход прекращён, а доступ владельца сохранён.
Не публикуйте содержимое конфигурационных файлов и пароли в отчёте о проверке. Достаточно указать, был ли доступ разрешён, кем выполнен тест и когда. Если панель не позволяет нужное ограничение, зафиксируйте это как свойство выбранной услуги и рассмотрите отдельные аккаунты или иной тип размещения.
Разделите базы и конфигурации приложений
Для независимых WordPress-проектов удобно иметь отдельные базы и отдельные учётные данные. Разные префиксы таблиц внутри одной общей базы помогают различать установки, но не заменяют разграничение прав пользователя базы. Если один пользователь имеет доступ ко всем таблицам, ошибка или компрометация одного приложения способна затронуть соседние данные.
В каждом wp-config.php должна быть ссылка на свою базу и её пользователя. Не копируйте файл конфигурации второго сайта без проверки всех зависимых значений и внешних ключей. При переносе или создании стенда также пересматривают домен приложения, путь, кэш, отправку писем и интеграции. Совпадающий пароль для разных проектов уменьшает пользу от формального разделения.
Что уточнить у провайдера
Спросите, можно ли выделить отдельного пользователя БД, какие права он получает и доступны ли независимые версии PHP по сайтам. Если часть возможностей общая на аккаунт, включите это в план обновлений. Не пытайтесь «исправить» модель shared случайным изменением системных прав, которые не входят в ваши полномочия.
Общие квоты: диск, файлы, CPU и фоновые процессы
Несколько сайтов часто делят общую квоту аккаунта. Импорт каталога или создание большого архива на одном проекте может мешать остальным. Запишите, к какой области относится каждый лимит: сайт, база, пользователь, аккаунт или услуга. Маркетинговое «неограниченно сайтов» не означает неограниченные вычисления, число файлов и параллельные операции.
| Нагрузка | Как проявляется на соседях | Как уменьшить конфликт |
|---|---|---|
| Резервирование большого сайта | Рост диска и нагрузка во время архивации | Согласовать расписание и место хранения |
| Импорт и обработка медиа | Очередь процессов и увеличение числа файлов | Делить на контролируемые порции, наблюдать лимиты |
| Массовая рассылка | Общие ограничения отправки и репутационные последствия | Использовать согласованный почтовый сервис |
| Ошибка фонового задания | Длительное потребление общих ресурсов | Вести журнал запуска и исключать пересечение |
Не запускайте нагрузочные испытания shared-окружения без разрешения поставщика. Для эксплуатационной приёмки достаточно согласованных операций на обезличенной копии и наблюдения за доступными метриками. Если лимиты срабатывают регулярно, выясните источник и границу нагрузки, затем оценивайте раздельное размещение или другой пакет.
Резервирование должно позволять восстановить один сайт
Общий архив аккаунта удобен для аварии целиком, но не всегда подходит для точечного восстановления проекта. До размещения нескольких сайтов выясните, можно ли выбрать отдельный каталог и базу, какую дату они имеют и затрагиваются ли почта, DNS и соседние проекты. Разные моменты создания файлов и базы способны дать несогласованное состояние приложения.
Проверьте восстановление сайта A в отдельную среду, не заменяя рабочие данные соседнего сайта B. Сверьте ключевые страницы, медиа, вход, поиск и фоновые операции. Если в источнике после копии появились новые записи, обозначьте границу потери изменений и порядок их учёта. Наличие файлового архива ещё не подтверждает, что такое восстановление возможно.
Реестр копии одного проекта
— каталог и дата файлов;
— база и дата экспорта;
— версия окружения и компоненты;
— необходимые внешние зависимости;
— исключённые рассылки и рабочие вебхуки;
— где и кем проверено отдельное восстановление.Обновляйте окружение по проектам, если это поддерживается
У сайтов могут быть разные требования к PHP и расширениям. Если версия выбирается на весь аккаунт, переключение ради нового проекта затронет старые. До такого изменения создайте стенды и матрицу совместимости. Если версия задаётся отдельно по домену, всё равно проверьте консольный интерпретатор и команды планировщика: они могут использовать другой путь.
Не обновляйте одновременно ядро, тему, плагины и окружение всех сайтов без промежуточной приёмки. Иначе при ошибке будет трудно определить причину и область возврата. Порядок зависит от совместимости связки; сохраняйте исходное состояние и проверяйте изменения на копии. Для рабочего магазина отдельно учитывайте новые заказы, которых не было в исходной резервной копии.
Как перенести один проект из общего аккаунта
Перенос начинается с карты зависимостей конкретного сайта. Кроме его каталога и базы проверьте почту, задания cron, пути к общим библиотекам, ключи интеграций и правила DNS. Копирование всей учётной записи ради одного сайта переносит лишние данные и усложняет ответственность. Выгружайте только согласованный состав, сохраняя достаточные права для последующей эксплуатации.
- Создайте независимую копию проекта и инвентаризацию его зависимостей.
- Разверните её у нового поставщика в совместимом окружении.
- Отключите реальные уведомления и обмены на тестовом контуре.
- Пройдите функциональную приёмку и отдельное восстановление.
- Согласуйте перенос последних изменений и переключение нужных записей домена.
- После приёмки удалите только действительно ненужные доступы и задания старого проекта по согласованному регламенту.
Не удаляйте общую базу, пользователя или каталог, пока не подтверждено, что соседний сайт их не использует. В спорной конфигурации сначала разделите зависимость. Возврат домена на прежний адрес не объединяет изменения двух работающих копий, поэтому план отката должен учитывать данные приложения, а не только DNS.
Когда лучше сразу выбрать отдельные аккаунты
Раздельные аккаунты полезны, когда проекты принадлежат разным владельцам, обслуживаются независимыми исполнителями или имеют разные требования к эксплуатации. Это уменьшает часть общей области отказа, хотя не является абсолютной гарантией безопасности. Отдельные аккаунты у одного провайдера тоже могут зависеть от общей инфраструктуры; реальные гарантии определяются услугой и договором.
Другой повод разделения — необходимость независимо оплачивать, передавать и переносить проекты. Если один заказчик прекращает обслуживание, его выход не должен блокировать остальные сайты. Сравните не только сумму размещения, но и затраты на разграничение доступов, резервирование и передачу управления. Иногда экономия на одном аккаунте меньше стоимости постоянного сопровождения сложной общей схемы.
Учебная приёмка двух проектов: что считать доказательством
Подготовьте два разрешённых учебных проекта с разными тестовыми файлами и отдельными базами. Не используйте для упражнения чужие сайты или рабочие конфигурации с клиентскими данными. В панели зафиксируйте, как домены связаны с корнями, и создайте ограниченного исполнителя только для проекта A. Сначала подтвердите разрешённую операцию, затем проверьте, что система ограничивает переход к данным B. Название домашнего каталога и список видимых файлов сами по себе недостаточны: важен фактический результат чтения и записи в согласованной области.
Если доступ предоставляется через SSH, чтение собственного контекста помогает понять модель. Команды ниже не меняют права и не должны выполняться от имени чужой учётной записи. Путь заменяют на свой. Результаты не публикуют вместе с паролями и содержимым конфигураций.
id
pwd
ls -ld /разрешённый/каталог/проектаПовторите проверку для базы через штатный ограниченный доступ: исполнитель A должен работать с тестовыми таблицами A и не получать административные права на B. Если панель показывает обе базы, уточните, означает ли это доступ к содержимому или только отображение списка. Не пытайтесь обходить ограничения. Неоднозначный результат передайте провайдеру с точным описанием теста. Отсутствие отдельного системного пользователя не всегда означает отсутствие всех защит, однако обещание полной изоляции в такой ситуации требует достаточного объяснения.
После отзыва доступа A заново проверьте вход, фоновые подключения и сохранение работы обоих сайтов. Затем восстановите только A в отдельное окружение и убедитесь, что B не изменился. Итоговый протокол состоит из конкретных границ: доступ, база, квота, восстановление и перенос. Если одна из них не проверена, её нельзя включать в общее утверждение «сайты полностью независимы». Для нескольких владельцев такая неопределённость может быть основанием выбрать отдельные аккаунты, даже если совместный тариф дешевле.
FAQ: что часто понимают неправильно
Два домена означают два изолированных сайта?
Нет. Домены могут вести в один каталог или использовать общий системный доступ. Изоляцию файлов, баз, прав и эксплуатационных операций проверяют отдельно.
Разные префиксы таблиц защищают независимые проекты?
Префиксы разделяют имена таблиц, но не полномочия одного пользователя базы. Для разграничения нужны соответствующие отдельные права и проверка выбранной модели размещения.
Можно ли передать клиенту общий доступ к панели?
Это даст ему ту область управления, которую предоставляет такая учётная запись, включая потенциально соседние проекты. Используйте отдельные права или аккаунт, соответствующий договорённостям.
Нужно ли немедленно переходить на VPS?
Не обязательно. Сначала определите конкретное ограничение. Отдельные shared-аккаунты иногда решают задачу проще; VPS требует собственного понятного сопровождения.
Контрольный результат
Правильный итог — карта каждого проекта, проверенные отдельные доступы, понятные общие квоты и возможность восстановить или перенести один сайт. Если какое-либо свойство не подтверждено, не считайте его выполненным только потому, что панель позволила добавить домен.
Для выбора сопоставьте готовые пакеты нескольких провайдеров, затем проверьте их модель доступа на учебной копии. Если проекты независимы по владельцам и ответственности, отдавайте приоритет управляемому разделению. Сохраняйте инструкции и актуальность доступов: именно они делают совместное размещение контролируемым, а не само число сайтов в тарифе.
Источники и дата
- WordPress — безопасность и границы доступа
- IANA — документальные домены example.com и example.net
- Пакеты Beget
- Пакеты SpaceWeb
- Установка нескольких WordPress
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
