The Coke Vs. Pepsi Challenge: Who Redirects Better?

Both Coca-Cola and Pepsico have seen fit to set up redirects on their homepage URLs—a very common practice among commercial websites. Classically, search optimization experts have advised clients that if their sites perform redirects on pages, they should use only server-side redirection, and it should ideally be a 301 redirect in order to ensure that the search engine can index and rank the destination page properly. However, Google is now handling some non-server-side redirects better than search engines once did—should people worry about 301-ing as much? Using these two big-brand competitors, let’s look at how they’ve set up their redirection to see what’s working and what’s not.

A "redirect" in the online world is a programming instruction delivered to a system which requests an internet resource, such as a web page or image, and the instruction tells the requesting system to "go elsewhere." For instance, if a web page has moved, a redirect could tell a browser that’s requesting that page that the page has been moved temporarily or permanently to a different URL.

A server-side redirect is where the web server replies back to a request, and the response includes the redirection directives in the "http response header." This header is a bit of code that’s invisible to users, and tells the requesting system how to interpret and display the resource—including things such as what language it’s in, what character set to use, compression encoding method, etc.

A few different status code numbers are returned as part of this response. A "200" response means "the request has succeeded," and is the usual response code when a web page is requested and returned in a straightforward manner. A "301" status means the resource has moved permanently, and the header includes a "location" with a new URI (uniform resource identifier) pointing to the new place to retrieve the resource (check out the great illustration on the Power of 301 Redirects from a few days ago). A "302" status means the resource has moved temporarily, and this header message is returned along with the temporary location URI.

A non-server-side-redirect uses other ways to send the requesting system to a new location. There are two main types of non-server-side-redirects commonly used by internet developers: Javascript redirection, and meta-refresh redirection. Both of these methods are coded into a page’s HTML. When a page using one of these methods is requested, the server will send back a header with a 200 "OK" response, along with the HTML code used by the browser to render the page, displaying its contents. Within the HTML returned, the meta-refresh tag or Javascript is included, and the browser begins executing that code after the page has loaded.

When a page contains Javascript, it may include all sorts of dynamic/active things which allow the page to interact with users. For instance, buttons on the page could change colors when users mouse over them. Javascript can also make the page redirect—this can be done immediately when the page is loaded, or it can be timed to happen after a certain delay after load; or the redirect could be kicked off by some other event such as the user clicking on something or mousing over an area.

Javascript redirects don’t work too well for the purposes of search optimization. This is mainly because there are so many different ways that a Javascript redirect could be written and invoked, making it difficult for the search engine to interpret how the redirect should be treated. A great example of this is the Coca-Cola product marketing site. Here’s the screen capture of their site on the Google search results page when you search for "coca cola":

(click to enlarge)

You’ll notice that the Coca-Cola Company web site, TheCoca-ColaCompany.com, (geared towards investor relations, publicity releases, and hiring info) is showing up 2nd with nice info in the second search results listing slot (the indented listing is not counted as a true "second" listing in the rankings, but that’s a different story). You can see that it has a great TITLE on the link: "The Coca-Cola Company: Soft Drinks, Energy Drinks, Sports Drinks…". And, the descriptive text below that link is good, too: "Welcome to the official web site of the Coca-Cola Company. You’ve come to the right…".

Yet, oddly, the Coca-Cola marketing site in the top results listing shows only a short link TITLE of the name, and no descriptive text.

Why?

The reason is that when Google requests the home page at "www.coca-cola.com", their server is returning a 200 status code, along with some very brief HTML code:

<!DOCTYPE html PUBLIC"-//W3C//DTDXHTML1.0Transitional//EN"

"https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="https://www.w3.org/1999/xhtml">
<head>
<title>Coca-Cola</title>
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">
<script type="text/Javascript">
//setacookieforwebtrendsprovidingthereferrer
if(document.referrer) {
varexpires=newDate();
expires.setTime(expires.getTime()+5*1000);//5minutes
document.cookie="original.referrer="+escape(document.referrer)
+";expires="+expires.toGMTString();
}
document.location=’index.jsp’;
</script>
</head>
<body></body>
</html>

