Here are 20 of the best SEO plugins to help you choose the right tags, tell search robots what to work on, optimize your post titles and more.

All in One SEO Pack – One of the most popular plugins ever for WordPress, this plugin does a bit of everything for you from helping choose the best post title and keywords, to helping you avoid duplicate content and more.

Automatic SEO Links – Automatic SEO Links allows you to choose a word or phrase for automatic linking, both internal and external, set anchor text, choose if it should be “nofollow” or not, and more. One of the best features of this plugin is that it will only do this for the first occurrence of a word in a post so you don’t have to worry about spamming your post with numerous links to the same thing.

Google XML Sitemaps – An essential tool in any blogger’s armory of SEO tools. While the name only mentions “Google,” this plugin creates an XML-sitemap that can be read by Ask, MSN and Yahoo also.

HeadSpace2 – This plugin allows you to install all sorts of meta-data, add specific JavaScript and CSS to pages, suggests tags for your posts and a whole lot more.

Meta Robots WordPress plugin – An easy solution for adding robot metadata to any page you choose on your blog. You can use it to make your front page links into “nofollows,” prevent indexing of search pages, disable author and date-based archives, prevent indexing of your login page and numerous other features.

Nofollow Case by Case – This plugin allows you to strip the “nofollow” command from your comments, and then you can apply it to only the comments you don’t wish to support.

Platinum SEO Plugin – The Platinum SEO Plugin offers you such features as automatic 301 redirects for permalink changes, auto-generation of META tags, post slug optimization, help in avoiding duplicate content and a host of other features.

Redirection – For any number of reasons you sometimes need to move a page from one spot on your blog to another, but then you risk losing that page’s status in search results. Redirection helps you with your 301 redirects, captures a log of 404s so you can work on correcting them, sets up an RSS feed for errors and more.

SEO Blogroll – Do you worry that the people you link to in your blogroll are feeding off of your PageRank? With SEO Blogroll you can make separate sections for various groupings of links, with an unlimited number in each, and all of them will receive the “nofollow” attribute.

SEO for Paged Comments – With the introduction of paged comments in WordPress 2.7, there was a potential problem with search engines thinking you had duplicate content as the post would appear on each page. This plugin aims to take care of this issue for you until the folks at WordPress change things up.

SEO friendly and HTML valid subheadings – Some themes for WordPress will confuse your sub-header tags based on the page they are to be displayed on, but this plugin will automatically reset them to make them more SEO friendly by moving them down one spot in the hierarchical tree. In other words, h2 becomes h3, h3 becomes h4 and so on.

SEO Friendly Images – Images can be a great source of traffic as people search for images of various subjects, and this plugin helps you with making sure that you have “alt” and “title” tags on all of your images so that the search engines can properly index them.

SEO No Duplicate WordPress Plugin – If you must have duplicate content on your site for whatever reason, SEO No Duplicate will allow you to state which version of the post search engines should index while ignoring the others.

SEO Post Link – The post slug is the blog title you see in a browser’s URL bar, and if it’s too long, search engines won’t take a liking to it. SEO Post Link comes with an already populated list of words to cut from a title when it turns into a URL to make your post addresses that much friendlier. You can set it so that it’s limited to a certain number of characters, cut short words, cut unnecessary words and more.

SEO Smart Links – Interlinking your blog can be the key to getting more people to read more of your posts, but it is time consuming and tedious to do it by hand. SEO Smart Links does this for you automatically when you tell it what words to link to what URLs, and it also allows you to set “nofollow” and “open in window” comands for the links.

SEO Tag Cloud Widget – Love ‘em or hate ‘em, a lot of people use tag clouds on their blogs. Since their inception they have been fairly unreadable by search engines, but with this plugin they will be converted to an SEO-friendly HTML markup that can be indexed.

SEO Title Tag – Your tags are an important part of your site for making sure that search engines know where to place your posts, and SEO Title Tag focuses exclusively on this. Unlike some other plugins, and WordPress itself, this extension will allow you to add tags to your pages, your main page and even any URL anywhere on your site.

Simple Tags – An extremely popular plugin that focuses on helping you choose the best tags for your posts by offering suggestions, auto-completion of tags as you type, an AJAX admin interface, mass tag editing and a whole lot more.

Sitemap Generator – This is a more customizable sitemap generator than most with options to support multi-level categories and pages, category/page exclusion, permalink support, choices on what to display, options to show number of comments and more.

TGFI.net SEO WordPress Plugin – This particular plugin will do most of the usual SEO work of optimizing titles and keywords, but it adds a unique twist as it is mainly directed at people who use WordPress as a CMS.

