Създайте идеалния URL адрес

Тази статия се появи за първи път в брой 215 на .net magazine - най-продаваното списание за уеб дизайнери и разработчици.

Дизайнът на URL наскоро отново стана тема на дискусии през последната година. Започна с редизайна на Twitter от есента на 2010 г., който изглежда утвърди това, което обикновено се смяташе за лоша техника на уеб дизайн за публични уеб сайтове: URL адресът „hash-bang“.



Това са URL адреси, които непосредствено след самия домейн започват с „#!“ Или „£!“ - например, twitter.com/kurafire става twitter.com/#!/kurafire . След това частта от URL адреса, която уникално идентифицира съдържанието на страницата, се добавя в края. Тази техника е насочена към подобряване на производителността - тя по същество има за цел да не презарежда цяла страница, когато трябва да презаредите само малко парче от нея. Но това не идва без сериозни недостатъци.



Този урок ще разгледа по-фините подробности за дизайна на URL адресите и ще обясни защо хеш-бретонът трябва да бъде обезкуражен. Но първо да разгледаме основите.

Какво е URL?

Терминът URL означава Uniform Resource Locator и указва местоположението на определен ресурс, например уеб страница. Тъй като местоположението е идентификация на място, всеки URL адрес също е URI или унифициран идентификатор на ресурс.



URL адресът обаче определя не само местоположението на URI, но и метода за достъп до него - схемата или протокола. Синтаксисът на URL е както следва:

схема: // домейн / път? query_string # fragment_identifier

Тук ще се съсредоточим върху уеб адресите, които използват HTTP протокола, и ще игнорираме неща като MAILTO, FTP или FILE, както и портове, вградени потребителски имена и пароли. HTTPS адресът е същият като всеки обикновен HTTP URL адрес, с добавеното изискване да използва защитена връзка.



Синтаксисът на URL адрес, разделен на съставните му части. URL адресът определя местоположението на определен ресурс, който може да включва уеб страници. В този урок ние

Синтаксисът на URL адрес, разделен на съставните му части. URL адресът определя местоположението на определен ресурс, който може да включва уеб страници. В този урок ние се концентрираме върху уеб адресите, които използват HTTP протокола

Домейн

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

Път

Пътят е една от най-важните части от дизайна на URL и трябва да бъде създаден като структура на папката, използвайки наклонени черти, независимо от настройката на вашия сървър. Всяка уникална страница на вашия уебсайт или уеб приложение трябва да има свой собствен уникален път.

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

Дръжте пътеките си възможно най-кратки. / about-this-company е ненужно дълъг; / за ще направи. Четените фрази като yourname.com/wrote/some-blog-post или yourname.com/works-for/a-cool-company могат да добавят приятен щрих, но за предпочитане е да запазите краткост.

Низове за заявки

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

В миналото много сървърни системи са използвали неправилно параметрите на низовете за заявки, за да обслужват различни страници на даден сайт, като somesite.com/index.php?p=about. Други сайтове отидоха една стъпка твърде далеч в правилната посока и пренаписаха низовете на заявките за търсене като път до нещо, наподобяващо това: / q / My% 20search% 20 query / sortby / date / order / desc /.

И двата подхода са лоши практики, които препоръчвам да избягвате. Най-важното е, че низът на заявката трябва да се третира като незадължително допълнение към страницата; URL адресът трябва да работи, за да създаде валидна и полезна страница, дори когато е премахнат. Пагинацията е валидно използване на низ за заявка за страници с променящ се поток на съдържание.

Идентификатори на фрагменти

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

Браузърите могат да навигират между множество идентификатори на фрагменти, без да презареждат страницата и именно този механизъм хората са избрали да злоупотребяват, за да накарат цели сайтове да работят без никакви презареждания на страници между навигацията (новата twitter.com , например).

Тъй като това е желателно потребителско изживяване, доставчиците на браузъри създадоха API за история на HTML5, който е подходяща (макар и съвсем нова) техника за навигация из сайтове, без да задейства презареждане на страници или злоупотреба с идентификатори на фрагменти.

За подробни инструкции как да използвате API на HTML5 History препоръчвам „ Манипулиране на историята ’Глава от онлайн книгата на Марк Пилигрим„ Потопете се в HTML5 “.

За ясна и кратка анатомия на уеб адрес, има

За ясна и кратка анатомия на уеб адрес има отлична статия на сайта на Doepud Web Design

Нарушаване на споразумението

Всяка комбинация от компоненти на URL представлява тихо споразумение: този конкретен URL ще върне уникален ресурс или обект от данни, като по желание се позовава на конкретен подраздел в този ресурс.

Тъй като идентификаторите на фрагменти не се изпращат до сървъра, може да се твърди, че URL адресите с хеш-взрив не са технически валидни.

