Блог ScottGu - Підказка / трюк: Виправлення загальних проблем у SEO за допомогою розширення URL Rewrite

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, які може мати ваш сайт. Щоб застосувати 4 прості, потрібно менше 15 хвилин (і ніяких змін у коді) URL Rewrite правила на вашому сайті, і таким чином викликайте пошукові системи більше відвідувачів і трафік на ваш сайт. Методи, наведені нижче, працюють однаково добре як з веб-формами ASP.NET, так і з веб-сайтами ASP.NET MVC. Вони також працюють з усіма версіями ASP.NET (і навіть працюють з вмістом non-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: Канонічні імена хостів

Іноді сайти підтримують сценарії, де вони підтримують веб-сайт як з префіксом ім'я хоста, так і з самим ім'ям хоста. Це призводить до того, що пошукові системи розглядають URL-адреси як різні та поділені пошукові рейтинги:

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

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

Як легко виправити ці проблеми SEO за 10 хвилин (або менше), використовуючи IIS Rewrite

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

"Хороша новина" полягає в тому, що виправлення вищезазначених питань є дуже простим Розширення перезапису URL . Це абсолютно безкоштовне розширення Microsoft, доступне для IIS 7.x (на Windows Server 2008, Windows Server 2008 R2, Windows 7 і Windows Vista). Найкраще використання розширення перезапису IIS полягає в тому, що він дозволяє виправити вищезгадані проблеми * без необхідності змінювати код у ваших програмах.

Ви можете легко встановити Розширення перезапису URL через 3 хвилини за допомогою Інсталятор веб-платформи Microsoft (безкоштовний інструмент, який ми постачаємо, що автоматизує налаштування веб-серверів і машин розробки). Просто натисніть зелену кнопку "Встановити зараз" на URL Rewrite Spotlight для інсталяції на машині Windows Server 2008, Windows 7 або Windows Vista:

Після встановлення ви побачите, що в інструменті адміністрування IIS 7 доступний новий значок "Перезапис URL-адрес":

Подвійним клацанням на піктограмі відкриється панель адміністрування 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-адреса відповідає шаблону регулярних виразів. Не хвилюйтеся, якщо ви не хороші з регулярними виразами - я теж всмоктую їх. Хитрість полягає в тому, щоб знати когось, хто добре їм, або копіювати / вставляти їх з веб-сайту.

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

(. *?) /? За замовчуванням

Цей шаблон буде відповідати будь-якому рядку URL, який закінчується за замовчуванням. "(. *?)" Відповідає будь-якому попередньому символу нуль або більше разів. "/?" частина говорить, щоб відповідати символу слеша нуль або один раз. Символ "$" в кінці гарантує, що шаблон буде відповідати лише рядкам, які закінчуються за замовчуванням.

Об'єднання всіх цих елементів регулярного виразу дозволяє цьому правилу працювати не тільки з коренем вашого веб-сайту (наприклад 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 - це означає, що пошукові системи будуть слідувати за ним.

Я також встановив властивість "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 - індексом зворотного посилання. У випадку з нашим шаблоном "(. *?) /" За замовчуванням aspx $ ", якщо вхідною URL-адресою є" products / Default.aspx ", то {R: 0} буде містити" products / Default.aspx "і {{ R: 1} буде містити "продукти". Ми будемо використовувати це значення {R: 1} / value для URL-адреси, на яку перенаправляють користувачів.

Крок 4. Застосуйте та збережіть правило

Останній крок полягає в тому, щоб натиснути кнопку "Застосувати" у верхній правій частині інструмента адміністрування IIS, що призведе до того, що інструмент збереже правило перезапису URL в кореневому файлі нашого додатка web.config (під <system.webServer / rewrite > розділ конфігурації):

<configuration>
<system.webServer>
<напис>
<правила>
<rule name = "Документ за замовчуванням" stopProcessing = "true">
<match url = "(. *?) /? За замовчуванням aspx $" />
<action type = "Redirect" "url =" {R: 1} / "/>
</rule>
</rules>
</rewrite>
</ system.webServer>
</configuration>

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

Крок 5: Спробуйте правило Out

Тепер, коли ми зберегли правило, давайте спробуємо його на нашому сайті. Спробуйте виконати такі два 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 Rewrite. Це знову відкриє діалогове вікно "Додати правило":

На відміну від попереднього сценарію (де ми створили "порожнє правило"), за цим сценарієм ми можемо скористатися вбудованим шаблоном правила "Впроваджувати рядкові URL-адреси". Коли ми натискаємо кнопку "ок", ми побачимо наступне діалогове вікно, яке запитує нас, чи хочемо ми створити правило, яке застосовує використання малих літер у URL-адресах:

Коли ми натискаємо кнопку "Так", ми отримаємо попереднє письмове правило, яке автоматично виконує постійне переспрямування, якщо вхідна URL-адреса містить у верхньому регістрі символи, - і автоматично надсилає користувачів до версії URL у нижньому регістрі:

Ми можемо натиснути кнопку «Застосувати», щоб скористатися цим правилом «як є», і застосовувати його до всіх вхідних URL-адрес нашого сайту.

Тому що мій www.scottgu.com Сайт використовує веб-форм ASP.NET, я збираюся внести одну невелику зміну у правило, яке ми створили вище - це додати умову, яка гарантує, що URL-адреси вбудованого ASP.NET в обробнику "WebResource.axd" виключені з нашої регістрів чутливості URL Rewrite logic. URL-адреси обробника WebResource.axd будуть надходити лише з елементів керування сервером, які видаються з моїх сторінок, і ніколи не буде пов'язано з зовнішніми сайтами. Хоча мій сайт продовжуватиме працювати нормально, якщо перенаправляти ці URL-адреси автоматично на нижній - це не є необхідним і додасть додаткове перенаправлення HTTP на багато моїх сторінок.

Хороша новина полягає в тому, що додавання умови, що перешкоджає тому, щоб моє правило перезапису URL-адрес відбувалося з певними URL-адресами, легко. Нам просто потрібно розширити розділ "Умови" вищевказаної форми

Потім ми можемо натиснути кнопку «Додати», щоб додати умову. Відкриється діалогове вікно "Додати умову":

Вище я ввів {URL} як вхід Умови - і сказав, що це правило має виконуватися, лише якщо URL не відповідає шаблону регулярного виразу, який містить рядок “WebResource.axd”. Це гарантує, що URL-адреси WebResource.axd до мого сайту будуть дозволені до виконання, але без перевизначення URL-адреси для того, щоб всі вони були нижчими.

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

Коли я натискаю кнопку "ок" і застосовую правило перезапису в нижньому регістрі, інструмент адміністратора збереже наступне додаткове правило до нашого файлу web.config:

<configuration>
<system.webServer>
<напис>
<правила>

<rule name = "Документ за замовчуванням" stopProcessing = "true">
<match url = "(. *?) /? За замовчуванням aspx $" />
<action type = "Redirect" "url =" {R: 1} / "/>
</rule>

<rule name = "URL нижнього регістру" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<conditions logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" "url =" {ToLower: {URL}} "/>
</rule>

</rules>
</rewrite>
</ system.webServer>
</configuration>

Спробуйте вимкнути правило

Тепер, коли ми зберегли правило, давайте спробуємо його на нашому сайті. Спробуйте виконати такі два URL-адреси на моєму сайті:

http://scottgu.com/Albums.aspx

http://scottgu.com/albums.aspx

Зверніть увагу, що перша URL-адреса (яка має велике значення "A") автоматично перенаправляє версію URL у нижньому регістрі.

Сценарій 3: трейлінг

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

http://scottgu.com

http://scottgu.com/

Ми можемо це виправити, додавши нове правило перезапису IIS, яке автоматично перенаправляє тих, хто переходить до першого URL (який не має кінцевої слеш), а потім переходить до другого. Як і раніше, ми налаштуємо перенаправлення HTTP як "постійне переспрямування", яке буде вказувати пошуковим системам, що вони повинні слідувати перенаправлення і використовувати новий URL, який вони перенаправляються, як ідентифікатор отриманого вмісту.

Щоб створити таке правило, знову натисніть посилання "Додати правило" у засобі адміністрування URL Rewrite. Це знову відкриє діалогове вікно "Додати правило":

Інструмент адміністрування URL Rewrite має вбудований шаблон шаблону "Додавання або видалення символу кінцевого слеша".

Коли ми виберемо його і натиснемо кнопку "ок", ми побачимо наступне діалогове вікно, яке запитує, чи хочемо ми створити правило, яке автоматично перенаправляє користувачів на URL з кінцевою косою рискою, якщо її немає:

Коли ми натискаємо кнопку "ОК", ми отримаємо попереднє письмове правило, яке автоматично виконує постійне перенаправлення, якщо URL-адреса не має кінця, а якщо URL-адреса не обробляється ні каталогом, ні файлом.

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

Це збереже наступне додаткове правило до нашого файлу web.config:

<configuration>
<system.webServer>
<напис>
<правила>

<rule name = "Документ за замовчуванням" stopProcessing = "true">
<match url = "(. *?) /? За замовчуванням aspx $" />
<action type = "Redirect" "url =" {R: 1} / "/>
</rule>

<rule name = "URL нижнього регістру" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<conditions logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" "url =" {ToLower: {URL}} "/>
</rule>

<rule name = "Trailing Slash" stopProcessing = "true">
<match url = "(. * [^ /]) $" />
<conditions logicalGrouping = "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" />
</conditions>
<action type = "Redirect" "url =" {R: 1} / "/>
</rule>

</rules>
</rewrite>
</ system.webServer>
</configuration>

Спробуйте вимкнути правило

Тепер, коли ми зберегли правило, давайте спробуємо його на нашому сайті. Спробуйте виконати такі два 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 Rewrite. Це знову відкриє діалогове вікно "Додати правило":

Інструмент адміністрування URL Rewrite має вбудований шаблон правила "Canonical domain name".

Коли ми виберемо його і натиснемо кнопку "ок", ми побачимо наступний діалог, який запитує нас, чи хочемо ми створити правило переспрямування, яке автоматично перенаправляє користувачів на основну URL-адресу імені хоста:

Над я вводжу основну URL-адресу, яку я хочу розкрити в Інтернеті: scottgu.com. Коли ми натискаємо кнопку "ОК", ми отримаємо попереднє письмове правило, яке автоматично виконує постійне перенаправлення, якщо URL-адреса має інший префікс головного доменного імені.

Це збереже наступне додаткове правило до нашого файлу web.config:

<configuration>
<system.webServer>
<напис>
<правила>

<rule name = "Cannonical Hostname">
<match url = "(. *)" />
<conditions logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{HTTP_HOST}" шаблон = "^ scottgu. .com $" negate = "true" />
</conditions>
<action type = "Redirect" "url =" http://scottgu.com/{R:1} " />
</rule>

<rule name = "Документ за замовчуванням" stopProcessing = "true">
<match url = "(. *?) /? За замовчуванням aspx $" />
<action type = "Redirect" "url =" {R: 1} / "/>
</rule>

<rule name = "URL нижнього регістру" stopProcessing = "true">
<match url = "[AZ]" ignoreCase = "false" />
<conditions logicalGrouping = "MatchAll" trackAllCaptures = "false">
<add input = "{URL}" pattern = "WebResource.axd" negate = "true" />
</conditions>
<action type = "Redirect" "url =" {ToLower: {URL}} "/>
</rule>

<rule name = "Trailing Slash" stopProcessing = "true">
<match url = "(. * [^ /]) $" />
<conditions logicalGrouping = "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" />
</conditions>
<action type = "Redirect" "url =" {R: 1} / "/>
</rule>

</rules>
</rewrite>
</ system.webServer>
</configuration>

Спробуйте вимкнути правило

Тепер, коли ми зберегли правило, давайте спробуємо його на нашому сайті. Спробуйте виконати такі два URL-адреси на моєму сайті:

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

http://scottgu.com/albums.aspx

Зверніть увагу, що перша URL-адреса (яка має префікс "www") тепер автоматично перенаправляє другу URL-адресу, яка не має префікса www. Оскільки це постійне перенаправлення, пошукові системи будуть дотримуватися URL-адреси та оновлюватимуть рейтинг сторінки.

4 Прості правила для покращення SEO

Ці чотири правила досить прості в налаштуванні, а для налаштування на існуючих сайтах, які вже є, потрібно менше 15 хвилин.

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

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

Натискання будь-якого з наведених вище правил відкриє редактор правил, щоб створити резервну копію та налаштувати / зберегти їх далі.

Резюме

Вимірювання та вдосконалення SEO - це те, що кожен розробник, що будує веб-сайт, що орієнтується на громадськість, повинен подумати і зосередитися. Якщо ви ще цього не зробили, завантажте та використовуйте SEO Інструментарій проаналізувати SEO ваших сайтів сьогодні.

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

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

Сподіваюся, що це допоможе,

Скотт