За съжаление, 99% от родните ни уеб разработчици или не разбират нищо от SEO или не ги интересува. Което всъщност е непрофесионално отношение към изработката на сайтове за клиенти.
Разработчиците трябва да носят своята отговорност не само към крайното изпълнение за функционалността на сайта, но също така и към неговата вътрешна оптимизация, което е обвързано с двустранна комуникация между оптимизатори и разработчици, така че процесът да бъде ползотворен и максимално ефективен.
В тази статия ще разгледаме някои важни и рядко обсъждани аспекти, които ще Ви помогнат за цялостното подобрение на Вашия сайт.
Стабилност на сървъра и Downtime
HTTP response кодът "503 Service Unavailable” е най-добрият подход, който можете да използвате при планирана профилактика на сайта Ви или непредвиден downtime. Този response code оказва минимално влияние на резултатите от търсенето, спрямо други 5хх статуси, които връща сайта Ви като отговор.
500, 502 и 504 HTTP response кодовете водят до това Google да понижи класирането на дадена страница или тотално да я премахне (деиндексира) от страницата с резултатите от търсенето (SERP-a). Очаквайте всеки път, когато потребителите или ботът на търсачката попадне на такъв тип страница, да имате увеличение на степента на отпадане (Bounce Rate-a).
Извършвайте навременни действия при наличие на грешки в Search конзолата, а също така комуникирайте активно с разработчиците на сайта при евентуални проблеми. Това ще Ви спести бъдещи потенциални проблеми, както и разговори с клиенти, чиито сайтове имат спад в посещенията или времето на престоя на сайта им.
Създайте персонализиран tracking event за всеки “зловреден” response code (4xx, 5xx грешки). По този начин, проблемите се диагностицират и отстраняват по-лесно, когато човек има общ поглед над цялостната картина, без да се налага да ги анализира постфактум.
Бъдете внимателни, когато разглеждате и анализирате общия и процентния брой грешки в даден сайт. Една по-комплицирана страница може да подаде например 150 заявки до сървъра, преди да бъде изцяло заредена в браузъра. Това означава, че лог файловете ще отчетат по-малко “лоши” response кодове, отколкото реално са били регистрираните такива.
Например, нека си представим, че отваряме и зареждаме дадена страница два пъти. При първото зареждане всичко е наред и сървърът връща статус код 200, но при второто зареждане, статус кодът е 502-Bad Gateway и страницата не може да бъде заредена. Заявките към сървъра са били общо 151 и само една от тях не е била успешна. Тоест, в процентно съотношение за потребителя, това са 50%, а не 0,6%, както изглежда калкулацията в общ план.
Опитайте се да избягате и да пренебрегнете изкушението от това да неглижирате малките грешки. В много случаи, на пръв поглед дребните проблеми, водят и до по-големи такива. Така че, старайте се всичко по структурата и семантиката на Вашия сайт да е в ред.
CDN услуги и кеширане
Кеширането е важна, но не и основна част от оптимизацията на Вашия сайт. Представете си, че кешираната версия на Вашия сайт е като най-добрата снимка, която имате и сте я качили в сайт за запознанства. Това е първото нещо, което хората виждат (своеобразната снимка), но когато се срещнете и опознаете с някого, тогава проличава истинското Ви “Аз” и вече “снимката” няма такова значение. Същото важи и при потребителите и търсещите машини.
Обръщайте внимание на размера на страниците и се старайте да ги оптимизирате максимално. Например, akamai.com има ограничение от файл до 1MB, а всичко надхвърлящо това условие води до грешка (статус код 500).
Синхронизирайте вътрешните си log файлове с тези на CDN услугата, която използвате (ако използвате), за да избегнете вероятността, да не можете да локализирате някой проблем.
За много големи сайтове с огромен брой страници, които не се обновяват редовно, обмислете варианта за използване на статус код “304-Not Modified”.
Проверете сайта Ви за страници, които не използват динамичнo сервиране на съдържание (например, статични листинги, които рядко се обновяват). По този начин можете да избегнете допълнителното натоварване на сървъра като кеширате страниците и планирате опресняването им.
Rewrite правила и менажиране на URL пренасочванията
Ако и когато Ви се наложи да промените URL адреса на дадена страница, погрижете се своевременно да го пренасочите към актуалния (новия) URL адрес. Това ще прехвърли голяма тежест от стария адрес към новия, а също така е много по-удачно пренасочването, спрямо това адресът да бъде разпознат от търсачките като 404 и чак след това да бъдат правени опити за неговото възстановяване.
Проверете внимателно rewrite правилата, които сайтът Ви използва. Доста често срещан случай е, когато даден домейн е бил достъпен първо през HTTP, а след това му е сложен SSL сертификат и бива достъпен и през HTTPS. Това може да доведе до няколко проблема. Първият е, така нареченият loop. Едната версия препраща към другата в различните вътрешни страници от сайта. Ако не са правилно описани rewrite правилата, домейнът може да се зарежда по много различни начини, което търсачките не харесват и обикновено третират като различни адреси с дублирано съдържание. Например:
https://www.example.com
http://www.example.com
https://example.com
http://example.com
Всички адреси трябва да са унифицирани и да имат правилно описани rewrite правила, така че всяка вариация от гореописаните да пренасочва към една единствена стойност на URL адреса.
Блокиране на ботовете
Както всички знаем, основната търсачка, в която се стремим да постигнем челни позиции има така наречения, Crawling Budget (бюджет за обхождане). Ако в миналото беше традиция да ограничаваме ботовете, за да не хабят сървърно време, то сега е точно обратното и няма нужда да ограничаваме Google бота да обхожда страниците ни. Точно обратното, искаме възможно най-често да ги посещава и да индексира новосъздадените или необходените такива. Не забравяйте, че това е пряко свързано с вътрешната структура на сайта Ви и броя страници, така че, внимавайте какво позволявате (респективно, забранявате) да бъде индексирано.
Бърз съвет: бот от Америка не е задължително добър сигнал. Бот от Русия не е задължително лош сигнал. Така че, следете си логовете и инструментите за мониторинг, анализирайте и блокирайте само ако има нужда.
Скорост на зареждане
Не е тайна, че скоростта на зареждане на даден сайт отдавна е ранкинг фактор при класирането в Google. Особено след активирането на Rank Brain алгоритъма и анализа на потребителското поведение, скоростта на зареждане е един от основните фактори за класирането на даден сайт. Накратко казано, ако потребител влезе в определен сайт и той не се зареди до няколко секунди (3), напълно нормално е потребителят да го напусне. Никой не иска да губи посетители от сайта си, защото това води до по-малко реализации (продажби), както и до спад в класирането и посещениета на сайта.
Изберете си някой от инструментите за измерване скоростта на сайта Ви и и се придържайте към него (GTmetrix, Google Page Speed Insight, Lighthouse или други).
Скоростта на зареждане през мобилни устройства има голямо значение. Дори и да поддържате AMP версия на страниците от Вашият сайт, Google прави “заключения” спрямо това кой потребител се е задържал на сайта, колко време е прекарал там, броя страници, които е разгледал и множество други фактори, които имат отношение към позиционирането на сайта Ви в търсачката.
Времето за отговор на сървъра - както вече споменахме, Google не обича сайтове, който се зареждат бавно, а също така не забравяйте и за crawling budget-a. Тоест, ботовете нямат неограничен ресурс, за да обходят всички налични сайтове, а също така нямат и време да “чакат” да се зареди някой бавен сайт, за да го обходят. Всъщност Google изпитват силен недостиг на възможности за обхождане на всички страници по света. Ето защо, трябва да осигурите добър и надежден хостинг на Вашия сайт, за да сте сигурни, че поне тази точка от пасивната оптимизация е покрита.
В този ред на мисли, ако имате голям уебсайт с много на брой страници и използвате NGINX, уверете се, че Gzip компресията Ви работи във Ваша полза, а не забавя времето за реакция на сървъра.
Изчистете всичко, което блокира рендерирането на дадена страница. Това със сигурност ще повиши скоростта на зареждане на Вашия сайт (JavaScript, CSS, шрифтове).
Фокусирайте се върху това, което се случва при зареждането на страницата и най-вече периода от първите 200ms до максимум 2 секунди. Ще се изненадате, че някои страници изобщо не се зареждат “докрай”, заради рекламни карета например.
Пътят на критичното рендиране
Time-to-first-byte е важен показател, но също толкова важно е какво се съдържа в този първи байт. Браузърът трябва да бъде в състояние да покаже съдържанието above the fold (видимата част без скролиране), преди да отвори нова връзка със сървъра.
Определете размера на елементите на страницата, за да не се получават хоризонтални скролирания. Потребителите силно се смущават, когато страниците се движат наоколо и това прави всичко да изглежда бавно, дори и да се зарежда бързо.
Технологии и достъпност за Google бота
Client-side рендерирането може да е доста неблагоприятно за SEO. Google препоръчва да предоставяте на ботовете server-side rendered страница, дори потребителите да виждат client-side rendered страница (това не се счита за cloaking).
Осигурете лесен начин на Google ботовете да разпознават страницирането на Вашия сайт, независимо дали сервирате на потребителя infinite scroll или отделни бутони за предишна и следваща страница.
Избягвайте използването на block-level линкове, въпреки че това олекотява кода. Всички допълнителни директиви в < a > тага затрудняват Google бота колко и каква контекстуална тежест да придаде на целевата страница, която се линква.
Осигуряване на качество и работа с тестови домейни
Когато използвате тестови домейни или сървъри, използвайте файла robots.txt, за да укажете на търсачките, че въпросният (под)домейн не трябва да бъде обхождан и индексиран. Това ще Ви предпази от дублирано съдържание, както и проблеми, които могат да възникнат с индексирането и позиционирането на основния сайт, който планирате да стартирате.
И понеже Google не винаги се съобразява с директивите в robots.txt, за да сте железни в това изискване, може да добавите и “noindex, nofollow”, като команда на meta robots.
Най-сигурния вариант е достъп с парола, но не винаги е най-удобния.
Продуктови изисквания
Обърнете се към някого (препоръчително е да е от SEO екипа или някой, който отговаря за продукт мениджмънта), който да може ясно и правилно да определи как да бъде изградена дадена страница. В това число влизат неща като: метазаглавие, H тагове, микроданни, метаописание и множество други on-page фактори.
Вътрешна свързаност (internal linking)
Линковете са кръвоносната система на един сайт, както и на цялата интернет мрежа. Всяка важна или релевантна вътрешна страница от даден сайт е важно да бъде линкната от друга такава. Това позволява по-лесното обхождане на сайта от търсачките, както и семантичното му определяне, ако са приложени правилно основните положения: структура, микроданни, навигация.
Javascript
Страница, която започва да се зарежда, след което става бяла, често се чупи поради отворен write() таг. Съветваме да не се използва.
Google ще се опита да следва относителните пътища в Javascript, дори когато те не съществуват. Става дума за библиотеки, които се извикват в Javascript, но са със сгрешени пътища. Това може да доведе до грешки при обхождане.
Регистрар и IP мениджмънт
Никога не позволявайте на маркетьори да изпращат промоционални имейли, както и бюлетини от IP-то, където се хоства Вашия сайт. При неправилната употреба на тези тактики може да бъде blacklist-нат домейнът Ви.
Погрижете се ежегодишно да попълвате информацията за Вашия домейн. Удостоверете, че Вие сте реалния собственик, за да се предпазите от евентуална кражба или присвояване на Вашия домейн от трети лица.