Позовавайки се на Страница в Уикипедия на URL адреси : „При изчисленията унифициран локатор на ресурси (URL) е унифициран идентификатор на ресурс (URI), който определя къде е наличен идентифициран ресурс и механизма за неговото извличане.“ URL адресът, базиран на хеш-взрив, недостатъчно указва механизма за извличане на съдържанието, тъй като изисква JavaScript двупосочно пътуване до сървъра, след като сървърът вече е изпратил на браузъра HTML страница - страница, която няма съдържанието, свързано с поискан URL адрес (все още).

Казано по друг начин, хеш-бретонът променя механизма за извличане на ресурс. Вече не се дефинира просто и единствено от схемата на URL, а от „напълно функциониращ JavaScript, както се определя и доставя от сървъра и се интерпретира от JavaScript процесор на ниво браузър“.

Всичко това може да изглежда педантично, но значението става ясно, когато вземете предвид реалността на начина, по който се осъществява достъпът до ресурси. Браузърът, който зарежда URL адрес, очевидно е най-често срещаният начин за зареждане на уеб страница, но не е единственият метод. Всеки прост опит за изтегляне на съдържание от мрежата, базиран на wget или curl, вече няма да работи и всеки софтуер, който зарежда уеб съдържание, сега трябва да включва пълен анализатор на JavaScript, за да поддържа такива URL адреси. И това е всичко, ако се предположи, че JavaScript не се филтрира от някакъв прокси сървър или защитна стена и не съдържа никакви грешки никъде на страницата. Когато потребителите изключат JavaScript в браузъра си, тези сайтове ще спрат да работят.

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

Там

В AppStorm има отлично обобщение на проблема с хеш-взрива

Лоши практики

Има много различни начини за проектиране на вашите URL адреси. Основите по-горе са чудесни техники, но трябва да знаем какво прави лошият дизайн на URL адреси, за да разберем напълно и да оценим какво прави добрия дизайн на URL адресите добър. Ето някои практики, които трябва да се избягват, като се започне с най-лошите нарушители и се стигне до методи, които са просто неразумни:

Хешове за идентификация на страници

Някои (предимно древни) системи за управление на съдържанието или блогови двигатели идентифицират всяка уникална страница с дълъг низ от произволни знаци; нещо подобно: 5F0C866C-6DDF-4A9A-9515-531B0CA0C29C.html. Ако вашата система за управление на съдържанието или двигателят на сайта генерира такива URL адреси, разберете как незабавно да презапишете или изключите това поведение; ако това не е възможно, наистина е по-добре да получите по-модерна CMS. Има само недостатъци на тези URL адреси - за вашите потребители и за вас самите - и безброй добри, модерни системи, които могат да захранват вашия сайт, които избягват тази ужасна техника.

Хешове на сесията

Въпреки че не е толкова лош, колкото когато се използва за страници, хешовете, използвани за сесии на вашия сайт, все още са лоши.

Като начало те могат да повлияят отрицателно на SEO. Но по-голямото притеснение е, че повечето системи, които ги използват, използват SHA-1, който е относително несигурен - със сигурност за потребителски сесии или влизания, съдържащи някакви чувствителни данни.

Файлови разширения

Вашите URL адреси не трябва да съдържат .php, .aspx и т.н. Файловите разширения не са съвместими с напред, така че ако промените бекенд системи и всичките ви URL адреси съдържат .aspx, ще бъдете принудени да правите пренаписване от страна на сървъра за всяка отделна страница на вашия сайт. Скъпо, неефективно и напълно ненужно. Разширението .html също не се препоръчва, но ако сте уверени, че някога ще обслужвате страниците, които изграждате, само като статични файлове, това е приемлива техника.

Не-ASCII знаци

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

шрифт с символи на ръкопис

Подчертаване

Те имат по-лоша използваемост и SEO стойност и нямат осезаеми ползи за тиретата.

Плънка с ключови думи

Добавянето на множество ключови думи към URL адресите може да помогне при SEO, но ще обърка потребителите ви. Освен това бързо ще рискувате да бъдете маркирани като спамер на ключови думи.

В

В „Стария Twitter“ целият този туит присъства два пъти: веднъж в съдържанието като описание и веднъж на страницата. Въпреки това...

... новият Twitter изобщо не съдържа туит и е с размер 44 килобайта. Тази страница трябва да се изпълни в среда за JS-парсинг, за да зареди чуруликането или то

... новият Twitter изобщо не съдържа туит и е с размер 44 килобайта. Тази страница трябва да се изпълни в среда за JS-синтактичен анализ, за ​​да зареди чуруликането, или не може да бъде извлечена

Добри практики

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

