Логовете са истината за поведението на бота

Суровите сървърни логове са единственият обективен източник, който показва как Googlebot реално взаимодейства със сайта ти в минута по минута детайл, без филтри и догадки. Те разкриват точния URL, timestamp, user-agent, реферер, статус код, байтове, латентност и IP, което ти позволява да видиш истинската картина: кои шаблони ботът предпочита, къде губи време, как реагира на натоварване, как се променя поведението му след релийз, CDN промяна или нови правила за редирект.

В логовете ще видиш и „скритите“ ефекти, които инструментите често пропускат: как Core Web Vitals и особено бавният TTFB/INP корелират с по-рядък crawl; как „меки 404“ (страници, връщащи 200 с празно или грешно съдържание) изяждат бюджет; как тънките серии и безкрайни параметри разпъват обхождането в безсмислени клонове.

За да използваш тези данни на максимум, изгради устойчив pipeline: централизирано събиране от уеб сървъра и от edge/CDN, унифициран формат (например JSON със задължителни полета path, query, ua, ip, status, bytes, ttfb, method), ретеншън поне 90 дни, и индексиране в система, където можеш да пишеш заявки по време, път, параметри и шаблон.

Обогати всеки запис с „етикети“ на приложение ниво като тип страница (начало, категория, продукт, статия, търсене), клик-дълбочина, присъствие в sitemap, наличие на canonical и hreflang, и информация за това дали URL-ът е индексиран според последния GSC export, защото бизнес контекстът превръща логовете от редове текст в карта на приоритетите.

Когато имаш такава карта, можеш да измериш реалното time-to-first-crawl за нов продукт, да валидираш дали RSS ping-овете и линковете от хъбове ускоряват откриването, да намериш страници, които ботът посещава необяснимо често без промяна в съдържанието, и да видиш секции, които стоят „студени“ седмици наред. Това е фундаментът за всяко решение по оптимизация: първо установяваш фактите от логовете, после преразпределяш сигнали, пренаписваш вътрешни линкове, чистиш параметри и каноникали, и накрая потвърждаваш ефекта отново в логовете чрез контролно измерване „преди/след“ по ясни KPI (уникални URL-и, дял 2xx, средна дълбочина, hits към money шаблони, time-to-index).

Нормализирай и валидирай бот трафика

Преди да тълкуваш която и да е метрика, трябва да изчистиш шума и да докажеш, че „Googlebot“ е наистина Googlebot. Това започва с двойна валидация: reverse DNS проверка на IP-то до *.googlebot.com и forward проверка обратно към същия IP, плюс съпоставка с публикуваните ASN/диапазони; всичко, което не минава, се маркира като „fake bot“ и излиза от анализа.

Успоредно нормализирай user-agent низовете, защото дребни вариации и суфикси могат да раздробят статистиката между Googlebot-Smartphone и Googlebot-Desktop; разделяй ги, за да видиш дали мобилният бот се държи различно по дълбочина и скорост.

След това нормализирай самите URL-и, за да не броиш едно и също съдържание като множество „уникати“: разбий адреса на път и параметри, сортирай параметрите по азбучен ред, конвертирай регистъра, декодирай енкоднати символи, премахни празни и дефолтни стойности, и унифицирай trailing slash. Така ?size=m&color=red и ?color=red&size=m стават един екземпляр, а utm, gclid, fbclid, mc_cid, sessionid, debug и подобни се класифицират като „технически“ и се изолират от фасетите, пагинацията и търсенето.

Добави и слой „шаблонна“ класификация на ниво приложение: регулярни изрази или маршрутизатор, който етикетира /category/..., /product/..., /blog/..., /search?..., за да можеш да анализираш по бизнес тип, а не само по низове. Маркирай допълнително каноничност (канон срещу параметричен вариант), присъствие в sitemap и вътрешна клик-дълбочина, за да откроиш случаи, в които ботът харчи бюджет в неканонични, несайтово рекламирани клонове.

Важна е и хигиената по филтриране: премахни вътрешни мониторинги, synthetic tests, headless проверки на QA екипи и CDN health-checks, защото те изкривяват latency и hit-rate графиките.

С такъв „почистен“ dataset ще видиш истински аномалии: внезапен скок на hits към /search? без органични входове, пълзящо нарастване на циклични 3xx между параметри и канон, превес на мобилния бот в дълбочина, което подсказва проблеми в десктопната навигация, или обратното.

Накрая автоматизирай нормализацията и валидацията като ежедневна задача, за да имаш сравними седмични/месечни серии и да хващаш отклонения рано; едва тогава картографирай честота по дълбочина и статус кодове, ловѝ 3xx/404 „черни дупки“ и преразпределяй вътрешни сигнали с увереност, че решенията ти стъпват на чиста, достоверна основа.

