WordPress security & performance, complete administrator guide 2025

Running a professional WordPress site is more than writing content. It’s continuous work on three pillars: Security, Visibility (Analytics/SEO) and Performance. This article expands on a training presentation and checks each recommendation against official documentation: the WordPress Advanced Administration Handbook, the WordPress.org security page, its server requirements, OWASP and Google’s own docs. Every section gives steps you can apply today.

#How to harden WordPress security without plugins

Many people think expensive “Security Pro” plugins are needed to secure WordPress. That’s a myth. The strongest protections work at server level, before a request ever executes PHP. A layered approach that starts with the infrastructure and moves up to the application is more reliable than relying on plugins alone.

#WordPress updates, unused plugins and nulled themes

Updates: According to the WordPress.org security page, only the latest WordPress version is officially supported; the Security Team (more than 50 experts, per the same page) backports fixes to older versions only as a courtesy. The hardening guide adds two facts: automatic updates have existed since WordPress 3.7, and details of fixed vulnerabilities are usually made public, so an old version gets easier to attack every week it stays unpatched. Our complete hardening guide goes further into the update workflow.

PHP: The official requirements recommend PHP 8.3 or greater, MySQL 8.0 or greater (or MariaDB 10.11 or greater) and HTTPS support. WordPress still runs on PHP 7.4 and MySQL 5.5.5, but both have reached end of life and the page itself warns they may expose the site to security vulnerabilities. If your server is still on PHP 7.x, upgrading is the first task.

Themes and plugins: Delete (not just deactivate) everything you don’t use. Every file on the server is a potential attack vector. Deactivated plugins can still be executed if an attacker requests their files directly, so full removal is the only safe option.

Source: Never download “Premium for free” plugins from torrents (Nulled). A nulled copy is code modified by an unknown third party, which you cannot audit and which receives no updates. The official guide says to download WordPress only from WordPress.org; for plugins and themes the equivalent is the official directory or the author’s own site.

#Which wp-config.php settings improve security

Add these lines to your config file to block typical attacks:

// Block file editing from admin
define( 'DISALLOW_FILE_EDIT', true );

// Force SSL for login and panel
define( 'FORCE_SSL_ADMIN', true );

// Change database prefix (do this ONLY during installation!)
$table_prefix = 'wp_a1b2_'; // Instead of default wp_

DISALLOW_FILE_EDIT removes the edit_themes, edit_plugins and edit_files capabilities from all users. The hardening guide is clear about its limit: it does not stop someone uploading malicious files, but it closes a common route after an administrator account is stolen. On the prefix, the same guide explains that many published SQL injection attacks assume wp_, so changing it blocks at least some of them. It is no replacement for prepared queries in code.

#How to disable XML-RPC and limit revisions

// In wp-config.php: limit revisions
define( 'WP_POST_REVISIONS', 5 );

// In a mu-plugin, not in wp-config.php
add_filter( 'xmlrpc_enabled', '__return_false' );
remove_action( 'wp_head', 'wp_generator' );

Two corrections to snippets that circulate online. First, WordPress has no XMLRPC_ENABLED constant; what exists is the xmlrpc_enabled filter (since version 3.5), and it only disables methods that require authentication. Pingbacks keep answering. If you don’t use XML-RPC, block xmlrpc.php at the server, as the rule below does. Second, remove_action() does not work in wp-config.php, because WordPress functions are not loaded yet at that point; it belongs in a plugin or in wp-content/mu-plugins/.

#How to block sensitive files with .htaccess

The .htaccess file (on Apache/LiteSpeed servers) is your first guard. Set rules that block access to sensitive files before any PHP code runs.

Block access to sensitive files (Apache 2.4 syntax, as used in the official guide):

<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php)">
Require all denied
</FilesMatch>

The Order deny,allow and Deny from all directives belong to Apache 2.2; on Apache 2.4 they only work through the mod_access_compat compatibility module. Block xmlrpc.php only if nothing uses it: the WordPress mobile app or Jetpack may depend on it.

Restrict wp-login.php by IP, if you work from fixed addresses. This is the example from the official brute force guide, with documentation addresses you replace with your own:

<Files "wp-login.php">
Require ip 203.0.113.15 203.0.113.16
</Files>

