Secure a WordPress site: the operational guide for freelancers and agencies

External diagnosis, hardening, monitoring and client reporting: a structured method to stabilize a portfolio of WordPress sites and turn security into a commercial argument.

A client calls on a Monday morning, their WordPress store redirects to an online casino. Three days later, Google has blacklisted the domain and revenue is at zero. This scenario plays out every week at agencies managing client site portfolios, and the cause is almost always the same: an obsolete plugin, a weak password, a login page exposed to thousands of attempts per hour.

Securing a WordPress site is not about stacking security plugins until the dashboard becomes unreadable. It is a structured approach that starts with an external diagnosis, continues with configuration hardening, and ends with continuous monitoring. This article details the concrete steps you can apply today, from the perspective of a freelancer or agency that wants to stabilize client sites and turn each audit into a commercial argument.

Why WordPress concentrates so many attacks

Popularity as exposure factor

WordPress powers a dominant share of the web. According to W3Techs, 43% of global sites run on this CMS, which mechanically makes it the first target for attackers. Bots do not target a specific site, they constantly scan every IP address on the web looking for known WordPress signatures.

When a vulnerability is published for a popular plugin, thousands of sites can be compromised within hours. The logic is purely statistical: an attacker who masters a flaw on a plugin present on a hundred thousand sites maximizes their return on investment. This is what makes the security posture critical, even for a small business showcase site that thinks it is invisible.

The most frequent attack vectors

The main entry points for a WordPress site are known and documented. Brute force attacks on the login page come first, followed by vulnerabilities in outdated plugins, nulled themes downloaded from pirate sites, and lax server-side configurations.

Add to that the exposed files that should never be public: the readme.html file that reveals the WordPress version, the /wp-content/uploads/ directory that allows free folder browsing, or the XML-RPC entry point that regularly serves as an amplification lever for attacks. A properly conducted external audit detects these structural vectors in seconds.

The cost of a hack for an agency

Beyond the technical damage, a hack costs remediation time, reputation, and sometimes clients. An emergency intervention on a compromised site bills between 500 and 2,000 euros depending on the scope of the cleanup, and does not include the damage to the end client. Conversely, a monthly maintenance contract at 100 or 150 euros that includes monitoring and updates remains more profitable for both parties.

External diagnosis: what an audit reveals without admin access

Information exposed by default

A standard WordPress installation exposes a surprising amount of information by default. The CMS version appears in the source code via the generator tag, in the readme.html file, and sometimes in HTTP response headers. This information lets an attacker target known flaws in this specific version.

Administrator usernames are also exposed via the WordPress REST API on the /wp-json/wp/v2/users endpoint, as well as via the ?author=1, ?author=2 parameters, etc. A bot that collects these names can then launch targeted attacks instead of trying random credentials.

Scanning sensitive folders and files

An external audit systematically checks the presence of files that should never be public. The wp-config.php.bak file, sometimes forgotten after a manual intervention, contains database credentials. The /wp-content/debug.log folder can reveal server paths and PHP errors. Free folder browsing on /wp-includes/ or /wp-content/uploads/ allows an attacker to map the installation.

In audits performed with Orilyt, we regularly observe that nearly one WordPress site in two leaves at least one of these files publicly accessible, without the owner being aware. Detection takes seconds, correction takes minutes.

Login page weaknesses

The /wp-login.php URL is known to all bots. In one night, a site with no protection can endure several thousand brute force login attempts. Shared servers sometimes end up displaying 500 errors simply due to this parasitic load.

An external audit can detect whether the login page is publicly exposed, whether it is protected by attempt limiting, and whether it has a second authentication factor. The complete WordPress audit methodology details the analysis grid applied to this CMS and the specific tests activated on this platform.

Harden the configuration: high-impact actions

Updates as absolute priority

The rule is simple: a plugin, theme or WordPress core that is not updated is a vulnerability waiting to be exploited. Patches published by WordPress and the community constantly fix vulnerabilities, sometimes critical ones. A plugin abandoned by its developer for more than twelve months must be considered dangerous and replaced.

Automatic core WordPress updates have been enabled by default since version 5.6 for minor versions. Extending this logic to critical plugins via dashboard options, or via a line in wp-config.php, drastically reduces the exposure window. Automatic plugin updates carry some risk (possible incompatibilities), but the opposite is statistically worse.

Passwords and authentication

An administrator password of less than twelve characters, without uppercase, numbers or special characters, is crackable in minutes by a standard script. The minimum rule is sixteen characters, ideally generated by a manager like Bitwarden or 1Password. The password manager is a non-negotiable professional tool for anyone managing more than three sites.

Two-factor authentication (2FA) adds a very effective defensive layer. Enabled via a lightweight plugin like Two Factor or Wordfence Login Security, it blocks nearly all brute force attacks, even if the password ends up compromised elsewhere.

File permissions and the database

Correct Unix permissions for a WordPress site are 644 for files and 755 for folders. The wp-config.php file should be 600 or 640 to limit access to server entities only. Lax permission configuration, like a 777 inherited from a botched migration, opens the door to arbitrary PHP file modification by a malicious script.

On the database side, the default wp_ prefix is known to all attackers and facilitates targeted SQL injections. Changing it to a random prefix at install time, or via a migration plugin later, complicates the work of automated scripts without performance impact.

Backups as safety net

No security is perfect, and regular backup remains the last line of defense. A 3-2-1 strategy remains the reference: three copies of the data, on two different media, including one off-site copy. Serious hosts offer automatic daily backups, but an independent backup stored with another provider (S3, Backblaze, OVH Object Storage) is insurance against compromise of the host itself.

