Чеклист запуска WordPress для бизнес-сайтов

Бизнес-сайт на WordPress может выглядеть готовым на staging и всё равно провалиться в день один. Формы никуда не уходят, сертификаты истекают посреди кампании, бэкапы никогда не проходили restore-тест, и никто не знает, кто владеет логином хостинга, когда что-то ломается в 21:00.

Запуск — это ops-шлюз. Дизайн и копирайт важны, но go-live — про доказательства, что сайт может оставаться онлайн, принимать лиды и обслуживаться без героических догадок. Это руководство проходит по чеклисту запуска WordPress для бизнес-сайтов. Оно покрывает preflight-владение, хостинг, безопасность, плагины, бэкапы, производительность, лёгкую SEO и measurement-настройку, handoff и первые две недели после переключения DNS.

Preflight: владельцы, доступы и решение о go-live

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

Назовите владельцев для регистратора домена, DNS, панели хостинга, админки WordPress, почты (если почта на том же домене), аналитики, Search Console и аккаунтов оплаты или CRM. Предпочитайте бизнес-owned email и общие password vaults вместо личных форвардов Gmail. Если сайт строило агентство, письменно решите, сохраняют ли они админ-доступ после запуска и на каком уровне прав.

Решите, что значит «done», до переключения. Рабочий порог go-live для сервисного бизнеса обычно включает: HTTPS работает на живом hostname, главная и ключевые денежные страницы грузятся без PHP fatals, контактная форма доставляет в мониторимый inbox или CRM, бэкапы включены с хотя бы одним успешным restore-drill, и на проде не осталось staging URL или активного плагина «coming soon».

Стикеры владельцев домена, DNS, хостинга, админки WordPress и аналитики до cutover DNS.

Совет: Положите решение о go-live в короткую общую заметку. Если маркетинг хочет анонс во вторник, а у ops всё ещё нет доказательства restore, вторник — не тот день.

Готовность хостинга и окружения

Хостинг — место, где многие истории «WordPress тормозит / WordPress взломали» на самом деле начинаются. Для бизнес-сайта выберите план под трафик и привычки обновлений. Самый дешёвый shared-бокс с установкой WordPress в один клик редко и есть этот план.

Подтвердите, что версии PHP и MySQL входят в то, что поддерживают текущие требования WordPress. Включите автоматические security-обновления ядра WordPress, если хост или workflow управления это безопасно поддерживают, и держите путь отката, если обновление сломает кастомную тему. Форсируйте HTTPS на уровне хоста или reverse-proxy, чтобы предупреждения mixed-content не появлялись только после того, как URL пошарят в Slack.

Проверьте, что продакшен использует живой домен в WordPress Settings → General (WordPress Address и Site Address). Staging URL, захардкоженные в базе, — классический сюрприз после миграции. Search-replace делайте осторожно при миграции; слепой find-replace может сломать сериализованные опции темы.

Диск, inode и отправка почты важнее брошюрных заявлений «unlimited». Формы на PHP mail() часто попадают в спам или молча падают. Предпочитайте аутентифицированный SMTP через transactional-провайдера или ваш workspace suite и отправьте реальный тест с живого домена.

Проверка	Pass выглядит так	Fail выглядит так
PHP / DB	Поддерживаемые версии по docs WordPress	End-of-life PHP «потому что тема работает»
HTTPS	Валидный сертификат на живом hostname	Предупреждения браузера или HTTP всё ещё каноничен
URLs	Site Address совпадает с продом	Staging-поддомен всё ещё в настройках
Mail	SMTP-тест попадает во входящие	Форма «отправляет», но ничего не приходит
Resources	Запас под медиа и всплески	Диск полный после недели загрузок

Готовность хостинга как HTTPS, поддерживаемый PHP, здоровье БД и почта, которая реально доставляет.

Если вы пересобираете, а не запускаете совсем новое свойство, относитесь к миграции как к отдельному проекту с редиректами и окном freeze. Чистое engagement настройки WordPress обычно фиксирует выбор окружения до полировки дизайна, чтобы неделя запуска не ушла на споры о хостах.

