Как проверить сайт перед запуском

Договоритесь, что именно проверяете

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

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

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

Пройдите путь клиента целиком

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

Убедитесь, что заявка дошла до человека

Отправьте форму со своим контактом и понятной пометкой «Тест запуска». Проверьте не только сообщение на сайте, но и почтовый ящик, CRM или другой согласованный канал. Сверьте телефон, текст, выбранную услугу и вложение, если оно есть. Назначенный сотрудник должен суметь открыть обращение и понять, что ответить клиенту.

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

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

Проверьте телефон и управление без мыши

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

Узкое окно на компьютере помогает найти часть ошибок, но не заменяет телефон. Документация Chrome прямо называет Device Mode приближённой имитацией: код продолжает работать на компьютере. Если проверяли только такой режим, так и запишите результат. Для интернет-магазина с заметной долей iPhone отдельно нужен сценарий в Safari на устройстве.

На компьютере уберите мышь и попробуйте добраться до формы клавишей Tab, вернуться через Shift+Tab и активировать кнопку. Смотрите, видно ли выбранный элемент и можно ли выйти из открытого окна. Первые проверки W3C WAI включают порядок фокуса, доступ к элементам и отсутствие ловушек клавиатуры. Такой прогон выявляет часть барьеров, но не подтверждает полное соответствие требованиям доступности.

Прочитайте содержание как заказчик услуги

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

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

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

Откройте основной домен и старые ссылки

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

Уточните основной адрес сайта и попросите проверить переходы с HTTP и альтернативного варианта домена. HTTPS защищает передачу данных; браузер также может блокировать небезопасные ресурсы внутри защищённой страницы. Это описано в рекомендациях MDN по TLS. Сам HTTPS при этом не служит доказательством отсутствия всех ошибок безопасности.

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

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

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

• robots.txt управляет обходом сайта роботом. Он не является надёжным способом скрыть конфиденциальные страницы.
• noindex может находиться в коде страницы или HTTP-заголовке. Если он остался на странице услуги, это препятствует её включению в поиск поддерживающей это указание системой.
• Sitemap помогает сообщить о страницах. В нём должны быть актуальные адреса нужной версии сайта, а не тестового домена.

Правила robots.txt и noindex подробно объясняет Google. В частности, робот должен получить доступ к странице, чтобы прочитать noindex. У Яндекса есть инструкция по Sitemap. Попросите показать результат проверки конкретных адресов и список известных ограничений, а не только скриншот файла.

Готовность к обходу и присутствие в выдаче являются разными состояниями. Google предупреждает, что успешная проверка URL не гарантирует индексирование; наличие Sitemap тоже не даёт такой гарантии. Перед запуском можно проверить технические препятствия. Срок появления в поиске и позиции нельзя подтвердить тем же тестом.

Сверьте аналитику с реальным действием

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

В документации Метрики указано, что в зависимости от реализации можно отслеживать нажатие кнопки или отправку формы. Даже корректно зафиксированная отправка не подтверждает доставку в CRM или почтовый ящик. Сопоставьте событие с полученной тестовой заявкой и согласуйте, как менеджер будет учитывать дальнейшие продажи.

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

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

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

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

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

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

Соберите замечания и повторите проверку

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

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

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

Если планируете новый сайт для компании, обсудите создание и запуск с WENLIX. Опишите, что клиент должен сделать на сайте и куда должны поступать обращения. Эти сценарии помогут определить состав работ и критерии проверки ещё до разработки.