SEO для вэб-сайтаў ASP.NET: URL

1. Уніфікаваны лакатар рэсурсаў
2. SEO і зручныя URL-адрасы
3. Дружалюбныя адрасы і маршрутызацыя
4. Маршрут
5. Смаўжы
6. Кананічныя URL-адрас
7. Перанакіраванне не-www на URL URL
8. рэзюмэ

Гэта другі артыкул у серыі артыкулаў, у якім разглядаюцца спосабы аптымізацыі вэб-сайтаў ASP.NET для пошукавых сістэм. Кожны артыкул у серыі канцэнтруецца на канкрэтнай тэме і разглядае магчымасці і інструменты, даступныя распрацоўнікам ASP.NET, каб зрабіць сайты пошуку дружалюбнымі і, такім чынам, палепшыць рэйтынг і праглядаць вынікі пошуку. У гэтым артыкуле будуць разгледжаны некаторыя лепшыя практыкі, якія тычацца URL-адрасоў вашага сайта і як зрабіць іх больш зручнымі для карыстальнікаў для пошукавых сістэм і людзей.

Поўная серыя артыкулаў складаецца з

Уніфікаваны лакатар рэсурсаў

URL (альбо Uniform Locator Resource) для любой дадзенай старонкі паказвае адрас, дзе ён знаходзіцца, і механізм (пратакол), па якім можна атрымаць. Для вэб-старонак пратакол будзе http або https у большасці выпадкаў. Звычайна за ім ідуць дамен, а затым унікальны ідэнтыфікатар некаторага апісання. У ідэале URL павінен апісваць змест і ўключаць ключавыя словы, якія таксама прысутнічаюць у назве старонкі, апісанні і змесце.

У папярэдняй версіі майго сайта URL для гэтага артыкула быў бы

http://www.mikesdotnetting.com/article.aspx?id=290

Гэта не дае ніякага паняцця чалавеку пра змест рэсурсу і, такім чынам, не з'яўляецца апісальным. Ён таксама не дапамагае ні пошукавым рухавікам разумець, дзе старонка змяшчаецца ў Інтэрнэце, так і ў іншых трох крыніцах інфармацыі для пошукавай сістэмы: больш назвы, апісання і зместу. У наш час URL-адрасы нашмат лепш з пункту гледжання SEO:

http://www.mikesdotnetting.com/article/290/seo-for-asp-net-web-sites-urls

Кожнаму, хто чытае толькі URL, павінна быць відавочна, што змест гэтай старонкі, хутчэй за ўсё, ахоплівае.

SEO і зручныя URL-адрасы

Схема URL для папярэдняй версіі майго сайта была абумоўлена тым, што старыя версіі вэб-формаў абапіраліся на адрасы, якія адпавядаюць назве і шляху фізічных файлаў. Любыя дынамічныя значэнні, такія як ідэнтыфікатар, для якога варта адлюстроўваць артыкул, перадаюцца ў якасці параметраў радка запыту. Можна было б перадаць назву артыкула ў якасці параметра радка запыту. Аднак савет пошукавых сістэм заключаецца ў тым, каб пазбегнуць радкоў запытаў, калі гэта магчыма, і дзе іх немагчыма пазбягаць, захоўваць іх вельмі мала і каротка.

Калі ў ASP.NET 3.5 (SP1) была ўведзена дынамічная дата, была ўведзена новая сістэма маршрутызацыі, якая дазваляе распрацоўшчыку адлюстроўваць адвольныя шаблоны URL-файлаў з фізічнымі файламі. Гэта было прынята для выкарыстання ў рамках MVC, які выйшаў прыкладна ў той жа час - хоць і ў выпадку з MVC, URL-адрасы супастаўляюцца з метадамі дзеянняў кантролераў па канвенцыі.

Дружалюбныя адрасы і маршрутызацыя

Вэб-формы па-ранейшаму працуюць на аснове адлюстравання URL-адрасоў з фізічнымі файламі, але таксама ўключае ў сябе новую сістэму для стварэння і працы з дружалюбнымі URL-адрасамі - ahem - " Дружалюбныя адрасы ". Ён заснаваны на той жа парадыгме, што і" сістэма маршрутызацыі па змаўчанні, якая ўваходзіць у склад рамкі вэб-старонак Razor , Усталёўка па змаўчанні будзе супадаць з URL-адрасам з фізічным файлам без пашырэння файла ў URL-адрасы, а таксама для адвольных частак дадзеных, якія будуць перададзены ў URL у якасці дадатковых сегментаў. Іншымі словамі, гэта сістэма, заснаваная на канвенцыях, якая залежыць ад таго ці іншага URL, які адпавядае шляху віртуальнага файла для вэб-формы (.aspx-файл). Дружалюбныя URL-адрасы даступныя ў выглядзе пакета Nuget (Microsoft.AspNet.FriendlyUrls) і папярэдне ўстаноўлены і ўключаны як частка стандартнага шаблона праекта Web Forms.