Базовая безопасность до того, как публичный URL жив

Вам не нужна крепость в день один. Нужны дефолты, которые останавливают скучные атаки на каждый открытый wp-login.php.

Используйте уникальные сильные пароли админов и перестаньте шарить один аккаунт «admin» на всю команду. Создайте пользователей по ролям (administrator, editor, author) и удалите неиспользуемые аккаунты от фрилансеров. Предпочитайте кастомный admin username и держите дефолтный admin удалённым, если он когда-либо существовал.

Обновите ядро WordPress, темы и плагины до запуска. Ждать «после кампании» — как known CVE встречают публичную главную. Удаляйте неиспользуемые темы и плагины вместо того, чтобы оставлять их деактивированными; деактивированный код всё ещё лежит на диске. Ограничьте попытки логина или уберите login за host-level защиту, если провайдер это даёт. Подтвердите, что права на файлы разумны для модели хоста, и что wp-config.php не world-readable.

Включайте Web Application Firewall только если понимаете, что он блокирует. Неправильно настроенные bot fights могут блокировать легитимных краулеров и ваш собственный мониторинг. Двухфакторная аутентификация для администраторов стоит трения на любом сайте, который принимает лиды или платежи.

Предупреждение: Не оставляйте WP_DEBUG включённым на проде. Debug-вывод может утекать путями и внутренностями плагинов в HTML или логи, которые посетители никогда не должны видеть.

Безопасность дня один: сильные аккаунты, обновления, трение на логине и закрытые файлы.

Изучите гайд по hardening WordPress для своего стека, затем применяйте только то, что можете поддерживать. Наполовину доделанный «security suite» с конфликтующими правилами файрвола хуже короткого owned-чеклиста.

Дисциплина плагинов на запуске

Плагины — как WordPress становится бизнес-инструментом. Они же — как сайты накапливают конфликты, вес и заброшенный код.

Инвентаризируйте каждый активный плагин и напишите одно предложение, зачем он существует. Слейте дубли (два SEO-плагина, два form-плагина, два слоя кэша). Предпочитайте хорошо поддерживаемые плагины с ясным каденсом обновлений «вечным бесплатным» клонам без пути поддержки. Page builders могут быть нормальны для редакционной гибкости; они становятся обязательством, когда каждый лендинг — уникальная снежинка без общих шаблонов.

Отключите или удалите импортеры demo-контента, помощников миграции и инструменты «coming soon» с прода. Всё, что может переписывать URL или flush rewrites, должно использоваться намеренно, затем сниматься или закрываться.

Класс плагина	Правило запуска
Forms	Один основной form-стек; тестируйте каждый destination
SEO	Один SEO-плагин или фреймворк; без конкурирующих sitemap
Cache / optimize	Один подход к кэшированию, согласованный с хостом
Security	Один согласованный стек; избегайте пересекающихся файрволов
Backup	Независим от темы; restore протестирован
Builder	Общие шаблоны; без заброшенных demo-страниц

Активные плагины отсортированы на keep, merge и remove до go-live.

Частая ошибка: Поставить «performance»-плагин, минифицирующий CSS, пока хост уже минифицирует, а CDN уже оптимизирует картинки. Выберите одного владельца кэширования и задокументируйте.

Бэкапы, которые вы реально можете восстановить

Бэкап, который вы никогда не восстанавливали, — файл надежды. Бизнес-сайтам нужны расписание, offsite-копия и restore-drill до того, как маркетинговый бюджет ударит по URL.

Решите, что бэкапите (файлы, базу или оба), как часто и где лежат копии. Снапшоты хостинга полезны; они не должны быть единственной копией, если спор по биллингу или компрометация аккаунта могут стереть панель. Держите хотя бы один свежий бэкап вне основного хоста.

Прогоните restore в одноразовое staging-окружение до запуска. Засеките время. Отметьте, какие credentials и DNS-трюки понадобились. Если restore занимает полдня и недокументированный SSH, почините процесс, пока сайт ещё тихий.

