Как принять сайт у разработчика

Как пользоваться этой инструкцией

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

Подготовьте техническое задание, согласованные макеты, перечень страниц и интеграций. Зафиксируйте проверяемый адрес, дату и версию. Создайте таблицу с колонками «Адрес / сценарий», «Ожидаемый результат», «Фактический результат», «Доказательство», «Ответственный», «Статус». Используйте четыре статуса: проверено, есть ошибка, не проверено, не применимо. Отсутствие доступа к кабинету — это «не проверено», а не «всё хорошо».

Сервисы, которые понадобятся

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

Убедитесь, что сайт действительно передан вам

Проверьте домен через WHOIS и кабинет регистратора

1. Откройте WHOIS, введите домен без адреса страницы, например example.ru, и запустите поиск.
2. Найдите регистратора и срок действия домена. Для зоны .ru срок может обозначаться полем paid-till; в других зонах название отличается.
3. Войдите в личный кабинет указанного регистратора под учётной записью заказчика. Убедитесь, что домен присутствует, доступны продление и управление DNS, а контакт для восстановления принадлежит ответственному сотруднику.
4. Сверьте сведения об администраторе домена с согласованной схемой владения. Если данные скрыты в WHOIS, это нормально: публичный сервис не заменяет проверку кабинета и документов.

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

Соберите реестр остальных доступов

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

Проверьте редиректы, ответы сервера и сертификат

Четыре варианта домена в httpstatus.io

Один сайт часто открывают через HTTP или HTTPS, с www или без него. Выберите основной адрес, например https://example.ru/. Затем откройте httpstatus.io и вставьте в поле четыре строки, заменив пример своим доменом:

http://example.ru/
http://www.example.ru/
https://example.ru/
https://www.example.ru/

Нажмите Check status. Раскройте результаты и посмотрите последовательность кодов и конечный адрес. У основного URL ожидается 200. Альтернативные адреса при постоянной склейке обычно ведут через 301 или 308 на основной HTTPS-адрес, который отвечает 200. Повторите проверку для вложенной страницы: путь не должен теряться.

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

Настоящая ли страница 404

Добавьте к своему домену заведомо отсутствующий путь, например /proverka-priemki-ne-sushchestvuet-8472/. Откройте его в браузере и проверьте тем же сервисом. Нужно увидеть понятный экран с навигацией и код 404. Если написано «Страница не найдена», но сервер отвечает 200, это ложная успешная страница. Для действительно удалённого ресурса также может осознанно использоваться 410.

Проверка HTTPS через SSL Labs

1. Откройте SSL Server Test. В поле Hostname введите домен без https:// и пути.
2. При необходимости отметьте Do not show the results on the boards, запустите тест и дождитесь завершения.
3. Проверьте срок сертификата, соответствие домену и сообщения о доверии к цепочке. Замечания о протоколах передайте администратору сервера вместе со ссылкой на отчёт.

В обычном браузере сайт должен открываться без предупреждения о недействительном сертификате. Отдельно проверьте загрузку изображений, шрифтов и скриптов: HTTPS у самой страницы не исправляет ссылки на ресурсы через HTTP. Оценка SSL Labs относится к настройкам TLS, а не ко всей безопасности сайта.

Проверьте, не закрыт ли сайт от поисковых роботов

Шаг 1. Откройте robots.txt

Введите в браузере https://ваш-домен/robots.txt. Найдите блок для User-agent: *, а также отдельные правила Googlebot и Yandex, если они есть. Такая пара строк запрещает обход всему соответствующему роботу:

User-agent: *
Disallow: /

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

Откройте Яндекс Вебмастер → Инструменты → Анализ robots.txt, укажите адрес сайта. После загрузки файла проверьте разрешение для главной, услуги, статьи и других важных URL. Если нужная страница запрещена, сохраните её адрес и правило, которое сработало. Порядок проверки описан в справке инструмента.

Шаг 2. Найдите noindex в странице и заголовках

Откройте исходный код страницы через меню браузера «Просмотреть код страницы». Поиском найдите name="robots", name="googlebot" и noindex. Важен настоящий метатег внутри <head>, например:

<meta name="robots" content="noindex, nofollow">

Если вы проверяете статью вроде этой, слово noindex может находиться в учебном примере и не быть действующим запретом. Дополнительно в отчёте httpstatus.io посмотрите заголовки ответа: директива может приходить как X-Robots-Tag: noindex. В WordPress отдельно проверьте «Настройки → Чтение» и опцию, предлагающую поисковым системам не индексировать сайт; настройки SEO-плагина тоже могут добавлять ограничения.

Нормальный результат: у страниц, предназначенных для поиска, нет случайного запрета индексации. Google должен иметь доступ к странице, чтобы прочитать noindex; закрытие обхода в robots.txt не заменяет эту директиву. Это различие объясняет документация Google.

