Как лучше всего поддерживать и управлять быстрой перезаписью URL-адресов в IIS 6?
У нас есть ряд URL-адресов, которые необходимо переписать для целей SEO, и этот список становится довольно длинным.
Я хотел бы знать о хороших стратегиях перезаписи URL-адресов, чтобы мы могли сохранить старые URL-адреса, но 301 перенаправить их на более дружественные для SEO URL-адреса. Каковы последствия для производительности используемой вами системы перезаписи URL?
IIRF работает, реализовано как фильтр ISAPI в C, очень быстро. СВОБОДНО. Может выполнять 301 редирект, а также перезаписывать. (иногда и то и другое для одного и того же URL).
Он включает установщик и документ CHM:
Если у вас есть доступ администратора к серверу, вы можете использовать ISAPI_Rewrite. Это фильтр ISAPI, который вы настраиваете в конфигурации IIS6. Есть платная и бесплатная версия, но я использовал только бесплатную версию.
Я использовал его на нескольких сайтах, чтобы делать то, что вы хотите, и я не вижу никаких проблем с производительностью с ним (хотя я официально не тестировал).
Чтобы настроить перенаправления, вы должны добавить запись для каждого из перенаправленных URL-адресов в файл ISAPI_Rewrite .ini. Синтаксис очень похож на mod_rewrite для Apache, но не совсем такой.
Примеры с сайта ISAPI_Rewrite:
# Translate my-super.product.html to /Product.aspx?ProductID=123
RewriteRule ^/my-super-product\.html$ /Product.aspx?ProductID=123
# Rewrite numeric URLs
RewriteRule ^/Products/P([0-9]+)\.html$ /Product.aspx?ProductID=$1 [L]
Вам следует проконсультироваться с документация для более тщательного использования.
Хотя мы используем Apache вместо IIS, у нас были аналогичные проблемы с производительностью из-за большого количества перенаправлений. Мы внедрили следующую систему:
Любые страницы, которые необходимо перенаправить, обычно генерируют ошибку 404 Not Found, поскольку они больше не существуют, поэтому мы обрабатываем перезапись только на 404. Это означает, что у нас нет потери производительности для обычных запросов.
Как только страница генерирует 404, мы передаем запрос нашему контроллеру 404, который проверяет (кешированную) таблицу db и отображает заголовок перенаправления в браузер. Если подходящей страницы не найдено, мы отображаем обычную страницу 404.
Поскольку перенаправления хранятся в таблице, мы можем интегрировать их в нашу cms, например предоставление возможности управлять всеми перенаправлениями на страницу из свойств страницы. Или автоматическая проверка перенаправлений, указывающих на несуществующие страницы.