Защо сървърните логове са важни за SEO

Анализът на сървърните логове може да предостави несравнима информация за приоритизирането на съдържанието, което позволява на оптимизаторите да оптимизират краулинг бюджета за по-добро класиране. Повечето уебмастъри не осъзнават значението на логовете на уеб сървърите, като рядко ги анализират. Особено големите брандове не успяват да се възползват от анализа на сървърните логове и безвъзвратно губят незаписани данни от тях. Организациите, които избират да използват анализ на сървърните логове като част от постоянните си усилия за SEO оптимизация, често успяват при търсенето в Google. Ако сайтът ви се състои от 100 000 или повече страници и искате да научите как и защо сървърните логове предлагат огромна възможност за растеж, прочетете тази статия.

Всеки път, когато ботът търси URL адрес, хостван на сървъра, автоматично се създава запис в дневника, отразяващ обменената в процеса информация. Когато обхващат дълъг период от време, сървърните логове стават важни източници за историята на получените заявки и върнатите отговори. Информацията, която се съхранява в регистрационните файлове на сървъра, обикновено включва IP адреса, датата и часа на заявката, заявения URL адрес на страницата, кода на HTTP отговора, количеството обработени байтове, както и агента на потребителя и препращащото устройство. Въпреки, че сървърни логове се създават при всяко поискване на уеб страница, включително заявки от браузъра на потребителя, оптимизацията за търсачки се фокусира единствено върху използването на данните от сървърните логове на бота. Това е от значение за правните съображения, свързани със системите за защита на данните, като GDPR/CCPA/DSGVO. Тъй като никога не се включват данни за потребителя за целите на SEO, необработеният, анонимен анализ на логовете на уеб сървъра остава свободен от други потенциално приложими правни разпоредби. До известна степен подобни заключения са възможни въз основа на статистиката за сканиране в Google Search Console. Там обаче данните са ограничени по обхват и времеви интервал.

Ценни данни в дневниците на сървъра

Всеки път, когато бот поиска страница, разположена на сървъра, се създава запис в дневника, която записва редица данни, включително:

• IP адресът на клиента, който подава заявка
• Точният час на заявката, често базиран на вътрешния часовник на сървъра
• URL адресът, който е бил поискан
• За заявката е използван HTTP
• Върнатият код на състоянието на отговора (напр. 200, 301, 404, 500 или друг)
• Реда на потребителския агент от структурата, която подава заявката (напр. име на бот на търсачка, напр. Googlebot/2.1)

Типичен примерен запис в дневника на сървъра може да изглежда по следния начин:

В този пример:

