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

Проверяйте сценарии, а не только страницы

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

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

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

Проверьте тексты и материалы

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

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

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

Пройдите навигацию и ссылки

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

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

Проверьте поведение несуществующего URL. Сайт должен показать понятную страницу, предложить навигацию и вернуть HTTP 404. Недостаточно написать «ошибка» внутри успешного ответа. Перенаправление всех неизвестных адресов на главную также скрывает проблему и путает пользователя. Для старых существовавших страниц нужны осмысленные решения, а для случайных адресов — честный статус.

Проверьте формы и контакты

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

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

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

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

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

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

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

Проверьте загрузку и устойчивость

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

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

Сравните лабораторную диагностику с реальным сценарием. Высокая оценка не означает, что форма доставляет заявки, а низкая не указывает автоматически на одну причину. Для наблюдения за опытом пользователей используются LCP, INP и CLS; назначение показателей описано в документации Google. После исправлений повторите затронутый путь, а не только генерацию отчёта.

Проверьте индексацию и метаданные

Убедитесь, что на рабочий сайт не переехал запрет индексации тестовой версии. Проверьте meta robots, HTTP-заголовки и robots.txt. Основные страницы должны быть доступны и возвращать успешный статус. В sitemap включайте рабочие основные URL, а canonical должен указывать на выбранную версию страницы. Не оставляйте в этих элементах тестовый домен или технический IP.

Проверьте уникальность title и описаний, понятность главного заголовка, структуру подзаголовков и внутренних ссылок. Для новых страниц укажите собственное содержание, а не один шаблон с заменой названия. Важная информация должна быть доступна в HTML и не зависеть от необязательного виджета. Сведения о компании, авторстве и условиях должны совпадать в тексте и структурированных данных.

Проверьте JSON-LD на синтаксис и соответствие странице. Для статьи подходят Article и реальные даты, для пути — BreadcrumbList. Вопросы и ответы в разметке должны присутствовать и в видимом FAQ. Валидная схема не гарантирует специальный вид выдачи. Для подробного плана первых работ смотрите «С чего начать SEO-продвижение».

Проверьте домен и старые адреса

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

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

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

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

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

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

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

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

Сделайте резервную копию файлов, базы и необходимых настроек. Проверьте, что архив читается, а восстановление понятно и по возможности испытано на отдельной среде. Копия только базы не содержит загруженные изображения, а копия файлов не сохраняет содержание CMS. Хранение единственного архива рядом с заменяемой папкой может оказаться бесполезным при сбое всего сервера.

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

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

Повторите проверку на рабочем домене

После переключения ещё раз откройте главную, ключевые услуги, проекты, статьи и контакты. Проверьте формы, аналитику, robots, sitemap, изображения и вход в CMS. Рабочая среда может отличаться путями, правами, версией PHP и настройками почты. Успех на техническом адресе не отменяет проверку после переноса. Сохраните время запуска и перечень существенных изменений.

Замечания фиксируйте с адресом, условиями воспроизведения и ожидаемым результатом. Разделяйте неисправности и новые пожелания. Для критических проблем должен быть понятен порядок возврата на сохранённую версию. После стабильного запуска можно планировать следующие улучшения, ориентируясь на реальные вопросы и обращения. Для небольших задач подойдёт помощь с сайтом от 1 000 ₽ в час.

Частые вопросы