Шаг 3. Проверьте XML-карту сайта

Возьмите адрес карты из строки Sitemap: в robots.txt или запросите у разработчика. Она может называться sitemap.xml, sitemap_index.xml или иначе. Откройте карту, а если это список отдельных карт — откройте карты страниц, товаров и статей. Проверьте, что адреса используют рабочий домен и основной HTTPS-вариант, а не тестовую площадку.

Выберите URL из каждого раздела и откройте их. В карте не должны случайно оставаться редиректы, удалённые страницы или страницы с noindex. Сверьте полный список с согласованным реестром сайта: одна открывающаяся карта не доказывает полноту. В Вебмастере используйте Инструменты → Анализ файлов Sitemap, вставьте ссылку и разберите ошибки; есть официальная инструкция.

Шаг 4. Проверьте страницу в Google Search Console

1. В Search Console выберите подтверждённый ресурс своего сайта.
2. Вставьте полный адрес важной страницы в верхнюю строку проверки URL.
3. Различайте сохранённые сведения из индекса и проверку текущей версии. Нажмите Проверить опубликованную страницу / Test Live URL, чтобы проверить актуальный ответ.
4. Раскройте сведения об обходе и индексации. При запрете или ошибке загрузки передайте разработчику конкретную причину. После исправления повторите живую проверку.

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

Найдите битые ссылки, дубли и ошибки разметки

Как запустить обход в Screaming Frog

1. Установите SEO Spider с официального сайта. Вставьте главную страницу в поле Enter URL to spider и нажмите Start.
2. Дождитесь окончания обхода. Если достигнут лимит бесплатной версии в 500 URL, не считайте отчёт полным: для большего проекта нужен инструмент без такого ограничения.
3. Посмотрите вкладку Response Codes, найдите ответы 4xx и 5xx. Выберите проблемный адрес и изучите Inlinks, чтобы узнать, с каких страниц на него ссылаются.
4. Экспортируйте результаты и передайте подрядчику пары «страница-источник → неработающая ссылка».

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

Что посмотреть в результатах

Названия и назначение вкладок приведены в справочнике SEO Spider. Автоматическая пометка — повод посмотреть страницу. Например, одинаковый title у намеренного дубля и одинаковый title у десяти разных услуг требуют разных решений.

Как проверить структурированные данные

Откройте Rich Results Test, выберите проверку URL, вставьте адрес и запустите тест. Раскройте найденный тип и ошибки. Этот сервис проверяет поддерживаемые Google расширенные результаты: отсутствие подходящего результата ещё не означает, что любой Schema.org-код неверен.

Поэтому дополнительно откройте Schema Markup Validator и проверьте тот же адрес. Сверьте значения с содержанием: название, автор, организация, изображение, URL и даты. У статьи должна быть связанная с ней иллюстрация, у услуги — актуальные сведения о ней. Зелёный валидатор не заметит выдуманного автора или фотографию от другой темы, если код формально корректен.

Отдельно посмотрите превью ссылки в мессенджере и метаданные og:title, og:description, og:image. Старый общий баннер на всех материалах — повод настроить изображения страниц. Учтите кеш мессенджера: он может показывать старую карточку после исправления.

Что проверить вручную в текстах и изображениях

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

Для поиска ошибок HTML можно использовать Nu Html Checker: передайте URL и разберите сообщения об ошибках структуры. Разработчик должен оценить их влияние; счётчик предупреждений не заменяет проверку сайта. Полный разбор поисковых настроек входит в технический SEO-аудит.

Проверьте интерфейс на разных экранах

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

Быстрая проверка ширины в Chrome

1. Откройте страницу, затем инструменты разработчика через меню браузера или F12.
2. Включите панель устройств кнопкой с телефоном и планшетом. В режиме Responsive задавайте ширину вручную.
3. Для первичного прохода проверьте 320, 390, 768 и 1440 пикселей. Это рабочий набор для поиска дефектов, а не универсальный список всех устройств.
4. На каждой ширине прокрутите страницу целиком, откройте меню, таблицы, вкладки и формы. Зафиксируйте адрес, ширину и скриншот проблемы.

Device Mode помогает проверять адаптивность, но не воспроизводит физический телефон полностью. Повторите основной сценарий на реальном Android и iPhone, если эти устройства входят в аудиторию проекта.

Что считать дефектом

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

Дополнительно пройдите элементы клавишей Tab. Фокус должен быть виден, кнопки и поля — доступны, ошибка — объяснена текстом. Увеличьте масштаб браузера до 200% и проверьте, сохраняется ли возможность прочитать материал и выполнить основное действие. Если есть согласованные требования доступности, проверяйте их отдельным перечнем.

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

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