Картирай честота по дълбочина, шаблон и статус код

Започни с дефиниция на клик-дълбочина за всеки URL: 0 за началната, 1 за хъбове/главни категории, 2–3 за подкатегории и листинги, по-дълбоко за продукти, статии и помощни страници. Присвой тази мета-информация на базата от логове, за да можеш да групираш bot hits по дълбочина и да видиш къде точно „потъва“ обхождането. Здравословният профил показва висок относителен дял на hits в дълбочини 0–3 (начало, хъбове, ранни страници на серията) и контролирано присъствие по-надолу, където е дългата опашка. Ако голяма част от обхождането е „заклещено“ в дълбочина 4+, това почти винаги е сигнал за преразход върху пагинации, филтри и технически страници.

Класифицирай URL-ите и по шаблон (homepage, category, pagination, product, article, search/results, tag, author, media, feed). Така ще различиш бизнес-критичните зони (money страници, категории, продуктови детайли) от обслужващи/нискостойностни (търсене, тагове, архиви). Наложи матрица „шаблон × статус код“ и наблюдавай съотношението 2xx/3xx/4xx/5xx по всяка клетка. Висок дял на 3xx при продукти подсказва шумни пренасочвания (варианти, UTM, нормализация), висок 4xx при pagination намеква за „мъртви“ страници (page/99), а 5xx пики в категории говорят за бавни заявки/таймаути, които убиват crawl rate.

Раздели данните и по време: дневни/часови серии, за да уловиш сезонност и ефект от релийзи. Ако след публикация на много продукти ботът не увеличава hits в категории и page/2–4, архитектурата не подава достатъчно сигнали (слаб вътрешен линк, липсва lastmod, бедни sitemaps). Използвай дженерални KPI: hit-rate към „ядрото“ (homepage + хъбове + page/2–4) като дял от всички hits; median crawl depth; median TTFB за Googlebot; share на 2xx по ключови шаблони; и „time-to-first-crawl“ за нов URL според timestamp от CMS/фийд срещу първия лог хит. Когато тези KPI са изкарани на табло, всяка промяна (нови каноникали, чистене на параметри, вътрешно линкване) трябва да се отразява като видим, устойчив ефект—иначе връщаш промяната за доработка.

Не забравяй да кръстосаш логовете с GSC (Crawl stats/Index coverage). Ако логовете показват стабилни hits към серия от URL-и, а в Index coverage те висят като „Discovered – currently not indexed“, имаш тънко съдържание или дубликати, които трябва да се консолидират. Обратно, ако GSC отчита чести посещения, а в логовете няма такива, вероятно филтрираш прекалено агресивно IP/UA или пропускаш edge/CDN логове—поправи извора, преди да правиш заключения.

Лови цикли и грешки, които „поглъщат“ бюджет

Построй детектор за проблемни вериги на база последователни 3xx отговори за един и същ първоначален URL в кратък времеви прозорец. Типични патърни са: параметър → канон → с кос наклон → без кос наклон → trailing slash нормализация; http → https → www/non-www → канон; сортировка/фасет → канон → пагинация → обратно към канон. Всяка допълнителна стъпка е излишна латентност и планомерно източване на crawl бюджет. Нормализирай на edge ниво така, че да има един-единствен 301 хоп до крайния канон.

Сканирай за „меко 404“—страници, които връщат 200, но съдържателно са грешка („Няма резултати“, празни категории, грешен продукт). В логовете те изглеждат като често обхождани URL-и без органични входове и с висока степен на повторяемост. Превърни ги в истински 404/410, или ги пренасочи към най-близкия релевантен канон. За „твърдо 404/410“ наблюдавай пикове по шаблон: ако pagination генерира 404 за дълбоки страници, сложи горна граница и лениво „last page“ логика; ако продуктите масово стават 404, внедри политики за редирект към най-новата версия/категория или към родителската категория, за да не губиш сигнал.

Следи 5xx по време и по път. Дори кратки пикове (деплой, миграция, изгорял кеш) могат да накарат Google да намали темпото за дни. В лог таблото тригърни аларми при 5xx > X% за Y минути по даден шаблон. Ремедии: кеширане на страници с висока честота на обхождане (начало, хъбове, page/2–4), оптимизация на заявки (индекси в БД, N+1 фиксове), защита от „горещи“ параметърни клъстери (rate-limit/normalization).

Извади „реферери“ за 404 и 3xx вериги—така ще видиш от кои вътрешни шаблони и външни домейни идват лоши линкове. Поправи източника, не само симптома. Ако 404 идват от sitemap, имаш процесен проблем: невалидни/стари URL-и влизат в картата. Ако идват от филтърни чипове, UI генерира crawlable шум—смени ги с контролирани форми/JS без нови адреси или пренасочи към канона с чисти параметри.

