Доработка чужого сайта: с чего начать, если проект создавал другой разработчик

Краткий ответ

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

Когда возникает эта ситуация

Чаще всего к доработке чужого сайта приходят в таких случаях:

Общий признак один: сайт работает и приносит заявки, поэтому рисковать им нельзя, а разобраться в нём — некому.

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

Варианты решения

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

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

Переписать сайт с нуля. Радикальный вариант, который оправдан при тяжёлом устаревшем коде, но не должен быть решением «по умолчанию»: он дороже, дольше и несёт риски для SEO.

Как проходит работа по доработке

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

После этого разворачивается тестовая среда: правки сначала идут на копии сайта, а не на боевой версии. Дальше — инвентаризация: версии PHP, CMS, плагинов и пакетов, зависимости, cron-задачи, интеграции с оплатой, доставкой и CRM. И только после этого составляется план доработок по приоритетам: сначала то, что влияет на заявки и стабильность.

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

Что влияет на сроки и стоимость

Честный список факторов, без «зависит от всего»:

• полнота передачи дел — нет доступов к хостингу, добавляется время на перенос и смену учётных данных;
• возраст и качество кода — самописные решения десятилетней давности разбирать дольше, чем актуальный WordPress со стандартной темой;
• количество интеграций — каждая связка с 1С, CRM или платёжным шлюзом отдельная зона риска;
• наличие тестовой среды — если её нет, её нужно сделать, это разумные вложения, а не переплата;
• срочность — аварийные правки вне очереди всегда стоят дороже плановых.

Частые ошибки заказчика

• давать правки «прямо на боевой сайт», чтобы «побыстрее» — быстрее получается один раз из десяти;
• не менять пароли после ухода прежнего подрядчика — доступы это актив компании, а не разработчика;
• требовать смету до аудита — по внешнему виду сайта невозможно понять состояние кода;
• сравнивать исполнителей только по цене часа — дешёвый час на разборе легаси-кода легко превращается в дорогой месяц.

Связанный кейс

Похожая ситуация была в проекте переноса WordPress-сайта на VPS: сайт был ограничен возможностями старого хостинга, поэтому новый исполнитель сначала поднял собственное окружение (Nginx, PHP-FPM, MySQL), перенёс файлы и базу, настроил HTTPS и редиректы — и только после этого реализовал доработки: кастомное формирование PDF коммерческих предложений, сквозную аналитику и улучшение архитектуры сайта.

Если у вашего проекта неполные логи и непонятные сбои, полезен и кейс о диагностике при ограниченной наблюдаемости.

Следующий шаг

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

FAQ

Что делать, если прежний разработчик не отдаёт пароли? Доступы к хостингу и домену восстанавливаются через регистратора и хостинг-провайдера по документам владельца. Админку сайта при крайней необходимости сбрасывают через базу. Это неприятно, но решаемо.

Сколько времени занимает аудит чужого сайта? Для типового сайта на CMS — от нескольких дней до двух недель в зависимости от размера проекта и полноты доступов.

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

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

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