There are two parts to having a “self-hosted” blog – a domain name and a website host.

What is a domain name?

According to Wikipedia, “A domain name is an identification string that defines a realm of administrative autonomy, authority, or control in the Internet.” According to us, a domain name is your URL. It’s the www.yourname.com; your website address. It’s the cnn, the yahoo, and the aol to the .com. But it doesn’t have to be just a .com, it can also be a .net, .org, .info, and many other dots.

If you purchase a domain name through a registrar, such as GoDaddy, you can choose your own domain from those available.

Without some sort of website hosting, your domain is just a name.

What is Website Hosting?

Website hosting is where your website “lives.” It is where all of the content, data, and images are stored. You purchase website hosting through a website hosting provider, such as HawkHost or HostGator. If your site is set-up with a web hosting provider, your site is considered “self-hosted.” You have the ability to FTP into your website servers to make changes to code. You also have the ability to access and modify any databases.

What about free platforms like Blogger and WordPress.com?

If you are just starting your blog or are on a limited budget, it is easy to get started with free platforms such as Blogger and WordPress.com. With these free platforms, you are able to select a custom blogspot.com or wordpress.com address, meaning your URL will be yourname.blogspot.com or yourname.wordpress.com. There is no cost to you, since Google and WordPress.com are essentially acting as your free web hosting providers. However you do not have the same accessibility that is available through a paid website hosting provider.

If I can do it for free, why should I pay for a domain name and hosting?

Many bloggers find more legitimacy and flexibility when they have their own domain name and hosting. If you are looking to monetize your blogs, many companies look for unique domain names (without the blogspot.com or wordpress.com.) In addition, some find that free platforms can be limiting in terms of features and functionality – such as limitations in design customization or the ability to use javascripts.

Another thing to consider is content ownership and control. In both cases, you own your own content, however with free platforms, there are additional terms you must follow. According to Google’s Terms of Service for Blogger, you own your content, as a third party licensor, however “Google furthermore reserves the right to refuse to accept, post, display or transmit any Content in its sole discretion.”

Also, “Google may, in its sole discretion, at any time and for any reason, terminate the Service, terminate this Agreement, or suspend or terminate your account. In the event of termination, your account will be disabled and you may not be granted access to your account or any files or other content contained in your account although residual copies of information may remain in our system for some time for back-up purposes.”

I’m on Blogger but I have my own domain name, does that mean I don’t have to worry about Google?

It’s a common misconception that owning your domain name means you “own” your site. Since all of your website content is still hosted and managed by Blogger, Google can still shut down your site.

OK. I’m ready to move, now what?

If you don’t currently own your domain name, you will need to purchase one from a domain name registrar. We use and recommend GoDaddy for domain name registration. Expect to pay $10 for one year of domain name registration.

Next, you will need to purchase website hosting. Popular hosting providers for blogs include HostGator and DreamHost. Creative Patience clients have access to an exclusive blog hosting plan through our parent company, ThreeCell, LLC. (Contact us for additional details.) Hosting plans range from $4/month to $40+/month depending on the hosting plan you select.

Once you have your domain name and host, you can have your blog transferred to your new home. If you are comfortable, you can do the blog transfer yourself. However many prefer to have someone with experience transfer their blogs. Creative Patience offers blog transfer services, as do other developers. Make sure you check out post about “How To Choose a Developer for Your Blogger to WordPress Transfer” to help guide your decision.

Developer Blogger to WordPress transfer services usually include:

• Transfer of posts & pages
• Transfer of comments
• Transfer of any widgets/sidebar items
• Set-up & fixing of permalinks
• Redirecting your domain name or Blogger blog to your new site
• Updating Feedburner

Optional items that typically incur an additional cost include:

• Installation of WordPress on your new server
• Installation or design of themes or templates
• Hosting packages for your site

Once you start looking for someone to do your transfer, you come across many different options. Creative Patience offers blog transfer services starting at $75, with the price scaling with the size of the blog that’s being transferred. However there are other developers that offer transfer services for as little as $30. For someone on a budget, the $30 may seem appealing, but it’s important to consider a few important factors.

