Всички сме виждали онези странни дълги (и подозрителни понякога) адреси с главни и малки букви и всевъзможни символи, съдържанието зад които остава напълно непонятно… докато не ги отворим. Нужно ли е да казваме, че е един оптимизиран URL адрес би изглеждал доста по-приемливо от потребителска гледна точка? Е, казваме го.
Пък и “чистият” уеб адрес се запомня сравнително лесно - можем директно да го напишем в браузъра, вместо да го търсим из сайта. ;)
Всъщност SEF (Search Engine Friendly) URL адресите са полезни и за търсещите машини, както и името им подсказва. Освен всеизвестния факт, че URL адресите на сайта ни трябва да бъдат уникални (за да бъдат обходени и индексирани), струва си да споменем и че при равни други условия търсещите машини биха класирали по-напред страниците с user-friendly адреси.
Нека припомним какво представлява URL адресът, преди да продължим нататък:
URL (Uniform Resource Locator) адресът или т.нар. уеб адрес обозначава местоположението на уникална уеб страница (или какъвто и да е друг ресурс) в уеб пространството. В действителност замества IP адресите, чрез които браузърите комуникират със сървърите.
Да разгледаме основните елементи на един уеб адрес:
- Обикновено протоколът е http:// или https:// (като s означава secure, при наличие на SSL сертификат), но може да бъде различен - като mailto://, например.
- Top-Level Domain (TLD) може да бъде .com, .net, .gov, .org и др. Country-Code Top-Level Domain (ccTLD) е Top-Level Domain за определена държава. Всяка държава има свой запазен Top-Level Domain, който обикновено е дълъг 2 букви. Напр.: .bg е запазеният ccTLD за България.
- Името на домейна (Domain name) е името на уебсайта, където се намира ресурсът. Името на домейна и Top-Level Domain заедно образуват Root Domain - който обичайно е най-високо в йерархията на сайта и най-често е началната страница. Логично всеки URL адрес, който е част от уебсайта ни, трябва да съдържа Root домейна в уеб адреса си.
- Поддомейните (Subdomains) се добавят пред Root домейна и са разделени от него чрез точка. Най-често можем да срещнем www., както и blog. Има поддомейни за държави, които заместват ccTLD. Напр.: https://bg.site.com. Тук е мястото да споменем, че държава може да бъде обозначена и по трети начин в URL адреса - чрез поддиректория (Subdirectory). Напр.: https://site.com/bg.
- В зависимост от страницата, на която се намира потребителят, и пътят, който е изминал, за да стигне до нея (“пътека” на потребителя - path), URL адресът може да съдържа имената на категории от различни нива от сайта, както и параметри (session ID, GET-параметри, GCLID параметри), които се “съхраняват” в URL адреса.
Какво е clean URL адрес?
SEF (Search Engine Friendly) URL, Clean URL, Use-friendly URL или дори Pretty URL е адрес, който е логично структуриран и разбираем за потребителите. Обикновено SEF адресите са кратки, ясни, лесно запомнящи се и в идеалния случай - съдържащи и ключови думи.
За Google наличието на ключови думи в уеб адресите не играе кой знае каква роля и веднага поместваме твърдение от страна на самия John Mueller по темата (2017г.):
Keywords in URLs are overrated for Google SEO. Make URLs for users. Also, on mobile you usually don't even see them.
— 🐝 johnmu.rss?utm_medium=large (personal) 🐝 (@JohnMu) March 8, 2017
Истината е, че в днешно време, когато сме в Google главно през мобилен браузър, доста рядко виждаме URL адресите. Освен това идеята, че ключовите думи в URL могат да повишат CTR (Click-Through Rate) от страницата с резултати, вече е леко застаряла, имайки предвид, че Google почти не показва URL адреси в SERP (Search Engine Result Page). Защо? Защото вместо това предлага на потребителя по-лесно ориентиране още на страницата с резултати чрез breadcrumb навигацията:
Абсолютно на място тук би бил въпросът:
Е, защо да си тровим живота с внедряване на SEF адреси тогава?
Google предпочита SEF адресите главно поради една проста причина: потребителите ги предпочитат.
Дотук всички сме съгласни, че оптимизираните адреси изглеждат със сигурност по-представителни от един дълъг адрес със session ID или неразбираеми параметри в опашката.
Ето обаче 3 по-обективни причини да оптимизираме URL адресите на сайта си
1. Google Ranking Factors
Може би вече знаете, че Google разчита на над 200 ranking фактора за своя алгоритъм - някои са потвърдени, други се считат за спекулация. Ние обаче ще бъдем сравнително обрани и в тази статия ще посочим тези, които са свързани с URL адресите. Според списъка с Google Ranking Factors за 2022 от Backlinko, факторите за класиране, които се отнасят до URL адреси, заемат следните позиции:
- Дължина на URL адреса. Според няколко проучвания по темата, кратките URL адреси имат леко предимство при позициониране в Google SERP.
- URL Path. Страници, които са по-близо до началната страница (Homepage), са предпочитани от Google пред тези, които са дълбоко заровени в йерархията на сайта и далечни на homepage.
Добра практика:
При онлайн магазини е препоръчително да няма вложеност при съставянето на URL адреси за продуктови страници.
Защо? Защото, в случай че един продукт присъства в повече от една категория, това е предпоставка за дублирано съдържание.
Пример:
https://site.bg/category-1/product-1
https://site.bg/category-2/product-1
Това са два различни за Google адреса, които обаче имат идентично съдържание - един и същ продукт.
- Ключова дума в URL. Както вече споменахме, от Google отричат ключовата дума в URL адреса да е кой знае какъв фактор за класиране, тъй като почти не виждаме адресите в днешно време. Но все пак е сигнал за релевантност и си остава ranking factor. Незначителен, но все пак ranking factor, нали?
- URL String. Категориите в един URL низ могат да бъдат тематичен сигнал за Google относно съдържанието на страницата.
https://drehi.bg/damski-drehi/letni-rokli
2. По-добър UX (User Experience)
Потребителите са по-склонни да кликнат върху адрес, който разбират. SEF адресите осигуряват както на хората, така и на търсещите машини, лесна и бърза за възприемане информация относно съдържанието на страницата. Чистите URL адреси са разбираеми и за най-обикновения потребител, запомнят се сравнително лесно и понякога директно ги пишем в полето за търсене.
3. Линкове (bare URLs)
Оптимизираните URL адреси могат да послужат като анкори, когато ги копираме и поставим във форуми, блог статии, публикации и коментари в социалните мрежи. Ако URL адресът не е оптимизиран, рискуваме да изглежда не особено надежден за потребителите, тъй като няма как да разберат какво е съдържанието на страницата, докато не я отворят.
Пример с публикация в LinkedIn:
На първото изображение виждаме user-friendly URL адрес и веднага разбираме какво е съдържанието на страницата, още преди да сме кликнали - SEO статии в блога на Netpeak.
Когато адресът не е оптимизиран, както е в случая на второто изображение, по-скоро е възможно да постигнем обратен ефект на желания - приятелите и колегите ни да не кликнат на този линк и да не разберат колко са готини и полезни статиите ни. :)
И не на последно място: въпреки че Google не показва URL адреси в страницата с резултати други популярни търсачки, като Bing например, все още ги показват:
Как да оптимизираме URL адреси
Стигаме и до практическата част: най-важните опорни точки и препоръки при оптимизацията на URL адреси.
Препоръчително е URL адресите да бъдат максимално опростени и логически структурирани, така че да бъдат “лесносмилаеми” за потребителя. Но как?
1. Думи > Параметри?
Когато е възможно, е препоръчително да използваме прости и описателни думи в URL адресите, вместо да се генерират ID номера или други параметри. От гледна точка на SEO, най-разумният съвет би бил да избягваме параметри и да използваме статични URL адреси. Но дали си заслужава…
Какво представляват статичните URL адреси?
Статичен URL, както името му подсказва, е URL адрес, който не се променя и не съдържа параметри. Тези адреси са сравнително по-кратки и леснозапомнящи се, защото обикновено съдържат думи вместо параметри, за разлика от динамичните адреси. Пренаписването на динамичните адреси в статични обаче е доста времеемко и сложно за изпълнение, когато информацията на сайта нараства бързо. Затова специалистите, които отговарят за по-големи онлайн магазини, блогове или форуми (сайтове с често обновяващ се голям обем от информация), понякога предпочитат да използват динамични URL адреси.
А динамичните URL адреси?
Често можем да разпознаем динамичен URL адрес по символи като: ? и &, или =. Най-големият недостатък на динамичните адреси е, че няколко различни URL адреса могат да имат подобно или дори идентично съдържание. Друг минус е, че споделени в социални мрежи, чатове и имейли, те не привличат толкова кликове, колкото би привлякъл един статичен разбираем за потребителя URL адрес, защото са… твърде дълги и пълни с параметри.
Статичен или динамичен URL адрес - кой е по-добър и защо?
Както вече споменахме, пренаписването на динамични URL адреси в статични често е сложен и дълъг процес. Освен самото “конвертиране” на адресите от единия в другия вид, трудна е и поддръжката им, в случай че базата данни нонстоп нараства и трябва да hard-code-ваме всяка нова страница на сайта. :(
Важно е да не се опитваме да скрием параметрите в URL адресите, в опити да ги направим да изглеждат статични. За да имаме статични адреси, е необходимо да имаме и статично съдържание. Ако имаме динамични адреси и голям обем от променливо съдържание, то по-безопасно от SEO гледна точка е да ги оставим динамични и да управляваме параметрите коректно.
Мит: Google не може да обхожда и индексира динамични адреси.
Ботовете разбират параметрите в динамичните URL адреси, така че индексирането и класирането на подобни адреси не е проблем. Що се отнася до пренаписването на динамични адреси от Google ни препоръчват да не пренаписваме динамичните адреси, така че да изглеждат статични, като премахваме или скриваме информация от параметрите. По-добре е да използваме статични адреси за статичното съдържание на сайта, но когато се налага употребата на динамични URL-и, то нека да оставим възможността на ботовете да използват информацията от параметрите и да я анализират.
Да разгледаме URL параметрите:
Те могат да бъдат различни видове и да служат за различни цели, като например за проследяване трафика от реклами и рекламни кампании (UTM кодове) или пък за странициране (напр. ?page=2). Необходимо е обаче да знаем как да ги управляваме, за да не се превърнат в 'таралеж в гащите' на SEO-то ни. ;)
Най-често URL параметрите могат да причинят:
- Дублирано съдържание. Ето пример за дублирано съдържание при динамични адреси:
https://site.bg/index.php?param=1¶m=2
https://site.bg/index.php?param=2¶m=1
При тези два различни URL адреса параметрите са едни и същи, но са разменени, съответно съдържанието на тези страници е еднакво (дублирано). Този проблем може да се избегне чрез употребата на статични URL адреси (ако това е възможно).
- Загуба на crawling бюджет. URL адреси с много параметри, които сочат към еднакво или идентично съдържание, затрудняват ботовете и изхабяват crawling бюджета.
- Несигурни ranking сигнали. Когато много адреси водят към идентично съдържание, търсачките са объркани кой адрес от всички да класират по определено търсене.
Session IDs
Това са уникални идентификационни номера, които се генерират от сървъра на сайта, когато даден потребител посети сайта ни за пръв път. Тези номера проследяват интеракцията на потребителя със сайта, като могат и да проследяват “пътеката” му (click-path).
Примерен URL със session ID:
https://www.sait.bg/blog/saveti-url-optimizatsia?sid=2354984855ghtfs_564981557asdf
Проблемът, който може да възникне при адреси с ID параметър (и като цяло каквито и да е параметри), е дублираното съдържание. Ако session ID номер се прибавя под формата на параметър към адреса на определена страница, Googlebot ще получава нов ID номер всеки път, когато нов потребител достъпи страницата. Но всички тези версии на съответната страница имат едно и също съдържание… Което си е red flag за Google. ;)
Какво можем да направим в такъв случай? Ако Content Management (CMS) системата на сайта ни използва ID параметри в URL, то е препоръчително да настроим rel=canonical от всяка страница, която използва ID параметър, към основната версия на страницата - без параметър, например:
<link rel="canonical" href="https://sait.bg/blog/saveti-url-optimizatsia">вместо
<link rel="canonical" href="https://sait.bg/blog/saveti-url-optimizatsia?sid=235984855ghtfs_564981557asdf">2. URL адресите - на латиница!
Необходимо е URL адресите да бъдат изписани на латиница. За адреси на кирилица се използват правила за транслитерация:
а = a | e = e | к = k | п = p | ф = f | щ = sht |
б = b | ж = zh | л = l | р = r | х = h | ъ = а |
в = v | з = z | м = m | с = s | ц = ts | ь = y |
г = g | и = i | н = n | т = t | ч = ch | ю = yu |
д = d | й = y | o = o | у = u | ш = sh | я = ya |
Според препоръките на Google за адресите трябва да използваме UTF-8 (Unicode Transformation Format) - това е стандарт за символно кодиране, чиито първи 128 символа са идентични на тези в ASCII стандарта (American Standard Code for Information Interchange), съответно всеки валиден ASCII текст е и UTF-8 валиден.
ASCII е първият стандарт за кодиране, който е използван при обмяна на информация в Интернет, и е базиран на латинската азбука.
URL адреси могат да се споделят в уеб пространството само ако са “преведени” на ASCII.
В случай че URL адресът съдържа символи, които не са част от ASCII стандарта, то те трябва да бъдат превърнати в съответния формат чрез URL кодиране. Обикновено тези символи биват заменени от знак за процент (%), следван от два символа от Шестнадесетичната бройна система, която се състои от арабските цифри от 0 до 9 и латинските букви от A до F. Освен това, адресите не може да съдържат интервали - те биват заменени със знак за плюс (+) или с %20.
Ето например как ще изглежда следната комбинация от символи на кирилица:
здравей
в ASCII формат:
%D0%B7%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9
В действителност адреси, съдържащи символи на кирилица, се класират успешно - можем да вземем за пример страниците на български език в Уикипедия. Проблемът е, че при споделяне в уеб пространството, напр. когато paste-нем URL адрес с кирилица в публикацията си или в лично съобщение, той се превръща в дълга редица от символи, абсолютно непонятна за човешкия мозък.
3. Lowercase
https://sait.bg/blog/Saveti-URL-Optimizatsia
или
https://sait.bg/blog/saveti-url-optimizatsia
Почти всички сървъри в днешно време третират малките букви (lowercase) и главните букви (uppercase) по един и същи начин в URL. Все пак обаче някои сървъри биха могли да ни върнат отговор 404 или пък да счетат двата адреса за отделни страници и да си отгледаме дублирано съдържание. По-добре да си спестим главоболията и да избягваме главните букви в URL адреси.
4. Тиретата в U-R-L
Всички пунктуационни знаци и интервали, освен буквите и цифрите, в URL адреса трябва да бъдат заменени от единичен знак за тире (-).
- В случай че се получат две или повече тирета подред, те трябва да бъдат заменени от едно тире;
- Ако се случи така, че да присъстват тирета в началото или в края на адреса, те трябва да се премахнат.
Ако имаме няколко поредни думи в URL адреса, то е препоръчително да ги разделим с тирета, вместо да ги слеем, с цел по-лесно разбиране от страна на потребителите.
Например:
https://drehi.bg/p-lyatna-roklya-na-sini-tochki
5. Слеш в края на URL/
През 2017 г. John Mueller коментира значението на наклонената черта (/) в края на URL адресите. Наличието на слеш след root домейна в URL не обособява различни адреси. Навсякъде другаде обаче наклонената черта играе своята роля (напр. след “пътека” или файл в края на адреса). В HTML слешът служи да индикира наличието на директория или категория.
Пример:
https://www.sait.bg = https://www.sait.bg/
но
https://www.sait.bg/neshto ≠ https://www.sait.bg/neshto/
I noticed there was some confusion around trailing slashes on URLs, so I hope this helps. tl;dr: slash on root/hostname=doesn't matter; slash elsewhere=does matter (they're different URLs) pic.twitter.com/qjKebMa8V8
— 🐝 johnmu.rss?utm_medium=large (personal) 🐝 (@JohnMu) December 19, 2017
Тъй като от Google не ни дават ясна препоръка дали да използваме слеш в края на URL или не, съветът, който можем да дадем е да изберете един от двата варианта и да се придържате към него.
6. Дати в адресите
Преди употребата на дати в URL адресите е била автоматична при някои CMS (като WordPress, например). В днешно време датите в URL са сравнително по-рядко срещани и от SEO гледище - излишни, тъй като единствено удължават URL адреса без да ни носят полза.p>
7. Геотаргетиране в URL
Ако уебсайтът ни оперира в няколко региона е препоръчително да използваме URL структура, която улеснява геотаргетирането. Имаме три опции:
- ccTLD;
https://sait.bg
Предимството на ccTLD е чистото геотаргетиране и лесното разделяне на уебсайтовете ни за различните държави.
- Поддомейн за държава;
https://bg.sait.com
Регионалните поддомейни и поддиректории се настройват сравнително лесно, за разлика от ccTLD, които са най-скъпият вариант и при които има доста изисквания понякога.
- Поддиректория за държава.
https://sait.com/bg
Поддиректориите са обикновено най-лесни за поддръжка, но пък езиковите версии на сайта ни трудно се различават една от друга.
HTTPS > HTTP
HTTPS (или HTTP over TLS) удостоверява защитата сайта и на сървъра, на който е качен. Още през 2014г. от Google констатират колко са важни безопасността и User Experience на сайта ни. Така наличието на HTTP over TLS се превръща в още един ranking фактор, защото гарантира сигурност при обмяната на данни между потребител и сървър.
Със сигурност това е не е shortcut към ТОП 3 на страницата с резултати (особено ако поначало сайтът ни не се класира на първа страница). Google препоръчва https:// пред http://, а и потребителите са по-склонни да се доверяват на сайтове с HTTPS протокол.
Заключение
Потребителите са движещата сила в Уеб пространството и поради тази причина главната препоръка на Google, що се отнася до оптимизацията на URL адреси, е да оптимизираме за хората. Добре е URL адресите ни да бъдат максимално кратки и разбираеми за потребителя, с ясна структура и да не съдържат излишни параметри. Разбира се, ако всичко това е постижимо и би ни донесло повече ползи, отколкото негативи.
Би било твърде просто, ако няма поне едно но. Важно е преди внедряване на SEF адреси, да оценим обективно възможностите на Content Management (CMS) системата на уебсайта ни. Добре е да оптимизираме URL адресите, ако CMS системата го позволява. В противен случай вместо да доведе до положителни резултати, внедряването на user-friendly адреси би могло да предизвика натоварване на сървъра и да забави сайта.
44
10
10
8
16