SEO для веб-сайтів ASP.NET: URL-адреси

1. Єдині локатори ресурсів
2. SEO та зручні URL-адреси
3. Дружні URL-адреси та маршрутизація
4. Маршрутизація
5. Слимаки
6. Канонічні URL-адреси
7. Перенаправлення без www до www URLS
8. Резюме

Це друга у серії статей, в яких досліджується оптимізація веб-сайтів ASP.NET для пошукових систем. Кожна стаття в серії концентрується на певній темі і розглядає функції та інструменти, доступні розробникам ASP.NET, щоб допомогти зробити сайти пошуковими системами дружніми і тим самим підвищити рейтинги та перейти до результатів пошуку. У цій статті буде розглянуто деякі найкращі практики, що стосуються URL-адрес вашого сайту, і як зробити їх більш зручними для користувачів пошукових систем і людей.

Повна серія статей складається з

Єдині локатори ресурсів

URL (або Uniform Resource Locator) для будь-якої сторінки вказує адресу, де він знаходиться, і механізм (протокол), за допомогою якого він може бути отриманий. Для веб-сторінок протокол буде 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-адреси для попередньої версії мого сайту була обумовлена ​​тим, що старіші версії веб-форм покладалися на URL-адреси, що збігаються з назвою та шляхом фізичних файлів. Будь-які динамічні значення, такі як ідентифікатор, для якої повинна бути показана стаття, передаються як параметри рядка запиту. Можна було б передати назву статті як параметр рядка запиту. Однак порада від пошукових систем полягає в тому, щоб уникнути рядків запитів, якщо це взагалі можливо, і де їх неможливо уникнути, зберегти їх дуже мало і коротко.

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

Дружні URL-адреси та маршрутизація

Веб-форми продовжують працювати на основі відображення URL-адрес на фізичні файли, але він також включає нову систему для створення та роботи з дружніми URL-адресами, які називаються - ahem - " Дружні URL-адреси Вона базується на тій же парадигмі, що і на система маршрутизації за замовчуванням, яка входить до складу рамки веб-сторінок 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-urls, наступний код показує, як витягти значення з сегментів за допомогою пакета дружніх URL-адрес у Article.aspx , а потім присвоїти їм літеральні елементи керування, які називаються ідентифікатором та заголовком, а також генерувати гіперпосилання за допомогою керування HyperLink:

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

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

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

Маршрутизація

Маршрутизація дещо відрізняється залежно від того, чи розробляєте веб-сайти або сайт MVC. По суті, обидві вони мають однакову основу - переносить URL-адреси на ресурси, коли програма запускається, і вхідні запити перевіряються на карті (або таблиці маршрутів), щоб побачити, куди вони повинні бути спрямовані. Однак на сайті Web Forms всі вхідні URL-адреси мають відображатися на фізичних файлах. Оскільки між вмістом URL-адреси та файловою системою веб-сервера не існує передбачуваної асоціації, кожна URL-адреса має бути налаштована. Можна використовувати як дружні URL-адреси, так і маршрутизацію на одному і тому ж сайті, тому це може зробити роботу конфігурації набагато простіше, коли більшість URL-адрес дійсно відповідають імені файлу без розширення. Наступний розділ коду показує клас за промовчанням RouteConfig, знайдений у папці App_Start у шаблоні веб-форм:

відкритий статичний клас RouteConfig {public static void RegisterRoutes (маршрути RouteCollection) {var settings = new FriendlyUrlSettings (); settings.AutoRedirectMode = RedirectMode. Постійний; routes.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 . Xxx може бути будь-яким значенням, але має бути присутнім для роботи маршруту. Ви можете зробити цю частину URL-адреси необов'язковою, або можете обмежити значення певним шаблоном за допомогою регулярних виразів. Ви можете прочитати більше про те, як це зробити Огляд MSDN маршрутизації ASP.NET .

Дружні URL-адреси завжди перемагатимуть у випадку, якщо запис маршрутизації відповідає шляху віртуального файлу для файлу .aspx на сервері. Наприклад, якщо хтось додасть файл до назви Test.aspx до кореневої папки сайту у наведеному вище прикладі, дружні URL-адреси піклуються про пряме відповідність між URL-адресою та файловою системою, а запис маршрутизації ніколи не буде викликається.

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

public static void RegisterRoutes (маршрути RouteCollection) {routes.IgnoreRoute ("{{ресурс} .axd / {* pathInfo}"); routes.MapRoute (ім'я: "За замовчуванням", url: "{контролер} / {дія} / {id}", типові значення: new {controller = "Home", action = "Index", id = UrlParameter .Optional}); }

Це визначення маршруту вказує, що перший сегмент URL містить ім'я контролера, другий містить ім'я методу Action, третій сегмент є необов'язковим, але якщо він заповнений, його можна підібрати до параметра з ім'ям id. Значенням за замовчуванням для сегмента контролера є Home, а за умовчанням для сегмента дії - Index.

Якщо ви хочете генерувати URL-адреси для використання в атрибутах anchor href або image src або подібних у MVC 5 або раніше, у вас є кілька допоміжних методів для вибору: ActionLink , RouteLink і UrlHelper's Методи дії та маршрути. У MVC у вас також є можливість використовувати новий Якірний тегХелпер ., де дія і contoller вказані як спеціальні атрибути asp на елементах HTML:

<a asp-action = "Index" asp-controller = "Головна"> Назад Головна </ a>

Слимаки

Slug - це термін, який часто використовується для опису чітко читаної частини URL-адреси. На моєму сайті я використовую назву статті як шлейф і тому ретельно вибираю назви статей, щоб переконатися, що вони містять відповідні ключові слова. Я також повторно використовую назву статті як назву сторінки та вміст заголовка h1, щоб ключові слова знаходилися послідовно по всій сторінці. The ASP.NET форуми і Переповнення стеку використовуйте формулювання розміщеного запитання як плюсик. Однак вони використовують різні роздільники слів: форуми ASP.NET використовують знак плюс (+) між словами, тоді як Stackoverflow використовує дефіси (-). Люди в Google рекомендують використовувати дефіси.

Питання, яке часто виникає, полягає в тому, як створити слізень, який може безпечно враховувати знаки пунктуації та інших зарезервованих символів. Хлопці Stackoverflow мають розміщено метод генерації кулі вони використовують. Я використовую варіант їхнього алгоритму, який має обмеження на 80 символів, яку вони використовують. Багато експертів SEO рекомендують зберігати URL-адреси максимум 75-80 символів, оскільки це максимальна кількість символів, які показуватимуть записи в SERP. Однак Google, зокрема, намагається скорочувати URL-адреси для відображення, щоб виділити відповідні ключові слова, замінюючи сегменти, що не є ключовими словами, еліпсами. У Google немає рекомендацій щодо встановлення максимальної довжини URL-адреси, тому здається, що вони насправді не турбують.

Канонічні 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 до www URLS

Більшість доменів створено за допомогою запису @, який вказує їхній домен у найчистішому вигляді (наприклад, domain.com) на IP-адресу веб-сервера та запис CNAME, який вказує www.domain.com на запис @. Потім обидва домену.com та www.domain.com додаються як прив'язки для сайту в IIS. Це корисно для тих відвідувачів, які вводять веб-адресу без префікса www. Він гарантує, що запит направляється на правильний сервер. Як я вже згадував, це призводить до двох дійсних URL-адрес для одного вмісту, і хоча цю проблему можна потурбуватися, використовуючи rel = "canonical", ви також можете використовувати перенаправлення HTTP, якщо ваш сервер IIS має URL Rewrite встановлено. Вам навіть не потрібен доступ до веб-сервера для налаштування правила перезапису. Ви можете зробити це у web.config вашого сайту.

<system.webServer> <rewrite> <rules> <rule name = "Перенаправити трафік без www на www" stopProcessing = "true"> <match url = ". *" ignoreCase = "true" /> <conditions> <add input = "{HTTP_HOST}" pattern = "^ mikesdotnetting.com $" /> </ Умови> <action type = "Redirect" url = "http://www.mikesdotnetting.com/{R:0}" redirectType = "Постійний" /> </ rule> </ rules> </ rewrite> </ system.webServer>

Це правило перезапису охоплює запити на будь-яку URL-адресу, яка відповідає шаблону. *, Яка в основному охоплює все. Вона вивчить хост-частину URL-адреси, а якщо не починається з "www". сервер відповідає кодом стану 301 - Постійно переміщено, а нове місце з попереднім www.

Резюме

Ця стаття охоплювала роль, яку відтворюють URL-адреси в пошуковій оптимізації. Він розглядав важливість використання URL-адрес користувача та сео-друзів і способів створення та роботи з ними в обох веб-формах ASP.NET і MVC. Нарешті, пояснювалися канонічні URL-адреси, і описані стратегії їх управління.

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