Аудит сайту і які проблеми він знаходить

Сайт працює, замовлення приходять, скарг немає. Питання «Чи не пора його перевірити?» звучить у такій ситуації дивно, і саме тому перевіряють зазвичай після аварії, а не до неї.

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

Чому сайт, який працює, все одно варто перевірити

Аудит потрібен не завжди. Є моменти, коли він окупається одразу, і моменти, коли гроші на нього підуть даремно.

• Сайту більше трьох років. За цей час змінилися вимоги пошуковика, версії програм і сам бізнес.
• Змінився підрядник. Нова команда має розуміти, що дісталося в спадок.
• Трафік просів без видимої причини. Реклама не змінювалася, а заявок стало менше.
• Планується велике доопрацювання. Дешевше з’ясувати стан до того, як почати додавати нове.
• Сайт передають усередині компанії. Той, хто ним займався, іде, і треба зафіксувати, що є.

Якщо жоден пункт не про вас і сайт зроблено торік, аудит можна відкласти.

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

Що накопичується за роки

Плагіни, які поставили й забули

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

Вимкнені розширення теж мають вагу. Вони не працюють, але залишаються на диску, і незакрита вразливість у файлі, який лежить у теці, працює незалежно від того, увімкнено плагін чи ні.

Окрема категорія це розширення, які більше не оновлюються. Автор перестав їх підтримувати, а сайт продовжує на них триматися. Це не привід негайно все ламати, але знати про такі місця треба.

База, що розрослася від логів і чернеток

База даних росте навіть тоді, коли товарів і сторінок не додається.

• Чернетки й версії сторінок. Кожне збереження створює копію, і за роки їх накопичуються тисячі.
• Журнали розширень. Частина плагінів пише свою історію в базу й ніколи її не чистить.
• Тимчасові записи. Створюються для кешу й мають зникати самі, але часто не зникають.
• Дані видалених розширень. Плагін прибрали, а його таблиці залишилися.
• Записи від старих інтеграцій. Обмін із сервісом, яким уже не користуються.

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

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

Застаріла версія PHP

Версія PHP, на якій працює сайт, з часом перестає отримувати виправлення безпеки. Сайт при цьому продовжує працювати нормально, і саме тому питання відкладають.

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

Доступи, про які ніхто не пам’ятає

Це найнеприємніша частина, бо вона не технічна.

Справжній ризик у тому, що в разі будь-якого інциденту неможливо зрозуміти, звідки він прийшов.

Друга сторона цієї ж проблеми виявляється в момент, коли доступ терміново потрібен. Домен оформлений на колишнього співробітника, пошта прив’язана до його особистої адреси, а він давно не працює і не відповідає. Такі історії розв’язуються, але процедура відновлення в реєстратора займає тижні, і робити її під тиском обставин значно неприємніше, ніж спокійно.

Копії, яких насправді немає

Питання про резервні копії ставлять усім, і відповідь майже завжди ствердна. Уточнювальні питання змінюють картину.

• Де вони лежать. На тому самому сервері це не копія.
• Що саме зберігається. Файли без бази або база без файлів марні.
• Наскільки вони свіжі. Копія місячної давності для інтернет-магазину майже нічого не рятує.
• Чи пробували відновлювати. Зазвичай ні.
• Скільки триває відновлення. Цю цифру не знає майже ніхто.

Практична частина аудиту зводиться до одного кроку. Береться свіжа копія і розгортається на тестовому майданчику. Результат буває несподіваним.

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

Сліди старих підрядників у коді

Коли сайтом за роки займалися три різні команди, у коді залишаються шари.

Найчастіше трапляється дублювання. Те саме завдання розв’язане двічі різними способами, обидва рішення працюють одночасно й іноді конфліктують. Далі йдуть правки, внесені прямо у файли розширень. Вони працюють лише до наступного оновлення, яке перезаписує файли, і проблема, яку вони розв’язували, повертається.

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

Ще одна знахідка, характерна для сайтів зі складною історією, це кілька систем аналітики одночасно. Два або три різні лічильники, поставлені різними людьми в різні роки. Дані в них не збігаються, довіряти незрозуміло якому, і в підсумку не дивляться в жоден.

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

Форми, аналітика та шлях заявки

Технічна частина показує стан сайту, але власника цікавить інше: чи доходять заявки. Це перевіряють окремо, і саме тут знаходять найдорожчі помилки.

• Форма надсилає лист. І він приходить не в небажану пошту.
• Адреса отримувача актуальна. Часто там залишається скринька людини, яка звільнилася.
• Заявка десь зберігається. Крім листа, який можна випадково видалити.
• Джерело переходу передається. Інакше рекламу нічим оцінювати.
• Подія фіксується в аналітиці. Щоб бачити конверсію, а не тільки візити.
• Працює на телефоні. Перевірено на реальному пристрої.

Тестова заявка з телефону, надіслана в присутності замовника, знімає більшість питань за п’ять хвилин. Буває, що вона просто не доходить, і виявляється, що так триває вже кілька місяців.

Що показує сам Google про ваш сайт

Частина відповідей уже є в Google Search Console, і власники туди зазвичай не заглядають.

• Скільки сторінок в індексі. Якщо їх у кілька разів більше, ніж реальних, десь генеруються дублі.
• Які сторінки виключені й чому. Часто там виявляються потрібні розділи.
• За якими запитами сайт показується. Іноді зовсім не за тими, на які розраховували.
• Помилки сканування. Биті посилання, недоступні сторінки, повільні відповіді.

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

Що дивляться очима, а не інструментом

Частину знахідок не бачить жодна програма, і саме вони зазвичай обходяться найдорожче.

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

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

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

Відкрити свій сайт і сайти двох конкурентів у сусідніх вкладках. Це дає більше, ніж будь-який перелік технічних зауважень, бо відвідувач саме так і вибирає.

Як виглядає звіт після перевірки

Звіт має бути таким, щоб з ним можна було працювати, а не милуватися.

• Перелік знахідок із поясненням. Що знайдено, чим це загрожує, наскільки терміново.
• Розділення за терміновістю. Критичне, планове, бажане.
• Оцінка робіт. Скільки годин займе кожен пункт.
• Що можна зробити самому. Частина пунктів не потребує підрядника.
• Що робити не варто. Іноді правильна відповідь це залишити як є.

Останній пункт відрізняє корисний аудит від переліку зауважень. Не кожна знахідка вимагає виправлення, і чесний звіт це прямо називає.

Формат подання теж має значення. Звіт на сорок сторінок з автоматичного інструмента виглядає солідно й не дає нічого: у ньому сотні однотипних зауважень без розділення на важливе й дрібне. Робочий звіт коротший і побудований від наслідків, а не від технічних параметрів: не «відсутній атрибут», а «через це сторінка не показується за таким запитом».

Що виправляють одразу, а що йде в план робіт

Одразу виправляють те, що створює ризик або вже забирає гроші.

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

Планове це оновлення версій, чистка бази, прибирання зайвих розширень і робота зі швидкістю. Вони робляться за графіком, з копією перед кожним кроком.

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

Скільки триває перевірка й скільки коштує

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

Пошукову частину перевірки, тобто індексацію, дублі, редиректи, карту сайту й швидкість, робимо в межах SEO-оптимізації та просування і рахуємо разово, від $200. Плагіни, налаштування хостингу, резервні копії, доступи й код попередніх підрядників перевіряємо в межах підтримки та розвитку проєктів. Первинний огляд і орієнтовну оцінку робимо безкоштовно. Повну перевірку заздалегідь оцінюємо в годинах, і залежно від обсягу вона йде в рахунок годин абонемента або оплачується погодинно. Далі виправлення або входять у регулярне обслуговування, або робляться разово, і що включає кожен формат, описано в матеріалі про те, що входить у підтримку сайту.

Чим аудит відрізняється від приймання

Приймання перевіряє, чи зробили те, що замовляли, і робиться один раз під час здачі нового сайту. Усі його пункти зібрано в чек-листі приймання сайту.

Аудит перевіряє стан сайту, який працює давно, і шукає не невиконані обіцянки, а накопичені наслідки. Перелік пунктів частково збігається, але питання ставляться різні: там «Чи все зробили?», тут «Що зіпсувалося за цей час?».

Висновки

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

Така перевірка знімає невизначеність, і це її головна цінність. Власник перестає гадати, чому просів трафік і чи страшно оновлювати систему, і починає ухвалювати рішення за фактами.

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