Письмо с темой вроде «Ваш хостинг успешно активирован» создает приятное ощущение, что половина работы уже сделана. Есть сервер, есть логин с паролем, в панели управления появились какие-то гигабайты, базы данных, PHP, FTP и DNS. Остается загрузить сайт, и можно заниматься содержанием.
Именно в этот момент проще всего заложить несколько проблем, которые проявятся не сегодня.
Через полгода окажется, что пароль от хостинга известен еще трем людям, один из которых давно не работает над проектом. Резервные копии вроде бы создавались, но восстановить нужную версию сайта невозможно. Домен зарегистрирован на старую почту. WordPress отправляет письма через обычную PHP-функцию, и половина сообщений из формы обратной связи не доходит. В корневой папке лежит забытый архив сайта с базой данных, а административная панель до сих пор доступна по паролю, который использовался еще на предыдущем проекте.
Ничего из этого не происходит потому, что владелец сайта сделал что-то особенно глупое. Просто после покупки хостинга обычно хочется быстрее увидеть работающую страницу, а не тратить вечер на DNS, бэкапы и двухфакторную авторизацию.
Но именно первые настройки определяют, насколько спокойно сайт будет жить дальше.
Поэтому разберем не только, как привязать домен и установить CMS, а весь путь от первого входа в панель хостинга до состояния, когда сайт уже можно считать нормально подготовленным к работе.
Сохраните данные от хостинга там, где вы действительно их найдете
Первое письмо провайдера часто содержит адрес панели управления, логин, технический домен, данные FTP или SSH, DNS-серверы и другую служебную информацию.
Худшее место для постоянного хранения этих данных — само письмо.
Через два года почтовый ящик может измениться, письмо случайно удалится, а доступ к старой почте потеряется. Еще хуже хранить пароль в текстовом файле «пароли.txt» на рабочем столе или отправлять его самому себе в мессенджере.
Для учетных данных лучше использовать менеджер паролей. Там можно сохранить адрес панели, логин, пароль и небольшую заметку с названием проекта.
Если сайтом занимается несколько человек, не нужно выдавать всем основной пароль владельца аккаунта. Проверьте, позволяет ли провайдер создавать дополнительные учетные записи или разграничивать доступ.
Главный аккаунт должен оставаться главным.
И обязательно посмотрите, на какую электронную почту зарегистрирован хостинг. Именно туда будут приходить сообщения о продлении, превышении ресурсов, технических работах и попытках восстановления доступа.
Старая почта, которую никто не проверяет, для такого аккаунта не подходит.
Сразу включите двухфакторную аутентификацию
Если панель хостинга поддерживает 2FA, включить ее стоит до загрузки сайта.
Пароль можно подобрать, украсть через вредоносное ПО, получить из утечки другого сервиса или случайно оставить сохраненным на чужом компьютере. Второй фактор значительно усложняет вход даже при компрометации пароля.
Особенно критично защищать аккаунт, если в нем находятся сразу несколько сайтов и доменов.
Получив доступ к панели хостинга, злоумышленник иногда получает значительно больше возможностей, чем при взломе одной административной учетной записи WordPress. Он может изменять файлы, базы данных, DNS, почту и другие настройки.
Коды восстановления 2FA тоже нужно сохранить. Желательно не на том же телефоне, где находится приложение-аутентификатор.
Без резервных кодов потерянный телефон способен превратить полезную защиту в неприятный разговор с поддержкой о восстановлении аккаунта.
Проверьте, на кого зарегистрирован домен
Если домен уже куплен, перед привязкой к новому хостингу полезно проверить учетную запись регистратора.
Домен и хостинг — разные услуги. Сервер можно сменить за несколько часов, а доменное имя остается постоянным адресом проекта. Подробно устройство доменных имен и связанные с ними настройки разобраны в материале «Домены от А до Я».
Для коммерческого сайта домен должен находиться под контролем владельца проекта, а не бывшего разработчика, рекламного агентства или сотрудника, который когда-то «быстро все зарегистрировал».
Проверьте контактные данные, почту аккаунта и дату окончания регистрации.
Если провайдер позволяет включить автоматическое продление, это может быть полезной страховкой. Но даже при автопродлении лучше поставить собственное напоминание заранее.
Банковская карта заканчивается, платеж отклоняется, баланс оказывается пустым — автоматизация тоже иногда не срабатывает.
Потерять домен из-за пропущенного платежа гораздо обиднее, чем несколько минут потратить на календарное напоминание.
Привяжите домен к хостингу через DNS
Домен сам по себе не знает, на каком сервере находится сайт. Эту связь обеспечивает DNS.
Обычно после покупки хостинга провайдер предлагает один из двух вариантов: заменить NS-серверы домена на его собственные или оставить текущие DNS-серверы и изменить необходимые записи вручную.
Для новичка первый вариант часто проще.
Регистратор домена предоставляет раздел управления DNS или серверами имен. Туда нужно внести NS, указанные хостером. После этого DNS-зоной будет управлять хостинг.
Но изменения распространяются не мгновенно.
Информация DNS кэшируется на разных уровнях, поэтому некоторое время один пользователь может уже попадать на новый сервер, а другой — еще на старый.
Именно поэтому после изменения DNS не стоит через пять минут решать, что «ничего не работает», и хаотично менять настройки обратно.
Если домен и хостинг только что куплены и никакого старого сайта нет, задержка обычно просто означает ожидание обновления DNS.
При переносе существующего проекта ситуация сложнее. В таком случае лучше заранее подготовить новый сервер, протестировать копию сайта и только затем переключать DNS. Для этого на Hostingi.org есть отдельная инструкция о том, как перенести сайт на новый хостинг.
Не забудьте про www
Адреса site.ru и www.site.ru технически являются разными именами.
Сегодня большинство проектов использует основной вариант без www, но принципиальной разницы для обычного сайта нет. Важно другое — выбрать один основной адрес.
Если главным является https://site.ru, запрос к https://www.site.ru должен корректно перенаправляться на него.
И наоборот.
Не нужно оставлять две независимые версии одной страницы. Это создает лишнюю путаницу для пользователей, аналитики и поисковых систем.
После настройки обязательно вручную откройте оба варианта адреса и убедитесь, что один автоматически приводит ко второму.
Создайте отдельный сайт в панели управления
У разных хостеров структура панели отличается, но логика похожа. Нужно добавить домен, указать папку сайта и выбрать необходимые параметры окружения.
Не стоит сваливать несколько независимых проектов в одну общую директорию.
У каждого сайта должна быть понятная собственная папка.
Это упрощает резервное копирование, перенос, работу разработчика и поиск файлов. А если хостинг поддерживает изоляцию сайтов, ее желательно использовать.
Изоляция особенно полезна при размещении нескольких WordPress-проектов в одном аккаунте. Уязвимость одного сайта в таком случае имеет меньше шансов стать входной точкой для заражения соседних проектов.
Если возможность изоляции существует, но отключена по умолчанию, стоит изучить ее до установки CMS.
Выберите актуальную версию PHP
Для PHP-сайта необходимо проверить версию интерпретатора.
Не нужно автоматически выбирать самую старую только потому, что «на ней точно все работает». Устаревшие версии перестают получать исправления безопасности.
Но и переключать существующий старый сайт на самую новую версию без проверки нельзя.
Для нового WordPress или другой современной CMS разумно использовать поддерживаемую версию PHP, совместимую с текущей версией движка и используемыми расширениями.
На хорошем виртуальном хостинге версию PHP обычно можно менять отдельно для каждого сайта.
Это особенно удобно, если в одном аккаунте находится несколько проектов разного возраста.
После переключения версии нужно проверить не только главную страницу, но и административную часть, формы, поиск, корзину и другие динамические функции.
Установите SSL до начала нормальной работы сайта
HTTPS лучше настраивать сразу, а не «когда-нибудь перед запуском».
Большинство современных хостингов позволяет бесплатно выпустить сертификат Let’s Encrypt прямо из панели. Подробно о принципах работы сертификатов и HTTPS можно прочитать в статье «SSL-сертификат: почему ваш сайт больше не может обходиться без HTTPS».
После выпуска сертификата нужно настроить перенаправление HTTP на HTTPS.
Проверяем четыре варианта:
http://site.ru
http://www.site.ru
https://site.ru
https://www.site.ru
В идеале все они должны привести пользователя к одному выбранному каноническому адресу.
Также убедитесь, что сертификат продлевается автоматически. Let’s Encrypt выпускается на ограниченный срок, поэтому ручное продление каждые несколько месяцев совершенно не нужно, если платформа умеет делать это сама.
После включения HTTPS откройте сайт и посмотрите консоль браузера. Если отдельные изображения, стили или скрипты продолжают загружаться по HTTP, появляется смешанный контент.
Его нужно исправить.
Создайте базу данных и отдельного пользователя
WordPress и большинство других CMS используют базу данных.
При создании базы хостинг обычно предлагает задать ее имя, пользователя и пароль.
Пароль должен быть случайным и сложным. Запоминать его не требуется — приложение хранит данные подключения в конфигурационном файле.
Не используйте что-нибудь вроде 12345678, название сайта или тот же пароль, что от панели хостинга.
Если в аккаунте несколько проектов, лучше создавать отдельную базу и отдельного пользователя для каждого.
Это облегчает перенос и уменьшает последствия компрометации одной учетной записи.
Имена тоже лучше делать понятными. Через два года db1, db2, db3 уже ничего не скажут, тогда как аккуратная система именования позволит быстро понять, какая база относится к какому проекту.
Устанавливать WordPress автоматически или вручную
Практически каждый массовый хостинг предлагает установку WordPress в несколько кликов.
Для обычного нового сайта в этом нет ничего плохого.
Автоустановщик создает базу, загружает файлы, формирует конфигурацию и экономит время. Новичку такой вариант обычно удобнее ручной установки.
Но не нажимайте «Далее» автоматически на каждом экране.
Посмотрите, какое имя получает администратор, какой пароль создается, куда устанавливается CMS и какие дополнительные плагины предлагается добавить.
Логин admin лучше не использовать, особенно если система позволяет сразу выбрать другой.
Также не нужно устанавливать десяток «рекомендованных» расширений только потому, что возле них стоят галочки.
Начните с чистой системы.
Добавить плагин потом занимает минуту. Разбираться, зачем на новом сайте уже установлено двенадцать неизвестных расширений, гораздо менее приятно.
Если вы только выбираете площадку для WordPress, отдельное руководство по выбору хостинга для WordPress поможет заранее оценить PHP, базы данных, бэкапы и другие важные параметры.
Сразу удалите все, что не используется
После установки CMS полезно провести маленькую уборку.
Удалите ненужные плагины, лишние темы и демонстрационный контент.
«Отключен» и «удален» — не одно и то же.
Файлы отключенного плагина по-прежнему находятся на сервере. Если в старой версии расширения обнаружится уязвимость, сам факт того, что плагин не активирован, не всегда является достаточной причиной хранить его годами.
То же относится к тестовым файлам и архивам.
Очень плохая привычка — оставить в публичной папке site-backup.zip, old.zip, backup.sql или другой архив с данными.
Если веб-сервер позволяет скачать такой файл по прямой ссылке, внутри может оказаться весь исходный код или база с конфиденциальной информацией.
Архивы для переноса после использования нужно удалить из публичной директории.
Настройте резервное копирование до первого серьезного изменения
Бэкап нужен не после того, как сайт стал важным. Он нужен до этого.
Сегодня на сайте пять страниц. Завтра появляется каталог, формы, комментарии, заказы и месяцы работы редактора.
Чем раньше настроено резервирование, тем меньше вероятность, что однажды придется вспоминать: «Кажется, хостинг что-то копировал автоматически».
Сначала выясните, какие резервные копии уже делает провайдер.
Нужно знать частоту, срок хранения и способ восстановления.
Затем желательно организовать независимую копию вне основного аккаунта. Подробная схема создания и восстановления резервов разобрана в руководстве как сделать бэкап сайта и восстановить его из резервной копии.
Для WordPress можно использовать автоматическую выгрузку копий в отдельное облачное хранилище. Hostingi.org также публиковал отдельную инструкцию по резервному копированию WordPress в облако.
Главное правило простое: рабочий сайт и единственная его резервная копия не должны зависеть от одной и той же точки отказа.
Один раз попробуйте восстановить бэкап
Наличие файла с названием backup еще не означает наличие работающей резервной копии.
Архив может оказаться поврежденным. Дамп базы — неполным. Плагин резервирования — создавать файлы, которые владелец не умеет восстанавливать.
Поэтому после первоначальной настройки полезно хотя бы один раз пройти процедуру восстановления на тестовой копии.
Это не паранойя.
В момент настоящей аварии гораздо спокойнее повторить знакомую процедуру, чем впервые читать инструкцию, пока рабочий сайт показывает ошибку.
Особенно важно тестировать восстановление интернет-магазинов и проектов, где данные постоянно меняются.
Создайте почту на своем домене
Для коммерческого сайта адрес info@site.ru выглядит естественнее личного почтового ящика.
Но прежде чем создавать десяток адресов, решите, где вообще будет жить корпоративная почта.
Можно использовать почтовую систему самого хостинга или отдельного поставщика.
Для небольшого проекта встроенной почты часто достаточно.
Создайте только действительно необходимые ящики: например, info, support или персональные адреса сотрудников.
Обязательно настройте SPF, DKIM и DMARC, если почтовая система и DNS позволяют это сделать.
Эти механизмы помогают принимающим серверам понять, какие источники имеют право отправлять письма от имени вашего домена.
Без нормальной настройки почты сообщения могут чаще попадать в спам.
Не отправляйте важную почту WordPress как попало
Форма обратной связи показывает «Сообщение успешно отправлено».
Владелец сайта уверен, что заявка пришла.
Клиент уверен, что заявка пришла.
А письма нет.
Это одна из самых неприятных проблем нового сайта.
WordPress по умолчанию может использовать серверный механизм отправки почты, но для важных уведомлений надежнее настроить нормальную SMTP-отправку через почтовый аккаунт или специализированный сервис.
После настройки обязательно протестируйте формы.
Причем не только на один адрес.
Отправьте сообщение на несколько популярных почтовых систем и посмотрите, куда оно попало — во входящие или спам.
Если сайт продает товары, отдельно проверьте уведомления о заказах, регистрации и восстановлении пароля.
Настройте Cron, если сайт использует задачи по расписанию
Cron позволяет запускать команды и скрипты автоматически.
На небольшом сайте он может использоваться почти незаметно. На более сложном проекте через него выполняются импорты, создание резервных копий, обновление данных, очистка временных файлов и другие процессы.
После переноса существующего сайта обязательно проверьте старые cron-задачи.
Файлы можно скопировать идеально, базу импортировать без единой ошибки, но забытый Cron способен через сутки напомнить о себе отсутствующим импортом каталога.
Для нового проекта не нужно создавать задания «на всякий случай».
Настраивайте только то, что действительно требуется CMS или конкретному приложению.
Проверьте права доступа к файлам
На Linux-серверах файлы и каталоги имеют права доступа.
Устанавливать 777 на все подряд ради решения ошибки — плохая идея.
Такой совет до сих пор встречается в старых инструкциях: если приложение не может записать файл, предлагается просто открыть полный доступ.
Правильнее определить, какому пользователю принадлежит каталог и какие права действительно необходимы.
На обычном виртуальном хостинге автоустановщик CMS обычно создает корректные права самостоятельно.
Если после ручной загрузки сайт требует 777, лучше разобраться с владельцем файлов и настройками окружения, чем превращать всю директорию в открытую площадку для записи.
Не храните пароли внутри файлов, доступных из браузера
CMS неизбежно хранит данные подключения к базе в конфигурационном файле. Это нормально, если веб-сервер настроен правильно.
Совсем другое дело — самостоятельно создать passwords.txt, config-old.txt или резервную копию конфигурации в публичной директории.
Не нужно также оставлять старые файлы вида wp-config.php.bak.
В зависимости от конфигурации сервера файл с необычным расширением может отдаваться пользователю как обычный текст.
Внутри окажутся данные базы.
Все служебные копии лучше хранить вне публичного каталога сайта.
Включите автоматические обновления осознанно
Обновления закрывают уязвимости, поэтому годами держать старую CMS и плагины нельзя.
Но схема «автоматически обновлять абсолютно все в любое время» подходит не каждому проекту.
На простом блоге автоматические обновления WordPress и проверенных плагинов обычно удобны.
На интернет-магазине, где изменение одного расширения способно затронуть корзину или оплату, разумнее иметь тестовую среду и резервную копию перед серьезными обновлениями.
Важно найти баланс.
Не обновлять ничего — опасно.
Обновлять все без возможности отката — тоже рискованно.
Минимум, который нужен любому сайту, — рабочий бэкап перед значительным обновлением.
Удалите стандартного администратора и создайте нормальные учетные записи
Если CMS создала пользователя admin, лучше использовать другое имя администратора.
Это не превращает WordPress в неприступную крепость, но убирает очевидный логин из автоматических попыток входа.
Каждому человеку, который работает с сайтом, лучше создать отдельную учетную запись.
Редактору не нужны права администратора, если он только публикует статьи.
Контент-менеджеру интернет-магазина тоже необязательно разрешать установку плагинов.
Принцип минимальных привилегий прост: пользователь получает только те возможности, которые нужны ему для работы.
И никогда не используйте одну учетную запись администратора на пятерых сотрудников.
После увольнения одного человека придется менять пароль для всех, а определить автора конкретного действия в журнале будет невозможно.
Проверьте ограничения хостинга
После установки сайта полезно найти раздел статистики ресурсов.
Посмотрите, что показывает панель: CPU, RAM, дисковое пространство, количество процессов, нагрузку на базу и трафик.
Не нужно ежедневно сидеть перед этими графиками.
Задача первого знакомства — понять, где они находятся и как выглядит нормальное состояние сайта.
Тогда через несколько месяцев, если проект начнет тормозить, появится точка сравнения.
Заодно прочитайте, что происходит при превышении лимитов.
Хостинг может ограничивать процессы, временно снижать доступные ресурсы или рекомендовать переход на другой тариф.
Лучше узнать правила до первого пика посещаемости.
Проверьте скорость нового сайта до наполнения
Очень полезно измерить производительность, пока проект еще относительно чистый.
Если пустой WordPress уже отвечает медленно, после установки тяжелой темы, магазина и двадцати плагинов быстрее он точно не станет.
Проверьте время ответа сервера и загрузку нескольких страниц.
Сохраните результаты.
После настройки темы и основных расширений повторите тест.
Так можно заметить момент, когда сайт начал становиться тяжелее.
Если аудитория находится в разных регионах или странах, в дальнейшем может пригодиться CDN для ускорения доставки контента. Но подключать CDN к новому небольшому сайту только потому, что аббревиатура звучит технологично, необязательно.
Сначала измеряется реальная проблема, потом выбирается решение.
Не устанавливайте плагин кэширования просто потому, что «так надо»
Кэш действительно способен значительно ускорить динамический сайт.
Но современные хостинги могут уже использовать серверное кэширование, Redis, собственные плагины или другие механизмы.
Если поверх одного решения без понимания установить второе, а затем добавить CDN с третьим кэшем, поиск причины устаревшей страницы становится занимательным квестом.
Сначала узнайте рекомендации своего хостинга.
Для WordPress провайдер иногда предлагает конкретный совместимый плагин.
После настройки проверьте сайт в режиме авторизованного и обычного пользователя, очистите кэш и убедитесь, что изменения контента появляются ожидаемо.
Подключите мониторинг доступности
Владелец не может круглосуточно обновлять главную страницу и проверять, работает ли сайт.
Для этого существуют сервисы мониторинга.
Они регулярно обращаются к заданному URL и отправляют уведомление, если сайт перестает отвечать.
Даже простого внешнего мониторинга достаточно, чтобы обнаружить ночные сбои, о которых иначе никто не узнает.
Он также помогает при разговоре с поддержкой.
«Сайт иногда не работает» — слишком неопределенное описание.
«24 августа с 03:17 до 03:29 сервер возвращал 503» — уже конкретный факт, который можно проверять по логам.
Добавьте сайт в Яндекс Вебмастер
Для сайта, ориентированного на русскоязычную аудиторию, Яндекс Вебмастер стоит подключить сразу после запуска.
Сервис позволяет подтвердить права на сайт, контролировать индексирование, видеть диагностические сообщения, проверять страницы и отслеживать технические проблемы.
После добавления нужно указать актуальный sitemap.xml, проверить robots.txt и убедиться, что поисковому роботу не запрещен доступ к рабочему сайту.
Последняя проблема встречается чаще, чем кажется.
Во время разработки сайт закрывают от индексации, а после запуска забывают снять запрет.
В результате страницы работают, посетители по прямой ссылке их видят, но поисковый робот получает указание не индексировать проект.
Проверьте robots.txt после запуска
robots.txt выглядит маленьким и безобидным файлом, но одна строка способна закрыть от обхода весь сайт.
Перед открытием проекта проверьте его вручную.
Особенно если сайт переносился с тестового домена или разработчик специально запрещал индексацию во время работы.
Для WordPress дополнительно посмотрите настройку «Видимость для поисковых систем».
Не нужно слепо копировать robots.txt с чужого сайта. Правила зависят от структуры проекта.
Цель файла — управлять обходом, а не создавать максимально длинный список запретов.
Создайте sitemap.xml и проверьте его
Карта сайта помогает поисковым роботам находить URL проекта.
Современный WordPress умеет создавать XML-карту самостоятельно, а SEO-плагины предлагают собственные варианты.
Важно не количество карт, а корректность одной используемой системы.
Откройте sitemap.xml или адрес карты, который генерирует CMS, и убедитесь, что он работает.
В карте не должны массово присутствовать технические, тестовые или ненужные страницы.
После этого sitemap можно отправить в Яндекс Вебмастер и другие используемые инструменты поисковых систем.
Настройте канонический адрес сайта
Если одна страница доступна по нескольким URL, поисковой системе нужно понимать, какой вариант является основным.
Часть задачи решается правильными редиректами HTTP/HTTPS и www/без www.
Для страниц CMS также используются canonical-ссылки.
Большинство современных SEO-плагинов WordPress управляет ими автоматически, но после запуска полезно открыть исходный код нескольких страниц и убедиться, что canonical указывает туда, куда нужно.
Особенно внимательно это проверяется у интернет-магазинов с фильтрами, параметрами и сортировкой.
Не открывайте тестовый сайт для поисковых роботов
При разработке часто создается технический адрес вроде new.site.ru, dev.site.ru или домен, предоставленный хостингом.
Если поисковик успеет проиндексировать тестовую копию, в выдаче могут появиться дубли будущего рабочего сайта.
Тестовую среду лучше защищать авторизацией.
Один robots.txt не является полноценной защитой от постороннего доступа.
Если внутри тестовой версии находятся реальные данные клиентов или заказы, она вообще не должна быть публично доступна.
После запуска рабочей версии тестовую копию либо закрывают, либо удаляют, если она больше не нужна.
Проверьте страницы ошибок
Введите адрес заведомо несуществующей страницы.
Сайт должен вернуть нормальную ошибку 404, а не перенаправить пользователя на главную без объяснения причин.
Затем, если есть возможность, проверьте обработку серверных ошибок.
Хорошая страница 404 помогает посетителю вернуться в рабочую часть сайта, но не должна маскировать сам HTTP-статус.
Для поисковой системы важно, чтобы отсутствующий URL действительно сообщал об отсутствии страницы.
Красивый текст «Ничего не найдено» с кодом 200 технически остается обычной успешной страницей.
Проверьте формы так, как будто вы настоящий клиент
Не ограничивайтесь кнопкой «Отправить».
Заполните форму правильно.
Оставьте обязательное поле пустым.
Введите неправильный email.
Отправьте сообщение с телефона.
Проверьте, пришло ли письмо владельцу.
Посмотрите, получил ли пользователь подтверждение, если оно предусмотрено.
Проверьте страницу благодарности и цели аналитики.
Для интернет-магазина нужно пройти полный тестовый заказ от карточки товара до уведомления администратора.
На этом этапе обнаруживаются ошибки, которые вообще не связаны с хостингом, но именно после запуска становятся особенно дорогими.
Сайт может открываться за 300 миллисекунд и при этом месяцами терять заявки из-за неправильно указанного адреса получателя.
Если это интернет-магазин, требования к хостингу выше
Магазин нельзя проверять как обычный блог.
Здесь постоянно изменяется база данных, работают корзина, заказы, пользователи, платежные системы и фоновые процессы. Подробные требования к такой площадке разобраны в материале о выборе хостинга для интернет-магазина.
После первоначальной настройки магазина нужно отдельно проверить производительность каталога, поиск, фильтры, оформление заказа и административную часть.
Особое внимание уделяется резервному копированию базы.
Для блога восстановление вчерашней копии может означать потерю одного комментария. Для магазина — нескольких оплаченных заказов.
Поэтому частота резервирования должна соответствовать скорости изменения данных.
Настройте журналы и научитесь хотя бы находить их
Не обязательно уметь читать серверные логи как системный администратор.
Достаточно знать, где они находятся.
Access log показывает запросы к веб-серверу. Error log помогает искать ошибки PHP и веб-сервера. CMS может иметь собственный журнал.
Когда сайт внезапно показывает белый экран или ошибку 500, логи часто дают больше информации, чем десять попыток перезагрузить страницу.
Если обращаетесь в поддержку, точное время ошибки и соответствующая запись из журнала значительно ускоряют диагностику.
Проверьте свободное место после установки
Новый тариф на 10 ГБ вовсе не означает, что сайту доступны все 10 ГБ навсегда.
Место используют файлы, база данных, почта, временные данные, журналы и иногда резервные копии.
После установки сайта посмотрите начальное потребление.
Если проект уже занимает 8,5 ГБ из 10, тариф выбран без нормального запаса.
Особенно быстро пространство заканчивается у сайтов с фотографиями, почтовыми ящиками и локальными бэкапами.
Полный диск способен привести к очень странным проблемам: база перестает нормально записывать данные, не создаются временные файлы, не приходят письма, резервное копирование завершается ошибкой.
Лучше получать предупреждение заранее, чем узнавать о нулевом свободном месте от клиента.
Не покупайте VPS заранее «для солидности»
Новый корпоративный сайт совершенно спокойно может работать на хорошем виртуальном хостинге.
VPS дает отдельную виртуальную машину и больше контроля, но вместе с этим появляются операционная система, обновления, веб-сервер, безопасность, резервирование и мониторинг.
Кто-то должен всем этим заниматься.
Если проект перерастет возможности обычного тарифа, его всегда можно перенести. На Hostingi.org есть подробное руководство по переносу сайта с виртуального хостинга на VPS/VDS.
Покупать VPS ради одного небольшого WordPress только потому, что четыре виртуальных ядра выглядят убедительнее строки «виртуальный хостинг», нет необходимости.
Сначала используйте инструмент, соответствующий задаче.
Сделайте собственный список настроек сайта
После завершения первоначальной настройки полезно создать маленький технический паспорт проекта.
Не с паролями.
В нем достаточно указать регистратора домена, хостинг, дату продления, используемую CMS, версию PHP, способ резервного копирования, расположение внешних копий, почтовую систему, основной домен и используемые внешние сервисы.
Если через год сайт придется передать другому разработчику, эти несколько строк сэкономят часы.
Для нескольких сайтов такой список становится еще полезнее.
В памяти все кажется очевидным, пока проектов два. Когда их становится пятнадцать, уже сложно вспомнить, какой сайт использует внешний SMTP, где находится DNS и почему у одного проекта нельзя просто обновить PHP.
Что проверить перед тем, как считать настройку хостинга законченной
Перед запуском полезно пройти сайт еще раз уже не как разработчик, а как обычный посетитель.
Открывается ли домен с HTTPS? Правильно ли работает www? Есть ли сертификат? Загружаются ли страницы с телефона? Отправляются ли формы? Приходит ли почта? Работает ли 404? Создается ли резервная копия? Можно ли ее восстановить? Не открыт ли тестовый домен? Разрешена ли индексация рабочего сайта? Добавлен ли sitemap? Есть ли свободное место на диске?
После этого стоит выйти из административной учетной записи и повторить основные действия как обычный пользователь.
Удивительно много проблем существует только потому, что владелец всегда смотрел сайт авторизованным.
Хорошо настроенный хостинг почти не напоминает о себе
На первоначальную настройку можно потратить несколько часов. Зато потом месяцами не возвращаться к большинству этих вопросов.
Домен продлевается вовремя. Сертификат обновляется автоматически. Бэкапы создаются по расписанию и уходят в отдельное хранилище. Формы действительно доставляют письма. Мониторинг сообщает о сбое раньше клиента. У каждого сотрудника свой доступ. Владелец знает, где посмотреть нагрузку и журналы, а тестовая копия не торчит в поисковой выдаче.
В этом и заключается нормальная работа хостинга.
Не в том, чтобы каждый день открывать панель и любоваться количеством доступных гигабайт, а в том, чтобы инфраструктура не требовала постоянного внимания.
Поэтому после покупки хостинга лучше не спешить сразу устанавливать тему WordPress и наполнять сайт. Сначала потратьте немного времени на фундамент: доступы, домен, DNS, HTTPS, резервирование, почту и безопасность.
Красивую главную страницу всегда можно переделать.
А вот восстанавливать потерянный домен, искать исчезнувший заказ или выяснять после взлома, почему единственная резервная копия лежала рядом с зараженным сайтом, значительно неприятнее.
