I was pleasantly surprised to find that my FeedEntryHeader plugin was featured on Episode 28 of the WordPress Weekly podcast. The mention was fairly brief,  but it’s nice to be noticed by such an influential podcast.

I’d like to thank Keith Murray for making FeedEntryHeader his plugin of the week. WordPress Weekly is one of the regular features of my 40 minute train ride into the Brisbane CBD. I always listen to the plugin of the week section with interest, but never thought one of my WordPress plugins would appear.

It’s probably lucky that I found out that FeedEntryHeader was featured before I listened to Episode 28. If I’d been taken by surprise on the train, there’s no telling what my reaction may have been!

Anyway, Keith mentioned the threat of having your content scraped by a splog and the role that FeedEntryHeader can play in combating this.

Ironically, I found out that FeedEntryHeader had been featured on WordPress Weekly when I followed a backlink in my WordPress Admin Dashboard. It took me to a splog, which appears to have been scraping Weblog Tools Collection! There was a copy of the Episode 28 page, word for word, including the link to the FeedEntryHeader home page.

So… I found out that WordPress Weekly Episode 28 had mentioned my plugin as a weapon against splogs, through one of these very splogs, that had scraped the Episode 28 page! This is the bit where I say that Weblog Tools Collection should use FeedEntryHeader right?

Well, as it happens, they’d been scraped by a reasonably nice splog, which had left all the post’s links intact, including the post title link pointing at the original post. However, FeedEntryHeader would have made it clearer to people that they were reading the post on the wrong blog. It could also help them with the other, not so nice splogs.

Anyway, it was very nice to have been mentioned by WordPress Weekly. It’s a great podcast and I have a lot of respect for the guys that run it.

There are dozens of new web based applications being launched every day. Most are moderately useful, but it’s rare that I actually need to use one. After playing with them for a while, I normally abandon them and go back to the core tools I use to get things done.

Well, I found one that’s going right into my toolset: smush.it, the image optimisation web application.

I recently read yet another one of those posts that list free web based applications that you must use! There are too many of these posts going around to keep track of. You see the same applications listed again and again and the lists grow longer and longer. Tiresome, but I still read them!

I’d seen smush.it mentioned before, but on this particular day, I decided to click through and check it out.

To be honest, I was skeptical before I tried it. I thought I knew a bit about balancing quality and size for web images. I use Adobe Fireworks CS3, which is pretty good at creating images optimised for the web. So, when I tried running smush.it on my blog’s header image, I wasn’t expecting much.

Results time: smush.it reduced my header image from 57.3KB to 46.7KB. That’s a saving of about 19%!

Here’s the original 57.3KB file created in Fireworks (click to open):

And here’s the 46.7KB smushed image (click to open):

You can guess which ones up there in the page header now!

When I open the smushed image in Fireworks and save it again, it goes back to 57.3KB. That’s for a flattened PNG24 image (same as the smushed image). Whatever Fireworks is adding, it must be pretty big! The only visible difference I can see is that the smushed image is 96dpi, while the original is 71dpi.

I also tried smushing some other images and only got a saving of around 2%, but every little bit counts and if you can occasionally chop 19% off an image, then it’s well worth running. I’ll be a regular user of smush.it from now on.

I optimised the image via the smush.it site, but they’ve also got a Firefox extension (or bookmarklet for other browsers) that will smush all the images on a web page and provide you with them in a zip file for you to download!

Who’s behind this new web 2.0 offering? Stoyan Stefanov and Nicole Sullivan, who are part of the of the Exceptional Performance team at Yahoo! (the team responsible for YSlow). No wonder it’s good!

Anyone else out there had any success optimising images using smush.it? Matt Mullenweg, if you happen to come across this, smush.it can reduce your main header image by 6.45KB (or 4.81%). Happy smushing everyone!

I recently ran into a CSS problem with a centered fixed width layout. It’s probably been written about before and experienced web developers may already know this, but it caught me out. I’m reasonably experienced, so I thought it worth mentioning here.

