Блог ScottGu - Полезные советы: исправьте типичные проблемы с SEO с помощью расширения перезаписи URL

1. Измерение SEO вашего сайта с помощью Microsoft SEO Toolkit
2. Релевантность поиска и разделение URL
3. 4 действительно распространенных SEO-проблем, которые могут возникнуть на ваших сайтах
4. Как легко исправить эти проблемы SEO за 10 минут (или меньше) с помощью IIS Rewrite
5. Сценарий 1. Обработка сценариев документов по умолчанию
6. Сценарий 2. Различный регистр URL
7. Сценарий 3: конечные слэши
8. Сценарий 4: канонические имена хостов
9. 4 простых правила для улучшения SEO
10. Резюме

Поисковая оптимизация (SEO) важна для любого публичного сайта. В настоящее время большой процент трафика на сайты поступает непосредственно из поисковых систем, а повышение релевантности вашего сайта в поисковой сети приведет к увеличению числа пользователей, посещающих ваш сайт по запросам поисковых систем. Это может прямо или косвенно увеличить деньги, которые вы зарабатываете через ваш сайт.

В этом блоге рассказывается, как вы можете использовать бесплатный Microsoft Расширение перезаписи URL чтобы исправить кучу общих проблем SEO, которые могут возникнуть на вашем сайте. Это займет менее 15 минут (и без изменений кода), чтобы применить 4 простых URL переписать правила для вашего сайта, и при этом поисковые системы привлекают больше посетителей и трафика на ваш сайт. Приведенные ниже методы одинаково хорошо работают как с веб-формами ASP.NET, так и с сайтами на основе ASP.NET MVC. Они также работают со всеми версиями ASP.NET (и даже работают с содержимым, отличным от ASP.NET).

[В дополнение к ведению блога, я также сейчас использую Twitter для быстрых обновлений и обмена ссылками. Следуй за мной по адресу: twitter.com/scottgu ]

Измерение SEO вашего сайта с помощью Microsoft SEO Toolkit

Несколько месяцев спустя Я в блоге о свободном SEO Инструментарий что мы отправили. Этот полезный инструмент позволяет автоматически сканировать / сканировать ваш сайт на предмет правильности SEO, а затем он отмечает любые проблемы с SEO, которые он находит. Я настоятельно рекомендую скачать и использовать инструмент против любого публичного сайта, на котором вы работаете. Это позволяет легко выявлять проблемы SEO, которые могут возникнуть на вашем сайте, и определять пути дальнейшей оптимизации.

Ниже приведен простой пример отчета, который я запустил на одном из моих сайтов ( www.scottgu.com ) до применения правил перезаписи URL, о которых я расскажу позже в этом блоге:

Релевантность поиска и разделение URL

Две важные вещи, которые оценивают поисковые системы при оценке «релевантности поиска» вашего сайта:

1. Сколько других сайтов ссылаются на ваш контент. Поисковые системы предполагают, что если многие люди в Интернете ссылаются на ваш контент, то он, вероятно, полезен и поэтому повышает его релевантность.
2. Уникальность контента, который он находит на вашем сайте. Если поисковые системы обнаружат, что контент дублируется в нескольких местах по всему Интернету (или по нескольким URL-адресам на вашем сайте), то это может привести к снижению релевантности контента.

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

В частности, если разрешить внешним сайтам ссылаться на один и тот же контент с несколькими URL-адресами, количество ссылок и рейтинг страниц будут разделены по этим различным URL-адресам (и, таким образом, вы получите меньший рейтинг страницы, чем он был бы, если бы был только один URL). Непозволительно ссылаться на внешние сайты по-разному, в теории это звучит легко, но вы можете задаться вопросом, что именно это означает на практике и как этого избежать.

4 действительно распространенных SEO-проблем, которые могут возникнуть на ваших сайтах

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

Проблема SEO № 1: Документ по умолчанию

IIS (и другие веб-серверы) поддерживает концепцию «документа по умолчанию». Это позволяет избежать явного указания страницы, которую вы хотите обслуживать, либо в корне веб-сайта / приложения, либо в подкаталоге. Это удобно, но означает, что по умолчанию этот контент доступен через два публично открытых URL-адреса (что плохо). Например:

