Обратно към основите с Петър Николов

Тук правим обзор на уебинара “ Обратно към основите“,  проведен на 20.12.2019 г.  ние от Serpact разговаряме с Петър Николов от Mobilio Development.

Преминаваме към въпросите:

Никола Минков: Добре дошли на поредния SerpAsk уебинар. Искам първо да благодаря на целия екип на Serpact, на хората, които помагат за осъществяването на нашите уебинари. Днес малко по-рано, както знаете с Джон Мюлер и с Дидо Григоров проведохме един уебинар, а сега с нашия така добър приятел и колега, който ще представиме след малко – Петър Николов.
Аз съм Никола Минков, SEO на Serpact. Фокусът ми е в стратегии, в изграждане на стратегии и процеси съответно във всеки един SEO проект и фокусите около него…

Борислав Арапчев: Здравейте. Аз съм Борислав Арапчев, SEO стратег на Serpact. Имам над петнадесет години опит в SEO, като специализирам в изграждане на стратегии, Local SEO, брандинг и съдържание.
Днес нашият гост е Петър Николов. Няма човек в областта на дигиталния маркетинг в България, който да не го познава и да не е чувал за него, затова ще го представя само с две-три изречения преди да му дам думата.
Петър прави своите софтуерни разработки за неговата компания MobilioDevelopment. Първия си уеб сайт прави още в университета още през 1997 година и от тогава се занимава с интернет уеб сайтове и приложения. Сега в наши дни той смята, че принципа „По-малкото е повече“ трябва да бъде приложен и към текущото състояние на интернет и уеб сайтове.
Петьо е още и Google Product Expert Gold Level (Златно ниво) – за Webmasters в областта.
Петьо, здравей…

Петър Николов: Здравейте. Приятно ми е точно преди Коледа да направим едно бързо уебинарче…

Борислав Арапчев: Винаги първият ми въпрос е как стартира, как навлезе в дигиталния маркетинг, в направата на сайтове, в програмиране, оптимизация и т. н. … Разкажи ни, защото се оказва, че това начало е интересно винаги на всички.

Петър Николов: 🙂 … Ами, както знаете 1997 година беше доста тежка, тогава имаше една много люта зима, а цените скачаха на всеки час, да не кажа, че и на всяка минута… Бях студент втори курс, ако не се лъжа, беше зимната сесия. И тогава се прибрах вкъщи, за да пестя пари… Имах един старичък компютър – мисля, че беше с 4 или 8 мегабайта RAM, имах и Windows 95… Тогава тъкмо намерих един хубав HTML редактор, който се казваше HTML Edit и започнах да експериментирам… Между другото, интересен факт е, че след 4-5 години се запознах с автора на този HTML Edit… Та започнах с него (с този HTML Edit) да експериментирам… Тогава имаше уеб браузъри, но ние не знаехме как се коди, т.е. ние не знаехме самия HTML… И аз взех този HTML редактор – тогава той беше безплатен – и започнах да изследвам какво представлява самия HTML.
Безсмислено е да казвам, че тогава нямаше интернет в този вид, какъвто е сега. Тогава интернетът беше само в университета, беше мно-о-о-ого бавен и освен това мога да ви кажа, че половината български интернет минаваше през една сателитна чиния, която била вързана в БАН и която предаваше данни към техническия университет във Виена… Всъщност тази чиния се използваше за да се предават някакви данни за нашите малки атомни реактори, (ако не се лъжа, това са реактори от първи до четвърти)… Навремето дошли някакви хора, видели са, че няма интернет тези данни да се качат бързо до Виена – по-бързо било човек да се качи на самолет и с някакви CD-та или хард дискове да домъкне данните там… В резултат на което, някой извадил едни пари (такава е сега конспиративната теория …) и закачил тази чиния в БАН. И когато чинията не се използваше за предаване на данни за атомните реактори, почти цяла България използваше тази чиния за достъп до интернет.

Тогава интернетът беше много стар, много бавен, много „първичен“, много „нерафиниран“ и аз имах интернет с един килобайт в секунда, но не всяка секунда, в резултат на което се ние кликахме някъде и чакахме нещо от порядъка на 5-6, че даже и повече минути дадена страничка изобщо да зареди…

Та оттогава аз почнах да се занимавам с HTML, започнах да гледам какво е HTML, мислех си даже дипломната ми работа да бъде базирана на php (тогава имаше вече и домашен интернет с едни модеми), но в крайна сметка се отказах, защото мислех си, че няма да мога да намеря никаква информация за Php и за MySQL. За съжаление, буквално две седмици след като се отказах от тази дипломна работа, намерих тонове информация как се работи с php (тогава Php беше версия 3, а MySQL беше версия 1 или 2 – нещо от този сорт)… Значи говорим за 2000-та година, даже за 1999 година…

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

Днес повечето хора, които правят сайтове и се занимават с тях – или ги оптимизират, или правят маркетинг на тия сайтове и т. н., не познават основното, фундамента и в крайна сметка тръгват да градят нещо нагоре, но фундамента им е много кекав, много слаб… Като резултат в момента, когато нещо се случи, цялата тази къща от карти веднага се разпада…

Никола Минков: Петьо, чудесно представяне, благодаря ти. Аз имам един въпрос, свързан с това. От доста години те гледах по конференции в началото като прохождах и ти се възхищавах много. Не че сега не го правя, като правиш презентации… уважавам твоя труд и знания и се радвам, че има българин с такива знания…

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

Петър Николов: Точно така… ами аз имам няколко интересни продукта, за които установих, че в крайна сметка след като се пуснат, им трябва малко „пушване“ в интернет, за да могат съответно те да прогресират. И това ме заведе до SEO…

До този момент аз мразех SEO, аз и сега частично мразя SEO, защото това е един тип бизнес, при който също както някога в дивия Запад са вадели едни пищаци и са почвали да се гърмят – знаем, че в SEO-то се гърмят с линкове най-сетне. Та поради това до онзи момент аз съвсем мразех SEO… Обаче установих, че след като излязоха „панди“, „пингвини“ и т.н. ъпдейти всъщност SEO-то започна да става много сладко… До този момент, обаче, не знам дали помните, имаше случаи, когато даден човек правеше някакъв тъп сайт, но тъй като тъпия сайт има линк, примерно, от 2-3-4-5 хиляди домейна, така линкче във футъра небрежно и този сайт може да изглежда много грозно, той може да представя само една картинка вътре без абсолютно нищо, но този сайт се класира много интересно по много ключови думи…

Тогава на всички ни беше ясно, че този момент ще спре и този механизъм ще работи до един момент… В крайна сметка, когато това се случи, аз започнах по-активно да се занимавам с тези неща и да ги изследвам.
Това е първото…

Второто е, че много SEO-та не разбират как работят операционните системи, как работят сървърите, как работят много неща… Дори, между другото, голяма част от българските дижитъл маркетъри не знаят фундаментални неща – как работи HTML, как се прави код и много други неща… Част и от западните страдат от същия дефицит… Така установих, че има много голяма празнина между девелопмънт и SEO, която трябва някой да запълни. Но този някой или трябва да е девелопър, който мигрира към SEO, или трябва да е SEO, който мигрира към девелопър… И тъй като двете страни са също като двете страни на една монета, всяка от които не знае и не иска да знае какво прави другата – в крайна сметка тази празнина между тях аз по някакъв начин в момента я запълвам сравнително успешно…