The Problem: Fixed Width Centering Inconsistent

I’ve been developing a website for a client, which uses a fixed width layout. I know there are arguments against using fixed width layouts, but leave that aside for the moment. It was fixed width.

The site was centered, using margin:0 auto; on the body element.

Things were looking good, until I added the fourth page. Then I noticed that there was a slight offset, maybe about 8px, between the centering on some of the pages.

When navigating between pages, the whole page (including the menu) would jump slightly to the left or the right. This was annoying (and bad for usability) as the menu should be positioned consistently on all pages.

Browser Consistency: Problem In Firefox, But Not IE

I checked to see if this was consistent across different browsers. The problem occurred in Firefox and Chrome, but not in Internet Explorer.

I didn’t bother checking Opera or Safari, as I was pretty certain they’d be the same as Firefox and Chrome (especially in the case of Safari which shares the same browser engine as Chrome).

Tracking Down The Problem

I set out to track down the problem, but it was slippery. Some pages were fine, some slightly to the left. I seemed to be able to make the problem disappear through various methods: reducing the font-size, removing a paragraph, removing an image, reducing the bottom margin values.

However it was inconsistent: one of the above methods would fix the problem short term, but later the problem would be back and the method would no longer work. Then the penny dropped:

The problem was happening when the browser scrollbar was shown.

When calculating the size of the area to center the page in, it was using the full width for short pages (with no scrollbar) and the full width minus 17px for long pages (with scrollbar). So obvious in hindsight! My ’solutions’ worked only because they shortened the page enough for the scrollbar to disappear.

The Solution: overflow:scroll

Fortunately, there was a simple solution: I added overflow:scroll to the body CSS element.

This will cause the scrollbar to always appear (if the page is wide enough), regardless of whether the page is long enough to actually need it. While this is annoying, it’s better than having the menus move around between pages.

Final Thoughts

Most sites I work with never have a page short enough for this problem to occur! In theory, the problem could occur on this very blog, but the sidebar is so long that the scroll bar will always be shown.

Have you ever been tricked by a CSS problem that has such a simple explanation in hindsight? If so, please share it in the comments!

It’s been a while since I last posted, because I’ve been tied up with some other projects. My focus is now returning to this blog, but before I get into anything of substance, there’s some housekeeping I need to take care of.

If you subscribe to the feed of one of my WordPress plugin categories, please be warned that these feeds will be removed in 7 days time. The feeds in question are the following:

If you want news about my WordPress plugins, please subscribe to the following feed:

http://www.scratch99.com/category/my-wordpress-plugins/feed

This feed will contain news and tips relating to ALL my WordPress plugins.

Alternatively, you can subscribe to the feed relating to the tag (rather than category) for each plugin. These will probably have all the news relating to each plugin, but may also contain other posts that mention the plugin in passing. These feeds are as follows:

• DualFeeds Tag Feed
• IFrameWidgets Tag Feed
• FeedEntryHeader Tag Feed
• LocalCurrency Tag Feed
• KeywordLuv Tag Feed

I’ve taken this move for two reasons:

1. I’m consolidating my categories, because I have too many of them. This will merge 5 categories into one general category for my WordPress plugins.
2. I normally stick to one category per post, but I often have news relating to more than one plugin. This will allow such news to reach everyone who needs it.

I regret any inconvenience this may cause, but hopefully it will result in a better site.

I recently listened to the WordPress Podcast - Episode 44. Although it’s a couple of months old now, it was quite interesting and one issue really caught my eye ear: the security related question for Matt Mullenweg at around 1:13:30 of the podcast.

A listener, Simon Jones from beforeiforget.co.uk, talked about the difficulty of changing the default WordPress user name from admin to something a little harder for hackers to guess. The only way to do this is to change it in the database itself - it can’t be done through WordPress.

