CloudFlare is one of many CDNs available to webmasters today, and it has the ability to kick your search rankings up a notch. Used incorrectly, however, it can be detrimental just as easily. Rather than struggle to figure things out yourself, I’ve done the research to point you in the right direction.
It has long been understood that a faster loading site is more likely to rank higher in the search results. The reason for this is simple and easy to understand; people like when their Internet performs quickly. They want their data to be presented to them as quickly as possible. When a site is slow, it frustrates them and stresses them out. When it takes more than a couple seconds to load, many users will simply back away or close the tab, abandoning the page.
An abandoned page is not a good search result. Consistently abandoned pages make for unusable search results, which is the opposite of what Google is going for. They want the most value possible in the top ten results, to please people and keep them using the search engine.
There are actually several different speed metrics, though.
Site speed has been a part of Google’s search ranking since 2010. You can see the initial announcement in all its relic glory here.
One thing mentioned in that blog post that I quite like is the webpagetest website. You can run a test on any URL and it will measure how fast your site is, both on first load and on a repeat, cached load. It will show you a very nice waterfall cascade of page elements and their load order and times, as well as some additional data like how much it would cost to load your site on a mobile, data-capped connection.
If you prefer a Google-backed tool for fixing an issue that’s relevant to Google, you can use Google’s site speed tools suite. We wrote about them over here.
A CDN, or content delivery network, is a powerful server that performs some functions for your website. At the most minimal level, A CDN does what YouTube embedded videos, Facebook and Twitter embedded posts, and Akamai hosted images all do; host one piece of media so that drawing on it is not a strain on your server. Rather, when a user connect, they get data about your site from your web host, and data about the embedded media from the CDN.
CDNs are usually more potent than web hosts. The reason is that while a web host has a server bank hosted in one location, a CDN has server banks located all around the world. When a user requests something of your website, and they’re all the way across the country – or across an ocean – their data has to reach your web host servers and come back. If they request something from a CDN, the CDN provides it from their nearest data center. CDNs are also big businesses, and are capable of hosting far more with far more powerful equipment than many web hosts muster for individual clients.
You can also offload more to a CDN than just your media. Many websites choose to distribute the scripts on their site, to even those – like social sharing buttons – load extremely quickly. Some sites barely host any of their own content outside of framework, sitemap, and blog post text.
Now, some of you might be wondering how this improves things. Sure, downloading an image or executing a script will be faster, but the user still needs their connection to go to the web host. Adding connections to the CDN can actually slow your site down; the user connection needs to go to your site, bounce to a CDN, come back to your site, and go back to the user computer. It adds a step, so no matter how fast that step is, it’s not faster than not having it.
CloudFlare is one of many CDNs, and they can all be a detriment to your site in this manner. CloudFlare specifically was called out a few years ago for having terrible uptime. They’ve improved a lot over the last few years, but it’s still a risk; a CDN can route traffic after a brief hiccup; a web host prefers to have their uptime guaranteed.
CloudFlare is also used for DDoS protection. This means it acts like a filter in front of your site, to prevent unwanted traffic from dragging your site down. The trouble is, sometimes the method for doing this is to put up an error page. As far as SEO is concerned, this is very dangerous. When Google attempts to crawl a site and can’t find it, they put a flag on the site in the index. Another crawl when the site isn’t up and it can be removed from the search results entirely. Google doesn’t want sites that have disappeared to be in their results. A good site with a good history will pop back into place upon crawling the online site again, but a couple of poorly timed CloudFlare blocks can devastate a site.
So why does anyone use a CDN? Well, 99.9% of the time it’s going to work, and it’s probably going to be faster if you offload as much data as you can onto it. Some sites even host themselves entirely on a CDN, so they become virtually impossible to slow down or take down.
Essentially, CDNs are good for edge cases, but not for every site. If your web host is slow or unreliable and you can’t upgrade, use a CDN. If the user experience is slow or poor, use a CDN.
Oh, and there’s one other issue with using CloudFlare as it relates to SEO; the “bad neighborhood” effect. By default, when you put a site on CloudFlare, you are assigned a default set of settings. This includes a single IP address that is often shared with other CloudFlare users; it’s the IP of their data centers. There are also a lot of people who run CloudFlare-based spam sites; sites that aren’t valuable and that aren’t designed to do more than link to slightly more valuable sites. Google looks at this and sees 100 sites from 1 IP, all of which are spam, and decides the IP is probably spam. If you get added to the IP, you can end up with the spam label as well.
Now, Google won’t tank your site based on IP alone; it’s a risk factor. They also understand how shared hosting works and know you aren’t necessarily responsible. However, they still won’t give you quite as much trust, and as we know, trust amplifies other signals, good and bad.
That said, this isn’t an issue you can blame on CloudFlare themselves. Rather, it’s a problem with your configuration. CloudFlare does allow separate IPs; you just need to implement them. This will solve all of those problems.
So, if you’re concerned about site speed as an SEO factor and want to speed up your site, why not take another action that is more guaranteed to have a positive effect with less of a chance of backfiring? Here are some of those actions you can take.
Make your images smaller. One of the primary types of media people offload into a CDN is their images, so if you compress them and make them smaller so they’re easier to download, you won’t need a CDN as much. Images will almost always be larger than HTML files, of course, but that doesn’t mean they have to be huge HD pictures. Instead of using code to resize an image on your page, resize and compress it into a properly formatted png file for your site.
Avoid using text in images if you want that text to matter. Remember; some people won’t have the images load, and others won’t pay attention to the images. Google also can’t parse text on images and won’t include it as part of the on-page content.
Keep an eye on your plugins when you’re running WordPress. Avoid using plugins that haven’t been updated in over a year, particularly if they haven’t been updated since the last major WordPress update. Uninstall plugins that don’t have an active use, like plugin performance scanners. Remove plugins you no longer use. Avoid installing plugins that duplicate functionality, like more than one image compression plugin or more than one SEO plugin. Whenever it’s possible to use a smaller plugin with narrow functionality, use it.
Use caching to store as many of the static elements of your page on the user’s computer as possible. If your entire navigation and script structure doesn’t change, cache it so the user doesn’t need to download it every time they load a new page. The more the user has to download, the slower the site will be to load fully. The first time they load the page it will take a while, but every subsequent load until the cache expires will be much, much faster.
Try not to install a dozen different analytics suites. At most, have Google Analytics, a supplemental analytics suite, and a heatmap. If you’re not actively using or studying the data from one analytics suite, you probably don’t need to keep it installed. Analytics by necessity need to be the first thing that loads on a page, so the more analytics you have, the slower your page loads to a readable level.
Buy better web hosting with a more robust server structure and more powerful data centers. Going to a CDN works, but upgrading from a cheap BlueHost shared virtual server to a high quality HostGator or DreamHost server will be much better. If you have the budget for a dedicated server, you’ll have an even better response time.
Enable compression of page elements. WordPress and other platforms allow GZip, which compresses text and HTML files on your site before they’re sent. It’s faster to compress a file, send it, and have it uncompress on the user’s end than it is to transmit the uncompressed file, in many cases. This is partially due to how efficient the GZip compression algorithm is, and partially due to connection bottlenecks causing speed drops.
Compress your code and strip your scripts. Talk to an experienced web designer before you dig into any of this, because you can break your site if you’re not careful. Most CMS platforms and many home-coded sites have code that simply isn’t necessary. An experienced web developer can prune down that code and make it that much smaller, which means it loads that much faster.
Minimize the number of redirects that happen on your site. You might be surprised at how these can stack up. Say you have a few simple redirect rules in place, like detecting mobile users and redirecting them from www.site.com to www.m.site.com, and making sure people go from site.com to www.site.com. Now say a mobile user wants to visit site.com, which redirects to www.site.com, which redirects to www.m.site.com. That’s a lot of redirecting and slows down load times considerably.
Some of these tips will work for you, others won’t. Maybe you already use GZip, or you don’t have any redirects in place; that’s fine. Take what steps you can, to minimize the load times both to first byte and to total load, and you’ll get what little SEO value you can. If you absolutely must use a CDN, such as for DDoS protection or on very image-heavy sites, take the other steps so that you can minimize any detrimental impact it has.
As always, though, remember that site speed is a minor SEO factor. There are many other things you can do for your site that will have more of an impact, particularly with the time involved in many of these changes. Consider the cost:benefit ratio for any change you want to make.