После запуска подтвердите, что бэкапы всё ещё идут на живом hostname и что cron или планировщик хоста не остались нацеленными на staging. Документируйте, кто получает failure email, когда job бэкапа умирает.

Файлы и база текут в offsite-хранилище с явным шагом restore-теста.

Лучшая практика: Поставьте restore-drill в календарь в ту же неделю, что и cutover DNS. Проваленный drill — блокер запуска.

Производительность до покупки трафика

Медленные первые загрузки сжигают платную рекламу и sales-демо. Вам не нужен идеальный Lighthouse score, чтобы запустить brochure-сайт, но вы должны знать, как денежные шаблоны ощущаются на mid-range телефоне на обычном wifi.

Измерьте главную, ключевую страницу услуги или продукта и путь контакта или checkout. Сжимайте и ресайзьте hero-изображения до загрузки; не полагайтесь на плагин, чтобы починить 4MB PNG. Откладывайте некритичные скрипты, где тема позволяет. Избегайте складывать три analytics-тега, чат-виджет, heatmap и popup в день один, если у каждого нет владельца и measurement-задачи.

Если используете CDN, подтвердите, что живой домен корректно привязан и что purge кэша может запустить кто-то из команды. Purge после деплоя, чтобы редакторы не гонялись полдня за «я обновил, а сайт всё ещё показывает старый логотип».

Кэш-плагины и page cache на уровне хоста не должны мешать друг другу. Документируйте единственный путь «мне нужна свежая страница сейчас».

Производительность запуска: вес изображений, один путь кэширования и smoke-тест размера телефона.

Core Web Vitals и более глубокие проблемы crawl могут подождать сфокусированного прохода, когда сайт стабилен. Если органический поиск уже канал роста, запланируйте технический обзор отдельно, а не впихивайте полный аудит в ночь запуска.

SEO-основы, которые относятся к go-live

SEO запуска — про то, чтобы не выстрелить себе в ногу. Это не замена ongoing-контенту и технической работе.

Подтвердите, что сайт индексируем на проде (Settings → Reading не отговаривает поисковики). Снимите password protection и basic-auth с публичного hostname. Отправьте чистый XML-sitemap в Google Search Console, когда живой домен верифицирован. Задайте предпочтительную форму URL (www или без www, политика trailing slash) и сделайте редиректы согласованными.

Каждой денежной странице нужен уникальный title и meta description, по которым кликнул бы человек. H1 главной должен называть оффер бизнеса. «Welcome» оставьте для интранета. Добавляйте Organization или LocalBusiness schema только если данные точны и поддерживаются; неверный NAP в JSON-LD создаёт работу по очистке позже.

Если мигрировали со старого сайта, отгрузите карту редиректов для high-traffic и high-conversion URL до анонса. Soft-launch без редиректов — как позиции и закладки умирают в ту же неделю.

Индексируемый прод, отправка sitemap, titles и редиректы как пол SEO запуска.

Держите этот раздел намеренно тонким. Глубокий crawl, canonical и Core Web Vitals заслуживают своего прохода, когда ops-чеклист зелёный.

Формы, аналитика и conversion plumbing

Бизнес-сайт, который не может принять лид, всё ещё черновик. Протестируйте каждую публичную форму на живом домене реальной отправкой. Подтвердите thank-you state, notification email, destination CRM или таблицы и spam-фильтрацию, которая не молча роняет клиентов.

Проверьте privacy-ожидания для вашего региона. Cookie-баннеры и consent-инструменты должны совпадать с тем, как вы реально грузите analytics и ads-пиксели. Сломанный consent UX, блокирующий форму, — дефект запуска.

Установите аналитику с задокументированным property ID и списком доступов. Отметьте дату запуска в заметках, чтобы позже отчётность имела чистый before/after. Если используете Google Analytics или privacy-first альтернативу, проверьте real-time хиты из инкогнито-сессии на проде. Верификация Search Console тоже сюда, чтобы проблемы coverage всплывали рано.

