« August 2007 | Main | October 2007 »
September 28, 2007
The Emergence of Universal Search Engine Optimization
In May of this year, Google announced its new Universal Search System which blended traditional search results with news, video, music, images, local and book search engine portals, as well as Blogs on a single page to help users find information with greater ease. Universal Search, a new platform which represents a major shift in information display and retrieval, is causing search engine optimization companies to rethink how they conduct service offerings. So what does this mean for SEO professionals?
For those who conduct Search Engine Optimization services for clients, “Universal Search” is yet another marketing opportunity worth considering. Our industry is already known for dealing with extreme change on a monthly basis, and as a result of being able to adapt to this ever-changing market, this has enabled us to thrive in the industry. With these changes, we must re-invent or enhance our offering to meet the growing changes presented by Google in order to stay ahead of the curve. The emergence of Google’s Universal Search now forces SEO professionals to look outside the box for providing their customers with bleeding edge Internet marketing solutions.
To be able to help our clients rank in the top Google search results, we now have to look towards creating effective SEO strategies that involve RSS, news, videos, audio files, images, local and book search engine portals, and Blogs. With so many new things being displayed in Google’s search results it will be much harder to attain a top ten search engine listings for clients. However, this doesn’t mean that the world is coming to an end for SEO’ers. Nevertheless, it means that we must look towards existing Google search platforms and integrate them into a new strategy called “Universal Search Engine Optimization.”
Universal Search Engine Optimization encompasses traditional SEO (on-site & off-site) methodologies as well as combines Web 2.0 marketing tactics, i.e., RSS, Online Optimized Press Releases, Podcasts, Vodcasts, Blogs, Social Bookmarking, Social News sites, Image and Book listing optimization, as well as Local Search, that aids clients in gaining a greater market share within Google’s Universal Search results.
The following Internet marketing activities make up a large part of Universal SEO:
"Definitions in parenthesis taken from Wikipedia"
RSS -- “RSS is a family of Web feed formats used to publish frequently updated content such as blog entries, news headlines or podcasts.”
Online Optimized Press Releases -- Tailoring a company’s news in such a manner to gain greater visibility online through optimizing elements within the press release.
Podcasts -- “A podcast is a digital media file, or a series of such files, that is distributed over the Internet using syndication feeds for playback on portable media players and personal computers.”
Vodcasts -- "Video podcast (sometimes shortened to vidcast or vodcast) is a term used for the online delivery of video on demand or video clip content via Atom or RSS enclosures.”
Blogs -- “Many blogs provide commentary or news on a particular subject such as food, politics, or local news; others function as more personal online diaries. A typical blog combines text, images, and links to other blogs, web pages, and other media related to its topic.”
Social Bookmarking -- “A way for Internet users to store, organize, share, and search bookmarks of web pages. In a social bookmarking system, users save links to web pages that they want to remember and/or share.”
Social News Sites -- News aggregation (social network) sites that gain stories from community members online.
Image Optimization -- Effectively optimizing image file names, alternate text, and the utilization of photo sharing sites such as Flickr, Picasa, Photobucket, etc.
Book Listing Optimization -- Optimize Book company Web site pages to enhance placement in search engines for the titles of books for sale.
Local Search Listings -- Create local business listings and optimize Web sites to better perform amongst local search engine (Google Local, Yahoo Local, etc) listings.
To stay competitive in the ever-changing SEO industry, we need to create strategies for our clients that focus on all aspects of Universal Search. I believe this new form of search results presented by Google will open many doors for companies seeking to embrace the evolution of search.
Posted by brett at 03:57 PM | Comments (0) | TrackBack
September 24, 2007
Topix TLD Migration -- Six Months Later
I'm a big fan of Rich Skrenta, co-founder of NewHoo (née Gnuhoo, which eventually took the more recognizable name DMOZ), co-founder of Topix.net, and -- what may be the coolest of all -- author of one of the first known computer viruses, one of the few to be written before the actual term "computer virus" was even coined.
So that's all very cool, but the search-related part of all this was how, six months ago, Topix finally purchased the .com version of its domain and decided to make the move away from .net. The Wall Street Journal, in a mainstream SEO article that actually managed to hit most of the salient points pretty accurately, highlighted Skrenta's anxiety at the global domain change:
Such a simple change, Mr. Skrenta has discovered, could have disastrous short-term results. About 50% of visits to his news site come through a search engine -- and about 90% of the time, that is Google. Some companies say their sites have disappeared from top search results for weeks or months after making address switches, due to quirky rules Google and other search engines have adopted. So the same user who typed "Anna Nicole Smith news" into Google last week and saw Topix.net as a top result might not see it at all after the change to Topix.com.
Like a lot of SEOs, at the time I wondered what was so "wrong" with the time-tested (at least in my experience) method of full-on 301 redirects from the old site to new -- especially since the code would be short and sweet, with each old .net URL going directly to its .com counterpart.
The Topix crew had apparently heard too many domain migration horror stories. On his own blog, Skrenta noted,
...there've been a whole bunch of the seo posts saying essentially "hey, it's easy to move a domain, you just 301 it." Of course I know about 301 and 302 redirects. The problem is that half of these people follow up and say "you'll only be out of the index for a few months". They also ignore the problems that big sites have. A redirect for a small site may work great, but if you have hundreds of thousands of pages or more, there are lots of cases where this caused some form of not-in-the-index-anymore doom.The number of seo consultants who claim to know how to move a 100k+ page site is much smaller than the number who have actually done it.
That last point is a good one. Conventional wisdom in SEO is frequently spawned by 5% research and 95% extrapolation, which is often the best you can do. The other dirty little secret of SEO is that when you start seeing the same sort of anecdote often enough, it's tempting to put it in the "research" column.
Still, I'd not seen or heard of the type of monumental tragedies that Skrenta was talking about (at least within the last few years), and neither had Danny Sullivan:
I still remain surprised that the 301 is that much of a problem for even a big site. I just haven't heard of that trouble, of half the people saying you'll be out or whatever. If that's what you had been hearing, I can understand your concern. But it seems a pretty straight-forward change, and it shouldn't even be a burden on the server in that you're not actually talking about 100,000 of physical redirects that have to be created and check but a change of one domain to the other.
Ultimately, Topix listened to its heart (or maybe its board) and surprised me by opting for all-out duplication, running identical content on the .net and .com sites, avoiding any sort of redirection plan. So to call it a TLD migration isn't quite accurate. it's more like Topix.net bought a summer house and called it Topix.com. Again, from the WSJ article:
Concerned about that [redirection] strategy, Topix has run its site at both Topix.net and Topix.com for awhile. One danger with that approach is that it is unpredictable; Google will see two versions of the same page and could choose to show the Topix.net page most prominently.
This course would appear to run contrary to the advice even Matt Cutts gave in the article:
Google's Mr. Cutts says the search engine should ultimately understand what is going on when a site changes its Web address. He says the best strategy is to move one section of the site to the new address and see what happens before switching the whole thing.
Skrenta has since left Topix, but the duplicated domain strategy hasn't. Go to any page on the Topix.net site, and you'll see that the exact same page exists on the .com version of the site. Currently, Google shows about 2 million Topix pages indexed on the .net TLD and about 1.2 million on the .com TLD.
So six months ago, had you asked any SEO "expert" about what to do, almost no one would have suggested the present course. But has it hurt anything? Maybe, maybe not. Topix.com has a PR6 home page with about 1.2 million inbound links, while Topix.net has a PR8 home page with almost 7.4 million inbound links. So at this point, in terms of raw accumulated power, consolidating those domains would create one very powerful site.
But would that be better than the current situation? Perhaps not. What about that "unpredictability" the WSJ (and zillions of SEOs) talk about with dupe domains? That even in the best case, Google will pick one page or the other at its own discretion -- and it might not be the one you want? Consider the SERP for [detroit local news]:

A page from Topix.net shows up in spot 8, and a page from Topix.com -- an exact mirror of the .net page -- comes in at spot 9. Not exactly Google choosing one over the other.
But if the pages are identical, why do they have different titles on the SERP? Because Topix.com is heavily linked to from DMOZ, and the .com page shown in this screen shot shows the title used on the Detroit News and Media category of DMOZ. This leads to a question: When Google pulls one page's title and/or meta description from DMOZ, does that override the duplication filter?
Detroit's hardly alone here. Do some searches yourself with a city name and "news" or "local news" and see for yourself.
There's really no moral to this story, other than every time something like this happens, the "guidelines" from engines lose more and more bite. I'm happy that (at least according to my superficial research) Topix is doing well; it's a great idea, smartly executed. But these SERPs are yet another frustrating case of mixed signals from engines.
In my opinion, in a case like this, once Topix owned the .com version, that was all that needed to happen. I don't think the .com even needed to have any content for the problem to be solved. Looking back, my advice would have been to keep all content on Topix.net and immediately set up a 301 from Topix.com to Topix.net -- the exact opposite direction that most people recommended. That way, the authority of Topix.net content would never have been in jeopardy, and any links that mistakenly found their way to Topix.com would immediately transfer link popularity (as well as the user) back to the main (.net) site. They could have even promoted the site as "Topix.com" with no major headaches. Almost no one would care (or even notice) if they were redirected, whether it was type-in traffic or someone that clicked over from a news story.
Posted by erik at 03:14 AM | Comments (0) | TrackBack
September 18, 2007
Search Tearing Down Walls Like It's 1989
We knew it was coming and we tried to bake a cake for Maureen Dowd more than a Month ago, yet we are still surprised at how search-friendly they are being in their explanation today:
What changed, The Times said, was that many more readers started coming to the site from search engines and links on other sites instead of coming directly to NYTimes.com. These indirect readers, unable to get access to articles behind the pay wall and less likely to pay subscription fees than the more loyal direct users, were seen as opportunities for more page views and increased advertising revenue.
If you have any doubt that this is the SEO equivalent of 1989 scroll a bit further down the page for this money quote:
The Wall Street Journal, published by Dow Jones & Company, is the only major newspaper in the country to charge for access to most of its Web site, which it began doing in 1996. The Journal has nearly one million paying online readers, generating about $65 million in revenue.Dow Jones and the company that is about to take it over, the News Corporation, are discussing whether to continue that practice, according to people briefed on those talks. Rupert Murdoch, the News Corporation chairman, has talked of the possibility of making access to The Journal free online.
Mr. Murdoch, tear down that wall!
Posted by john at 03:53 PM | Comments (0) | TrackBack
September 17, 2007
PPC vs. Yellow Pages vs. Direct Mail CPA
Via Chris Zaharias via MediaPost via Piper Jaffray, we get this stark contrast:
Search advertising has proven to be fertile ground for customer acquisition. A recent study by Piper Jaffray & Co. entitled, “The New eCommerce Decade: The Age of Micro Targeting,” indicated that the average CPA for search was $8.50, considerably lower than the CPA for the Yellow Pages ($20), online display ads ($50) and direct mail ($70).
Could you imagine how low the Organic CPA would have been in comparison, had they found a way to incorporate that into the study?
Posted by john at 04:03 PM | Comments (0) | TrackBack
September 12, 2007
302 Redirects: A Guide to Search-Friendly Usage
Here are a few of the "absolutes" in the SEO field:
- Never use Flash
- Never use cloaking
- Never use 302 redirects
These are, of course, wild oversimplifications. Equating Flash or cloaking with bad SEO is like classifying Hank Aaron as a poor hitter because he batted cross-handed.
So when is a 302 redirect better than a 301 redirect? Here are a few examples. Keep in mind that in these scenarios, the 302 is not the only possibility to achieve the desired results. Plenty of CMS options likely exist that will do the same thing. It all depends on your setup. But in each of these cases, the 302 is certainly better than a 301. Let me say that one more time. Each of these scenarios likely has several non-redirect options that perform the same task. But the point of this post is that the 301 is not always the redirect you want, and sometimes it can hurt you if you buy into the "301 is the only good redirect" argument.
Example 1: New Products, Fresh Content. You run a cell phone information site, and one of your targeted phrases is [newest cell phones]. You have a URL called /newest-cell-phones.php, which is your users' go-to page for the latest in cellular technology.
For the last few days, the /newest-cell-phones.php page has redirected (via 302) to /lg-vx8350.php, which is the latest phone you've torn apart and reviewed. At the same time, you also have a static link in the LG portion of your site directly to /lg-vx8350.php, because you want to get that content crawled on its own as well. You're not particularly worried about dupe content issues, because tomorrow, you'll be done with your /nokia-2610.php page, and it will then become the target URL for the /newest-cell-phones.php redirect.
Example 2: Restaurant Content, Lazy-Susan Style. You run a popular restaurant with a large user base who check in each morning to see the day's menu. Because you buy local and fresh, you often have only a few days' notice about what you'll serve on any given day. You've done some user testing and found that your customers HATE the dreaded "giant PDF menu download" they find at most restaurant sites. Conseqently, you have a link on your home page directly to a URL called /todays-menu.htm. In addition, you have seven other pages:
- /sunday-menu.htm
- /monday-menu.htm
- /tuesday-menu.htm
- /wednesday-menu.htm
- /thursday-menu.htm
- /friday-menu.htm
- /saturday-menu.htm
On Monday, for example, /todays-menu.htm uses a 302 redirect to /monday-menu.htm. The next day, it redirects to /tuesday-menu.htm, and so on.
Would a 301 work here too? Absolutely not. You want /todays-menu.html to remain in the indexes and rank for terms like [restaurant name menu]. You do NOT want a URL like /wednesday-menu.htm to become associated with [restaurant name menu], because it's counterintuitive for such a URL to appear in SERPs (at least six-sevenths of the time!), and you have no control over what URL the engines will choose to replace /todays-menu.htm in the index, since you don't control what day they crawl it.
So what do these examples have in common? Here are some guidelines when deciding whether 302 is the way you want to go:
You could consider using a 302 when, for the following redirect:
URL A ---> URL B
- ...it is important that URL A be indexed and remain indexed.
- ...it's not critical that URL B be indexed, but its content is very helpful for users.
- ...you have several different URLs that might fit logically in the URL B spot above.
- ...you have put some resources into strong internal and directory linking for URL A.
As I said before, a 302 is not the only way to achieve this. Plenty of dev environments and independent scripts will enable you to achieve this also, but depending on your setup, a 302 might be the easiest way.
A little background on the often-misunderstood 302: If you spend any time slogging through HTTP header documentation (and who doesn't?), you've probably noticed that the 307 -- not the 302 -- is the true "temporary redirect." But older clients apparently don't always know how to handle a 307 properly, and the 302 does more or less the same thing.
Plenty of development environments use 302 redirects to direct users to the "appropriate" version of the home page when the root is called. For example, if you go to www.adidas.com, you'll be redirected (twice, actually) to the appropriate language and country version of the home page -- in my case, /us/shared/home.asp. This, in my opinion, is not the best environment for a 302 redirect. (See Bill Slawski's excellent analysis of 302s at domain roots from earlier this year.)
The downside to the whole approach I've laid out here is that it's sometimes hard to get good external links to "URL A," because by the time users click it, they've been redirected, and if they copy the URL from their browser, it's "URL B." Some good directories will allow you to submit a URL that redirects, as long as it redirects to a page on the same domain. But to get people to link to URL A, you'll need to make a conscious effort to give them the correct URL.
Posted by erik at 04:55 PM | Comments (0) | TrackBack
September 10, 2007
Google Book Search Results Defy Clustering, Quantity Precedents
Sean pointed this out to me early this morning. While we've known that Google has rolled out Book Search results in its main results column, some of the things Sean is seeing seem a bit out of whack with G's traditional clustering and placement precedents.
For example, here's the first page of results for [monopoles]. When I run the query, I don't see these results, but Sean does, along with a few other people that Sean has (mono)polled around the country:
![the first 10 results for [monopoles]](http://seoblog.intrapromote.com/google-books-serp.jpg)
Note how the results are unclustered. In other words, results from a specific subdomain typically get grouped together on the SERP for the sake of convenience, user experience, or ... well, for some reason, anyway. The results pulled from the books.google.com subdomain seem immune from the clustering behavior. And when results appear in the "regular 10" (as opposed to one-box) results, any given group of 10 results typically shows only two results from a given subdomain. This SERP shows three.
This is hardly the clustered behavior that some bloggers like Seth Godin have noticed. The examples he gives in that post are neatly organized at the top of the SERP in a one-box-style format.
If you move to the second page of SERPs (results 11-20) you'll see even more instances. In the case of [monopoles], Google Book Search holds six positions in the 11-20 group:
![results 11-20 for [monopoles]](http://seoblog.intrapromote.com/google-books-serp2.jpg)
So for at least this query (and several others he's shown me today), Google Book Search has nearly half the top organic positions. That's hard to beat.
Posted by erik at 01:43 PM | Comments (0) | TrackBack
September 07, 2007
Late Friday Flawed Online Argument of the Week
As reported in Just An Online Minute, the now oddly named Department of Justice's argument against Net Neutrality:
Among other arguments, the DOJ says that there's no reason for the government to step in with regulations, because Internet service providers haven't yet taken any steps to degrade service.
Following new Justice logic, then, should there have never been a murder committed in the United States, would it then not be illegal?
Posted by john at 03:49 PM | Comments (0) | TrackBack
September 05, 2007
Boost Visibility With XML Sitemap Submission to Ask.com
We have been keeping a close eye on Ask.com and are seeing traffic increases from Ask.com for some of our clients. In fact, one e-commerce client over this summer has seen transactions more than double from Ask.com referrers. A 100% increase in transactions - now that really gets our attention!
We've shared with Wagon readers about submitting an XML sitemap to Google, to Yahoo and updated readers about the potential of submitting to MSN this Fall. I thought I would remind readers that you can also submit your XML sitemap to Ask.com and provide some simple how to's.
There are two ways to submit your XML sitemap to Ask.com:
1. Use the auto-discovery directive in your robots.txt file:
SITEMAP: http://www.yoursitemapurl.xml
2. Submit your sitemap via Ask.com's ping URL:
http://submissions.ask.com/ping?sitemap=http://www.yoursitemapurl.xml
Lastly, make sure you're using the accepted sitemaps protocol.
Posted by doug at 03:44 PM | Comments (7) | TrackBack

