Как принять сайт у разработчика: страницы, заявки, доступы и аналитика

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

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

Зафиксируйте версию сайта, объём и условия приёмки

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

Заполните паспорт проверки:

Демонстрационный адрес, локальный макет и публичный сайт — разные результаты. Если на демо-адресе показан рабочий шаблон, а договор включает выпуск на домене заказчика, публичную версию проверяют отдельно. Отметку с демонстрации на неё не переносят.

Сверьте страницы, содержание и переходы с заданием

Пройдите согласованную карту URL. Для каждой страницы проверьте название услуги, тексты, изображения, контакты, документы, внутренние ссылки и основной призыв к действию. Макетный телефон, неподтверждённая цена или чужой кейс — отдельное замечание, даже если шаблон выглядит законченным.

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

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

Пройдите интерфейс на телефоне и с клавиатуры

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

Затем повторите интерактивную часть только клавиатурой. Фокус должен быть виден, порядок переходов — понятен, кнопки — доступны, а ошибочное поле — исправимо. Движение мыши по экрану не заменяет эту проверку.

Например, кнопка отправки видна до открытия экранной клавиатуры, но после ввода она оказывается перекрыта. Запишите условия экрана и шаги воспроизведения, а после исправления повторите тот же путь.

Если в задании есть критерий производительности, сохраните страницу, метод и единичный результат. Один лабораторный замер не описывает поведение всех посетителей.

Проследите тестовую заявку до подтверждённого результата

До отправки согласуйте среду, синтетический контакт, узнаваемую метку, получателя и порядок удаления теста. Не используйте контакт клиента и не оставляйте тестовую запись как новую продажу.

Проверяйте маршрут по отдельным узлам:

1. Форма приняла действие и показала предусмотренное сообщение.
2. На стороне сайта найдена запись, связанная с меткой, временем или номером события.
3. Отдельно подтверждены получатель и доставка уведомления.
4. Если CRM входит в объём, найдены конкретная запись и назначенный ответственный.

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

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

На собственном сайте Switch On AI сохранение заявки и доставка уведомления разделены. Это подтверждённое устройство собственного проекта, а не универсальная архитектура для любого сайта. Для сайта заказчика проверяют именно согласованный маршрут.

Проверьте аналитику на согласованном контрольном действии

Попросите исполнителя показать предусмотренные права просмотра, используемый счётчик или проект и описание событий. Наличие кода аналитики или значка сервиса не доказывает правильность измерения.

Для контрольного действия запишите:

• что означает событие;
• где оно срабатывает;
• время и исходную страницу;
• синтетическую метку теста;
• где принимающий наблюдает результат;
• какой вывод из этого наблюдения допустим.

Если измеряется принятие заявки, событие не должно срабатывать только от нажатия кнопки до подтверждения записи. Повторное нажатие проверяют по правилу конкретного проекта. Если событие ещё не видно, результат остаётся «не установлен»; назначьте повторную проверку, не придумывая универсальную задержку сервиса.

Отдельно проверьте согласованный режим включения аналитики и минимальный состав данных. В свидетельствах не должно быть контакта или содержания обращения. Юридические условия обработки данных определяются не этой статьёй.

Проверьте опубликованные адреса и поисковые настройки

Работайте с фактическим публичным доменом. Для важных URL отдельно запишите HTTP-ответ, переадресацию, основной адрес, title и description, внутренние ссылки и согласованное решение об индексации. Попросите техническое подтверждение canonical, robots или noindex, sitemap и применимой разметки именно для опубликованной версии.

Отсутствие ошибки при разборе разметки не доказывает смысловую правильность данных или индексацию. Сопоставляйте технические значения с тем, что видит посетитель.

Если в передачу входит Search Console, исполнитель показывает состояние выбранного URL и дату данных. Сведения об индексированной версии относятся к последней известной Google копии, а живая проверка оценивает текущую страницу в пределах возможностей инструмента. Живой тест не предсказывает выбранный Google canonical и не проверяет все условия появления в поиске. Поэтому HTTP, настройки страницы, индексированные сведения и живой тест записывают раздельно.

Полезный пример ограниченного свидетельства — обезличенная квитанция проверки собственного сайта от 29 сентября. В ней указано наблюдение 2026-09-29T11:35:00+03:00, область HTTP/HTML-проверки, метод и ограничения. Это реальная квитанция узкого обследования Switch On AI, но не полная приёмка сайта. GET 29 октября подтвердил доступность JSON-файла, а не повторил сентябрьскую проверку и не проверил форму или аналитику.

Получите доступы, материалы и порядок дальнейшей работы

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

Не подразумевайте передачу чужого SaaS, всех библиотек или сторонних лицензий. Объём прав задают договор и условия правообладателей.

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

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

Оформите замечания и повторите проверку исправлений

Записывайте дефект как воспроизводимую разницу между заданием и наблюдением.

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

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

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

Если проверка выявила предметный объём работ, у Switch On AI можно обсудить разработку и доработку сайта для бизнеса: страницы, форму, поисковую подготовку и передачу согласуют как проверяемый состав, а не как неопределённое обещание «исправить всё».

Учебный чек-лист приёмки сайта услуг

EX-W04 — учебный пример на вымышленном сайте. Проверки этого примера не выполнялись; фактический результат заполняют после согласованных действий.

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

Паспорт EX-W04

Порядок работы с шаблоном:

1. Получить карту, состав передачи, критерии и разрешение на тестовые действия.
2. Выполнить строки по очереди, записывая фактический результат и обезличенное свидетельство.
3. При несоответствии оформить замечание и согласовать повторный проход исправленной версии.
4. Решать вопрос о сдаче только по подтверждённому объёму; непроверенное оставить видимым.

Программа и журнал

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

Условная учебная находка, не выполненный тест

Предположим, что в вымышленной ситуации A-03 дала запись с номером, но по A-04 подтверждения доставки нет.

Корректная запись: «Запись обращения условно подтверждена только в рамках задачи-примера; доставка не установлена. Оформить замечание по A-04, назначить ответственного и повторную проверку».

Нельзя писать «весь маршрут работает», «уведомление потеряно» или «заявка не сохранена». Отсутствия подтверждения недостаточно для этих выводов.

EX-W04 отличается от реальной квитанции от 29 сентября: квитанция уже содержит дату, область, метод и ограничения состоявшегося узкого обследования, а учебная таблица пока содержит лишь действия, ожидания и места для будущего факта.

После заполнения собственного протокола можно обсудить замечания и состав доработки сайта со Switch On AI. Передайте публичный адрес, согласованный пункт задания и обезличенное описание «что делали — чего ожидали — что получили». Пароли, базы и контакты посетителей через открытую форму отправлять не нужно.