Discussion: Plugin name length, readability and consistency.

[dufresnesteven]

I wanted to open up a place to discuss a few issues and trends that we are seeing with plugin titles on wp.org (and via Admin interface) and how they relate to the greater WordPress Plugin experience.

Issues/Trends

• Plugin titles in the .org directory don't always map to the Plugins list in the WordPress Admin after install.
• Some plugin titles are long and not user-friendly.
• Some appear to be exclusively targeting specific keywords for wp.org (search API) SEO purposes.

Adjacent Topics (probably best to talk about in a different ticket)

• Some include trademark violations.

Related Tickets:

• Deprecate readme.txt plugin name header: https://meta.trac.wordpress.org/ticket/6106

Why is this happening

I'm speculating, but since we use the readme.txt plugin name in the search algorithm, plugin authors are inclined to load it with keywords to enhance their visibility in search results. It's also a possibility that authors overlook the readme.txt file when updating their plugin and they fall out of sync.

We also need to keep in mind that the search algorithm is used to display results on wp.org and via the admin interface (/wp-admin/plugin-install.php). So a change on .org is also a change to the WordPress Admin result list.

@dd32 proposed that we start by deprecating the readme.txt plugin name in #6106 in favor of the plugin name in the plugin's header fields.

That makes sense to me, do others have anything they want to add to this discussion of things to consider or potential solutions?

[flexseth]

it's my faveee

[flexseth]

no favee love

[flexseth]

We also need to keep in mind that the search algorithm is used to display results on wp.org and via the admin interface (/wp-admin/plugin-install.php). So a change on .org is also a change to the WordPress Admin result list.

What has always been weird to me is that I can ❤️ a plugin on WP.org, and then search for it.
Yet for some reason it doesn't show up as my first search result.

In this case the plugin is actually Gutenberg

... which I absolutely do love and want to be the first result.

and for whatever reason find myself in this workflow more often than you'd think

[dd32]

@flexseth That's deserving of a dedicated ticket, to boost users favourited plugins in results. It's very much unrelated to this ticket overall.

I'll note however, that you searching from within a WordPress dashboard, the search algorithm has no knowledge of who you are, The favourites view exists for finding your favourited plugins.

[joostdevalk]

I'm in favor of deprecating any duplication we have between plugin headers and readme.txt. Makes it better for everyone.

If we do it for the plugin name, I'd consider also doing it for the short description. Use the one from the plugin file.

I think restricting the length might make sense but we'd have to put the limit relatively high, which would still leave _some_ room for search optimization driven titles. Maybe someone can gather some data for the top 1,000 or so plugins and put their titles in a sheet so we can have a look at what would be realistic?

[bradshawtm]

I'd definitely prefer to limit SEO manipulation in plugin names. We can't fully remove the plugin name from the search params, though, as I'd expect to be able to fuzzy search (potentially with typos) for X plugin and get my preferred plugin.

Perhaps we could limit plugin names to 5 or so words?

[smub]

I can see why deprecating the duplication may sound ideal from a development perspective. As a plugin owner, I believe centralizing everything in readme.txt since that's where everything else is managed anyways would be the best approach. If a plugin doesn't have readme, then the Plugin Header can be displayed (so we cover custom plugins that are not on .org).

With regards to the concerns around length in title, I believe @joostdevalk suggestion is good for analyzing the top 1000 or even top 3000 plugins, so we're taking 5% of sample data.

We should also consider the use-case of the two different screens because although it may seem similar, it's not. Search in admin area or .org site is for "discoverability" so users can find the solution they're looking for --- the plugin screen in admin area is for site management.

In discoverability use-case, a descriptive title is needed to help user find what they're looking for.

For example:

Jetpack – WP Security, Backup, Speed, & Growth << without the description, a beginner user simply wouldn't know what Jetpack is. Furthermore, Jetpack wouldn't rank for Jobs to Be done keyword which is what a new user would type (i.e backup or speed) in the search.

Dokan – Best WooCommerce Multivendor Marketplace Solution – Build Your Own Amazon, eBay, Etsy << a lot of users don't know what multivendor is. They might search for amazon or ebay or etsy.

MonsterInsights – Google Analytics Dashboard for WordPress (Website Stats Made Easy) << we know in our research that a lot of users don't know what Google Analytics is, so instead they either type analytics or stats in WPBeginner site search. Furthermore, we know that most beginners find analytics and data to be confusing, so adding the descriptive part that we make Website Stats Easy is helpful in discoverability phase.

