WordPress themes & plugins are able to do some amazing things. They can spice up your home page with random featured images, provide a myriad of caching techniques to improve user experience, or — and this is in just about everybody’s top 5 — soup up your site’s search engine optimization.
On the simple side, a search engine optimization plugin would add a meta box to the WordPress “Add New Post” screen. This box, which is basically a pretty GUI for custom fields, would allow users to add search engine treats such as a description, keywords, and sometimes even a post title specifically for the title tag.
The actual custom fields being saved into your post’s meta, though, may go by varying names. Again, on the simple side, a plugin might save a search engine description for a post into a custom field with a key (name) of “description.” The keywords would be saved into “keywords,” title into “title,” and so on.
But what we see in the wild among search engine plugins or themes with optimization features build in is diversity. The simple names may be used for some (or even many), but what of addons which use propriety naming schemes?
Let’s use the fictional Theme X as an example. You start your blog with it, you post for years, and you eventually amass a library of thousands of posts, all with search engine data saved using Theme X’s custom field naming schema: x_description, x_title, x_keywords, et al.
But then something awesome happens, and a search engine plugin named Plugin Y is released which promises to take your site into the next level of Search Engine Nirvana. You believe the hype to be justified, and you install the plugin.
After a few weeks, though, you start to notice that your older posts don’t seem to be performing as well in the search engines. After some investigation, you notice that your descriptions, keywords, and titles entered using Theme X’s system are no longer being used. Instead, Plugin Y forces its values, and of course any post published prior to installing Plugin Y would have nothing to output.
So what do you do? Some may start the tedious task of manually reentering the data using Plugin Y’s meta box. Others may look for a bit of database code to convert the old custom field keys to the new ones used by Plugin Y (actually, this is pretty easy to do).
But really, this situation shouldn’t have to come up in the first place. Users shouldn’t be expected to have to play Compatibility Warden between plugins & themes, especially on something as simple, not to mention important, as search engine optimization.
So what I would like to suggest to the WordPress community — and if you like this idea, run with it! — is to establish some open standards for plugin & theme authors, starting with custom field naming conventions for search engine meta.
Everyone’s job would be easier if every developer used “description” for description fields, and developers would no longer find it necessary to either build in compatibility with other themes or plugins (which could be a neverending task as others are developed & popularized).
Compatibility, efficiency… and most importantly no surprises for users who switch from one system to another.