Чат-виджеты, планировщики и кнопки оплаты получают то же обращение, что и формы. Один сломанный Calendly-embed на странице «Book a call» будет стоить дороже недели правок копирайта.

Путь лида от формы к inbox или CRM с подключёнными аналитикой и Search Console.

Главный вывод: Conversion plumbing — часть QA запуска. Design review не заменяет залогированный тестовый лид с timestamp.

Чистая передача после go-live

Handoff — где фриланс- и агентские проекты тихо проваливаются. Сайт жив, счета оплачены, а институциональное знание уходит вместе со строителем.

Отдайте короткий operations packet. Включите локации логинов хостинга и DNS (не пароли в email), URL админки WordPress, как создать новую страницу из стандартного шаблона, как purge кэш, расписание бэкапов и контакт restore, список плагинов с заметками о назначении и кого звать при чрезвычайных ситуациях в первые 30 дней.

Обучите редактора реальному workflow, которым будут пользоваться еженедельно. 40-минутный Loom «добавить страницу услуги» и «обновить hero главной» бьёт общий курс WordPress. Уберите временные админ-аккаунты, когда обучение закончится.

Согласуйте коммерческие ожидания. Ongoing-обновления, security-мониторинг и мелкие правки контента — maintenance. Новые шаблоны, редизайн checkout и миграции — проекты. Если нужен retained care после запуска, скажите явно, а не надейтесь, что «быстрый взгляд» покроет неделю ransomware.

Operations packet, walkthrough для редактора и определённое окно поддержки после cutover.

Разбор сценария для региональной сервисной фирмы

Представьте 12-страничный сайт региональной фирмы professional services. Staging выглядел отполированным. Неделе запуска всё равно нужен был чеклист с зубами.

Понедельник заполнил лист владения. Домен и DNS сидели у IT-подрядчика фирмы. Хостинг и админка WordPress — у веб-партнёра. Аналитика использовала корпоративный Google-аккаунт вместо личного логина дизайнера.

Вторник подтвердил хостинг на актуальном PHP, выпустил HTTPS-сертификат для apex и www и подключил SMTP к workspace фирмы. Search-replace починил три внутренние ссылки, всё ещё указывавшие на staging-поддомен.

Среда: security-проход убрал два неиспользуемых demo-плагина builder, ротировал общий админ-пароль в индивидуальные editor-аккаунты и включил 2FA для администраторов. Backup-плагин писал в offsite-хранилище, и restore на одноразовый поддомен прошёл меньше чем за час.

Четверг: image-проход по hero главной и фото команды, задокументирован один путь кэширования, формы протестированы и в inbox office manager, и в CRM. Одно правило нотификаций осталось на staging-адресе и молча бы провалилось.

Утро пятницы: верификация Search Console, отправка sitemap, снят чекбокс «discourage search engines». Редиректы для пяти старых URL услуг с предыдущего brochure-сайта отгружены. Soft launch — только staff.

После обеда пятницы окупилось более раннее снижение TTL DNS. Cutover, purge CDN, повторный тест форм на публичном hostname. Handoff-заметка ушла с Loom для редактора и двухнедельным окном hypercare для break/fix.

Эта последовательность обычна. Безопасной её сделали доказательства на каждом шлюзе. Более fancy тема не заменила бы эти проверки.

Пятидневная неделя запуска со шлюзами владения, хостинга, безопасности, QA и cutover.

Первые две недели после запуска

Post-launch — когда реальные пользователи и боты давят на допущения. Смотрите графики ресурсов хостинга, error logs и сбои form-нотификаций ежедневно первую неделю. Подтвердите, что бэкапы всё ещё успешны на живом сайте. Перепроверьте Search Console на сообщения coverage или security, когда данные начнут течь.

Ожидайте правок контента. Редакторы будут вставлять из Docs, загружать oversized-изображения и ставить «всего один плагин», если права позволяют. Держите короткий change log для окна hypercare, чтобы можно было соотнести «поставили X» с «формы сломались во вторник».