But once the plugin is installed, then the user doesn't necessarily need to know the full title again (the brand alone becomes sufficient). So in that case, we can simply truncate the title in the Plugin screen if the concern is managing the height / scrollability of that screen.

With that said, I do understand concern of keyword spam and trademark violation as well. We have seen several new plugins who use our trademark and other's to spam the title in hopes of ranking higher in search results for our branded keyword. This should not be allowed and I know .org plugins team takes action against these since it's a violation of the policy already.

But to stop that systematically is going to be a challenge and will need some more sophisticated solutions.

One suggestion would be to change the incentive alignment by reducing the weight of Title and Slug from ranking algorithm and shifting more weight to avg. ratings / readme description (where length was already reduced anyways).

[dd32]

In discoverability use-case, a descriptive title is needed to help user find what they're looking for.

I disagree. That's what the description field is for.

Perhaps what you're getting at though; is that the interface puts too much weight on the Name of the plugin, and not enough focus on the description.

We have seen several new plugins who use our trademark and other's to spam the title in hopes of ranking higher in search results for our branded keyword. This should not be allowed

Of the three plugins you've listed, only Jetpack is compliant with trademarks. The other two are violating the WooCommerce, Google Analytics, WordPress, and potentially Ebay/Etsy/etc trademark rules. Most of these platforms will look at the entire title, including any descriptive text, as the product name. The description field would have to be used to meet it.

Perhaps we could limit plugin names to 5 or so words?

I don't think limiting word length is the complete answer here, it might certainly help, but it's not a solution.

[dufresnesteven]

We should also consider the use-case of the two different screens because although it may seem similar, it's not. Search in admin area or .org site is for "discoverability" so users can find the solution they're looking for --- the plugin screen in admin area is for site management.

I am sensitive to the difference in context between discovering and managing and agree it is a notable distinction. For it to matter, we do have to agree that the plugin name is the primary driver of discoverability. If we don't find that is the case (I personally don't think it should be), I don't see the value in supporting a path that makes deviation possible based solely on the fact that they are different contexts without specific use cases where it makes sense for them to be different.

---

Maybe starting with better guard rails for the display name, regardless of whether it comes from the readme.txt or plugin headers may be a better approach. I wouldn't want plugin authors to move the not-so-user-friendly plugin names that we see in the readme.txt to their Plugin headers to maintain their (unfair?) ranking. That isn't a better outcome for end users.

[smub]

Replying to dd32:

Of the three plugins you've listed, only Jetpack is compliant with trademarks. The other two are violating the WooCommerce, Google Analytics, WordPress, and potentially Ebay/Etsy/etc trademark rules. Most of these platforms will look at the entire title, including any descriptive text, as the product name. The description field would have to be used to meet it.

Different brands choose to enforce their trademarks differently. Descriptive use is considered fair use by many so I disagree with your assessment above.

The MonsterInsights example was clarified with Google team. Plugin name starts with MonsterInsights and then explains what it does via integration. We have a very good integration partnership with the Google team.

Similarly the use of WooCommerce in Dokan's name is fair use because it highlights that it's an integration plugin for WooCommerce. Of course Automattic reserves the right to disallow it based on their trademark guidelines, but based on what I read on their page, it's fair game according to the policy except the fact it uses the word "Best" in the title which Woo sites discourages.

Nonetheless, the main point I am trying to share is that descriptive titles are needed to explain the functionality of the plugin during discoverability because people often only look at the title (not small description text) because we scan before reading. Even when you look at website Meta Title which is used in Google Search (largest search engine on the planet), the titles are descriptive because it helps with discoverability.

Here is the meta title that WordPress.org uses to show up in Google Search result: "WordPress.org: Blog Tool, Publishing Platform, and CMS"

Here is another example from WordPress.com meta title used for Google search discoverability: "WordPress.com: Build a Site, Sell Your Stuff, Start a Blog & More"

This is done for a reason: To help users with discoverability.

I think we can learn from Google search here. The readme title is effectively the meta title as well. This helps new users find what they are looking for easily so they can create their dream project with WordPress.

This change that's being proposed have a lot of adverse consequences on discoverability for beginners which would also hurt the growth of WordPress long term because discoverability has a huge impact.

[flexseth]

Replying to dd32:

@flexseth That's deserving of a dedicated ticket, to boost users favourited plugins in results.

Enhancement requested

[strangerstudios]

I agree with Syed.

The additional words are doing their job to help folks find the plugin they need... both by making the results more scannable but also by pushing plugins with the search terms in the title up in the results. There is still a length limit for titles, and plugins are forced to make tough decisions on which terms to target.

