Приёмка сайта WordPress: как проверить готовность к запуску без знаний кода

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

Предпринимательница в фиолетовом жакете проверяет мобильную версию сайта на смартфоне в современном шоуруме; подпись Uweam.

«Сайт готов, посмотрите» — ещё не приглашение к полноценной приёмке. По ссылке можно оценить дизайн и заметить опечатки, но трудно понять, куда поступит обращение, сможет ли сотрудник изменить цену и что останется компании после завершения проекта. Эти вопросы лучше закрыть до запуска рекламы и окончательного согласования результата.

Приёмка сайта WordPress не требует от заказчика читать код. Ему нужно пройти несколько рабочих ситуаций, сопоставить результат с согласованным заданием и получить подтверждения по тем вещам, которые нельзя увидеть глазами. Ниже — порядок такого разговора с исполнителем, а не инструкция по самостоятельной настройке сайта.

До созвона: попросите не презентацию, а условия проверки

Уточните, какую версию сайта вам показывают: тестовую копию или уже рабочий адрес. Попросите список готовых разделов, согласованное описание функций и перечень известных ограничений. Если часть материалов пока временная, это должно быть видно в списке, а не выясняться при просмотре страницы «О компании».

Договоритесь, кто участвует в проверке со стороны бизнеса. Руководитель может согласовать общее впечатление, менеджер — путь обращения, сотрудник каталога — редактирование товаров. Один человек редко замечает всё, особенно если не будет ежедневно работать с сайтом.

Условие полезной приёмки: исполнитель знает ожидаемый результат, а заказчик проверяет его на своих задачах. Фраза «сделайте красиво и чтобы всё работало» не заменяет общие критерии готовности.

Пройдите сайт в трёх ролях

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

Не ограничивайтесь главной. Выберите длинную страницу, карточку товара или услуги и страницу с контактами. Проверьте, что текст читается, важные кнопки доступны, а всплывающее окно не закрывает весь экран. Скриншот согласованного макета и работающий сайт — разные предметы проверки: второй должен выдерживать реальные действия.

Клиент, который готов обратиться. Отправьте согласованную тестовую заявку с узнаваемой пометкой. Попросите ответственного сотрудника подтвердить получение и показать, какие сведения пришли. Здесь важно не только сообщение «Успешно» на экране, но и возможность продолжить работу с обращением. Если заявка должна попадать в CRM, проверьте её именно там, а не только в почте разработчика.

Для магазина поручите исполнителю показать весь путь согласованного тестового заказа, включая результат оплаты и уведомления. Не переводите платёжную систему работающего магазина в тестовый режим самостоятельно. В документации WooCommerce о тестовых заказах отмечено, что они могут запускать письма и попадать в аналитику; тестирование платежей рекомендуется проводить на отдельной тестовой копии. Поэтому заранее согласуйте безопасную демонстрацию и отдельную проверку рабочих настроек перед запуском.

Сотрудник, который останется с сайтом. Попросите показать обычную задачу вашей команды: заменить фотографию, исправить описание или обновить цену. Затем пусть её выполнит ваш сотрудник в согласованной среде под своей учётной записью. Цель — проверить удобство передачи управления, а не научиться разработке. Если каждое изменение требует обращения к автору сайта, выясните, соответствует ли это исходной договорённости.

Замечания лучше разделить, чем собрать в один длинный чат

Представим условную проверку: на телефоне не нажимается кнопка обращения, у фотографии неверная подпись, а директор хочет добавить новый раздел. Это три разных вопроса. Первый мешает основному действию посетителя; второй относится к содержимому; третий может менять согласованный объём работ. Они не должны теряться в общей фразе «есть правки».

Что обнаруженоЧто обсудить с исполнителем
Не работает согласованная ключевая функцияИсправление и повторную проверку до запуска соответствующего сценария
Ошибка в согласованных текстах или материалахКто исправляет, к какому сроку и где проверить обновление
Появилась новая идеяОтдельную оценку изменения и его влияние на сроки, без смешивания с дефектами

Для каждого замечания достаточно адреса страницы, устройства, краткого описания действия и ожидаемого результата. При необходимости добавьте скриншот или короткую запись экрана. Назначьте одного человека, который собирает обратную связь компании: противоречивые пожелания из нескольких переписок задерживают завершение проекта.

Что получить вместе с готовым сайтом

  • Управление: доступы к согласованным аккаунтам, перечень владельцев домена, хостинга и внешних сервисов. Секреты передаются безопасным способом, не публикуются в общем документе.
  • Рабочие материалы: краткую инструкцию для сотрудников, список используемых платных продуктов и условий их продления.
  • Готовность к эксплуатации: подтверждение проверки резервного копирования, основных обращений, необходимых интеграций и настроек рабочего адреса.
  • Порядок после запуска: куда направлять обнаруженные ошибки, кто их рассматривает и какие изменения относятся к отдельным работам.

Попросите отдельно подтвердить настройки доступа поисковых систем. В WordPress предусмотрена настройка, предлагающая поисковикам не индексировать сайт; её назначение описано в официальной документации. Для публичного проекта важно не перенести ограничение с тестовой копии. При этом разрешение индексации не обещает быстрых позиций или обращений из поиска.

После исправлений повторите только затронутые сценарии и убедитесь, что рядом не появилось новых проблем. Итогом пусть станет один согласованный список: что принято, что осталось, кто отвечает и когда будет следующий контроль. Порядок окончательного расчёта должен соответствовать вашим договорённостям; эта проверка не заменяет условия договора.

Сайт можно считать готовым к согласованному запуску не потому, что закончилась вёрстка, а потому, что команда понимает, как получать обращения, менять содержимое и действовать при сбое. Именно такой результат стоит принимать у подрядчика.