WordPress Security Hardening for UAE Business Sites: A Practical Checklist

Hardening is a one-time pass over your WordPress site's launch settings — done once, verified, and revisited only when something changes. It is not a guarantee: WordPress's own guide frames security as risk reduction, not risk elimination. The pass closes the doors standing open — shared logins, the file editor, the reachable configuration file — so attackers must work far harder. Each step below says where it is changed and how to prove it took effect.

The short answer: the hardening checklist, in order (table)

The problem: compromises enter through defaults nobody changed

Most UAE SME WordPress sites were installed quickly — by a freelancer, a previous agency, or a one-click installer — and nobody revisited the defaults: the guessable username, an editor that can rewrite site code from the dashboard, a configuration file holding the database password.

Compromise through these doors is quiet: the first visible sign is often a Google warning in search results, spam pages under your domain, or a host suspension notice — weeks after entry.

Before you change anything: a read-only review of code, accounts and updates

Start by looking, not changing. Open Site Health and note what it flags. List every user account and mark which you recognise. Have core files checked against the official release — a file-integrity check flags any that differ.

Note what is out of date, and confirm a restorable backup exists before touching settings — the plan itself belongs to our guide to a website backup and disaster recovery plan; here it is the prerequisite. If you find accounts or files nobody recognises, stop: that is no longer hardening — see the compromised-site section below.

Accounts and logins: unique admins, 2FA, least privilege, login limits

Give every person their own account; administrator logins belong to one human each — a shared "admin" login means a shared password, no accountability, and nothing to revoke when someone leaves. Replace any account called "admin" — easily guessed usernames are attacked first. Delete dormant accounts outright.

Set strong, unique passwords in a password manager, and turn on two-factor authentication for every admin and editor — the highest-value step here, because a stolen password alone no longer opens the dashboard. Apply least privilege: editors edit, shop managers manage the shop, only maintainers hold administrator. Limit login attempts so guessing gets locked out.

Lock the dashboard: disable the file editor and unused features (XML-RPC)

The dashboard's theme and plugin editor lets an administrator edit the site's PHP from a browser — and, as the guide puts it, it is often the first tool an attacker uses after logging in, because it allows code execution. Disable it with one line in wp-config.php — define( 'DISALLOW_FILE_EDIT', true ); — equivalent to removing all users' edit capabilities. Real code changes belong in proper file access.

Review XML-RPC the same way: the old remote-publishing interface still accepts login attempts. If nothing you use needs it — check first, as some app and third-party connections rely on it — turn it off at server or plugin level.

Protect the files: wp-config.php, permissions and PHP in uploads

wp-config.php holds your database credentials and security keys, and must never be readable over the web. On Apache, the guide's rule denies all web access to it; other servers have an equivalent — ask your host to confirm. Set its permissions tighter: readable only by the server process, in the 400–440 range.

For everything else, use the guide's scheme: directories at 755, files at 644, nothing world-writable. Block PHP execution in uploads — they serve images and documents, never code — and switch directory listing off. If the salts in wp-config.php were never set, generate fresh ones; replacing them logs everyone out, so pick your moment.

HTTPS and security headers — including the two to add carefully

Force HTTPS site-wide, admin included, so logins and form submissions are never sent unencrypted. Warnings or mixed-content errors after forcing it are faults, not hardening — our guide to HTTPS problems, mixed content and expired certificates covers fixing them.

Add the low-risk headers next: X-Content-Type-Options (nosniff), frame protection (X-Frame-Options or frame-ancestors) against clickjacking, and a Referrer-Policy limiting what leaks to third parties. Treat two others carefully. HSTS makes browsers refuse plain HTTP — enable it only once HTTPS works flawlessly everywhere, because browsers enforce it even if you roll back. A Content Security Policy copied blindly can break checkout and payment tools: build it with your developer, run report-only mode, then enforce.

Delete what you don't run: unused plugins, themes and old installs