• 150.174.193.196 е IP адресът на заявяващия обект
• [15/Dec/2021:11:25:14 +0100] е часовата зона и часът на заявката
• “GET /index.html HTTP/1.0″ е използваният HTTP метод (GET), исканият файл (index.html) и използваната версия на HTTP протокола
• 200 е кодът на състоянието на HTTP, върнат от сървъра
• 1050 е размерът на отговора на сървъра в байтове
• “Googlebot/2.1 (+http://www.google.com/bot.html)” е потребителският агент на подателя на заявката
• “www.example.ai” е URL адресът на връзката

Как да използвате сървърните логове?

От гледна точка на SEO оптимизацията има три основни причини, поради които логовете предоставят отлична информация:

1. Помагат за филтриране на нежелания SEO трафик от ирелевантни ботове от желания трафик от ботове на търсачки, идващи от легитимни ботове, като Googlebot, Bingbot или YandexBot. Предоставяне на информация за SEO относно приоритетите на обхождане и по този начин даване на възможност на SEO екипа да определи и коригира предварително управлението на бюджета си за обхождане
2. Позволява наблюдение и предоставяне на запис на отговорите на сървъра, изпратени до търсачките
3. Фалшивите ботове на търсачките могат да бъдат досадни. Съществуват редица специализирани доставчици на услуги, като Cloudflare и AWS Shield, които могат да помогнат за управлението на нежелания бот трафик. Фалшивите ботове обикновено играят второстепенна роля при анализа на дневниците на уеб сървърите

За да се определи с точност кои части на уебсайта са с приоритет, различен от този на основните търсачки, при анализа на логовете трябва да се филтрира трафикът от ботове. В зависимост от целевите пазари фокусът може да бъде върху ботовете на търсачките като Google, Apple, Bing, Yandex или други. Особено за уебсайтове, при които релевантността на съдържанието е ключов фактор, честотата на повторно сканиране на тези сайтове може да окаже критично влияние върху полезността им за потребителите.

С други думи, ако промените в съдържанието не се възприемат достатъчно бързо, сигналите за взаимодействие с потребителите и класирането при органично търсене вероятно няма да достигнат пълния си потенциал. Въпреки че Google се стреми да претърсва цялата налична информация и редовно претърсва URL адреси, които вече познава, ресурсите му за претърсване не са безкрайни. Ето защо при големи уебсайтове със стотици хиляди целеви страници, циклите на повторно обхождане зависят от алгоритмите на Google за определяне на приоритетите на обхождане. Това разпределение може да бъде стимулирано положително от надеждни уеб услуги, оптимизирани специално за бърза работа.

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

Освен това анализът на логовете предлага важна информация за SEO за големи уебсайтове. Той може да отговори на въпроса колко време е необходимо на Google да сканира отново целия уебсайт. Ако този отговор се окаже твърде дълъг – месеци или повече – може да са необходими действия, за да се гарантира, че индексираните целеви страници за SEO са сканирани. В противен случай има голям риск всички подобрения в SEO оптимизацията на уебсайта да останат незабелязани от търсачките месеци след пускането му, което от своя страна е рецепта за ниски позиции. Отговорите на сървъра са от решаващо значение за добрата видимост в търсенето в Google. Въпреки че Google Search Console предлага важна информация за последните отговори на сървъра, всички данни, които Google Search Console предлага, трябва да се разглеждат като представителна, но ограничена извадка. Въпреки че може да бъде полезен за идентифициране на сериозни проблеми, анализът на сървърните логове може да се използва за анализиране и идентифициране на всички HTTP отговори, включително всички количествено значими отговори, различни от 200 OK, които могат да застрашат класирането. Възможните алтернативни отговори могат да показват проблеми с производителността (напр. 503 Услугата е недостъпна, планиран престой), ако са прекомерни.

Откъде да започнем?

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

• отдалеченият IP адрес на структурата, която подава заявка
• низ на потребителския агент на заявяващия обект
• схема на заявката (например дали HTTP заявката е била за http или https, или нещо друго)
• име на хоста на заявката (например за кой поддомейн или домейн е била HTTP заявката)
• път на заявката, често пътят до файл на сървъра като относителен URL адрес
• параметри на заявката, които могат да бъдат част от пътя на заявката
• часът на заявката, включително дата, час и часова зона
• метод на заявка
• код на състоянието на отговора на http
• време за реакция

Ако пътят на заявката е относителен URL адрес, полетата, които често се пренебрегват в регистрационните файлове на сървъра, са името на хоста и записът на схемата на заявката. Ето защо е важно да проверите с ИТ отдела си дали пътят на заявката е относителен URL адрес, така че името на хоста и схемата също да бъдат записани в регистрационните файлове на сървъра. Прост начин за заобикаляне на проблема е да запишете целия URL адрес на заявката като едно поле, което включва схемата, името на хоста, пътя и параметрите на един ред. При събирането на регистрационни файлове на сървъра е важно да се включат и регистрационните файлове, произхождащи от CDN и други услуги на трети страни, които уебсайтът може да използва. Проверявайте редовно тези услуги на трети страни, за да разберете как да извличате и запазвате регистрационните файлове.

Преодоляване на пречките пред анализа на сървърните логове

Често има две основни пречки пред преодоляването на спешната нужда от запазване на данните от дневника на сървъра: разходи и правни въпроси. Въпреки, че и двете в крайна сметка се определят от индивидуални обстоятелства, като например бюджет и юрисдикция, нито едно от тях не трябва да представлява сериозна пречка. Съхранението в облак може да бъде дългосрочен вариант, а съхранението на физически хардуер вероятно също ще ограничи разходите. При цени на дребно на твърди дискове с капацитет около 20 TB под 600 USD разходите за хардуер са незначителни. Като се има предвид, че цените на хардуера за съхранение падат от години, разходите за съхранение едва ли ще се превърнат в сериозен проблем за регистрирането на сървъри.

Съществуват и разходи, свързани със софтуера за анализ на логове или с доставчика на услуги за SEO одит, който предоставя услугата. Ние лично ползваме Screaming Frog SEO Log File Analyser. Въпреки че тези разходи трябва да бъдат включени в бюджета, те отново са лесно оправдани с оглед на ползите, които предлага анализът на сървърните логове. Макар тази статия да има за цел да опише присъщите ползи от анализа на сървърните логове за SEO, тя не трябва да се разглежда като правен съвет. Такъв правен съвет може да бъде предоставен само от квалифициран юрист в контекста на правната рамка и съответната юрисдикция. В този контекст могат да се прилагат редица закони и разпоредби като GDPR/CCPA/DSGVO. Конфиденциалността е сериозен въпрос, особено когато се работи в ЕС. Въпреки това за целите на анализа на сървърните логове за целите на SEO, всички потребителски данни са без значение. Всички записи, които не могат да бъдат окончателно проверени въз основа на IP адреса, трябва да бъдат игнорирани. Що се отнася до съображенията за поверителност, всички лог данни, които не са потвърдени от бот на търсачка, не трябва да се използват и могат да бъдат изтрити или анонимизирани след определен период от време, въз основа на съответните правни насоки. Този доказан подход се използва редовно от някои от най-големите оператори на уебсайтове.

Кога да започнете?

Основният въпрос е кога да започнете да събирате данни от дневника на сървъра. Отговорът е веднага! Данните от дневника на сървъра могат да се използват смислено и да се правят препоръки за действие само ако има достатъчно данни. Критичната маса на полезност на сървърните логове за SEO одити обикновено варира от 6 до 36 месеца, в зависимост от размера на уебсайта и приоритетните сигнали за обхождане.

Незаписаните сървърни логове не могат да бъдат получени на по-късен етап. Следователно събирането на данни от сървърните логове трябва да започне възможно най-рано и да продължи без прекъсване, докато уебсайтът работи и се стреми да се представя добре при нормални търсения^.

Източник: https://searchengineland.com/why-server-logs-matter-for-seo-378199