So, you’re gonna change hosting providers. In many cases, moving the content of the site is as easy as zipping up the content and unzipping it on the new server. There is another aspect of moving the domain that many people over look: DNS.

The Domain Name System (DNS) is the translation service that converts your domain name (e.g. keyrelevance.com) to the corresponding IP address. When you move hosting companies, it’s like changing houses, if you don’t set up the Change of Address information correctly, you might have some visitors going to the old address for a while. Proper handling of the changes to DNS records makes this transition time as short as possible.

Let’s assume that you are changing hosting, and the new hosting company is going to start handling the Authoritative DNS for the domain. The first step is to configure the new hosting company as the authority. This should best be done a couple or more days before the site moves to the new location.

What does “Authoritative DNS” mean?
There are a double-handful of servers (known as the Root DNS servers) whose purpose is to keep track of who is keeping track of the IP addresses for a domain. Rather than them handling EVERY DNS request, they only keep track of who is the authoritative publisher of the DNS information for each domain. In other words, they don’t know your address, but they tell you who does know it.

If we tell the Root level DNS servers that the authority is changing, this information may take up to 48 hours to propagate throughout the internet. By changing the authority without changing the IP addresses, then while visiting browsers are making requests during this transition, both the old authority and the new authority will agree on the address (so no traffic gets forwarded before you move).

Shortening the Transition
The authoritative DNS servers want to minimize their load, so every time they send out an answer to a request address for a given domain, they put an expiration date on it. This is called the “Time To Live”, or TTL. By default, most DNS servers set the domain TTL to 14,400 86,400 seconds, which equals 1 day (thanks Andrew). Thus, when a visitor requests the address of the authoritative DNS, it returns the IP address and says “and don’t bother asking again for 24 hours.” This can cause problems during the actual transition, since the old address might continue to be accessed for a whole day after the address has changed.

The Day Before the Move
Since the new hosting company is the authority, they can shorten the TTL to a much shorter value. We recommend that 15 minutes (900 seconds) is a good compromise TTL value during the transition time.

Moving Day
When you are ready to make the switch, have the new DNS servers change the IP information to the new address(es). Since the TTL was set to 15 minutes, very quickly the other DNS servers on the ‘net will be asking for the IP address of the domain. They will be provided with this info, and the switchover will happen much more quickly than if the authority had not changed. Once the new site is live and you have verified nothing is horribly wrong, you can change the TTL on the new DNS servers back to 1 day. If on the other hand, something IS wrong with the new site, you can change the DNS back to the old IP address and within 15 minutes most if not all traffic should be back to the old servers. We also recommend changing the old DNS info to point to the new IP address as a precaution, but if you follow these steps, most of the traffic should have already trasnsitioned to the new DNS servers.

A Bug in BIND
There is a bug in some versions of the BIND program (which executes the DNS translation). This bug will cause a DNS server to continue to ask the same authoritative DNS server for the info as long as he is willing to give it. To complete the transition cleanly, you need to turn the DNS records for the domain off in the old DNS servers. This will cause it to generate an error, which in turn will cause the requesting DNS server to ask the Root level servers for the new authority. Until you make this change, there is still a chance that some traffic will continue to visit the old domain.

Change of Address Forms
The USPS offers a Change of Address kit to help make moving your house easier. Below is the Key Relevance Change of Address Checklist that may make you site’s transition painless.

One of the most over-looked items related to your web site is a small unassuming text file called the robots.txt file. This simple text file has the important job of telling web crawlers (including search engine spiders) which files the web robots can access on your site.

Also known as “A Standard for Robot Exclusion”, the robots.txt file gives the site owner to ability to request that spiders not access certain areas of the site. The problem arises when webmasters accidentally block more than they intend.

At least once a year I get a call from some frantic site owner telling me that their site was penalized and is now out of Google when often they blocked the site from Google via their robots.txt.

An advantage of being a long time search marketer is that experience teaches you to know where to look when sites go awry. Interestingly, people are always looking for a complex reason for an issue when more times than not, it is a simple more basic problem.

It’s a situation not unlike the printing press company hiring the guy who knew which screw to turn. Eliminate the simple things that could be causing the problem before you jump to the complex. With this in mind, one of the first things I always check when I am told a site is having a penalty or crawling issues is the robots.txt file.