Если платные кампании стартуют сразу, согласуйте UTM-конвенции и поведение кэша лендингов до масштабирования spend. Закэшированная thank-you страница, которая всё ещё показывает форму, запутает и пользователей, и атрибуцию.

Цикл hypercare: логи, бэкапы, формы и Search Console после go-live.

Планируйте следующий ops-milestone, пока запуск свеж. Ежемесячные обновления, квартальный restore-drill и более глубокий SEO- или conversion-проход, когда паттерны трафика реальны, — всё это в календарь. Полнота запуска и долгосрочный рост — разные работы.

Часто задаваемые вопросы

Когда переключать DNS относительно freeze контента?

Замораживайте структурные и plugin-изменения за 24–48 часов до cutover, когда можете. Правки копирайта на существующих страницах обычно ок. Крупные изменения темы или builder mid-cutover мешают отличить DNS lag от настоящей регрессии.

Нужен ли staging-сайт навсегда?

Держите staging, если обновляете плагины ежемесячно или отгружаете нетривиальные изменения темы. Крошечные brochure-сайты, которые редко меняются, иногда могут жить с host-level staging по запросу. Правило простое. Если не можете позволить сломанную главную на день — держите место тестировать обновления.

Нормален ли page builder для бизнес-запуска?

Да, когда команда реально редактирует в общих шаблонах и кто-то владеет обновлениями. Становится дорого, когда каждая страница — one-off, а builder, тема и «helper»-плагины все нуждаются в согласованных обновлениях. Решите модель редактирования до запуска. Ждать до первой сломанной главной стоит неделю поддержки.

Какова минимальная политика бэкапов для lead-gen сайта?

Ежедневные бэкапы базы, регулярные full-site бэкапы, одна offsite-копия и restore-тест до go-live. Увеличьте частоту, если публикуете или принимаете заказы весь день. Одни снапшоты хостинга — single point of failure, когда панель — это инцидент.

Должны ли security-плагины заменять файрволы хостинга?

Они решают разные слои. Контроли хоста и сети останавливают много шума до PHP. Application-level плагины помогают с login abuse и целостностью файлов. Пересекающиеся продукты, оба переписывающие .htaccess или оба челленджащие каждого посетителя, создадут тикеты поддержки. Выберите стек и задокументируйте.

Насколько техничной должна быть передача клиенту?

Достаточно техничной, чтобы клиент мог восстановить доступ и делать рутинные правки без вас. Не настолько плотной, чтобы стать непрочитанным PDF. Карта логинов, workflow редактирования, контакты бэкапов и путь эскалации бьют 40-страничный мануал.

Можно ли запускать без Search Console?

Можно, но будете летать вслепую по индексации и security-уведомлениям. Верификация дёшева относительно недели «почему нас не показывают». Сделайте это в неделю запуска, если Google-поиск хоть как-то важен бизнесу.

Что относится к hypercare, а что к новому проекту?

Hypercare покрывает дефекты сборки и конфигурации запуска. Новые шаблоны страниц, новые интеграции и редизайны — новый scope. Запишите эту границу, чтобы goodwill не стал неоплаченной product-работой.

Закройте шлюз, затем держите свет включённым

Чеклист запуска WordPress для бизнес-сайта на самом деле — чеклист доказательств. Владельцы названы, хостинг подогнан под задачу, security-дефолты на месте, плагины обоснованы, бэкапы восстановлены хотя бы раз, производительность достаточна для реальных телефонов, SEO не самосаботируется, формы доказаны, и handoff, которым люди будут пользоваться.

Когда эти шлюзы зелёные, маркетинг может тратить, а редакторы публиковать, не изобретая ops под давлением. Когда жёлтые — отложите анонс. URL подождёт; публичный провал — нет.

Если нужна помощь превратить это в конкретный план go-live или чистую сборку до переключения DNS, напишите через контактную форму.