Deactivated code still sits on the server, and the guidance is blunt: if you are not using a plugin, delete it. Delete unused plugins rather than deactivating them, remove themes you do not run — keep the active theme plus one current default as fallback — and clear out old test installs and forgotten subfolder copies.

Which borderline plugins stay, merge or get replaced is covered in our WordPress plugin audit. Here: if nobody can say what unused code is for, it goes.

Watch it afterwards: file-change, login and vulnerability alerts

Hardening without monitoring is a locked door nobody checks. Turn on alerts for what matters: changes to core or plugin files, failed-login spikes and lockouts, new administrator accounts, and vulnerability disclosures affecting plugins you run.

Verify the site in Google Search Console for security-issue notifications. Keep the safe layer current — automatic minor and security updates are part of staying hardened; the full weekly cadence is the WordPress maintenance routine covered next door. If the site collects customer data, keep the access list short and documented, as our website handover and ownership checklist sets out.

Verify the pass: how to prove each step actually took effect (checklist)

Do not trust the checklist — test it. Log out and back in: two-factor should challenge every admin. The theme and plugin editors should be gone from the menus. Try opening your wp-config.php address in a browser: it should be refused, not displayed or downloaded. Ask your host to confirm the uploads rule with a test file and spot-check permissions against 755 and 644.

Confirm the padlock, no mixed-content warnings, and your headers in the browser's developer tools. Submit your forms and, on a store, complete a test checkout — hardening that breaks payments is a fault, not a finish. Record the date and results in your site documentation.

If you are already compromised, this is not the article — do this instead

If you already have spam pages, redirects you did not create, a Google security warning, or unrecognised accounts and files, hardening locks the problem in. Stop, install nothing new, and follow a recovery process: our guide to hacked WordPress site recovery steps covers containment, cleanup and re-securing. Return here afterwards — a cleaned site gets hardened before normal duties resume.

Common mistakes

• Deactivating unused plugins instead of deleting them.
• One shared "admin" account, no two-factor.
• Copying a CSP from a tutorial and breaking checkout.
• Enabling HSTS before HTTPS works perfectly everywhere.
• Treating a hidden login URL as a substitute for 2FA and login limits.
• Stacking security plugins that fight each other.
• Changing every setting at once, then not knowing which broke the site.
• Skipping verification, so half the steps never took effect.

FAQ

What is WordPress hardening?

Hardening is a one-time, preventive pass over a WordPress site's launch settings and defaults — accounts, the dashboard editor, wp-config.php protection, file permissions, HTTPS, headers and unused code — closing openings that need no sophisticated attack. It reduces risk; as WordPress's own guide frames it, security is risk reduction, not elimination.

Does hardening mean my site cannot be hacked?

No. Hardening removes the easy entry points — guessed logins, an enabled file editor, readable configuration files, executable uploads — so opportunistic attacks fail and move on. It cannot promise immunity: monitoring, updates and backups still matter — a determined attacker is a different problem from an open default.

Should I disable XML-RPC on my WordPress site?

If nothing you use needs it, yes — it accepts login attempts and is a long-standing password-guessing target. Check first: some mobile apps and third-party connections still rely on XML-RPC. If yours does, keep it and rely on two-factor authentication and login limits instead.

What file permissions should WordPress use?

The official Hardening WordPress scheme is 755 for directories and 644 for files, with wp-config.php restricted further — readable only by the server process, in the 400–440 range — and web access to it blocked at server level. Nothing on a business site needs world-writable permissions.

How often should I repeat the hardening pass?

The pass is one-time, but re-verify it after structural changes: a hosting move, redesign, new agency or administrator, or a replaced security plugin. Day to day, the recurring update, test and monitoring routine maintains protection.

Want the hardening pass done and verified for you? (CTA)

If your site still runs launch-day defaults and nobody in-house owns wp-config.php, permissions and headers, have the pass done once and verified. WebStackRank builds and rebuilds business websites with defaults set correctly from the start. Start with our website development company in Dubai page, tell us about your site, and expect an itemised proposal within 24 business hours. We will show you which steps were done and how each was checked — with no promise that any site "cannot be hacked", because that promise is never honest.