Accidental Blockage by Way of Robots.txt
This is often a self-inflicted wound that causes many webmasters to want to pound their heads into their desks when they discover the error. Sadly, it happens to companies small and big including publicly traded businesses with a dedicated staff of IT experts.

There are numerous ways to accidentally alter your robots.txt file. Most often it occurs after a site update when the IT department, designer, or webmaster rolls up files from a staging server to a live server. In these instances, the robots.txt file from the staging server is accidentally included in the upload. (A staging server is a separate server where new or revised web pages are tested prior to uploading to the live server. This server is generally excluded from search engine indexing on purpose to avoid duplicate content issues.)

If your robots.txt excludes your site from being indexed, this won’t force removal of pages from the index, but it will block polite spiders from following links to those pages and prevent the spiders from parsing the content of those pages. (Pages that are blocked may still reside in the index if they are linked to from other places.) You may think you did something wrong that got your site penalized or banned, but it’s actually your robots.txt file telling the engines to go away.

How to Check Your Robots.txt
How do you tell what’s in your robots.txt file? The easiest way to view your robots.txt is to go to a browser and type your domain name followed by a slash then “robots.txt.” It will look something like this in the address bar:

http://www.yourdomainname.com/robots.txt

If you get a 404-error page, don’t panic. The robots.txt file is actually an optional file. It is recommended by most engines but not required.

You can also log into your Google Webmaster Tools account and Google will tell you which URLs are being restricted from indexing.

You have a problem if your robots.txt file says:
User-agent: *
Disallow: /


A robots.txt file that contains the text above is excluding ALL robots – including search engine robots – from indexing the ENTIRE site. Unless you are working on a staging server, you don’t normally want to see this on a site live on the web.

How to Keep Areas of your Site From Being Indexed
There may be certain sections you don’t want indexed by the engines (such as an advertising section or your log files). Fortunately, you can selectively disallow them. A robots.txt that disallows the ads and logs directories would be written like this:
User-agent: *
Disallow: /ads
Disallow: /logs

The disallow statement shown above only keeps the robots from indexing the directories listed. Note that the protocol is pretty simplistic: it does a text comparison of the path of the URL to the Disallow: strings: if the front of the URL matches the text on a Disallow: line (a “head” match), then the URL is not fetched/parsed by the spider.

Many errors are introduced because webmasters think the robots.txt format is smarter than it really is. For example, the basic version of the Protocol does NOT allow:

• Wildcards in the Disallow: line
• “Allow:” lines

Google has expanded on the original format to allow both of these options, but these are not universally accepted, so it is recommended that these expansions ONLY be used for a “User-agent:” run by Google (e.g. Googlebot, Googlebot-Image, Mediapartners-Google, Adsbot-Google.).

Does the robots.txt Restrict People From Your Content?
No, it only requests that spiders keep from walking through and parsing the content for its index. Some webmasters falsely think that if they disallow a directory in the robots.txt file that it protects the area from prying eyes. The robots.txt file only tells robots what to do, not people (and the standard is voluntary so only “polite” robots follow it). If certain files are confidential and you don’t want them seen by other people or competitors, they should be password protected.

Note that the robots exclusion standard is a “please don’t parse this page’s content” standard. If you want the content removed from the index, you need to include a Robots noindex Meta tag on each page you want removed from the index.

Check robots.txt First
The good news is that if you have a situation where you accidently blocked your own site, the solution is easy to fix now that you know to look at your Robots.txt file first. Little things matter online. To learn more about the robots.txt file see http://www.robotstxt.org.

Check out how Visual.ly has grown content in the last few months:

Visual.ly's content has grown to over 5,000 images in just a few months.

Their growth in numbers of fans on Facebook has been really good, too:

Visual.ly hasn’t grown search market share at the skyrocketing rate we’ve seen with Pinterest, but it has grown enough to be interesting and worthwhile for promotion of infographic images.

I’m suspecting most of its audience share is made up of search marketers and graphic artists at this point, but if they can make the social voting aspects more compelling it might leverage the potential hinted at in the Facebook Likes numbers more effectively.

Either way, this is one worth watching.

It seems unusual to see a new image-sharing type of social media site to be gaining so much ground, and so quickly. This could be happening due to beneficial attention from influential people who may be serving as “mavens” as Malcolm Gladwell describes them. With significant people such as Jeremy Stoppelman (involved in early PayPal, Yelp, etc) as initial investors backing it, it has gotten pretty good industry attention.