Накрая измери ефекта „преди/след“ със същите метрики: брой 3xx хопове средно на сесия за бот; дял на 404/410/5xx; median TTFB за Googlebot; time-to-index за нови URL-и; и дела на hits към ядрените секции. Видиш ли свиване на веригите до един 301, спад на грешките и ръст на 2xx при ключови шаблони, значи реално си освободил crawl бюджет и си го пренасочил към страниците, които печелят трафик.

Намалявай нискостойностните и дублиращи серии

Голяма част от разхищението на crawl бюджет идва не от липса на съдържание, а от прекомерна репликация на едно и също съдържание в различни параметрични комбинации. Логовете ясно показват къде се случва това: хиляди заявки към страници, които реално връщат идентични резултати – примерно сортиране по цена, име, наличност или фасетни комбинации, които променят само реда, но не и съдържанието. Тези дублиращи серии „надуват“ графа и създават изкуствени клъстери, в които ботът обикаля без да открива нищо ново.

Първата стъпка е картографиране: извлечи от логовете кои параметри имат най-голям дял от обхожданията. Обикновено това са sort, order, view, session, filter и собствени ключове, добавени от CMS или JS функционалности. След като имаш картата, класифицирай параметрите на „без стойност“ (utm, session, debug), „вариации без съдържателна промяна“ (sort, order), и „фасети с потенциал“ (color=red, size=38). За първите приложи 301 към канона или изцяло ги изрежи чрез пренаписване на URL на edge ниво. За вторите – каноникализация и изчистване от вътрешни линкове, за да не се разпиляват сигнали. За фасетите – изграждане на whitelist от комбинации с реално търсене, всички други автоматично да се маркират с noindex,follow.

Дублиращите серии трябва да се държат в изолация и да не се включват в sitemap, защото това праща грешен сигнал на Google. Вътрешното линкване е критично – ако навигациите, breadcrumbs или UI чипове сочат към параметризирани URL-и без стойност, сигналите се губят. Вместо това те трябва да водят към чистите канонични версии. При по-сложни сайтове добър подход е да изградите middleware, което да пренаписва параметри и да връща само „санитизирани“ адреси навън.

Когато премахнеш излишъка, наблюдавай KPI: спад на броя уникални URL-и в логовете, ръст на честотата на обхождане на базови маршрути, скъсяване на time-to-index за нови продукти. Това доказва, че бюджетът вече се харчи там, където има бизнес стойност, а не в шумни и безкрайни серии.

Насочи сигналите към „money“ страниците и ускори откриването

След като си изчистил шума, идва най-важното – как да пренасочиш освободения бюджет към страниците, които реално носят приходи или трафик. Това са така наречените „money“ страници – начална, основни категории, подкатегории с висок обем търсене, продуктови детайли с висока конверсия и ключови статии, които носят линкове и органични входове.

В логовете често ще видиш, че именно тези страници имат парадоксално нисък hit-rate. Причината е, че архитектурата не ги приоритизира достатъчно: sitemap е беден, вътрешното линкване е плитко, хъбовете сочат прекалено дълбоко или UI компонентите пращат сигнали към второстепенни параметрични версии. Решението е целенасочена оптимизация на сигналите.

Започни със sitemap: увери се, че всички ключови страници са в XML картата с актуален lastmod и правилна приоритизация. Добави отделен sitemap за ново съдържание, за да сигнализираш бързо на Google. Използвай също и HTML sitemap или добре структурирани навигации, които държат money страниците на клик-дълбочина ≤2.

След това подсили вътрешното линкване. Използвай хъб страници (категории, блог постове, лендинги) като „рампa“ за money URL-и – добави линкове в текста, препоръчани продукти, модули „най-продавани/най-нови“. Увери се, че линковете са в HTML, видими без JS и с anchor текст, който подсказва семантика.

За ускоряване на откриването на ново съдържание използвай RSS ping, push към Search Console Indexing API (за критични URL-и), и свежи линкове от начална или хъб страници. В логовете трябва да видиш, че новите продукти получават първо crawl посещение значително по-бързо (вместо дни – часове).

Следи KPI: ръст на hit-rate към money шаблоните, спад на дяла на параметрични/нискостойностни URL-и, скъсяване на time-to-first-crawl и ускоряване на индексацията. Ако тези показатели вървят в правилната посока, значи бюджетът се инвестира там, където носи най-голяма възвръщаемост.

Мери before/after и автоматизирай наблюдението

Всяка промяна в crawl стратегията е безсмислена, ако не бъде измерена с ясни показатели „преди и след“. Логовете позволяват този тип валидиране, защото можеш да сравниш периоди (например 30 дни преди и 30 дни след внедряване на нови правила). Започни с най-основните KPI: брой уникални URL-и, които ботът е обходил; средна и медианна crawl дълбочина; дял на 2xx отговори спрямо 3xx, 4xx и 5xx; честота на посещение на money страници; време до първо посещение на нови URL-и; и общото натоварване (hits/ден). Ако след промяната броят уникални URL-и спада, дялът на 2xx расте, а time-to-first-crawl за ново съдържание се скъсява, значи оптимизацията е успешна.

Друго важно измерване е по шаблони. Извади статистики за homepage, категории, продукти, статии, пагинации, търсене и филтрирани комбинации. Целта е да видиш, че посещенията се преразпределят от нискостойностните серии към бизнес-критичните секции. Ако това не се случва, значи вътрешното линкване или sitemap все още не подава достатъчно сигнали и трябва донастройка.

Следващата стъпка е автоматизация. Никой SEO или DevOps екип не може ръчно да следи милиони редове логове всяка седмица. Изгради pipeline, който ежедневно събира логове, нормализира ги, класифицира по шаблони и параметри, и обновява табла с метрики. Настрой аларми: скок на 4xx/5xx над определен праг, внезапно падане на Googlebot hits към ключови секции, неочакван ръст на crawl в „шумни“ зони като вътрешно търсене или фасети. Такива аларми трябва да стигат автоматично до Slack/Teams или имейл, за да може екипът да реагира веднага.

Кръстосай данните от логовете с Google Search Console (Crawl Stats и Index Coverage). Ако виждаш в логовете по-добро обхождане, но в GSC няма ръст на индексирани URL-и, значи имаш проблем със съдържанието или каноникалите. Обратно – ако GSC показва много URL-и като „Discovered – currently not indexed“, а в логовете няма достатъчно hits, вероятно сигналите към бота са слаби.

Дългосрочната цел е процес, който работи като мониторинг система: логовете не са просто исторически отчет, а жив инструмент за управление на crawl бюджета. С автоматизирани отчети и аларми знаеш в реално време дали Googlebot харчи ресурси там, където трябва, и можеш да коригираш курса преди проблемите да доведат до загуби в органичния трафик.

FAQ и полезни съвети

В: Колко често да анализирам логовете?
О: За големи сайтове – ежедневно с автоматизирани табла и аларми, плюс седмичен дийпдайв. За средни – седмично. За малки – месечно или след големи релийзи/миграции.

В: Кои са задължителните KPI за „преди/след“?
О: Уникални URL-и, дял 2xx срещу 3xx/4xx/5xx, median/avg crawl depth, Googlebot hits към money шаблони, time-to-first-crawl и time-to-index за нови URL-и.

В: Как да валидирам, че „Googlebot“ е истински?
О: Reverse DNS → *.googlebot.com → forward обратно към IP + сравнение с публикувани ASN/диапазони. Всичко останало – „fake bot“ и извън анализа.

В: Как да третирам параметрите, които раздуват логовете?
О: Нормализирай (сортирай ключове, махни празни/дефолтни), 301 към канона при еквивалентност, noindex,follow за нискостойностни фасети, премахни вътрешни линкове към безполезни комбинации.

В: Robots.txt или noindex,follow?
О: Noindex,follow за страници, през които ботът трябва да мине и да предаде стойност. Robots.txt – за машинни „кладенци“ (search/debug), но не решава консолидацията на сигнали.

В: Как да ускоря откриването на ново съдържание?
О: Вътрешни линкове от хъбове/начална, свеж lastmod в sitemap, RSS ping, (където е приложимо) Indexing API за критични URL-и, и стабилна SSR пагинация към page/2–4.

В: Кои грешки най-много „поглъщат“ бюджет?
О: Циклични 3xx (многостъпални нормализации), „меки“ 404 (200 с празно съдържание), масови 404 в дълбоки пагинации, кратки, но чести 5xx пикове.

В: Как да разбера дали sitemap ми помага?
О: Кросчек: URL в sitemap трябва да има растящ hit-rate и по-кратък time-to-first-crawl. Ако не – картата е бедна/остаряла или сигналите (вътрешни линкове) са слаби.

В: Да включвам ли параметрични URL-и в sitemap?
О: По подразбиране – не. Изключение: малък whitelist от фасетни лендинги с доказано търсене и уникално интро съдържание.

В: Какво да правя при продукто-редиректи и изчерпани артикули?
О: Едностъпален 301 към най-близкия релевантен канон (нов модел/категория), 410 за окончателно премахнати без заместител, и чистене на вътрешни линкове към старите URL.

Съвет: Автоматизирай целия pipeline – събиране → нормализация → класификация → табло → аларми – и дръж „златните“ метрики видими: hits към ядро (homepage/хъбове/page 2–4), time-to-first-crawl и дял 2xx. Ако някоя от тях тръгне надолу, реагирай преди да падне органичният трафик.