Talking about a content delivery network and SEO in the same sentence is a tricky one. A CDN can be a huge benefit to SEO, or it can hurt your site immensely, and it all comes down to configuration.
A content delivery network is sort of like an augment or a superpower for your website. It’s a way to make a $10-a-month web hosting package feel like a $100-a-month package. So what is it, and how does it work?
When you have a website, your website is hosted on a web server owned by your web host. The host’s server might be physically located in one position, or they might have three or four mirrors around the country or around the world, but the results are the same. Whenever someone wants to load your website, they send a message to the host’s server, which responds with the website data.
This is fine if, say, the data center is in Utah and the web user is in Ohio. It still works fine if the web user is in Florida. It works a little less fine if the user is in Panama, and even less fine if they’re in China. The further away, geographically, the longer it takes messages to go back and forth.
This is especially relevant with international traffic. Traffic from somewhere in Asia has to pass through all kinds of regional servers and either via satellite or undersea cable across the ocean to reach a server in Utah, and then all the way back with the data. Depending on configurations and latencies, it’s easy for a request to get lost, time out, or otherwise fail to load. Even in ideal circumstances, it can take quite a while to load.
A content delivery network is essentially a network of dozens or even hundreds of servers, scattered around the world. When a user makes a call to your website, your website responds with two things; the basic text and data, and instructions to pull the media and/or scripts from the CDN. The user’s browser obeys those instructions and asks the CDN for the media.
Rather than having to download 100 MB of images or video from Utah, the hypothetical user in Japan pulls 1.5 MB of data from your Utah server, and the remaining data from a CDN endpoint in Japan. It results in dramatically faster loading.
For example, take a look at Amazon’s CloudFront CDN infrastructure. They have a map on their details page, showing dots where individual or multiple servers are set up. Users who request data from the CDN will be referred to the nearest CDN server, which provides the data as quickly as possible. This is fast enough to support anything from images and scripts to livestreamed video from a service like Twitch.
All of that is a simplification of the real situation, of course. It’s superficial, but it’s close enough to the core concept that you can see how it might speed up web browsing for users around the world. So how does this impact your website SEO?
First of all, page load times are a search ranking factor. The longer it takes to load your page, the worse off your site will be in the search rankings.
Now, a CDN will speed up loading the media on your site, but that speed increase may or may not be impactful to your business. It’s worth digging a little deeper to understand.
With our hypothetical data center in Utah, areas geographically close to Utah will get the best speeds. Users from more remote corners of country – Seattle, New York City, Miami – might have a harder time loading the page, but they will still load it fairly quickly. With a CDN, the speed of that load will increase, but perhaps not by more than a few milliseconds.
A few milliseconds might not be that much, though. It’s unlikely to be the single factor that’s the difference between a search ranking of #3 and #1. The American version of Google, then, is probably not going to be too impacted by the increase in speed.
On the other hand, browsers from outside the country, particularly those overseas, will see a dramatically larger increase in site loading speed. It’s a lot faster to load a video from Germany when the video is coming from a server in Germany than a server in Utah.
Consequently, you’re going to see a greater impact on non-English versions of Google. Users browsing from those other locations are going to have a larger decrease in load times, perhaps even full seconds knocked off large media files like videos. This, in turn, is a more dramatic change and will result in a greater impact on search rankings.
It’s up to you to determine how valuable this is. If you only serve North America with your shop, you don’t really care how you appear in German Google; those aren’t potential customers, not really. On the other hand, if you’re an information site, an affiliate marketer, or someone who ships internationally, using a CDN can be a huge boost to sales.
Second, in some circumstances, a CDN can increase security. What I mean by this is that a CDN can serve media in HTTPS even if the rest of your site is not using SSL encryption. We’ve written a lot about using SSL, as well as talked about the risks of site-wide SSL usage, but modern improvements to the HTTP/2 protocol and to SSL parsing have mitigated some of those risks.
Google announced that using SSL will be a benefit to search ranking, and while the benefit is still minor, it’s still a benefit. SSL on your media also help prevent malicious man-in-the-middle attacks, injected code, or otherwise corrupted media served from a shady pass-through server.
A third potential benefit is faster image indexation. Google’s image search indexes images based on their meta data and some image analysis performed by robots and spot-checked by humans. You can get a lot of traffic from this, especially since Google recently removed the “view image” button and now forces users to visit the page the image is on instead. For some sites, this can be a huge benefit. For others, maybe not so much. Still, if you’re reliant on images for a lot of your traffic, a CDN can make them show up faster, load faster, and have a better presence in the search results.
The fourth benefit, which is promoted by services like Cloudflare, is DDoS protection. A denial of service attack happens when massive numbers of users, typically bots, make requests of your server. They typically send requests for media-heavy pages if they can find them, to hammer your server with requests, overload the server, and bring down the site.
Since a CDN is serving your media, the heavy lifting of a DDoS attack is forwarded to the CDN servers instead of your own. The CDN can then implement anti-DDoS steps, which can temporarily blacklist IP ranges, block loading of your site to geographic regions issuing the requests, and so on. Plus, a CDN is able to record data about DDoSing and botnets, and can aggregate that data for the international security community, which you’re unlikely to do on your own or via your webhost when they’re scrambling to keep a server from frying.
Now, there are a lot of benefits to using a CDN, but there are some particular issues as well. Most of them come down to poor configuration or poor usage, though, and can be mitigated.
First of all, you might encounter cross-site security issues. These tend to happen if you’re running SSL on your site, but not using SSL on the CDN. A CDN can use encryption for the content they serve to a non-encrypted site, but not vice versa. If your site is encrypted, but is referring unencrypted media, web browsers will issue a warning. This can be particularly detrimental if your CDN is forwarding scripts; a cross-site scripting warning often blocks a site from loading completely.
Secondly, a misconfigured CDN can potentially cause duplicate content issues. This is pretty rare! Most every CDN sets up canonicalization for the content they host. At the very least, they have instructions for you to do it. If you’re getting duplication issues or a Panda penalty from Google, chances are you can fix it with just a couple of configuration options.
Third, a CDN might delay loading your site. This happens when you have render-blocking media attached to the CDN. Essentially, the user polls your web server looking to load the page, starts to load the page, then has to wait on the CDN to respond before the page fully loads.
This is a sign of poor implementation of the CDN. When you’re loading scripts or media, you want them to be loaded asynchronously. This applies whether or not you’re using a CDN, for that matter. You don’t want the text of your blog post to have to wait for an embedded video to load before the text appears, right? Lazy loading content is essential, whether you’re using a CDN or not.
One fourth consideration is the expense of a CDN. Now, most CDNs these days are pretty cheap. Amazon’s CloudFront is free for customers with under 50 GB of data transfer and under 2,000,000 monthly requests. For on-demand pricing, it’s something like 8.5 cents per 10 terabytes of data transfer, which is insanely cheap.
That said, any expense is more than no expense. If you’re operating on a shoestring budget, the additional cost of a CDN might not be something you want to pay. On the other hand, if you get a spike of traffic and your web host has a bandwidth camp, a CDN might be cheaper than the charges the web host levies on you. It’s certainly something to consider.
Of course, there are some free CDN options. We even wrote about them here. A free CDN isn’t going to be as robust or as useful as a paid CDN, but they’re still an option if you want something and something is better than nothing.
A fifth concern about CDNs is using a different domain for media. If your site is www.example.com, but your images are all coming from example.CDNDomain.com, some users become skeptical about the content. Others might have cross-site media blocked. Fortunately, for most modern CDNs, you can map your domain to the CDN. You essentially get a custom subdomain with CDN.example.com, so everything looks like it loads from your site. It’s not really a problem outside of a few curmudgeonly folks who are both technical enough to see the problem and not technical enough to understand it’s not a problem.
So, as you can see, pretty much every possible drawback of a CDN is something that is mitigated with proper configuration. If you’re having issues, it’s something you can find and fix, not an excuse to abandon using a CDN.
There’s one potential problem with some CDNs, in particular CloudFlare. CloudFlare is primarily a DDoS protection tool, and a CDN second. They have had some issues in the past, when large-scale DDoS attacks are going on; anyone using CloudFlare at the time might be negatively impacted. They tend to be a little overzealous with IP blocking and can block legitimate users as well. Still, that’s more of a CloudFlare problem, and not even a common problem.
The only actual problem with using a CDN comes from using a bad CDN. If you pick a content delivery network that doesn’t have reliable uptime, well, that’s the same as picking a web host that doesn’t have reliable uptime. You’re likely going with something because it’s cheap, not because it’s worthwhile, and you’ll suffer for it. Just choose a good CDN provider, cheap or free or otherwise, configure it properly, and reap the benefits.