I have written numerous times about image SEO and leveraging social media image sharing sites in the past as a means for building PageRank when doing search engine optimization, so I may have to update my comparison matrix for image sharing sites for SEO value in order to rank it.

Pinterest’s homepage has a toolbar PageRank value of 6 currently, but nearly 16 million pages are indexed! Even more wonderfully from a search marketer’s viewpoint, the dreaded NOFOLLOW tag is not in use as of yet, so links included with images can pass PageRank. For instance, this page of wedding photos contains links which pass PageRank (although, arguably the links could be slightly more optimal if they weren’t opened into new windows with the target=”_blank” parameters in the link tags). Pictures from Pinterest.com are showing up nicely under image search results, too.

According to Google Insights, searches for “Pinterest” have climbed so quickly this year that it’s now on par with searches for “Flickr” and “Picassa”. While searches for the brandname do not equate with traffic/visits to the site, they typically do correlate pretty closely.

Some degree of Pinterest’s success may be attributed to its iPhone app, which has gained over 35,000 votes, and has 4.5 stars, indicating it’s well-liked by users.

The main detraction from the site right now is in terms of motivation — why do users wish to go here, versus merely sharing images in Facebook, Twitter, Flickr — or, even within Google+, for that matter? The main advantage the site has right now seems to be in terms of the user-interface featuring the pinboards, which allow for good browsing, compared with less compelling lists of thumbnails found in most sites.

The site also has a number of significant issues in terms of usability. If you sign up now, you can expect some clunkiness, depending on your browser. However, I would expect these issues to be addressed fairly rapidly.

For SEOs, I recommend that you enjoy the not-yet-NOFOLLOWed status, because it’s certain to come to an end really soon. I might also predict that as it stands now, I think Pinterest might make better longterm sense as a user-interface feature of some other social media service such as Facebook, Twitter, or Google Plus. It might make for a very good acquisition for one of those services.

So, what does this mean in terms of displaying dates on pages as I earlier explored? Does the recent algo tweaking change my earlier recommendation that displaying dates on webpages may help rankings?

As you may recall, Michael Gray and I differed on this point — he suggested that one should opt out of having dates on pages because Google displays them willy-nilly in snippets, and they may frequently prejudice users from clicking through if other content with more recent dates is available in the same search results page. In contrast, I argued that Google’s usability testing apparently found that users often prefer to see the dates in the SERP listing snippets, and that factoid makes it an element that Google’s algorithm might prefer slightly for ranking purposes. Even if the algorithm didn’t give advantage to pages with dates, their research indicates that it might still increase user CTR to the webpage, which can indirectly improve rankings over time. Both Michael and I provided caveats, however, and acknowledged that their are exception cases.

In that earlier post, I provided a decision matrix which I believe supports my general stance that having the dates is likely beneficial in more cases than not. In it, the green check marks are cases where having the date is probably advantageous, while the red exxes indicate cases where it might not be helpful:

Now that Google has apparently bumped up the “freshness factor” in ranking signals as slightly more important than before, I believe it further supports my stance that having the date on pages is beneficial for most types of content. By making this change to the algorithm (and announcing it publicly), Google has signaled that this is particularly important. Therefore, having the date in the snippet is likely even more important to searchers.

Now, you might be thinking at this point that you have older or even stale content, so you will opt out of the date in order to avoid some perceived penalty of the application of the freshness factor. I’ll tell you flat out that this particular reasoning is illogical: Google has a separate factor which they independently derive to decide a document’s initial publication date. It’s probably based upon the date when they index the webpage for the very first time. This document inception date is *not* affected by the date printed on the webpage, so you can’t fool the algo by declining to display the date or lying about the publication date! (Search Engine Land further verified this in chatting with Google about their freshness ranking announcement.) In fact, if you frequently change the date you print on the page without actually changing the page’s content, you could get dinged in your quality score — I would not try it.

One thing you could do is periodically review your content and update it with postscripts or revision notes at the end, and THEN change the “last updated” date you display on the page to reflect the day of the change. This method is, of course, costlier, and requires some actual investment in ongoing quality improvement. But, I’d say that it’s the valid way to optimize in terms of date and freshness, and there’s likely no good shortcut for this signal.