Notice how the HTML returned for the Coke homepage has absolutely nothing between their <BODY> tags! You can also see that there’s no META Description tag—which is the reason why the listing displays no descriptive text below the link in Google’s search engine results pages.

When someone visits that homepage via their browser, the HTML loads, and the Javascript then executes. The Javascript is first setting a cookie (for WebTrends?), and then you’ll see the line, "document.location=’index.jsp’;", which tells the browser to go to "https://www.coca-cola.com/index.jsp". This was likely a quick/easy/cheap method for Coca-Cola’s developers to send users over to their index.jsp program to deliver up the page code. There are other, better ways to do this, too. I don’t know why their server wouldn’t be configured to take an index request and automatically execute files named "index.jsp" in the document/program directory, which would negate the need for a redirect altogether.

If you click on the cached page link for www.coca-cola.com in the Google SERP, you’ll get an error message. The reason for this is that when Google sends your browser their HTML code, the Javascript redirect is "relative", meaning that it now functions relative to the Coca-Cola server. When that Javascript executes on the Google cached page, the browser tries to redirect to "index.jsp", located on the Google cache server, and since that resource doesn’t exist at that location (https://64.233.167.104/index.jsp), Google displays a standard error page.

Now, Coca-Cola is actually making a mistake beyond the use of Javascript with the home page redirection. When the base URL redirects to "www.coca-cola.com/index.jsp", that location is actually redirecting requests yet again. Checking that redirect, it’s returning a 302 response — "resource moved temporarily". That location redirects to "https://www.coca-cola.com/glp/e/index-e.html".

Both the Javascript redirect and the secondary temporary redirect are bad tactics for search engines like Google. How can you tell this isn’t great? There are a few factors:

• No on-page keywords other than "Coca-Cola" in the TITLE, are associated with the homepage URL, so some signal potential is being lost. For instance, when you click on the URL, you can see on the final destination page that they list out a menu of languages for Coca-Cola sites. But, do a search for "coca cola en espanol" and this homepage doesn’t come up to the top of the SERP as relevant, nor are any of the natural search results links on the first page of Google results pointing to any of those official Coca-Cola company web sites at the moment.
• PageRank doesn’t transfer to Coca-Cola’s final destination homepage. When you go to "https://www.coca-cola.com/glp/e/index-e.html", the Google toolbar shows zero PageRank! All that link-juice potential is focused on a page containing no real content and no links to their other content pages, so the PR value isn’t being fully exploited or transmitted to the page where it needs to be applied.

• This is also bad for many users who browse with Javascript disabled in their browsers. What do you get if you browse to www.coca-cola.com with Javascript disabled? A big blank screen! That’s exactly what Google’s algorithms are seeing on that page.

Well, perhaps Coca-Cola can afford to get away with this indifference to even basic SEO techniques. So many people link to the site and its sub-pages that some of the other pages still have some strong PageRank. Heck, Coca-Cola’s leading everyone in world-wide name-brand recognition, so they don’t even have to work very hard at some of their marketing stuff. But, if you do click through to the English -> United States page for the site, you’ll see that they have an online store. So, if they optimized a trifle better they could be getting a lot more traffic and associated sales with that store. The bad homepage redirection is preventing the store and other site pages from having as much PageRank as they could.

Now let’s look at what Pepsi is doing.

When you do a search for "Pepsi" in Google, you’ll see their marketing web site, www.pepsi.com, listed first:

(click to enlarge)

In contrast to Coca-Cola’s search result listing, Pepsi’s is displaying a very brief description under the linked TITLE: "Pepsi’s official web site." They also have four "site links" listed under their first listing. Once you click through to "www.pepsi.com", you’ll notice that the page redirects to "https://www.pepsi.com/home.php".

Pepsi’s site is also returning a 200 status code and then using a non-server-side redirect to handle this—and they’re also using Javascript to accomplish it.

So, why does the Javascript redirect work for Pepsi where it isn’t working for Coke?

There are a few differences in Pepsi’s homepage delivery. First, Pepsi’s Javascript redirects the requesting agent to that destination page at home.php, and stays there — there’s no second hop through a 302 redirect as in the Coca-Cola case. Pepsi is also returning a whole lot more HTML/page-code with the first page. There’s a lot more Javascript—some of which is checking for Flash support and such—and it’s returning some contents within the page’s <BODY></BODY> tags to display for users who have Javascript disabled.

Also, the TITLE tags of the page contain a different text than what Google is displaying in the SERP:

<title>Pepsi USA Flash Check</title>

There’s absolutely no META Description within that initial page code—no text in the page that says "Pepsi’s official web site." Here’s a telling thing about Google’s functionality. If you look in the HTML code of the page that Pepsi’s site redirects the homepage URL to, you’ll see that it’s TITLE contains the actual text that’s being used in the Google SERP:

<title>Pepsi USA</title>

So, Google has taken the TITLE from the page at "home.php", and associated it with their homepage at www.pepsi.com, exactly as they would if Pepsi had set up a 301 redirect over to home.php!

There’s still not any META Description on that final destination page for Pepsi, but Google’s apparently pulling the descriptive snippet displayed under the link in the SERP from Pepsi’s description text found in DMOZ directory.

Finally, Pepsi’s destination page is actually showing some PageRank in the Google toolbar—indicating that rank is flowing from the site’s inbound links, and getting transferred through the Javascripted redirect to the landing page. This all shows that for some simple Javascript redirects, Google will successfully interpret the redirection and treat it quite similarly to how they treat server-side redirects—PageRank transfers, and the content on the landing page is associated with the URL of the original page. (You can find other pages in the internet wild where Google is handling redirection similarly.)

Pepsi’s setup for redirecting their homepage to the content application is better than Coca-Cola’s in a few respects! Pepsi doesn’t have the second hop through a 302 redirect, causing PageRank and keyword association stuff to fail in transferring. Pepsi also has some text to display for users who have Javascript disabled in their browsers along with a helpful link to allow the user click on through to the landing page.

But, both Coca-Cola and Pepsi should still avoid using the Javascript redirection. Only Google handles this with any fluidity, and there’s too many chances for it to not work well in ranking the homepage, and the links out to other site pages from that homepage. Other search engines such as Yahoo! and MSN do not handle non-server-side redirection very well, which is one big reason to avoid setting up a web application in this manner. (Yahoo’s listing for Coke appears to have been hand-written, and Microsoft’s shows description snippet from content apparently cached since 2003. Pepsi’s listing in Yahoo and Microsoft Live are also bad.) There are a number of ways that the homepage applications could be set up which would be more elegant for requesting agents, and more successful for natural search marketing. Both of these companies may already have so much brand traffic that they don’t care about the natural search channel, but all the rest of us can’t afford the luxury of throwing away traffic and associated revenue potential in such a wasteful manner.

Interestingly enough, Google also handles META refreshes fairly fluidly, but that method of redirection should also be avoided in application design for the same reasons outlined above. Google engineers have mentioned to me that Google may apply treatment to Meta refreshes similar to 301 redirects, but this is partly conditional on the time delay coded with the refresh—too much delay, and they would choose not to treat it like a server-side redirect, apparently.

A lot of developers will set up redirects on homepages to accomplish various things with load balancing and handling of application parameters, but it’s really not necessary. I see lots of WebSphere Commerce sites set up in this way, for instance, but even IBM has advised against using non-server-side redirection.

Just because your site and homepage are getting crawled doesn’t mean you should ignore how your application may be redirecting users. If someone passes to your domain name, watch to see if the browser automatically changes the URL before delivering up the homepage. If it does, you have a redirect, and you should then check the redirect to see what it’s doing. You can do this by typing your domain name into a HTTP header "sniffer" or "checker", such as this one. I recommend checking to also see the raw HTML returned by the application as well as the header response. If it returns a 200 status code and the URL is redirecting in your browser, you’ve got a non-server-side redirect going on which is less-optimal. Unless you have so much brand-name recognition like a Coke or Pepsi, you can’t afford to be using less-than-optimal redirection methods.

Chris “Silver” Smith is Lead Strategist at Netconcepts and writes for the Locals Only column at Search Engine Land.