Weekly SEO Recap: Google & HTTPS, Bing no longer nice

Joost's weekly SEO recapAn interesting week this one, including an update that seems to have quite a bit of impact. There are also some nice new features in Google Trends, possible labels for slow loading sites and some more annoying news about Bing and keywords.

A Google update

It wasn’t Panda, it wasn’t Penguin, though both are still “to come”, but this week we had an update that gave several people in the SEO industry a shudder. Mozcast, which measures changes in the search results for a fixed set of keywords and calculates a “temperature” based on that, had one of its “warmest” days ever.

Dr Pete over at Moz wrote a post, thinking this change could be related to the HTTPS changes Google did earlier. This was quickly refuted by Googler Gary Illyes on Twitter. And of course, most SEO bloggers stopped thinking at that point and just wrote down that it wasn’t HTTPS related. I disagree with that. I think Googlers don’t necessarily always know anymore what causes something to happen.

Google’s algorithms are, in part, self-learning. They automatically determine factors that cause a site to be trusted. This week, Wikipedia started moving to HTTPS entirely. If more and more sites that Google trusts, like Wikipedia, the FBI and now also Reddit, all are on HTTPS, that factor might automatically become more important, simply because of that machine learning. So while Googlers might say they haven’t changed the algorithm, the algorithm might have changed itself. Note that Gary’s tweet said “AFAIK”. They do that more and more when talking about the algorithm. Simply because they don’t always know.

Of course, this is just a theory, and it would not explain all of the changes, but nothing ever does. My own thoughts on HTTPS haven’t changed much since January last year.

More Google news

Google did more this week. Google Trends got a nice update, including both real time data and data for YouTube. You should definitely just have a play with that for a bit. This Wired piece on it is good. Another interesting bit was that Google UK confirmed that more than half of their searches and YouTube views now happen on mobile. Have I reminded you to get your site ready for mobile enough now?

There was some fuzz the last few weeks about a Google backed company getting a penalty and then being reinstated in the search results within a week. Apparently John Mueller of Google said that everyone could get back this quickly. All you have to do is do a “fantastic job of cleaning these things up” and send in a “great” reconsideration request. I’ve spoken to a few SEO’s who do cleanups for sites that got penalized the same way this company did. No one had ever seen it happen, but that doesn’t mean it’s impossible.

Google is once again testing a “Slow to load” label in the search results. It’s hard to reproduce tests like that, probably in part because where I spend most of my time online, at work and at home, I have either 4G Internet or a 200 mbit fiber connection. Doesn’t really make sense for Google to show that label on those connections.

Another update from Gary Illyes making me kinda scared was this one. He said this:

Please be mindful with noindex directives and remember that most search engines will honour it, even if it’s in the BODY element.

Which brings back all sorts of bad thoughts in me, wanting to leave meta robots noindex elements in comments on posts. It’s a good reminder nonetheless. Another tweet from Gary pointed to new breadcrumbs documentation, unfortunately it doesn’t answer some of the questions I had from the old documentation so I’ve send another email to Google.

Bing stops being nice

I’ve always had a soft spot for Bing, in part because they employ Duane Forrester, who is a great guy doing Webmaster outreach there. I have to admit they’ve made me lose some of those warm feelings this week when they announced they were no longer going to pass on search queries (part of them also moving to HTTPS completely). In their words:

to further protect our users’ privacy, we will not include the used query terms.

I think that’s nonsense, because just like Google, they will give them to advertisers. I wrote a scathing piece about that on SEObook when Google announced that in 2011. This is no different. Of course Bing doesn’t really send most sites that much traffic anyway, so most of you won’t (and/or shouldn’t) care.

That’s it for this week!

We still have an action on our site reviews, for a little while longer you can get $100 off. See you next week!

joost signature

This post first appeared as Weekly SEO Recap: Google & HTTPS, Bing no longer nice on Yoast. Whoopity Doo!

WordPress SSL setup tips & tricks

WordPress SSL SetupAs we’re now running a plugin shop here on yoast.com, selling our Video SEO plugin, Tag optimizer and soon more, we also have a checkout page. I wanted that checkout page to run on https, for obvious reasons: people fill out their email and, depending on their payment method, their credit card details there. That deserves more security. It turned out not to be as simple as I wanted it to be, but I fixed it. This posts documents my mistakes and issues with my WordPress SSL setup in the hope of preventing you from making them.

You might think: couldn’t I just always load that image over SSL? Yes you could, but that’d be slower, which is why I chose not to do it.

Getting an SSL certificate on your server

This is by far the geekiest bit of this entire process, and not something I want to explain completely. In fact, I didn’t even do this myself. Just like all other VPS.net customers, you can get a free Comodo SSL certificate, all you have to do is file a support request for your VPS. It’s one of the reasons why I think VPS.net delivers the best WordPress hosting out there. BTW, they’re running a special at VPS.net, giving away Amazon gift cards for new VPSes, so if you’ve been thinking about switching, now’s a better time than any to switch to VPS.net.

