Меню

Iis url rewrite module настройка



Using URL Rewrite Module 2.0

Introduction

This section of the documentation applies to the URL Rewrite 2.0 for IIS 7.

URL Rewrite 2.0 for IIS 7 and above is an incremental release that includes all the features from version 1.1, and adds support for .NET extensibility and for outbound response rewriting. More specifically, it can be used to:

  • Implement complex rewrite logic by using rewrite providers written in .NET
  • Replace the URLs generated by a web application in the response HTML with a more user friendly and search engine friendly equivalent
  • Modify the links in the HTML markup generated by a web application behind a reverse proxy.
  • Fix up the content of any HTTP response by using regular expression pattern matching.
  • Modify HTTP request and response headers and IIS server variables.

Features

URL Rewrite 2.0 includes the following key features:

  • Custom rewrite providers (new in RTW). The rewrite providers can be used when an URL rewrite logic cannot be expressed in terms of regular expression patterns or when it is required to make rewriting decisions based on data stored outside of web.config file (e.g. SQL database or text files). Customer rewrite providers can be implemented in any .NET language.
  • Rules-based response rewriting engine. Outbound rules are used to express the logic of what to compare parts of the response with and what to do if comparison was successful. Web server and site administrators can use outbound rules to define complex response rewriting logic.
  • Rewriting within the content of specific HTML tags. Instead of scanning the entire response for a particular match, the rule can be configured to look only inside of certain HTML tags, such as , , etc. That way the pattern is greatly simplified and the process of applying the rule to the content is much faster comparing to applying the pattern to the entire response.
  • Pre-conditions for outbound rules. Applying rewrite rules on every response is an expensive operation and is not necessary in majority of the cases. Pre-conditions are used to check the response metadata to determine if outbound rules evaluation should be applied.
  • Rewriting of server variables and HTTP request headers. Various IIS server variables and HTTP request headers can be set by using rewrite rules.
  • Rewriting of HTTP response headers. Outbound rewrite rules can be used modify any existing HTTP response headers or to set new ones.
  • Allow list for server variables. To prevent distributed rewrite rules from accidentally or purposefully modifying IIS server variables that may affect security or runtime behavior of a web application the modifiable server variables now have to be explicitly added to the allow list.
  • HtmlEncode function. Outbound rewrite may often use an un-trusted data (e.g. query string or HTTP headers) to build a replacement string to insert into the HTTP response. In those cases the HtmlEncode function should be used to prevent insertion of client-side scripts into the response, which could result in cross-site scripting vulnerability.
  • Tracking capture groups across rule conditions. The conditions back-referencing logic in URL Rewrite 1.1 worked only against the last matched conditions. In v2 it is possible to configure back-referencing logic to work against all matched conditions.
  • Rule templates for Search Engine Optimization (new in RTW). Three new rule templates make it very easy to create redirect rules that will enforce usage of canonical URLs for web pages on your site.
  • Reverse Proxy rule template (new in RTW). This template can be used to very quickly generate inbound and outbound rewrite rules that implement reverse proxy configuration.
  • Logging of rewritten URLs. The rewrite rules can be configured to log the rewritten URL in IIS W3C logs as opposed to logging an originally requested URL.
  • Updated user interface in IIS Manager. The user interface has been significantly improved to better represent the module configuration and to simplify such common tasks as configuring of rewrite rules and rewrite conditions.

Installing the module

Download the URL Rewrite 2.0 by using the links at the module’s home page at https://www.iis.net/extensions/urlrewrite

  • If a previous version of URL Rewrite, such as v1.0 and v1.1, is already installed then it will be upgraded to the v2.0
  • If an RC version of the URL Rewrite 2.0 is already installed, then it will be upgraded to RTW version.

Known Issues

  1. Response rewriting does not work with static compression. You will have to disable IIS static compression in order to use response rewriting.
  2. Outbound rules are not applied to chunked transfer encoded responses if rewriteBeforeCache is enabled. Set rewriteBeforeCache to false if you need to rewrite responses that are chunked transfer encoded.

Installing the extensibility samples

The URL Rewrite Extensibility Samples include the .NET assemblies and the source code implementing these providers:

  • DbProvider — this provider can be used to retrieve rewrite mappings from a SQL Server database table by executing a stored procedure;
  • FileMapProvider — this provider can be used to retrieve rewrite mappings stored in a text file;
  • FileContainsProvider — this provider can be used to check if any string in a text file is a substring of the provider’s input string.

Using the module

These articles cover the functionality of the URL Rewrite v2.0 and explain how to use it to accomplish common rewriting scenarios.

Источник

Iis url rewrite module настройка