UpdraftPlus, BackWPup or Duplicator are the reference plugins to automate this kind of backup. Their configuration takes ten minutes and can save a day of work the day a client calls in panic.

The network layer: HTTP headers and HTTPS

HTTPS and systematic redirection

A site without HTTPS in 2026 is unacceptable. Beyond exchange encryption, the absence of a valid SSL certificate triggers a Chrome warning that drives visitors away. All hosts now offer Let's Encrypt for free, and setup takes five minutes via cPanel or an equivalent panel.

Systematic redirection from HTTP to HTTPS must be configured at the server level (htaccess for Apache, nginx configuration) and not only via WordPress. A poorly configured .htaccess file sometimes leaves the HTTP version accessible on some URLs, which exposes session cookies to sslstrip-type attacks.

HTTP security headers

HTTP security headers are an underused defensive layer. Strict-Transport-Security (HSTS) forces the browser to use HTTPS for all future requests, even if the user types an HTTP URL. Content-Security-Policy (CSP) limits the sources of allowed scripts and blocks XSS injections. X-Frame-Options prevents the site from being included in an external iframe, protecting against clickjacking attacks.

For a detailed analysis of each header and the recommended values on Apache and nginx, the dedicated article on HTTP security headers covers concrete configuration and the classic pitfalls of production deployment.

Web application firewall and CDN

A web application firewall (WAF) filters malicious requests before they reach WordPress. Cloudflare offers a free WAF in its basic plan, enough to block most automated attacks. Sucuri and Wordfence offer WAFs more specialized for WordPress, with rules dedicated to common CMS vulnerabilities.

The secondary benefit of a CDN is static caching that absorbs traffic spikes, including malicious spikes. A site protected by Cloudflare remains accessible even during a moderate DDoS attempt, which is a concrete commercial argument for an e-commerce client.

Continuous monitoring and detection

Logs and anomaly detection

Once the site is hardened, monitoring takes over. Server logs reveal intrusion attempts, suspicious PHP errors, accesses to files that should not exist. On shared hosting, log access generally goes through cPanel or an equivalent panel. On a VPS, the /var/log/apache2/access.log and error.log files are consulted in SSH.

A plugin like WP Activity Log records all actions performed in the WordPress dashboard (user creation, file modification, plugin installation) and allows suspicious activity to be detected quickly. This is particularly useful for multi-user sites where several people have administrator access.

Automated alerts

Manual monitoring does not work at the scale of a portfolio of several client sites. Setting up automated alerts on critical changes (expiring SSL certificate, outdated WordPress version, vulnerable plugin, login page suddenly receiving an abnormal volume of attempts) is the only industrializable approach.

Orilyt generates monthly alerts on the evolution of the security posture of each monitored site, with a readable client report that summarizes resolved points, ongoing points, and recommendations for the following month. This automation frees the freelancer or agency from manual daily monitoring.

Post-incident verification

If a site has been compromised, the procedure does not stop at cleanup. You must verify that all administrator users are legitimate, regenerate the SALT keys in wp-config.php, change all passwords (WordPress, FTP, database, host), and scan the entire site. A complete post-incident verification generally takes four to eight hours and must be documented for the client.

Turn securing into a commercial argument

The client report as a sales tool

An audit that translates into an unreadable PDF full of jargon generates neither trust nor a signature. The readable client report, structured in facts, impacts and actions, is what allows a technical recommendation to be turned into a business decision. A client who understands that their readme.html file exposes the WordPress version, and what this concretely implies, more easily signs a remediation quote.

To dig into the conversion of an audit into a recurring mission, the WordPress maintenance contract article details the clauses to integrate to structure a profitable and defensible offer in front of the client.

Automatic quote from the audit

Moving from audit to quote is often the step that loses the most time. Each failed test must be translated into a service line item understandable by a decision-maker, with an estimated effort and a price. An automatic quote generated directly from the audit report reduces this delay to a few minutes instead of several hours, and that is the main lever to turn an audit into a maintenance contract without letting the prospect cool off.

That is the difference between an agency that closes a security file in 24 hours and one that lets it drag on for a week, while the client signs elsewhere. Response speed is a documented conversion factor in B2B sales.

Monthly follow-up and retention

Once the contract is signed, the automatic monthly report justifies the recurring billing. A client who pays 150 euros per month without ever seeing a deliverable ends up questioning the expense. Conversely, a report that shows applied updates, verified backups and handled alerts makes the value tangible and facilitates renewal.

This retention logic is the main multiplier of a maintenance activity. A client kept for two years brings in much more than a new client signed every quarter, and the acquisition cost is zero. To estimate the right plan based on your portfolio, compare Orilyt pricing against the volume of sites you manage.

Securing a WordPress site is not a one-time project but a continuous process that combines initial hardening, monitoring and reporting. A freelancer or agency that structures this approach across the entire portfolio gains credibility with clients, profitability through recurring maintenance, and peace of mind through early incident detection.

The read-only external audit remains the simplest entry point to start. It requires no admin access, no installation, no risk to the site, and provides in minutes the complete mapping of points to fix. It is also the basis of an honest commercial conversation with a prospect who does not yet know you.

Your most frequent questions

Sources and references

• W3Techs, Usage Statistics of Content Management Systems — CMS market share statistics across the global web.
• OWASP, WordPress Security Implementation Guideline — reference for WordPress security best practices.
• MDN Web Docs, HTTP Strict Transport Security — official documentation of the HSTS header.
• CNIL, Website Security — security recommendations from the French CNIL for websites.
• Cloudflare Blog, Web Application Firewall — technical articles on web application firewalls.