Temporary Domain Changes

[dapacifi]

Hi All,

Our development team needs to do a temporary site name change from www.sitename.com to new.sitename.com and then wants to return to www.sitename.com. They need to do this for the whole site due to how it's built with single sign on (SSO) and how certain post login pages utilize pre login pages and need to keep people logged in. This process is changing with a CMS upgrade and website and post login pages will be independent of the pre login pages moving forward.

My question is what is the best way to manage this transition? Right now it seems like the best solution I've been able to work out with development is to reduce the domain shift down to one week and use 302 Redirects, don't index the new.sitename.com site, and for that week and take my lumps as they come from search. Looking for any other suggestion that may help marketing work with dev without casting blame on any teams for drops in organic traffic.

[K.Dempsey]

Hi everyone
I'm in the same boat too. If either Tim or Dan (or anyone else) have any learnings besides the advice shared here please do.

Thanks, Kayley

[tldev]

Hi Dan,

I was wondering how this all turned out for you? I'm in a similar boat right now.  Any advice you can share?

Thanks,

Tim

[dapacifi]

Thanks Paul,

I'll try to make sure to keep an eye on this site move as it's much different than any other site moves i've implemented and it's incredibly tricky.

Dan

[ThompsonPaul]

I suspect your idea for 302ing to the temp new URL is probably the best you can do given the circumstances, Jeff. The alternative would be to leave the domain the same and have all pages return a 503 header with a Retry After header indicating a time span after the return to the normal site. But this is more invasive and probably more prone to errors. If the 302 redirect stays in place for too long, search indexers may start to consider it permanent despite the 302 status, but keeping it to one week likely shouldn't cause this.

My suggestion from a marketing perspective - I would make the temp site be something like www2.sitename.com instead of "new". This way, most visitors are unlikely to even notice. If they see the "new.sitename.com" site for a week, then are put back on what they now consider the "old" site - they may think they're getting shortchanged or something is wrong that they're no longer getting the "right" version of the site.

The other thing to make sure you've checked on - what other 3rd-party integrations/tools/advertising networks/analytics etc will need to be addressed while the redirect is in place? (For example, Adwords and many ad platforms don't look kindly on ads that redirect from their display URL to a new URL.) So make sure you've checked out and adjusted for any of those. Your SSL certificate and SMTP/site notification email sending functionality are other examples.

And yea, communication and setting expectations will be key here. If the devs truly can't accomplish what they need to any other way than such a major upheaval, everyone needs to be clear that all steps will be taken, there is a plan for the move, for the return, and for monitoring and trying to compensate afterwards (like maybe some extra PPC ready to go if a significant traffic drop will require recovery time?). But there are significant unknowns and while every effort will be made to minimise impact, things beyond your control will have possible negative effects and it's impossible to know in advance how severe they might be. You'll want a clear communication plan for all stakeholders of each of these steps in advance. You don't want to be trying to come up with the communications while in the middle of the process.

Sounds like an opportunity for an interesting case study - be sure to let us know how it goes. Good luck!

Paul

[Edited to add - verifying a new GSC property for the new subdomain(but not submitting any sitemap or fetch) would be a good idea. That would let you monitor whether any of the site was getting indexed. Then as soon as the site goes back to normal and the temp site is 301-redirected back, you could use it to declare a change of address back to the main site to help get any of the temp URLs out of the index faster, (assuming any get indexed) ]