У якасці прыкладу URL адрасу http: // localhost: 1234 / article / 101 / seo-for-asp-net-web-sites-URL-адрасы, наступны код паказвае, як атрымаць значэнні з сегментаў, выкарыстоўваючы пакет Friendly URLs у Article.aspx. , а затым прызначыць іх літаральным элементам кіравання, якія называюцца ID і Headline, і як стварыць гіперспасылку з дапамогай элемента кіравання HyperLink:

абароненая несапраўдная старонка Page_Load (адпраўнік аб'екта, EventArgs е) {var сегменты = Request.GetFriendlyUrlSegments (); if (segments.Any ()) {ID.Text = "ID:" + сегменты [0]; Headline.Text = "Загаловак:" + сегменты [1]; Link.Text = Link.NavigateUrl = FriendlyUrl .Href ("~ / артыкул", сегменты [0], сегменты [1]); }}

Метад GetFriendlyUrlSegments - гэта метад пашырэння, які знаходзіцца ў Microsoft.AspNet.FriendlyUrls, таму вам таксама спатрэбіцца дырэктыва, якая выкарыстоўваецца ў верхняй частцы файла, каб прывесці прастору імёнаў у сферу. Метад вяртае aList <string>, які змяшчае значэнні ў любых сегментах пасля імя файла. Дапаможны метад FriendlyUrl.Href стварае URL з віртуальнага шляху і прадстаўленых значэнняў сегмента. Гэта прысвойваецца як уласцівасцям Text, так і NavigateUrl элемента кіравання Hyperlink.

Дружалюбныя URL-адрасы - гэта вельмі простая сістэма для выкарыстання ў сайтах вэб-формаў, дзе выкарыстоўваюцца адносна простыя схемы URL-адрасоў, і дапушчальная сувязь паміж URL-адрасам і імем файла без пашырэння. Для ўсяго іншага, маршрутызацыя, як правіла, рэкамендуецца.

Маршрут

Маршрутызацыя працуе крыху па-іншаму, у залежнасці ад распрацоўкі сайта вэб-формаў або сайта MVC. У прынцыпе, у абодвух ёсць адна і тая ж падстава: пры запуску прыкладання вы адлюстроўваеце URL-адрасы рэсурсаў, а ўваходныя запыты правяраюцца на карце (ці табліцы маршрутаў), каб даведацца, куды яны павінны быць накіраваны. Аднак на вэб-сайце ўсе ўваходныя URL-адрасы павінны супаставіць з фізічнымі файламі. Паколькі на вэб-серверы не існуе меркаванай сувязі паміж змесцівам URL і файлавай сістэмай, кожны URL павінен быць настроены. Можна выкарыстоўваць як дружалюбныя URL-адрасы, так і маршрутызацыю на адным і тым жа сайце, таму гэта можа зрабіць працу канфігурацыі значна прасцей, калі большасць URL-адрасоў сапраўды адпавядаюць імя файла без пашырэння. У наступным раздзеле кода паказаны клас RouteConfig па змаўчанні, знойдзены ў тэчцы App_Start у шаблоне вэб-формаў:

адкрыты статычны клас RouteConfig {public static void RegisterRoutes (RouteCollection маршруты) {var settings = new FriendlyUrlSettings (); settings.AutoRedirectMode = RedirectMode .Permanent; маршруты.EnableFriendlyUrls (налады); routes.MapPageRoute ("", "test / {id}", "~ / mytest.aspx"); }}

Першыя тры радкі кода ў метадзе RegisterRoutes дазваляюць дружалюбныя URL-адрасы і паказваюць, што па змаўчанні запыты, напрыклад, http://domain.com/contact.aspx прыводзяць да коду стану 301 Перамяшчаецца пастаянна і размяшчэння http: //. domain.com/contact (без пашырэння).

Апошняя радок кода з выкарыстаннем маршрутызацыі для адлюстравання запытаў на http://domain.com/test/xxx на mytest.aspx . Ххх можа быць любым значэннем, але ён павінен прысутнічаць на шляху да працы. Вы можаце зрабіць гэта часткай URL неабавязковым, альбо вы можаце абмежаваць значэнне для пэўнага шаблона, выкарыстоўваючы рэгулярныя выразы. Вы можаце даведацца больш пра тое, як гэта зрабіць Агляд MSDN маршрутызацыі ASP.NET ,

Дружалюбныя URL-адрасы заўсёды выйграюць у выпадку запісу маршрутызацыі, які адпавядае шляху віртуальнага файла для файла .aspx на серверы. Напрыклад, калі хто-то павінен дадаць файл з назвай Test.aspx у каранёвую тэчку сайта ў прыведзеным вышэй прыкладзе, Friendly URL-адрасы будуць клапаціцца пра прамое супадзенне паміж URL-файлам і файлавай сістэмай, і запіс у маршрутызацыі ніколі не будзе. выклікаецца.

На сайце MVC маршрутызацыя - адзіная сістэма адлюстравання URL-адрасоў да рэсурсаў, таму што няма файлаў для адлюстравання. Для большасці сайтаў вам ніколі не трэба выходзіць за рамкі адзінага маршруту, які вызначаецца па змаўчанні:

публічнае статычнае пустэч RegisterRoutes (RouteCollection маршруты) {routes.IgnoreRoute ("{рэсурс} .axd / {* pathInfo}"); routes.MapRoute (імя: "Па змаўчанні", url: "{controller} / {action} / {id}", па змаўчанні: новы {controller = "Home", дзеянне = "Index", id = UrlParameter .Optional}); }

Гэта вызначэнне маршрута паказвае, што першы сегмент URL змяшчае імя кантролера, другі змяшчае імя метаду Дзеянне, трэці сегмент не з'яўляецца абавязковым, але калі ён запаўняецца, яго можна супаставіць з параметрам з імем id. Значэннем па змаўчанні для сегмента кантролера з'яўляецца Home, а па змаўчанні для сегмента дзеянняў - індэкс.

Калі вы хочаце генераваць URL-адрасы для выкарыстання ў атрыбутах anchor href ці image src або аналагічных у MVC 5 або больш ранніх версій, у вас ёсць шэраг дапаможных спосабаў: ActionLink , RouteLink і UrlHelper's Метады дзеянняў і маршруту. У MVC вы таксама можаце выкарыстоўваць новы Якар TagHelper ., дзе дзеянне і кантролер задаюцца ў якасці спецыяльных аспектаў элементаў HTML:

<a asp-action = "Index" asp-controller = "Home"> Назад дадому </ a>

Смаўжы

Slug - гэта тэрмін, які часта выкарыстоўваецца для апісання чытальнай часткай URL-адрасы. На маім сайце я выкарыстоўваю загаловак артыкула ў якасці слюза, і таму старанна выбіраю загалоўкі артыкулаў, каб яны ўтрымлівалі адпаведныя ключавыя словы. Я таксама паўторна выкарыстоўваю назву артыкула як загаловак старонкі і змест загалоўка h1, каб ключавыя словы знаходзіліся паслядоўна на ўсёй старонцы. Форумы ASP.NET і Перапаўненне стэка выкарыстоўваць фармулёўку апублікаванага пытання ў якасці кулі. Аднак яны выкарыстоўваюць розныя падзелы слоў: форумы ASP.NET выкарыстоўваюць знак плюс (+) паміж словамі, у той час як Stackoverflow выкарыстоўвае злучкі (-). Людзі ў Google рэкамендуюць выкарыстоўваць злучкі.

Пытанне, якое ўзнікае даволі часта, заключаецца ў тым, як стварыць кулі, які бяспечна ўлічвае пунктуацыі і іншыя зарэзерваваныя сімвалы. Хлопцы ў Stackoverflow ёсць размясціў метад генерацыі кулі яны выкарыстоўваюць. Я выкарыстоўваю варыянт алгарытму, які мае мяжа 80 сімвалаў, якія яны выкарыстоўваюць выдаленыя. Шматлікія эксперты SEO рэкамендуюць захоўваць URL-адрасы максімум 75-80 знакаў, паколькі гэта максімальная колькасць знакаў, якія будуць паказаны запісы ў SERP. Тым не менш, Google, у прыватнасці, імкнецца скарачаць URL-адрасы для адлюстравання, каб вылучыць адпаведныя ключавыя словы, замяняючы неэфектыўныя сегменты эліпсамі. Ад Google не рэкамендуецца ўсталяваць максімальную даўжыню для URL, таму здаецца, што яны сапраўды не турбуюцца.

Кананічныя URL-адрас

Павінна быць толькі адзін сапраўдны URL для кожнага рэсурсу. Гэта вядома як кананічны URL. Небяспека таго, што некалькі адрасоў, якія паказваюць на адзін і той жа рэсурс, складаецца ў тым, што рэйтынг для любой старонкі будзе разведзены па розных URL. Наступныя URL-адрасы могуць выглядаць аднолькава:

http://www.mikesdotnetting.com/article/290/seo-for-asp-net-web-sites-urls http://mikesdotnetting.com/article/290/seo-for-asp-net-web-sites -urls http://www.mikesdotnetting.com/article/290/Seo-For-Asp-Net-Web-Sites-URLs

Сапраўды, усе яны будуць прыводзіць да таго, што змесціва будзе здабывацца з базы дадзеных і аднаго і таго ж зыходнага кода на выніковай старонцы (прынамсі, на маім сайце ...). Але ўсе яны адрозніваюцца ад пункту гледжання SEO - нават з розным корпусам. Па гэтай прычыне вы павінны адпавядаць URL-адрасам, якія вы выкарыстоўваеце ў вашай навігацыі і іншых спасылках на месцы.

Нягледзячы на ​​ўсе намаганні, каб справіцца з гэтым у сваім уласным кодзе, ёсць і іншыя спосабы, па якіх SEO вашай старонкі можа быць фрагментаваным у выніку некалькіх URL-адрасоў, якія паказваюць на той жа рэсурс. Вы не можаце пазбегнуць магчымасці іншых людзей ствараць змены вашых URL-адрасоў пры звароце да вас са свайго сайта, форумаў або сацыяльных медыя і г.д. Па гэтай прычыне вам рэкамендуецца выкарыстоўваць элемент спасылкі HTML на кожнай старонцы для інфармавання пошукавых сістэм. які кананічны URL для гэтай канкрэтнай старонкі:

<link rel = "canonical" href = "http://www.mikesdotnetting.com/article/290/seo-for-asp-net-web-sites-urls" />

Перанакіраванне не-www на URL URL

Большасць даменаў усталяваны з @ запісам, які паказвае іх дамен у чыстай форме (напрыклад, domain.com) на IP-адрас іх вэб-сервера і запіс CNAME, які паказвае www.domain.com на @ запіс. Затым як domain.com, так і www.domain.com дадаюцца як прывязкі да сайта ў IIS. Гэта карысна для тых наведвальнікаў, якія ўводзяць вэб-адрас без прэфікса www. Гэта гарантуе, што запыт будзе адпраўлены на правільны сервер. Як я ўжо казаў, гэта прыводзіць да двух сапраўдных URL-адрасоў для таго ж зместу, і ў той час як гэтае пытанне можа быць вырашана пры дапамозе rel = "canonical", вы таксама можаце выкарыстаць перанакіраванне HTTP, калі ваш сервер IIS мае URL перапісаць усталяваны. Вам нават не патрэбны доступ да вэб-сервера, каб усталяваць правіла перазапісу. Вы можаце зрабіць гэта на web.config вашага сайта.

<system.webServer> <перапісаць> <rules> <rule name = "Перанакіраваць не-www-трафік на www" stopProcessing = "true"> <match url = ". *" ignoreCase = "true" /> <умовы> <дадаць input = "{HTTP_HOST}" pattern = "^ mikesdotnetting.com $" /> </ conditions> <action type = "Redirect" url = "http://www.mikesdotnetting.com/{R:0}" redirectType = "Permanent" /> </ rule> </ rules> </ перапісаць> </ system.webServer>

Гэта правіла перазапісу ахоплівае запыты на любы URL-адрас, які адпавядае шаблону. Ён будзе разглядаць асноўную частку URL, і калі не пачынаецца з "www". сервер адказвае 301 - Код стану перамяшчэння пастаянна і новае месца з папярэднім WWW.

рэзюмэ

Гэты артыкул ахоплівае ролю, якую адыгрываюць URL-адрасы ў пошукавай аптымізацыі. Ён разглядаў важнасць таго, каб мець зручныя URL-адрасы для карыстальнікаў і SEO, і як іх ствараць і працаваць з імі як у ASP.NET Web Forms, так і ў MVC-прыкладаннях. Нарэшце, былі растлумачаныя кананічныя URL-адрасы, і апісаны стратэгіі кіравання імі.

У наступным артыкуле я разгледзім, як можна кіраваць змесцівам, які індэксуе пошукавыя сістэмы на вашым сайце.