Представьте себе, что на вашем сайте есть поиск по каталогу, выдача которого имеет адрес /catalog/search/?s=поисковый+запрос. Все замечательно работает, но в один прекрасный момент приходит специалист по поисковому продвижению и говорит, что требуется особым образом продвигать результат поиска по запросу "Котики". Для этого нужно, чтобы такая страница имела адрес /cats/, и у нее должны быть особенный заголовок и особенные мета-теги.
Вмешиваться в работу поискового механизма - это большие трудозатраты, и вообще плохая идея. Гораздо лучше воспользоваться возможностями компонента UrlRewriter.
Начало работы
Устанавливаем компонент, идем в админку по адресу /admin/url_rewriter/ (подмена урлов) и нажимаем кнопку "Добавить". Заполняем форму:
Теперь по запросу /cats/ будет выдаваться все та же страница с результатами поиска, причем если поиск поддерживает дополнительные GET-параметры, то их тоже можно передавать в новую страницу. Например страница /cats/?page=2 будет эквивалентна странице /catalog/search/?s=котики&page=2.
Заголовок страницы
Посмотрев внимательнее на страницу /cats/ мы увидим, что мета-теги установились успешно, а вот заголовок страницы остался прежним, указанное в админке значение "Котики" было проигнорировано. Это произошло потому, что в поисковый механизм не знает о существовании компонента UrlRewriter, и в шаблоне страницы выдачи заголовок отрисовывается без его учета. Поэтому шаблон нужно немного подправить:
<h1><?= Component_UrlRewriter::h1('Результат поиска') ?></h1>
Теперь на подмененных страницах будет отображаться подмененный же заголовок, а на оригинальных - значение по умолчанию, переданное параметром в функцию Component_UrlRewriter::h1.
Обратная замена
А что же делать с оригинальной страницей? Она ведь осталась работать как и прежде, т.е. у нас образовался дубликат страницы. Прежде всего, его индексацию можно запретить обычными средствами. Но что делать если специалист по поисковому продвижению настаивает на том, чтобы работа поискового механизма была изменена так, чтобы при вводе поискового запроса "Котики" пользователь перенаправлялся на страницу /cats/, а вовсе не на оригинальную страницу?
Это тоже возможно, но здесь уже придется немного модифицировать поиск. Программисту нужно вмешаться в перенаправление на страницу с поисковой выдачей и вместо того, чтобы сразу отправить на адрес /catalog/search/?s=...., сначала пропустить его (адрес) через функцию Component_UrlRewriter::href($href). Результат работы этой функции в зависимости от переданного параметра:
- При /catalog/search/?s=котики вернет /cats/
- При /catalog/search/?s=котики&page=2 вернет /cats/?page=2
- При /catalog/search/?page=2&s=котики вернет /cats/?page=2
- При /catalog/search/?s=бегемотики вернет /catalog/search/?s=бегемотики
Предупреждения
Обратите внимание, что обратная замена - весьма дорогостоящая процедура. Понятно, что есть соблазн пропустить через функцию Component_UrlRewriter::href вообще все ссылки на всех страницах и дать тем самым полную свободу продвиженцам. Но сервер от такого надругательства, очевидно, ляжет. Пользуйтесь этой возможностью только там, где есть явная необходимость.
Также и прямая замена - совсем небесплатная. Следует понимать, что после установки компонента производится проверка любого GET-запроса к любой странице. Т.е. обработка каждого запроса возросла на один SQL-запрос к базе данных.