Tag Archives: seo

Why would Google be Traffic Shaping?

There’s an interesting thread over on Webmasterworld about Google Traffic Shaping. It may seem overbaked a bit, but if you know some of the thread participants personally, you’ll realize that if their focus is on it, there’s a good reason.

Secrets abound and on these threads you need to read between the lines a lot or else you’ll be scratching your head.

To summarize the thread, some people have noticed Google tuning their knobs on a site by site basis with respect to traffic that converts. One month traffic may go up while conversions go down…and vice versa.

We all know Google is a data analysis monster. You kind of have to be when your products are “free” and you have to make money through the back door, if you know what I mean.

So how do they make their money? Selling adwords. Lots of them. The more money their advertisers make, the more they’ll advertise. And the more Google will make.

So while they may repeat the mantra that they want to provide the best possible results to the user…as a public corporation, their DUTY is to provide the best possible return on investment to their shareholders.

Therefore, and I say this without emotion or casting aspersions, you have to assume that their dream scenario is a bit different than the PR….

For them, the shopper is the most important Google visitor. Give your customer (ie advertiser), a shopper who converts, and now you have a product with a metric that sounds like music to advertisers.

Imagine if you will, you’re a local shop, independent or outlet of a large chain. You want to pay Google for shoppers and shoppers alone.

So in Google’s ideal world, shoppers will type search terms in Google. All organic results will be of no interest to the shopper and only the paid search results will entice them to click. And once they click, they will convert.

THAT’s why they are experimenting with traffic shaping, particularly in respect to conversions. And they seem pretty far along.

The take home point for webmasters is, to score well online, at least with Google, you need an online presence that converts…and you need to pay Google for that traffic.

I really don’t want any of my friends at Google to be upset by this post. So I’m going to repeat. Google is a public corporation. PR is PR. Business is business. And if Google AREN’T doing this, they would be breaking their fiduciary responsibility. Like in the Godfather, everyone needs to put bread on the table. It’s not personal.


Important to note that Zend Framework _redirect defaults to 302

From the Zend Framework Manual:

_redirect($url, array $options = array()): redirect to another location. This method takes a URL and an optional set of options. By default, it performs an HTTP 302 redirect.

Now you can argue about what the 302 header code SHOULD do. It’s spelled out in W3C:

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

But in the past 302’s have been royally borked by search engines.

For some history, I was peripherally involved in documenting and tracking down the initial cause of these problems when a popular directory app (more or less correctly) used 302 redirects to link to resources. The creator of the program felt that he wasn’t doing anything wrong, but it turned into massive threads in the Search Engine forums.

Due to a glitch, a 302 on these directory sites gave all users of the program the SERPs of sites it linked to. Along with the ire of indignant site owners everywhere. Honest people were called spammers, fights broke out. It was ugly.

It also took a long time for the search engines to fix. Really long. And just when you thought it was safe to go back in the water, it broke again.

Eventually it seems the major problems got fixed for good. There have been countless discussions about this topic. Although I haven’t read the latest, in my opinion, 302s hurt your ranking. Just last week a friend of mine asked me to check out her potential client’s low ranked corporate website (they are a household name), and lo and behold, their homepage has a 302 redirect!

The purpose of this post is mostly to alert Zend Framework developers in case they assumed, as did I, that a redirect would send a 301 header code. Used in the wrong place, the results can be costly!

Therefore, make it a habit to pass in the code you desire each time you use _redirect().

In my opinion, the redirect should either default to 301, or, since the ramifications of an incorrect redirect can be harmful to search engine rankings, a valid code should be required to be passed in. This will engender good habits.

I’d love to hear comments on this issue. In particular, to answer these questions:

  1. What do you think the default in Zend Framework should be and why?
  2. Does W3C’s definition of the 302 work in the real world?
  3. Should W3C’s make any changes to redirect codes and if so, what should they change?
  4. What code should you send to redirect pages in various situations? After logging in… Accessing a page when not logged in (it could be a valid page for a logged in user)… etc..

For those who are curious, the default is set in /path/to/ZendFramework1.84pl1/library/Zend/Controller/Action/Helper/Redirector.php, right after the class statement:
protected $_code = 302;