6

Wondering if there are any negative implications to using a redirect on my own domain as a kind as a URL Shortener.

I am often asked by folks creating printed documents for "short URLs". My predecessor did this by using a 301 Redirect. The practice seems wrong to me, but am not able to explain why.

6

The only real downside is that if you set up a lot of redirects, it can eventually start to be a load on your server. Since servers vary widely, along with traffic and code performance, there's no magic number as to how many redirects is too many. Anecdotally, I manage a website with ~ 220,000 pageviews a month and we typically have 200-300 vanity redirects in place along with over 800 other lines in .htaccess at any given time, with no performance issues. I've managed much higher-traffic sites without negative repercussions as well. If you're worried about the performance, take site speed measurements before and after adding a batch of redirects to ensure you're not impacting performance, but generally speaking unless you're on a low-performance shared host, you shouldn't see problems with these simple redirects. Simple one-to-one Redirects aren't very performance-expensive, as compared to something like a RedirectMatch which is where you typically start to notice more performance impact.

If you're using a CMS, I would suggest looking into whether or not there may be a plugin available to add this type of redirect. That way, you are empowering your marketing folks to set up their own redirects - and that way they will also be able to see what redirects already exist, as eventually people may forget what's already been set up. Plugins like this vary in quality and functionality - some do 302s, some 301s, some can also begin to have performance issues once you hit a critical load of redirects. But it will save you a lot of time versus manually editing your .htaccess file every time someone wants a new vanity URL.

A word of caution: it helps to set up naming conventions before you start setting these up. Decide up front whether you want to make all vanity URLs all-lowercase (since typing them in manually from a printed piece is simpler if they are all-lowercase) or whether you want to allow title case. Decide whether you want to prefer hyphens (seen as SEO-friendly and easy to find on mobile keyboards) or underscores (more old-fashioned but maybe they match your full URLs) and whether you have any hard character limits for how long a vanity URL is allowed to be.

Finally, something else that may be of use for these printed pieces: look into Google's UTM parameters. If anyone will at some point find it helpful or interesting to measure how many people actually type in a certain URL from a particular printed piece, have them set up a separate vanity URL for every print medium they use. So for example, you could have example.com/tx-offer which redirects to

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

and also example.com/ks-offer which redirects to

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

so in effect they both go to the same landing page, but the utm_source and the other parameters tell you whether the Kansas magazine or the Texas magazine - perhaps with the same creative - sent more actual visitors to your website. This of course is only useful if you're measuring such things in Google Analytics, but it's fairly common and free to set up. This may in turn help people better understand which print pieces are more successful. This is another thing you want to standardize if possible before you begin - decide whether you want to stick with lowercase for convenience, or perhaps uppercase, to track your campaigns. You might even get more granular than "print" for media (magazine vs. newsletter, etc.) or you may want to group all "print" media to more easily compare them in one view. Even if you're not working on paid campaigns, it may help you determine where to spend more time and money - say postcards perform much poorer than your newsletter, so maybe you don't have web CTAs on postcards anymore.

4

I think this is a good idea overall, certainly better than using third party shorterners but there are some things you may want to consider.

  1. How will you actually implement the redirects, a web server config file is one way but it doesn't really scale particularly well to large numbers of urls. A script based soloution can be more flexible and handle a large range of urls but at a potentially higher overhead per redirect issued.
  2. Do you really want to use 301? or do you want to keep flexibility at the cost of slightly more sever load by using 302?
  3. How will you manage the possibility of conflicts between regular urls and redirects (I have seen some sites use a dedicated domain, which avoids this issue and allows the shortened urls to be even shorter but has the potential for user confusion over where the link is legit) .
  4. Do you want a system that can make the redirects case insensitive so you can publish title-case urls but still get the visitors who forget to press the enter key?
2

There are likely advantages to using URL shorteners on your own domain instead of a service who will do it for you.

For one, 301 redirects are known to pass 90-100% of link juice. So when a link goes from urlshortener->example.com/page, example.com may not capture 100% of the link juice as some may be lost onto the urlshortener service. Whereas if you use your own service, the lost link juice likely retains on your own domain.

Htaccess redirects are considered slow, but we are talking about milliseconds. It's possible that a url shortening service may be optimized to be faster for redirects than your own servers, but the time difference is likely to be barely noticeable. It also takes extra time to load a page for each server/domain request that is needed. With a url shortening service, multiple server requests are required in order to load your page, whereas your own short url only requires one server request.

There is also brand awareness. When a person sees a link for a urlshortener, he doesn't see your brand name. Whereas when he sees example.com/url your brand is displayed in the link, especially when the link is also the anchor text.