„Готините URI не се променят“, както Тим Бърнърс-Лий каза още през 1998 г., но освен че ги поддържа постоянно за редизайн, какво друго прави страхотни адреси? Някои ключови съображения са стабилността, хакерството и пространството на имена.

Здраво картографиране на URL адреси

Хората ще споделят URL адресите ви и понякога ще го правят в среда, където средата на получателите може да обгърне URL адреса в два реда. Това е най-често при публикации в блогове, които включват пълна дата и дълго заглавие в URL адреса.

Едно от решенията е да запазите всичките си URL адреси по-къси от 70 знака, но това не винаги е идеално. Освен това естеството на релационните системи от бази данни е такова, че ID стойностите се търсят бързо, но низовете не са.

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

Здравото картографиране на URL адреси може да реши и двата проблема за вас. Чрез вграждане на уникален идентификатор в началото на пътя си, можете да имате дълги, напълно описателни URL адреси, когато е необходимо, но въпреки това да се наслаждавате на надеждността на по-кратки URL адреси и скоростта на търсенето на идентификатори.

Вземете този URL: yourdomain.com/news/1982-this-is-a-longer-news-posts-title-, който-почти-със сигурност-би се разбил-на-нова-линия-в-някои- клиенти. В този пример ‘1982’ е стойността на идентификатора на записа в базата данни за тази конкретна публикация. След това вашата CMS може да използва само тази част от URL адреса, за да направи успешно търсене: yourdomain.com/news/1982.

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

Единственият недостатък на тази техника е, че самите идентификатори не са толкова удобни за хората, така че това е компромис, който трябва да се вземе предвид.

Прозорливи URL адреси

В добър, хакнат URL адрес, човек може да коригира или премахне части от пътя и да получи очаквани резултати от вашия сайт. Те дават на посетителите Ви по-добра ориентация около страниците Ви и им позволяват лесно да се придвижват нагоре по нива. Пример е: yourdomain.com/blog/2011/05/20/some-article. Намаляването на това до всяка наклонена черта напред трябва да доведе до очаквани резултати. Например вашият домейн.com/blog/2011/05/20/ трябва да върне всички публикации, публикувани на 20 май 2011 г. yourdomain.com/blog/2011/05/ ще даде преглед на публикациите от май 2011 г., докато yourdomain.com/blog / 2011 / може да се използва за представяне на общ преглед на публикациите за 2011 г., или, ако това е твърде подробно, просто публикуване на суми за всеки месец. yourdomain.com/blog/ трябва да връща най-новите актуализации, независимо от действителната им дата на публикуване.

Колко подробно трябва да бъдете при проектирането на такива URL адреси, всъщност зависи от съдържанието и аудиторията на сайта. Колкото по-актуално е съдържанието, толкова повече се възползва от датите на публикуване в URL; колкото по-често се публикува ново съдържание, толкова повече се възползва от по-фината детайлност.

Други области - като категории, продукти и услуги - не се нуждаят от компоненти за дата, но без значение колко подробни (или не) са URL адресите ви, в крайна сметка те трябва да бъдат напълно хакерски.

Грешка е да се твърди, че хакерските URL адреси се използват само от технически интелигентни посетители и ги отхвърляте, ако аудиторията ви не е в тази ниша. Първо, потребителите ще получат повече технологично разбиране с течение на времето, не по-малко. Но по-важното е, че не познавате всеки свой посетител, настоящ и бъдещ.

Пространства от имена

Разделът от най-високо ниво на пътя е най-ценният недвижим имот в URL. Ако вашият сайт позволява на потребителите да се регистрират и да имат свой собствен профил на това ниво, трябва да създадете черен списък с потребителски имена, съдържащ всички текущи и възможни бъдещи функции, които може да искате да имате. Можете да намерите някои чудесни примерни списъци на Quora за това.

Функции за пространство на имена зад потребителското име: списъците или / последователите са чудесни решения за публични функции, които принадлежат на всеки потребител поотделно.

Частните неща, като например настройките на акаунта, никога не трябва да се разполагат с имена зад потребителското име и трябва просто да се показват след / акаунт или / настройки. Също така, не смесвайте и съчетавайте техники тук. Ако започнете да поставяте някои функции под / функция /, а други под / функция, само ще объркате потребителите си.

Ако започнете даден сайт като блог, но очаквате да го изградите повече в бъдеще, помислете дали да добавите всички публикации под / blog / като пространство от имена на най-високо ниво, за да избегнете потенциални конфликти по-късно.

Quora има няколко чудесни съвета за предотвратяване на регистрациите на вашето потребителско име

Quora има няколко чудесни съвета за предотвратяване на регистрациите на потребителско име от „кражба“ на ценни ключови думи за URL адреси

Бизнес казусът

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

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

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