Доста от западни SEO-та правят абсолютно същото, опитват се да говорят на девелопърите – на SEO език и обратно… Имал съм срещи там и със SEO-та, и с девелопъри – едните казват, трябва да направите туй, а другите – трябва вие да направите онуй… Примерно, девелопърите казват: ние туй нещо ще го направим за срок от два месеца… А аз просто се обръщам и казвам: искаш да ми кажеш, че сега тука за да ми добавиш едно бутонче и едно поленце на теб ще ти трябват цели два месеца за цялото туй нещо ли???

В резултат на което девелопърите започват да усещат, че те говорят с някого, който говори на техния език и започват: да бе, човек, ама сега тук базата данни и не знам какво си, и не знам що си… трябва да се оправи… После пък аз започвам да обяснявам на самите девелопъри какво всъщност искат SEO-тата и как това нещо ще им помогне… примерно, като им показвам в SERP как изглежда дадения резултат, защо трябва да има структурни данни… и тогава те казват: а-а-а-а, да бе, ние това нещо го знаем, то е интересно, но на нас това никой не ни го е обяснил така, защото SEO-тата говорят много сухарски: трябва да добавите структурни данни…, и за тях въпроса с това е приключен! Обаче какви структурни данни, как да се оптимизира в back end и т. н. – това за тях е нещо… сякаш някой им говори на марсиански…
В този смисъл аз, общо взето, запълвам тази дупка като превеждам на едните какво искат другите и съответно какви са им техническите проблеми в дадената ситуация. …

Борислав Арапчев: …да, това е много ценно, понеже тези проблеми възникват твърде често… Ние ги виждаме в нашата работа и ти ставаш един вид преводач между двете звена като обясняваш на всеки кой какво трябва да свърши…

Петър Николов: Не само преводач, Боре… Аз се занимавам така също така и с Linux от 1997 г., което лично на мен ми помага да направя някои неща сам… Вие много добре знаете, че когато се случи някакъв мега голям технически проблем, за да се реши проблема някой трябва съответно да звънне на някакъв админ, който ядосано ще му каже, че това нещо НЕ МОЖЕ ДА СТАНЕ!… Обаче ако му се възрази: „чакай сега, какво искаш да ми кажеш, – че тези файлове не могат да се прехвърлят в друг сървър ли?“… или, „че не може да ми се инсталира друга версия на уеб сървър???…“, или нещо подобно, примерно… Тогава той казва: „А-а-а, то това може да стане…“ И аз му казвам: „Ами да, в крайна сметка хората точно това решение искат от тебе…“ Като резултат разговорът пак се обръща, защото админът изведнъж разбира, че говори с някой, който има dev-ops skills или admin skills и тогава той казва вече: … да бе, това може да стане, ама не по този , а ето по този друг (втори, трети…) начин… и съответно започва да предлага разни неща за разрешаване на проблема…

Вие отлично знаете, че IT-тата са мега: „НЕ!!!“, „това нещо НЕ МОЖЕ да стане!“, „това нещо НЯМА КАК да стане така“, „това нещо НЕ МОЖЕ ДА СЕ НАПРАВИ СЕГА“, „може да стане ама чак след две години…“ и т.н. … Но когато пред тях изскочи някой и им каже: „добре, бе, защо да не може да стане…?“ и съответно те трябва да му приведат някакви доводи… като например – хардуерът е стар, код бейза ни е тъп… и т. н., а някой друг като мене им казва: „добре де, а не можем ли да направим един междинен бек енд, който да кешира информация от тези, да връща на онези…“ и т. н. … И тогава нещата започват да се случват… А дотогава всичко е „НЕ!, НЕ! и НЕ!!!“. Така че самата ми комбинация от skills общо взето ме спасява доста пъти и освен това ми позволява да избегна това „НЕ!, НЕ МОЖЕ ДА СТАНЕ!“ и т.н. …

Борислав Арапчев: Точно така… По този начин искам да прелея към нашите въпроси, по които сме планирали днес да говорим и е много хубаво, че ти имаш базата (основата), за което ни разказа, защото си тръгнал отдолу нагоре да градиш, да се учиш и да се развиваш, а това е много важно, тъй като си наясно със всичките програмирания, технологии и т. н. … по подобен начин съм се развивал и аз…, но… това е друга тема…

Никола Минков: …аз не… но само искам да добавя тук нещо, което е супер релевантно към това, което Петьо каза преди малко „Понякога това ми спасява кожата“… Припомням ти, Петьо, когато бяхме заедно в Цюрих скоро и ти участва в hangout-та на Google, което е супер!…, и всъщност на първия въпрос… нещо, което е типично за човек, който разбира и от програмиране и не е за типичен SEO специалист…

Петър Николов: … точно така…

Никола Минков: … в случая ти отговори много хубаво, защото аз изгледах уебинара… Ето, това е един пример, когато понякога за такива знания идва момента… те може да не са ти потрябвали и две години, но идва момент, в който ще ти потрябват.
Добре. Боби, нека да започваме с темите, защото Петьо има да разказва доста…

