Redirect Status Codes and Domain Registrar’s 302 Forwarders
TLDR; Always check (and double-check) redirect status codes. This is a particular useful exercise when working with clients that have changed their main URL at some point. Use a variety of tools to check the redirect status. Keep old domains registered within Google Search Console too.
When carrying out some historic SEO analysis for a few clients’ websites, I came across some interesting results regarding redirect status codes. SEO specialists are always recommending the use of server side 301 (permanent redirects) wherever possible (much to IT department’s annoyance, I’m sure) but my research here led me to discover that many domain registrar’s actually use 302 (temporary) redirects when the redirect is added within their control panel. Maybe this is common knowledge in the SEO industry, but to me it was an interesting discovery regardless.
It’s worth checking on your own or your SEO client’s sites if they’ve previously used domain names than their current one. In my case a number of clients I was working with (hotel websites) had gone through big rebrands; hotels have a habit of changing ownership on a quite regular basis, during which their company name changes completely. As a result, a completely new domain name is registered as part of the transition.
Rebranding is always tough on organic search rankings; and even if everything is done correctly from an SEO perspective, search engines still take a relatively long time to take stock of the change and to update their rankings accordingly. On top of this it can take a while for the business to recover from the rebrand – previous customers (here, hotel guests) need to be informed of the change, which is a long and difficult process, whilst online travel sites like TripAdvisor, Booking.com and Trivago will also need updating. So from a digital marketers perspective, who’s one controlling element is the technical SEO aspect of the rebrand, it’s really key that this is executed correctly. If you wanted more reading on the topic of website relaunches SeerInteractive did a good job here.
Typically as part of a website rebrand and relaunch the most important SEO tasks you’ll need to do will consist of the following:
– Setting up 301 redirects from all pages/content on the old domain, pointing to the new domain.
– Adjusting Google/Bing Business Listings to reflect the new name, and new URL.
– Adjusting your Analytics tracking tool to reflect the new URL.
– Setting up Google Search Console for the new domain (all variants of it – naked WWW & SSL, etc).
There are a whole load of other related tasks but to me those are the key ones to complete when rebranding/relaunching a website.
As part of the above then, I’d want to give all the right signals to the search engines so that they now associate any of the SEO rankings of the old hotel URL, with the new hotel URL. Therefore giving them a 302, temporary redirect status is really the one thing you’d want to avoid. Although from the user experience perspective everything is fine (they visit the old hotel website, get redirected automatically to the “new” version, and all things going accordingly they proceed to book their stay at that particular hotel). So in this instance the hotel shouldn’t notice any substantial drop in visits or revenue in the very short term. The overall impact will depend on how well the hotel has marketed this rebrand (offline as well as online), but this a topic for another day.
What about the long-term SEO impact of serving a 302 redirect vs a permanent 301? Google has quite recently stated that 302’s served over a long period may be treated the same as a 301 (can’t find the exact source here but here’s an article stating that no PageRank is lost from any 3xx’s), and Cyrus Shepard did a good job of covering this on the Moz Blog, but as he says, and Sistrix tend to agree, I wouldn’t want to risk this – plus it’s very difficult to reliably test this theory out, let alone on a client’s website.
GoDaddy and the Strange 302 Redirect Status
Because in this particular case some of my client’s sites had hundreds of good quality backlinks pointing to their old domain name (verified and checked using Majestic’s backlink tool) I naturally wasn’t comfortable that the redirects were apparently 302’s – despite what Google have been saying about them passing PageRank.
Interestingly enough, my attention was initially drawn to the redirect status from GoDaddy by noticing some strange behaviour from the Crawl Errors report within Google Search Console. There were page errors appearing here which seemingly didn’t exist on the hotel’s website, and have never actually existed. Pages consisting of a string of seemingly random characters, like /XyVsjHfC/
Screenshot showing one of the crawl errors from GSC
When crawling the site from Screaming Frog’s tool, checking on the Internet Way Back Machine, looking for broken links in Majestic, and running various other checks, I could see no reason why that would create a Crawl Error for Google (the URL never existed on the site, and had no links pointing to it that I could find). I checked Google Analytics too, just in case there was evidence of spam/referral traffic going to those strange URL’s, but found nothing. I had previously found evidence from a client’s site hosted on WordPress that spam traffic had been creating a number of extremely spammy crawl errors within Search Console (hotel.com/buy-pharma-drugs/ and so on) but that was a separate issue completely.
It was only when trying to run a Fetch and Render in Search Console using the domain name which previously belonged to the hotel when I noticed the issue – Googlebot was being redirected to those non-existent pages, via a 302 redirect – all thanks to GoDaddy’s domain forwarder (which I’ll come back to). To make things even weirder, sometimes I’d see a 301 status returned when testing the URL in Screaming Frog but then sometimes a 302 status was returned – without changing any settings within Screaming Frog! I cross-checked using various other tools like HTTPStatus and URIValet, as well as changing the User Agent to Googlebot, but the status was (mainly) a 302, and never consistently a 302.
Because there were several pages which had been indexed previously on the old hotel’s website, and they also had backlinks pointing to them still (too many to reach out manually to fix), I felt the best resolution was to setup a new hosting environment where I could place a manually built .htaccess file containing the required 301 redirects on a line-by-line basis, and then to point the GoDaddy domain to these Nameservers via their DNS manager. A long-winded solution, but IMO the best way to serve search engines with a 301 redirect status. Sadly I’ve yet been able to implement this (issues getting access to the domain registrar due to the client not having access, etc etc) but I’d be keen to see what, if any, SEO impact it has by switching the 302’s to 301’s now – this client has had this setup for around 2 years already. Is it true that Google treats 302’s like 301’s (especially if live for a very long period?) – this is something I’d love to test in more depth at some point.
A tip here – if your client is going to rebrand, and is moving away from their domain to a new one, double-check the verification method of the old domain within Search Console. If you’ve verified using the HTML file upload, via Google Tag Manager, or Google Analytics, you will need to select a different method as soon you’ll lose this verification status (probably a few days after the new domain gets launched). Having the old domain setup within Search Console will give you access to all kinds of valuable SEO info (crawl errors, crawl stats, etc).
Checking the redirect status of other Domain Providers
Because I was curious as to whether the above domain forwarding behaviour within GoDaddy was the norm or the exception, I decided to run a few tests using other domain name registrars that I happened to have access to for some of my own web projects. Here’s a table showing the redirect status when using each domain registrar’s forwarding option:
|Domain Name Registrar||Redirect Status Codes|
|123-Reg||301 or 302|
*Note – despite what the GoDaddy article says above, there wasn’t an option to select a 301 when reviewing their domain forwarder option.
Conclusion (and follow up questions) – what does this all mean?
Overall the takeaway here is that when carrying out SEO audits for a client you shouldn’t forget to review any domains that previously belonged to your client – sometimes you will need to ask them directly for this info, other-times you might have to do some digging online. Searching for the businesses phone number or address should be a good place to start (unless they’ve relocated at some point) as you may find evidence of the business having a different name and website address. With that info you can then check to see whether that domain resolves or redirects as required (using Ayima’s redirect status in Chrome is always handy for this). As always, for any backlinks from particular good sources it’s best that the link goes directly to the clients site without any kind of redirect, so in some cases it’ll be worth asking/helping the client to reach out to those sites to ask them to politely update their link. So far I’ve not been convinced that anything other than a server-side 301 redirect is the best solution here.
However, seeing how advanced Google is becoming, and hearing about the advances they’re supposedly making, I’d love to see examples (hard evidence!) that Google treats a long-lasting 302 redirect as a permanent 301 redirect – so giving as much value to it as a 301. Obviously you’d be a bit naive to willingly use a 302 when a 301 is easily possible, so it’s hard to persuade someone sane to willingly give it a try, and it’s also hard to setup a completely fair testing environment. But it’s definitely worth looking into to confirm.
If you know of any other domain registrars that 302 redirect instead of a 301 it’d be good to know – I’d happily include it in my table above (or, if you find evidence proving my findings to be incorrect, please tell me!).