Finally, if you’re thinking about abruptly changing all of the URLs of your article pages to periodically start the clock ticking once more for the document inception dates, you should know that one of the prime ranking factors that’s been in play for years now is an advantage given to pages with a longer legacy. Pages which have been around for a longer period of time on stable URLs have had some ranking advantage in Google SERPs. The question now is, how much advantage? Does the advantage of recency now outweigh the advantage of longevity?

If you dump all your legacy URLs you might find out — but the answer may not be to your liking.

In truth, I suspect that this freshness factor tweak is likely somewhat subtle and the actual impact may be fairly light for most sites. While the figure of 35% of searches being changed sounds impressive and impactful, it could be as simple as one page out of 10,000 getting bumped up to the first page. It doesn’t mean that 35% of the first page of SERPs will alter. Listings that are bumping in and out of positions ten and eleven likely wouldn’t notice a change at all.

While this particular Google Places information accuracy widget is new, Google has long been leveraging similar user-generated content to try to enhance and grow map information. They have been actively crowd-sourcing map accuracy work for a while now, but it’s not without significant issues.

Obviously, one of the more serious issues involved is the fact that people will lie and cheat.

So, it’s no surprise that Google Maps help groups have instances reported where people suspect that their locations have been compromised some by malicious competitors, disgruntled former employees, or randomly psychotic customers. I’ve had clients and colleagues approach me with similar reports, and Mike Blumenthal has reported these types of stories as well.

Not only can some of the general public be expected to purposefully try to cause mischief, well-meaning people can also ignorantly make mistakes in commenting or reporting on data accuracy — just think of all the stories throughout popular culture of stereotyped representations of men who can’t find addresses while driving (and refuse to ask directions) or spatially-challenged women who can’t read maps. I’m not suggesting that these stereotypes are accurate representations of the sexes, but that the stories likely come from the fact that many people, regardless of sex, find navigation and map interpretation highly challenging.

So, there are some inherent problems with attempting to base a large percentage of location accuracy upon crowd sourced information.

What’s particularly concerning about Google’s methodology is that they’ve recently declared that they’ll sometimes use this data to override business owners’ disclosed information, or call into question accuracy in consumers’ minds. Blumenthal hilariously communicated the issue in his brother-in-law’s open letter response to the matter. An actively-engaged business owner may have gone in and verified that their address and map are correct in Google Places, but if a small handful of users claim the address is wrong, it can get incorrectly flagged as being a closed location, or that the address may be wrong — something which would clearly discourage potential customers from going to the business.

Mike organized a really humorous experiment to illustrate this issue when he asked a handful of us to go in and flag Google’s own corporate headquarters as “closed”. For a brief while, the Mountain View location’s Place Page listing carried the flag, “Reported to be closed.”:

Auditors (and perhaps an activity pattern detection algorithm) twigged to the fact that a bunch of users had declared the location closed, and someone at Google corrected the defacement. But, the point was made — users can falsely get a listing flagged as closed. (This was done to illustrate the issue from the perspective of small local businesses, and not with any intent or expectation of causing harm. So, hopefully those of us who participated were not blackballed by Google Places!)

If Google headquarters was a local business that relied upon having potential walk-in customers referred by Google Places, they would have almost certainly lost business during the time that the alert appeared on their Places page. You should ask yourself: is that fair? Should a mean little gang be allowed to abruptly paint a “closed” sign over the door of a viable business?

My concern with the testing of these new crowd sourced accuracy widgets is that the same sorts of stuff can and will happen across the millions of businesses listed in the United States. Having a place flagged as closed is potentially damaging to these businesses, and so is having a location of a business tagged as possibly erroneous — or having the address changed outright to an erroneous place.

There are numerous methods for assessing address correctness which can be handled with algorithms and which do not involve trusting humans. For instance:

• if the street address is outside of the ZIP code polygon;
• if the ZIP is not associated with the City name;
• if an odd-numbered address is geolocated to the even side of a street (and vice-versa);
• if the phone area code is outside of the City or ZIP;
• if the address number seems impossibly high or low;
• if the street address is determined to be less likely to be located in the city block where it’s geolocated (if neighboring addresses are pinpointed elsewhere);
• if the street name is not recognized in the ZIP area;
• if the other directory data sources are in reasonable agreement on the geolocation pinpoints;

…And, there are more. (For a primer on basic causes for online mapping errors, see my article, “Top Causes of Errors in Online Mapping Systems“.)