Борислав Арапчев: Петьо, като първо и най-важно, ние считаме, че основата на един сайт и на един онлайн бизнес в случая, се явява сървъра или хостинга… Какви са твоите препоръки и наблюдения, (тъй като имаме Shared хостинг, VPS или Dedicated и т.н. – ти какво би препоръчал от твоята практика. Как трябва да подходи един бизнес, когато иска да стартира своята дейност в интернет като начало?

Петър Николов: Основният фундамент, който пропускат хората е, че каквото и да направят, където и да си сложат нещата, те опират в крайна сметка до един сървър… и този сървър може да бъде shared хостинг, VPS или Dedicated хостинг… Но ние всички, в крайна сметка, говорим за пари и това най-напред трябва да изясним.
Shared хостингът струва няколко левчета месечно – това е най-простото и най-евтиното нещо… Но от друга страна, един сървър, който се използва за хостинг, много лесно може да стъпи на 10-15-20 хиляди лева…много лесно!!! Един системен администратор взема, например, по 50-100 лв. на час, а може да взема и повече…, и изниква фундаменталният въпрос – как един shared хостинга успява при всички тези разходи да струва само няколко левчета месечно? Отговорът е много прост…

Над целия този хостинг се закача не един клиент, а се закачат няколко десетки или няколко стотици клиенти…

Борислав Арапчев: … триста…, триста клиенти…

Петър Николов: … но може да са 1000, а може да са и повече…

В резултат на което, когато имаме един такъв сървър с много закачени клиенти, които плащат, тогава сметката излиза, защото може да се закупи един такъв сървър, може да се наеме един системен администратор да го менажира и цялото това нещо действа…

Тъй като ние имаме 300 или 1000 клиенти на един сървър, това обстоятелство води до някои известни ограничения. Първото известно ограничение е, че всеки един от клиентите не може да разполага с целия сървър и да се шири, както той си иска, защото сървъра има няколко ограничения… Първото ограничение е т.н. „процесорно натоварване“, т.е. хостинг компанията ни дава този сървър при условие, че ние използваме само 100 минути дневно. Второто ограничение е RAM паметта – всички тези сървъри имат 128 гигабайта RAM, може да бъдат с 256 RAM, но виждал съм и с 512 RAM памет. Обаче в даден момент един клиент може да използва максимум 1 или 2 гигабайта от паметта, но не и повече.
Третият проблем е така нареченото „дисково пространство“… Понеже модерните сървъри имат вързани терабайти дискове, ние не можем да използваме всичките тези терабайти, както си намерим за добре, на нас ни се дават 5-10-20 или 50 гигабайта и само толкова можем да използваме…

И последното натоварване, за което се сещам в момента, е честотната лента, която можем да използваме. В повечето хостинг компании това е ограничено, т.е. вие може да използвате 50-100 гигабайта месечно и това да е ограничението. При надхвърляне на този лимит, хостинг компанията съответно или ни моли да минем на по-горен пакет, или да минем на друг вид хостинг – VPS или Dedicated.

Shared хостингът, колкото и хората да го мразят, има едно много полезно нещо – той струва левчета, всеки може да си го позволи. И още – shared хостингът си има назначени администратори, които се грижат за тази машина, как работи това нещо и да не би някой да почне да прави някакви шмекерии… Ако нещо подобно се случи тогава тези системни администратори се намесват…

Shared хостингът може да е подходящ за сайтове, при които е възможно след необходимите инсталации, софтуери и т. н., той може да домъкне няколко хиляди клиенти дневно, ако имаме един CMS или няколко десетки до няколко стотици дневно, ако имаме е-commerce. Но ако това се надскочи, трябва да се мине на следващото ниво хостинг – така наречения VPS.

VPS-ът представлява следното: имаме един голям компютър, примерно, с 40 ядра, със 128 гигабайта RAM, с два терабайта диск и когато го използваме, ние трябва да го разделим по някакъв начин на всеки един клиент. Затова стартираме една виртуална машина, която заема, например, едно процесорно ядро, два гигабайта RAM и десет гигабайта дисково пространство. Всичко това се предоставя на един клиент като му се казва, че може да използва това нещо по този начин само дотам. Клиентът, когато го вземе, може да види, че е виртуализиран. (Между другото, има някои техники на виртуализация, но в момента няма да се спирам на това нещо, защото е прекалено техническо). Клиентът си използва процесорното ядро, използва си RAM-та и си използва диска…
Но VPS-ът е подходящ за по-големи процесорни натоварвания – да кажем ако имаме няколко хиляди клиента дневно на е-commerce, или няколко десетки хиляди ако имаме сайт, който се движи от CMS…

От основните проблеми при VPS-а, първият проблем е цената. VPS-ът струва от няколко десетки до няколко стотици лева месечно в зависимост от параметрите. Но при него има една специфична особеност – VPS-ът не предлага включена в цената системна администрация. Можем да оприличим VPS-а на мощен автомобил от Формула 1 – много бърз автомобил, който се движи само в една определена писта, а за да управлявате подобен автомобил на вас ще ви трябват години опит и години тренинг, за да го използвате. Т.е. ако вие искате да минете на VPS, то трябва да си вземете или да имате под ръка системен администратор, който да ви наглежда сървъра, защото хостинг компанията не предлага това, освен ако не е managed VPS решение…

При VPS-а полезното е, че щом разполагате със собствен компютър, макар и виртуализиран, вие може да инсталирате всякаква комбинация от пакети, което не можете да направите на shared хостинг. Вие можете да си конфигурирате по какъвто си искате начин уебсървъра, по какъвто си искате начин можете да си инсталирате Php, дори можете да си компилирате чисто нов пакет, т.е. ако в момента излезе Php някоя бета, вие можете да си смъкнете сорс кода, може да си го компилирате на този сървър и може да го използвате. В shared хостинга това нещо не съществува…

И, последното, най-хубавото, „Еверестът на хостингите“ е така нареченият Dedicated. При Dedicated имате достъп до цял един компютър, който да използвате както си искате – може да го виртуализирате, може да го нацепите за shared хостинг или ако сте много голям клиент, вие дори може да използвате собствено само този сървър за вашия сайт. Познавам няколко души в България, които правят това нещо…

Dedicated е много хубаво нещо, но за съжаление, има една много специфична особеност. Ако на VPS-а има един системен администратор, който гледа хардуерно машината – дали процесорът работи, дали вентилаторът охлажда, дали дискът не е почнал да се скапва – то при dedicated машината вие трябва да надзиравате тези неща. Имал съм случаи, когато компютър някъде си започва да бави (и сериозно ви го казвам!)… при влизане в конзолата се видя, че вентилаторът е спрял да работи. Трябваше да пратя човек, който физически да измъкне самия компютър от rack-a , да оправи вентилатора, да го затвори и да го сложи отново в rack-a. След оправянето на вентилатора, машината заработи отново без проблем.

При dedicated трябва вие да поемете хардуерния мониторинг на машината. Това е специфичната особеност тук.
Сега много хора може да запитат – защо да не вземаме dedicated машина, а VPS? Отговорът е много лесен. При dedicated машината вие не може да я бутате – т. е., ако искате да вдигнете процесора и RAM-та, вие трябва да спрете тази машина, да замените процесора, да вдигнете нова RAM, да сложите нов диск или, евентуално, да мигрирате тази машина към нова… Това обаче е свързано с време, това нещо е свързано и с пари, тъй като сървърните компоненти са брутално скъпи. Затова ако искате да скачате нагоре, или да се връщате надолу, по-добре е да вземете един VPS.
Пример: взимате VPS с два процесора и 4 гигабайта RAM. Идва Черен петък и вие знаете, че трафика ви ще скочи десет пъти. Свързвате се с хостинг компанията и казвате – искам временно процесорите да ми се вдигнат на 8, а RAM-та да скочи на 16. Това го правите седмица или две-три преди Черния петък. Хостинг компанията за секунди прави тази миграция. Сървърът се рестартира евентуално и като резултат, вие вече разполагате с цялото това нещо, след което идват Коледа, Нова година, задържате го… После след празниците, може отново да си минете на двата процесора и 4-те гигабайта RAM с един много бърз рестарт…

При dedicated машината това е невъзможно да стане, тя така си остава, тя не се пипа, но при VPS това е възможно.
Такова е най-простото обяснение за това каква е разликата между трите вида хостинг…
А ето и нещо, което много хора забравят… Голяма част от цифровите маркетъри, с които работя, знаят само, че единствен източник на данни в даден сайт е така наречения аналитикс и те вярват, че аналитикс им дава 100% от данните. Ако се занимавате с цифров маркетинг, в скоро време ще трябва да направите едно от най- интересните неща – ще трябва да установите къде се намират на вашия сървър лог файловете и да започнете да правите анализ…

Борислав Арапчев: … да, … тъкмо щях да те питам за лог файловете…

Петър Николов: log файловете са едно добре забравено старо знание, защото всеки един бот, всеки един потребител, всеки един лош бот и абсолютно всеки един човек от този свят, за да достъпи вашия сайт, той трябва да изпълни някаква заявка към сайта и той съответно да се върне към самия клиент. В резултат на това вие в log файла имате знания – IP, дата, час, какво е искал, как го е искал и какъв е user agent-а?. Това нещо съм го разправял и на други конференции, че единствения вариант да установите какви проблеми имате със сайта, какво работи и какво не работи и най-добрия вариант е да започнете да изследвате log файла. В log файла може да видите, че даден редирект не работи, че даден важен линк е счупен и може да направите някоя много елементарна промяна на този сайт… Аз лично съм виждал сайт, който след две или три миграции, някой е забравил да направи най-важната страница в този сайт, която имаше най-много линкове… Тази страница води към 404, защото тя е редиректната към 2-3-4 и някъде във всичките тези миграции, някой някога е пропуснал един редирект и съответно това води до 404…

Борислав Арапчев: Петьо, само ще те прекъсна за момент. Напоследък много инструменти излязоха за анализ на log файлове… Какво препоръчваш ти – с туул ли да се анализира log файла ръчно или човек да прецени според своите знания кое ще е по-удачно за неговия случай?

Петър Николов: Ами зависи и сега ще обясня защо.

Борислав Арапчев: При големи обеми от данни, може би е по-добре с инструмент да се гледа…

Петър Николов: При големи обеми от данни аз съм виждал сайт, където log файла е един гигабайт за един ден – некомпресиран…

Борислав Арапчев: …което е нещо огромно… да.

Петър Николов: На това нещо по абсолютно никакъв начин не може да се направи анализ, а има и още по-брутални случаи…
Най-най-най-простия анализ, който може да направите с какъвто и да е текст в редактора е да видите как Google бота ви кроули вашия сайт, като отворите log файла съответно и видите всички адреси, които са, да кажем, 64 точка 249, защото това е IP-то от Google. Това е най-простото… вие филтрирате само тези IP адреси и гледате какво ви кроули и какъв отговор съответно връщате на Google. За съжаление, когато пред вас се изправят гигабайти, това нещо е практически неизползваемо.

Много лесен туул, който може да използвате, е на SemRush Log File Analyzer, в който вие там просто си ъплойдвате файла и самия SemRush по много интересен начин ви показва кои са най-често използваните линкове и кога за последно са кроулени.

Друг много хубав инструмент е така наречения SOULMU, но той е платен инструмент (мисля, че струва 249 долара еднократно), който е инструмент на инструментите, но той не е специфично за SEO-тa, той е мащабен инструмент…
Друг инструмент, който изследвам в момента е така наречения Log Octopus. (Това го е правил SEO с девелопърска насоченост).Той позволява да видите на база на логовете кои са най-често използваните URL-и и съответно по някакъв начин може да направите някаква оптимизация (не точно за SEO, по-скоро говоря за сървърна оптимизация – примерно, кешове и т.н., за да се оптимизира достъпа до тези страници).

Но …, ако имате един проблем (за него след малко ще поговорим), това е единствения вариант изобщо да го решите – анализ на log файловете… За съжаление в България анализ на log файловете правим единици.

Борислав Арапчев: Те са много полезни, ние сме откривали така много тънки проблеми, които са видими и разбираеми само там… Затова анализа на log файловете започна да расте, да се развива като метод и да се популяризира макар и по-бавничко, защото е много специфично. И когато не разбираш понякога при някои казуси къде е „препъни камъчето“, това може да ти даде отговора…

Петър Николов: Tочно така! Това е много интересен проблем и сега ще обясня защо.
Общо взето, при нас идват клиенти, които имат проблеми. Например, имат сайт на десет години, сменили са 2-3-5 системни администратори, местили са хостинги, сменяли са SEO компании и когато питаш човека кой, къде и какво е правил и дали има някакъв списък за това, той казва „Не, нямам, оправяй се!“ Така че единствения вариант вие да се оправите в тази ситуация е анализ на log файловете, защото Google помни адресите. И дори преди десет години вие да сте имали там някакъв адрес, който днес да го няма, ботът, ако има връзка към този адрес, продължава да го кълве (този адрес), вие го виждате и съответно правите анализ защо този URL е изтрит – може да направите редирект или да върнете страницата обратно.

Никола Минков: Всъщност много често 300-400-500 грешки източват много кроул бюджета и оттам се получава доста сериозен проблем с лендингите – не може да достигне дотам бота… Тук съм съгласен! Това е основен анализ, който задължително трябва да присъства в един одит.

Петър Николов: … точно така!

Борислав Арапчев: Да, Ники, ние по-късно ще говорим за кроулинг бюджета…Нещата са свързани и затова трябва да се внимава как трябва да се постъпи…

Никола Минков: Петьо, предполагам, че вече си завършил с уеб сървърите, уебинарът е един час, а не четири… Просто напомням… Знам, че има много какво да кажеш, което ми харесва, разбира се, както и на аудиторията…

Борислав Арапчев: За Петьо уебинарът трябваше да е два часа…

Никола Минков: Но да минем делово по-нататък: HTML, основни понятия, линкове, връзки и http…

Борислав Арапчев: …а аз после ще добавя и за валидацията на кода, която някои търсят и гледат дали тя има отношение и връзка към оптимизацията.

Петър Николов: Повечето, да не кажа даже всички сайтове, които се правят, след като сървъра генерира HTML-а, този файл се изстрелва към самия уеб браузър и уеб браузъра трябва да започне да работи по HTML-а. Съответно браузърът прави други изисквания, вземат се едни CSS-и, вземат се и едни Java Script-oве, но фундамента е самия HTML, защото HTML е това нещо, което браузърите появяват.

HTML има няколко основни неща, които много хора обикновено забравят.
На първо време HTML е разделен на две основни части – имаме head и имаме body. Повечето от работата за SEO се случва в head-a, но друга основна част, която потребителите виждат, се случва в самото body. В HTML-а е изключително важно да се види какво се сервира на бота в head-a и какво се сервира на потребителите в самото body.
Има много инструменти, които показват как се вижда в head-a и body-то. Това беше валидно допреди две години. Сега има промяна, защото google ботът смъква CSS-а, смъква Java Script-a и го рендира. Така че вие трябва да знаете какво се смъква в HTML преди рендиране и какво се получава след самото рендиране.

Каква е основната разлика?

Преди около 2 години google ботът вземаше HTML-а, смъкваше си го и съответно започваше да прави анализ как този HTML работи. Сега google ботът, понеже иска да бъде максимално близко до потребителите, освен че смъква HTML-а (той между другото го гледа този HTML, така че не пропускайте това нещо) той смъква Java Script-a и го рендира.
Фундаментът – в HTML-а има три основни неща.

Първото – с robots вътре в head-a, може да има no index, no follow, no snippet, може да има и други неща.

Второто много важно!!! Всяка една страница трябва да има title, т. е. в head-a горе имаме title tag, който се скрива до затварянето на title-а, в който е самия title на HTML документа.

И третото – трябва да имаме и meta description.

Това са трите основни неща, които трябва да ги има във всяка една страница в head-a, защото когато търсите нещо с google или с някоя друга търсеща машина, виждате отгоре заглавието, виждате meta description-a или някакъв snippet и точно това нещо ви кара да решитедали да кликнете на този линк, или този линк не дава отговор на вашия въпрос.
Преди около десетина години можеше да има един и същ title на много страници. В днешно време е абсолютно задължително всяка страница да има уникален title и уникален meta description. Ако това го няма, ботът започва да се чуди – каква е тази информация, необходима ли ми е тази информация, защо да я индексирам и започват да се случват глупости… Примерно, една страница канибализира други страници… или човек знае, че има много индексирани страници, но това никога не се появява в search, с други думи, става така наречената вътрешна канибализация…
Това са много тежки неща и ако вие ги видите, трябва да се върнете към основното – какъв е title-a, какъв е description-a и да видите вътре какъв е content-a на самата страница.

В днешно време не само google бота, а и другите ботове, разбира се, са станали доста „хитри“ и в момента, когато те видят, че при различни URL –и се връща една и съща страница. Тогава ботът започва да си „мисли“ доста странни работи – той или канибализира страниците, или започва да ги смята, че това е някакъв thin content, който по някакъв начин се преборва, но най-странното е, когато видите в search конзолата soft 404 проблем. Така виждате, че при дадена страница google ботът казва – това е soft 404 и тази страница или съвкупност от страници той не ги появява в search-a… това беше валидно преди няколко години, когато страниците се правеха на ръка предимно. Сега обаче има CMS-и или e-commerce системи, които правят тези страници – правят продуктови страници, категорийни страници, начални страници и т. н., но фундамента пак си остава… всяка една страница трябва да има уникален title и всяка една страница трябва да има уникален meta description…

От тука e и другия проблем, който възниква в самото body – как точно работят линковете.
Преди около година имаше едно много интересно видео на Google, където се казваше – ние виждаме линкове и използваме линкове, отчитаме линкове само когато са “a href = на нещо си”. Всички останали начини са невалидни! Т.е., когато има on click, когато има on event и т.н.

Борислав Арапчев: …покажи ги, Петьо, защото това е много важно в момента…

Петър Николов: …няма как сега да ги покажа…

Борислав Арапчев: …не, в смисъл кажи ги…

Петър Николов: В една страница може да направите линкове по много начини…

Борислав Арапчев: … с един Java Script, например…

Петър Николов: … да, с един Java Script могат да се направят много линкове, но ботът това не го вижда, не го брои и по никакъв начин не го следва… Следва го самои единствено, когато има a href равно на нещо си. Само тогава google ботът вижда, че има линк от тази страница към други страници, това се използва за калкулиране на Google PR-а, че има и други страници, които съответно Google да почне да изследва… Т. е., фундаментът е, че може да имате много на брой, да не кажа и безброй начини да направите линк в дадена страница, примерно, с Java Script, с CSS, но Google ще изследва само тези с “a href = на нещо си”!!! …

Борислав Арапчев: … тук трябва да слушат дизайнерите, защото те много обичат такива CSS и някои по-красиви или по-гъзарски неща…

Петър Николов: … в резултат на което, като им покажеш (на дизайнерите) някакво техническо задание как тези линкове се променят, изведнъж те ти стават обществен враг №1, защото „ама те, линковете са много красиви, те са много хубави…“ Да! Линковете са много красиви, линковете са много хубави, но Google бота и другите ботове не ги виждат. Нали, в смисъл, имаме и BingBot, Yandexbot … и т. н.

Борислав Арапчев: Аз бих вмъкнал нещо много простичко – когато сложите мишката и долу в браузъра ви се изпише, че това ще заведе човек към определен адрес, това е показател, че линка е от най-обикновените и ще се види и разбере от Google. Нали така?

Петър Николов: Точно така! Аз по принцип правя същото като тебе … Ако отида с мишката до даден линк и ако отдолу пише Java Script, две точки и там нещо си… не! Tова не е линк!…, или ако пише там някакви други истории – това не е линк…

В този случай единствен вариант е да видите рендирания HTML и вътре в рендирания HTML да измъкнете само a href елементите.
Аз имам в Google Chrome, ако не се лъжа, един много интересен плъгин, (после ще ви го покажа, като го пусна в коментарите), който първо рендира HTML-а и показва какви са разликите, а друг плъгин отива и екстрактва от първия само кои са линковете, за да се изследва тази информация, т. е. нищо друго, а само линковете се изследват…Това е много важно!

Преди над 20 години сайтовете се правеха на ръка, както съм ги правил и аз…

Борислав Арапчев: … и аз…!

Петър Николов: … после почнаха да ги правят с CMS-и, с WP или с някой e-commerce и т. н., а в днешно време потребителите залитнаха по Java Script, React, View и др. подобни…(да не изреждам всичко!)… Това доведе до ситуация да се произвеждат по този начин много невидими за google бота линкове. Става така, че ти казват – ето, аз направих много хубав сайт с 5000 продукта вътре…

Да, сайтът е хубав, даже е много хубав, обаче Google вижда само една страничка от този сайт… google ботът просто не знае, че съществуват тези 5000 продукти, защото линковете към тях на практика са невидими за него и той не ги изследва … Ето това е основното!

Борислав Арапчев: Петьо, напреднахме във времето, затова бързам да те попитам – дали валидацията на HTML кода има пряко отношение към успехите в SEO?

Петър Николов: Валидацията на HTML-а е от порядъка на същото добре забравено старо знание… Когато дадете валидиран код, браузърът много по-бързо ще го „опатка“ и ще тръгне да го рендира, т. е. много по-бързо ще го парсне. Но когато имате нещо пропуснато – HTML tag, нещо не е затворено, нещо е два пъти отворено или нещо невалидно…, тогава браузърът започва да включва някакви екстендед програмистки истории – чакай да видим това къде свършва, чакай да видим онуй къде започва…

И така браузърът на практика започва да хаби време и енергия за тези допълнителни калкулации и подсещания…

Борислав Арапчев: … същото е и за google бота.

Петър Николов: Да. Същото е и за google бота!
Когато стоварите валиден CSS и валиден HTML към самия браузър, той много по-бързо се справя и много по-бързо започва да рендира, защото всичко му е „ясно“ и затова не включва допълнително излишни действия.
Много по-хубаво е да стоварите валиден HTML, защото така щадите енергията и на мобилните потребители. В момента щом стоварите невалиден HTML код, устройството, апаратът или телефонът с Android се стартира и то започва да прави така нареченото battery drain, започва да хаби батерията за допълнителните пресмятания.

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

Петър Николов: Да, така е, не трябва да сме фанатици, но когато имаме някакъв проблем, например, с рендиране, невидими линкове и т. н., хубаво е да се види дали кодът изобщо е валиден… Аз съм имал случаи да виждам два хеда горе, два title-a горе, два meta description-a два canonical-a… даже съм виждал проблем с две body-та… И когато всичко това се стовари в самия браузър, той почва да се „чуди“ – кой title да използвам, кой description да използвам, защо виждам два head-a, кой от body-тата работи… съответно това хаби малко по малко батерията… Това прави работата на браузъра много по-тежка… А представете си, че искате да правите ранкинг на този сайт – това вече ще е абсолютно невъзможно, защото просто кода не е пълен…

Никола Минков: … или, всъщност, както ти показах с едно case study, като бяхме в Цюрих, как един уебсайт изчезва от Google News точно заради това…

Петър Николов: …да, аз го помня и даже помня къде ми го каза…

Никола Минков: Всъщност ето петнадесет часа труд и накрая решихме – дайте да видим HTML-а… и, оп! Tам е грешката…! Що е изчезнал? Ами щото вижда от кода само title-a, датата и снимката.

Петър Николов: Точно така! Когато имате проблем, гледайте си HTML-а! Това е основното… HTML-ът е фундамент, на който се гради абсолютно всичко нагоре!

Никола Минков: Петьо, давай да минаваме нататък…

Борислав Арапчев: … да, и аз приканвам към това… Петьо, ти имаш много знания, интересно и много полезно е всичко казаноот теб, но ние имаме определен лимит от време, а то напредва… Това, за което ми се иска да поговорим още с теб е за тази много важна комуникация между google бота и сайта, осъществима основно чрез robots.txt-то. Знаем, че ботът посещава първо този файл, за да види къде може да отиде и къде не… после гледа site map-a и съответно вече минава по линковете, които са в сайта. Какво ще ни кажеш за това?

Петър Николов: Това е още едно забравено старо…

Борислав Арапчев: … но то е много важно…

Петър Николов: …да, то е много важно! Изключително важно е да имате robots.txt, но ако нямате не е болка за умиране… Също така, по принцип, не е болка за умиране, ако robots.txt-то ви връща 404, защото вие нямате такъв файл…
НО!!! Казвам едно голямоНО!!!
Ако robots.txt-то е насочено някъде другаде, ако robots.txt-то ви връща грешка 500 или грешка 503 и ако и тогава вие си кажете – „няма го тоя файл – ОК, никой няма да умре!“… тогава в този случай вие се хвърляте в друга погрешна посока, защото google бота, когато посещава сайта, а вие сте му стоварили една грешка 500 или 503, то google ботът си казва – тоя сайт не е нещо добре, айде ще го отложа… днес няма да го пусна…, ще го отложа за утре, за в други ден или за след една седмица. Идва той пак след една седмица, вижда отново грешка 500 и вече google ботът категорично започва да пропуска този сайт …

Следователно, да имате robots.txt е фундамент, но също така е фундамент да виждате какво връща robots.txt и как точно го връща. Виждал съм сайтове, които примерно, за потребител не връщат грешка, обаче за google бота връщат грешка 500. Човекът идва и казва – сайтът ми е много хубав, имам си robots.txt, всичко си работи, обаче този сайт не работи в Google… Поглеждаш и … опа-а-а! … виждаш, че за google бота се връща грешка 500 или 503… Т. е., трябва да следите и да си знаете във всеки един момент какво е съдържанието на robots.txt-то и какво изобщо връщате на бота.

Борислав Арапчев: Трябва с рендъра на Google да се анализира в конзолата, има и добри бот симулатори…

Петър Николов: … точно така… Стандартните браузъри не ги бърка robots.txt. Но това е направено само и единствено за ботовете, затова е изключително важно да знаете как именно тези двата сайта работят…

Много важно е да знаете и как работи сайт мап-а, защото когато имате ново съдържание, google ботът не кибичи нон стоп във вашия сайт за да види, че имате ново съдържание… Най-простия начин е да имате site map, който да кажем се посещава поне веднъж или два пъти дневно. Така се вижда – аха, там има нова страничка. Google ботът отива и директно кроули тази страничка. Подобно нещо е изключително важно за новинарски сайтове…

Ако вие имате новинарски сайт, но нямате news site map, който е различен site map… News site map-ът се посещава по няколко пъти на час, виждал съм и по десет пъти на час…

Борислав Арапчев: … Това зависи от честотата на публикуване на нови материали…

Петър Николов: … Да. Примерно знаете, че стандартно google ботът идва, взема началната страница и съответно гледа дали има линк. Но това нещо е ресурсоемко и те са направили такъв вариант с news site map или съответно със site map. Google ботът отива, взема един файл и веднага вижда – аха, там има нова промяна вътре, която трябва до изкроуля, за да видя какво е това нещо…

Виждал съм сайтове, които пак по същия начин връщат грешка 500 на site map СПЕЦИАЛНО за Google. Виждал съм на живо такива случаи… В резултат този сайт мап започва да пада, по-бавно се индексира и т. н. …

Въпрос на живот и смърт е да знаете какво става в тези два сайта към Google, съответно, към фейса, и към Bing, и към Yandex, защото тези два файла са фундамент. Те не ви засягат като крайни потребители, но … за Google са фундамент!

Никола Минков: Съгласен съм с това, Петьо… Тук е момента само да кажа и да напомня на тези, които са пропуснали, че Google News Publisher е ъпдейтнат. Има вече нова функционалност вътре и може да правите категории и т. н. Разгледайте го – това се случи миналата седмица…

Борислав Арапчев: Много напреднахме с времето, Петьо…

Никола Минков: Спокойно, ще го държим още, ако трябва – ще го вържем, защото има много въпроси…

Борислав Арапчев: Ще вмъкна един въпрос, макар че имаме план за темите… Питат ни – понеже ти, Петьо, както и ние от Serpact, си посетил много международни конференции, може ли да споделиш какво си научил от там, какво е твоето мнение?

Никола Минков: Какво си научил от тези мероприятия?… Ама и ти, Боби, ще отговориш на този въпрос…

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

При нас в България контактите са по-особени. Понеже сме малка страна, тук започна една зверска канибализация – взаимно изяждане… виж какъв голям специалист съм аз… тоя не го слушай… и т. н. Когато изгреете навън от страната, когато излезете навън от нея, виждате, че пазара е необятен ихората там, въпреки някои лични дрязги помежду си, установяват и поддържат някакви нормални човешки взаимоотношения с всички. Те знаят, че всички сме хора и нормалното е да се държим като хора. Докато в България се правят много простотии и когато някой направи простотия, върху този човек всички започват да изливат кофи с помия… Аз също съм имал проблеми с тоз и онзи, но в крайна сметка дърпам човека настрани и му пиша съобщение – хей…, допуснал си някаква грешка, внимавай, защото аз няма да го опиша на публично място.

Това е най-важното, което там се научава за човешките отношения… Когато излезете вън от България, независимо кой сте, вие може да си поговорите, например, с даден спийкър, или с всякакви други хора, от които може да научите много неща. Хората там са много отворени да си споделят знания и опит помежду си, докато тук, в България, понеже сме мно-о-го големи специалисти, като отидеш при някой колега с намерението да споделиш с него проблема си, повечето махват небрежно тежко с ръка и с досада те отрязват с думите – не ме интересува, не ме касае, не ми спами темата… и други такива неща.
Имал съм случай да питам някого как е решил даден проблем, а той високомерно да ми отговори, че няма да ми каже, защото – „…а, не, това е фирмена тайна… няма да ти кажем как ние го правим във фирмата…“ Е, ами хубаво сега като няма да ми кажеш – пазарът е голям!…

Между другото, Google казва, че само 20-25% от фирмите в световен мащаб имат сайтове. Това на Запад го виждат и се знае… А сега си представете какво ще стане, когато и останалите 75-80% дойдат… Ами пазарът ще стане необятен! Имайте предвид и другото – ако сега в България със SEO-то се занимават, примерно, хиляда души, тогава за в бъдеще за тази дейност ще трябват десет хиляди или сто хиляди човека… Пазарът не само, че ще ги поеме всичките, но и пак ще трябват още хора…(т. е .хляб и работа ще има за всички…) Така че за мене това е най-важното – да бъдем хора и да имаме нормални колегиални отношения…

Никола Минков: Браво, Петьо! Много добър съвет! Боби, сега си ти по темата… какво ще кажеш, кое е най-важното, което си научил от международните конференции в чужбина ?

Борислав Арапчев: Както каза и Петьо, при посещението ни на самите конференции, в лекциите се научават много и все полезни за нашата дейност неща… Но между лекциите, в уъркинг-ите, в личните срещи и контакти с колегите, винаги се коментират най-добре всякакви идеи и подходи, които работят. Някой колега може буквално с едно изречение да ти покаже някаква практика или да ти каже метод, които след като ги приложиш, дават изключително добър резултат…
И другото, за което искам да кажа, е за лекцията на Изи Смит в Цюрих, където бяхме с тебе, Ники, и с Дидо…

Петър Николов: … и с мене! …

Борислав Арапчев: … Да! Да, Петьо, бяхме и с тебе, извини ме! Аз тук в момента мислех само за нашия екип от Serpact… Разбира се, че и ти беше с нас, но аз за теб мисля като за някакъв ангел-пазител над нас…

Говорих за лекцията на Изи Смит, която беше много успешна и силна … Тя каза, че трябва да минем, да се издигнем над техническите неща и да бъдем преди всичко хора, както го изтъкна и Петьо…т. е., трябва да се стремим и да даваме полезност, добавена стойност на потребителите… Техническите подробности (CSS-и, скорости и т. н) в нашата работа са една част от усилията ни за това, но ние ще имаме истински успех само тогава, когато даваме решения и отговори на хората…

Съгласен съм изцяло с нея, защото макар и по друг начин, същото съм го казвал и аз много пъти в моите лекции за съдържанието – смисълът и целта на един сайт, независимо от това какво има в него (статии, новини, продукти, услуги и пр.), е да предлага винаги ценно и стойностно съдържаниена хората, които го четат и разглеждат!

Никола Минков: Да, така е, Боре. Но да продължим нататък. Все пак Петьо е нашия гост…

Борислав Арапчев: Ники, от аудиторията има желание този уебинар с Петьо да продължи още един час…

Никола Минков: Ами тогава, Петьо, ако няма още какво да добавиш за HTML-ите и txt-тата, да продължим по-нататък с частта за кроулинг бюджeта.

Петър Николов: Ами гледайте си HTML-ите, гледайте си robots.txt–тата и най-вече, гледайте как Google ги вижда…
Между другото, това е много интересен въпрос, защото повечето хора отиват, гледат log файла и казват – ама аз връщам на бота код 200…

А аз му казвам – да, бе човек, ти хубаво му връщаш код 200, но дай да видим какво ние изпращаме нагоре, защото не е тайна, че има много заразени сайтове, които като потребител ги виждаш по един начин, а ботът вижда нещо съвсем различно… Затова: оглеждайте внимателно, гледайте какво се връща и най-вече гледайте какъв content се изпраща към ботовете, защото това е много важно.
И така, стигнахме до …

Борислав Арапчев: … до кроулинг бюджета, което е сравнително ново и стана модерно, а и е много важно…

Петър Николов: … не! Не е ново това…

Никола Минков: Само ще те върна малко, Петьо… ти каза да тестваме как Google вижда сайтовете. Приемаме, че нямаме search конзола, дай инструментите, с които хората от нашата аудитория могат да тестват външно някой уебсайт какво връща. Знаем ги, но все пак дай ги…

Петър Николов: По принцип аз използвам най-често webpagetest.org, защото това е фундамента и той позволява тестването на сайт от много на брой различни мобилни устройства, от различни локации и т. н. Проблемът е, че webpagetest не позволява „шменти капели“ от типа, да кажем, че ние сме google бот или че ние сме фейсбук бот… В този случай аз използвам така наречената команда Curl, която е от команден ред, като в curl-а сменям user agent-a… то се сменя с тире, главно А, интервал, кавички и пиша си user agent-a… Достатъчно е само да напишеш google бот, да затвориш кавичките и отзад да парснеш URL…

Борислав Арапчев: Това за някои наши потребители ще е трудно и сложно… Може би е хубаво да кажеш и браузъра Chrome, където…

Петър Николов: Да, точно това сега след малко ще кажа…
Значи, curl-ът е много полезен ако вие обаче имате Unix среда… Примерно, ако ви работи на unix или на Mac OS, или ако случайно сте си инсталирали unix на windows-а…

Понеже това е трудно, в Google Chrome направиха една нова функционалност, където отварям нов таб, натискам десен бутон и се отваря на inspect, след което в долния таб се отваря network condition и с юзър ейжън-та може да дадеш custom user agent.

Много е полезно да видите дали вашия сайт или вашия и-комърс случайно не стрелва друг HTML при смяна на user agent-та, защото това е фундамент. Когато това нещо се появи, т. е. вие на един и същ URL изстрелвате различно съдържание, щом пуснете новина, щом вкарате нов продукт вътре и въобще щом напишете нещо ново. Google ботът е създаден максимално бързо да дойде и да види какво е новото. Но понякога има някои странни случаи, когато google ботът е толкова натоварен с работа във вашия сайт, че не забелязва новото в него. Имал съм случаи човек да ми казва – аз съм новинарска медия, пиша новина, всички мои конкуренти я преписват от мен, а при мен в Google се появява след два дена…

Когато имате този проблем, проблемът ви е с кроулинг бюджeта. Тук отварям една скоба…
(Примерно, google бота се събужда, да речем, в Калифорния и си казва – ти имаш 1000 страници, аз днес ще дойда и ще ти обновя 10 страници, утре пак ще ти обновя 10 страници, в други ден – пак 10 страници и т.н. …А вие знаете това, че на ден Google ви кроули 10 страници… Обръщам вниманието, че в примерите, които давам, сметката e приблизителна.

Кога възниква проблема?

Когато имате мултимилионен сайт с много страници, google ботът вече няма да ви кроули 10 страници, а ще кроули 1000, 10 000 или дори 100 000 страници, но за вас е много важно, въпрос на живот и на смърт е даже!, от всичко, което се кроули, кроулинг бюджeта да изкроули ВАШЕТО НОВО СЪДЪРЖАНИЕ, т.е. – новите продукти. Но понякога google ботът е така натоварен с този кроулинг бюджитi, че той не минава и не кроули нито новото съдържание, нито новите продукти и дори съм виждал случаи, когато той дори индексира нов продукт чак след два месеца…, т. е. пускате нов продукт, променяте му цена, слагате му име, натискате в e-commerce бутона „запис“ и чакате цял месец продукта да излезе…

Борислав Арапчев: … но продуктът не излизa…

Петър Николов: … но новият продукт не излиза – излиза чак след месец-два… в това e проблемът! Именно тогава вие установявате, че имате мега брутален проблем! Повтарям, когато имате такъв проблем, вие имате проблем с кроулинг бюджета!
Как се решава проблема с кроулинг бюджета? Много трудно!!!

За да се реши този проблем трябва да се види:

Първо – да се види log файла.

Второ – да се види какво се стоварва нагоре към Google, да се видят http-тата, head-a и т.н. и трето – да се направи анализ на всичко, за да разберем защо Google на практика „не харесва“ този сайт и защо Google работи бавно с него.
Когато направите внимателен анализ на log файла, тогава ще видите какво google бота най-много „харесва“ като линкове, защо именно тях кроули и защо новите продукти, новини, или др. съдържание, са толкова малко изкроулени… Единственият вариант за решаване е точно анализа на log файла и да видите там защо това нещо не работи.
Съществуват и други начини за решаване на проблема с кроулинг бюджета, но тези начини са прекалено сложни – примерно, да се ускори сайта или да се направи нещо подобно… Но, общо взето, основното е, че нещо някъде грандиозно се е счупило … Вероятно защото вие подавате 404 към Google или google ботът изпада в някакви вътрешни редиректи, които се убива да ги скъсва, или той минава и кроули някакви много стари страници, защото именно тях много си е „харесъл“, или ако имате много URL параметри (това важи най-вече за e-commerce-те), например, при сортирането – хоризонтално, вертикално, по азбучен ред, по цена нагоре, надолу, по продажби и пр., когато имате много параметри с въпрос нещо си там в URL-а, Google ботът се скъсва да индексира категорийните пейжове (страниците с категориите) и затова отделя по-малко внимание на продуктовите страници. Виждал съм го този вариант много пъти… виждал съм и вариант, когато google ботът минава, вижда само първия категориен пейдж и за него другите категорийни пейджове са невидими, т. е., ако на пета страница имаме нов продукт и понеже той не може да отиде на пета страница в категории, затова съответно не вижда и този продукт…

Никола Минков: … това при положение, че е лимитирано през txt-то или – не???

Петър Николов: … не, не е лимитирано, обаче някой е направил страниците с on click, поради което те стават тотално невидими и това нещо не работи…

Единственият вариант да оправите кроулинг бюджета е с анализ на log файловете и с много дълбок анализ какво изобщо е много важно в проблемния сайт.
Понякога има много вътрешни съпротиви между различните отдели и около сайта –- SEO компанията, дизайнерската компания, девелопърите и т. н. …

А ето и нещо много важно, което вие знаете МНОГО ДОБРЕ: кроулинг бюджета не се оправят от днеска за утре (с едно щракване), кроулинг бюджета изисква месеци и даже година работа, за да се подобри това нещо… Ако имате сайт с милиони страници, вие разбирате, че когато направите дори и най-малката промяна, се изисква гигантско много време да се обходи целия ви сайт. Затова е хубаво когато имате проблем с кроулинг бюджета да следите и четете всичко налично по темата и чак тогава да правите промени. Виждал съм хора, които са паникьосани и почват да правят промяна след промяна, но, общо взето, нищо не се случва…

Никола Минков: … не виждат промяна в резултатите и те си казват – „мале-е-е, нещо не сме направили като хората!“, – а те всъщност очакват за два дена нещо да се подобри…

Петър Николов: …Да!
Друго нещо – малките и средни сайтове нямат подобни проблеми с кроулинг бюджита. Но ако имате сайт от около 10 000 и нагоре повече страници е хубаво да се замислите за кроулинг бюджета и той да ви стане добър приятел, защото след като сте направили дори най-малката промяна в сайта, вие трябва задължително да се запитате как тази промяна ще се отрази на кроулинг бюджета… При сайт от 1000 страници не е голям проблем това…

Никола Минков: … Да, но не е лошо все пак да се анализира сървър log файла за да се види дали от тези 1000 страници не хвърляте 20 от тях в девета глуха…

Петър Николов: Точно така!

Никола Минков: Съгласен съм с теб, Петьо. Страхотно споделяне на знания… от аудиторията не искат да те пускаме… обаче трябва да минем към следващия етап…

Борислав Арапчев: … а този следващ етап, както знаете от нашата традиция накрая е да завършим забавно… Предлагаме на Петьо да даде подходящ alt tag на определено от нас изображение… Нека колегите да пуснат изображението…

Петър Николов: Ами това е моето куче, което през лятото ни роди пет малки сладура …. Едното от тях беше с вродена малформация, която, за съжаление, не беше несъвместима с пълноценен живот, според мнението на няколкото лекари, където бяхме…, така че останаха само четири сладурковци, които буквално ни се качиха на главата… Наложи се да се разделим с тях като ги раздадем, но… такава е съдбата на всички кученца…

Аз бих нарекъл изображението Тамара и нейните пет кученца…

Борислав Арапчев: … или Сладурковците, може би… 🙂 .

Петър Николов: … примерно  да!… 🙂 …

Никола Минков: … супер! … Нека сега Петьо да каже и няколко последни думи на финала, с които да обобщи казаното…

Борислав Арапчев: … например, как виждаш хората да планират своята стратегия занапред, как да се подготвят за в бъдеще, какви мерки да предприемат, за да са успешни? …

Петър Николов: По принцип виждате, че преди Google работеше по един начин, днес работи по друг начин, утре и в други ден ще работи другояче… Ето защо единственият способ да оцелеете в тези вълни, които връхлитат и могат да преобърнат в бурното море вашето малко сайтче, което е като едно корабче, като една яхтичка вътре…, единственият вариант е вие да давате на потребителите важно и полезно съдържание. Ако не го правите няма как да оцелеете!
В Цюрих ни казаха в прав текст – гответе се за по-чести и по-резки ъпдейти с течение на времето… Така че механизмите, които вчера и онзи ден са работили, днес вече няма да работят и единственото което остава да давате е съдържанието да бъде максимално полезно за онова, което е важно за потребителите… В противен случай ще губите самите потребители…

Често се задава въпроса – трябва ли да се обновява съдържанието. Да, трябва да се обновява, но има неща, които по принцип не могат да се обновяват. Това са, примерно, историческите събития и факти или някои други подобни неща, затова не бива да се изпада в крайности като ежеминутно обновление на всяко съдържание…

Никола Минков: Благодаря, благодаря ти, Петьо. Ще си позволя да завърша този последен за 2019 година уебинари да го затворя с кратък обзор на това, което се случи през годината.

Искам да благодаря поименно на всеки един от участниците в Serpask. Това бяха Даун Андерсън, Оги Младенов, Мурад Ятаган, Георги Стефанов, Димитър Димитров от Инбаунд, Генади Воробьов, Теодор Захариев, Иво Илиев, Мери Хайнс, Петър Дяксов, Бил Славски, Едуард Димитров, Мартин Сплит, Милош Красински, Теодора Петкова, Педро Диас, Любомир Атанасов, Дидо Григоров, Док Шелдън, Евгени Йорданов, Дацко Дацев, Дана ди Томазо, Алейда Солис, Петър Николов и Джон Мюлер. Искам да благодаря на всички тях, както и на екипа ни поименно, защото без хората от екипа тези уебинари нямаше да се случат – Дидо Григоров, Иванина Минчева, Христо Саманджиев, Деян Стоянов, Борислав Арапчев, Константин Курдалиев, Павел Сарандев, Сияна Караатанасова, Светла Йорданова, Иван Ангелов, Катя Минкова, Мария Тодорова, Пламена Джарадат и Стефан Фотелов, както и на Лариса Илиева… Благодаря на всички, които бяха част от нас в тези 26 уебинари, което значи, че сме хвърлили над 300-400 часа за тях. Надяваме се да продължим и през новата година, надявам се някой да ни помогне и със спонсорство, ако иска да му направим реклама, предстои ни нова серия от уебинари. Там ще предложим анонсиране на новото в интересни формати.
На всички желая весело посрещане на празниците, бъдете здрави, работете с партньори и колеги коректно, дръжте се етично. Пожелавам през новата 2020 година на всички много успехи… 🙂

Борислав Арапчев: Весели празници на всички… Петьо, благодаря ти, че днес беше наш гост… 🙂

Петър Николов: Весела Коледа и честита Нова година на всички… 🙂 .