Simon’s main question was "Why isn’t there an easier way to change the default user from admin to something else?". Matt didn’t actually answer this, presumably because Simon’s question was fairly long and to be honest, could have been a little more to the point.

However, Matt did mention that it’s very difficult to brute force WordPress because such an attempt would need to submit thousands of requests per second and web servers won’t allow that many requests. He also mentioned that he’d changed his user name, though obviously not for security reasons, because he told everyone what it was!

Anyway, the podcast has inspired me to go on to discuss a couple of points related to WordPress security:

Password Strength

What Matt didn’t say (because it’s elemental) is that having a strong password is essential. A user name / password combination of Admin and dS35Hg68p1d will be much harder to break than one of admin and WordPress.

If you have a strong password, leaving user name as admin is less of an issue. So make sure your password is reasonably strong.

Protecting The Wp-admin Folder

For the paranoid, such as myself, who are worried about their WordPress login being hacked, it’s possible to add an extra layer of security to the wp-admin folder. This is more effective than just changing the default user. There are different ways to do this, including:

• only allowing users from a certain IP address or range to access the wp-admin folder
• using the AskApache Password Protect plugin to password protect the wp-admin folder
• using CPanel to password protect the wp-admin folder (here’s a general tutorial, but one that could be applied to wp-admin)

The second two methods will present the user with an additional user name / password prompt before the normal WordPress login screen can be accessed. This obviously takes longer to log in, but it also makes it much more unlikely that your site can be hacked.

Problem With Password Protecting The Wp-admin Folder

When I first tried to password protect the wp-admin folder, using the AskApache Password Protect plugin, I ran into a serious problem. I wasn’t given the “Authentication Required” window, I just got a 404 File not found message. This meant I was unable to log into my WordPress system and couldn’t access the plugin screen to turn off the password protection.

So how did I get access to my site again? I logged into my host via FTP and removed the following files:

• .aahtpasswd from the public_html folder
• .htaccess from the public_html/wp-admin directory (not the one from public_html)

I later experienced this same problem when password protecting the wp-admin folder via Cpanel, but of course, I could just turn off the password protection again via Cpanel.

I found a permanent solution to this problem at Developed Traffic’s WordPress admin password protection 404 post. The solution is to create an empty file called myerror.html and upload it to your public_html folder, then add the following to your .htaccess file (in public_html):

ErrorDocument 401 /myerror.html
ErrorDocument 403 /myerror.html

If you want to store the myerror.html file in a folder, rather than in public_html, then simply add the folder’s name to the two lines, ie:

ErrorDocument 401 /foldername/myerror.html
ErrorDocument 403 /foldername/myerror.html

That should fix the problem - although I’m not sure what impact it may have on other things (ie by having 401 and 403 go to the new file rather than WordPress handling it). If anyone out there know this please let me know in the comments.

The Real Lesson About WordPress Security

This post is all about trying to minimize the slight chance that someone may be able to break into your WordPress system via the login screen. I’m willing to bet that out of all the WordPress blogs ever hacked, very few of them would have been hacked via the login screen.

In the previous section, I mentioned how I locked myself out of the WordPress login screen, but got around it by FTPing in. All that security on the login screen is worth nothing if someone gets access to your host account via FTP.

From what I’ve heard, most hacked sites were compromised via:

• their host login being stolen after their email account was hijacked and used by the hackers to get the login details from the host service provider
• through an XSS exploit in WordPress

So the real lesson is to keep your computer free of viruses and spyware and your WordPress installation up to date with the latest security releases.

If you have any further thoughts on WordPress security, please let me know in the comments.

I recently wrote about displaying ads only to search visitors in WordPress. A key part of the technique described is to set a cookie, identifying the visitor as having come from a search engine. It should have been simple, but my PHP setcookie command didn’t appear to work.

I was using the setcookie command in the same way I’d done countless times before. I’d already taken into account that the cookie wouldn’t be available on the first page view. I couldn’t see anything wrong with the command I was using (in functions.php in the WordPress theme I was creating):

