Есть ли недостатки в использовании перенаправления 301 из более короткого URL-адреса в нашем собственном домене, а не в использовании службы сокращения URL-адресов?

Интересно, есть ли какие-либо негативные последствия для использования перенаправления на моем собственном домене в качестве вида URL Shortener.

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

5 голосов | спросил malcman 11 PMpWed, 11 Apr 2018 22:55:21 +030055Wednesday 2018, 22:55:21

6 ответов


5

Единственный реальный недостаток заключается в том, что если вы настроите большое количество переадресаций, это может в конечном итоге стать нагрузкой на ваш сервер. Поскольку серверы различаются в широких пределах, а также производительность трафика и кода, нет никакого магического числа относительно того, сколько переадресаций слишком много. Анекдотически, я управляю веб-сайтом с ~ 220 000 просмотров страниц в месяц, и у нас обычно есть 200-300 редиректов тщеславия, а также более 800 других строк в .htaccess

Если вы используете CMS, я бы предложил посмотреть, доступен ли плагин для добавления этого типа перенаправления. Таким образом, вы уполномочиваете своих специалистов по маркетингу создавать свои собственные переадресации - и таким образом они также смогут увидеть, какие перенаправления уже существуют, поскольку в конечном итоге люди могут забыть, что уже было создано. Подобные плагины различаются по качеству и функциональности - некоторые из них 302, некоторые 301, некоторые могут также иметь проблемы с производительностью, как только вы нажмете критическую нагрузку перенаправления. Но это сэкономит вам много времени и вручную отредактирует ваш файл .htaccess каждый раз, когда кто-то хочет новый URL-адрес тщеславия.

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

Наконец, что-то другое, что может быть полезно для этих печатных экземпляров: посмотрите параметры UTM Google. Если кто-нибудь в какой-то момент найдет полезным или интересным измерить, сколько людей на самом деле набирает определенный URL-адрес из определенной печатной части, попросите их создать отдельный URL-адрес тщеславия для каждого используемого ими печатного носителя. Например, у вас может быть example.com/tx-offer, который перенаправляется на

example.com/offers/september/?utm_campaign=offer&utm_medium=print&utm_source=texas-magazine

, а также example.com/ks-offer, который перенаправляется на

example.com/offers/september/?utm_campaign=offer&utm_medium=print&utm_source=name-of-kansas-magazine

, поэтому они оба переходят на одну и ту же целевую страницу, но utm_source и другие параметры сообщают вам, есть ли журнал Kansas или журнал Texas - возможно, с тем же креативным - отправил более реальных посетителей на ваш сайт. Разумеется, это полезно, если вы измеряете такие вещи в Google Analytics, но это довольно часто и свободно настраивается. Это, в свою очередь, поможет людям лучше понять, какие печатные экземпляры более успешны. Это еще одна вещь, которую вы хотите стандартизировать, если это возможно, прежде чем вы начнете - решите, хотите ли вы придерживаться строчной буквы для удобства или, возможно, заглавного, для отслеживания своих кампаний. Вы даже можете получить более гранулированный, чем «печать» для СМИ (журнал против информационного бюллетеня и т. Д.), Или вы можете группировать все «печатные» носители, чтобы легче сравнивать их в одном представлении. Даже если вы не работаете в платных кампаниях, это может помочь вам определить, где тратить больше времени и денег - скажите, что открытки работают намного беднее, чем ваш информационный бюллетень, так что, возможно, у вас больше нет веб-CTA на открытках.

ответил WebElaine 12 AMpThu, 12 Apr 2018 00:27:53 +030027Thursday 2018, 00:27:53
4

Я думаю, что это хорошая идея в целом, конечно, лучше, чем использование сторонних shorterners, но есть некоторые вещи, которые вы можете рассмотреть.

  1. Как вы на самом деле реализуете перенаправления, конфигурационный файл веб-сервера является одним из способов, но он не очень хорошо масштабируется для большого количества URL-адресов. Решение, основанное на сценарии, может быть более гибким и обрабатывать большое количество URL-адресов, но с потенциально более высокими накладными расходами при выдаче редиректа.
  2. Действительно ли вы действительно используете 301? или вы хотите сохранить гибкость за счет немного более большой нагрузки, используя 302?
  3. Как вы будете управлять возможностью конфликтов между регулярными URL-адресами и перенаправлениями.
  4. Вы хотите систему, которая может сделать регистр не зависящим от регистра, чтобы вы могли публиковать URL-адреса заголовков, но все равно получать посетителей, которые забыли нажать клавишу ввода?
