Розробник зник або зробив криво: як врятувати інтернет-магазин

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

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

Знайомі симптоми

Якщо ви впізнаєте хоча б два-три пункти зі списку, проблема вже не в дрібних багах, а в тому, як зроблений і як підтримується сайт:

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

Крок 1. Заберіть усі доступи

Це найважливіший крок, і робити його треба одразу, поки розробник ще хоч якось виходить на зв’язок. Без доступів ви не зможете ні виправити сайт, ні перенести його до іншої команди. Складіть список і перевірте кожен пункт особисто, а не зі слів розробника.

Що забрати	Навіщо
Домен (кабінет реєстратора)	Без нього сайт можуть просто відключити або не продовжити. Домен має бути оформлений на вас або вашу компанію
Хостинг або сервер	Тут фізично лежать файли і база даних магазину
Адмінка CMS з правами адміністратора	Не «менеджерський» доступ, а повний — з керуванням модулями й користувачами
FTP/SFTP і база даних	Потрібні для резервної копії, перенесення і роботи нового розробника
Google Analytics, Search Console, Tag Manager, Merchant Center	Статистика, позиції та реклама — ваша історія, яку не можна втрачати
Платіжні системи, служби доставки, CRM	Ключі API, через які сайт приймає оплату і передає замовлення
Пошта на домені і DNS	Від них залежить, чи доходять листи клієнтам і заявки вам
Репозиторій з кодом (якщо є)	Історія змін і власні модулі, написані під ваш магазин

 

Окремо перевірте, на кого оформлений домен. Зробити це можна через сервіс WHOIS або в кабінеті реєстратора. Якщо власник — розробник, попросіть передати домен на вас: у більшості реєстраторів це робиться через зміну власника або передачу в інший акаунт.

Що робити, якщо розробник не відповідає

Почніть з письмового звернення з чітким списком доступів і терміном. Якщо відповіді немає, звертайтеся напряму до хостинг-провайдера і реєстратора домену: підтвердьте, що сайт ваш, — договір, рахунки, оплати хостингу з вашої картки, листування. Провайдери регулярно вирішують такі ситуації, але чим більше документів, тим швидше. Тому договір і чеки зберігайте з першого дня.

Крок 2. Зробіть резервну копію

Щойно доступи у вас — зробіть повну копію сайту: файли й базу даних. Зберігайте її не на тому ж хостингу, а окремо: на своєму комп’ютері чи в хмарі. Якщо під час подальших робіт щось піде не так або колишній розробник вирішить «помститися», у вас буде робоча версія, яку можна відновити за годину.

Резервні копії мають робитися й надалі — автоматично і регулярно. Якщо на хостингу немає автоматичних бекапів, це перше, що варто налаштувати.

Крок 3. Проведіть технічний аудит

Зовні магазин може виглядати нормально, а всередині мати проблеми, які рано чи пізно вилізуть. Аудит відповідає на головне питання: що на сайті зроблено правильно, а що доведеться переробляти. Ось що перевіряють у першу чергу.

Що перевіряємо	Тривожні ознаки
Версія CMS, PHP і модулів	Застаріла версія без оновлень безпеки; хостинг вимагає новішого PHP, а сайт на ньому падає
Правки в ядрі CMS	Розробник змінював системні файли замість модифікаторів — будь-яке оновлення зламає сайт
Звідки взяті модулі	Піратські або «нульовані» модулі без ліцензії — часте джерело шкідливого коду
Безпека	Сторонні користувачі в адмінці, підозрілі файли, переадресації на чужі сайти
Оформлення замовлення	Тестове замовлення з телефона не проходить, не приходять листи, не працює оплата
Швидкість	Низькі показники PageSpeed, особливо на мобільних, повільний каталог і кошик
Мобільна версія	Елементи виходять за межі екрана, дрібні кнопки, незручні фільтри
SEO-база	Сайт закритий від індексації, дублі сторінок, биті посилання, немає редиректів

 

Частину цього можна перевірити самостійно: зробити тестове замовлення з телефона, прогнати сайт через PageSpeed Insights, подивитися в Search Console, скільки сторінок у індексі. Але правки в ядрі, безпеку і якість коду оцінить лише розробник, який подивиться в код.

Пастки, які найчастіше знаходяться на аудиті

Окремо варто згадати проблеми, про які власник магазину зазвичай навіть не здогадується, доки вони не вистрілять:

