Первый сайт редко остается единственным. У компании появляется отдельный лендинг под рекламу, у веб-мастера второй информационный проект, у предпринимателя интернет-магазин рядом с корпоративным сайтом, у разработчика несколько клиентских площадок. И довольно быстро возникает вопрос: покупать каждому сайту отдельный хостинг или собрать их на одном аккаунте?
Второй вариант выглядит очевидно выгоднее. Вместо пяти платежей остается один, домены и базы находятся в общей панели, резервные копии делаются централизованно, а свободное место не простаивает на пяти разных тарифах. Если один сайт занимает 700 МБ, а другой 1,5 ГБ, нет особого смысла покупать каждому по 10 или 20 ГБ отдельно.
Но здесь есть ловушка. Надпись «до 20 сайтов» не означает, что тариф действительно способен комфортно обслуживать двадцать любых проектов. Двадцать небольших визиток и двадцать интернет-магазинов на WordPress создают совершенно разную нагрузку. Формально провайдер разрешает одинаковое количество сайтов, фактически во втором случае ресурсы могут закончиться задолго до того, как будет добавлен двадцатый домен.
Поэтому хостинг для нескольких сайтов стоит выбирать не по одной цифре в тарифной таблице. Нужно понимать, какие ресурсы проекты будут делить, насколько они изолированы друг от друга, как устроены резервные копии и что произойдет, если один сайт внезапно начнет потреблять слишком много CPU или будет взломан.
Можно ли держать несколько сайтов на одном хостинге
Да, и для большинства небольших проектов это совершенно нормальная практика. Один аккаунт виртуального хостинга может обслуживать несколько доменов, а каждый домен открывать свой независимый сайт. У проектов могут быть разные CMS, базы данных, почтовые ящики и SSL-сертификаты. Например, основной сайт компании работает на WordPress, второй представляет собой статический лендинг, а третий сделан на другой CMS. Технически им не обязательно находиться на разных хостингах.
Главное условие простое: выбранный тариф должен разрешать нужное количество сайтов. Провайдеры считают их по-разному. Где-то один тариф рассчитан на один проект, следующий на пять, более дорогой на несколько десятков. Встречаются планы, где количество сайтов формально не ограничено. Последняя формулировка звучит особенно привлекательно, но ее нельзя воспринимать буквально как возможность разместить сколько угодно полноценных проектов с любой посещаемостью.
У аккаунта все равно остаются конечные CPU, RAM, процессы, I/O, дисковое пространство и другие ограничения. «Неограниченное количество сайтов» обычно означает отсутствие отдельного счетчика сайтов, а не бесконечные ресурсы сервера.
Представим тариф с 20 ГБ диска и возможностью разместить десять сайтов. Если каждый проект занимает по 500 МБ, по объему все выглядит прекрасно. Но пять из них могут быть почти статичными, а шестой запускать тяжелый импорт каталога каждые полчаса. Именно этот один сайт способен занять значительную часть доступного процессора и замедлить остальные.
Поэтому правильнее рассматривать аккаунт как общий контейнер ресурсов. Все размещенные внутри проекты пользуются его возможностями. Чем больше сайтов, тем важнее не только максимальное разрешенное количество доменов, но и реальная нагрузка каждого из них.
Для владельца нескольких небольших сайтов такая схема обычно выгодна. Блог, визитка, лендинг, небольшой корпоративный сайт и тестовый проект способны годами спокойно работать в одном аккаунте. Особенно если они нормально оптимизированы, используют кэширование и не получают огромных всплесков посещаемости.
Есть и организационное преимущество. Продление одно, панель одна, настройки DNS и SSL находятся рядом, а при смене тарифа не приходится отдельно переносить каждый проект. Для человека, который самостоятельно обслуживает свои сайты, это заметно упрощает работу.
Но удобство начинает превращаться в риск, когда в одном аккаунте оказываются проекты разных владельцев или сайты с очень разной ценностью. Личный экспериментальный блог и интернет-магазин, который ежедневно принимает заказы, не всегда стоит держать в одной корзине только ради небольшой экономии.
Сколько сайтов реально выдержит один тариф
Самый неудобный, но правильный ответ: заранее назвать точное число невозможно. Если провайдер пишет «10 сайтов», это лишь административный предел тарифа. Он не обещает, что десять любых сайтов будут одновременно работать с одинаковой скоростью.
Небольшая статическая страница практически не создает динамической нагрузки. Хорошо кэшируемый WordPress-блог тоже может обслуживать заметную аудиторию довольно экономно. Интернет-магазин, форум, сайт объявлений или проект с личными кабинетами выполняет гораздо больше серверной работы.
Поэтому пять сайтов не обязательно тяжелее одного. Один плохо оптимизированный магазин способен потреблять больше ресурсов, чем десять аккуратных корпоративных сайтов.
При выборе тарифа полезно мысленно сложить не сайты, а их нагрузку. Сколько динамических запросов они выполняют? Есть ли WooCommerce? Используются ли тяжелые конструкторы страниц? Запускаются ли импорты и синхронизации? Как часто делаются резервные копии? Сколько почты хранится на аккаунте? Есть ли посещаемые разделы, которые невозможно нормально кэшировать?
Особенно важно понимать общий характер ресурсных ограничений. CPU, оперативная память, I/O и PHP-процессы обычно распределяются на аккаунт. Если один проект достигает потолка, последствия способны почувствовать остальные. Подробно механизм таких ограничений разобран в статье о ресурсах и лимитах хостинга.
Диск считается проще, но и здесь есть нюансы. В общий объем могут входить файлы всех сайтов, базы, почта, логи, кэш и иногда локальные резервные копии. Если тариф дает 30 ГБ, это не значит, что каждый из десяти сайтов получает по 30 ГБ. Все проекты делят один объем.
Для нескольких обычных сайтов 20-30 ГБ нередко оказывается большим запасом. WordPress-проект без огромной медиатеки может занимать всего несколько гигабайт. Но фотографии, почта и забытые архивы способны быстро изменить картину.
Есть еще inode, то есть ограничение на количество файлов. Десять установок WordPress создают значительно больше файлов, чем одна. К этому добавляются плагины, темы, кэш, миниатюры изображений и почта. Поэтому на многосайтовом аккаунте лимит файлов иногда становится важнее свободных гигабайт.
Отдельный вопрос, резервное копирование. Если ночью одновременно запускаются собственные плагины бэкапа на восьми сайтах, нагрузка может резко вырасти. Гораздо аккуратнее распределить задачи по времени или использовать систему резервного копирования самого провайдера, если она подходит по возможностям.
То же касается Cron. Когда каждый сайт имеет набор фоновых задач, случайное совпадение расписаний создает пик нагрузки. На одном проекте это незаметно, на десяти уже способно стать причиной периодических тормозов.
Поэтому оценивать вместимость тарифа лучше постепенно. Разместили несколько сайтов, посмотрели статистику CPU, памяти и диска, проверили пиковые часы. Если запас большой, добавляем следующие. Такой подход надежнее попытки заранее вычислить магическое число проектов по одной строке тарифной таблицы.
Когда один аккаунт действительно экономит деньги, а когда создает риск
Главная причина размещать несколько сайтов вместе очевидна: стоимость. Если каждый небольшой проект покупать на отдельном минимальном тарифе, значительная часть оплаченных ресурсов будет простаивать. Один более высокий тариф на 10-20 сайтов часто обходится дешевле нескольких отдельных аккаунтов.
Кроме денег экономится время. Не нужно помнить десять дат продления, переключаться между кабинетами и отдельно настраивать одинаковые вещи. Если провайдер позволяет создавать независимые сайты, базы, FTP-пользователей и SSL внутри одной панели, управление становится довольно удобным.
Для собственных проектов одного владельца это часто оптимальная схема. Например, у веб-мастера есть три информационных сайта, небольшой каталог и пара экспериментальных доменов. Все они умеренно посещаемые, не хранят критические персональные данные и не требуют особой серверной конфигурации. Покупать пять отдельных аккаунтов здесь действительно мало смысла.
Иная ситуация возникает с клиентскими сайтами. Если вы обслуживаете проекты разных компаний, общий аккаунт связывает их судьбу. Проблема с оплатой, блокировка аккаунта или серьезный технический сбой затрагивают сразу всех клиентов. Передача одного сайта другому специалисту тоже становится менее удобной.
Безопасность еще важнее. Современные хостинги используют различные механизмы изоляции, но конкретная архитектура зависит от провайдера. Если сайты одного аккаунта имеют доступ друг к другу на уровне файловой системы или используют общие учетные данные, заражение одного проекта может увеличить риск для остальных.
Поэтому для важных сайтов нужно проверить, как именно провайдер изолирует проекты внутри аккаунта. Хорошо, если можно использовать отдельные системные или FTP-пользователи, независимые базы и разные пароли. Совершенно точно не стоит подключать все WordPress к одной базе под одним пользователем только ради удобства.
Разделение особенно полезно, если проекты принадлежат разным людям. Владелец одного сайта не должен получать доступ к файлам остальных. Если тариф не позволяет организовать такие права нормально, экономия превращается в потенциальную проблему.
Есть еще фактор отказоустойчивости. Пять сайтов на одном аккаунте могут одновременно стать недоступными при проблеме сервера. Если эти проекты выполняют разные критичные функции, иногда разумно распределить их между площадками. Например, основной коммерческий сайт и независимый служебный сервис лучше не всегда держать в одной точке отказа.
Но и здесь не нужно впадать в крайность. Разносить три маленьких личных блога по трем провайдерам ради «географической отказоустойчивости» обычно только усложняет обслуживание. Архитектура должна соответствовать цене простоя.
Хороший компромисс выглядит так: связанные небольшие проекты одного владельца находятся вместе, а наиболее важные или клиентские сайты получают отдельную среду, когда это оправдано бизнесом и безопасностью.
Как выбрать хостинг для нескольких сайтов и не переплатить за лишнее
Первый параметр очевиден: разрешенное количество сайтов. Но смотреть на него нужно вместе с остальными характеристиками. Тариф «50 сайтов» с очень скромным CPU может быть менее полезен, чем план на 15 сайтов с заметно большим запасом ресурсов.
Дальше смотрите на диск. Для нескольких обычных WordPress-сайтов десятки гигабайт часто достаточны, но заранее оцените медиатеку и почту. Если на каждом проекте хранятся тысячи фотографий, документы или большие каталоги, объем становится существеннее. При этом 100 ГБ не должны отвлекать от процессорных ограничений.
Следующий вопрос, базы данных. В идеале каждый самостоятельный сайт получает собственную базу и отдельного пользователя. Если тариф разрешает 20 сайтов, но только пять баз, для некоторых сценариев это неудобное ограничение.
Полезны отдельные версии PHP для разных сайтов. Старый проект может временно требовать одну версию, новый другую. Если PHP переключается только сразу для всего аккаунта, обновление одного сайта способно создать проблемы другому.
Проверьте SSL. Бесплатный сертификат должен нормально выпускаться для каждого подключенного домена. Сегодня доплачивать за базовый HTTPS каждого нового сайта обычно нет причин.
Резервные копии для многосайтового аккаунта требуют особого внимания. Хорошо, если можно восстановить один сайт или одну базу, не откатывая весь аккаунт. Представьте, что плагин сломал только site3.ru. Возвращать вчерашнее состояние одновременно еще девяти проектам было бы очень неудобно.
По этой же причине полезно иметь возможность скачать отдельный бэкап. Резервные копии провайдера удобны, но критичные проекты лучше дополнительно сохранять вне основной площадки.
Посмотрите на панель управления. Когда сайтов много, мелкие неудобства умножаются. Быстрое создание домена, базы, почты, SSL и пользователя становится заметно ценнее красивой главной страницы кабинета.
Для WordPress полезна автоматическая установка, но еще полезнее возможность нормально обслуживать уже созданные проекты. Если провайдер предлагает staging или клонирование сайта, это может пригодиться для тестирования обновлений. Для пяти одинаковых проектов такая функция экономит заметно больше времени, чем для одного.
SSH и SFTP важны разработчикам и тем, кто обслуживает сайты профессионально. Git, Composer и консольные инструменты тоже могут стать критерием выбора, если проекты выходят за рамки простого WordPress из панели.
Не забудьте о технической поддержке. Когда в аккаунте десять сайтов, вопрос «какой из них создает нагрузку?» становится практическим. Хорошо, если панель показывает статистику по проектам или поддержка может помочь определить источник превышения.
И наконец, смотрите на следующий тариф. Сегодня у вас четыре сайта, через год может быть восемь. Если текущая линейка заканчивается на пяти, придется переносить проекты. Гораздо удобнее, когда можно увеличить ресурсы и лимит сайтов внутри того же аккаунта.
На Hostingi.org можно посмотреть актуальный рейтинг хостингов и уже после этого сравнить тарифы подходящих провайдеров именно по количеству сайтов, ресурсам и условиям масштабирования. Для нескольких проектов это полезнее, чем сортировать предложения только по минимальной цене.
Один большой тариф или VPS: где проходит граница
Когда сайтов становится много, VPS кажется естественным следующим шагом. Вместо ограничений shared-хостинга вы получаете виртуальный сервер с определенным количеством CPU, RAM и диска и можете размещать на нем столько проектов, сколько позволяют ресурсы и лицензии используемого ПО.
Но VPS не всегда дешевле и точно не всегда проще. На обычном виртуальном хостинге серверную часть обслуживает провайдер. Вам не нужно самостоятельно обновлять систему, настраивать веб-сервер, следить за службами и разбираться с базовой безопасностью инфраструктуры.
На VPS эти задачи либо переходят владельцу, либо оплачиваются как администрирование. Поэтому сравнивать нужно не только цену тарифа, но и стоимость обслуживания.
Если у вас десять небольших WordPress-сайтов, которые вместе используют небольшую часть ресурсов хорошего shared-тарифа, переезд на VPS может ничего не улучшить. Появится больше технической работы, а посетители не заметят разницы.
VPS становится интереснее, когда проекты регулярно упираются в лимиты виртуального хостинга, нужна нестандартная конфигурация, собственные службы или более предсказуемое распределение ресурсов. Также он удобен разработчикам и агентствам, которые умеют администрировать сервер или готовы платить за managed-обслуживание.
Еще один сценарий, большое количество сайтов. Если провайдер берет существенную доплату именно за число проектов, собственный VPS иногда экономически выгоднее. Но перед переездом стоит посчитать лицензии панели управления, резервное копирование, администрирование и время на обслуживание. Дешевый VPS без настройки не является полноценной заменой готовому хостингу.
Для владельца сайтов без серверного опыта хороший многосайтовый тариф часто остается наиболее практичным вариантом намного дольше, чем кажется. Он позволяет сосредоточиться на самих проектах, а не на обновлении Linux.
Именно поэтому границу лучше проводить не по количеству сайтов, а по совокупной нагрузке и требованиям. Пятнадцать легких сайтов могут прекрасно чувствовать себя на shared-хостинге. Один тяжелый проект способен потребовать VPS раньше них.
Какой вариант выбрать в итоге
Если у вас два, пять или даже десять небольших сайтов одного владельца, начинать стоит с виртуального хостинга, который разрешает нужное количество проектов и дает нормальный запас ресурсов. Это проще в обслуживании и обычно дешевле отдельных аккаунтов.
При этом не покупайте тариф только потому, что он обещает «безлимитные сайты». Смотрите на CPU, память, процессы, диск, inode, базы данных и резервное копирование. Именно эти параметры определят реальную вместимость аккаунта.
Для сайтов разных клиентов разделение становится важнее. Если проекты коммерческие и принадлежат независимым компаниям, отдельные аккаунты или хорошо изолированная серверная среда упрощают безопасность, передачу доступа и ответственность.
Критичный интернет-магазин тоже не обязательно должен жить рядом с десятком экспериментальных проектов. Цена его простоя выше, поэтому решение стоит принимать не только из расчета ежемесячной экономии.
Если сайты небольшие, но их количество постепенно растет, выбирайте провайдера с удобной линейкой тарифов. Возможность перейти с пяти сайтов на пятнадцать или тридцать без миграции часто ценнее скидки в несколько десятков рублей на старте.
И не пытайтесь заранее купить хостинг «на всю жизнь». Сегодня проектам достаточно одного тарифа, через два года требования могут полностью измениться. Нормальная стратегия проще: выбрать площадку с запасом, наблюдать за реальной нагрузкой и масштабироваться тогда, когда это подтверждают цифры.
В итоге хостинг для нескольких сайтов действительно позволяет заметно экономить. Но экономия появляется не тогда, когда на самый дешевый тариф пытаются уместить максимальное количество доменов. Она появляется тогда, когда несколько проектов разумно используют общий запас ресурсов, а владелец не платит за десятки пустующих отдельных аккаунтов.
Если тариф позволяет независимо управлять сайтами, дает достаточные ресурсы, нормальные бэкапы и простой переход на следующий уровень, держать несколько проектов вместе вполне рационально. А когда один из них вырастет и начнет требовать отдельной инфраструктуры, его всегда можно вынести. Это гораздо практичнее, чем с первого дня оплачивать каждому небольшому сайту собственный сервер.