Пошаговая проверка каждой формы

1. Составьте список разных форм: заявка внизу страницы, обратный звонок, всплывающее окно, бриф, форма с файлом. Одинаковые внешне формы могут отправлять данные разным обработчикам.
2. Откройте нужную страницу. Для проверки источника можно добавить согласованные тестовые метки: ?utm_source=acceptance&utm_medium=test&utm_campaign=site_handover.
3. Введите узнаваемую пометку, например «ТЕСТ приёмки — форма услуги — 14:35». Используйте свой согласованный контакт. Заполните каждое поле отдельным значением, чтобы заметить потерю данных.
4. Отправьте форму один раз. Запишите время и результат на экране.
5. Найдите письмо во входящих и проверьте спам. Если предусмотрено сохранение в CMS, найдите запись там. В CRM проверьте карточку, воронку, ответственного, телефон, комментарий и источник.
6. Сопоставьте данные с отправленными. Вложение должно открываться, ссылки — вести на нужные материалы, рекламные метки — попадать в предусмотренные поля.

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

Проверьте ошибки и повторную отправку

Магазин, оплата и личный кабинет

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

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

Проверьте цели Метрики после реального действия

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

Как включить отладчик

1. Откройте страницу с параметром ?_ym_debug=2. Если в URL уже есть знак вопроса, добавьте &_ym_debug=2.
2. Выполните целевое действие и откройте панель отладки внизу страницы.
3. На вкладках Events и Console проверьте номер счётчика и событие. Сопоставьте его с согласованной целью.
4. Затем найдите достижение в отчёте по конверсиям, учитывая задержку обновления данных и фильтры собственных визитов.

Режим _ym_debug=2 предназначен для нового кода счётчика. Если панель не появилась, используйте описанный Яндексом вариант с _ym_debug=1 и консолью браузера. Точные шаги и причины отсутствия события приведены в официальной инструкции проверки целей.

Как понять, что цель настроена неправильно

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

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

Как проверить PageSpeed и понять, что исправлять

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

1. Откройте PageSpeed Insights, вставьте полный URL и нажмите кнопку анализа.
2. Дождитесь отчёта. Проверьте обе вкладки: мобильные устройства и компьютеры. Их оценки и условия различаются.
3. Сохраните ссылку на отчёт, дату, URL и устройство. Для повторного замера укажите, какие изменения сделаны между запусками.
4. Посмотрите сначала реальные пользовательские данные, если они доступны, затем лабораторную диагностику. В блоке реальных данных проверьте, относится ли он к этому URL или к сайту в целом.
5. Раскройте рекомендации и найдите конкретные ресурсы: изображение, скрипт, шрифт, запрос. Передавайте разработчику их адреса и описание проблемы вместе с отчётом.

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

Пороги Core Web Vitals применяются к 75-му процентилю реальных посещений с разделением по устройствам. У нового или малопосещаемого сайта таких данных может не быть. Это не означает ни нулевую скорость, ни автоматический провал. Определения и условия приведены в документации Web Vitals.

Пример разбора отчёта

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

Нужно ли требовать именно 100

Баллы Lighthouse — результат конкретного лабораторного запуска. На них влияют условия измерения; Google объясняет расчёт и вариативность в документации оценки производительности. Если в требованиях записано 100, фиксируйте метрику, тип устройства и условия, затем проверяйте фактический результат. Нельзя писать «100 на всём сайте» по одному скриншоту.

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

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

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

Сценарий контрольного восстановления

1. Выберите конкретную резервную копию и запишите дату. Уточните, что именно из неё должно восстановиться.
2. Попросите разработчика развернуть её на изолированной тестовой площадке. Не заменяйте рабочий сайт ради эксперимента.
3. До запуска отключите реальные платежи, рассылки, уведомления и другие внешние действия в восстановленной копии. Закройте тестовую площадку от посторонних и поисковых роботов подходящими средствами.
4. Откройте страницы, войдите в CMS, проверьте изображения, данные и основной сценарий на тестовых получателях.
5. Зафиксируйте время восстановления, недостающие части и инструкцию. Убедитесь, что копия доступна ответственному, даже если основной сервер потерян.

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

Минимальный контроль безопасности при передаче

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

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

Проверьте, сможете ли вы обновлять сайт сами

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

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

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

Как передать ошибки разработчику и проверить исправления

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

Приоритеты исправлений

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

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

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

Чек-лист перед завершением приёмки

Отмечайте пункт только после проверки. Галочки ниже служат для текущего просмотра и не сохраняются после перезагрузки: перенесите результаты и ссылки на доказательства в свой журнал.

Частые вопросы о приёмке сайта