Шаблон: книга аналізу серверних логів для SEO

Книга аналізу логів (для заповнення)

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

Книга аналізу серверних логів

Джерело логів: [сервер, CDN або балансувальник навантаження] · Період: [щонайменше 30 днів] · Усього перевірених запитів Googlebot: [кількість]

Аркуш 1: перевірка

Аркуш 2: класи URL

Аркуш 3: перевірка ключових сторінок

Марне сканування = перевірені звернення до класів URL, які вам не потрібні в пошуку, плюс звернення, що закінчуються редиректами, soft 404 або помилками. Запишіть частку як відношення до всіх перевірених звернень і тримайте формулу поруч.

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

Чи це вам взагалі потрібно

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

Чи важливий для вас бюджет сканування?

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

У посібнику Google про бюджет сканування наведено орієнтовні пороги: сайти з приблизно 1 мільйоном унікальних сторінок або більше, які змінюються щотижня, сайти з 10 000 сторінок або більше, які змінюються щодня, і сайти, де велика частка URL застрягла в статусі "Discovered - currently not indexed" (виявлено, але наразі не проіндексовано). На менших сайтах логи все одно корисні: вони допомагають знайти помилки та цикли редиректів, на які постійно натрапляє Googlebot.

Тривожні сигнали, що виправдовують цю роботу

• Фасетна навігація або фільтри створюють нескінченні комбінації URL
• Важливі сторінки не індексуються тижнями після публікації
• Search Console показує багато URL зі статусом "Discovered – currently not indexed" (виявлено, але наразі не проіндексовано)
• Серверні логи переповнені зверненнями ботів до параметрів, сортування чи пагінації

[URL сайту]: вкажіть тут приблизну загальну кількість URL: [Усього URL]. Якщо їх небагато і сторінки індексуються швидко, пропустіть решту та зосередьтеся на іншому.

Отримання та підготовка лог-файлів

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

Де знайти логи

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

Типові джерела: ваш вебсервер (Apache, Nginx), CDN (наприклад, Cloudflare чи Fastly) і будь-який балансувальник навантаження перед ними. Вивантажте дані з [Джерело логів] за період [Період].

Підготуйте дані

1. Об'єднайте логи з усіх серверів, щоб не пропустити запити, які обслуговували різні машини.
2. Переконайтеся, що кожен рядок містить мітку часу, запитаний URL, код статусу, user agent та IP-адресу.
3. Перевірте Googlebot: виконайте зворотний DNS-запит для IP і переконайтеся, що хост закінчується на googlebot.com, google.com або googleusercontent.com, потім виконайте прямий запит і переконайтеся, що він повертає ту саму IP. Для великих файлів натомість звіряйте IP зі списками діапазонів IP, які Google публікує для своїх краулерів. Ніколи не довіряйте лише рядку user agent.
4. Залиште тільки перевірених пошукових ботів, перш ніж робити висновки про поведінку сканування.

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

Аналіз патернів сканування

Коли використовувати: Зрозумійте, що Googlebot насправді сканує, як часто і які коди статусу отримує.

На що дивитися спочатку

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

Ключові питання

• Які URL скануються найчастіше? Порівняйте найбільш скановані URL з найважливішими сторінками. Розбіжності - це сигнал.
• Як часто скануються ключові сторінки? Комерційні сторінки мають відвідуватися регулярно; важливі URL, які скануються рідко, застарівають.
• Які коди статусу бачить Googlebot? На здоровому сайті переважають 200. Стежте за сплесками 404, редиректів 301/302 та серверних помилок 5xx.
• Які розділи домінують? Згрупуйте звернення за директоріями, щоб побачити, чи не забирає малоцінний розділ активність сканування.

Запишіть висновки для [Найбільш сканований розділ] і позначте розділ, який сканується надмірно відносно своєї цінності: [Надмірно сканований шлях].

Інтенсивне сканування редиректів чи помилок - марні зусилля, які слід прибрати на наступних кроках.

Пошук марного сканування

Коли використовувати: Визначте малоцінні, дубльовані та биті URL, що виснажують ресурси сканування.

Куди витікає бюджет сканування

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

Типові джерела марного сканування

• Фасетні URL та URL з параметрами: фільтри, сортування та параметри відстеження, що перетворюють одну сторінку на тисячі варіантів.
• Дубльований контент: та сама сторінка доступна за кількома URL, зі слешем у кінці чи без, з великими чи малими літерами в шляху.
• Soft 404: порожні результати, прострочені оголошення чи бідні сторінки, які повертають 200, але не мають цінності.
• Ланцюжки редиректів: URL, що проходять кілька переходів, перш ніж дійти до цілі.
• Нескінченні простори: календарі, результати пошуку та ідентифікатори сесій, що генерують майже нескінченну кількість URL.
• Видалені сторінки, які досі віддають контент: у посібнику Google сказано, що назавжди видалені сторінки мають повертати 404 або 410, а не 200.