1. What is the developer’s background/experience?
Someone who has a background in php, CSS, HTML, etc. will be able to handle any potential glitches or hiccups easier than someone who doesn’t have any coding experience. If the transfer goes perfectly, this may not be an issue. But if you’re looking to integrate similar themes or adjust functionality – this will be critical.

2. Is the developer experienced in transferring blogs of your size?
One blog transfer is not the same as another. Larger blogs with lots of comments, or medium sized blogs that have used a commenting system, or a number of any other potential complications means that each transfer can have its unique set of issues. Just because someone has transferred their own blog, does NOT mean they can transfer yours. Developers with more experience have a few tricks up their sleeve to handle these types of blogs and any potential problems that could come up. There are many developers who will charge you a low price, but do not have the knowledge or the experience, to handle these types of situations. Choosing the “low-priced” option could actually hurt your blog.

For example, we recently worked with a client who was being told that in order to transfer their blog, they would lose a significant portion of their 2000 posts and their 80,000 comments. Other developers recommended deleting older posts, which would mean that blog would lose any Google juice associated with those posts. We worked through the weekend and ultimately, Creative Patience was able to move over 97% of their original content and comments – a far cry from having to delete 2 years worth of posts and comments. This is something that happens quite frequently in the blog transfer world. Don’t let a developer convince you to delete your hard work (ie. your blog content) because they don’t have the skill set to handle your blog transfer.

As another example, we had a blogger who came to us asking for a quote for her very large blog. We provided a quote based on the amount of time it would take to properly transfer a blog of her size and she opted to go with a cheaper option. 10 days later, she was on the boards asking for help because her blog transfer wasn’t going smoothly and she had lost most of her comments.

These are the types of situations that require a developer with more than your average experience – not only to successfully complete the transfer, but also to provide the client with the peace of mind that things will be resolved. Part of a developer’s job is to give the client confidence in their skill and ability, so that if there are any questions or problems, the client will ask them and feel confident that they will get a knowledgeable response. In no situation, should a client be pleading for help online because the developer dropped the ball.

Remember – you get what you pay for.

3. Does the developer offer technical support?
Once a blog is transferred to WordPress, oftentimes the blogger can have questions about how to implement certain things on their blog. Many bloggers like to look around and see what’s under the hood, so-to-speak, which can mean they accidentally “break” their blog. This is something that frequently happens just because the blogger is on a new platform and isn’t related to the actual transfer process. Does the developer offer technical support if you “break” something?

4. Does the developer have happy clients?
Creative Patience believes that our happy clients are our best proof of service. We consistently strive to ensure that our clients are confident and satisfied with the services they’ve received. We strongly suggest that you ask for client referrals from bloggers of similar size to get a true assessment of the experience.

As a company that strives to make the transfer process as smooth and worry-free as possible for the clients, we’d also like to offer these few gentle reminders.

• Many of you make your living off your blog. We make our living by providing our design and web services. We’re happy to help bloggers become familiar with WordPress and do a little bit of hand-holding at the beginning of the process. We love sharing our knowledge and helping others learn. But as a service provider, our time and knowledge is money – please respect that.
• Be aware that after transferring from one blog platform to another, certain SEO best practices should be implemented. This service is typically NOT included in the blog transfer process – which only covers content transfer and initial set-up.
• If something breaks – it might be you. Oftentimes when people learn a new blogging platform, small or large errors can accidentally occur. If something isn’t working, don’t assume it was your developer – especially if everything was working when the project was completed. You can certainly check with your developer to see if a mistake might have been made, but be open to the possibility that while you were “exploring”, you might have deleted a “;” or forgotten to close a tag which could break your blog.

I also have a word for our fellow developers out there.

