Аналіз серверных лог-файлаў для адсочвання пошукавых ботаў — гэта самы надзейны спосаб убачыць, якія URL-адрасы, з якой частатой, з якімі кодамі стану і спажываннем рэсурсаў наведваюць Googlebot, Bingbot і іншыя краўлеры на вашым сайце. У той час як SEO-інструменты прапануюць толькі ацэнкі, серверныя логі паказваюць рэальныя запыты, непасрэдна зафіксаваныя вашым серверам. Гэта дазваляе вам дакладна вымераць марнаванне краўлінгавага бюджэту, памылкі 404/500, ланцужкі перанакіраванняў, сканіраванне непатрэбных дынамічных URL-адрасоў з параметрамі і праверыць, ці дастаткова часта боты наведваюць важныя старонкі.
Тэхнічнае SEO часта засяроджваецца на бачных рэчах: унутранай аптымізацыі, хуткасці, мікраразметцы і спасылкавым профілі. Але каб зразумець, як пошукавая сістэма бачыць ваш сайт, неабходна вывучаць паводзіны ботаў. Самая неапрацаваная і дакладная крыніца інфармацыі пра іх — гэта access-логі. Асабліва для буйных інтэрнэт-крамаў, навінавых парталаў, SaaS-праектаў, шматмоўных сайтаў і блогаў з актыўным кантэнтам аналіз логаў адыгрывае крытычную ролю ў вырашэнні праблем з індэксацыяй.
У гэтым кіраўніцтве мы пакрокава разгледзім практычны падыход, які выкарыстоўваецца ў блогу Hostragons: дзе знайсці серверныя логі, якія палі чытаць, як адрозніць сапраўдных пошукавых ботаў ад падробак, якія паказчыкі адсочваць для SEO і як ператварыць вынікі аналізу ў канкрэтныя дзеянні. Калі для рэгулярнага аналізу логаў вам патрэбна надзейная хостінгавая інфраструктура, звярніце ўвагу на Hostragons Вэб-хостынг, а для праектаў з высокім трафікам — на Hostragons VPS Server.
Што такое серверны лог-файл і чаму ён важны для SEO?
Серверны лог-файл — гэта журнал, у якім запісваецца кожны запыт да вашага вэб-сервера. Калі карыстальнік адкрывае галоўную старонку, Googlebot скануе катэгорыю або сканер бяспекі адпраўляе запыт — гэтая падзея фіксуецца ў логу. Звычайна ён змяшчае дату, час, IP-адрас, запытаны URL, HTTP-метад, код стану, памер адказу, user-agent і часам час водгуку.
Для SEO лог-файлы важныя тым, што яны паказваюць, як пошукавыя сістэмы скануюць ваш сайт. Google Search Console дае статыстыку сканіравання, але не заўсёды дэталізуе кожны запыт на ўзроўні URL, не ахоплівае ўсіх ботаў і не заўсёды аператыўна паказвае памылкі сервера. Дзякуючы аналізу логаў вы можаце ўбачыць, што за апошнія 7 дзён Googlebot зрабіў 12 400 запытаў, 18% з якіх сышлі на 301-я перанакіраванні, 6% — на памылкі 404, 2% — на памылкі 500, а важныя старонкі тавараў прасканаваныя толькі на 9%.
Гэтыя даныя асабліва каштоўныя для кіравання краўлінгавым бюджэтам. Краўлінгавы бюджэт — гэта колькасць URL-адрасоў, якія боты могуць прасканаваць на вашым сайце за пэўны час. Калі ў вас шмат непатрэбных фільтраў, старонак пагінацыі, унутраных пошукавых вынікаў, URL з параметрамі або памылковых перанакіраванняў, боты марнуюць час і не дабіраюцца да каштоўных старонак. Лог-файлы дакументальна выкрываюць гэтыя страты.
На якія пытанні трэба адказаць пры адсочванні пошукавых ботаў?
Паспяховы аналіз логаў — гэта не проста адкрыццё файла і чытанне радкоў. Спачатку трэба задаць правільныя пытанні. Тэхнічныя SEO-спецыялісты звычайна шукаюць адказы на наступныя:
- Якія групы URL-адрасоў Googlebot скануе часцей за ўсё?
- Ці дастаткова часта наведваюцца важныя старонкі?
- Колькі запытаў атрымліваюць коды 200, 301, 302, 404, 410 ці 5xx?
- Ці працягваюць боты адпраўляць запыты да раздзелаў, забароненых у robots.txt?
- Ці з'ядаюць краўлінгавы бюджэт URL з параметрамі, дублі ці нізкаякасныя адрасы?
- Ці адрозніваюцца паводзіны мабільнага Googlebot ад дэсктопнага?
- Ці запавольвае час водгуку сервера сканіраванне?
- Ці марнуюць рэсурсы падробныя боты, якія маскіруюцца пад Googlebot?
Кожнае з гэтых пытанняў можа прывесці да непасрэдных дзеянняў. Напрыклад, калі Googlebot скануе шмат старых URL-адрасоў акцый і атрымлівае 404, вы можаце наладзіць 301-е перанакіраванне на адпаведную катэгорыю або, калі старонка выдаленая канчаткова, аддаваць код 410. Калі 30% запытаў ботаў ідзе на вынікі ўнутранага пошуку, варта перапрацаваць налады robots.txt, canonical, noindex або кіраванне параметрамі URL.
Дзе знаходзяцца лог-файлы?
Месцазнаходжанне лог-файлаў залежыць ад тыпу хостінгу, панэлі кіравання і вэб-сервера. На агульным хостінгу доступ да запісаў звычайна ажыццяўляецца праз cPanel, Plesk або раздзелы статыстыкі (Raw Access Logs). У праектах на VPS або выдзеленых серверах доступ адбываецца праз SSH.
Тыповыя шляхі да логаў для Apache і Nginx
На Linux-серверах для Apache часта выкарыстоўваецца шлях /var/log/apache2/access.log або /var/log/httpd/access_log. Для Nginx тыповы шлях — /var/log/nginx/access.log. Пры наладзе віртуальных хостаў для кожнага сайта можа весціся асобны лог-файл, што павышае дакладнасць аналізу на шматсайтавых канфігурацыях.
Прыклад радка логу: 66.249.66.1 - - [12/Sak/2026:10:15:22 +0300] GET /blog/tehnicnae-seo HTTP/2.0 200 18432 Googlebot/2.1. З гэтага радка вы можаце атрымаць IP-адрас, час запыту, URL, код стану, памер адказу і user-agent. Калі ваш фармат логу таксама змяшчае час водгуку, вы атрымліваеце магутны набор даных для аналізу прадукцыйнасці.
Спампоўка логаў з панэлі хостінгу
Для карыстальнікаў з базавымі тэхнічнымі ведамі самы просты спосаб — спампаваць логі праз панэль кіравання. Шукайце раздзелы "Access Logs", "Raw Logs", "Наведвальнікі" або "Вэб-статыстыка". На буйных сайтах штодзённыя логі могуць утрымліваць сотні тысяч радкоў, таму эфектыўней спампоўваць іх у сціснутым выглядзе. Для рэгулярнага доступу, бяспечнага рэзервовага капіявання і кантролю прадукцыйнасці зручныя рашэнні, такія як Хостынг cPanel Hostragons, могуць паскорыць вашу працу.
Важныя для SEO палі ў радку логу
Не кожны радок логу аднолькава каштоўны. Для SEO трэба сфакусавацца на пэўных палях. IP-адрас выкарыстоўваецца для праверкі сапраўднасці бота. Дата і час дазваляюць вымераць інтэнсіўнасць сканіравання па днях і гадзінах. HTTP-метад звычайна павінен быць GET; незвычайныя POST-запыты могуць быць падазронымі. Запытаны URL паказвае, якая старонка скануецца. Код стану паказвае даступнасць. User-agent дапамагае зразумець, хто менавіта робіць запыт. Поле часу водгуку (time taken), калі ёсць, вельмі каштоўнае для ацэнкі досведу бота і нагрузкі на сервер.
Дапусцім, за 30 дзён у логах 50 000 запытаў ад Googlebot. З іх 38 000 — з кодам 200, 7 500 — 301, 2 000 — 404, 1 200 — 304, 800 — 5xx і 500 — 302. Праблема відавочная: доля перанакіраванняў і памылак перавышае 20%. Мэта тэхнічнага SEO — звесці памылкі 5xx да нуля, скараціць 404 да разумнага мінімуму і паменшыць колькасць непатрэбных перанакіраванняў.
Як адрозніць сапраўднага Googlebot ад падробкі?
Давяраць толькі полю user-agent нельга. Шкоднасныя праграмы лёгка маскіруюцца пад Googlebot. Таму для верыфікацыі сапраўдных ботаў неабходна рабіць зваротны (rDNS) і прамы DNS-пошук. Google рэкамендуе наступны метад: пераўтварыць IP-адрас у хаст-імя праз rDNS, пераканацца, што яно заканчваецца на googlebot.com або google.com, і затым праверыць, ці вядзе гэтае хаст-імя назад да таго ж самага IP.
Працэс выглядае так: вазьміце IP з user-agent Googlebot у логу. Выканайце каманду host 66.249.66.1 або nslookup 66.249.66.1. Калі атрыманае даменнае імя выглядае як crawl-66-249-66-1.googlebot.com, пераходзьце да наступнага кроку. Цяпер выканайце прамы пошук гэтага даменнага імя. Калі вынік супадае з зыходным IP, гэта з вялікай доляй верагоднасці сапраўдны бот. Калі не супадае або выводзіць незвязанае імя — гэта падробка.
Такая праверка асабліва важная для адсячэння ботаў, якія спажываюць шмат рэсурсаў. Фальшывыя Googlebot'ы могуць ствараць нагрузку, шукаць уразлівасці або займацца крадзяжом кантэнту. Выявіўшы такі трафік, вы можаце прымяніць WAF, абмежаванне колькасці запытаў (rate limit), блакаванне IP або правілы брандмаўэра. Для налад бяспекі злучэння азнаёмцеся з Hostragons SSL сертыфікаты.
Інструменты для аналізу логаў
Няма адзінага правільнага інструмента для ўсіх. Выбар залежыць ад памеру сайта, вопыту каманды і бюджэту. Для невялікіх сайтаў можа быць дастаткова Excel, Google Sheets або простых фільтраў у камандным радку. Для сярэдніх праектаў больш эфектыўныя Screaming Frog Log File Analyser, GoAccess або скрыпты на Python. На карпаратыўным узроўні выкарыстоўваюцца Elasticsearch, Logstash, Kibana, BigQuery або SIEM-сістэмы.
| Метад | Для чаго лепш за ўсё | Перавагі | Абмежаванні |
|---|---|---|---|
| Excel або Sheets | Невялікія блогі, нізкі трафік | Лёгка асвоіць, хуткая фільтрацыя | Запавольваецца на вялікіх файлах, мае ліміты па радках |
| Камандны радок | Тэхнічныя спецыялісты, VPS | Хуткі, бясплатны, лёгка аўтаматызуецца | Патрабуе ведаў Linux |
| SEO-аналізатары логаў | Сярэднія і буйныя сайты | Гатовыя справаздачы па ботах, URL і кодах | Можа патрабаваць платнай ліцэнзіі |
| ELK або BigQuery | Карпаратыўныя, высоканагружаныя сайты | У рэальным часе, маштабуецца, дэталёва | Патрабуе экспертызы для ўсталявання і падтрымкі |
Для практычнага старту дастаткова спампаваць логі за апошнія 7-14 дзён і адфільтраваць іх па user-agent асноўных ботаў: Googlebot, Bingbot, YandexBot ды іншых. Затым можна пабудаваць зводныя табліцы па URL, кодах стану і даце. Мэта першага аналізу — не пабудаваць ідэальнае сховішча даных, а хутка знайсці самыя вялікія страты для SEO.
Пакрокавы аналіз серверных лог-файлаў
1. Вызначце мэту аналізу
Спачатку дакладна вызначце, што вы хочаце даведацца. Новыя артыкулы не індэксуюцца? Старонкі катэгорый недастаткова скануюцца? Ці ўплываюць памылкі сервера на бачнасць? Калі мэта дакладная, сігналы, якія вы шукаеце ў логу, таксама становяцца зразумелымі. Напрыклад, для праблемы індэксацыі трэба глядзець, калі Googlebot апошні раз сканаваў важныя URL. Для праблем з прадукцыйнасцю — аналізаваць коды 5xx і час водгуку.
2. Выберыце правільны часавы інтэрвал
Занадта кароткія перыяды могуць увесці ў зман, а занадта доўгія — непатрэбна павялічыць памер файла. Для малых і сярэдніх сайтаў 14-30 дзён — добры пачатак. Для хуткаабнаўляльных навінавых сайтаў маюць сэнс нават 3-7 дзён. У буйных інтэрнэт-крамах сезоны, акцыі і абнаўленні катэгорый варта дадаткова пазначаць.
3. Адфільтруйце трафік ботаў
Вылучыце ў полі user-agent такіх ботаў, як Googlebot, Googlebot-Image, Googlebot-News, Bingbot, YandexBot, DuckDuckBot, Applebot. Але не забывайцеся правяраць іх сапраўднасць для крытычных справаздач. З-за Mobile-First індэксацыі запыты Googlebot Smartphone трэба адсочваць асобна. Калі дэсктопны бот вельмі актыўны, а мабільны не, гэта можа сведчыць аб праблемах з канфігурацыяй або доступам.
4. Стварыце групы URL-адрасоў
Пастаронкавы аналіз на буйных сайтах неэфектыўны. Разбіце URL на шаблоны: галоўная, катэгорыя, тавар, блог, тэгі, фільтры, пошук, пагінацыя, выявы, API, статычныя файлы. Так вы ўбачыце, якім раздзелам боты аддаюць перавагу. Напрыклад, калі ў інтэрнэт-краме 42% запытаў Googlebot ідзе на URL з фільтрамі і толькі 18% — на старонкі тавараў, гэта праблема прыярытызацыі.
5. Ацаніце коды стану
Коды стану — адзін з галоўных індыкатараў у SEO-аналізе логаў. Код 200 азначае паспяховы доступ, 301 — пастаяннае перанакіраванне, 302 — часовае, 304 — не змянілася, 404 — не знойдзена, 410 — канчаткова выдалена, 429 — занадта шмат запытаў, 5xx — памылкі сервера. Мэта — каб важныя старонкі па магчымасці адразу аддавалі код 200, а боты не гублялі час на памылкі і ланцужкі перанакіраванняў.
6. Вымярэнне часу водгуку і нагрузкі на сервер
Калі ваш фармат логу змяшчае час водгуку, вывучыце сярэдні час і 95-ы працэнціль для запытаў ботаў. Сярэдні час 180 мс можа выглядаць добра, але калі 95-ы працэнціль складае 2800 мс, некаторыя тыпы URL запавольваюць ботаў. Асабліва ўважліва трэба праверыць старонкі з фільтрамі, унутраны пошук, дынамічныя справаздачы і старонкі з цяжкімі запытамі да базы даных. Калі вы сутыкнуліся з праблемамі прадукцыйнасці, разгледзьце больш магутныя рашэнні, напрыклад Хмарны сервер Hostragons.
Самыя крытычныя знаходкі аналізу логаў для SEO
Марнаванне краўлінгавага бюджэту
Марнаванне краўлінгавага бюджэту — гэта калі боты трацяць занадта шмат часу на няважныя URL. URL з параметрамі, фільтры сартавання, ідэнтыфікатары сесій, версіі для друку, бясконцыя каляндарныя архівы і вынікі ўнутранага пошуку — самыя частыя крыніцы. Калі аналіз логаў паказвае высокую долю такіх URL, варта разам ацаніць налады canonical, robots.txt, noindex, спрашчэнне параметраў і ўнутраную пералінкоўку.
Недастатковае сканіраванне важных старонак
Часам праблема не ў тым, што боты шмат скануюць, а ў тым, што яны скануюць не тое. Новыя старонкі тавараў, пасадачныя старонкі з высокім патэнцыялам канверсіі або абноўленыя даведнікі могуць наведвацца недастаткова. Прычынай можа быць слабая ўнутраная пералінкоўка, неактуальная карта сайта, нізкая хуткасць або глыбокае размяшчэнне ў архітэктуры. У такім выпадку абнавіце XML-карту сайта, прастаўце спасылкі з галоўных катэгорый і рэлевантнага кантэнту, знайдзіце старонкі-сіроты і паменшыце глыбіню ўкладання. Калі вы на этапе планавання дамена і структуры, пачніце з Даменны запыт, каб знайсці імя, сугучнае брэнду.
Ланцужкі перанакіраванняў
У логах часта можна ўбачыць, як боты пераходзяць са /stary-url на /pramiezhkavy-url, а потым на /novy-url. Такія ланцужкі зніжаюць карыстальніцкі досвед і эфектыўнасць ботаў. Ідэальная структура — гэта калі стары URL адразу аддае 301 на канчатковы. Пры пераносе буйных сайтаў старыя правілы перанакіравання могуць назапашвацца. Штомесячная праверка логаў дазваляе вылавіць гэтыя ланцужкі на ранняй стадыі.
Памылкі 5xx і нестабільная даступнасць
Калі пошукавыя боты часта сутыкаюцца з памылкамі 500, 502, 503 або 504, яны могуць знізіць частату сканіравання. Гэта можа паўплываць на арганічны трафік, асабліва падчас акцый. У логах праверце час узнікнення памылак 5xx, тып URL і від бота. Напрыклад, калі кожную ноч а 02:00 падчас рэзервовага капіявання расце колькасць памылак 503, варта скарэктаваць акно абслугоўвання, планаванне рэсурсаў або стратэгію кэшавання.
Як чытаць robots.txt, Sitemap і логі разам
Аналіз логаў магутны сам па сабе, але становіцца значна больш інфарматыўным у спалучэнні з данымі з robots.txt, XML-карты сайта і Google Search Console. Параўнайце, ці скануюцца ботамі URL з карты сайта. Знайдзіце URL, якія часта скануюцца, але адсутнічаюць у карце. Праверце, ці прыходзяць запыты да раздзелаў, забароненых у robots.txt. Калі забароненыя URL працягваюць з'яўляцца ў пошукавай выдачы, аднаго robots.txt недастаткова; магчыма, спатрэбіцца noindex або стратэгія выдалення.
Добрая практыка — кожны месяц ствараць тры спісы: важныя URL, якія ёсць у карце сайта, але не скануюцца; нізкаякасныя URL, якіх няма ў карце, але яны часта скануюцца; запыты ботаў з кодамі памылак. Гэтыя тры спісы — аснова вашай дарожнай карты тэхнічнага SEO.
Якія паказчыкі павінны быць у справаздачы па аналізе логаў?
Каб справаздача была зручнай для кіравання, не варта перагружаць яе мноствам лічбаў. Засяродзьцеся на паказчыках, якія вядуць да дзеянняў. Для большасці сайтаў дастатковы наступны стартавы набор:
- Агульная колькасць запытаў ботаў і размеркаванне па асобных ботах
- Суадносіны Googlebot для смартфонаў і дэсктопаў
- Размеркаванне кодаў стану: 200, 3xx, 4xx, 5xx
- Частата сканіравання па тыпах URL
- Топ-100 самых сканаваных URL
- Важныя URL, якія не скануюцца або скануюцца вельмі рэдка
- Сярэдні час водгуку і 95-ы працэнціль
- URL, якія часцей за ўсё аддаюць 404 і 5xx
- Доля запытаў з параметрамі
- Спіс фальшывых ботаў або падазроных user-agent
Рыхтуйце справаздачу на рэгулярнай аснове — штотыдзень ці штомесяц — і параўноўвайце дынаміку. Напрыклад, калі ў студзені доля памылак 5xx была 1,8%, а ў лютым знізілася да 0,2%, вы даказалі эфект ад паляпшэння інфраструктуры. Калі пасля ўнутранай пералінкоўкі колькасць запытаў Googlebot да кантэнту блога вырасла на 35%, ваша рашэнне па архітэктуры пацверджана данымі.
Практычны прыклад: сцэнар аналізу логаў за 30 дзён
Уявім тэхналагічны блог, дзе прааналізавалі access-лог за 30 дзён. Сярод 320 000 запытаў было выяўлена 48 000 запытаў ад пошукавых ботаў. Googlebot зрабіў 39 500 запытаў, Bingbot — 5 200, іншыя боты — 3 300. Размеркаванне кодаў стану: 200 — 78%, 301 — 11%, 404 — 7%, 5xx — 1,5%, астатнія — 2,5%.
Пры групаванні URL высветлілася, што 28% запытаў Googlebot ішло на старонкі тэгаў, 22% — на старыя архівы, 19% — на артыкулы блога, 8% — на катэгорыі, астатняе — на выявы і статыку. У той час як мэтай арганічнага трафіку былі актуальныя кіраўніцтвы і кластары катэгорый. У якасці дзеянняў нізкаякасныя тэгі былі закрытыя ад індэксацыі праз noindex, унутраныя спасылкі на архівы паменшаныя, актуальныя кіраўніцтвы атрымалі спасылкі з галоўнай і катэгорый, а карта сайта спрошчана і змяшчае толькі патрэбныя URL.
За наступныя 30 дзён доля запытаў Googlebot да артыкулаў вырасла з 19% да 34%, да катэгорый — з 8% да 14%. Дзякуючы наладцы перанакіраванняў доля 404 знізілася з 7% да 2,1%. Гэты прыклад паказвае, што аналіз логаў — не проста тэхнічная справаздача, а механізм прыняцця рашэнняў, які непасрэдна падтрымлівае стратэгію арганічнага росту.
Тыповыя памылкі
Самая распаўсюджаная памылка — сляпы давер да user-agent. Калі не ўлічваць падробных ботаў, справаздачы будуць хлусіць. Другая памылка — лічыць усе URL аднолькава каштоўнымі. Рэдкае сканіраванне старонкі палітыкі прыватнасці і рэдкае сканіраванне галоўнай катэгорыі — зусім розныя па наступствах сітуацыі. Трэцяя памылка — рабіць вялікія высновы на аснове аднаго дня. Паводзіны ботаў змяняюцца, таму выбірайце рэпрэзентатыўныя перыяды.
Чацвёртая памылка — меркаванне, што robots.txt вырашае ўсе праблемы. Ён абмяжоўвае сканіраванне, але не заўсёды дастатковы для кіравання індэксацыяй. Пятая памылка — не ператвараць знаходкі ў дзеянні. Калі пасля аналізу логаў не прымаюцца рашэнні па перанакіраваннях, пералінкоўцы, карце сайта, canonical, прадукцыйнасці і бяспецы, справаздача застаецца проста праглядам файла.
На што звярнуць увагу з пункту гледжання бяспекі і прыватнасці
Лог-файлы змяшчаюць IP-адрасы і інфармацыю аб запытах, таму захоўваць іх трэба асцярожна. Нельга перадаваць іх неўпаўнаважаным асобам. Спампаваныя для аналізу файлы не варта захоўваць на лакальных кампутарах даўжэй, чым трэба, і пажадана маскіраваць даныя. У карпаратыўных праектах тэрмін захоўвання логаў павінен адпавядаць палітыкам канфідэнцыяльнасці. Акрамя таго, калі ў логах бачныя токены, параметры сесій або канфідэнцыйныя радкі запытаў, варта перагледзець палітыку лагіравання на ўзроўні прыкладання.
З пункту гледжання бяспекі логі каштоўныя не толькі для SEO, але і для выяўлення нападаў. Рэзкі рост колькасці спроб з 404-й памылкай, сканіраванне адмін-панэлі, незвычайныя POST-запыты або інтэнсіўны трафік з пэўных IP-блокаў могуць быць сігналам трывогі. Таму SEO-спецыялістам і сістэмным адміністратарам карысна аналізаваць логі сумесна.
Выснова: аналіз логаў — гэта пласт рэальных даных у SEO
Аналіз серверных лог-файлаў для адсочвання пошукавых ботаў памяншае колькасць рашэнняў, заснаваных на здагадках, і робіць бачнымі рэальныя паводзіны краўлера. Дзякуючы логам вы можаце вымераць, якія URL лічацца каштоўнымі, якія памылкі стомліваюць ботаў, калі серверу цяжка і дзе марнуецца краўлінгавы бюджэт. Рэгулярны аналіз — гэта карысная звычка, якая дапамагае падтрымліваць якасць індэксацыі і арганічную бачнасць, асабліва для сайтаў, якія растуць.
Для хуткага старту спампуйце свой access-лог за апошнія 14 дзён, адфільтруйце сапраўдныя запыты Googlebot і зрабіце выбарку па кодах стану і групах URL. Калі вашы знаходкі паказваюць на праблемы з прадукцыйнасцю, бяспекай або недахоп рэсурсаў, перагляд інфраструктуры будзе добрым крокам. З рашэннямі Hostragons для хостінгу, VPS, воблачных сервераў, даменаў і SSL вы можаце ўмацаваць тэхнічны падмурак вашага сайта і ўкараняць паляпшэнні па выніках аналізу логаў у больш здаровым асяроддзі.
Частыя пытанні
Чым серверны лог-файл для SEO адрозніваецца ад Google Search Console?
Google Search Console паказвае абагульненыя даныя, арыентаваныя на Google, у той час як серверны лог-файл фіксуе рэальныя запыты да сервера на ўзроўні URL, часу, IP, user-agent і коду стану. Таму аналіз логаў — гэта больш неапрацаваная, дэталёвая і правяральная крыніца інфармацыі.
Колькі дзён даных дастаткова для аналізу логаў?
Для большасці сайтаў 14-30 дзён — гэта добры старт. Для навінавых або вельмі часта абнаўляльных праектаў аналіз за 3-7 дзён таксама можа быць паказальным. Сайтам з сезонным трафікам варта дадаткова аналізаваць перыяды акцый.
Як зразумець, сапраўдны Googlebot ці не?
Не давярайце толькі user-agent. Выканайце зваротны DNS-пошук для IP-адраса, пераканайцеся, што атрыманае імя заканчваецца на googlebot.com або google.com, і праверце, ці вядзе гэтае імя назад да таго ж IP. Калі ёсць супадзенне, бот, хутчэй за ўсё, сапраўдны.
Ці заўсёды памылкі 404 — гэта праблема для SEO?
Не кожная 404-я памылка з'яўляецца праблемай; для выдаленых або ніколі не існавалых старонак гэта нармальна. Але 404-я URL, на якія вядуць важныя ўнутраныя спасылкі, якія маюць знешнія бэклінкі або часта скануюцца Googlebot, могуць марнаваць краўлінгавы бюджэт. Для такіх URL варта разгледзець перанакіраванне або код 410.
Як часта трэба рабіць аналіз логаў?
Для невялікіх сайтаў дастаткова штомесячнага аналізу. Для буйных інтэрнэт-крамаў, навінавых парталаў і высоканагружаных праектаў рэкамендуецца штотыднёвае, а ў крытычныя перыяды — нават штодзённае адсочванне. Пасля пераносу сайта, змены інфраструктуры або буйных абнаўленняў кантэнту абавязкова правярайце логі.