В данном случае рассматривается ситуация, когда необходимо скрыть результаты опроса SharePoint, а именно скрыть — Графическую сводку ответов опроса SharePoint, на сегодняшний день адекватного решения для данной «проблемы» нет, кто то использует JQuery и Java скриты, кто то пытается редактировать CSS, иными словами, проблему решают, кто на что горазд. Мною эта проблема была решена другим образом — созданием редиректа, решение оказалось быстрым и эффективным.

Читайте также:  Инструкция по настройке кам модуля триколор

Как скрыть сводку ответов SharePoint

В данном случае необходимо создать несколько страниц — заглушек, которые к примеру будут содержать текст аля «Извините, страница недоступна», страницы создаются стандартным методом, после создания страниц, настраиваем редирект.

Настройка редиректа в IIS для SharePoint

Редирект можно настроить используя модуль URL Rewrite, который можно установить из Web Platform Installer, который идет по умолчанию в комплекте IIS последних версий, если этого компонента нет, то загрузить его можно от сюда, оригинальный мануал по модулю здесь, после установки и перезагрузки оснастки IIS, апплет появляется в панели IIS

Адрес с которого необходимо совершить редирект:

Адрес, куда необходимо совершить редирект:

Настройка IIS URL Rewrite

Открываем URL Rewrite, создаем правило на основе регулярных выражений, выставляем параметры:

  • Request URL: Mathes Pattern
  • Using: Regular Expression
  • Pattern:

  • Action type: Redirect
  • Action Properties:
  • Включаем параметр: Append query string
  • Redirect type: Permanent (301)

Не забудьте применить правило, нажав кнопку Apply.

Источник

Перенаправление с помощью IIS URL Rewrite

Задача: необходимо настроить перенаправление домена с префиксом www на домен без www или наоборот.

Среда:

Windows Server 2008, IIS 7.5, URL Rewrite 2.0

Решение:

Url Rewrite — расширение для IIS, с помощью которого можно создавать перенаправления и обрабатывать запросы по схожему принципу работы RewriteRules в Linux.

Скачать Url Rewrite можно, перейдя по этой ссылке .

Итак, для того, чтобы создать перенаправление с http://www.site.com на site.com Вам необходимо выполнить такие действия :

1) Откройте IIS Manager, выберите домен и перейдите в меню «URL Rewrite»

2) Нажмите «Add rules» -> Blank rule с панели.

3) Настройте перенаправление.

В появившемся меню необходимо назвать перенаправление, которое будет выделятся среди остальных. Например, url rewrite.

В выпадающем списке с названием «Using» можно выбрать тип перенаправления — wildcard (предпочтительно) или регулярное (regular).
В поле «»Pattern» (шаблон) необходимо указать *. Это обозначает применения перенаправления для всех определений.
Откройте меню “Conditions” и нажмите “Add”. В меню диалога укажите следующие параметры :

Condition input:
Check if input string: Matches the Pattern
Pattern:
Ignore case: Отмечено.

После вышеуказанных действий, нажмите «Ок». Выражения, которые будут обрабатываться, мы настроили. теперь необходимо указать действие, которое будет применяться для данных выражений. В меню «Action» укажите тип действия — Redirect (перенаправление).
Action Properties — укажите http://www.site.com/
— сохраняет правильность обработки ссылки с и без www префикса.

Пункт «Append query string» должен быть отмечен. Тип перенаправления (“Redirect Type”) должен быть 301 (Permanent).

Примените данное правило, нажав кнопку «Apply». Созданное правило должно работать корректно.

Источник

URL Rewrite Extension: исправляем распространенные проблемы SEO

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

Данная статья расскажет вам, как вы можете использовать URL Rewrite Extension для того, чтобы исправить кучу распространенных проблем в SEO, которые могут быть у вашего сайта. Вам потребуется всего 15 минут и не нужно вносить какие-либо изменения в коде, чтобы применить 4 простых правила URL Rewrite для своего сайта и привлечь больше посетителей и трафика с поисковых систем. Перечисленные ниже приемы работаю одинаково, как на ASP.NET Web Forms, так и на ASP.NET MVC сайтах (и даже не на ASP.NET сайтах)

Замеряем SEO-уровень для вашего сайта с помощью Microsoft SEO Toolkit

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

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

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

Две важных вещи, которые оценивают поисковые системы на вашем сайте для релевантности поиска:

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

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

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

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

Ниже я перечислю 4 примера самых распространенных проблем, которые могут по неосторожности возникнуть и привести к различным ссылкам на один и тот же контент.

Проблема №1: Документ по умолчанию
Проблема №2: Регистр символов в URL
Проблема №3: Слеш туда, слеш сюда
Проблема №4: Базовые адреса

Как легко исправить перечисленные проблемы за 10 минут, используя IIS Rewrite

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

Хорошие новости заключаются в том, что эти 4 проблемы устраняются с помощью URL Rewrite Extension. Это полностью бесплатное расширение от Microsoft для IIS 7.x (на Windows Server 2008/R2, Windows Vista/7). А теперь новость еще лучше – вам не придется изменять код в вашем приложении.