• We all know how much time a blog transfer can take. The price you set for your transfer determines the price with which you value your time, and I guarantee you, your time is worth more than $10/hour. According to PayScale, a web developer with 1-4 years experience averages ~$20/hour, and that’s on the low side IMO. Your time is money.
• Don’t take the heat for doing something wrong when you’ve actually done everything right. After implementing a transfer, there are times when legitimate errors can occur that are beyond your control. There are some clients who might jump out on the boards and start saying that “The transfer went well, but they broke my site.” Don’t accept blame for something you didn’t do wrong. For example, the comment feed URL for WordPress is different than the comment feed URL for Blogger, which means Google will show crawl errors if it has indexed a comments feed. The only solution is time – time waiting for Google to re-index the entire site which doesn’t happen overnight (even if you’ve submitted a sitemap.) You can’t control it. It can’t be fixed. Don’t take the heat – even if your client tries to convince you that you broke their site.
• Keep it professional. In the mommy blogging world, there are many nice women that you will have the opportunity to work with. But remember, this is still your job, and no matter how nice they seem, things should be handled and dealt with in a professional manner. See the first bullet – your time is money.

This is quite a lot of information, but we’re putting it out there in the hopes that it can help both bloggers and developers work together to create smooth (and happy) blog transfers.

You can see all of the available Google Web Fonts in the Google Fonts Directory. There are over 150 different fonts currently available, ranging from serif to sans serif to scripts.

Once you find the font you like, click on the font and it will take you to a Google web fonts page that gives you a preview of the font, shows you the character set, and a link to download the font (which is great for designers who need to use sample fonts in web layouts.)

Click on the “Use this font” link and the page will show you two bits of code. The first item is a <link> tag that should be inserted inside the <head> tags of your site. For example:

Source code

<head>
...
<link href='http://fonts.googleapis.com/css?family=Rokkitt&v1' rel='stylesheet' type='text/css'>
...
</head>

After you have add the link to the font stylesheet, you need to customize your own stylesheet (usually style.css) to call the new font. Any place you want to use the custom font, you will use “font-family: ‘font name’;” It’s good practice to provide alternate fonts in case there is something wrong with your first font choice, so “font-family: ‘font name’, arial, san-serif;” is a good choice. As an example, if I want the entire site to use the custom font ‘Rokkit’, then I would use the code:

Source code

body {
  font-family: 'Rokkit', arial, sans-serif;
}

Save your stylesheet and you’re done! You’ve just installed a custom font to your blog.

1. The colors you chose make your site hard to read

I think a lot of times, people underestimate color choice. While some colors might look good as an outfit or on your walls, that doesn’t mean that those colors should be used on your blog. The biggest problem we’ve come across is people choosing font colors and background colors that make the site almost impossible to read. Here are a couple of examples:

and

While these colors might be able to work in small doses or for accents, having your entire content with these types of color schemes makes it harder for the reader to view over time. Personally, I think the best color choice for reading is a light background with a dark font.

2. Your blog is set to fit the entire width of the browser window

With the advances in technology, prices of wider screen monitors are decreasing. While there was a time that monitors were 15″, most monitors shipped with new computers are above 19″ wide with a typical screen resolution of 1280×1024 or 1440 x 900 for a widescreen 19″ monitor. Why does this matter? If your blog is set to be the entire width of the browser window, when it is maximized that means the content of your site will go completely across the screen.

A good rule of thumb is to keep your content under 650px for maximum usability. For example, Yahoo news content is ~ 630px, Google search results is under 550px, and CNN articles are under 450px. If your blog goes across 1280, that’s about twice the width of what is recommended. Can you imagine if this post was twice as wide as it is now? Would it be as easy to read? Personally, I find it much harder to keep track of which line I’m on if my eye has to move from the absolute right of the screen at the end of one line to the absolute left of the screen to find the next line.

3. You fail to proof read or spell check your posts

I know that perfectly punctuated posts aren’t always achievable. Many bloggers write several posts a day, and for some time sensitive posts, they need to get them up quickly. This leaves ample opportunity for typos and misspelled words to sneak through. And while one or two errors is understandable, coming across a blog that has multiple spelling errors in each post suggests that they don’t know about WordPress’s built-in spell check.

After you write a post, go ahead and click the spell check button. WordPress will underline all of the words that seem “questionable” and will offer suggestions for any potential errors. Not only will this make your readers happy, but it will make you look professional. Just imagine what you would think if you read a magazine that you’d just purchased only to discover pages filled with typos. You might think that the magazine didn’t care enough or take the time to spell check. Don’t let your blog give people the wrong impression about you.

