I was reading a summary of topics that were presented at PubCon written by Rand Fishkin over at SEOMOz. One in particular caught my eye as I have been giving this very advice to clients for most of 2009: “Web Page Load Time can Positively Influence Rankings.”

It makes sense, doesn’t it? Google’s success is based on focusing on three key areas: user experience, monetization, and branding. Often, these principles may seem to be at odds, but it is the struggle that produces innovation. A tripod couldn’t stand if the legs weren’t pushing against each other right?

In this case, Google is focusing on user experience to feed branding, and may be sacrificing short-term revenue. In this case they may giving less focus to websites showing their content network ads and greater focus to established businesses that can afford to concentrate on optimizing load times.

The Most Important Issue in Load Times

One of my favorite anecdotes from my web career comes from a few years back when I was interviewing for a graphic designer position. A well-meaning fellow came to us with experience in ColdFusion and PaintShopPro (we were a .Net and Illustrator department at the time).

After running through our list of general questions we started asking the more existential ones, like “What is the most challenging thing you’ve ever had to do for a client?” The answer we got is hilarious to me, even today.

After a short explanation that “the web” ran on connections between machines, he launched into a short dissertation on the hex-code color system. Eventually we learned that, in his view, optimizing load times was best accomplished by taking a color which was used throughout the website (say “purple”) and gently dialing the hex codes closer to white, each time saving himself a bit of bandwidth usage (in theory).

Not only does this not make any sense from a design standpoint, it’s also fundamentally flawed from a tech-standpoint as well. But it does illustrate the desperation which plagues some designers in reducing their memory footprint.

Unfortunately, in the modern search landscape, kb-size means less and less. When you consider the cost of bandwidth (especially from Google’s perspective, who is amassing one of the largest fiber-optics collections in the world) the difference between downloading a 500kb page and a 5kb page is so small that it doesn’t matter, let alone the difference between 20kb and 18kb.

The most notorious factor now affecting this aspect of search rankings is one level deeper: it’s your server.

An Example of Server Response vs. Rankings

In 2008 I acquired a domain which had been abandoned by its previous owner. I set up a blog on that domain which stuck with the topics of the previous owner, and put in place a system which gave me 100s of pages of new content each week. By the end of 2008 the site was approximately 6,000 pages large, but with only a couple hundred pages actually indexed by Google.

During that time, the site was hosted on a shared platform. With approximately 3,000 other websites on the server, the load would sometimes spike to levels where the site was inaccessible, at least by the standards of the modern user.

I don’t have the exact numbers, but I would guess from experience that the site probably only had an 85% uptime (determined by pinging the site in 15 minute intervals). In March of 2009, I moved the site to a dedicated server.

The Not-so-Instantaneous Effects

When the site was re-launched on the dedicated server, I noticed an uptick in the number of pages indexed for the rest of March. Looking back, I would guess that these pages were considered “questionable” by the GoogleBot due to their unpredictable load times, and were suddenly being served very close to 100% of the time.

For the next month or so, nothing much happened. I believe Google was giving the site some time, the change in IP address probably tripped something on their end to wait and see what else happened.

Around May the site picked up momentum in leaps and bounds. In the space of a month I watched the number of pages indexed at Google jump from just under 1,000 all the way to the low 6,000s by the end of June. The site now stands at just over 14,000 pages indexed, which is roughly 75% of the total pages available.

Traffic similarly skyrocketed, from around 12,000 pageviews early in the year to a record 182,000 pageviews in August.

Caveats

Of course, it’s difficult to isolate the compounding variables in any SEO experiment, especially when you don’t know you’re experimenting in the first place.

There are a number of other factors that could have influenced the growth of this particular site: the fact that it now has a dedicated IP, or, since it is a blog, additional links in to popular posts. But I believe the predominant factor is the increased uptime.

Checking Server Response, and Why Load Time isn’t the Whole Game

There are many services out there that can help you monitor server performance, one of the most famous is PingDom. I’ve also used BasicState, which is a free service that sends you alerts and summaries when your server is unreachable.

It’s important to see how often your server is unreachable, not just how long it takes to load a page. You have to remember that for all the collective intelligence at Google, the menial tasks are still performed by robots.

Let’s say your site has 1,000 links coming in to it from other sites. And let’s pretend Googlebots follow those links at a rate of 10 per day, and that any given Googlebot will wait 10 seconds for your page to load before reporting that the site is gone and moving on. For simplicity’s sake, let’s also assume that all Googlebots communicate back to an Aggregator of some kind which stores data about your website.

On Day One, 10 Googlebots come by (or the same Googlebot 10 times, however you prefer to think of it). Your server is only capable of responding 8/10 times. Maybe one time it didn’t respond within 10 seconds, and one time it was actually down.

Remember, Googlebot is stupid. In the first case, Googlebot calls Aggregator and says, “The site is slow,”. In the second case, where the site is giving him a 404 error, he reads it as “Not Found” and decides the page is gone. He calls Aggregator and says “I got to this page via a link from someothersite.com and the page is gone.”

Aggregator sits back and watches this happen for 10 days. At the end of that cycle, he finds that Googlebot has reported 100 broken links (because the site was down when it got there) and 10% of the time the page did not load within the allotted time.

Aggregator compares this information to the limits set by Google Engineers, and data collected from other websites of this type. He then removes 100 links from your site’s profile (they go to “Not found” pages right?), and then places the site further down in the results, beneath websites that are better at responding to users.

The Bottom Line

The bottom line is that your website is an investment. If it’s worth it for you to spend time and money on an SEO strategy, then it’s worth your time and money to make sure you’re running on a strong server.

All too often, I see people get started by having their nephew build them a website. Eventually they realize they need to upgrade and hire a competent web-dev. Next they know they want more people on the page so they hire an SEO, who tweaks titles and builds links.

Nowhere in that entire chain did anyone think to upgrade the server. Servers are thought to be an issue for IT and Security, not Marketing. But in the world of Web Marketing, the underlying structure is just as important as the message.

To put it another way: would you print your next direct mail piece on the inkjet in the office? Or have it printed in full color on glossy cardstock?