Top WordPress Myths You Should Stop Thinking About: Part 1

As WordPress grows in popularity, so do the misconceptions/myths connected with it. Being the top CMS there are plenty of WordPress myths, and new people running into WordPress would most certainly be confused.  Today we will focus on top WordPress myths revolving around WordPress hemisphere and hopefully come to a conclusion of how much of these myths are true.

Myth 1# You should hide the fact your using a WordPress site

If you’re curious about how this hiding software version thingy came into scene then I must quote from WP White Security –

The idea of hiding the version of the software you are running originated from the web application security industry, because many organizations cannot always use the latest version of the web server or other software available because of web application incompatibilities.

Therefore most of the time, by hiding the version of the web server saved them from malicious hacker attacks, especially back in the days when automated security tools, which are also used for hacking were not so popular or couldn’t identify most of the vulnerabilities.

There are various ways to know about WordPress version, In most cases it won’t help you to protect your WordPress from automated mass malicious attacks. Most hacking are result of using outdated WordPress version and plugin/theme vulnerability with combination of weak passwords.

Hiding a WordPress site won’t be easy for you and it’s probably overkill for most parts, and more importantly you will have to put hundreds of hours of tweaking codes to cover up your WordPress mask.

As said by Konstantin who works at Automattic –

 There are hundreds if not thousands of ways to not only find out the fact that you’re using WordPress, but also find out the exact version number, regardless of any plugins or hacks changing or hiding the “generator” meta tag, the readme file and so on.

Quoting from a Stackexchange answer –

The problem is not the obvious wp-* urls, the generator meta etc. The hard problems are with patterns that are associated with WordPress that a home grown system will not bother to implement like author pages, year,month,day, use p=nnn as a valid parameter, have comment form with the WordPress comment class, structure and link names, and then there is the self promotion of the caching plugins and yoast SEO and probably many other plugins that you see only when you inspect the HTML itself.

And even if you put the effort into cleaning up everything indicating that this is a WordPress, you might need to redo or at least recheck after every plugin or core upgrade. Life is just too short for that.

Just because some white hat tools do not detect your site is a WordPress do not mean that black hat do not do a better detection job. If this is done as a security measure then it is security by obscurity which is always wrong, and if you are just ashamed of using WordPress, then let me tell you something – no one cares, and even the very few that do probably will not know how to figure it out by themselves.

If you look closely most of the WordPress site compromise happens because the site owners do not take actions when themes/plugins/core vulnerability is exposed. You need to deactivate/delete/change that “rogue” plugin/theme/patch update to keep yourself unaffected.

Trying to hide the WordPress version is much harder work than just securing your WordPress website.  All one has to do is look at the page’s source code, and see what plugins/themes you are using, either by looking at the CSS and JavaScript files being loaded, or by the class prefixes that themes and plugins use.

In most cases, you don’t even have to look at the class prefixes. Look at the path of the external files being loaded, the names of the plugins/theme is usually right in there.

Hide the fact that your site runs on WordPress? You are dreaming, unless you countless spend hours changing tons of code, manually But if you do hide the fact you’re using WordPress you’ll still need to add the required security settings. so the need to hide WordPress isn’t worth the hassle.

Conclusion : Going through the hassles of hiding your WordPress won’t do much good. You should better invest your time on keeping yourself up to date with themes/plugins and WordPress core.

Myth 2# You should move wp-login.php file

Here’s what WordPress founder Matt Mullenweg thinks –

Obfuscation of login and admin directories is complete snake oil, it doesn’t actually fix any problems long-term and makes things more difficult for legitimate users. If a tutorial or guide suggests that you can safely ignore the entire thing.

This isn’t a great security idea because the wp-login or wp-admin page in of itself does not pose a security threat. Though it can be argued that if someone had your password/username they might not be able to find where to login, thus security through obscurity.

You could probably to some fancy re-directs, not sure how well that would scale with future releases or if it is even worth the trouble.

You can password protect your page using .htaccess ( so you will have a double login), Use a plugin like Limit Login Attempts. which locks out a user after failed logins, or you can white-list your IP, meaning you can log into your website from specific IPs only.

The best thing you could do for this matter is IP filtering and allow only those networks that are allowed to login to the WP-Admin dashboard (e.g. your office IP, developers’ IP, etc.)

