| ||
| We live in SERP! |
| ||
| In a recent web content for one of our clients, I sang paeans to Google Adsense earnings' potential. In particular, I was referred to an article in USA Today that showcased instances of substantial Google Adsense earnings by website owners for whom Google's doles are like god-sent (never mind Google's own skyrocketing revenue from Adsense). Since I was constrained by my client's need to write on virtues of Adsense while authoring his web content, I couldn't focus on 'allegedly' darker sides of Adsense. I say 'allegedly' because it is not clear whether Google really is the culprit as made out to be. Be that as it may, let me turn to what a few website owners faced while trying to claim a pie of Google Adsense earnings. Stas Bekman's story Stas started publishing Adsense ads on his website from December, 2005. His site was already receiving 600 page-views a day, so Stas thought Adsense ads would be ideal to put his site-estate to perfect use. Since Adsense delivered highly targeted ads, there was always a chance that his viewers would click on the ads resulting in revenues for both Stas and Google. He was not off the mark in his assumption. The ads displayed on his website did generate clicks, and on one day the number of clicks surged to 169. This generated Stas's Google Adsense earnings of $32 on a single day. The 'WOW' however didn't last long. Google came hotfooted and charged Stas of generating invalid clicks from his website, suspending his account promptly. Whatever his Google Adsense earnings were at the time of suspension also stood withdrawn. Since Stas didn't pull down the ads immediately though they were of no use to him for the time being, it remained unclear as to who earned the commission money for the clicks generated during this period. Stas got going immediately and after a series of email correspondence, his account was finally restored by Google a few days later. Stas apparently agreed that deliberate clicks (click fraud) triggered the episode (which Google too said). But the question remained as to who did that? As it turned out, Stas had to forego $30 of his Google Adsense earnings. He didn't mind. He reasoned that for all its supposed follies, Adsense does fetch money for his website. What has Stas got to say on his experience? Taste this: “ Click here to read Stas Bekman's story. Benjamin Cohen's account A similar experience is reflected in Benjamin's account. In his case, after Adsense earnings stopped for him for the first time, Benjamin waited awhile and applied afresh. He got a new account but that too was terminated by Google for alleged 'click fraud'. Though he gives a fair measure of his Google Adsense earnings each time his account operated, Benjamin fails to mention anything regarding number of clicks or whether there were anomalies in them. After going couple of times through Benjamin's article, I concluded that more information would be needed to know what exactly happened. Benjamin complains about the VAT payments but that is something not directly related to Google Adsense earnings per se. Benjamin Cohen's account can be reached here. The truth The truth must lie between what Stas and Benjamin faced and the policies of Google Adsense. Let me turn to what Google has to advise on Adsense. To be sure, Google has lined up many success stories that range from health website to home improvement site to even one that deals in aircraft seating information for frequent flyers. If you feel intrigued, there's perhaps a reason or two there. The common thread is the fact that many site-owners do have bulging Google Adsense earnings. Speaking on behalf of Google, its reluctance to spell out all that we want to know is understandable, given the fact that the contextual advertising scene is becoming very competitive with each passing day. Having said that, I want to echo Stas's wish of having more control on Adsense account. In the least, let Google automatically filter self-clicks and not count them for revenue. YPN (Yahoo! Publisher Network) is already doing that. Why Google cannot is a mystery. If Google takes care of this small scruple, it'll make life easy for many site owners like Stas and Benjamin. Summing up Perhaps Google has reasons to act against Stas and Benjamin like it did. Perhaps not. Is the reason attempted click fraud? If so, what about their insistence that they didn't do what Google says they did? Even as the debate continues, let there be no doubt that the lure of handsome Google Adsense earnings is too much for small website owners to not abstain from opting for it. | ||
| 0 Comments | Post Comment | Permanent Link |
| ||
| Google finally released Google Notebook today. Google Notebook is a resource provided that allows you to take notes on web sites that you visit. You can mark your notes as private or share them with the rest of the world. You can compare this to delicio.us, furl, stumbleupon, etc. as a recent way in the past to help increase your web site rankings that would provide links to your web site. However, because of new developments there is another stronger reason to consider these options. With the Google BigDaddy update, resources point to the development of enhancing searches by what people 'bookmark' and take 'notes' to be a stronger ranking factor than in the past! With the greater number of pages being indexed it is becoming harder to rank web sites according to traditional methods. Google is actively pursuing ways to make the searches more accurate using users input, in ways such as Google Notebook for example. Matt Cutts of Google has an in depth blog on BigDaddy that enlightens this point. The BigDaddy Blog can be found here. Here are a couple of excerpts from the blog describing what BigDaddy function is. When you compare it to the recent development of Google Notebook and other services out there such as furl, stumbleupon, and delicio.us you can see how having your web site getting 'note'ed, 'bookmarked', 'furl'ed, and 'stumbled upon' can help with your rankings. "If your page is showing up as supplemental one day and then as a regular result the next, the most likely explanation is that your page is near the crawl fringe. When it’s in the main results, we’ll show that url. If we didn’t crawl the url to show in the main results, then you’ll often see an earlier version that we crawled in the supplemental results. Hope that helps explain things...Google is less likely to give those links as much weight now. That’s the simple explanation for why we don’t crawl you as deeply, in my opinion." "You ask “I’m wondering how you gain relevant links, in some sectors, without reciprocating, or paying? Do you believe that rivals would give you a free one way link, lol?” My answer is that trying to force your way up to the top of search engines is in many ways not working in the most efficient way. To the degree that search engines reflect reputation on the web, the best way to gather links is to offer services or information that attract visitors and links on your own. Things like blogs are a great way to attract links because you’re offering a look behind the curtain of whatever your subject is, for example." Google believes, as do I, that if we get more user input on if a web site is more valuable we can use that information to get more accurate search results. The 'votes' used in the past to rank a site valuable was done with links. The 'votes' used NOW to rank a site valuable are done with Google Notebook, delicio.us, furl, etc. (Although I strongly believe that linking will still remain a very strong point for ranking.) In the past it was only a matter of time before people learned how to abuse the linking 'votes' by creating linking farms. Google combated this by taking link age, link number on the same page, linking relevance, linking from the same IP address, linking source, etc. to weed out the cheating links from the genuine links. With this new way of ranking how valuable a web site is by personal notes, votes, stumbleupons, etc. dawns a new age on optimizing web sites. Soon people will think of ways to 'cheat' the system. Hopefully, Google will be ready for the 'cheaters' out there with this new way of adding value to a site and I hope that this will bring more accurate search engine results. But like an ancient proverb, "Be careful what you wish for, you may get it!" I may find my ranking in Google in the top 5 for 'seo consultation' to drop because of this! | ||
| 1 Comments | Post Comment | Permanent Link |
| ||
Several people have asked for the recommended way to move to a new webhost or IP address without having problems in Google. I tested this method this past Sunday and everything worked fine for me. I’ll walk you through my example, which is moving mattcutts.com from one IP address to another IP address by changing hosts. This is not an example of moving mattcutts.com to someotherdomain.com. I’ll talk about that a bit at the end. If you have a static site or can afford a day or so where your site can be in limbo between two IP addresses, life will be easier. If you have a dynamic site with databases and such, it’s trickier, even though the idea is the same. Step 1. Find a good web host and sign up for an account. Step 2: Make a back-up of your site at the new webhost. Step 3: Change DNS to point to your new web host. Step 4: Wait for the DNS change to propagate through the net. Step 5: Once you are sure people or Googlebots are fetching from the new webhost/IP address, you’re done. You can shut down the old site. Let’s talk through these in a little more detail. Step 1. Find a good web host and sign up for an account. Research + references should help you find a good host. I liked my current webhost (csoft.net) quite a bit and I did a lot of research, but the site readership was growing faster than I expected. I asked a (non-SEO) friend who runs a heavily-trafficked site what he uses, and he uses pair.com. In this example I’ll refer to things by IP addresses, and we’ll be moving from csoft with an IP address of 63.x.x.x to pair.com with an IP address of 65.x.x.x. Just as a reminder, DNS is the system that maps pretty names like www.google.com to an actual Internet Protocol (IP) address that a machine can use, such as 66.102.7.147. Step 2. Make a back-up of your site at the new webhost. If you have a static website, this isn’t that bad; just copy the entire file structure over to the new webhost and you’re done. Harder is something like a blog, which usually has a MySQL or other database for storing posts. Harder still is some e-commerce site that has to have its database kept in a sync’ed state. In that case, you might have to set up database replication between the old location and the new location while you are doing the transition. But let’s take the example of a WordPress blog with a MySQL database that can be down for a few hours without too much trouble. Assume that you’ve already used tar or FTP to copy the static files from one webhost to another. First, you want to create a new MySQL database at the new web host. Ideally, you can make it have the same database name and user name. If not, you’ll want to tweak the WordPress wp-config.php at the new location to update the database/username/password/etc. Now that you’ve got the MySQL database ready to copy over, dump the old MySQL database, copy it to the new webhost, and load your database at the new location. Those three commands would look like this:
Bear in mind that you have a username/password to login to the old and new webhosts, but you also have separate username/password for the databases at each location as well. You might even have the MySQL database stored on a different host, which is why I showed the -h (host) option when restoring the database. Again, if the new host has different options for your database, you’ll need to edit your wp-config.php file or WordPress won’t be able to access your database at the new webhost. Now you have identical copies of your site at two different locations. If you’re just running a blog with a comment or two a day, it’s not a big problem if someone posts a comment or otherwise changes your database while you’re doing the transition to a new web host. If you run a big, industrial-strength forum or e-commerce site, you’ll need to do extra work to keep the two databases and/or file systems synchronized. Step 3: Change DNS to point to your new web host. This is the actual crux of the matter. First, some DNS background. When Googlebot(s) or anyone else tries to reach or crawl your site, they look up the IP address, so mattcutts.com would map to an IP like 63.111.26.154. Googlebot tries to do reasonable things like re-check the IP address every 500 fetches or so, or re-check if more than N hours have passed. Regular people who use DNS in their browser are affected by a setting called TTL, or Time To Live. TTL is measured in seconds and it says “this IP address that you fetched will be safe for this many seconds; you can cache this IP address and not bother to look it up again for that many seconds.” After all, if you looked up the IP address for each site with every single webpage, image, JavaScript, or style sheet that you loaded, your browser would trundle along like a very slow turtle. You can actually see the TTL for various sites by using the “dig” command in Linux/Unix:
In this case, the Time-To-Live for the IP address for mattcutts.com is 3572 seconds (a little less than an hour). Time-To-Live is an important factor for a site’s DNS. Some sites like google.com, yahoo.com, and msn.com have really short DNS TTL settings like 300 to 900 seconds. Why? Well, if you have multiple data centers, you might want to take one data center down so that the data center mechanics can sprinkle fresh, magical index data onto the machines. With a short TTL, you could pull a data center’s IP address out of the rotation in just a few minutes. That also helps explain the “Google Dance” of days gone by. The Google Dance would last for about a week, and people would see both old and new results, depending on which data center they happened to hit. The underlying reason was that each data center was brought down, loaded with new data or algorithmic settings, and then brought back up again. It took several days to switch the data at all data centers. During that time, webmasters used to love to check www2.google.com and www3.google.com because those DNS aliases usually pointed to the newest data centers. These days our production system is better equipped to switch things around quickly instead of over several days. There, a little easter egg for the people who care about DNS. In fact, it’s even worse. DNS is hierarchical. At the top of DNS there are 13 root servers that can handle any DNS lookup for a .com domain, but DNS caches flow all the way down to ISPs like Comcast or Cox. If someone on Comcast looked up your IP address just before you changed your DNS settings, all of Comcast would use the old IP address until the Time-To-Live expired. So the upshot is that if you can make your TTL short (like an hour) instead of long (like a day), you’ll be in much better shape. Everyone will move to your new IP address in short order instead of having a mish-mash where some people are using the old IP address for hours. The actual switchover process is pretty easy. Your new webhost will give you a pair of nameservers to use as the primary nameservers. If you have a domain registered with GANDI (the delightful French registrar that I happen to use), you go to account settings and switch from the old webhost’s nameservers to the new webhost’s nameservers. GANDI (and probably other registrars) is smart enough to recognize nameservers that are already present in the DNS system, so it can make the change pretty much immediately. If you’re going with a nameserver that no one has ever heard of before, you might have to wait 24 hours or so for things to percolate into the system. Step 4: Wait for the DNS change to propagate through the net. This is mostly a function of TTL and whether you’re switching to nameservers that are already present in DNS. Remember that DNS is hierarchical, and you have to wait for DNS caches to be flushed as Time-To-Live is exceeded. If you are using a smart registrar and a well-known set of new nameservers, the switch at the root level of DNS can be pretty quick. To verify that the root servers have the new nameserver, you can use the “dig +trace domain” command in Linux/Unix. The “+trace” option tells dig to go all the way up to the DNS root servers for the lookup:
Above you can see that my nameservers have switched to pair.com nameservers. After that, you just have to wait for TTLs to expire for your new nameserver (and thus IP address) to wend its way out to everyone. If you are on a Windows XP system, you can use the command “ipconfig /flushdns” to flush your machine’s DNS cache, but it probably won’t do much good by itself. Remember that DNS is cached at each level, so your ISP probably has cached the previous IP address until the TTL expires. Step 5: Once you are sure people or Googlebots are fetching from the new webhost/IP address, you’re done. You can shut down the old site. When you ping your domain and see your new IP address, you know that you’re getting close. Previous visitors might still be using the old IP address from their DNS cache, but new visitors are getting the new IP address. It’s still a good idea to give a day or so in case anyone had a long Time-To-Live set, but most TTLs are a day or a few hours or less. After a day or so, it should be safe to deactivate the hosting at the old location. If you want to be ultra-safe, check your logs. When you see Googlebot fetching from the new webhost and no more visitors in your logs at the old location, it’s okay to turn off your old webhost. Moving to a different domain Now let’s talk for a minute about moving from mattcutts.com to someotherdomain.com. All other things being equal, I would recommend to stay with the original domain if possible. But if you need to move, the recommended way to do it is to put a 301 (permanent) redirect on every page on mattcutts.com to point to the corresponding page on someotherdomain.com. If you can map mattcutts.com/url1.html to someotherdomain.com/url1.html, that’s better than doing a redirect just to the root page (that is, from mattcutts.com/url1.html to someotherdomain.com). In the olden days, Googlebot would immediately follow a 301 redirect as soon as it found it. These days, I believe Googlebot sees the 301 and puts the destination url back in the queue, so it gets crawled a little later. I have heard some reports of people having issues with doing a 301 from olddomain.com to newdomain.com. I’m happy to hear those reports in the comments and I can pass them on to the crawl/indexing team, but we may be due to replace the code that handles that in the next couple months or so. If it’s really easy for you to wait a couple months or so, you may want to do that; it’s always easier to ask crawl/index folks to examine newer code than code that will be turned off in a while. | ||
| Permanent Link |
Okay, where were we? Right, switching DNS and Time-To-Live. You should care about TTL because if someone loads your website in their browser just before you update your DNS settings, and your TTL is one day, then that person’s browser will try to use your old IP address all that day.
| ||
We've been talking about it for over a month, and now you can now give Google Health a try before it is launched. Visit http://64.233.167.99 (one of Google's datacenters) and search for anything health related. The results page gives users the option to narrow down or filter to produce desired results. For example, I searched for migraine and it let me choose from various options including: treatment, research papers, symptoms, news and alternative medicine. Clicking on "From medical establishment" gives even more options.
Basically, Google Health is what I expected — an enhanced way to search for health related material. Lots of people were hoping for a more feature-rich product (including myself) but that's not usually how Google operates. They like to see and hear what people want before they spend time developing what they think people want — this is how they get things done so quickly. What do I think? I like the service as it reminds me of a great product called kosmix.com — a vertical search engine that was designed to help users find health related content. Google Health delivers better results to users searching for medical information without them having to learn how a new service works. I do hope they eventually expand this service so it acts more like a health information portal. I'm thinking it could turn into a service like Google Finance that links a bunch of Google services together. Groups to link users with similar conditions, Images to see visually how something might look, News to see if there are any recent medical breakthroughs, Maps to find local medical clinics, etc. Right now we just have integration with Search — but it's a good step in the right direction. | ||
| Permanent Link |
Cheap phone card at PB - Telephone cards for international calls
Cheap prepaid calling cards at CC21 - Calling cards online
Homes, Real Estate For Sale By Owner - Buy and sell homes online without realtors
Jewelry news and stroties at JT - Jewelry Blog
Telecommunications World at JT - Telecommunications news
Blog Search Bot at BSB - HQ Blog Search Engine