Plugins are a major part of why WordPress powers millions of blogs and websites around the world. The ability to extend WordPress to meet just about any need is a powerful motivator for choosing WordPress over other alternatives. Having written several plugins myself, I’ve come to learn many (but certainly not all) of the ins-and-outs of WordPress plugin development, and this article is a culmination of the things I think every WordPress plugin developer should know. Oh, and keep in mind everything you see here is compatible with WordPress 3.0+.

Don’t Develop Without Debugging

The first thing you should do when developing a WordPress plugin is to enable debugging, and I suggest leaving it on the entire time you’re writing plugin code. When things go wrong, WordPress raises warnings and error messages, but if you can’t see them then they might as well have not been raised at all.

Enabling debugging also turns on WordPress notices, which is important because that’s how you’ll know if you’re using any deprecated functions. Deprecated functions may be removed from future versions of WordPress, and just about every WordPress release contains functions slated to die at a later date. If you see that you are using a deprecated function, it’s best to find its replacement and use that instead.

How to Enable Debugging

By default, WordPress debugging is turned off, so to enable it, open wp-config.php (tip: make a backup copy of this file that you can revert to later if needed) in the root of your WordPress installation and look for this line:

// Tells WordPress to log everything to the /wp-content/debug.log file

05

define('WP_DEBUG_LOG', true);

06

07

// Doesn't force the PHP 'display_errors' variable to be on

08

define('WP_DEBUG_DISPLAY', false);

09

10

// Hides errors from being displayed on-screen

11

@ini_set('display_errors', 0);

With those lines added to your wp-config.php file, debugging is fully enabled. Here’s an example of a notice that got logged to /wp-content/debug.log for using a deprecated function:

[15-Feb-2011 20:09:14] PHP Notice: get_usermeta is deprecated since version 3.0! Use get_user_meta() instead. in C:\Code\Plugins\wordpress\wp-includes\functions.php on line 3237

With debugging enabled, keep a close eye on /wp-content/debug.log as you develop your plugin. Doing so will save you, your users, and other plugin developers a lot of headaches.

How to Log Your Own Debug Statements

So what about logging your own debug statements? Well, the simplest way is to use echo and see the message on the page. It’s the quick-and-dirty-hack way to debug, but everyone has done it one time or another. A better way would be to create a function that does this for you, and then you can see all of your own debug statements in the debug.log file with everything else.

Here’s a function you can use; notice that it only logs the message if WP_DEBUG is enabled:

Use the BlackBox Debug Bar Plugin

I only recently discovered this plugin, but it’s already been a huge help as I work on my own plugins. The BlackBox plugin adds a thin black bar to the top of any WordPress post or page, and provides quick access to errors, global variables, profile data, and SQL queries.

Clicking on the Globals tab in the bar shows all of the global variables and their values that were part of the request, essentially everything in the $_GET, $_POST, $_COOKIE, $_SESSION, and $_SERVER variables:

The next tab is the Profiler, which displays the time that passed since the profiler was started and the total memory WordPress was using when the checkpoint was reached:

You can add your own checkpoints to the Profiler by putting this line of code anywhere in your plugin where you want to capture a measurement:

Perhaps the most valuable tab in the BlackBox plugin is the SQL tab, which shows you all of the database queries that executed as part of the request. Very useful for determining long-running database calls:

And finally we have the Errors tab, which lists all of the notices, warnings, and errors that occurred during the request:

By providing quick access to essential debug information, the BlackBox plugin is a big-timer when it comes to debugging your WordPress plugin.

Prefix Your Functions

One of the first things that bit me when I started developing WordPress plugins was finding out that other plugin developers sometimes use the same names for functions that I use. For example, function names like copy_file(), save_data(), and database_table_exists() have a decent chance of being used by other plugins in addition to yours.

The reason for this is because when WordPress activates a plugin, PHP loads the functions from the plugin into the WordPress execution space, where all functions from all plugins live together. There is no separation or isolation of functions for each plugin, which means that each function must be uniquely named.

Fortunately, there is an easy way around this, and it’s to name all of your plugin functions with a prefix. For example, the common functions I mentioned previously might now look like this:

There is one caveat to this, however. If you use PHP classes that contain your functions (which in many cases is a good idea), you don’t really have to worry about clashing with functions defined elsewhere. For example, let’s say you have a class in your plugin named “CommonFunctions” with a copy_file() function, and another plugin has the same copy_file() function defined, but not in a class. Invoking the two functions would look similar to this:

By using classes, the need to explicitly prefix your functions goes away. Just keep in mind that WordPress will raise an error if you use a function name that’s already taken, so keep an eye on the debug.log file to know if you’re in the clear or not.

Global Paths Are Handy