Conclusion : You can move your wp login URL but it’s not the recommend way to hardening your security. Without moving login URL you can take other preventive steps to secure your WordPress site.

Myth 3# You should change database “wp-prefix”

The main reason some people suggest to change the database prefix is to prevent SQL injection.  What is SQL injection? According to SQL injection article –

SQL injection must exploit a security vulnerability in an application’s software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed.

You must have heard this a number of times, and even implemented, but this seems kind of like putting a band-aid on a broken arm. Security through obscurity is (largely) a lost cause.

If someone has access to your database, it likely won’t matter what your database name is as you are compromised. If someone doesn’t have access to your database, it doesn’t matter what you name your tables because they don’t have access to your database.

There are certainly exploits that work without proper access to the database. It would be better to plug/prevent those exploits than hoping no one guesses your table names or discovers them in another fashion. Database table names aren’t exactly the most secure pieces of information.

This WordPress Table Prefix: Changing It Does Nothing to Improve Security article from Wordfence did a great job at explaining in more technical way –

SELECT DISTINCT SUBSTRING(`TABLE_NAME` FROM 1 FOR ( LENGTH(`TABLE_NAME`)-8 ) )
FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE '%postmeta'; 

and can get your database prefix

Conclusion : It’s much like locking your doors. If someone wants in, they’ll break a window, kick in the door, or whatever. But we still lock our doors. Changing wp_ to anything else may or may not help. It’s easy to change so if you think it helps you might go for it. But beware changing your database prefix, some plugins might break your site or cause additional headaches in certain circumstances. 

Myth 4# You should hide WordPress version

It’s Security by obscurity, and is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice:

“System security should not depend on the secrecy of the implementation or its components.” However, NIST also states, “For external-facing servers, reconfigure service banners not to report the server and OS type and version, if possible. (This deters novice attackers and some forms of malware, but it will not deter more skilled attackers from identifying the server and OS type.)”

A system may use obscurity as one layer of a defense in depth strategy, which involves layered security. Despite its criticism of security through obscurity, NIST also suggests not making the operating system and version disclosed to attackers to deter novices using known flaws.

An attacker’s first step is usually identifying this information and if specific details of the system are not easily available, this step may be delayed. However, attackers with high skill and motivation will get the info they need through other means, making these obscurity measures ineffective.

The technique stands in contrast with security by design and open security, although many real-world projects include elements of all strategies

Even though standard bodies recommends against it. but they also suggested to use this technique to ward off novice attackers.

Conclusion : Whether you use it or not. Expert hackers will ultimately find your WordPress version number. But keep in mind that site hacks don’t depend on WordPress version rather they exploit on vulnerable plugins/themes. 

Myth 5# Too many plugins slow down a WordPress site

If you’re new to WordPress, you must be thinking too many plugins will slow down your site. Well, it’s not entirely true. It doesn’t matter if you have 50+ if they are well structured and coded.

The main point is, One badly written plugin can affect your site performance than twenty well written plugins. It’s not about the quantity of plugins, it’s about the quality of plugins.

Quoting from Mika Epstein‘s article How many plugins , She’s by the way in the admin plugin review theme and WordPress core review team, said – 

When people ask why their site is slow, sometimes my coworkers will say “It’s the plugins, right? He has 40 plugins!” and I’ll say “Maybe.” Then I look at what the plugins are, because it’s never the number of plugins, but their quality.

Pippin Williamson, the developer of Easy Digital Downloads, member of WordPress plugin review team and one of the most active WordPress thought leaders who runs a high number of plugins of his sites. PippinsPlugins.com runs 81 in total, and EasyDigitalDownloads.com runs 83. Pipping also voiced his concern in wpegine article –

The trick isn’t how many plugins you have, but what operations they need to perform in order to render your site in a visitor’s browser. Most plugins are pretty simple, but some will perform complex actions that are “expensive” in terms of backend processing, and will slow a website down.

In other words, you could have a quickly loading website with 80 plugins, and add a single, complicated plugin and lose half a second (or more) of loading time!

According to Pippin, there are four major areas he looks for when he evaluates adding a plugin to his website.

1. Does it load lots of scripts, styles, or other assets?

2. Does it add extra database queries to each page?

3. Does it perform complex operations?

4. Does it perform remote requests, like to external APIs?