За результатами аналізу логів перелічіть тут найгірші випадки: [Патерн марного сканування 1], [Патерн марного сканування 2]. Оцініть частку звернень Googlebot до цих малоцінних URL: це число і є вашою можливістю. Пріоритезуйте виправлення за тим, скільки активності сканування забирає кожен патерн.

Підвищення ефективності сканування

Коли використовувати: Вживіть конкретних заходів, щоб пошукові системи витрачали зусилля сканування на важливі сторінки.

Спрямуйте краулерів на важливе

Коли ви знаєте, де марне сканування, мета - консолідувати сигнали та спрямувати ботів до цінних канонічних URL.

1. Посильте внутрішні посилання на важливі сторінки, щоб їх було легко знайти і щоб вони сигналізували про свій пріоритет.
2. Тримайте XML-карти сайту чистими: додавайте лише канонічні URL, доступні для індексації, і прибирайте редиректи, помилки та сторінки з noindex.
3. Використовуйте robots.txt для URL, які ви ніколи не хочете сканувати, наприклад внутрішній пошук і нескінченні простори параметрів. Google не радить використовувати його для тимчасового перерозподілу бюджету, а блокування сканування - не те саме, що видалення з індексу.
4. Не покладайтеся на noindex, щоб зекономити сканування. Google все одно має запросити сторінку, щоб побачити тег.
5. Обробляйте параметри за допомогою тегів canonical, що вказують на чисту версію, і не ставте внутрішніх посилань на URL з параметрами.
6. Виправте ланцюжки редиректів, спрямувавши перший перехід одразу на кінцеву адресу одним 301.
7. Усуньте soft 404: повертайте справжній 404 або 410 або покращте сторінку, щоб вона заслуговувала на сканування.

Запишіть три головні дії: [Дія 1], [Дія 2], [Дія 3]. Впроваджуйте зміни поступово, щоб можна було виміряти їхній ефект.

Моніторинг через статистику сканування

Коли використовувати: Відстежуйте поведінку сканування з часом за допомогою Search Console та регулярних перевірок логів.

Замкніть цикл

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

За чим стежити

• Звіт «Статистика сканування» (Crawl Stats) у Search Console (розділ «Налаштування» (Settings), лише для ресурсів кореневого рівня): переглядайте загальну кількість запитів на сканування, середній час відповіді та розподіл за відповіддю, типом файлу, метою (виявлення чи оновлення) і типом Googlebot.
• Стан хоста (Host status): охоплює отримання robots.txt, DNS і з'єднання з сервером за останні 90 днів. Повільний сервер або сервер із помилками змушує Google сканувати менше.
• Динаміка кодів статусу: переконайтеся, що після виправлень кількість 404, редиректів і помилок 5xx знижується.
• Звіти про індексування: перевірте, чи переходять сторінки, що раніше застрягли, у стан проіндексованих.

Створіть регулярний процес

Регулярно (щомісяця або щокварталу) вивантажуйте серверні логи заново і порівнюйте з базовим рівнем. Запишіть тут дату перевірки: [Дата наступної перевірки] та відповідального: [Відповідальний].

Якщо марне сканування повернеться, ви помітите це рано, а не після того, як важливі сторінки випадуть з індексу.

Заповнений приклад (вигаданий маркетплейс)

Коли використовувати: Заповнена книга для вигаданого маркетплейсу вживаних фотокамер, де URL фільтрів поглинають сканування.

Заповнений приклад: LensLoop

Лише приклад. Компанію, людей, URL і цифри вигадано, щоб показати, як виглядає придатна до використання заповнена версія.

30 днів логів CDN. 412 000 запитів заявляли, що вони від Googlebot; 398 000 пройшли перевірку.

Що показали цифри

Близько 62% перевірених звернень припадало на URL, які команді не були потрібні в пошуку: фільтри, продані оголошення та редиректи. Нові оголошення знаходилися, але сторінки категорій оновлювалися повільно. Першим виправленням стали правила для фільтрів, бо цей клас був найбільшим.

Наступний крок

Відстежте знайдені ланцюжки за допомогою Redirect Checker, перебудуйте чисті карти сайту в XML Sitemap Generator і підготуйте правила для параметрів у Robots.txt Generator, перш ніж їх тестувати. Запустіть аудит сайту, щоб виявити проблеми зі статусами та редиректами, на які вказують ваші логи. Якщо потрібен аудит логів «під ключ», наша партнерська агенція SEOquick виконує проєкти з технічного SEO.