http://scottgu.com/

http://scottgu.com/default.aspx

Проблема SEO № 2: различные адреса URL

Веб-разработчики часто не понимают, что URL чувствительны к регистру для поисковых систем в Интернете. Это означает, что поисковые системы будут рассматривать следующие ссылки как два совершенно разных URL:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Проблема SEO № 3: конечные слэши

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

http://scottgu.com

http://scottgu.com/

Проблема SEO № 4: канонические имена хостов

Иногда сайты поддерживают сценарии, в которых они поддерживают веб-сайт как с ведущим префиксом «www», так и с самим именем хоста. Это заставляет поисковые системы обрабатывать URL-адреса как разные и разделяют ранжирование поиска:

http://scottgu.com/albums.aspx/

http://www.scottgu.com/albums.aspx/

Как легко исправить эти проблемы SEO за 10 минут (или меньше) с помощью IIS Rewrite

Если вы не были осторожны при кодировании своих сайтов, скорее всего, вы страдаете от одной (или более) из вышеперечисленных проблем SEO. Решение этих проблем улучшит ваш рейтинг релевантности в поисковых системах и привлечет больше трафика на ваш сайт.

«Хорошая новость» заключается в том, что исправить вышеуказанные 4 проблемы действительно легко, используя Расширение перезаписи URL , Это полностью бесплатное расширение Microsoft, доступное для IIS 7.x (в Windows Server 2008, Windows Server 2008 R2, Windows 7 и Windows Vista). Преимущество использования расширения IIS Rewrite заключается в том, что оно позволяет исправить указанные выше проблемы * без * изменения какого-либо кода в ваших приложениях.

Вы можете легко установить Расширение перезаписи URL менее чем за 3 минуты, используя Установщик веб-платформы Microsoft (бесплатный инструмент, который мы поставляем, который автоматизирует настройку веб-серверов и машин для разработки). Просто нажмите зеленую кнопку «Установить сейчас» на URL переписать Spotlight Чтобы установить его на свой компьютер с Windows Server 2008, Windows 7 или Windows Vista:

После установки вы обнаружите, что новый значок «URL Rewrite» доступен в IIS 7 Admin Tool:

Двойной щелчок по значку откроет админ-панель перезаписи URL - в ней отобразится список правил перезаписи URL, настроенных для конкретного приложения или сайта:

Обратите внимание, что наш список правил перезаписи выше в настоящее время пуст (который используется по умолчанию при первой установке расширения). Мы можем нажать кнопку «Добавить правило ...» в правом верхнем углу панели, чтобы добавить и включить новую логику перезаписи URL для нашего сайта.

Сценарий 1. Обработка сценариев документов по умолчанию

Одной из проблем SEO, которую я обсуждал ранее в этом посте, был сценарий, когда функция IIS «документ по умолчанию» заставляет вас непреднамеренно выставлять два URL для одного и того же контента на вашем сайте. Например:

http://scottgu.com/

http://scottgu.com/default.aspx

Мы можем исправить это, добавив новое правило перезаписи IIS, которое автоматически перенаправляет любого, кто переходит на второй URL, вместо этого, чтобы перейти на первый. Мы настроим HTTP-перенаправление как «постоянное перенаправление», которое будет указывать поисковым системам, что они должны следовать перенаправлению и использовать новый URL-адрес, на который они перенаправляются, в качестве идентификатора контента, который они получают.

Давайте посмотрим, как мы можем создать такое правило. Мы начнем с нажатия на ссылку «Добавить правило» на снимке экрана выше. Это приведет к отображению ниже диалогового окна:

Мы выберем шаблон «Пустое правило» в разделе «Входящие правила», чтобы создать новое пользовательское правило перезаписи URL. Это отобразит пустую панель, как показано ниже:

Не волнуйтесь - настроить вышеприведенное правило легко. Следующие 4 шага объясняют, как это сделать:

Шаг 1: Назовите правило

