Задача «скопировать лендинг» на практике почти никогда не сводится к сохранению HTML-страницы через браузер. Заказчику обычно нужно не изображение сайта, а работающая копия: с формами, которые реально отправляют заявки, с корректной адаптивностью и с возможностью редактировать тексты без разработчика. Разберу технический процесс клонирования лендинга под ключ.
Прежде чем приступать к работе — важно понимать разницу между «использовать чужой дизайн как референс/шаблон для собственного проекта» и «выдавать копию чужого фирменного сайта за оригинал». Легитимные случаи клонирования — это копия собственного старого сайта при смене хостинга или CMS, воссоздание лендинга по купленному шаблону, перенос сайта, на который у заказчика есть права. Технический процесс ниже одинаков во всех случаях, разница — в источнике прав на контент.
Первый шаг — получить полный набор файлов страницы: HTML, CSS, JS, изображения и шрифты. Если доступа к исходным файлам нет, использую инструменты сохранения сайта целиком (например, wget с рекурсивным обходом ресурсов страницы), после чего вручную привожу пути в порядок — сохранённые таким способом файлы почти всегда содержат абсолютные ссылки на исходный домен вместо относительных, что ломает работу после переноса. Отдельная проблема — минифицированный и обфусцированный JS: если скрипт критичен для функциональности (например, кастомный слайдер), часто проще переписать его логику с нуля по наблюдаемому поведению, чем распутывать минификацию.
Статическая HTML-копия неудобна для заказчика — любое изменение текста требует разработчика. Поэтому статику разбиваю на шаблон CMS (в моём случае обычно WordPress) с вынесением редактируемых блоков в мета-поля или блочный редактор, сохраняя исходную CSS/JS-логику без изменений. Структура остаётся идентичной оригиналу, но заголовки, тексты преимуществ, цены и изображения становятся редактируемыми через стандартную админ-панель, без прямого доступа к коду.
В исходном лендинге форма отправки почти всегда завязана на чужой backend — сторонний скрипт обработки, сервис форм или CRM оригинального владельца. При переносе этот action формы нужно полностью заменить на собственный обработчик. Использую Contact Form 7 или собственный AJAX-хендлер на admin-ajax.php, сохраняя исходную вёрстку и клиентскую валидацию полей, чтобы визуально форма не отличалась от оригинала. Обязательно добавляю защиту от спама — honeypot-поле или капчу — так как публично видимая форма на новом домене быстро попадает в базы спам-ботов, а исходная защита (если она была) переносу не подлежит: она находилась в закрытом backend чужого сайта.
Счётчики Яндекс.Метрики и Google Analytics 4 в скопированной странице ссылаются на чужой идентификатор — их нужно полностью заменить на собственные ID, иначе статистика визитов будет уходить в аналитику владельца оригинального сайта, а не заказчика. Отдельно переношу структуру целей и событий, если они были — клик по кнопке «Обсудить проект», отправка формы, скролл до определённого блока — эти события в оригинале обычно настраивались через dataLayer.push или прямые вызовы ym(ID, 'reachGoal', 'name'), и их нужно переинициализировать под новый счётчик, а не просто скопировать код с чужим ID.
Перед сдачей проверяю: скорость загрузки скопированной страницы (перенос статики часто тянет за собой неоптимизированные исходные изображения — их пересжимаю), отсутствие битых ссылок и путей на исходный домен (поиск по всем файлам строки исходного домена — надёжный способ поймать пропущенные абсолютные пути), корректность sitemap.xml и robots.txt для нового домена, а также реальную доставку тестовой заявки через форму — до, а не после того как заказчик отправит первый боевой лид.
Забытые относительные пути к шрифтам и иконкам — распространённая причина, почему скопированная страница «выглядит немного не так», хотя HTML и CSS перенесены полностью. Веб-шрифты, подключённые через @font-face с относительным путём к файлу .woff2, и иконочные спрайты, зависящие от абсолютных путей исходного домена, при простом копировании CSS-файла перестают подгружаться, и браузер незаметно подставляет системный шрифт по умолчанию.
Вторая проблема — JavaScript-виджеты, завязанные на API-ключ оригинального владельца (карты, чат-виджеты, калькуляторы курса). Внешне такой виджет продолжает загружаться после переноса, но при исчерпании лимита запросов по чужому ключу — или ещё быстрее, если владелец ключа его отзовёт, заметив чужой домен в списке использования, — функциональность отключается без предупреждения на стороне переносимого сайта.
Третья — мобильная версия, скопированная не полностью. Если у исходного лендинга мобильная вёрстка реализована через отдельный CSS-файл или условную загрузку ресурсов по User-Agent, а при снятии копии сохранялась только десктопная версия страницы, итоговая копия может выглядеть корректно на компьютере и полностью ломаться на телефоне — это стоит явно проверять, а не полагаться на то, что адаптивность «перенеслась вместе с остальным CSS».
Четвёртая — отсутствие HTTPS и смешанный контент. Ресурсы, подключённые в скопированном коде по протоколу http:// вместо https:// или с абсолютным URL исходного домена, при выпуске SSL-сертификата на новом домене вызывают предупреждение браузера о смешанном содержимом и блокировку части ресурсов — это тот самый пропущенный абсолютный путь, который стоит вылавливать поиском по исходному домену перед сдачей работы.