Читайте также:  Настройка эмулятора ppsspp для god of war

Вы можете легко установить URL Rewrite Extension за 3 минуты, используя Microsoft Web Platform Installer (бесплатный инструмент, которое автоматически настраивает веб-сервера и машины разработчиков). Достаточно нажать на зеленую кнопку “Install Now” на странице URL Rewrite Spotlight для установки на вашей машине:

Установив дополнение, его иконка сразу появится в IIS 7 Admin Tool:

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

Обратите внимание, что в списке сразу отсутствуют какие-либо правила. Мы можем нажать “Add Rule” в правом верхнем углу панели для добавления новой логики URL Rewrite для нашего сайта.

Пример №1: Обрабатываем вариант документа по умолчанию

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

Давайте рассмотрим, как создать данное правило. Начнем с нажатия “Add Rule”, как показано ниже:

Мы выберем шаблон “Blank Rule” в группе “Inbound rules” для создания нового собственного правила URL Rewrite. А далее увидим пустую панель:

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

Шаг №1: Имя для правила

Первым шагом будет задать имя правилу. Следует задать разумное название, чтобы легко ориентироваться в списке в дальнейшем. Давайте назовем данное правило “Default Document URL Rewrite”:

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

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

Ниже мы зададим нужное регулярное выражение:

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

