WordPress Configuration Cheat Sheet 1

WordPress is one of the most popular CMS in the world. That is why its good to have a simple cheat sheet for most of the important stuff in it.


The debug functionality should not be active in a production environment, as it might provide useful information to potential attackers.

The debug information is very helpful during the development of a WordPress application. However, it is important to make sure that the parameter is set back to false before loading the system onto a remote server. Errors should be logged, but they must not be visible to unauthorized users.

define( 'WP_DEBUG', false );
#if WP_DEBUG_LOG is enabled, you have to enable WP_DEBUG as well
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );


Each WordPress installation should have its own database with a dedicated user and a secure and unique password.

When installing WordPress, a table prefix can be specified. This can allow you to run several installations using one database. However, sharing one database between different installations is dangerous because if one instance gets hijacked, the other installations will also be at risk. In addition, you should avoid using the database root account, as it has full access to all databases on the server.

define( 'DB_NAME', 'unique_database_name' );
define( 'DB_USER', 'unique_database_user' );
define( 'DB_PASSWORD', 'strong_and_unique_password' );


No one should be able to read the traffic between your server and your users. Use SSL encryption and force WordPress to use only this type of connection.

It is now standard practice to encrypt your traffic. Many browser manufacturers mark un-encrypted connections as dangerous. Often web hosters offer their customers simple free certificates to enable SSL encryption. Also providers like Let’s Encrypt offer free certificates.

define( 'WP_SITEURL', 'https://www.mydomain.com' );
define( 'WP_HOME', 'https://www.mydomain.com' );
define( 'FORCE_SSL_ADMIN', true );
define( 'FORCE_SSL_LOGIN',true );


WordPress supports automatic database repair. This should not be possible without a backup of the database.

The path wp-admin/maint/repair.php, which even unauthenticated users can access, triggers this automatic process. This might be helpful for a broken or fragmented database schema. However, this should never be done without a proper backup of the database.

define( 'WP_ALLOW_REPAIR', false );


Admins and Editors are able to publish unfiltered HTML or files. If that is not absolutely necessary, activate these filters

By default, Admins and Editors are able to write unfiltered HTML in the post title, post content, and comments. The filetype filter can also be deactivated. This filter should remain activated.

define( 'ALLOW_UNFILTERED_UPLOADS', false );


Your WordPress should always be up to date so that it can resist the latest attacks. Activate the automatic security updates .

Since WordPress is a wide-spread application, many attackers test for known vulnerabilities in outdated installations. Don’t forget to perform a backup before each core upgrade, so only the minor update with current security patches should be installed automatically.

https://codex.wordpress.org/ Configuring_Automatic_Background_Updates

define( 'WP_AUTO_UPDATE_CORE', 'minor' );


Prohibit the editing of code lines in plugins and themes by your admins and editors. Deactivate the file editor for all extensions. To harden your installation completely you can prevent any changes to your system by prohibiting the installation of plugins and themes.

By manipulating code, a trusted extension can become a gateway for attackers. Themes and plugins can not only bring advantages for your WordPress. You must trust the creators of these extensions. Activate this barrier to prevent your admins and editors from loading untrusted extensions.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

If you need support or you are an agency we can help you.