We've now completed our change to serving content via HTTPS only. Hopefully most people won't notice much difference.
API users who are having problems (if your app won't handle a redirect to the HTTPS URL) should update the URL they're accessing and use the HTTPS version of our API pages.
Shortened URLs are now always returned from our site and API in HTTPS format (rather than plain HTTP as previously). This is the first step in our plan to only serve pages via HTTPS, which I posted an advance notice about back in January.
For now all our pages are still also accessible via HTTP, while we monitor the impact of this change.
The site will be down for maintenance on 8 May 2016 from 01:00 UTC, while I update and reboot various servers. My initial estimate is that this will take about 2 hours.
Update: This has been done and the site is back up. It was a bit quicker than anticipated, with the total downtime being about 45 minutes.
Our host are upgrading their power infrastructure, which requires powering down servers on a rack by rack basis. As this will affect some of our key database servers, we expect downtime during each of the windows listed below. Apologies for any inconvenience caused.
All times are in GMT/UTC. We expect actual downtime to be less than the window given (probably a few hours each time).
- 01/02/2016 22:00 - 02/02/2016 06:00
- 03/02/2016 22:00 - 04/02/2016 06:00
This is an advance notification that we intend to serve pages only via secure HTTPS in future. We plan to make this switch on or around 1st May 2016.
The only change that the majority of our users will notice is that we will start returning HTTPS shortened links rather than HTTP ones after we switch. All existing shortened links will still work, we will seamlessly redirect them.
API users should ensure that their apps are prepared to receive HTTPS shortened URLs in response to a shortening request. They should also either ensure that their apps are prepared to accept a redirect to the HTTPS version of the API URLs, or modify them to only access the HTTPS versions (which are already available).
Link statistics are offline temporarily while we replace failed hardware in one of our stats servers. I will update this post when this work has been completed. Assuming there are no unexpected issues, I expect them to be available again later today.
Update: This has now been completed and stats should be functioning again.
is.gd and v.gd are now more picky about what URL formats they will accept. Certain malformed URLs, URLs containing unencoded spaces, and URLs with protocols that aren't on the IANA list of assigned schemes will no longer be accepted for shortening.
Developers using our API will need to ensure that URL parameters are properly encoded (our API documentation has always stated this and gives guidance on it) to avoid running into problems.
The reason for tightening up these rules is that lately we've seen spammers linking to malformed URLs that only certain browsers will accept. Some browsers are very flexible in this regard (for example Chrome seems to accept IP addresses that are written partly in decimal and partly in hexadecimal notation). Some non-standard formats were also difficult for us to parse, reducing the effectiveness of our usual anti-spam measures.
If you notice any cases where the shorteners are now rejecting valid URLs that should be accepted, please let me know the specific URL concerned and I'll look into it.
Apologies for the recent performance problems with is.gd and v.gd, which have both had sporadic availability over the last couple of days.
This was due to a twofold issue with much higher than normal traffic causing performance problems (probably a DoS attack) combined with a problem with one of our web servers, which exacerbated the issue by always returning error responses to our cloud distribution service, causing it to not even attempt to serve some requests.
We've now partially fixed this, and will be monitoring performance of the site going forward until we're sure it's completely resolved.
I'm pleased to report that HTTPS access should finally be working fully again for both is.gd and v.gd. There were some configuration issues between us and the CDN that we're using to mitigate DoS attacks - however we've now resolved this.
Several users have reported that visiting is.gd links posted in Twitter feeds currently sends users to a "The site you were trying to visit may be unsafe" page. Twitter also appears to not be accepting new posts containing is.gd links. Our own testing also confirms these issues.
This warning is implemented on Twitter's side, and we don't currently know why they've decided to flag all is.gd links in this way. I've made several attempts to get in touch with Twitter's support staff regarding this, and will post an update should I get a response (unfortunately it appears hard to get hold of a real human).
Update 26/10/2014: This now appears to have been resolved, and is.gd links seem to be working on Twitter again.
We anticipate some periods of downtime next week. This is due to our host powering down servers in certain racks in order to make improvements to their power feed infrastructure. We currently expect these windows to be 20:30-21:30 UTC on 21 October, 19:45-20:45 UTC on 22 October and 22:00-23:00 UTC on 22 October.
It's very likely that impact on our service will extend beyond these windows, as our DB servers have a large cache and can take some time to properly reinitialise. These periods may also vary or be extended without notice should our host encounter any unforeseen issues.
Update: This maintenance was cancelled by our host until they resolve some reliability issues that cropped up during their testing. As such the above is no longer correct, and we expect no downtime. We'll make a new post once our host is able to reschedule this work.
We've decided to no longer allow linking to hosts by their IP address (e.g. http://188.8.131.52/my_link) - a domain name is now required. This is because we see a great deal of abusive use of this type of link, and comparatively little legitimate use.
Apologies for the intermittent downtime and performance issues today (18 August). This was partly due to a bunch of malicious traffic aimed at us (which recently isn't very unusual), but mainly due to a system configuration issue which meant our servers were using more resources than expected to deal with the requests. I've made some changes and believe this has now been resolved.
We expect some intermittent performance issues and downtime over the next week. This is due to our host doing a staged physical move of their servers to a new data centre.
is.gd has been experiencing a sizable denial of service attack today, resulting in our host having to temporarily suspend access to it to mitigate the effect on their network.
They're working hard to resolve this, and will have things up and running again as soon as is practical. Although this issue is beyond our control, I'd like to apologise to users for the downtime and the inconvenience.
Update 20/05/2014: Sorry for the extended downtime, we haven't forgotten about this and the issue is still being worked on. The reason for the delay is that we're implementing a 3rd party DoS protection service to prevent a recurrence of the same issue. This has been further complicated by problems obtaining administrative control of the domain to change the configuration (the body in control of the .gd registry has changed, resulting in us not being able to make changes via the company we originally purchased it from and our accounts with them). We're well on the way to getting this resolved, but time zone issues with talking to the new registrar haven't helped.
I appreciate these issues and delays are frustrating for is.gd's users. We're doing all we can, and have to make sure we're properly protected from further high bandwidth DoS attacks in future before restoring service.
Update 03/06/2014: The site has been up and running for the last week or two since my previous update and this should now be resolved. Hopefully the measures we've put in place will help to mitigate future attacks. We haven't yet restored HTTPS access due to some configuration issues, and plan to get this done soon.
is.gd and v.gd are now accessible via encrypted HTTPS connection at https://is.gd and https://v.gd respectively. All the sites' features (for example creating shortened URLs via our API) are also available at the equivalent HTTPS URL.
Shortened URLs you generate using the HTTPS site or API are still returned as basic HTTP URLs to avoid confusion. However both versions of shortened URLs will work, so feel free to use the HTTPS variant if you prefer.
As a reminder, while this feature encrypts the connection between you and us, you still shouldn't be using our URL shorteners to link to unprotected confidential information. All our shortened URLs are publicly accessible, and a 3rd party could easily guess the URL you're using.
We've updated the abuse email address on our contact page and have also made some changes to our email hosting arrangements. There was a transition period of a few hours when some emails we were sent may have been bounced. If you attempted to contact us today and were affected by this, please resend the relevant email.
We've also made a slight tweak so that standard HTTP requests for URLs we've disabled as spam now return a 410 HTTP response code (this does not affect requests via our API, which work as before). This change is to improve compatibility with some 3rd parties who report abuse to us, and shouldn't impact typical users in any way.
For the reasons given in my previous post, I've now gone ahead and reduced our rate limits. The most significant change is that shortened URL creations have been limited to 200 per hour (4,800 per day).
Applications should wait for a few minutes before retrying when we send them a rate limited response. Our rate limiting algorithm will now penalise apps that ignore this - the wait time before we'll service their requests again increases with each additional request. This can stack up to as much as half an hour if a machine continues to send hundreds or thousands of requests while rate limited.
This is an advance warning to developers that I plan to substantially reduce our API shortening limits in the near future. I haven't decided on the exact numbers, but we'll likely limit shortening to a maximum of a few thousand URLs per day instead of the current 43,200.
The reason for this is that unfortunately we've seen a lot of abuse of our current generous limits by automated software. For example numerous small business websites are using a social bookmarking plugin that submits all their site URLs for shortening on every page load, without any user interaction. A few cases of this wouldn't bother me, but many sites each submitting tens of thousands of URLs per day for shortening that they don't actually need is a major waste of our resources. As a free service without 3rd party advertising, it's important to manage our costs and give everyone a fair chance, rather than allowing a tiny number of users to suck up a disproportionate amount of our resources.
We've temporarily disabled link statistics while our host replaces a failed disk in one of our stats servers. I will update this item when the work is complete.
Update 05/09/2013: This has now been completed and statistics reactivated - sorry for the slight delay!
Fixed a minor bug that prevented redirects working for very long URLs close to our length limit (around 4,000-5,000 characters long). Thanks to Adam Bergmark for bringing it to my attention.
We had a brief period of poor performance/dropped requests for around 10 minutes at about 02:10 UTC today. This was due to me completing the work of bringing new servers online by deleting some data that was no longer needed from the older servers. Although they were still up, the extra disk IO of this work caused some performance issues with the site.
The good news is that this completes the work I've been doing over the last week or so to add servers and reduce the impact our backup process has on performance. As such hopefully performance should be more predictable going forward and I won't have to post any updates for a while (fingers crossed!)
I need to restart software on some of our database servers in order to make some configuration updates. This is aimed at improving our backup process to impact performance less.
This will be today (27 March) at around 1-2 AM UTC and may cause various kinds of disruption for up to 15 minutes.
Update 27/03/2013 02:12 UTC - I encountered various unexpected delays/problems while doing this that I hadn't anticipated and had to perform crash recovery on a server. This resulted in around 30 minutes of complete downtime I hadn't planned. Apologies for the inconvenience.
Unfortunately the site was down between approximately 07:30 UTC and 09:30 UTC today due to a network infrastructure failure at our host and the necessary hardware replacements to repair it.
Memset have significant upgrades to their core network planned in the coming weeks - the introduction of additional spare capacity should hopefully help to avoid this type of issue in future.
We've just brought several additional front end web servers online which should hopefully improve our resilience and and responsiveness. They appear to be serving requests as expected, but it's always possible I could have overlooked something when configuring them, so do let me know if you notice any weird problems!
I'm also planning to bring some extra database servers online soon and make a few tweaks to our DB configuration. This may require a brief service disruption, so I'll make an additional post in advance with the expected time/date of that when I'm ready to go ahead with it.
Unfortunately we've had some issues with poor page loading speeds/dropped requests for several hours today. This has been due to extremely large numbers of malicious requests (probably from a botnet) placing abnormal load on our servers. We've made some tweaks to mitigate this and will continue to monitor the situation.
One of our host's upstream providers is currently suffering a congestion issue on one of their circuits. This is resulting in degraded performance for us and may result in some slow or dropped accesses to the site for some users, although our testing suggests the vast majority of requests are still being served.
Our host is working with their upstream providers to resolve this as swiftly as possible, so we expect normal service to be resumed shortly.
Update 17/08/2012 16:20 UTC - this has now been resolved.
Unfortunately we've recently seen a number of phishing campaigns using is.gd links to redirect users to fake login forms hosted at Google Docs. It's a shame the scum of the Internet always seem to find a way to abuse every handy service!
As part of our goal to protect users from this type of scam as much as we can, I've decided to make all shortened links to Google Docs go via our preview page first. I'm conscious of the fact that this is inconvenient for legitimate users and requires an extra click, so hopefully this can be a temporary measure.
Update 25/08/2012 - I've disabled this measure again now and allowed links to go straight to Google Docs destinations. If I see significant abuse I may reintroduce it.
Updated again 22/09/2012 - I'm afraid the Google Docs phishers have returned, so I've decided to reactivate the enforced preview page on these links for the forseeable future. This is why we can't have nice things!
I will be updating some of the software running on our servers tonight (25-26 January). Link statistics may be inaccessible for up to a few hours due to a database software upgrade. There should be no effect on any of our core functionality (accessing and creating shortened URLs) if everything goes according to plan. I will update this post once these changes are complete or if I encounter any unexpected issues.
Update: This work is now complete and link statistics should be functioning as normal.
A bug in our caching system caused URLs containing quotes or apostrophes to appear to have an extra backslash in them after shortening. The good news is that they were still stored in our database correctly, so would "fix themselves" after 10 minutes or so when the incorrect cache entry expired.
I've now fixed this bug - thanks to Brian Johnson for noticing it!
Previously v.gd and is.gd wouldn't accept URLs without a dot in as valid. This is no longer a requirement if you specify the protocol yourself within the link. Thanks to John Jiang for bringing this to my attention.
Hopefully fixed a very minor bug where some browsers would incorrectly show the v.gd icon for is.gd links in their toolbar or bookmarks list. This was a cosmetic issue and didn't affect functionality.
I've added a new form to report shortened URLs that are being used against our terms on the contact page. This should allow us to improve our process for dealing with these by adding a warning page to URLs that have been reported but we haven't yet had chance to manually check, as well as eliminating duplicate reports. Please let me know if you notice any problems with this new form or have any feedback on it. You're still welcome to email us abuse reports instead if you prefer, and we have no plans to remove this.
I've added the original long URL to the creation page for reference. This makes it easier to avoid mistakes in copying/pasting, especially when using is.gd in multiple tabs at the same time. The long URL is deliberately not hyperlinked to minimise the potential for confusion. Thanks to Shirley for suggesting this change.
It's been brought to my attention that several devices that read URLs in QR code form don't interpret them properly and always treat the URL as if it was all in lower case. This can cause issues with QR codes to is.gd links, where the case is significant (http://is.gd/example and http://is.gd/EXAMPLE represent two different URLs). As such I now recommend using our functionality to generate links all in lower case (or specifying a custom URL that's all lower case) when working with QR codes. I've added a tip whenever a user generates a QR code to give information on this.
You can also read more on the story that prompted this change (we've since pointed the lower case version of the URL in question to the intended destination).
We've seen a problem today with a significant number of Tumblr blogs being redirected to point at a shortened URL that we'd already disabled due to malicious use (phishing related). This redirection is outside our control and appears to be a Tumblr site issue, so affected users who can't access their blogs will need to resolve it with their support. We've also reported this to them and have been assured they're working on it.
As a stopgap measure I've redirected affected traffic back to Tumblr's front page instead of showing them the "URL disabled" page on our site they were previously seeing, since this was causing users to assume we were responsible and generating vast amounts of support emails for us.
We've raised the size limit for URLs to shorten from 1,000 to 5,000 characters. This is because some services (e.g. Google's new "search by image") had started using URLs over 1,000 characters long, so our previous limit was looking a bit stingy. Thanks to Ryan Feeley for letting me know about this.
There will be a short period of service disruption this evening since I will be making some changes to the database to facilitate raising the length limit we have on URLs. This may prevent the creation of certain custom URLs if the URL you pick happens to reside in the table I'm editing at the time. It shouldn't affect basic random shortened URL creation. If you do see any issues creating certain custom URLs please wait 10 minutes and try again.
We will experience some brief downtime next Thursday (16 June) since our host will be refreshing some of their core network switches with new hardware. This will most likely be minimal and last just a few seconds, but there is a possibility it could take up to 15 minutes. This work is planned some time between 21:00 and 22:00 UTC.
I finally got around to listing a few pieces of software and browser plugins that support is.gd on our (rather empty) software page. I know there are dozens (if not hundreds) of applications using is.gd but I can't recall most of them offhand so please contact us if you've developed such an application or if there's one you find particularly useful so that I can add it to the list.
I'd especially like to see some software on there that offers v.gd as an option as well since it's currently less widely supported. Any apps that support some of our newer API features like custom shortened URLs would also be welcome additions.
Just a heads up for users that we have blacklisted all .co.cc links due to widespread abuse in email/Facebook spam campaigns etc. I don't usually post about sites we've blacklisted here but felt it was necessary in this case since some users may not realise that co.cc is not an official top level domain but is privately owned by a Korean company that offers free redirection services. This allows spammers to register any number of 'domains' via the site for free. It remains our policy to blacklist other URL shortening or redirection services to prevent this type of abuse (see our spam policy).
It took a little longer than we anticipated (around an hour and a half due to some minor network configuration issues), but I'm happy to announce that this work has now been completed and stats should be available again for all of our links that have this feature switched on. Thanks for your patience.
The work mentioned previously affecting statistics will be done today (4th May) instead, so we expect link statistics to be unavailable for around 1/2 hour. Sorry for the lack of notice, our provider couldn't fit this in when I previously stated and I figured it was best to get this work out of the way now while they had a window to do it. This doesn't affect our core functionality, so should only affect a small subset of users that are using link statistics and happen to be looking them up during this period.
There will be a short downtime affecting URL statistics only this Friday (22 April) while some of our servers are moved to a new rack. This won't affect visiting or creating shortened URLs at all. Only statistics on shortened URLs (viewing and collecting) will be offline. We expect this to last for around 30 minutes.
I've had a few requests over the years for a feature that allows users to see a list of the URLs they've shortened recently. The main reason I didn't implement this before now was due to privacy concerns and not wanting to go down the path of a user account system.
I feel I've now come up with a way to implement this which is a good compromise and avoids tracking this data on our servers - it will store up to 10 of your most recently shortened URLs in a cookie on your own PC which we can then use to display a (hopefully) helpful list. Assuming you've shortened some URLs with us and have cookies enabled, you'll see a link to this on the front page of the site, just below the "Shorten" button.
We're just testing this out right now, so please let me know if you notice any problems with this functionality, have a way we could improve it, or have a strong opinion about whether we should or shouldn't continue to offer this in future.
Today I've rolled out a completely redesigned cache architecture which should give the site faster and more consistent performance across the board. This might not be very noticeable to users since it wasn't exactly slow before, but shortening and looking up URLs may seem just a fraction snappier.
Some other functionality has also been slightly improved/changed, specifically: -
- Link access statistics are now updated in real time instead of at 5 minute intervals (remember stats are optional and you'll only get them if you selected them from the "Further options" menu when you created a shortened link).
- Our standard randomly generated shortened URLs are now unique (if you shorten the same long URL multiple times, you'll keep getting the same shortened URL back). This doesn't apply to custom shortened URLs (because it makes no sense) or to URLs with stats enabled (we always generate new ones for these so that the stats are meaningful).
- Made a minor user interface improvement where the descriptive text in the "Further options" field is properly tagged as a label and is clickable, giving a wider area to hit with mouse clicks and making these a bit easier to use (thanks to Marco Banfi for the suggestion).
If you notice any problems or bugs have been introduced, please let me know.
Update 11/03/2011 - fixed a minor bug with the new system, further increasing performance.
Around 1/4 of our users experienced downtime of our sites for several hours today. This was due to the cumulative effect of two different failures. Firstly one of our frontend web servers stopped responding - normally our system would automatically fall back to our other working servers and this wouldn't cause a problem. Unfortunately today the process on our load balancer which handles this automatic failover had itself stopped working, which caused around 1/4 of our users to continue to be continually directed to the failed server and to see the site as down.
These events also occurred just after 3.00am for us here in the UK, which obviously doesn't help! The site is now fully up and running again, but we'll be looking into why this issue with our load balancing process happened and taking steps to prevent a recurrence of this problem. Apologies to any users who were affected by this outage.
I've been keeping a close eye on the performance and usage of the detailed link access statistics we've been providing on is.gd for a week (since we changed to the new platform). This feature is not particularly widely used (the vast majority of link stats are never looked up) but uses a lot of resources to provide due to the massive amount of accesses is.gd links get (over 10.8 billion so far!). This is somewhat at odds with our green mission and seems like a waste of resources.
As such instead of tracking accesses to all shortened URLs, I've decided to make logging statistics on access an optional feature that you can choose (via the "further options/custom URL" menu) when creating a link. I think it makes more sense to have this as an option since a lot of our users don't care about stats and many of our shortened URLs are automatically generated via our API or are intended for one time use only.
Due to this change, stats tracking has been defaulted to off on all existing links. If you were using this feature on any links you created recently (or have any legacy links you want it enabled on) drop me an email with a list and I'll be happy to switch it on for those links - this will also restore access to any previously collected stats.
Made yet more updates to the site! I've now made the FAQ and other docs consistent with the fact that v.gd has link previews by default but is.gd doesn't. You can optionally turn on automatic previews for all is.gd links you visit using our preview control page.
It's possible a few users might get sent to the automatic preview page without having turned it on (hooray for bugs), this is due to an issue with cookies from the old site. If you experience this please either use our preview control page to turn the feature off or clear your browser's cookies.
I added a hint to the URL creation page to make it clearer to is.gd users how to access statistics on their shortened links - I'm not actually too fond of the current process and will think about whether it's possible to improve it further e.g. by showing users their recently shortened links somewhere and offering stats on them.
Last but not least I got rid of the coloured boxes for URL creation on the frontpage for both is.gd and v.gd and went back to using plain text boxes. This was because most of the feedback I got on these agreed that they looked quite tacky and they also didn't display too well in Safari.
I've decided not to introduce link preview pages as the default on is.gd and to leave it so that is.gd shortened URLs send users straight to the destination site by default. This is partly due to the issues it caused with using is.gd URLs that were embedded in pages as images or other content and partly as a response to the feedback I've had from users (the overwhelming majority were against this change). Thanks to everyone who emailed me to make their opinions on this known.
v.gd will retain link preview pages as the default option since it's always had them so doesn't suffer the same drawbacks with legacy embedded content or functioning differently to how users expect.
Some of the options and documentation on is.gd are inconsistent with this change at the moment since it's not what I originally planned to do - I'll be sorting it out over the next few days as well as adding functionality so that users can optionally turn preview pages on if they want them, which was available on the old site.
After reading through my clogged email inbox, it's become apparent that the link preview page we've added to legacy is.gd URLs in order to increase confidence and reduce the potential for abuse has unforeseen issues for people who use the site in certain ways. As an example, people were linking to is.gd URLs directly within image tags, which although it's probably not a great use for a URL shortener, is something I'd prefer not to break. The preview page was also confusing for non-English speakers.
Although I think it's a good idea in principal, I've disabled link previews on is.gd for the time being due to these problems. I plan to think it over for a couple of days and decide whether there's a better implementation and whether having these by default is a step forward or not. Drop me an email if you have an opinion on this. In the meantime, if you want to see a preview page for a shortened URL or get to your URL's stats, add a hyphen (dash) to the end to force the preview page to appear e.g. http://is.gd/example-.
We discovered and fixed another configuration issue that was affecting performance, so the site should be a fair bit faster now and perform more like you'd expect. All is.gd's content should be migrated to the new platform and working as expected now, hopefully people are enjoying the new features. I'll continue to monitor things and will look over any feedback we get and respond to any reports of problems.
We've resolved an issue with uneven load balancing which seems to have brought things back to life. Performance still isn't as snappy as I'd like - I think we may have underestimated the amount of frontend web servers necessary to handle is.gd's traffic. I'll continue to look into and monitor this, and if necessary we'll be bringing more web servers online over the next few days to ensure is.gd and v.gd are as speedy as they should be!
As you've probably noticed, we've finished moving is.gd's URLs to our new architecture and are redirecting requests to the new site. We're noticing some performance problems (specifically with load balancing) and are looking into these at the moment, so apologies for slowness/pages not loading. I'll post an update shortly once we've managed to resolve this or have further information.
This update is technical in nature and details are given for the benefit of developers.
Made an update to send further search engine crawlers and automated services to destination URLs instead of to our preview page (in addition to major search engine bots we added this for previously). This behaviour has now been extended to anything that identifies as "bot", "crawler" or "spider" in its user agent string, as well as to some additional URL lookup libraries such as cURL and urllib.
I will probably tweak this further in future, but my intention is for automated services to go straight to the destination but humans browsing the web to get the preview page by default. This is so automated web crawlers can understand our shortened links more easily and so link credit is passed along by search engines appropriately.
If you're developing an app that actually wants to look up the destination of our URLs rather than being redirected, please use our published URL lookup API.
Made a security update since there was a way to trick users into disabling our link preview page without their interaction by having them visit a certain URL. This functionality has now been tweaked slightly to fix this bug.
Made lots of changes behind the scenes over the last couple of days to prepare for is.gd's migration onto v.gd's architecture. These were mostly changes with templating so that certain documentation pages will change to refer to the appropriate site they're being viewed from when the time comes. This shouldn't have changed any functionality, so if you do notice any new problems or inconsistencies as a result of these changes please let me know.
Also fixed the very minor (but slightly annoying) issue where the advanced controls/custom URL box appeared briefly while our homepage was loading before disappearing. The page should load more cleanly now.
I've now set a provisional date of 12 January 2011 to migrate is.gd over to the same new architecture that v.gd already uses. After this migration is complete is.gd will have access to the same new features v.gd already enjoys such as custom URLs and improved link statistics. Users of is.gd's API in particular may wish to read further details. Assuming everything goes according to plan we don't anticipate any downtime for v.gd on that day and there shouldn't be any impact on the service.
I noticed today that due to an oversight on my part search crawlers following our shortened links were getting to our default preview page. This was bad since it caused them to just index our preview page over and over instead of the destination and also because it wasn't giving the destination sites "link credit" for SEO purposes.
I've now added a fix for this by serving up a 301 (permanent) redirect instead of a preview to crawlers for the major search engines, including Google, Yahoo and Bing. This will ensure link credit and destinations are passed along appropriately.
We're determined to run our URL shorteners ethically, and I think the actions we've taken in this area are one of the most important things in making v.gd a great URL shortener to use, both now and in future. I've added some information on the ethics of v.gd to the site which I hope will give a good idea of what direction we're going with it and how we plan to continue.
Many of the points in there also apply to is.gd but I feel our strong ethics are something we haven't made enough noise about in the past and something many people weren't aware of. We'll be featuring our policies more prominently from now on (hence the link on the front page)!
Made a minor update since it was difficult for users who had disabled the automatic preview page to get to their URL's statistics without going through the long process of turning it back on again. Adding a dash (-) to the end of a shortened URL will now force the preview page to appear even if you've previously disabled it e.g. http://v.gd/example-.
I'm very excited to announce the launch of v.gd, our new URL shortener. It has various improvements over its sister service is.gd (other than the domain being a character shorter) including custom URLs, more detailed URL statistics, an improved API and a distributed backend to make sure we can expand easily as use of the service grows. If you want to learn more a great place to start is our FAQ page which already has a wealth of information on v.gd.
If you're a die hard is.gd lover don't worry, I intend to move that site over to the same architecture in the next couple of months so it can benefit from the same improvements once we've got any teething problems worked out.
Since v.gd's code is a complete rewrite it's possible there might be some bugs or performance issues that didn't show up in our early testing. If you notice any problems or bugs with v.gd please get in touch and I'll get to work on swatting them as soon as possible.