I first installed the Limit Login Attempts plugin some time ago but after forgetting my password a couple of times I disabled it. You see, with so many blogs I don’t always update all of the passwords at the same time. So, by inserting an incorrect password one too many times, I would end up locking myself out of my own blog. Not fun!

Change of Heart

I recently decided to reinstall the Limit Login Attempts plugin. After looking at my traffic logs. I found quite a few IP addresses accessing my WordPress Login screen. It doesn’t take a rocket scientist to figure out why someone besides me is spending time on my Login screen.

By installing the Limit Login Attempts plugin, I’m able to add a layer of protection between would-be hackers and my blogs. The plugin allows me to set the number of login tries before being locked out. I can also configure it to notify me after a pre-set number of lockouts. Some blogs I set the number to 1 and other blogs to 2.

Several Tier Lockout

After a lockout, the hacker, er I have 60 minutes or so before I can try again. I’ve actually increased the lockout time to about 6 hours. After that, if anyone gets locked out again, the lockout time is increased to several days. In the meanwhile the plugin logs the IP address and the username used when attempting to login.

Oh, and to get around being locked out because I forgot the password, I created a second login username and password that is impossible for me to forget. Therefore, if I happen to lock myself out using username #1, I can always use username #2 to gain administrative access and reset the lockout.

Security Layer Number 2

Because my blogs are hosted on HostGator, HostGator provides a feature in their control panel called IP Deny Manager. By adding the questionable IPs to IP Deny’s list, those IPs are denied access to all of my HostGator sites. So, at the end of the day when I receive all of my “too many login attempts” notifications, I gather the IP addresses, log into my HostGator account and add the IPs to the list so those particular hackers won’t be able to access my sites again.

This is not foolproof because if someone truly wants to hack in, they will, but I can’t just sit idly by and watch them gain access to my sites.

A Little Advice

After installing a new blog, always change the username from the default “admin” to something a little less predictable. Each hacking attempt tried using “admin, Admin or webmaster” as the user name.

Maintaining a blog is sort of like gardening. No matter how much you care for your garden, weeds are always ready to take over. You have to weed out the online hackers just as you have to pull weeds from your garden.

Knowing that I can’t control Google, I continued on doing what I do, playing around behind the scenes and writing occasionally.

An Enlightening Email from Google

Imagine my surprise when I received an email from Google notifying me of “Failed Ad Crawls.” In essence their AdSense ad crawler was having a hard time crawling my sites because of my robots.txt file.

If the AdSense crawler is unable to crawl my site, Google is unable to display the most relevant ads to compliment my site’s content. This is most probably what lead to my decrease in earnings (although things were just fine a week or so ago so I’m not sure why the sudden change).

Amending the Robots.txt File

Way back when I first started playing online I was aware of a file called robots.txt file. I think I might have played around with it back then, but after switching to WordPress, I forgot all about it. Apparently WordPress installs a default robot.txt file and that’s what I had on each of my blogs.

My robots.txt file for most of my sites looked like this:

User-agent: *
 Disallow: /cgi-bin/
 Disallow: /wp-admin/

I have a few sites where the robots.txt was even more sparse and looked like this:

User-agent: *
 Disallow:

The sparse robots.txt file belongs to non-money making sites so I’m not so concerned.

Anyway, Google recommended that I add the following code to the top of my robots.txt file to allow the AdSense crawler in:

User-agent: Mediapartners-Google
 Disallow:

After doing a little research, I went a little further and modified my robots.txt file to look like this:

User-agent: Mediapartners-Google
 Disallow:

# Google Image
 User-agent: Googlebot-Image
 Disallow:

# global
 User-agent: *
 Disallow: /cgi-bin/
 Disallow: /wp-admin/
 Disallow: /wp-includes/
 Disallow: /wp-content/plugins/
 Disallow: /wp-content/cache/
 Disallow: /wp-content/themes/
 Disallow: /trackback/
 Disallow: /feed/
 Disallow: /comments/

Sitemap: http://www.insertsitemapurlhere.com/sitemap.xml

I don’t totally understand all of the robots.txt file stuff, but it gives me something else to research. In the meanwhile, I’ve made the changes and have noticed an increase in earnings.

A Little More Robots.txt Info

The robots.txt file is usually located in a domain’s root directory. So, if you type in the domain name followed by /robots.txt you can read anyone’s robots.txt file. Mine is here, eHow’s is here, Suite 101’s is here and CNN’s is here. There’s no secret, but you can see how each of them differ.

Over the next few days I’ll play around with my robots.txt file to see which brings in the best return. I’ll be reviewing the robots.txt files of successful sites to see how theirs read.

Golf and Online Writing

My husband always says that golf is a game of inches. I feel online writing is the same. It’s not actually inches, but a game of tweaking. If tweaking my robots.txt file will make a difference to my financial bottom line, call me a tweaker.

This neat plugin is especially helpful if you have old blogs with lots of posts. Finding all broken links on old blogs is just about impossible. Broken Link Checker continually checks for broken links and sends notification emails when broken links are found.