• Сайт закритий від індексації. Під час розробки сайт закривають від пошукових систем, а після запуску забувають відкрити. Магазин працює місяцями, а Google його просто не бачить.
• Аналітика на акаунті розробника. Google Analytics і Search Console підключені до чужої пошти. Коли розробник зникає, разом з ним зникає і вся історія статистики.
• Тестовий режим оплати. Платіжний модуль залишився в тестовому режимі або з ключами розробника — клієнт «оплачує», але гроші не надходять.
• Листи падають у спам. Пошта відправляється без налаштованих записів SPF і DKIM, тому підтвердження замовлень і листи клієнтам не доходять.
• Сертифікат SSL не продовжується автоматично. Одного дня браузер починає показувати покупцям попередження «небезпечний сайт».
• Немає жодної резервної копії. Достатньо однієї невдалої правки чи збою хостингу, щоб втратити магазин разом з товарами й замовленнями.

Кожна з цих проблем виправляється швидко, але лише за умови, що про неї знають. Саме тому аудит потрібен навіть тоді, коли сайт «начебто працює».

Доопрацювати чи переробити?

Це головне питання, і відповідь не завжди «переробити все з нуля». Часто достатньо виправити зламане й привести до ладу код, а все, що працює, — залишити. Орієнтуйтеся на таблицю:

Доопрацювання вигідніше, якщо	Переробка вигідніша, якщо
Сайт на популярній CMS (OpenCart, WordPress) без серйозних правок у ядрі	Сайт на самописному рушії, який ніхто, крім автора, не розуміє
Проблеми локальні: окремі сторінки, модулі, мобільна версія	Проблеми всюди, і кожне виправлення тягне за собою нові
Дизайн загалом влаштовує, криві лише окремі блоки	Дизайн застарів і відлякує покупців
Сайт уже має позиції в Google і стабільний трафік	Позицій немає, тож втрачати при переїзді нічого
Потрібно додати кілька функцій	Потрібна принципово інша логіка магазину

 

Якщо вирішили переробляти, плануйте переїзд так, щоб не втратити накопичене: зберегти адреси сторінок або налаштувати редиректи зі старих на нові, перенести товари, відгуки і клієнтів, зберегти аналітику. Тоді новий сайт стартує не з нуля, а з того, що вже заробив старий.

Як обрати, хто підхопить сайт

Після поганого досвіду хочеться знайти «того самого» надійного підрядника. Кілька ознак, на які варто звернути увагу:

• Починає з аудиту, а не з оцінки «на око». Чесна команда спершу дивиться в код, а потім називає терміни й вартість.
• Пояснює, що саме буде робити. Ви маєте розуміти план робіт, а не отримувати лише суму в рахунку.
• Працює за договором. З прописаними термінами, правами на код і гарантією на виконані роботи.
• Готовий до підтримки. Сайт — не разова покупка: оновлення, бекапи і дрібні правки потрібні постійно.

Як не потрапити в цю ситуацію знову

Більшості проблем можна уникнути ще на етапі замовлення сайту. Ось чек-лист, який варто пройти з будь-яким підрядником — новим чи старим:

1. Домен і хостинг оформлені на вас. Розробник отримує доступ, але власником є ваша компанія.
2. Договір з правами на код. Після оплати код належить вам, і ви можете передати його іншій команді.
3. Ліцензійні модулі. Платні модулі куплені на ваш акаунт, а не «знайдені в інтернеті».
4. Без правок у ядрі CMS. Доробки робляться через модулі й модифікатори, щоб сайт можна було оновлювати.
5. Тестовий сервер. Великі зміни спершу перевіряють на копії сайту, а не на робочому магазині.
6. Автоматичні бекапи. Копії зберігаються окремо від сайту і регулярно перевіряються.
7. Список доступів у вас. Актуальний документ з усіма логінами, який оновлюється після кожної зміни.

Підсумок

Якщо розробник зник або залишив сайт у поганому стані, діяти треба в такому порядку: забрати доступи, зробити резервну копію, провести аудит і лише потім вирішувати — доопрацьовувати чи переробляти. Поспішне рішення «зробимо все з нуля» часто коштує дорожче, ніж грамотне виправлення того, що є. Ми беремо на технічну підтримку сайти, зроблені іншими командами, доопрацьовуємо магазини на OpenCart і WordPress, а якщо стару версію рятувати невигідно — робимо новий інтернет-магазин з переїздом без втрати позицій. Якщо магазин працює, але продає гірше, ніж міг би, перевірте, чи є в ньому необхідний функціонал.