Google is undoubtedly using some of the algorithmic methods for detecting and correcting map errors, but are they using all of them, and couldn’t they do more?!? For long-established businesses, there perhaps shouldn’t even be an option for users to suggest that a location is incorrect.

Owner-verified listings should be particularly trusted above user-generated content. In fact, there should be some safeguards in place for owner-verified listings such that “this location may be closed” and “the address location may be incorrect” messages perhaps shouldn’t be displayed at all without first alerting the contact email address for the listing, and even giving it some sort of time delay such as a month before the general public would see such a message.

Some of the top yellow pages sites which dealt with these types of data issues for many decades came up with business rules to help mitigate discrepancies in data sources. For instance, for a certain number of months after a business has been contacted and has updated/verified its own info, any other data source is set to a lower priority. And, this is the way it should be in Google Maps as well. The business owner has much more invested in insuring that location information is correct than the general public does. They have skin in the game! This is why data which comes directly from the owner is correlated with a higher degree of correctness than that of the general public (at least when that data is fresh or recently verified).

Google’s user-centered product development is great in many ways, but the ongoing refusal to properly incorporate and represent the business owner in the overall local business ecosystem is problematic. They are a type of user themselves, and they are a highly important demographic which should be given proper precedence in some areas of the communication and presentation of business information. This is why we undertook the experiment with the Google headquarters listing — to illustrate the disparity.

One suspects that Google employees overrode the crowd-sourced edits we submitted stating the location was closed — not only should the flag not have appeared, but the same sort of listing alerts and controls should be extended to small businesses who’ve verified their listings.


Panda photo by J. Patrick Fischer, CC BY-SA 3.0

For those of us who have been following Google’s evolution over time, the Panda updates actually weren’t all that surprising. For me, the emergence of Panda seemed very familiar, harkening back to perhaps as far back as 2006 when Google clamped down on affiliate sites. At that same time, Henk van Ess revealed how Google was hiring on temporary quality evaluation staff to rate search results. In Google internal documents which van Ess exposed, the evaluators were instructed to give poor ratings to spam content, porn ranking on inappropriate keyword phrases, and “thin affiliate content”. It became clear very quickly that the negative human ratings for “thin affiliate content” were related quite closely to the virtual penalization that many affiliate sites experienced at that time.

What Google was focusing upon in reducing the ratings of “thin affiliates” were instances where a search results page would be filled up with links to pages which all had virtually the same content, and where those pages often weren’t the final destinations of the people who landed upon them (obviously, with most affiliate sites one clicks-through to the actual retailer’s site where more information could be found and orders could be placed). From Google’s perspective, it was a poor user experience for there to be millions of pages indexed which had all essentially identical content and which often edged out other more-worthwhile pages which consumers might prefer.

From all of the information around the “Panda” Updates, it seems highly likely to me that Google is continuing to leverage their human quality evaluator staff, along with a number of other automated metrics which they could also incorporate in determining quality of pages. For instance, the numbers of people clicking back out of a page they found in the search results in order to select another page — this sort of a bounce rate metric could indicate which a page is of very poor quality for a particular keyword term.

Naturally, there are far more pages on the internet than what Google may reasonably have evaluators visit and assess, but there have also been developments in methods for using small numbers of ratings to be algorithmically applied across larger numbers of websites and pages. The TrustRank analysis technique is just one of these methods, and the research paper describing it shows how one could use a small sample set of rated webpages in combination with an automated analysis of the link graph associated with those pages in order to broadly apply ranking decisions to good content or poor content.


TrustRank Diagram

The combination of human interaction metrics is likely used by Google to determine a sort of “quality score” for pages, and some sort of mechanism similar to the TrustRank method is used to apply the quality score values across a broad swath of a site’s sections and pages.

While the Panda Updates were initially targeting “content farms”, or sites which specifically generated large numbers of pages to target user search queries, the criteria used to ding them could easily wreck many other types as well. Poorly constructed sites where users are confused about where to find what they were searching-for, or sites which make a bad impression by being too crammed full of ads, tricky links, or unsophisticated layouts might also fall under the treads of Panda.

The leaked evaluator documents from Google gave a few ideas of the sorts of things which could decide between a “thin affiliate” that got bad ratings versus sites which happened to contain affiliate content but which might otherwise get good ratings. Having additional content on the pages, particularly “value-added” content such as maps or user ratings or price comparisons could make a difference.

