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

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

Полная серия статей состоит из

Унифицированные указатели ресурсов

URL (или унифицированный указатель ресурса) для любой данной страницы указывает адрес, где она находится, и механизм (протокол), по которому ее можно получить. Для веб-страниц протокол будет 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 для предыдущей версии моего сайта была обусловлена ​​тем фактом, что более старые версии Web Forms полагались на URL, соответствующие имени и пути физических файлов. Любые динамические значения, такие как идентификатор, для которого должна отображаться статья, передаются в качестве параметров строки запроса. Было бы возможно передать заголовок статьи в качестве параметра строки запроса. Однако совет от поисковых систем заключается в том, чтобы избегать строк запросов, если это вообще возможно, и там, где их невозможно избежать, чтобы их было очень мало и их было мало.

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

Дружественные URL и маршрутизация

Веб-формы по-прежнему работают на основе сопоставления URL-адресов с физическими файлами, но также включают новую систему для создания и работы с дружественными URL-адресами, которая называется - ahem - " Дружественные URL ". Он основан на той же парадигме, что и система маршрутизации по умолчанию, которая входит в структуру Razor Web Pages , Настройка по умолчанию будет сопоставлять URL-адрес с физическим файлом без расширения файла, включенного в URL-адрес, а также обрабатывать произвольные фрагменты данных, которые будут передаваться в URL-адресе в качестве дополнительных сегментов. Другими словами, это основанная на соглашениях система, которая использует некоторые или все URL-адреса, соответствующие пути виртуального файла для веб-формы (файл .aspx). Дружественные URL-адреса доступны в виде пакета Nuget (Microsoft.AspNet.FriendlyUrls) и предварительно установлены и включены как часть стандартного шаблона проекта веб-форм.

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

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

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

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

маршрутизация

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

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

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

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

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

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

public static void RegisterRoutes (RouteCollection маршруты) {rout.IgnoreRoute ("{ресурс} .axd / {* pathInfo}"); route.MapRoute (имя: «По умолчанию», URL: «{controller} / {action} / {id}», значения по умолчанию: new {controller = "Home», action = "Index", id = UrlParameter .Optional}); }

Это определение маршрута указывает, что первый сегмент URL содержит имя контроллера, второй содержит имя метода Action, а третий сегмент является необязательным, но если он заполнен, его можно сопоставить с параметром с именем id. Значением по умолчанию для сегмента контроллера является Home, а по умолчанию для сегмента действия - Index.

Если вы хотите сгенерировать URL-адреса для использования в атрибутах привязки href или image src или аналогичных в MVC 5 или более ранних версиях, у вас есть выбор из нескольких вспомогательных методов: ActionLink , RouteLink и UrlHelper-х Методы действий и маршрутов. В MVC у вас также есть возможность использовать новый Якорь TagHelper ., где действие и контроллер определены как специальные атрибуты asp для элементов HTML:

<a asp-action = "Index" asp-controller = "Home"> Вернуться домой </ a>

Слизни

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

Вопрос, который возникает довольно часто, заключается в том, как создать слаг, который может безопасно учитывать пунктуацию и другие зарезервированные символы. Ребята из Stackoverflow имеют опубликовал метод генерации пули они используют. Я использую вариацию их алгоритма, в которой удалено ограничение в 80 символов, которое они используют. Многие эксперты по SEO рекомендуют, чтобы URL-адреса содержали не более 75–80 символов, поскольку это максимальное количество символов, которое будет отображаться в записи в поисковой выдаче. Тем не менее, 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-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> <rewrite> <rules> <rule name = "Перенаправить трафик без www на www" stopProcessing = "true"> <match url = ". *" ignoreCase = "true" /> <условие> <добавить input = "{HTTP_HOST}" pattern = "^ mikesdotnetting.com $" /> </ condition> <action type = "Redirect" url = "http://www.mikesdotnetting.com/ndomR:0}" redirectType = "Постоянный" /> </ rule> </ rules> </ rewrite> </ system.webServer>

Это правило перезаписи охватывает запросы на любой URL, соответствующий шаблону. *, Который в основном охватывает все. Он проверит хост-часть URL-адреса и, если он не начинается с "www." сервер отвечает кодом статуса 301 - Постоянно перемещенное и новым местоположением с предыдущим www.

Резюме

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

В следующей статье я рассмотрю, как вы можете управлять контентом, который индексируют поисковые системы на вашем сайте.

Похожие

Комментарии