Put another way: Extra words in the title affecting the search results is a feature, not a bug. I guess that's the discussion here, but I feel adding new rules or restrictions is just going to complicate things for the sake of our feels those few times we see a particularly egregious title.

As proposed, I expect forcing the readme and plugin header titles to be the same will result in the longer, more descriptive titles being used in both spots vs. the shorter titles. Looking for a plugin already installed on your site is a different activity from looking for a new plugin in the directory. The different titles are crafted consciously for each use case.

An alternative solution would be to lower the weight of the title in search results, but then that would make it harder to find plugins in those cases where you DO know the brand name. Minor tweaks like this have knock on effects. Let's make sure we think it through.

It should also be understood that adjusting the title rules so they can only contain brand names in them is going to disproportionately hurt newer and smaller plugins that don't have the benefit of a brand built off .org. It's also going to hurt folks who are more creative than I am, and come up with better plugin names than the already keyword stuffed "Paid Memberships Pro".

[carlhancock]

For comparison, and while I know the plugin and theme repositories are not full blown app stores I feel the comparison is very relevant, here are the character limitations for app titles in various app stores and marketplaces...

Shopify
30 Characters

Google Play
30 Characters

Apple App Store
30 Characters

Atlassian Marketplace
40 Characters

Slack App Marketplace
35 Characters

Square App Marketplace
32 Characters

Wix App Marketplace
30 Characters

The name is what is used when a user browses or searches. It is then accompanied by a short description where things people typically stuff in the plugin title on the WordPress.org repo would typically reside. Or in some cases they rely entirely on imagery and the image includes the necessary short descriptive text.

They then also have a longer page title for the individual listings. For example. Zapier's listing on Shopify's app store can be found here:

​https://apps.shopify.com/zapier?surface_detail=store-management&surface_inter_position=2&surface_intra_position=8&surface_type=category&surface_version=redesign

Notice the app name or isn't simply "Zapier" but is a bit more descriptive with "Zapier: Workflow Automation" meanwhile the meta page title is "Zapier: Workflow Automation - Easy automations for your ecommerce business." and the "Easy automations for your ecommerce business." is also the short description which is displayed with the app below the name when searching or browsing apps. And then of course they have a long description that is displayed on the listing along with screenshots, etc.

All of these examples we can look to for inspiration have one thing in common... they look a lot better and far more professional than what is going on in the plugin repository right now.

[dd32]

here are the character limitations

Character limitations seems like a good starting point for the title, which might reduce the level of effort required here.

For reference, of all plugins

Average Readme Length	24.2 Characters
Average Plugin name length	21.5 characters
Number of Readme length >50char	5.28% (3,138 plugins)
Number of plugin name > 50char	1.88% (1,115 plugins)

If we just look at plugins updated in the last 2 years:

Average Readme Length	29.4 Characters
Average Plugin name length	23.5 characters
Number of Readme length >50char	11.14% (2,379 plugins)
Number of plugin name > 50char	3.31% (707 plugins)

The 50 characters chosen above was rather arbitrary, just the next roundest number above the above examples.
Looking at the plugin names that are greater than 50, they're all either a) descriptive, or b) similar to {Different Plugin Name} Extension/Addon: {Functionality this plugin adds}

[danieliser]

First I'm surprised there isn't already a pseudo length limit using ... truncation like they do for the plugin description in results now.

That said.. I'm entirely inclined to agree with @smub as well. His comparison of google meta titles and readme plugin name header is spot on. There isn't anybody in this thread that isn't trying to game the SEO levers on their site to get favorable results from Google.

At the end of the day if any part of the search factors can be manipulated in a plugin authors favor, just like with SEO, its their job to find those openings and make the best advantage for themselves at getting in front of users who might be seeking their product.

To @strangerstudios point, I don't see the manipulation of search here as a bug, if they change this and weight the plugin file header more, authors will make the most of it there too, which will have an impact, flooding the Plugins page in dash with useless extra long plugin names.

In reality the search algo likely should change over time just like major search engines, ever chasing toward higher quality matches.

It should not however be concerned with more aesthetically pleasing results pages at the expense of giving users the best chance of finding what they are looking for.

[Marc4]

Those who use the title for keyword stuffing will continue to do so, whether they have 30 or 150 characters available in the title. That's why I think setting a character limit is a good idea.

It's also true that the new, wider plugin directory design may alleviate the feeling of extremely long and overloaded titles.

Limiting the characters in the title is not synonymous with reducing the discoverability of content, otherwise there would be no ASO in apps directories.