After testing the plugin on one of my smaller blogs, I installed it here on NJFM. The plugin found over 200 broken links on this site. When you consider that I’ve only got a little over 500 posts, 200 is a rather high percentage of broken links.

Waning Interest

As I was fixing the links I realized most of the links came from NJFM’s comment section. It made me realize that I’m not the only one who loses interest after building blogs.

The majority of the broken links were from folks who created a new blog, came here to No Job for Mom and got very involved in the community. Over time they lost interest and allowed their blog’s domain name to expire thus resulting in broken links (this is not a complaint, just an observation).

The People Factor

I think cleaning up broken links improves the reader’s experience. I know I’ve read quality and compelling comments on other blogs only to be later disappointed when I clicked on the commenter’s website link to find that it was a dead end.

SEO Factor

I am not an SEO expert but I would think search engines appreciate blogs with current links as opposed to blogs with a ton of broken links. Whether or not fixing broken links improve search engine results remains to be seen, but it can’t hurt.

Broken Link Checker has earned its way onto my favorite WordPress plugins list.

When converting a site from Joomla to WordPress (or changing platforms), do not change the category structure or the file naming convention. In other words, don’t do what I did.

Old School

When the site was hand coded, there was only one way to access any page on the site. All a reader had to do was type in the static URL and boom…there was the page! With content management systems such as Joomla and WordPress (yes, I call WordPress a content management system), it’s different.

It wasn’t until after I received over 600 “File not found” errors (started at 90 a day and has now trickled to only 10 or 15 a day) that I had a V-8 moment.

My old school thought process of accessing each page via one URL was outdated. With content management systems, pages can be accessed in a variety of ways. I won’t get into the whole relational database structure reasoning for why that is, but take my word for it.

Changing with the Times

In the past when I changed platforms all I had to do was insert a “change of address” line from the old webpage to the new. Now, with at least 10 ways to access any one page from my old Joomla site, the redirects seem endless. You see, something as simple as including or excluding the forward slash (/) at the end of a URL can generate a “File not found” error if things aren’t redirected correctly.

So, this Redirect Queen has been putting out redirect fires as they happen. I was pleased yesterday when I only received 11 crawl errors.

How do I Find the Errors?

There are two ways to track errors. The easy and not so thorough way is by checking my Statcounter stats. When I see “Page not found” in the log, I know I need to address the problem.

The other more complete way is by signing into my Google Webmaster account. There they list all of the errors Google encounters when the bots crawl my site. Some of the errors are because of redirects but some of the errors are a result of incorrect link backs. I see some of the sites linking to Tidbits were incorrectly coded.

Additionally, I’ve found that Joomla created a few pages that made absolutely no sense to me, but I’ve redirected them anyway.

When will it End?

The way I calculate it, I fully expect to be resolving redirects for a couple of months. Fortunately, each day there are fewer and fewer redirects and I’ve got it down to a science. I can now complete my daily redirect duty before I finish my first cup of coffee.

BTW, if you find yourself with the same problem (hopefully you won’t), there’s a plugin that helps to make the redirection process a little easier. The plugin is appropriately called Redirection .

Ya gotta love this stuff or else you wouldn’t do it.

From time to time I experiment with different plugins to enhance my blog’s functionality (functionality…such a tech writing word).  Anyway, I use a plugin that is supposed to help detect hack attacks.

After having a couple of my blogs hacked some time ago, I’m a bit sensitive to hacking.

The plugin I use is called WordPress Firewall 2.  Recently I had been receiving notification emails initiated by the plugin telling me a certain IP address was attempting to insert malicious code into my site by attacking a certain file.  After receiving 20 such notification emails in a short period of time, I decided to take action.

A Little Research

I looked up the IP address and it seemed to be a Google bot.  Not being 100% sure that it was, I did a little research.  My research left me on the fence.  It could in fact be a Google bot or it could be a hacker redirecting an IP address to make it look like a Google bot.

After being online for several years and never having this happen before, I decided to err on the side of caution and ban the particular IP address.  I did so by modifying my .htaccess file and inserting the following code:

order allow,deny
deny from XX.XXX.X.XX  (x represents actual IP address)
allow from all


Sit Back to See What Happens

The world didn’t come crashing down after inserting the code and the annoying emails stopped.  Whew, dodged a bullet.

Several days later (about 3), I noticed the traffic for that particular blog dropped significantly.  Hmmm, what’s going on?  So, I searched for my site in Google and found it. The site was there in a great position on page one of the search results but beneath the site’s URL were the words “You are banned.”

Yup, I dodged the bullet when I should have employed fancy footwork.  Instead of getting shot in the upper body, I shot myself in the foot.  The IP address was actually a Google bot.  So, I immediately removed the code from the .htaccess file and temporarily deactivated the plugin. Fortunately, the “banned” statement was removed within seconds and the traffic returned.

Better Safe than Sorry

When I originally received the email notifications, my first line of action was to contact Google to see if it was really their bot.  The problem with contacting Google is contacting Google.  It’s not easy finding the right department, email address or even forum thread in which to post a query.  Instead I took matters into my own hands.

Bottom line, I lost about half a day’s worth of income, but I’d rather that than have lost several weeks or months worth by fighting hackers.  Another online lesson learned.