Before publishing a post, take a moment to preview it in the browser window so you can see what your readers will see. Read it through once or twice to make sure you’ve caught any spelling or grammatical errors. This will also help you catch any instances where you might have written “their” instead of “there” or “they’re” or places where your might have left out a word or two.

4. You steal images and don’t know it

I know how easy it is to download a picture or to link to it from your site. It’s as simple as right-clicking. However it’s important that you are aware that many images are covered by copyright law and using other people’s photos without permission is illegal. Not to mention, showing the link through another person’s URL instead of having a local copy on your server is considered poor web etiquette (aka bandwidth stealing. You are using their server resources to show their image on your blog. Tsk tsk.)

There are three ways to address this issue.

1. Use your own photos! You have full rights and permissions to use photos that you take.
2. Download free stock photos. We are big fans of the Dreamstime free photo archive – there are tons of options to choose from and are completely free to use for your site under their Royalty-Free license.



3. Use photos with permission and include the appropriate credits. CreativeCommons.org is another resource that has a plethora of photos that you can use if you credit the contributors appropriately.

5. Your blog automatically starts playing music or videos

The tricky thing about music is that your taste may not be my taste and vice versa. I often find myself browsing sites late at night and then get a quick jolt when music starts playing. In general, it is frowned upon to have music or videos playing on your site. If you want to include videos or music on your blog, make sure that the default setting is to have the sound off. Give the reader the option to listen to your songs of choice if they want.

These are just a handful of common blog mistakes that we’ve noticed. What are some of the mistakes you’ve noticed?

Before using Contact Form 7, we need to install the plugin to the blog. If you aren’t familiar with the process, from your WordPress admin panel, click on Plugins > Add New. Type “Contact Form 7″ in the search box and click the “Search Plugins” button. Contact Form 7 by Takayuki Miyoshi should be the first result. Click the “Install Now” link and then “Activate Plugin.”

Once the plugin is installed, there is a new “Contact” menu option on your WordPress Admin panel.

By default, there is already a contact form ready for you to use. The pre-made form includes a place for name, email, subject, and message. Here’s a shot of the code in the pre-made form and what the resulting form would look like.

Each item in the form passes its content to the the mail generation form. You can see below where each field from the form above (ex: your-name and your-subject) is entered into the mail template. If you do not include the variables in your mail template, you won’t receive the information the person enters in your emails.

If you want to modify the form, you can do by deleting items from the form or by adding new elements using the “Generate Tag” dropdown menu. For example, we strongly recommend including a CAPTCHA field on all forms. This helps prevent spammers from being able to bombard your email box with spam via your contact form.

To add a CAPTCHA field, the Really Simple CAPTCHA plugin must be installed. You can you the same installation steps we mentioned above to install it. Next, we’ll select CAPTCHA from the “Generate Tag” drop down. A window will appear with several CAPTCHA options. Most of these options are optional and are settings for the CAPTCHA image and your input fields; you can leave these blank. The code that we’re interested is the short code highlighted in brown.

To add the CAPTCHA field to our form, we need to copy the short code highlighted into our form. To keep our formatting consistent, we’ll wrap our code with <p> tags. Hit the “Save” button at the top of your form, and this is what you should have:

If you want to have multiple contact forms on your site, you can create a new contact form by clicking the “Add new” button. After you select your language, you will have a new basic form that you can modify.

To install your contact form onto the page, simply copy and paste the provided short code (you’ll see it underneath the title of the form) onto the post or page you would like the form to be displayed.

Most blog buttons are 125×125 pixels in size and have the name of the blog with consistent design branding. You can make a blog button yourself using Adobe Photoshop or a similar program. This tutorial picks up after you have your blog button designed and you now want to install the button and the scroll box that contains the sharing code.

Step 1  for Blogger:

Upload your blog button to a photo sharing site, such as Photobucket. After your blog button has loaded, copy the Direct link to your image and save it in a place you can reference (such as opening a new Notepad.)