I had already set up the free certificate a while back, as I wanted to run my WordPress admin over https, but I decided to go for a Extended Validation certificate today. This is a certificate that doesn’t just show an SSL icon in the browsers location bar but actually gives a green background for it and adds the company’s name, like so:

extended validation SSL certificate

Of course this isn’t needed for every site, but I think it’s worth testing if you sell products. It provides just that bit of extra trust that can be so needed for online transactions.

Next: forcing SSL on that one page

There are plugins that can do this for you, most notably WordPress HTTPS, but as I wanted a bit more control and understanding of what was happening, I decided to code it manually. The code consists of two bits, this bit forces the checkout page to be on https all the time and at the same time redirects all pages that do not need to be SSL to an http URL:

function yst_ssl_template_redirect() {
	if ( is_page( 123 ) && ! is_ssl() ) {
		if ( 0 === strpos($_SERVER['REQUEST_URI'], 'http') ) {
			wp_redirect(preg_replace('|^http://|', 'https://', $_SERVER['REQUEST_URI']), 301 );
			exit();
		} else {
			wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );
			exit();
		}
	} else if ( !is_page( 123 ) && is_ssl() && !is_admin() ) {
		if ( 0 === strpos($_SERVER['REQUEST_URI'], 'http') ) {
			wp_redirect(preg_replace('|^https://|', 'http://', $_SERVER['REQUEST_URI']), 301 );
			exit();
		} else {
			wp_redirect('http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );
			exit();
		}
	}
}
add_action( 'template_redirect', 'yst_ssl_template_redirect', 1 );

If you’re sure the URL will always be “clean”, as in, without parameters, this can be even simpler, but in this case I needed it to work with the URL parameters that Easy Digital Downloads uses. The number 123 is the ID of the checkout page, you should of course replace with your own page ID if you use this code.

Now we also want get_permalink to return the right URL, so let’s filter its output:

function yst_checkout_page_ssl( $permalink, $post, $leavename ) {
	if ( 123 == $post->ID )
		return preg_replace( '|^http://|', 'https://', $permalink );
	return $permalink;
}
add_filter( 'pre_post_link', 'yst_checkout_page_ssl', 10, 3 );

This way if something links to the checkout page, the redirect isn’t even needed as the link is already an https link.

MaxCDN, W3 Total Cache & SSL: a golden trio

My favourite WordPress CDN provider MaxCDN, works great with W3 Total Cache. It does so even with SSL, if you know how to set it up. It’s very bloody simple too once you know it: for each CNAME, you enter not just the CNAME, but you follow it by a comma, and then enter the SSL version. For me, this looks like this (click for larger version):

WordPress SSL Setup: W3TC MacCDN SSL settings

This settings makes W3 Total Cache use the first hostname for http requests, and the second one for https. With a rather image heavy site like this one that’s a golden thing.

Broken SSL: fixing links in theme files

broken SSLIf you load a page over SSL, all the other files that are loaded on that page should also be loaded over SSL for it to not be “broken”. This means that every single image, javascript file, stylesheet etc. needs to be loaded over SSL. WordPress will fix a lot of this for you, but you’ll probably encounter some issues, as did I, causing a broken SSL icon in the location bar, as shown above here.

In my case, within my theme’s stylesheet, I was loading a google web font file. That shouldn’t be an issue, of course, but I was loading that font file over http, instead of using what’s called a protocol relative link. Every time you’re embedding images, javascript or CSS files, you should be using a protocol relative link. Instead of linking to:

http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600

I’m now linking to:

//fonts.googleapis.com/css?family=Source+Sans+Pro:400,600

As you can see, I left out the http:, this will make the browser use the current protocol to fetch that file. This means that when a user is on plain http, it’ll use that, which is faster, but if the user is on https, it’ll use the safe https link.

Bonus: WordPress SSL setup for the admin panel

Now that you’ve set all this up, you might as well use that SSL certificate for your admin too. That part is actually pretty easy. Just drop this in the wp-config.php:

define('FORCE_SSL_ADMIN', true);

That’ll force the entire admin over SSL, which is what you want in most cases. If that is too slow for you though, you could also decide to just force the login page over SSL:

define('FORCE_SSL_LOGIN', true);

This will force the login and registration pages to be SSL. I think you should go for the first option though, and run your entire admin over SSL.

Conclusion: WordPress SSL setup is easy, do it!

With all these tips, there’s really no reason anymore why you couldn’t run any page where a user submits private data on SSL. So, just do it!

WordPress SSL setup tips & tricks is a post by on Yoast - Tweaking Websites. A good WordPress blog needs good hosting, you don't want your blog to be slow, or, even worse, down, do you? Check out my thoughts on WordPress hosting!