setcookie("sevisitor", 1, time()+3600);

This should have set a cookie with a name of sevisitor and a value of 1, that expires after one hour. However, no cookie was created.

After scouring the Internet in vain, I found a hint somewhere in the WordPress Support Forums (although I can’t find the page again now!). It suggested that the setcookie command’s domain parameter needed to be set.

I’d never used this parameter before and although I’ve seen explanations of what it does, I still can’t find a clear explanation of why you’d want to use it. Most descriptions of it mention that it’s optional, but don’t mention under what circumstances it would be necessary. Any PHP experts out there, please feel free to put me straight in the comments!

Anyway, after some experimentation, I got it working, by using the following command:

setcookie("sevisitor", 1, time()+3600, "/", ".scratch99.com");

Problem solved! As you can see I’ve done the following:

• added the path parameter, setting it to “/”, which allows the cookie within the entire domain.
• added the domain parameter, setting it to my top level domain (.scratch99.com). Note the preceding . apparently makes it compatible with more browsers.

Obviously, if you want to set a cookie in WordPress, you’ll have to replace .scratch99.com with the domain you are using.

Alternatively, you could let WordPress work out the domain for you, by using the following:

setcookie("sevisitor", 1, time()+3600, "/", str_replace('http://www','',get_bloginfo('url')) );

This uses the get_bloginfo('url')) command to get the site’s URL from WordPress, then strips the preceding http://www from it, leaving only the domain. Note, if you don’t use the www on your site, you’ll need to change:

str_replace('http://www'

to

str_replace('http://'

However, it’s really not worth doing things this way – your site will be slightly faster if you hard code your domain in.

The only time you’d want to use the above would be if you were putting this into a WordPress Theme that you were creating to be distributed. In that case, you’d probably want to make it a little cleverer, so that it works whether or not the www is present. But I’ll leave that to you to work out!

Anyway, the lesson I learned: If you want to set a cookie in WordPress, you must set the path and domain parameters.

In the past, I’ve written about only showing Google Adsense to search engine visitors, so as to decrease the chance of being smart priced. In this post, you’ll see how to improve the technique outlined previously, so that you can make more money.

Background On Smart Pricing

By now, most people know that Smart Pricing is a penalty Google applies to Adsense accounts that don’t convert well for the advertiser, resulting in you earning only about 10% of what you’d normally earn per click.

I’m not going to go into more detail than is absolutely necessary in this post, so if you want more information on Smart Pricing, see my post on how smart pricing may cost you money or for the ultimate description, see Grizzly’s Optimization Tips for Adsense.

For now, you just need to know that only certain visitors are going to click Adsense ads and buy something from the advertiser. Who? It’s not your regular readers. It’s not the stream of visitors from StumbleUpon, Digg or Sphinn. It’s the search engine visitors.

Search engine visitors provide targeted traffic for the advertiser, which converts well. The other sources don’t. If the majority of your traffic comes from the social news sites, then you’re in danger of being smart priced. That’s why I chose to show Adsense only to search engine visitors.

The Original “From Search” Function

In my original Shylock Adsense Plugin - Hack To Avoid Smart Pricing post, I provided two approaches: one based on hacking just the Shylock Adsense plugin; another on a more generic solution that can be called from wherever you want (within the Shylock Adsense plugin, the sidebar, single.php, etc).

In this post, I’m using the second approach as it has a wider application. This was originally explained in the Hacking Shylock Adsense AND Sidebars section of the previous post. This worked by adding the following function to functions.php in your theme’s folder (wp-content/themes/yourtheme folder, where yourtheme is the name of your theme):

function scratch99_fromasearchengine(){
  $ref = $_SERVER['HTTP_REFERER'];
  $SE = array('/search?', 'images.google.', 'web.info.com', 'search.', 'del.icio.us/search', 'soso.com', '/search/', '.yahoo.');
  foreach ($SE as $source) {
    if (strpos($ref,$source)!==false) return true;
  }
  return false;
}


This function was then called from the Shylock Adsense plugin, a sidebar widget, or anywhere else you may want to, via the following code:

if (function_exists('scratch99_fromasearchengine')) {
  if (scratch99_fromasearchengine()) {
    INSERT YOUR CODE HERE
  }
}

Obviously, INSERT YOUR CODE HERE needs to be replaced with whatever code you want to show the search engine visitors: your Adsense code if it’s in the sidebar (using the ExecPHP widget) or the Shylock Adsense code (see my original post for more details).

Problem With The Original Function

As Zath pointed out in the comments, the original function only works on the first page the visitor lands on. If the visitor subsequently navigates to another page on your site, the ads disappear. This is because the http_referer is no longer the search engine, it’s now the page where they landed on your site.

Of course, that means they no longer have the option to click an ad before leaving the site. I wasn’t worried about this, because I figured not many search engine visitors would go to another page on my site. I was wrong!

Leaving Money On The Table

According to Google Analytics, over the last month, visitors arriving at this site from a search engine read 1.54 pages per visit. That means that every second visitor is clicking another page.

Every second visitor! That means I could be serving up 50% more ads to the sort of visitor who is likely to click ads!

I decided I better change the way I was doing things, so that search engine visitors see ads on every page they visit at my site. Fortunately, this is fairly easy to do, by setting a cookie that identifies search engine visitors.

New “From Search” Function Using Cookie

Here is the solution I’m now using on this blog.

First, the you need to add some code to functions.php in your theme’s folder (wp-content/themes/yourtheme folder, where yourtheme is the name of your theme). The following should be added immediately before the ?> at the bottom of the file:

$ref = $_SERVER['HTTP_REFERER'];
$SE = array('/search?', 'images.google.', 'web.info.com', 'search.', 'del.icio.us/search', 'soso.com', '/search/', '.yahoo.');
foreach ($SE as $source) {
  if (strpos($ref,$source)!==false) {
    setcookie("sevisitor", 1, time()+3600, "/", ".scratch99.com");
    $sevisitor=true;
  }
}
 
function fromasearchengine(){
  global $sevisitor;
  if ($sevisitor==true || $_COOKIE["sevisitor"]==1) {
    return true;
  }
  return false;
}


Note: In the setcookie line, you must change “.scratch99.com” to your own domain!

The fromasearchengine function can then be called from wherever you want to use it (to check if a visitor is from a search engine or not). This is explained further below.

Notes About The New “From Search” Function

The code that detects whether the user is from a search engine has been moved out of the fromasearchengine function, into the body of functions.php. This means it will only run this code once per page load, rather than every time the function is called, which may be several times per page load (I call it from Shylock Adsense and from the sidebar).

Also, the $sevisitor variable was introduced because the cookie can’t be detected on the first page view. The cookie is set on the first page view, but the $_COOKIE function won’t see it until the next page view. The above code checks whether the $sevisitor variable is set (ie it’s the first page view) or whether the cookie is set (ie it’s a subsequent page view).

I had one problem with setting the cookie via WordPress, but it doesn’t affect the final solution above, so I leave that for a future post.

Calling The New “From Search” Function

To call the new fromasearchengine function from Shylock Adsense, edit the shylock_adsense.php file which comes with the plugin. Look for the following code (on line 325 in version 1.2):

function shylock_adsense_filter($content){
  global $id,$user_level;
  $output = $content;

and replace it with:

function shylock_adsense_filter($content){
  global $id,$user_level;
  $output = $content;
 
if (function_exists('fromasearchengine')) {
  if (fromasearchengine()) {


Then go down to about line 364 and look for:

  return $output;

and replace it with:

} } return $output;

Alternatively, to call it from a PHP sidebar widget or somewhere else (such as single.php), you would add the following code in the appropriate place:

<?php if (function_exists('fromasearchengine')) {
  if (fromasearchengine()) { ?>
    INSERT YOUR CODE HERE
<?php } } ?>

replacing INSERT YOUR CODE HERE with your Adsense code or whatever else you wanted to show the search engine visitor.

Final Thoughts

Using this technique, to set a cookie to identify search engine visitors, then only serving Adsense to such visitors, should help you make more money, while avoiding being smart priced. However, as always, it pays to experiment with Adsense and monitor the affects on your income.

Of course this technique will have other applications as well, allowing you to serve whatever content you like to search engine visitors. I hope some of you find it of use.

This post marks an exciting new theme for More Than Scratch The Surface. Regular readers won’t recognise the site! I’ve extensively overhauled the theme and in this post I explain the changes, the choices I made and why I made them.

Firstly, for my regular readers, if you’re reading this in a feed reader, come on over to the site and check it out. I’d love some feedback from you. And if you find any problems, please let me know.

Screenshots

For posterity, here is a screenshot of both the old theme and the new one:

A New Theme?

Actually, it’s not a new theme, it’s the same theme. I’ve just totally overhauled it to the extent that you wouldn’t know it’s the same theme.

My original plan was to start from scratch and build a new theme from the ground up. However, I’m short on time at the moment, so I decided to just adapt my current theme.

I started by creating the header graphic and the menu section in straight HTML, then modified my current WordPress theme to incorporate it.

Making the new stuff work with the old has resulted in some very messy HTML / CSS. I’m quite irritated by this, so I’m still planning to create a new theme, from the ground up, when I have time.

It’s also not quite finished yet. I have some other features I’d like to add and I’m not quite convinced by some things (the font, the link colour, the background colours), so there’ll be some small changes in future.

However, this post marks the big change and I’m pretty happy with the general look of the theme, especially the header. So which designer did I use to create it? Me! And I really enjoyed doing it.

The Menu

I originally included a text based menu, but ended up changing to an image based menu.

In general, I prefer text based menus because they’re simpler, cleaner and easier to maintain. However, I’m a bit of a control freak at times, and the text menu didn’t look so good when the text was resized. This was a ‘problem’ even when specifying the font in px (IE won’t resize but Firefox will).

By using an image based menu I could ensure that the menu will always look right. As a bonus, using an image allowed me to use a far more attractive font! I was going to go all glassy buttons with the menu, but decided that would make the page too busy.

I understand that one of the principles behind accessibility is that the user can decide how the page will look. I don’t mind resizing for most of the page, but I don’t want the menu to appear broken, especially as the site acts as an advertisement. Let’s face it, potential clients are probably more concerned (wrongly) about looks than they are about accessibility.

Anyway the menu IS accessible: the HTML is clean and the menu is an unordered list. If the user disables CSS, provides their own style sheet or is using different media, they’ll get a nice list of menu options. Note, I made a point of saying the menu is accessible, because once you hit the sidebars, things aren’t perfect. It’s not terrible, but not as good as I’d like.

Images And Performance

Having read many times that one of the keys to speeding up a page is to reduce the number of http requests, I made a concerted effort to reduce the number of images used in theme. I even went so far as to sacrifice size to achieve this.

The old theme had 8 images with a total size of 18KB. The new theme only has 3 images, but they weigh in at 68KB. The new images were always going to be larger than the old theme’s, but I’m sure I could have kept it under 50KB if I’d split the images up further.

The image based menu increased the total size of images used, especially as the image changes on mouse hover. I used CSS sprites to keep the number of images needed down: the images used for the menu’s normal and hover states are both part of the main header image.

I’ll admit that the image size worries me, so I’ll be keeping an eye on performance. I’m not sure at what point the size outweighs the number of http requests.

This influenced my decision not to use JQuery to fade in the hover state. I’ve been playing with JQuery lately and I like the idea, but it’s not worth adding the size of the JQuery script just to get fading menus. If I start using JQuery for something else, I’ll revisit this idea.

Finally, I used an image for the background of the WordPress plugins blurb near the top of the sidebar. No big deal right? Well I actually used a vertical sliding doors technique to cater for the user resizing the text. It may be overkill, but you have to increase the text size about 20 times in Firefox before it starts to fall apart. I’ll write up how I did this in a separate post.

Advertising

Another big change with this theme is that I’ve finally embraced direct advertising and built ad spaces into the theme. I’ve been planning to do it for a while and the new theme seemed like the right time to introduce it.

I’m offering special introductory prices (50% off) until the slots fill up, making it only $12.50 for a spot at the top of my sidebar, or $7.50 for a spot lower down in the right sidebar. If you want to advertise on More Than Scratch The Surface, check out my Advertise page!

One important thing to note however, is that I’m nofollowing the links, to protect both the advertiser’s site and mine from attracting a toolbar PageRank penalty from Google. Advertising here is purely to build brand awareness for your site and send you traffic, not to game the search engines.

Final Thoughts

I’ve spent a fair bit of time making these changes to my theme and I’m very happy with the new look. But what do you think? Leave a comment and let me know!

For those of you who don’t know, there’s a new social news site for WordPress, called WPVote. I’ve been using the site for a couple of days and while the concept is great, the quality of entries are poor at this early stage.

I’m a big believer in the idea of a social news site for WordPress. It’s a great way of pooling together all of the WordPress related posts out there, making it easy for people to find quality information about WordPress.

The Published News section should be the most valuable list of WordPress related articles around. Unfortunately however, to be quite frank, there’s a lot of crap in the Published News section at the moment.

There are the obligitory Top WordPress Plugins Lists that don’t add anything new (and seem to miss many of the essential plugins to boot), generic How To Blog posts with only a tenuous link to WordPress, and posts that don’t really help. For example, one post includes the point:

If you have added a new feature to your WP blog by writing some PHP code that executes SQL queries; make sure that you minimize the load on the server.

If you know what that means, you probably don’t need to be told. If you don’t know what that means, this doesn’t help you at all! If it had a link to a site that told you how to minimise the load on the server, then it would add value. Without such a link, it’s useless.

I won’t link to these entries here, as I’m not having a go at individuals and don’t want to single anyone out, but posts such as this don’t belong in the Published News section.

Now, I’m not saying that these articles are all bad (or that mine are better), or that there aren’t top quality posts there as well (see Perishable Press’ excellent and original article on .htaccess rules for permalinks), or that this doesn’t happen on other social news sites.

I’m not even saying that the poor quality entries shouldn’t be on WPVote. Of course they’re entitled to be! I just want to see better quality in the Published News section. How do we get that?

We all need to get behind WPVote. Submit quality WordPress articles when you find them. Vote on entries in the Upcoming News section. Add comments. Spread the word about WPVote, so the community grows.

I know this post sounds harsh, but it’s a call to action. I believe WPVote can be truly great - but the only way that will come to pass is if we all get behind it. Let’s make WPVote great!

This morning I noticed an entry on Sphinn highlighting GreyWolf’s Seth Godin Wants to Cheat Advertisers with Fake Clicks post. It discusses Seth Godin’s Ads are the new online tip jar post, which suggests that readers should click ads to reward bloggers for their writing. To quote Seth:

If you like what you’re reading, click an ad to say thanks.

GreyWolf condemns Seth’s advice and rightly points out that anyone following this advice is guilty of click fraud:

If you click on an ad and your purpose is to make sure the site owner or blogger gets money from the click, and you had no intent to buy or research, that is click fraud.

As you’d expect, given they are Internet Marketing / SEO communities, comments on GreyWolf’s post and on Sphinn strongly condemn Seth’s statement. The majority of commentators agree that this is click fraud. I concur!

However, what’s intrigued me is that no-one’s mentioned the effect this may have on a blog being smart priced by Google. Seth’s advice may actually end up costing bloggers who run Google Adsense.

I’m not sure why no-one’s mentioned this. It may be that most members of those communities fall on the advertising, rather than publisher, side of the fence. I’m definitely on the publisher side, so I’ll go ahead and explore the impact on smart pricing.

What Is Smart Pricing?

I’m not going to go into what smart pricing is in detail. That’s been covered before, both by myself in my How To Avoid Adsense Smart Pricing On Blogs post, and by better bloggers than me.

The short description is that smart pricing is a penalty applied by Google, resulting in the amount of money you receive when someone clicks an Adsense ad (on your site) being only a fraction of what you would normally receive.

If you want to find out more about smart pricing, the best description I’ve found is Grizzly’s Optimization Tips for Adsense. Read his long article in full for a good understanding, but here’s his quick summary of smart pricing:

If you are running ads on your blog that an advertiser has bid $0.50 per click on and your traffic clicks the ads and doesn’t convert well for the advertiser then Google will not pay you the usual $0.25 per click. They will likely give you $0.01 to $0.05 per click. This means you have been smart priced. This will also mean that you will receive lower payouts on every site you have Adsense on - not just the poorly converting site. This is a penalty because you are not optimizing your Adsense pages in order to give the advertiser the most bang for his or her buck.

So basically, if clicks from your site give advertisers a low conversion rate, you get a huge penalty on what you earn.

But It’s More Complicated Than That

There’s more at play here than what I’ve described above. Admittedly, no-one but Google really knows how it works, but Grizzly knows as much as anyone else and mentions targeted traffic.

Google considers where the traffic comes from and how much value traffic is to the advertiser. Even if the visitor doesn’t buy anything from the advertiser, if it’s targeted traffic, Google considers that you’ve delivered quality traffic to the advertiser. As Grizzly explains:

My best advertiser is looking for people looking to “make money online”. The ad says “Make Easy Money Online”. Most of my traffic - about 75% find my blog searching on Google for the term “make money online” or a long tail version of that term. If one of my visitors clicks on the ad they are most likely looking for what the advertiser has to offer and even if they don’t buy, Google can charge the advertiser full price because the visitor left a “make money online” trail. They found me using the term and they found the advertiser because of the term. That is as targeted as traffic can get and Google can charge the advertiser full price. If all my traffic came from stumble upon and clicked the ads then the advertiser wont get many conversions and Google can see where the traffic originated, knows it isn’t targeted and will penalize me and give the advertiser a rebate.

So you’re more likely to be smart priced if a high percentage of the visitors clicking ads, arrived at your site from a source other than a search engine.

Seth Godin Could Cost You Money

How can you avoid smart pricing? The answer: Try to ensure you’re delivering targeted traffic (ie from search engines) to the advertisers and that a good percentage of that traffic converts for the advertiser.

If your regular readers follow Seth’s advice and click on ads to reward you, you’ll get more clicks, but you won’t be delivering targeted traffic to the advertiser and only a low percentage of people will actually buy anything.

That puts you squarely in smart pricing territory. Thanks Seth!

If you only have one site, the impact may not be so bad: There’s no guarantee you’ll be smart priced and anyway, a lot of low value clicks may equal a few high value clicks.

However, the risk is not worth it, especially if you have other sites running Adsense. If you get smart priced on your blog, you get smart priced on all your sites. That could really cost you.

Final Thoughts

I’ve got nothing against Seth Godin - he’s obviously very well respected - but I think he’s wrong on this occasion. I’m far from an expert in this, but leaving the click fraud argument aside, it seems his advice, aimed at helping bloggers, could actually hurt them if they run Google Adsense ads.

As a publisher, I don’t want my normal visitors to click ads. When people choose to click ads on my site, I want them to be highly targeted search engine visitors, who’ll lead to a higher advertiser conversion rate and won’t get me smart priced.

Oh, if you came to this post from Sphinn or StumbleUpon, or you’re one of my regulars, and you’re wondering why you can’t see Adsense on this blog, well you can’t. Only search engine visitors see Adsense ads on this blog.