The main thing you'll want to make sure is that all your JavaScript libraries and images are loading from HTTPS and not HTTP. If you don't, the browser may not load those resources or may show your site as not secured. The default Analytics code will do this for you, but make sure your other libraries are doing so. A great tool for finding any you've missed is Firebug, a Firefox addon. You open it up, load your website and on the Net tab you can see the URL of every resource loaded and even break them down by type (image, JS, etc).

Analytics itself is not affected by HTTPS. Your metrics will continue to load just fine.

There really isn't any practical difference. Here's the raw HTML so you can see

[Your Link Here](some url) OR Your Link Here

vs

[Your Link Here](some url)

Google's bot will parse the URL and note it as a link.

At the bottom of this post there's a button that says Email Updates. If there's no check in that button, you won't get any updates about your thread.

The bulk of his argument could be summed up as "Fresh content usually wins". It has some merit. But the rest of the article could be taken as saying "Game what you can now and move on."

SEO is a subset of marketing. It always has been and always will be. SEO is where you market to the search engines.A major part of Google's problem is we don't have any idea what constitutes what they like anymore. So his guess about it all being about freshness sounds good until you find searches where that's not true. But you CAN produce quality content and still lose the SEO game. But you can lose the SEO game and still win the war.

The danger for this guy is that he seems to advocate link spam. He heavily caveats it but offers no real reasons not to engage in it. I have no doubt link spam still works. The question you have to ask yourself is "Do I want to build something on top of that which Google is trying to actively destroy?" If you can live with being a flash in the pan, go for it. Make your money and then watch as Google throws it in the garbage. And hope that the next time around they're just as gullible.

A CNAME is a DNS record that says that domainA.com lives where domainB.com is. That means you then do another lookup on domainB.com and get its A record. Somewhere down the chain you have to have an A record. An A record is what ties a domain to an IP.

The problem here is that a CNAME is not the same thing as 301. If you go to the CNAME as mentioned above, your browser will still say domainA.com. We use a CNAME because we have a load balancer with AWS. So our site resolves to a CNAME that resolves to the load balancer address but it still shows up as www.ourdomain.com. We have dozens of URLs like this pointed to the same hosting configuration and each domain is seen as the original TLD. This will cause duplicate content problems for your client.

The correct solution is to set them up with an A record pointed at a web server and then have your web server return a 301.