Step 1 for WordPress:

Upload your blog button to your Media Library by going to Media > Add New. After uploading the file, copy the File URL and save it in a place you can reference. Make sure you save the image after you have uploaded it.

Step 2 for both Blogger and WordPress:

For Blogger, add a new HTML/Javascript Gadget to the section you would like your blog button. To find you Gadgets, click on Dashboard > Design > Page Elements. Click on the “Add a Gadget” link for the section you would like to add the blog button to.

For WordPress, add a new Text Widget. To find your Widgets, click on Appearance > Widgets from your Admin menu, then drag the “Text” box into the sidebar where you would like to place the blog button.

Use the following code for a horizontal layout (one where the image is to the left and the code is to the right):

Source code

<center>
<a href="http://yourURL.com/"><img  style="border: 1px solid #474747;
margin-right: 5px; vertical-align: top;" border="0"
src="http://imageurl.com/image.jpg"/></a> <textarea rows="7" cols="12" >
<a href="http://yourURL.com/" target="_blank"><img
style="border: 1px solid #474747;" border="0" width="125"
alt="Your Website Name" src="http://imageurl.com/image.jpg" height="125"/>
</a></textarea>
</center>

Make sure your replace the following information with your links:
yourURL.com = the link to your website
imageurl.com/image.jpg = the link to your blog button image (which you copied and saved from Photobucket or the Media Library)
“Your WebsiteName” = the name of your website

Here is an example of how this code appears:

<a target=”_blank” href=”http://cre8ivepatience.blogspot.com/” _mce_href=”http://www.creativepatience.com/”><img style=”border: 1px solid #474747;” _mce_style=”border: 1px solid #474747;” border=”0″ width=”125″ alt=”Creative Patience, LLC” src=”http://www.creativepatience.com/blog/wp-content/uploads/2011/04/125button.jpg” _mce_src=”http://i1198.photobucket.com/albums/aa457/cpatience/blog-button.jpg” height=”125″/></a>

Use th following code for a vertical layout:

Source code

<center>
<a href="http://yourURL.com/"><img  style="border: 1px solid #474747;"
border="0" src="http://imageurl.com/image.jpg"/></a><br /><br />
<textarea rows="7" cols="12" ><a href="http://yourURL.com/" target="_blank">
<img style="border: 1px solid #474747;" border="0" width="125"
alt="Your Website Name" src="http://imageurl.com/image.jpg" height="125"/>
</a></textarea>
</center>

Here is how the vertical code appears:

<a href=”http://www.creativepatience.com/” target=”_blank”><img style=”border: 1px solid #474747;” _mce_style=”border: 1px solid #474747;” border=”0″ width=”125″ alt=”Creative Patience, LLC” src=”http://i1198.photobucket.com/albums/aa457/cpatience/blog-button.jpg” _mce_src=”http://www.creativepatience.com/blog/wp-content/uploads/2011/04/125button.jpg” height=”125″/></a>

Within both codes, there are a couple of things you can do to adjust the scroll box. Notice, in the area that says <textarea rows=”7″ cols=”12″….>. By increasing the number of rows, you will adjust the height of the scroll box. By increasing the number of cols (columns) you will adjust the width of the scroll box.

After updating the code and adjusting the size, make sure you save your gadget or widget, and you’re done! You’ve just added a blog button and sharing code to your Blogger or WordPress blog.

First, you will need to enable the post thumbnail functionality for your theme by pasting the following into your functions.php file:

Source code

// add post-thumbnails support
add_theme_support('post-thumbnails');

Once enabled, you can insert the thumbnail into the loop of your WordPress theme by calling

Source code

<?php the_post_thumbnail(); ?>

The trick is, that when you set your featured image, it may not be exactly the thumbnail size that you would like. There are a couple of ways to control your thumbnail size. First, you can go Settings > Media and manually set the thumbnail size:

The other option is to add another line to your functions.php file:

Source code

// add post-thumbnails support
add_theme_support('post-thumbnails');
set_post_thumbnail_size(100, 100, true);

where the variables are (width, height, crop? (true/false)).

