Що робити відразу після запуску нового сайту: рекомендації + цікавий кейс

  1. Аналіз логів сервера на старті проекту - нагальна потреба
  2. Історія одного запуску, який мало не провалився

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

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

На жаль немає.

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

В першу пару тижнів після старту за сайтом потрібно стежити особливо уважно і оперативно його доопрацьовувати. Новонароджений ресурс вразливий (наприклад, для злодіїв контенту). Не завадить, якщо перше враження на пошукові системи буде сприятливим.

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

Що ж робити? Очевидно, користуватися тими даними, які є.

Аналіз логів сервера на старті проекту - нагальна потреба

За великим рахунком, логи - єдине, що є в перші дні. Для оптимізатора важливий в першу чергу access.log . Заодно можна поставити розробнику завдання розгрібати лог помилок і виправляти їх - гірше не буде.

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

  • Відвідування сторінок, яких немає в карті сайту (а не сміттєвий це документ?).
  • Помилки сервера, в першу чергу 404. На новому нормальному сайті їм взятися нізвідки. Варто перевірити і редіректи (301,302).
  • Звернення з малою кількістю відданих байт. Знову ж підозра на сміттєвий контент або некоректну роботу скрипта, неповне завантаження.
  • Безліч заходів з одного і того ж IP (��проба злому? Парсинг контенту?).

Зрозуміло, неоціненну допомогу логи можуть надати для прискорення індексації великих сайтів. Приклад використання показував в доповіді на SEMPRO :

Для автоматизації аналізу можна використовувати цей безкоштовний інструмент . Майте на увазі, що всю роботу він за вас не зробить, тому що можливих проблем сила-силенна. На щастя, на стадії запуску журнали не такі великі (немає реальних відвідувачів, в основному боти). Лог за день-два можна переглядати і вручну, використовуючи простий пошук в Notepad.

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

Історія одного запуску, який мало не провалився

Якось до мене звернулися за аудитом для щойно створеного сайту.

Взагалі-то правильно спочатку зробити аудит, а потім вже відкривати доступ до ресурсу. Але краще вже так, ніж через два роки після старту.

Я насамперед зажадав логи. Відкриваю і бачу, що Googlebot досить активно повзає по сторінках, буквально з першого ж дня. Якось підозріло, не схоже на нього (див. тут ).

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

Реферер - це один з HTTP-заголовків, які відправляються при запиті url з сервера. Містить адресу джерела переходу. Якщо ви клацніть по посиланню вище, яка веде на статтю в Вікі про access.log, то в балці Вікіпедії з'явиться запис з реферером http://alexeytrudov.com/biznes/internet/ srazu-posle-zapuska .html.

Реферер у вигляді адреси одній зі сторінок сайту може з'являтися у заходу пошукового робота, якщо запитується файл css або js. Це нормальна ситуація. Ну а в описуваному випадку показувався зовсім стороння сайт.

Виявилося, що на домені з реферера розташовується повна копія проекту! Домен мав А-запис з виділеним IP сайту, який я аудійовані. Тобто через налаштувань зони DNS і сервера клієнта за адресою чужого домену віддавався весь контент сайту. Візити Googlebot насправді відбувалися на адреси, що належать чужому домену (звідси і реферер). Більш того, десятки сторінок з чужого сайту вже потрапили в індекс!

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

Як вирішили проблему:

  • Оперативно завели на сервері клієнта сайт з чужим доменним ім'ям і поставили заглушку з відповіддю сервера 410. Вона стала відкриватися по всіх адресах, у тому числі тим, які вже потрапили в індекс.
  • Додали canonical там, де він був відсутній (для Google в принципі цього було б достатньо, але так як Яндекс не враховує міждоменні canonical, обмежуватися тільки їм не можна).
  • Розробник написав скрипт для моніторингу логів і відстеження заходів з реферером; знайшли і знешкодили ще один домен.

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

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