Один сайт редко остается единственным навсегда. К основному проекту появляется лендинг, затем блог, сайт другого направления бизнеса, тестовый домен или небольшой интернет-магазин. Покупать отдельный хостинг для каждого кажется странным, поэтому владелец начинает искать тариф, на котором можно разместить все сразу.
Первым делом взгляд цепляется за строку «количество сайтов». Если хостер разрешает десять, двадцать или вообще не ограничивает число доменов, вопрос вроде бы решен.
На самом деле это только начало.
Десять сайтов в панели управления не означают десять независимых наборов ресурсов. На виртуальном хостинге проекты одного аккаунта обычно делят между собой доступную вычислительную мощность, память и другие ограничения. Поэтому хороший тариф для нескольких сайтов выбирают не по максимальному числу доменов, а по тому, насколько комфортно вся эта группа сможет работать вместе.
Сначала посчитайте не сайты, а их характер
Пять лендингов и пять интернет-магазинов являются пятью сайтами только с точки зрения счетчика в панели. Для сервера это совершенно разная нагрузка.
Небольшой корпоративный сайт может получать несколько десятков динамических запросов в час. Магазин в это же время обрабатывает поиск, фильтры, корзину, личные кабинеты, фоновые задания и обмен данными с внешними системами.
Поэтому перед выбором тарифа я бы составила простой список проектов и напротив каждого отметила:
- какая CMS или технология используется;
- сколько места занимают файлы и база;
- есть ли интернет-магазин или личный кабинет;
- насколько сайт посещаемый;
- работают ли импорт, cron и другие фоновые задачи;
- насколько критичен простой этого проекта.
После такого списка может выясниться, что девять сайтов почти ничего не требуют, а десятый создает большую часть всей нагрузки. Именно он и определит выбор тарифа.
Разрешенное количество сайтов не равно производительности
Формулировки «до 20 сайтов» или «неограниченное количество сайтов» описывают возможность добавить домены в аккаунт. Они не отменяют ограничения процессора, оперативной памяти, числа процессов, дисковых операций и других ресурсов.
Это особенно важно для безлимитных тарифов.
Если провайдер не ограничивает число сайтов, это не означает, что один аккаунт способен обслуживать бесконечное количество тяжелых проектов. Физический сервер все равно имеет конечную мощность, а shared hosting построен на совместном использовании инфраструктуры.
Поэтому после строки о количестве сайтов ищите условия нагрузки. На Hostingi.org мы отдельно разбирали лимиты CPU, RAM и процессов, потому что именно эти параметры часто объясняют, почему внешне просторный тариф оказывается тесным.
Для нескольких сайтов вопрос становится еще важнее: ресурсы расходуются не по очереди, а тогда, когда они нужны проектам.
Общие ресурсы создают эффект соседей внутри собственного аккаунта
Обычно о «соседях по хостингу» говорят как о других клиентах сервера. Но при нескольких проектах похожая ситуация может возникнуть внутри одного аккаунта.
Допустим, ночью один сайт создает резервную копию, второй обновляет каталог товаров, а третий запускает тяжелую задачу по расписанию. Если все это происходит одновременно, нагрузка складывается.
В результате четвертый сайт, на котором вообще ничего необычного не происходило, может начать отвечать медленнее.
Это не обязательно означает плохой хостинг. Иногда владелец сам собрал все ресурсоемкие задания в один временной интервал.
Простое разнесение cron, импортов и резервного копирования по времени способно заметно сгладить пики.
Если же один проект постоянно забирает значительную часть доступных ресурсов, его имеет смысл рассматривать отдельно от остальных.
Диска должно хватать не только на файлы сайтов
Суммировать размер каталогов недостаточно.
На хостинге место занимают базы данных, почта, журналы, временные файлы и иногда локальные резервные копии. WordPress создает дополнительные размеры изображений, плагины могут хранить кэш, а магазин постепенно накапливает медиатеку.
Поэтому тариф, который сегодня заполнен на 90 процентов, плохо подходит для группы растущих проектов, даже если формально все сайты на нем помещаются.
Стоит посмотреть и на ограничение количества файлов или inode. Несколько WordPress-сайтов с кэшем и большой медиатекой способны создать огромное число небольших файлов задолго до исчерпания гигабайтов.
Большой диск сам по себе тоже не повод переплачивать. Если пять сайтов вместе занимают несколько гигабайт и растут медленно, огромный запас хранилища не компенсирует слабые вычислительные лимиты.
Разные сайты могут требовать разные версии PHP
Этот пункт легко забыть, пока все проекты новые.
Через несколько лет один сайт может работать на актуальной версии PHP, другой зависеть от старого расширения, а третий находиться в процессе обновления. Если хостинг позволяет выбирать версию PHP отдельно для каждого сайта, обслуживать такую группу значительно проще.
Но старую версию не стоит сохранять бесконечно только ради совместимости. Неподдерживаемое программное обеспечение является риском безопасности. Лучше обновить CMS, тему или плагин, который мешает переходу.
Перед покупкой полезно проверить не только список доступных версий PHP, но и способ их назначения. Настройка на уровне отдельного домена удобнее, чем одна версия на весь аккаунт.
Если среди проектов есть приложения не на PHP, требования становятся еще важнее. Поддержка Python или Node.js на виртуальном хостинге может отличаться по возможностям от полноценного VPS.
Отдельная база для каждого сайта упрощает жизнь
Технически некоторые проекты можно заставить использовать одну базу с разными префиксами таблиц. Для нескольких независимых сайтов это редко дает полезное преимущество.
Отдельные базы и учетные записи делают структуру понятнее. Проще переносить один проект, создавать резервную копию, выдавать доступ разработчику и восстанавливать данные.
Поэтому количество доступных баз данных имеет смысл сравнить с количеством проектов.
Важно и ограничение самой СУБД. Некоторые тарифы задают лимиты на размер базы, число одновременных соединений или нагрузку MySQL. Для обычного небольшого сайта они могут никогда не стать заметными, но несколько активных магазинов создают совсем другой сценарий.
Один аккаунт удобен до первой проблемы с безопасностью
Размещение всех сайтов вместе упрощает управление. Один вход в панель, один файловый менеджер, одна учетная запись для оплаты.
Но чем больше проектов собрано в одном месте, тем важнее их изоляция.
Если зараженный сайт способен изменять файлы соседнего проекта, компрометация одного WordPress превращается в проблему всего аккаунта. Поэтому стоит выяснить, как хостинг разделяет сайты и пользователей.
Особенно осторожно я бы объединяла проекты разных владельцев. Свои пять сайтов и пять клиентских сайтов представляют разные уровни ответственности.
Разработчику или небольшой веб-студии иногда удобнее использовать отдельные аккаунты или реселлерскую модель, чтобы доступ клиента к одному проекту не открывал остальные.
Даже внутри собственного аккаунта не стоит использовать одинаковые пароли администратора WordPress, базы или FTP для всех сайтов.
Резервное копирование нужно проверять до переноса
Когда на одном хостинге находится один небольшой сайт, ручная копия кажется терпимой. Когда сайтов десять, ручная рутина быстро перестает работать.
Я бы обязательно проверила, делает ли провайдер автоматические резервные копии файлов и баз, сколько версий хранится и можно ли восстановить один конкретный сайт, не затрагивая остальные.
Последний момент особенно важен.
Если сломался один WordPress, не хочется откатывать весь аккаунт вместе с девятью нормально работающими проектами.
И резервные копии самого хостера лучше не считать единственной защитой. Для важных сайтов полезно иметь независимую копию вне основного аккаунта.
Несколько проектов увеличивают цену одной ошибки, поэтому резервирование становится важнее, а не менее важным.
Почта тоже может съедать ресурсы тарифа
Хостинг для сайтов часто одновременно используется как почтовая площадка. На одном домене два ящика, на другом десять, на третьем сотрудники годами хранят вложения.
Через некоторое время оказывается, что значительная часть диска занята вообще не сайтами.
При выборе тарифа посмотрите, считается ли почта в общий объем, есть ли отдельные квоты и сколько ящиков разрешено создавать.
Для бизнеса с большим объемом переписки может быть удобнее специализированный почтовый сервис. Тогда смена веб-хостинга не затрагивает корпоративную почту, а файлы писем не конкурируют с сайтами за дисковое пространство.
Но для нескольких небольших проектов встроенной почты хостинга вполне может хватать. Здесь опять нет универсального правильного варианта.
Одна панель управления действительно удобнее нескольких
Это главный практический аргумент в пользу объединения небольших сайтов.
Домены, SSL, базы, резервные копии, файловый менеджер, cron и статистика находятся в одном месте. Не нужно помнить, у какого провайдера размещен очередной лендинг и где оплачивается его тариф.
Особенно удобно, если хостинг позволяет быстро копировать сайт, создавать тестовые поддомены и переносить проекты между каталогами.
Но централизация работает в обе стороны. Ошибка с оплатой, блокировка аккаунта или серьезный сбой затрагивают сразу всю группу.
Поэтому критичные проекты не всегда стоит складывать в одну корзину только ради удобства панели.
Когда большой тариф уже хуже небольшого VPS
Представим, что сайты постепенно росли. Вы несколько раз переходили на следующий тариф, увеличивали доступные ресурсы, но один магазин продолжает регулярно упираться в ограничения.
В этот момент возникает выбор: искать еще более производительный виртуальный хостинг или переходить на VPS.
VPS дает больше контроля над серверным окружением и более предсказуемую модель ресурсов. На нем можно самостоятельно настроить веб-сервер, версии программ, кэш и ограничения отдельных проектов.
Но вместе с этим появляется администрирование. Если никто не хочет заниматься Linux, обновлениями и безопасностью, хороший виртуальный хостинг может оставаться более практичным решением.
Есть и промежуточный вариант: вынести на VPS только самый тяжелый сайт, а остальные небольшие проекты оставить на shared hosting.
Часто это рациональнее, чем переносить всю коллекцию из-за одного выросшего магазина.
Как я бы выбирала тариф для нескольких сайтов
Сначала отсеяла бы варианты, которые физически не позволяют разместить нужное количество доменов и баз.
Затем проверила бы суммарный объем данных с запасом на рост. После этого перешла бы к тому, что обычно написано менее крупным шрифтом: CPU, память, процессы, ограничения базы и дисковых операций.
Дальше посмотрела бы на возможность выбирать PHP для каждого сайта, автоматические SSL, резервное копирование, SSH, cron и удобство панели.
Если проекты коммерческие, отдельно оценила бы поддержку. Когда на одном аккаунте находится несколько рабочих сайтов, хороший ответ технического специалиста ценнее небольшого различия в объеме диска.
И обязательно проверила бы возможность быстро перейти на более мощный тариф без ручного переноса всех проектов.
Это позволяет начать без огромного запаса «на всякий случай» и увеличивать ресурсы только тогда, когда они действительно понадобятся.
Не все сайты обязательно должны жить вместе
Удобство одного аккаунта легко превращается в привычку. Появился новый проект — автоматически добавляем его туда же.
Лучше иногда пересматривать эту схему.
Небольшие информационные сайты одного владельца действительно удобно держать вместе. Критичный интернет-магазин, экспериментальный проект с неизвестным кодом и клиентский сайт уже не выглядят идеальными соседями.
Разделять можно по нагрузке, владельцам, требованиям безопасности или важности.
Такой подход не требует отдельного сервера для каждого домена. Иногда достаточно двух аккаунтов виртуального хостинга или связки обычного хостинга и VPS.
Главное, чтобы один проблемный проект не создавал ненужный риск для всех остальных.
Поэтому лучший хостинг для нескольких сайтов не тот, где крупнее написано «безлимитно». Хороший вариант позволяет удобно управлять проектами, дает достаточно общих ресурсов, не мешает разделять их настройки и оставляет понятный путь для роста.
Если сегодня у вас три небольших сайта, нет смысла покупать инфраструктуру для тридцати тяжелых магазинов. Выберите тариф с разумным запасом и возможностью перейти выше. А когда один из проектов действительно перерастет соседей, его всегда можно вынести отдельно.