In our case, we were updating an old theme that used custom fields to call our thumbnail images. We wanted to switch to the new the_post_thumbnail() call simply because it makes it much easier to insert thumbnail images. However, when updating the theme, we did not want to have to go back and update every single thumbnail image that was inserted using the custom field.

All we had to do was add an extra conditional statement into our loop to first check to see if there was a post-thumbnail, and if not, check to see if there was a custom field thumbnail. Our code is below:

Source code

<?php if ( has_post_thumbnail() ) : ?>
    <div class="thumbnail"><?php the_post_thumbnail('thumbnail'); ?></div>
 <?php  elseif( get_post_meta($post->ID, "thumbnail", true) ): ?>
    <div class="thumbnail">
        <img src="<?php echo get_post_meta($post->ID, "thumbnail", true); ?>" width="100" height="100" alt="<?php the_title(); ?>" /></div>
 <?php  else: ?>
<?php endif; ?>

This is just a basic introduction on how to get started. There are other posts that go into more detail and complexity on the things you can do with the_post_thumbnail().

First, we’ll register the menus in the functions.php file. In this example, we are creating three customizable menus – one for pages, on for categories, and one for the footer.

Source code

add_action( 'init', 'register_my_menus' );
function register_my_menus() {
	register_nav_menus(
		array(
			'page-menu' => __( 'Page Menu' ),
			'category-menu' => __( 'Category Menu' ),
			'footer-menu' => __( 'Site Links Menu' ),
		)
	);
}

Next, we call our custom menus within our theme with the following:

Source code

<?php wp_nav_menu( array('theme_location' => 'category-menu', 'menu_class' => 'category_item', 'container_class' => 'category_menu')); ?>

Let’s take a moment to break this down. In this code, I’m calling my new “category-menu”. I would like this menu to have the class of “category_item” and for it to reside within a div class of “category_menu.”

For more wp_nav_menu parameters, you can visit the WordPress Codex.

Once you have the menus set-up in your theme, you can go ahead and style the menus in your .css file.

Then, we’ll need to set-up the menus from the WordPress Admin panel. Once logged in, you can find the menus under Appearance -> Menus.

What we need to do now is actually create the Menus. We do this by typing in the name of the menu we are creating in the “Menu Name” box and hitting the Save Menu button. To add more menus, click on the + tab.

If you like, you can also add the items you would like in those menus at the same time. New menu items can be created manually using the Custom Links box, or you can check off pages or category tags that you would like to add to the menu. Remember that you’ll need to click “Save Menu” after you’ve added all of your menu items.

After creating your first menu, you’ll see a “Theme Locations” box appear in the top left corner. Once all of your menus are created, simply select which menu goes into which theme location using the dropdown menus and hit save.

And that’s it! Your new menus are set-up and are much more flexible and customizable.

In general, there are a couple of different ways for websites to track your visits – one is through extrapolating data based on web patterns they collect and analyze. Another is by directly measuring hits to your site.

Let’s look at the first scenario first. There are two major stat provider/analysis companies that utilize the collect & analyze approach – Compete and Alexa.

Compete.com says:

Compete’s clickstream data are collected from a 2,000,000 member panel of US Internet users (about a 1% sample), using diverse sources.

Alexa says:

Alexa computes traffic rankings by analyzing the Web usage of millions of Alexa Toolbar users and data obtained from other, diverse traffic data sources.

The way these two sites work is that they have a specific number of users who install a toolbar (or some other type of software) on their computer. The sites then use the toolbars to analyze the web traffic patterns of those users. Using that data, they extrapolate numbers to apply to the entire web user world. Here’s another way to look at it. Nielson ratings for TV shows are obtained by having a specific number of households having their TV watching patterns recorded. Nielson then applies those numbers and formulates the total number of people who watched a show, based on that sample group.

My general feeling is that while these sites might provide interesting demographic information or even comparison information, they will be far less accurate than traffic recorded directly from your website.

Next, let’s look at statistics providers that measure hits to your site directly. This is usually achieved by having you install a script into your web template. A couple of stat trackers that I use that fall in this category are StatCounter and Google Analytics. But even between those two, the stats delivered vary. Here’s a chart that shows a sample of Google Analytics numbers vs. StatCounter numbers.