Объединив все элементы регулярного выражения мы получим работающее правило не только для корня веб-сайта (http://scottgu.com/default.aspx), но и для других поддиректорий сайта (http://scottgu.com/photos/default.aspx). Так как установлена галочка “ignore case” (игнорировать регистрозависимость), то работать будут оба варианта адреса “Default.aspx” и “default.aspx”.

Одной из приятных встроенных функций является возможность оттестировать шаблон — “Test pattern”:

Выше я добавил адрес “products/default.aspx” и нажал “Test”. Мы сразу же получили результат выполнения правила по отношению к данному URL-адресу.

Шаг №3: Установка перманентной переадресации

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

Выше, я задал выпадающему списку “Action Type” действие “Redirect”. “Redirect Type” будет HTTP 301 Permanent переадресацией, что гарантирует следование поисковыми системами за переадресацией.

Я так же задал свойство “Redirect URL”:

Оно означает, что мы хотим переадресовывать запрос веб-клиента по новому URL-адресу, откидывая от оригинального URL последнюю часть “Default.aspx”. Например, для запроса http://scottgu.com/default.aspx переадресация будет на http://scottgu.com/, а для http://scottgu.com/photos/default.aspx будет http://scottgu.com/photos/.

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

Шаг №4: Сохраняем и применяем правило

configuration >
system.webServer >
rewrite >
rules >
rule name =»Default Document» stopProcessing =»true» >
match url =»(.*?)/?Default\.aspx$»/>
action type =»Redirect» url =»/»/>
rule >
rules >
rewrite >
system.webServer >
configuration >

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

Шаг 5: Тестируем правило

Заметили, что вторая ссылка автоматически переадресовывает на первую.

Пример №2: Регистр символов в URL

Мы можем исправить это добавив новое правило IIS Rewrite, которое автоматически переадресовывает любого, кто перейдет на первую ссылку, на вторую. Как и раньше, мы зададим HTTP переадресацию, как перманентную:

Для создания правила, нажмите снова кнопку “Add Rule” в административной панели URL Rewrite:

В отличии от предыдущей ситуации, где мы создавали “Blank Rule”, мы воспользуемся встроенным шаблоном правила “Enforce lowercase URLs”. Когда мы нажмем “ok”, то увидим следующий диалог, который попросит подтвердить наши намеренья:

После нажатия “Yes”, мы получим готовое правило, которое автоматически выполняет перманентную переадресацию, если входящий URL содержит заглавные буквы, на URL с полностью прописными буквами:

Мы можем сохранить правило ничего не изменяя, нажав кнопку “Apply” и применить его ко всем входящим URL-адресам.

Так как мой сайт www.scottgu.com использует ASP.NET Web Froms, мне предстоит внести небольшие изменения в представленное выше правило, добавив условие, которое исключает встроенного в ASP.NET обработчика “WebResource.axd”. URL для обработчика WebResource.axd будут приходить только от серверных элементов управления на моих страницах и никогда с внешних сайтов.

Хорошая новость – добавить условие, которое отключает URL Rewrite правило для некоторых URL-адресов очень просто. Нам нужно только развернуть группу “Conditions” в форме:

Далее жмем кнопку “Add”:

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

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

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

configuration >
system.webServer >
rewrite >
rules >

rule name =»Default Document» stopProcessing =»true» >
match url =»(.*?)/?Default\.aspx$»/>
action type =»Redirect» url =»/»/>
rule >

rule name =»Lower Case URLs» stopProcessing =»true» >
match url =»[A-Z]» ignoreCase =»false»/>
conditions logicalGrouping =»MatchAll» trackAllCaptures =»false» >
add input =»» pattern =»WebResource.axd» negate =»true»/>
conditions >
action type =»Redirect» url =»>»/>
rule >

rules >
rewrite >
system.webServer >
configuration >

Тестируем правило

Заметьте, что первый URL-адрес, у которого присутствует заглавная буква “А”, автоматически перебрасывает на URL в нижнем регистре.

Пример №3: Слеш в конце

Мы можем исправить это, добавив новое правило IIS Rewrite, которое автоматически переадресует любого, кто перешел по первой ссылке(у которой нет в конце слеша), на вторую. Как и раньше мы зададим HTTP переадресацию, как перманентную: та

Для создания правила, нажмите снова кнопку “Add Rule” в административной панели URL Rewrite:

Инструмент администрирования URL Rewrite содержит уже готовый шаблон правила “Append or remove the trailing slash symbol”.

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

После нажатия на “OK” мы получим готовое правило.

Как и с предыдущим правилом нижнего регистра, мы добавим дополнительное условие, которое исключает из правила WebResource.axd адреса. В итоге в web.config файле мы получим:

configuration >
system.webServer >
rewrite >
rules >

rule name =»Default Document» stopProcessing =»true» >
match url =»(.*?)/?Default\.aspx$»/>
action type =»Redirect» url =»/»/>
rule >

rule name =»Lower Case URLs» stopProcessing =»true» >
match url =»[A-Z]» ignoreCase =»false»/>
conditions logicalGrouping =»MatchAll» trackAllCaptures =»false» >
add input =»» pattern =»WebResource.axd» negate =»true»/>
conditions >
action type =»Redirect» url =»>»/>
rule >

rule name =»Trailing Slash» stopProcessing =»true» >
match url =»(.*[^/])$»/>
conditions logicalGrouping =»MatchAll» trackAllCaptures =»false» >
add input =»» matchType =»IsDirectory» negate =»true»/>
add input =»» matchType =»IsFile» negate =»true»/>
add input =»» pattern =»WebResource.axd» negate =»true»/>
conditions >
action type =»Redirect» url =»/»/>
rule >

rules >
rewrite >
system.webServer >
configuration >

Тестируем правило

Теперь, когда у нас готово правило, давайте его протестируем:

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

Пример №4: Базовые адреса

Мы можем исправить это, добавив правило IIS Rewrite, которое автоматически переадресовывает всех, кто переходит по первой ссылке (с “www” префиксом) на вторую. И снова переадресация будет являться перманентной.

Для создания правила, нажмите снова кнопку “Add Rule” в административной панели URL Rewrite:

Инструмент администрирования URL Rewrite содержит уже готовый шаблон правила “Canonical domain name”.

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

Выше, я ввел первичный адрес, который хочу использовать для веба: scottgu.com. После нажатия на “OK” мы получим готовое правило в web.config файле:

configuration >
system.webServer >
rewrite >
rules >

rule name =»Cannonical Hostname» >
match url =»(.*)»/>
conditions logicalGrouping =»MatchAll» trackAllCaptures =»false» >
add input =»» pattern =»^scottgu\.com$» negate =»true»/>
conditions >
action type =»Redirect» url =»http://scottgu.com/»/>
rule >

rule name =»Default Document» stopProcessing =»true» >
match url =»(.*?)/?Default\.aspx$»/>
action type =»Redirect» url =»/»/>
rule >

rule name =»Lower Case URLs» stopProcessing =»true» >
match url =»[A-Z]» ignoreCase =»false»/>
conditions logicalGrouping =»MatchAll» trackAllCaptures =»false» >
add input =»» pattern =»WebResource.axd» negate =»true»/>
conditions >
action type =»Redirect» url =»>»/>
rule >

rule name =»Trailing Slash» stopProcessing =»true» >
match url =»(.*[^/])$»/>
conditions logicalGrouping =»MatchAll» trackAllCaptures =»false» >
add input =»» matchType =»IsDirectory» negate =»true»/>
add input =»» matchType =»IsFile» negate =»true»/>
add input =»» pattern =»WebResource.axd» negate =»true»/>
conditions >
action type =»Redirect» url =»/»/>
rule >

rules >
rewrite >
system.webServer >
configuration >

Тестируем правило

Обратите внимание, что первый адрес (с “www” префиксом) автоматически перебрасывает вас на второе URL, у которого префикс отсутствует.

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

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

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

Изменять ваши правила URL Rewrite в будущем довольно просто, редактирую файл web.config или используя административную панель IIS 7.x:

Нажатие по любому правилу откроет редактор, который поможет изменить и сохранить любое правило.

Итоги

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

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

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

Источник

➤ Adblock
detector