#What file permissions WordPress needs

The hardening guide gives concrete values: directories at 755 and files at 644, which is also what automatic updates apply. The root, wp-admin/, wp-includes/ and wp-content/plugins/ should be writable only by your user account; wp-content/ also by the web server. For wp-config.php it recommends 440 or 400, so only the owner and the web server can read it, and it mentions moving the file one directory above the installation, with the caveat that some experts consider the benefit minimal.

find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 /path/to/wordpress/wp-config.php

The same principle applies to the database: normal operation needs only SELECT, INSERT, UPDATE and DELETE, but the guide advises against revoking ALTER or DROP, because updates and some plugins change the schema. A separate database user per site, on the other hand, costs nothing.

#HTTP security headers in .htaccess

Add headers that protect against common attacks such as clickjacking and MIME sniffing. The values follow the OWASP HTTP Headers Cheat Sheet:

# Security headers
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header set X-XSS-Protection "0"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header unset X-Powered-By

Many older guides recommend X-XSS-Protection: 1; mode=block. OWASP says the opposite: don’t send the header, or set it to 0, because the browser filter it switched on could create XSS issues on otherwise safe sites. Real XSS protection is a Content Security Policy that disallows inline JavaScript. OWASP prefers DENY or the CSP frame-ancestors directive over X-Frame-Options; SAMEORIGIN is the usual compromise on WordPress because the Customizer loads the site inside a same-origin iframe. Treat HSTS with care: an expired certificate locks visitors out for the whole max-age, so enable it only once HTTPS works on every subdomain.

#Two-factor authentication (2FA) in WordPress

Enable 2FA for every administrator account. The official brute force guide states it plainly: WordPress core does not ship 2FA, so you need a reputable plugin or identity provider. Plugins such as Two Factor (maintained by WordPress contributors), WP 2FA or Google Authenticator provide it. The same guide adds three measures: don’t use the admin username, use long unique passwords with a password manager, and rate-limit wp-login.php and xmlrpc.php at the edge (WAF or CDN) or in the web server, because a security plugin still burns PHP resources during a large attack.

#How to back up a WordPress site

The official backup guide splits the job into two parts that belong together: the database (posts, comments, settings) and the files (core, plugins, themes, uploads). A database-only copy does not restore the site. Recommended frequency: weekly for small sites, daily for high-activity sites, and always before an upgrade. Keep 3 to 5 recent backups in different places and on different media. To restore, put the files back first, then import the database; if credentials changed, update wp-config.php. The hardening guide adds that backups should be encrypted, with independent hashes kept to prove nobody altered them.

#Which OWASP Top 10 2025 risks apply to WordPress

The WordPress.org security page says the Security Team works to harden core against threats such as the OWASP Top Ten. The 2025 edition is useful as an administrator checklist, because several categories map to decisions made in the dashboard or on the server rather than in core code:

On logs, the hardening guide explains that server logs show the IP, time and action, and reveal attempts at XSS, file inclusion, directory traversal and brute force. It recommends tools such as OSSEC and filtering out noise so important alerts do not get lost.

#How to set up Google Search Console and GA4 for WordPress

You can’t manage what you don’t measure. Google Search Console (GSC) and Google Analytics 4 (GA4) are your business’s eyes and ears.

#What to check in Google Search Console every week

The only place where Google “talks” to you about your site. It is the most important tool for any WordPress administrator who cares about search visibility.

1. Sitemap: Make sure you’ve submitted your sitemap (usually domain.com/sitemap_index.xml generated by SEO framework). Check that all important URLs are included and that there are no processing errors.
2. Indexing Errors: Check the “Pages” section weekly. Look for 404 (not found) and 5xx (server errors). A 404 on a URL that receives links or traffic is a lost visit; a repeated 5xx points to a server problem.
3. Core Web Vitals: GSC will tell you directly if your site loads fast enough (LCP), responds to interactions in time (INP) and is visually stable (CLS). Focus on field data (real users), which is what the report counts.

#Which Core Web Vitals thresholds a page must meet

According to web.dev, a page has good Core Web Vitals when it meets all three thresholds at the 75th percentile of page loads, measured separately on mobile and desktop:

The 75th percentile means most visits must meet the threshold, not just the average. That is why a fast lab test from your office does not guarantee a green report in GSC.

#How to set up key events in GA4

GA4 differs from old UA. It focuses on events rather than pageviews, which changes how you measure a site’s success.

• Don’t just measure “visits”. Configure key events: form submission, phone click, PDF download. Google renamed the concept: what used to be conversions in GA4 are now called key events, and “conversion” is reserved for measurement tied to Google Ads.
• Remember GDPR. Consent Mode v2 passes the visitor’s consent decision to Google tags. According to Google’s documentation, version 2 adds the ad_user_data and ad_personalization parameters to the existing ad_storage and analytics_storage. Consent Mode does not replace a consent banner or a legal basis: it only makes the tags respect the user’s choice.
• Add custom events that reflect your own business goals: quote requests, newsletter sign-ups, WhatsApp clicks, appointment bookings.

#How to optimize WordPress performance (WPO)

A fast site improves user experience and Core Web Vitals, which Google measures in the GSC report described above.

#What hosting a fast WordPress site needs

You can’t optimize a site on hosting for $5/year. The official optimization guide notes that moving to a server with SSD or NVMe drives, more CPU and more memory can make a big difference. Look for hosting with:

• NVMe disks for fast database I/O.
• Redis/Memcached support (database in RAM) for object caching.
• LiteSpeed (LSCache) or Nginx server for efficient request handling.

The same guide gives two tips that are often forgotten: don’t run DNS or a mail server on the WordPress server. For contact forms, use a form plugin with an external mailing service.

#How to optimize images in WordPress

Images are usually the heaviest resources on a page, and the LCP element is often an image.

• Lazy Loading: WordPress does this by default since version 5.5, but optimization plugins add more control over iframes and videos. Do not lazy-load the main image visible on load, because it delays LCP.
• Formats: Use WebP or AVIF. According to Google, lossy WebP is 25 to 34% smaller than a comparable JPEG at equal SSIM quality, and lossless WebP is 26% smaller than PNG.
• Dimensions: Don’t upload 4000px photos to a blog where text width is 800px. Resize before uploading.

#Page cache, object cache (Redis) and browser cache in WordPress

Your site shouldn’t generate PHP for every visitor. Use caching at several levels:

• Page Cache: Saves ready HTML to server disk for instant responses. The official optimization guide says caching pages as static files can speed up fairly static pages several hundred times over.
• Object Cache (Redis): Keeps database query results in memory. Crucial for WooCommerce stores and large sites where the same queries repeat constantly.
• OPcache: Keeps compiled PHP code in memory; the official guide lists it as an accelerator that speeds up every PHP file, not only WordPress.
• Browser Cache: Set expiry headers so browsers store static assets locally.

#CDN and edge computing for WordPress

For sites with a global audience, a CDN such as Cloudflare mirrors images and other static files on servers close to each user; the official guide presents it as the answer to geographic distance between server and visitor. Edge computing goes a step further, running server logic close to the user to cut latency. A CDN with a WAF is also the right place to rate-limit requests to wp-login.php.

#How to find which plugin slows WordPress down

The official optimization guide proposes a simple method: deactivate plugins selectively and measure server performance after each change. If one of them weighs a lot, read its documentation, ask in its support forum or look for an alternative with similar features. The developer tools in Firefox or Chrome include performance panels good enough for a first measurement. On the database side, the same guide recommends InnoDB, the default MySQL engine, and converting old MyISAM tables.

#Continuous performance monitoring

Set up performance monitoring with tools such as DebugBear or SpeedCurve. They detect performance regressions automatically, so you can act before users notice.

#How often to maintain a WordPress site

Looking after a WordPress site is a process, not a one-time action. Set a firm schedule:

• Daily: Check backups (automatic) on high-activity sites and watch security alerts.
• Weekly: Update plugins, check GSC, review error logs and, on small sites, take the weekly backup.
• Monthly: Do a speed audit, a user review (does anyone unauthorized have admin access?) and database cleanup.
• Quarterly: Full security audit, review of installed plugins, a test restore of one backup and an update of the disaster recovery plan.

This systematic approach gives peace of mind and stable growth. Security and performance are not projects with an end date, they are ongoing processes.