StatCounter says:

When a visitor visits your webpage with the installed HTML and Javascript code, their anonymous details are sent to StatCounter to be recorded. Their details are gathered either from the counter the visitor loads from StatCounter, or an invisible image depending on your settings.

Google Analytics says:

Google Analytics uses a first-party cookie and JavaScript code to collect information about visitors and to track your advertising campaign data.

The next question is – if both StatCounter and Google Analytics measure traffic to the site directly – why are the numbers different? Here are some reasons that might explain the discrepancy:

1. Google Analytics only tracks visitors who have javascript enabled browsers while StatCounter can track visitors regardless of whether the browsers are javascript enabled or javascript disabled. This alone would suggest that StatCounter will report more visits than Google Analytics.
2. If a visitor returns to your site within 30 minutes of their last activity on the site, Google will count it as a new page view – not a new visit. StatCounter allows you to manually establish the idle time between visits. By default it is set to 30 minutes but can be changed to anything from 30 minutes to 1 week. So if the idle time between visits is set to 2 hours on StatCounter, and a visitor returns after 2 hours, StatCounter would count it as a page view while Google Analytics would count it as a new visitor. The difference can be addressed by switching the configuration in StatCounter to 30 minutes as well.
3. BOTS! Google Analytics will not track visits from bots. StatCounter probably does count visit from bots.

What about AWstats you ask? While it’s appealing to have a stat tracker that measures direct server hits, my AWStats gives numbers that are much, MUCH higher than either Google Analytics or StatCounter. This is probably because AWstats will track server calls from bots and search engine crawlers, which will have a big impact on your numbers. (For example, AWstats reported almost 3 times more visits and 8 times more page views than Google Analytics for the month charted above.) I don’t believe that AWstats is as viable a tool for collection of web marketing data. (And it’s not anywhere near as user-friendly as Google Analytics or StatCounter.)

So which is more accurate? The answer is probably both. I suspect that StatCounter overcounts and Google Analytics undercounts and averaging the two might get you very close to the actual number. But unless you want to go through your actual server logs (which I honestly don’t want to do) there’s no way to know for certain. Both stat providers have pros and cons which we can go into in another post. But at the very least this should help explain why your numbers are different.

1. Create a copy of your current single.php file and name the new copy something like single_original.php.
2. Create a new file for your custom single post display template – such as single_custom.php. Code and style that template however you wish.
While we use single_custom.php in this example, I recommend you use a naming convention that makes the templates easily identifiable. So a custom template for recipe posts could be called single_recipes.php.
3. Look-up the Category ID for the category that you want to have the customized post templates for. The easiest way I’ve found to do this is to go to your Categories admin page, then just hover over the category name you want. The preview link in most browsers will tell you what the ID number is.

So at this point you should have three files: single.php (your original file), single_original.php (the copy of your original file) and single_custom.php (your new custom single post template.)

Next, open up single.php and paste the following code:

<?php
   $post = $wp_query->post;
    if ( in_category('ID#') ) {
       include(TEMPLATEPATH . '/single_custom.php');
    }
    else {
       include(TEMPLATEPATH . '/single_original.php');
    }
?>

Where ID# = the ID number of the category you want custom post templates for.

This is basically saying: “Every time I try to access a post, check to see if it is in Category ID X. If it is, then use my custom single post template. Otherwise use my original single post template.”

If you want to have custom post templates for multiple categories, then simply create the additional custom single templates and then modify the ifelse code in single.php to something like:

<?php
   $post = $wp_query->post;
    if ( in_category('ID#') ) {
       include(TEMPLATEPATH . '/single_custom.php');
    }
    elseif ( in_category('ID#2') ) {
       include(TEMPLATEPATH . '/single_custom2.php');
    }
    elseif ( in_category('ID#3') ) {
       include(TEMPLATEPATH . '/single_custom3.php');
    }
    else {
    include(TEMPLATEPATH . '/single_original.php');
    }
?>