ответил Peter Green 12 AMpThu, 12 Apr 2018 06:38:16 +030038Thursday 2018, 06:38:16
2

Вероятно, есть преимущества использования сокращений URL в вашем собственном домене вместо службы, которая сделает это за вас.

Например, 301 переадресация, как известно, передает 90-100% сока связи. Поэтому, когда ссылка идет от urlshortener->example.com/page, example.com не может захватить 100% сока ссылки, поскольку некоторые могут быть потеряны в службе urlshortener , Если вы используете свой собственный сервис, сок потерянных ссылок, вероятно, сохраняется в вашем собственном домене.

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

Существует также понимание бренда. Когда человек видит ссылку для urlshortener, он не видит вашего бренда. Принимая во внимание, что когда он видит example.com/url, ваш бренд отображается в ссылке, особенно когда ссылка также является якорным текстом.

Аналогично, Google не сканирует каждую найденную ссылку. И хотя это может быть предположение, основанное только на моих собственных мыслях, когда оно обнаруживает ссылку example.com, это может считаться таковым как упоминание бренда. Он также может даже передать example.com некоторый рейтинг доверия, только подтвердив связь, несмотря на то, что он не сканирует ее. Когда служба urlshortening имеет свой домен в качестве ссылки, эта возможность теряется.

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

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

ответил Michael d 12 AMpThu, 12 Apr 2018 01:11:24 +030011Thursday 2018, 01:11:24
2

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

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

Если все сделано правильно, возможно даже размещение CMS и сокращенного URL-адреса на одном пути - просто убедитесь, что URL-адреса различаются (например, с помощью префикса или такого).

ответил schwarzbrot 12 AMpThu, 12 Apr 2018 01:23:39 +030023Thursday 2018, 01:23:39
0

Нет реального недостатка, и на самом деле многие сайты используют URLS, которые могут быть сокращены, например /1234/my-article-about-goats/, которые, по крайней мере, могут быть загружены используя /1234/goats/ и /1234/g/, но часто даже как /1234/

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

Имейте в виду, что наличие менее строгих URL-адресов может привести к тому, что люди изменят заголовок в URL-адресе на /1234/my-article-about-cats/, и другие люди могут подумать вам нравятся кошки, а не козы. Таким образом, вы можете, по крайней мере, перенаправить с URL-адресов с неправильным слизком на URL-адрес с текущим слизнем.

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

ответил allo 12 PMpThu, 12 Apr 2018 12:03:22 +030003Thursday 2018, 12:03:22
0
  

Интересно, есть ли какие-либо негативные последствия для использования перенаправления на моем собственном домене в качестве вида URL Shortener.

Это действительно сводится к миллисекунде. Зачем? Потому что одним из важных факторов является термин «Время до первого байта», что означает время, которое требуется для того, чтобы первый байт был распознан веб-браузером.

Использование удаленной службы любого рода только для того, чтобы создать перенаправление на любую из ваших веб-страниц, является полностью невыгодным, поскольку: а) как указал Стивен, требуется дополнительный запрос DNS, что означает дополнительное время ожидания для клиента, плюс вы полагаясь на скорость удаленного компьютера, который обрабатывает запрос, поэтому, если этот компьютер работает как старый «процессор 286», то использование этой службы может привести к тому, что ваши клиенты приземлится на переадресацию, чтобы подождать несколько секунд больше прежде чем они даже видят первый символ на экране, который в сегодняшнем мире ужасен.

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

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

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

В целом, что бы вы ни делали, ПОЖАЛУЙСТА, используйте инструменты тестирования, такие как webpagetest.org, и измерьте время до первого байта. Это очень важно. Кроме того, при тестировании выберите место, наиболее удаленное от вашего сервера, а также рядом с тем, чтобы люди, расположенные далеко, могли иметь хороший опыт на вашем сайте.

ответил Mike 14 AMpSat, 14 Apr 2018 02:43:26 +030043Saturday 2018, 02:43:26

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132