Likewise, Google does not crawl every link that it discovers. And while this may be speculation just based on my own thoughts, when it discovers an example.com link, it may count that as a brand mention. It also may even pass example.com some trust score just by acknowledging the link despite not crawling it. When the urlshortening service has their own domain as the link, this opportunity is lost.

It seems that most of the major brands have moved away from urlshortener services as they appear to be a lot more popular a few years ago. It's quite possible that their use of them was excessive, and potentially a mistake. Some of the urlshortener services offered some nice data analytics traffic to go along with it which is probably a large reason as to why some large sites were using them.

Also, Twitter used to count url size against it's maximum tweet character count, and so having a shorter link on Twitter instead of a longtail link was hugely important. And Twitter's rising popularity at the time probably had a lot to do with urlshorteners becoming a big trend. But this isn't the case anymore as url size no longer counts against character count on Twitter.

  • 5
    Using redirects on an external site is going to require additional DNS queries, opening an additional socket, and maybe another HTTPS negotiation. It is almost guaranteed to be faster to do redirects on your own domain. A redirect on your own domain should add 10 to 100 ms. A third party redirect is going to be 50 to 150 ms overhead. – Stephen Ostermiller Apr 11 '18 at 22:51
2

A common feature of URL shortener services are statistics for each redirect (you could try to extract this information for your own redirects from your server logs as well, but it might be quite tedious). Since you have mentioned printed documents: This is of course commonly used for getting usage feedback for printed ads etc., so it might be of interest for your folks?

That said: there is more than one solution out there for hosting your own URL shortener service on your own domain. You‘re not necessarily tied to using an external service to have a convenient URL shortener.

If done right, even hosting a CMS and a URL shortener on the same path is possible - just make sure that URLs are distinguishable (e.g. by using a prefix or such).

0

There is no real downside and in fact many sites are using URLS which can be shortened, like /1234/my-article-about-goats/ which at least can be loaded using /1234/goats/ and /1234/g/ but often even as /1234/.

You should consider to make these URLs your canonical URLs (and add them using the corresponding tag to the HTML) and only use the long "SEO-URLs" for your users. Then you may or may not redirect from the numeric only version to the long version.

Keep in mind that having less strict URLs matching can lead to people changing the title in the URL to /1234/my-article-about-cats/ and other people may think you like cats instead of goats. So you may want to at least redirect from urls with the wrong slug to the url with the current slug.

Another thing to consider: If you really want to implement short.mydomain/a6x style autogenerated redirects for arbitrary URLs, you need to make sure you continue to host the short URL service or you will break a lot of URLs when you discontinue it.

  • For best SEO, you should use your canonical URLs consistently throughout your site. – Stephen Ostermiller Apr 12 '18 at 10:43
0

Wondering if there are any negative implications to using a redirect on my own domain as a kind as a URL Shortener.

It really comes down to the millisecond. Why? Because one factor of great importance is a term "Time to First Byte" which means the time it takes for the first byte to be recognized by the web browser.

Using a remote service of any kind just in order to create a redirect to any of your web pages is fully disadvantageous because a) as Steven indicated, an extra DNS request is required which means additional waiting time for the client, plus you're relying on the speed of the remote computer that processes the request, so if that computer functions like an old '286 processor then using that service may cause your clients that land on redirects to wait several seconds more before they even see the first character on the screen which in today's world is terrible.

Now, what YOU can do as a webmaster is ask whoever is controlling the computer that stores your web pages to ensure it is running at excellent speed. Then you can host the redirect pages yourself on the same server. If you run your server, then make sure unnecessary background processes do not run.

Also, when you are done, make sure that any search engines you submit your URLs to will only receive the NEW URLs, not the old ones. This will minimize the need to request the old URLs that are the redirects to the new ones.

Heck, as a bonus (something I constantly do to the HTML to my site since thousands of people visit it), try to put the frequently used pages on a ram drive on the server since accessing content from ram is significantly faster than accessing it from disk. But if you do this, then you'll need a backup on disk so that if the computer resets, then the contents of ram are erased and you'll have to reload the data onto ram for max speed.

All in all, whatever you do, PLEASE use testing tools like webpagetest.org and measure your Time to First Byte. It's very important. Also, when testing, choose a location farthest away from your server as well as close by so people located far away can have a good experience on your site.

  • The RAM drive is not really needed with modern (as in the last 20 years) operation systems. When the file is accessed frequently it will be in the read cache, which is more or less the same effect as storing it on a RAM disk. If you need really many pages in RAM, you can configure the disk cache to be bigger (For details ask on serverfault.com). – allo Apr 16 '18 at 7:23
  • It also depends how that cache is configured. If its poorly configured then it could act like a windows swap file. – Mike Apr 17 '18 at 3:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.