0

I am interested in technical considerations I should mind to safely switch my naked domain to a www. subdomain. By safely I mean things like not loosing SEO (redirects will suffice?) or avoiding some redirect loops (I imagine it's not hard to screw this up).

I would like to switch to a www subdomain, as I plan to scale the site up and would like to make use of cookie-less static.mydomain.com subdomain. (Yes, I know I could buy a separate domain for that, but I prefer not to.)

I am aware any cookie that has been already set on the naked domain will be sent to static.mydomain.com anyway. I'm interested in the solution nevertheless, even if only for the future users.

This question is not about DNS setup or server config, but rather general technical considerations I should care about when doing the switch.

If this helps anyone answering the question, feel free to inspect the cookies sent on the current naked domain: http://zadrutowani.pl

I'm aware it's non-SSL, I'm about to drop Wordpress altogether. Currently it's a WP on Apache, it'll be a custom solution on Nginx.

Tim
  • 30,383
  • 6
  • 47
  • 77
karni
  • 111
  • 5
  • 1
    I would simply do a redirect from zadrutowani.pl to www.zadrutowani.pl in your nginx's config (example there; http://stackoverflow.com/questions/7947030/nginx-no-www-to-www-and-www-to-no-www) – yagmoth555 Feb 09 '17 at 14:06
  • Thank you for your comment, @yagmoth555 ! I recognise it may actually be that simple. Was just afraid whether this may have other repercussions I may not be immediately aware of. I guess it circles back to "simple is usually the best" :). Let's see if anyone else got something to add. Cheers! – karni Feb 09 '17 at 15:33
  • Is HTTP the only protocol in use, or do folks SSH or whatnot in to the not-www name? – thrig Feb 09 '17 at 15:50
  • @thrig Great question. I will be the only person SSH'ing in. I don't plan on using ftp (for known reasons), though I do plan on sending mail using @ zadrutowani.pl domain, if that matters (I admit I have least knowledge of the mailing part, currently simply using a mailbox at gandi.net that I pop3 into gmail, I'll need to add SPF). I find your question very interesting. Could you expand on the reasoning behind it? Would love to learn what you were going for :). If I'm not mistaken, using either naked domain or www. variant would not affect the use of SSH (default port 22 vs 80). Thank you! – karni Feb 09 '17 at 17:32
  • 1
    I've done similar moves where it turned out users were doing a SSH to the bare domain name and they ended up confused because they were connecting to the wrong thing post-move. Usually better to sort these things out in advance rather than afterwards. – thrig Feb 09 '17 at 17:41
  • Although your question is well-suited on ServerFault for the technical aspects, you might ask want to take a look and ask on http://webmasters.stackexchange.com where there thousands of questions with regards to [SEO](http://webmasters.stackexchange.com/questions/tagged/seo) as that is usually not a concern of ours... – HBruijn Feb 09 '17 at 17:45
  • Ha, that's some great input indeed! Yes, in my case it's no issue, but I'm sure future readers of this question will appreciate your comments :)! FWIW I plan to do the switch over (of both naked and www) one night, whenever the MVP will be ready. Until then, will be SSH'ing via IP. Thank you, @thrig! – karni Feb 09 '17 at 17:47
  • Ah, I see! Thank you @HBruijn for your guidance. I shall do that as well! – karni Feb 09 '17 at 17:48
  • 301 redirect will preserve your SEO efforts, at least most of them. However I'm not sure the move is worth doing. Sure a subdomain may receive root domain cookies, but is that really important? It can just ignore them and the overhead is likely to be minimal. – Tim Feb 09 '17 at 17:51
  • Hi Tim! I recognize the yes/no-www debate is heated, therefore the decision wasn't an easy one. The argument that shifted weight for me was the cookie aspect (with www., cookies aren't sent to static., hence less data sent [agree, small difference], which in turn is faster [just a tad]; also the high availability/DNS aspects of www. as opposed to naked domain, although I'm only planning one load balancer). I may consider storing session encrypted in cookie client-side, at which point the cookie size would be more significant I suppose. One of stateless app server strategies (if not just Redis) – karni Feb 09 '17 at 18:00
  • Perhaps trying to squeeze so much info in a comment made it less readable. What I meant was, if the cookie size was larger (say, session encrypted in the cookie, if I choose that way over sessions in Redis) and we had more users, perhaps the amount of transferred data would no longer be negligible? – karni Feb 09 '17 at 18:01
  • Ah, I've also read cookies sent to static.* may prevent from proper request caching, although I don't have enough knowledge to support this argument. Maybe it also depends on the infrastructure setup. – karni Feb 09 '17 at 18:04
  • 3
    Your site sent me no cookies. Go ahead and flip the switch. – Michael Hampton Feb 09 '17 at 18:51
  • 1
    Related: [The 301 'www' nightmare. How do I change back?](http://serverfault.com/q/451348/126632) – Michael Hampton Feb 09 '17 at 18:53
  • @MichaelHampton It's quite amazing the author of yes-www answered my question :) (and thank you for yes-www btw!). Your comments and the answer in the related link give me confidence what I should do next (I also have 301 there and that's exactly what I was afraid of (!), but I grep www.zadrutowani.pl of apache access logs had zero hits \o/ ). – karni Feb 10 '17 at 01:29
  • 1
    Ah, I have Google Analytics blocked on this browser. In any case that ought not to matter much. You can change the canonical site URL in your Analytics admin settings for the site. – Michael Hampton Feb 10 '17 at 01:30
  • If I understand correctly, only the two Google Analytics cookies could be sent to static.zadrutowani.pl in the future (for old users, which I don't mind). Perfect, thank you! @MichaelHampton I would be happy to accept your comments as an answer. Or should I write the answer on my own and credit you? :) – karni Feb 10 '17 at 01:31
  • 1
    I'm sure many people could answer the question now. Including yourself. :) – Michael Hampton Feb 10 '17 at 01:32

1 Answers1

1

I'm answering the question myself to save the readers having to go through the comments :) (Thank you to all involved!)

In particular case of my naked domain, the only cookies the site sent was Google Analytics (or none, if you had GA blocked in the browser). Hence, @MichaelHampton (btw, the author of yes-www) advised it should be safe to flip the switch and simply add www.

Note there may be an issue for users, who you may have redirected from www to the naked domain before with a 301. In case you'd redirect the naked domain to www now, there could be a redirect loop, of which case is documented here: The 301 'www' nightmare. How do I change back?

However, by inspecting the apache access logs I noticed none of our (30k+ unique) users accessed the site through www subdomain, therefore the 301 redirect from www to naked domain is a non issue.

Additionally, assuming URLs are properly redirected to the new www subdomain (in case adding www is no the only thing you're changing), this should not affect SEO. Remember to change your preferred canonical address in Google's Search Console.

Thank you, Michael Hampton :)! Your comments where key here.

Community
  • 1
karni
  • 111
  • 5