Наш первый шаг - назвать правило, которое мы создаем. Присвоение имени описательному имени облегчит поиск и понимание позже. Давайте назовем это правило нашим правилом «Перезапись URL документа по умолчанию»:

Шаг 2. Настройка регулярного выражения, соответствующего этому правилу

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

Ниже мы собираемся указать следующее регулярное выражение в качестве правила шаблона:

(. *?) /? Default \ .aspx $

Этот шаблон будет соответствовать любой строке URL, которая заканчивается Default.aspx. «(. *?)» Соответствует любому предшествующему символу ноль или более раз. "/?" Часть говорит, чтобы соответствовать символу косой черты ноль или один раз. Символ «$» в конце гарантирует, что шаблон будет соответствовать только строкам, оканчивающимся на Default.aspx.

Объединение всех этих элементов регулярного выражения позволяет этому правилу работать не только для корня вашего веб-сайта (например, http://scottgu.com/default.aspx ), но также для любого приложения или подкаталога на сайте (например, http://scottgu.com/photos/default.aspx , Поскольку флажок «игнорировать регистр» установлен, он будет соответствовать как «Default.aspx», так и «default.aspx» в URL.

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

Выше я добавил URL «products / default.aspx» и нажал кнопку «Тест». Это даст мне немедленную обратную связь о том, будет ли выполняться правило для него.

Шаг 3: Настройте постоянное действие перенаправления

Затем мы настроим действие, которое будет выполняться, когда наш шаблон регулярного выражения соответствует входящему URL:

В приведенном выше диалоговом окне я изменил раскрывающийся список «Тип действия» на действие «Перенаправление». «Тип перенаправления» будет постоянным перенаправлением HTTP 301 - это означает, что поисковые системы будут следовать за ним.

Я также установил свойство «Redirect URL»:

{R: 1} /

Это указывает на то, что мы хотим перенаправить веб-клиент, запрашивающий исходный URL-адрес, на новый URL-адрес с первоначально запрошенным URL-путем, за исключением «Default.aspx». Например, запросы на http://scottgu.com/default.aspx будет перенаправлен на http://scottgu.com/ и запросы на http://scottgu.com/photos/default.aspx будет перенаправлен на http://scottgu.com/photos/

Конструкция регулярного выражения "{R: N}", где N> = 0, называется обратной ссылкой регулярного выражения, а N - индексом обратной ссылки. В случае нашего шаблона «(. *?) /? Default \ .aspx $», если входной URL-адрес «products / Default.aspx», тогда {R: 0} будет содержать «products / Default.aspx» и { R: 1} будет содержать «продукты». Мы будем использовать это {R: 1} / значение в качестве URL-адреса, на который мы перенаправляем пользователей.

Шаг 4: Применить и сохранить правило

Нашим последним шагом является нажатие кнопки «Применить» в правом верхнем углу инструмента администрирования IIS, что заставит инструмент сохранить правило перезаписи URL-адреса в корневом файле web.config нашего приложения (в <system.webServer / rewrite > раздел конфигурации):

<Конфигурация>
<System.webServer>
<Переписывают>
<правила>
<rule name = "Документ по умолчанию" stopProcessing = "true">
<match url = "(. *?) /? По умолчанию \ .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</ правило>
</ Правила>
</ Переписывание>
</System.webServer>
</ Конфигурация>

Поскольку IIS 7.x и ASP.NET совместно используют одни и те же файлы web.config, вы можете просто скопировать / вставить вышеуказанный код в файлы web.config с помощью Visual Studio и пропустить необходимость полного запуска инструмента администратора. Это также значительно упрощает добавление / развертывание правил перезаписи URL в приложениях ASP.NET.

Шаг 5: Попробуйте исключить

Теперь, когда мы сохранили правило, давайте попробуем его на нашем сайте. Попробуйте следующие два URL на моем сайте:

http://scottgu.com/

http://scottgu.com/default.aspx

Обратите внимание, что второй URL-адрес автоматически перенаправляет на первый. Поскольку это постоянное перенаправление, поисковые системы будут следовать URL и должны обновлять рейтинг страниц http://scottgu.com включить ссылки на http://scottgu.com/default.aspx также.

Сценарий 2. Различный регистр URL

Еще одна распространенная проблема SEO, о которой я говорил ранее в этом посте, заключается в том, что URL чувствительны к регистру для поисковых систем в Интернете. Это означает, что поисковые системы будут рассматривать следующие ссылки как два совершенно разных URL:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Мы можем исправить это, добавив новое правило перезаписи IIS, которое автоматически перенаправляет любого, кто переходит на первый URL-адрес, вместо этого переходит на второй (все строчные). Как и прежде, мы настроим HTTP-перенаправление как «постоянное перенаправление», которое будет указывать поисковым системам, что они должны следовать перенаправлению и использовать новый URL-адрес, на который они перенаправляются, в качестве идентификатора контента, который они получают.

Чтобы создать такое правило, мы снова нажмем ссылку «Добавить правило» в инструменте администрирования перезаписи URL. Это приведет к тому, что диалоговое окно «Добавить правило» появится снова:

В отличие от предыдущего сценария (где мы создали «Пустое правило»), в этом сценарии мы можем воспользоваться встроенным шаблоном правила «Принудительное использование строчных URL-адресов». Когда мы нажмем кнопку «ОК», мы увидим следующее диалоговое окно, которое спрашивает нас, хотим ли мы создать правило, которое предписывает использование строчных букв в URL:

Когда мы нажимаем кнопку «Да», мы получаем предварительно написанное правило, которое автоматически выполняет перенаправление, если на входящем URL-адресе присутствуют символы верхнего регистра, и автоматически отправляет пользователей на строчную версию URL-адреса:

Мы можем нажать кнопку «Применить», чтобы использовать это правило «как есть» и применить его ко всем входящим URL-адресам нашего сайта.

Потому что мой www.scottgu.com сайт использует ASP.NET Web Forms, я собираюсь внести одно небольшое изменение в правило, которое мы сгенерировали выше - добавить условие, обеспечивающее исключение URL-адресов во встроенном обработчике ASP.NET «WebResource.axd». из нашей логики перезаписи URL с учетом регистра. URL-адреса для обработчика WebResource.axd будут поступать только от серверных элементов управления, отправленных с моих страниц, и никогда не будут связаны с внешними сайтами. Хотя мой сайт продолжит нормально работать, если мы перенаправим эти URL-адреса автоматически в нижний регистр - это не нужно и добавит дополнительный HTTP-перенаправление на многие из моих страниц.

Хорошая новость заключается в том, что добавить условие, которое предотвращает выполнение правила перезаписи URL-адреса с определенными URL-адресами, легко. Нам просто нужно расширить раздел «Условия» в форме выше

Затем мы можем нажать кнопку «Добавить», чтобы добавить условие условия. Это вызовет диалог «Добавить условие»:

Выше я ввел {URL} в качестве ввода условия - и сказал, что это правило должно выполняться, только если URL не соответствует шаблону регулярных выражений, который содержит строку «WebResource.axd». Это обеспечит нормальное выполнение URL-адресов WebResource.axd на моем сайте без необходимости перезаписи URL-адреса в нижний регистр.

Примечание. Если у вас есть статические ресурсы (например, ссылки на файлы .jpg, .css и .js) на вашем сайте, которые в настоящее время используют символы верхнего регистра, вы, вероятно, захотите добавить дополнительные условия фильтра условий, чтобы URL-адреса к ним также не использовались. не перенаправляются в нижний регистр (просто добавьте правила для таких шаблонов, как .jpg, .gif, .js и т. д.). Ваш сайт будет продолжать работать нормально, если эти URL будут перенаправлены в нижний регистр (это означает, что сайт не сломается) - но это вызовет дополнительное перенаправление HTTP на вашем сайте для URL, которые не нужно перенаправлять для SEO причины. Поэтому настройка условия условия имеет смысл добавить.

Когда я нажимаю кнопку «ОК» выше и применяю правило перезаписи в нижнем регистре, инструмент администратора сохраняет следующее дополнительное правило в нашем файле web.config:

<Конфигурация>
<System.webServer>
<Переписывают>
<правила>

<rule name = "Документ по умолчанию" stopProcessing = "true">
<match url = "(. *?) /? По умолчанию \ .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</ Правило>

<rule name = "Строчные URL-адреса" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<condition logicGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</ условие>
<action type = "Redirect" url = "{ToLower: {URL}}" />
</ правило>

</ Правила>
</ Переписывание>
</System.webServer>
</ Конфигурация>

Попробуйте исключить

Теперь, когда мы сохранили правило, давайте попробуем его на нашем сайте. Попробуйте следующие два URL на моем сайте:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Обратите внимание, что первый URL-адрес (с большой буквы «А») автоматически выполняет перенаправление на строчную версию URL-адреса.

Сценарий 3: конечные слэши

Еще одна распространенная проблема SEO, о которой я говорил ранее в этом посте, это сценарий слэша в URL. Конечная косая черта создает еще одну ситуацию, в которой поисковые системы обрабатывают URL-адреса как разные и, таким образом, разделяют рейтинги поиска:

http://scottgu.com

http://scottgu.com/

Мы можем исправить это, добавив новое правило перезаписи IIS, которое автоматически перенаправляет любого, кто переходит на первый URL-адрес (без косой черты), вместо этого перейти на второй, который выполняет. Как и прежде, мы настроим HTTP-перенаправление как «постоянное перенаправление», которое будет указывать поисковым системам, что они должны следовать перенаправлению и использовать новый URL-адрес, на который они перенаправляются, в качестве идентификатора контента, который они получают.

Чтобы создать такое правило, мы снова нажмем ссылку «Добавить правило» в инструменте администрирования перезаписи URL. Это приведет к тому, что диалоговое окно «Добавить правило» появится снова:

Инструмент администратора перезаписи URL имеет встроенный шаблон правила «Добавить или удалить символ косой черты».

Когда мы выберем его и нажмем кнопку «ОК», мы увидим следующее диалоговое окно, которое спрашивает нас, хотим ли мы создать правило, которое автоматически перенаправляет пользователей на URL с косой чертой, если таковой отсутствует:

Когда мы нажимаем кнопку «ОК», мы получаем предварительно написанное правило, которое автоматически выполняет постоянное перенаправление, если URL не имеет конечной косой черты - и если URL не обрабатывается ни каталогом, ни файлом.

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

Это сохранит следующее дополнительное правило в нашем файле web.config:

<Конфигурация>
<System.webServer>
<Переписывают>
<правила>

<rule name = "Документ по умолчанию" stopProcessing = "true">
<match url = "(. *?) /? По умолчанию \ .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</ Правило>

<rule name = "Строчные URL-адреса" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<condition logicGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</ Условие>
<action type = "Redirect" url = "{ToLower: {URL}}" />
</ Правило>

<rule name = "Конечная косая черта" stopProcessing = "true">
<match url = "(. * [^ /]) $" />
<condition logicGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{REQUEST_FILENAME}" matchType = "IsDirectory" negate = "true" />
<add input = "{REQUEST_FILENAME}" matchType = "IsFile" negate = "true" />
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</ условие>
<action type = "Redirect" url = "{R: 1} /" />
</ правило>

</ Правила>
</ Переписывание>
</System.webServer>
</ Конфигурация>

Попробуйте исключить

Теперь, когда мы сохранили правило, давайте попробуем его на нашем сайте. Попробуйте следующие два URL на моем сайте:

http://scottgu.com

http://scottgu.com/

Обратите внимание, что первый URL (без косой черты) автоматически выполняет перенаправление на URL с косой чертой. Поскольку это постоянное перенаправление, поисковые системы будут следить за URL и обновлять рейтинг страницы.

Сценарий 4: канонические имена хостов

Последняя проблема SEO, которую я обсуждал ранее, - это сценарии, когда сайт работает как с ведущим префиксом «www», так и с самим именем хоста. Это заставляет поисковые системы обрабатывать URL-адреса как разные и разделяют ранжирование поиска:

http://www.scottgu.com/albums.aspx

http://scottgu.com/albums.aspx

Мы можем исправить это, добавив новое правило перезаписи IIS, которое автоматически перенаправляет любого, кто переходит на первый URL-адрес (с префиксом www), вместо этого перейти на второй URL-адрес. Как и прежде, мы настроим HTTP-перенаправление как «постоянное перенаправление», которое будет указывать поисковым системам, что они должны следовать перенаправлению и использовать новый URL-адрес, на который они перенаправляются, в качестве идентификатора контента, который они получают.

Чтобы создать такое правило, мы снова нажмем ссылку «Добавить правило» в инструменте администрирования перезаписи URL. Это приведет к тому, что диалоговое окно «Добавить правило» появится снова:

Инструмент администратора перезаписи URL имеет встроенный шаблон правил «Каноническое доменное имя».

Когда мы выберем его и нажмем кнопку «ОК», мы увидим следующее диалоговое окно, которое спрашивает нас, хотим ли мы создать правило перенаправления, которое автоматически перенаправляет пользователей на основной URL-адрес имени хоста:

Выше я ввожу основной URL-адрес, который я хочу показать в Интернете: scottgu.com. Когда мы нажимаем кнопку «ОК», мы получаем предварительно написанное правило, которое автоматически выполняет постоянное перенаправление, если URL имеет другой префикс имени домена.

Это сохранит следующее дополнительное правило в нашем файле web.config:

<Конфигурация>
<System.webServer>
<Переписывают>
<правила>

<rule name = "Каноническое имя хоста">
<match url = "(. *)" />
<condition logicGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{HTTP_HOST}" pattern = "^ scottgu \ .com $" negate = "true" />
</ условие>
<action type = "Redirect" url = " http://scottgu.com/{R:1}» />
</ правило>

<rule name = "Документ по умолчанию" stopProcessing = "true">
<match url = "(. *?) /? По умолчанию \ .aspx $" />
<action type = "Redirect" url = "{R: 1} /" />
</ Правило>

<rule name = "Строчные URL-адреса" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<condition logicGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</ Условие>
<action type = "Redirect" url = "{ToLower: {URL}}" />
</ Правило>

<rule name = "Конечная косая черта" stopProcessing = "true">
<match url = "(. * [^ /]) $" />
<condition logicGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{REQUEST_FILENAME}" matchType = "IsDirectory" negate = "true" />
<add input = "{REQUEST_FILENAME}" matchType = "IsFile" negate = "true" />
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</ Условие>
<action type = "Redirect" url = "{R: 1} /" />
</ Правило>

</ Правила>
</ Переписывание>
</System.webServer>
</ Конфигурация>

Попробуйте исключить

Теперь, когда мы сохранили правило, давайте попробуем его на нашем сайте. Попробуйте следующие два URL на моем сайте:

http://www.scottgu.com/albums.aspx

http://scottgu.com/albums.aspx

Обратите внимание, что первый URL (который имеет префикс «www») теперь автоматически выполняет перенаправление на второй URL, который не имеет префикса www. Поскольку это постоянное перенаправление, поисковые системы будут следить за URL и обновлять рейтинг страницы.

4 простых правила для улучшения SEO

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

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

Дальнейшую настройку правил перезаписи URL-адреса легко выполнить, либо напрямую отредактировав файл web.config, либо, альтернативно, просто дважды щелкните значок перезаписи URL-адреса в инструменте администрирования IIS 7.x, и он выведет список всех активных правил для вашего веб-сайта. сайт или приложение:

Если щелкнуть любое из вышеперечисленных правил, откроется редактор правил и вы сможете их настроить / настроить / сохранить в дальнейшем.

Резюме

Измерение и улучшение SEO - это то, о чем каждый разработчик, создающий публичный веб-сайт, должен задуматься и сосредоточиться. Если вы еще этого не сделали, загрузите и используйте SEO Инструментарий проанализировать SEO ваших сайтов сегодня.

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

Расширение перезаписи URL предоставляет множество дополнительных замечательных возможностей - далеко не только SEO - Я буду больше рассказывать об этих дополнительных возможностях в будущих постах.

Надеюсь это поможет,

Скотт

Похожие

Комментарии