Writing the PHP code to make your plugin work is one thing, but if you want to make it look and feel good at the same time, you’ll need to include some images, CSS, and perhaps a little JavaScript as well (maybe in the form of a jQuery plugin). And in typical fashion, you’ll most likely organize these files into their own folders, such as “images”, “css”, and “js”.

That’s all well and good, but how should you code your plugin so that it can always find those files, no matter what domain the plugin is running under? The best way that I’ve found is to create your own global paths that can be used anywhere in your plugin code.

For example, I always create four global variables for my plugins, one each for the following:

Store the Plugin Version for Upgrades

When it comes to WordPress plugins, one of the things you’ll have to deal with sooner or later is upgrades. For instance, let’s say the first version of your plugin required one database table, but the next version requires another table. How do you know if you should run the code that creates the second database table?

I suggest storing the plugin version in the WordPress database so that you can read it later to decide certain upgrade actions your plugin should take. To do this, you’ll need to create a couple more global variables and invoke the add_option() function:

I certainly could have simply called add_option('myplugin_version', '1.0.0'); without the need for the global variables, but like the global path variables, I’ve found these just as handy for using in other parts of a plugin, such as a Dashboard or About page.

Also note that update_option() could have been used instead of add_option(). The difference is that add_option() does nothing if the option already exists, whereas update_option() checks to see if the option already exists, and if it doesn’t, it will add the option to the database using add_option(); otherwise, it updates the option with the value provided.

Then, when it comes time to check whether or not to perform upgrade actions, your plugin will end up with code that looks similar to this:

Use dbDelta() to Create/Update Database Tables

If your plugin requires its own database tables, you will inevitably need to modify those tables in future versions of your plugin. This can get a bit tricky to manage if you’re not careful, but WordPress helps alleviate this problem by providing the dbDelta() function.

A useful feature of the dbDelta() function is that it can be used for both creating and updating tables, but according to the WordPress codex page “Creating Tables with Plugins”, it’s a little picky:

You have to put each field on its own line in your SQL statement.

You have to have two spaces between the words PRIMARY KEY and the definition of your primary key.

You must use the keyword KEY rather than its synonym INDEX and you must include at least one KEY.

Knowing these rules, we can use the function below to create a table that contains an ID, a name, and an email:

Important: The dbDelta() function is found in wp-admin/includes/upgrade.php, but it has to be included manually because it’s not loaded by default.

So now we have a table, but in the next version we need to expand the size of the name column from 100 to 250. Fortunately dbDelta() makes this straightforward, and using our upgrade logic previously, the next version of the plugin will have code similar to this:

While there are other ways to create and update database tables for your WordPress plugin, it’s hard to ignore the flexibility of the dbDelta() function.

Know the Difference Between include, include_once, require, and require_once

There will come a time during the development of your plugin where you will want to put code into other files so that maintaining your plugin is a bit easier. For instance, a common practice is to create a functions.php file that contains all of the shared functions that all of the files in your plugin can use.

Let’s say your main plugin file is named myplugin.php and you want to include the functions.php file. You can use any of these lines of code to do it:

But which should you use? It mostly depends on your expected outcome of the file not being there.

include: Includes and evaluates the specified file, throwing a warning if the file can’t be found.

include_once: Same as include, but if the file has already been included it will not be included again.

require: Includes and evaluates the specified file (same as include), but instead of a warning, throws a fatal error if the file can’t be found.

require_once: Same as require, but if the file has already been included it will not be included again.

My experience has been to always use include_once because a) how I structure and use my files usually requires them to be included once and only once, and b) if a required file can’t be found I don’t expect parts of the plugin to work, but it doesn’t need to break anything else either.

Your expectations may vary from mine, but it’s important to know the subtle differences between the four ways of including files.

Use bloginfo(‘wpurl’) Instead of bloginfo(‘url’)

By and large, WordPress is installed in the root folder of a website; it’s standard operating procedure. However, every now and then you’ll come across websites that install WordPress into a separate subdirectory under the root. Seems innocent enough, but the location of WordPress is critically important.

To demonstrate, in the “General Settings” section of the WordPress admin panel, you’ll find the “WordPress address (URL)” and “Site address (URL)” settings, and for sites where WordPress is installed into the root directory, they will have the exact same values:

But for sites where WordPress is installed into a subdirectory under the root (in this case a “wordpress” subdirectory), their values will be different:

At this stage it’s important to know the following:

bloginfo(‘wpurl’) equals the “WordPress address (URL)” setting

bloginfo(‘url’) equals the “Site address (URL)” setting

Where this matters is when you need to build URLs to certain resources or pages. For example, if you want to provide a link to the WordPress login screen, you could do this:

But that won’t resolve to the correct URL in the scenario such as the one above where WordPress is installed to the “wordpress” subdirectory. To do this correctly, you must use bloginfo('wpurl') instead:

Using bloginfo('wpurl') instead of bloginfo('url') is the safest way to go when building links and URLs inside your plugin because it works in both scenarios: when WordPress is installed in the root of a website and also when it’s installed in a subdirectory. Using bloginfo('url') only gets you the first one.

How and When to Use Actions and Filters

WordPress allows developers to add their own code during the execution of a request by providing various hooks. These hooks come in the form of actions and filters:

Actions: WordPress invokes actions at certain points during the execution request and when certain events occur.

Filters: WordPress uses filters to modify text before adding it to the database and before displaying it on-screen.

The number of actions and filters is quite large, so we can’t get into them all here, but let’s at least take a look at how they are used.

Here’s an example of how to use the admin_print_styles action, which allows you to add your own stylesheets to the WordPress admin pages:

It’s impossible to write a WordPress plugin without actions and filters, and knowing what’s available to use and when to use them can make a big difference. See the WordPress codex page “Plugin API/Action Reference” for the complete list of actions and the page “Plugin API/Filter Reference” for the complete list of filters.

Tip: Pay close attention to the order in which the actions are listed on its codex page. While not an exact specification, my experimentation and trial-and-error has shown it to be pretty close to the order in which actions are invoked during the WordPress request pipeline.

Add Your Own Settings Page or Admin Menu

Many WordPress plugins require users to enter settings or options for the plugin to operate properly, and the way plugin authors accomplish this is by either adding their own settings page to an existing menu or by adding their own new top-level admin menu to WordPress.

How to Add a Settings Page

A common practice for adding your own admin settings page is to use the add_menu() hook to call the add_options_page() function:

wp_die('You do not have sufficient permissions to access this page.');

15

}

16

17

// Here is where you could start displaying the HTML needed for the settings

18

// page, or you could include a file that handles the HTML output for you.

19

}

By invoking the add_options_page() function, we see that the “My Plugin” option has been added to the built-in Settings menu in the WordPress admin panel:

The add_options_page() function is really just a wrapper function on top of the add_submenu_page() function, and there are other wrapper functions that do similar work for the other sections of the WordPress admin panel:

add_dashboard_page()

add_posts_page()

add_media_page()

add_links_page()

add_pages_page()

add_comments_page()

add_theme_page()

add_plugins_page()

add_users_page()

add_management_page()

How to Add a Custom Admin Menu

Those wrapper functions work great, but what if you wanted to create your own admin menu section for your plugin? For example, what if you wanted to create a “My Plugin” admin section with more than just the Settings page, such as a Help page? This is how you would do that:

wp_die('You do not have sufficient permissions to access this page.');

27

}

28

29

// Render the HTML for the Settings page or include a file that does

30

}

31

32

functionmyplugin_help() {

33

if(!current_user_can('manage_options')) {

34

wp_die('You do not have sufficient permissions to access this page.');

35

}

36

37

// Render the HTML for the Help page or include a file that does

38

}

Notice that this code doesn’t use any of the wrapper functions. Instead, it calls add_menu_page() (for the parent menu page) and add_submenu_page() (for the child pages) to create a separate “My Plugin” admin menu that contains the Settings and Help pages:

One advantage of adding your own custom menu is that it’s easier for users to find the settings for your plugin because they aren’t buried within one of the built-in WordPress admin menus. Keeping that in mind, if your plugin is simple enough to only require a single admin page, then using one of the wrapper functions might make the most sense. But if you need more than that, creating a custom admin menu is the way to go.

Provide a Shortcut to Your Settings Page with Plugin Action Links

In much the same way that adding your own custom admin menu helps give the sense of a well-rounded plugin, plugin action links work in the same fashion. So what are plugin action links? It’s best to start with a picture:

See the “Deactivate” and “Edit” links underneath the name of the plugin? Those are plugin action links, and WordPress provides a filter named plugin_action_links for you to add more. Basically, plugin action links are a great way to add a quick shortcut to your most commonly used admin menu page.

Keeping with our Settings admin page, here’s how we would add a plugin action link for it:

With this code in place, now when you view your plugins list you’ll see this:

Here we provided a plugin action link to the Settings admin page, which is the same thing as clicking on Settings from our custom admin menu. The benefit of the plugin action link is that users see it immediately after they activate the plugin, thus adding to the overall experience.

Additional Resources

I’ve covered a lot in this article, but there’s plenty more out there to keep you busy awhile. The most comprehensive documentation for WordPress plugin development can be found on the WordPress Codex, a huge collection of pages documenting everything that is WordPress. Below are some of the more pertinent links from the codex you’ll need: