Краул бюджет: какво реално обхожда Google на сайта ви

Search Console показва какво Google е решил да покаже. Сървърните логове показват какво Google реално е направил — кога е дошъл, какво е поискал и какво е получил в отговор. Разликата между двете е мястото, където се крият най-скъпите проблеми.

Тази статия е за краул бюджета: колко внимание отделя Google на сайта ви, къде то изтича и как да го насочите. С реални числа от логовете на един български WordPress сайт, а не с теория.

01Какво е краул бюджет и кой има нужда да мисли за него

Краул бюджетът е грубо казано колко страници Google е готов да изтегли от сайта ви за даден период. Определя се от две неща: колко натоварване издържа сървърът ви и колко интересен смята съдържанието ви търсачката.

Второто е по-важното. Google не обхожда по-рядко, защото се притеснява за сървъра ви — обхожда по-рядко, защото при последните посещения не е намерил достатъчно, което да си струва.

Какво изглежда като проблем с бюджета, но не е

• Страница не е индексиранаОбикновено не е защото ботът не е стигнал до нея, а защото я е видял и е решил, че не си струва. Проверете съдържанието, не бюджета.
• Новите статии влизат бавноПри сайт с рядко обхождане това е нормално. Помага вътрешна връзка от често посещавана страница, не техническа настройка.
• Googlebot идва по-рядко от предиСимптом на понижен интерес след ъпдейт или спад в качеството. Лекува се със съдържание, не с robots.txt.

02Как да видите какво реално се случва

Има два източника и те казват различни неща. Нужни са и двата.

Къде са логовете

При споделен хостинг обикновено ги има в cPanel („Raw Access Logs“) или директно по SSH — при нас пътят е ~/access-logs/ за текущия ден и ~/logs/ за архивите по месеци. Файловете са текстови: един ред на заявка.

Важно: проверявайте автентичността. Всеки може да се представи за Googlebot. Истинският идва от диапазона 66.249.* и се потвърждава с обратна DNS справка. В нашите логове открихме 135 фалшиви заявки с Googlebot етикет от български доставчици — най-вероятно инструменти за проследяване на позиции.

03Реален случай: sitemap 404 в продължение на седмици

Ето какво намерихме в логовете на сайт, чиито позиции падаха от месеци, без видима причина.

Sitemap файловете връщаха 404 — не един ден, а през целия период от началото на юли до края на месеца. Googlebot ги беше поискал на 13 отделни дати и всеки път беше получил „няма такова нещо“. Bing беше опитал 74 пъти.

Причината се оказа банална: загубени правила за пренаписване на адресите след промяна по сайта. Поправката отне една команда. Но три седмици Google не беше получавал списъка със страниците — точно докато сайтът се нуждаеше от преоценка.

Иронията: в същия период sitemap файловете на една забравена тестова папка в същия сървър работеха и връщаха 200.

Какво още показаха логовете

04Къде изтича бюджетът в WordPress

• Изтрити или тестови поддиректорииСтар сайт, копие за разработка, папка от предишен изпълнител. Google продължава да ги чука с месеци. Ако не съществуват — връщайте 410 вместо 404: „изтрито завинаги“ се обработва по-бързо от „не е намерено“.
• Вериги от пренасочванияАдрес А води към Б, Б води към В. Всяка стъпка е отделна заявка. Сочете винаги към крайния адрес.
• Безкрайна пагинацияСтраници като /page/2/, /page/99/, които връщат 200 за всяко число. Проверете какво връща произволно голямо число — ако не е 404 или пренасочване, имате безкрайно пространство за обхождане.
• Филтри и параметри в магазинаWooCommerce с филтри по цвят, размер и цена генерира хиляди комбинации. Всяка е отделен адрес. Това е най-честата причина за реален проблем с бюджета.
• Архиви, които не носят стойностАрхиви по автор при един автор, по дата, по етикет с по една публикация. Всеки е страница, която трябва да бъде обходена.
• Фийдове и служебни адресиRSS фийдовете на всяка категория и публикация се обхождат. Малък разход, но безсмислен.

05Как да насочите вниманието натам, където има смисъл

1. Изчистете мъртвото

   Изтритите раздели връщат 410. Старите адреси с трафик — 301 към най-близкия жив еквивалент. Никакви пренасочвания „на сляпо“ към началната: това се разпознава като мек 404.

2. Оправете sitemap-а и го проверете като бот

   Отворете адреса му в браузър в анонимен режим. Ако не се зареди за вас, не се зарежда и за Google. Проверявайте го периодично, не еднократно.

3. Затворете безсмислените пространства

   Пагинация без край, филтри с параметри, архиви без стойност — с noindex или блокиране, според случая. Внимавайте: блокираното в robots.txt не се обхожда, но може да остане в индекса.

4. Свържете важното вътрешно

   Страница, до която води една връзка, се обхожда рядко. Тежестта тече по връзките — това е и най-прекият начин да ускорите преоценката ѝ.

5. Дръжте сървъра бърз

   Бавните отговори намаляват темпото на обхождане. Кеширането не е само за посетители.

6. Поискайте индексиране за ключовите страници

   След съществена промяна: Search Console → проверка на адрес → заявка за индексиране. Работи за единични страници, не за целия сайт.

→Изводът

Влязохме в логовете, за да преценим краул бюджета, и излязохме с два поправени дефекта, за които нищо друго не подсказваше. Това е и практическият извод: анализът на логовете е диагностика, не любопитство.

За повечето малки сайтове размерът на бюджета няма да е проблемът. Проблемът ще е, че Google идва рядко и когато дойде, попада на 404, на пренасочване или на файл, който не съществува. Тези три неща се оправят за един следобед.

Ако искате да проверим какво реално получава Googlebot на вашия сайт — логове, sitemap, отговори по адрес и дял успешни заявки — това е част от техническия одит. Как изглежда картината за AI ботовете сме описали в анализа на 39 654 записа от логовете.