Conclusion : Well coded plugins will not slow down your WordPress site. Use plugins like Query Monitor, Asset Queue Manager, What’s running, WP Simple Debug, WP Performance Profiler and Wixiweb FirePHP Queries to identify which plugin(s) is slowing your site down and find alternatives.

Myth 6# Inactive plugins doesn’t pose security risk

A plugin that has security holes is a problem, whether or not it is activated. So, here are some reasons why it is often recommended to remove plugins that you are not using.

1. If you have plugins that you aren’t using, you often don’t care about keeping them updated. As a result, they won’t get any security updates, and that will be a vulnerability on your site.
2. People often think that a plugin that is not running can’t negatively affect your site, but in the case of security, an attacker can exploit a security hole in a plugin that is installed, even if it is not activated.
3. Think about why the plugin is not running in the first place. If it is a plugin that you use regularly, and you just turn on and off as needed, that is fine. However, it could be a plugin that didn’t work right, or is no longer being maintained.
4. This second category of plugins are especially a problem for security, as they are often the source of security holes.

If your deactivated plugins are actively maintained and are kept updated, they aren’t a problem. But if you have plugins installed that aren’t being used and aren’t being updated, it is best to remove them. The real impact of inactive plugins affecting your site speed performance will be felt within the WP Admin or Dashboard.

Conclusion : If you don’t update inactive plugins, it’s best to remove them. 

Myth 7# Just install  SEO plugins there’s no need for SEO agency

You have been hearing this concept since the beginning of WordPress. May be, you have had clients who installed few SEO plugins and expect you to do some tweaking and rank them first page on Google.

Sorry to burst your bubble but the truth is SEO plugin(s) will help you to optimize your site/content for search engines but SEO plugin(s) will not cover everything.

This article 10 WordPress SEO Questions That Took Me 10 Years To Answer!  from searchengineland explained it better.

SEO isn’t a “quick and easy install.” It’s not turnkey. It’s not “set and forget.” That isn’t how SEO works. SEO is a continuous process that should be woven into the fabric of your ongoing marketing efforts.

There’s no WordPress plugin that can cover all elements of SEO, just as a great hammer won’t by itself help you build a fantastic new house! Configuring your SEO plugin correctly is a step in the right direction — but it’s only the first step! The big picture is a lot more complex and comprehensive.

What you need is a SEO specialist working for you. And that person understands how search engines ranks contents/websites, has solid grasp on ever changing SEO ranking factors, keeps self educating on search engine algorithm updates.

Knows how SEO strengthens your marketing, and keeps you from making costly mistakes. And you should keep in house SEO agent or have long-term relationship or hire a consultant/agency for a monthly retainer to ensure that your website/content perform best.

May be you are still not convinced, still thinking SEO plugins will do all the work there’s no need for any agency or consultant. Here are some real life example ( Again quoting from searchengineland ) to help you illustrate better –

• When you upgrade WordPress, or a plugin, or install a new plugin or theme, it will alter your website’s code. These changes may negatively impact your site’s SEO if not properly accounted for, which could cost you lost rankings.
• Adding new plugins can slow your site down. Site loading speed is an important ranking factor in Google’s algorithm — and just that innocent change could negatively impact your rankings.
• Content marketing is critical for every online business. Optimizing your content for specific keywords based on SEO analysis can do wonders in attracting your ideal prospective customers, engaging them, and converting them into buyers. WordPress alone will not be able to advise on keyword trends around which you should build this content.
• Running periodic SEO audits can ensure that your site is always optimized and able to stay abreast of the changing SEO environment. Having a WordPress SEO consultant on tap for advice and guidance can increase organic traffic so much that it pays for itself many times over.

People think SEO(s) is easy and they can certainly bring more traffic easily and call themselves SEO guru. Sadly, the reality is very different.

Google has over 200 ranking factors and you can check them on Google’s 200 Ranking Factors: The Complete List. Even if you install 10 different SEO plugins. You can not possible cover everything.

Conclusion : By all means install SEO plugin(s) but don’t reply on them for everything. And for that matter plugin(s) can not cover every aspects of SEO.

Did you buy into any of these top WordPress myths that you believed for a long time and later found out it was not true?  What do you think of these WordPress myths and their conclusions ? Feel free to comment and share your opinion.