Here in 2011, I’d say the bar is even higher, though. You want your site to make a good impression when a searcher lands upon it, and you want them to have trust in your content. You need the site to be usable so that it doesn’t frustrate users, and you need to seriously consider removing impediments which annoy or hamper users in getting what they’re seeking. That gigantic interstitial ad that blocks them from the page, or all the cluttered fineprint and links may result in higher bounce rates which will translate into lower rankings for you.

In the past year, Google introduced Page Speed as a ranking factor — a major element which impacts consumer satisfaction with webpages. In their blog posts about Google they mention improving a number of elements affecting quality of a sites, including spelling and grammar (we previously highlighted how Google could use spelling and grammar in quality determinations and rankings). With the increasing attention to user experience factors in ranking determinations, it has become clear that if you’re not doing usability analysis, you may not be doing SEO at all.

Search engine optimization based purely upon clever technical tricks really appears to be on the wane with the Panda Updates. SEO may really decline in favor of much more sustainable longterm attention to User Experience and Usability factors. Unfortunately, I don’t see a whole lot of websites or companies positioned to take advantage of the trends. Most of the companies I’ve consulted with continue to base site design decisions more heavily upon arbitrary egos, expediency, and mere immitation of their competition rather than upon informed UX testing.

You can catch some of us from KeyRelevance at next week’s SMX East in New York — Christine Churchill, President of KeyRelevance, and Chris Silver Smith, Director of Optimization Strategies, will both be speaking and moderating on various panels:

Sept 13:

• 7:30-9:00 SMX Boot Camp: Keyword Research & Copywriting For Search Success (Christine Churchill, speaking)
• 9:00-10:15 Google Survivor Tips (Chris Silver Smith, Q&A moderating)
• 10:45-Noon SMX Boot Camp: Link Building Fundamentals (Christine Churchill, moderating)
• 10:45-Noon What Every Paid Search Marketer Needs To Know About Google +1 (Chris Silver Smith, Q&A moderating)
• 1:45-3:00 Panda-Proofing Your Content (Chris Silver Smith, speaking)

Sept 14:

• 10:45-Noon PPC & SEO: Can’t We All Just Get Along? (Christine Churchill, Q&A moderating)
• 1:30-2:45 Best Practices With adCenter For Bing & Yahoo (Christine Churchill, Q&A moderating)

Sept 15:

• 9:00-10:15 Video Search Success Stories (Chris Silver Smith, Moderating)
• 2:00-3:00 Mobile Search Ads (Chris Silver Smith, Q&A Moderating)

We hope to see you there!

Quite a number of years ago, AOL got sued by some of their subscribers for not upholding service representations, and as a result, AOL began to automatically cache images and webpages from across the internet, keeping them in their servers in Reston, Virginia. This helped them to cut one leg off of the circuit for delivering content for their subscribers. As part of their caching process, they’d recompress images, knocking percentages of the images’ filesize off, reducing how much data needed to be transferred. This actually used to cause problems for some types of images, since their compression algorithm had one or two errors in it, causing big honkin’ artifacts to be left unattractively in the image.

(It’s very geeky of me, but I actually remember some of the image processes which would cause the compression errors, because I had to deal with cases at Superpages.com where our artists made ads for clients, and then the client might call us up and scream because the ad looked bad to them. Such calls could be confounding — imagine an irate attorney who pays many tens of thousands of dollars per year calling you up because he sees crap in the ad your team made for him, and when you pull it up on screen, you can’t see any problem! Then imagine trying to explain to him how he’s seeing the error because he’s on AOL, while the people in your company who create the ads are not on AOL… and you and up with an interesting conversation. Don’t EVER do tech support! But, I digress.)

Anyway, Google’s Page Speed service is taking AOL’s idea just a little further, because they’ve married a few of their services together in order to improve the HTML of the pages they’re caching. Some of that automated improvement will be stuff like rewriting the code to specify heights and widths of images, and minifying CSS or JS code. They might even be doing some of that image compression which was so troublesome with AOL’s rehosting of the entire internet.

But, I’m being snarky with the AOL comparisons! I actually think Google’s idea is a very cool one, and it’s one that I had previously predicted. It made sense once Google rolled out the Page Speed diagnostic (which helped webmasters find areas for improving their pages speed) to then roll out something that would cut down on the network travel time between web site servers and the endusers who request webpages.

This service also immitates other CDNs which came previously, such as Akamai and Amazon’s EC2. I’m a big believer in the power of CDNs, since they have long helped sites move content out closer to “the edge” of the network, reducing the time it takes to deliver webpages, images, Flash, videos, etc. I recommended a CDN for Superpages back when I was there, and it helped improve the user-experience for the millions of visitors we had.

Google’s deployment of this service is a great fit for them, since they already have an array of servers located around the globe, which had enabled them to essentially be their own content delivery network. Also, I wonder if Google couldn’t leverage some of their dark fiber to further reinforce their delivery network’s effectiveness.

The open question at the moment is whether integrating with Google’s Page Speed Service will positively influence search rankings. Since Google started using Page Speed measures as a ranking factor (another development we at KeyRelevance had anticipated), and since using their service would speed up a site’s delivery speeds, it’s easy to connect the dots to see that using such a service could provide a website with an immediate advantage for this ranking factor.

So, Google’s retread of a very old AOL idea may not be all that original, but it is cool since it’s a tool that could help optimize your site a little and improve your user experience very quickly.

Now, I see a wide range of numbers of reviews for all sorts of industries — from zero or just a small handful, to around a hundred, all the way up to a few thousand for highly-popular eateries located in big cities. So, a range of these numbers is normal, and for some cases it’s normal for there to be a few thousand.

For instance, the famous Union Oyster House in Boston is showing a couple of thousand reviews. Considering it’s the oldest restaurant (in continuous service) in the entire country, this even makes sense. It makes even more sense when you see that they have quite a few hundred reviews in Yelp, and OpenTable as well. When someone has placed a reservation for the restaurant in OpenTable, they may be receiving an invite to rate the restaurant after they’ve had their visit there. I’d say this is is a great practice and works well for everyone — the business itself, the person rating, OpenTable, and for consumers shopping for an eatery. The natural outcome is that they’ll have hundreds and thousand of reviews in a relatively short time period.

But, there’s something else going on in vacation rentals which is similar, but isn’t ideal.

Here’s an example from Avalon, California, on Santa Catalina Island where the main industry is tourism and there are dozens of vacation rentals which people stay at annually. Notice the high number (over 1300) of reviews Google shows for a rental agency there:

What I see happening is this: some travel information sites are listing vacation rentals, and allowing consumers to rate/review those rental properties. The rental properties are associated with a particular rental agency, and the travel info site is assigning all those reviews to the rental agency that they roll up under.

Now, this works well for cases where the property is handled by one company which handles the rental and property management. However, there are a lot of cases where multiple rental agents from different companies may be renting out the same property, depending upon who lets it out to a renter first. In those cases, having all the reviews rolling up under one company is unfair.

Where vacation rentals are concerned, I believe that consumers are also fairly naive about what it is that they are reviewing. They are likely being led to believe they’re reviewing the property itself — and if they property isn’t owned by the company managing it, details about its amenities maybe shouldn’t be applied to the rental company. For instance, the process of reserving and renting the property may have sucked, but the consumer is mainly being asked about how great the Wi-Fi was, the hottub, and the quality of the window views.

In most cases I’ve looked at across the country, the large bulk of these reviews are coming from FlipKey, operated by TripAdvisor.

FlipKey’s interface for reviewing the rentals encourages the property be reviewed more than the rental agency, as I suspected. The review form is titled “Rate this vacation rental”, rather than “Rate the property management company”, and it says “Review your stay”. Their tips do suggest that one “Describe the service you received”, but it also says “Tell us how you liked the home”, and to “Talk about the location and amenities” — neither of which are necessarily controlled at all by the property agency.

But, as I see it the primary issue is whether reviews of individual rental properties ought to be rolled-up into an aggregate to represent the rental agency in this manner. Google has no quick way of assessing instances where properties may be represented by multiple rental agents, and property owners sometimes switch the agents representing them — in which case do the reviews then get reassigned to the new rental agency, or do they stay associated with the first rental agent as part of their legacy?

This appears to be a form of spam. FlipKey has been clever with design this so that individual vacation rental reviews will roll up collectively under rental agent listings, and having their data associated importantly with so many businesses is useful in terms of some referral traffic as well as a promotion vehicle for potential advertisers.

This is yet another problem which Google has associated with user reviews and business listings. Not long ago, Google Maps rolled out “Descriptive Terms” derived from user reviews, causing undesirable and often unfair effects for local businesses.