A brute-force run against WordPress looks like the same request to wp-login.php repeating hundreds of times from one address, usually with a scripted user agent and a response that never changes size. You do not need a security plugin to see it. You need the raw access log, three shell commands, and about five minutes.

I open the access log before any dashboard, because a dashboard tells you what it chose to record and the log tells you what the server received.

The short version

• Log fields are positional. Field 1 is the IP, field 7 is the requested path, field 9 is the status code, field 10 is bytes sent.
• One line means nothing. Two hundred of the same line from one IP inside an hour means everything.
• POST /wp-login.php returning 200 is a rejected attempt. Returning 302 means somebody got through.
• Count before you block, and prefer hardening the endpoint over banning the address — botnets rotate IPs faster than you can write firewall rules.
• Read the rotated files too. Attacks straddle midnight, and the .gz from yesterday holds the half you are missing.

One line, read left to right

Apache and nginx both default to the combined log format. Fields are separated by spaces, and the quoted parts can contain spaces of their own, which is why the request is wrapped in quotes as a single unit.

203.0.113.45 - - [01/Nov/2026:04:12:33 +0800] "POST /wp-login.php HTTP/1.1" 200 4312 "-" "python-requests/2.31.0"

Read it as a sentence. At 04:12 in the morning, an address that sent no referrer and identified itself as a Python script posted to the login form, and the server answered with a 200 and 4,312 bytes. Nothing about that line belongs to a person.

The IP above is from the documentation range, not a live log.

Where the file actually lives

This is the step most people give up at.

cPanel: /home/<user>/access-logs/<domain.com>. It is a symlink to the real domlogs file, and it is readable by your account, which is all you need. The error log sits in ~/logs/. If you are in File Manager rather than SSH, turn on hidden files, because the directory is easy to miss next to the public_html tree.

Plesk: /var/www/vhosts/system/<domain>/logs/. Inside it you get access_log, access_ssl_log, proxy_access_log and the matching error logs. On Plesk, nginx sits in front of Apache and sees the real client IP, so proxy_access_log is the file you want when access_log shows a loopback address.

Plain nginx: /var/log/nginx/access.log, with access.log.1 and gzipped archives beside it. Rotated files end in .gz, so read them with zcat instead of cat — a normal attack runs for hours and will be split across two files.

The four patterns worth naming

Not every 404 is an attack and not every bot is hostile. These four are the ones I act on.

1. The login drumbeat. Hundreds of POST /wp-login.php lines from one address, all 200, all roughly the same byte count. The 200 is the point: WordPress re-renders the form with an error, so a rejected attempt and a served form share a status. Identical byte counts are the giveaway.

2. The 302 that follows. A POST /wp-login.php answered with 302 is a successful authentication — WordPress redirects to /wp-admin/ on success and only returns 200 on failure. If the timestamp is 3 a.m. and the IP is not yours, assume the password is already known to someone else. Rotate it before you do anything else, then run the five-minute infection check.

3. XML-RPC as an amplifier. POST /xmlrpc.php with system.multicall lets a client try hundreds of passwords in a single HTTP request. It barely registers in request counts and hammers the CPU, which is also how small accounts end up suspended for resource abuse. If you do not publish from a desktop client or the WordPress app, turning XML-RPC off removes the whole class of attack.

4. Reconnaissance before the attempt. GET /?author=1 through ?author=9 enumerates usernames. So does /wp-json/wp/v2/users. A scattering of 404s against plugin folders you never installed is somebody running a vulnerability scanner against your site. None of it breaks anything by itself; all of it is a preview of what comes next.

Counting, not squinting

You cannot eyeball ten thousand lines. Three commands answer almost every question I have. Run them from the directory that holds the log.

# top talkers, all traffic
awk '{print $1}' access_log | sort | uniq -c | sort -rn | head -20

# who is hitting the login form
grep 'POST /wp-login.php' access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# bursts: requests per IP per minute
awk '{print $1, substr($4,2,17)}' access_log | sort | uniq -c | sort -rn | head -20

# did anything actually succeed?
awk '$9 == 302 && /POST \/wp-login\.php/ {print $1, $4}' access_log

The third command separates a bot from a person. A visitor loads a page, an image, a script, then leaves — a handful of requests in a minute, all different paths. An attacker sends the same path over and over. More than a few dozen requests to one endpoint in one minute is not a customer.

Save the output before you change anything. Logs rotate on a schedule you did not set, and the evidence you need for a host support ticket disappears with them.

Blocking it without breaking your own site

Blocking an IP is the weakest option and the one most people reach for first. A credential-stuffing run comes from hundreds of addresses; you can ban them one at a time until you run out of patience. Do the durable things first.

• Rate limit the endpoint at the edge. One rule in Cloudflare — more than a handful of POSTs to your login path per minute from one IP, block for an hour — stops the drumbeat before it reaches PHP.
• Two-factor authentication on every administrator. It converts a successful password guess into a failed login, which is the only fix that survives a leaked password.
• fail2ban on a VPS. A jail watching the Apache or nginx access log for repeated 200s on wp-login.php will ban automatically and expire the ban on its own.
• .htaccess as a last resort. If you must deny an address by hand, wrap the rule so you do not wipe out normal access, and whitelist yourself first.

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

On cPanel, the IP Deny Manager does the same thing with a form. Either way, add your own address and your uptime monitor to the allow list before you add anything to the deny list, or you will lock yourself out of the admin you were trying to protect. If the log already shows a 302, the ban is housekeeping — change the password, check for new administrator accounts, and treat the site as compromised until you have looked.

Ten minutes, the next time you get an alert

1. Open the access log, not the dashboard.
2. Run the top-talkers command and look for one address far ahead of the rest.
3. Grep the login path and count per IP.
4. Check for any 302 on a login POST. If it exists, rotate the password now.
5. Check POST /xmlrpc.php traffic and disable XML-RPC if you do not use it.
6. Look for ?author= sweeps and /wp-json/wp/v2/users requests.
7. Read yesterday’s .gz log for the same address.
8. Only then add a block, and only after you have hardened the endpoint.

Do one thing today: run the top-talkers command on your busiest site and write the normal number down. You cannot recognise abnormal traffic until you have seen a quiet day. For the logs that matter when something breaks rather than attacks, this is the map I use.

Your WordPress site is slow because one layer is doing the damage, and you probably have not found which one yet. The speed fixes people reach for first — an image plugin, a caching plugin, a theme swap — often target a layer that is not the problem. Measure, fix the slowest layer, change one thing, re-measure.

I run two sites on shared hosting and one on a VPS. The most useful thing I have learned is that a single number tells you which half of the problem to look at.

The short version

• Measure time to first byte before you install anything. It is the one number that separates server-side slowness from front-end weight.
• If TTFB is over a second on a page that is already cached, the problem is hosting, PHP or the database. No front-end trick will fix it.
• Page caching is the biggest cheap win — and the reason a site can be fast for visitors and slow for you.
• Images are usually why a page is heavy, not why it is slow to start.
• Change one thing, re-measure, then change the next. Two at once and you learn nothing.

Measure first, with one command

TTFB is how long your server takes to start answering. Run this three times against your homepage:

curl -o /dev/null -s -w "ttfb=%{time_starttransfer}s total=%{time_total}s\n" https://yourdomain.com/

On shared hosting, a cached page should answer in well under a second. A figure above 1.5 seconds on a page that is already cached means the server is struggling. Then run the same command against a static file on the same host. If the static file is fast and the homepage is slow, WordPress is doing the work. If both are slow, it is the server or the network, and the rest of this article can wait.

Two conditions: log out first, because your own admin session bypasses page caching and will always look slower; and test from elsewhere, since your ISP’s route to the host is not your visitor’s route. How to test your hosting speed properly covers that part.

Layer one: hosting and PHP

If TTFB is high on a cached page, this is where the time is going.

Check the PHP version first: Tools → Site Health → Info → Server. Anything on PHP 7.4 or older is both unsupported and slower than 8.x, and changing it is a dropdown in most control panels. Test on a staging copy if you have one, since an old plugin can break on the newer branch — but that move is worth the risk on its own.

Then look at what your plan actually allows. Shared hosting limits CPU seconds, memory and disk I/O, and when you cross a limit the host throttles you instead of showing an error. A site that is fine at 9am and crawling at 3pm is usually being throttled, not attacked. Check for resource-limit emails and a CPU usage graph in the panel — cheap hosting versus good hosting is about what those limits mean in practice.

If PHP and the limits look sane, ask support two things: whether OPcache is on, and whether the database is local.

Layer two: page caching

A page cache stores the finished HTML so PHP does not rebuild it for every visitor. Done once and properly, it removes most of the load. Done three times, it causes bugs.

• Use one layer. If your host has a built-in cache — LiteSpeed hosts, most managed WordPress plans — turn it on and skip the plugin. Stacking a host cache, a plugin cache and Cloudflare’s HTML cache is how people end up with stale pages and random logouts.
• Exclude what has to stay dynamic: /wp-admin, /wp-login.php, and any cart or checkout page. A rule that bypasses the cache when the logged-in cookie is present is what keeps the admin usable.
• Expect asymmetry. A cached site is fast for visitors and still slow for you while logged in. That is the cache working, not failing.
• Clear it after every change, or you will spend an hour debugging a fix that is already live.

If Cloudflare sits in front of the site, its default static-file cache is the safe setting for WordPress — setting up Cloudflare without breaking a small site covers where that line is.

Layer three: images and front-end weight

Images rarely cause a slow TTFB, but they cause most of the wait after the first byte and they are the easiest layer to fix.

Open the homepage and check total page weight and the largest image. A hero exported at 4000 pixels wide for a slot that renders at 1200 is the most common problem I find on small sites. Resize to the size the theme actually displays and export as WebP or AVIF.

WordPress adds loading="lazy" to images by default since 5.5, which is right everywhere except the image at the top of the page. That one should load immediately — delaying it makes the page feel slower even when the measured numbers improve. Most optimisation plugins let you exclude the first image.

Then fonts and scripts. Every web font is a separate download that blocks text from painting, so two families with four weights is four files before any content appears. If the theme loads a font you cannot see on the page, remove it. Render-blocking CSS and JS are the other half, and the honest fix is usually fewer plugins.

Layer four: plugins and the database

Every active plugin is code that runs on every request, whether or not the page uses it. The reliable way to find the expensive ones:

• Install Query Monitor on a staging copy and open a normal page. It shows the query count, the slowest queries and which plugin caused each one.
• Deactivate plugins in halves on staging, measuring TTFB after each round. You will find the culprit in a few rounds without taking the live site down.

On the database side, the measurement worth taking is autoloaded options — the rows WordPress loads on every single request. In phpMyAdmin:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options WHERE autoload = 'yes';

A few hundred kilobytes is normal. If that number is measured in megabytes, a plugin is stuffing data into the options table and every page load pays for it. Expired transients are the usual offender. Clearing expired transients is safe; deleting rows you do not recognise is not.

Last piece of this layer: WP-Cron. It is triggered by page loads, so on a low-traffic site jobs run late, or several at once on the first visit after a quiet spell — exactly when a visitor notices. A real system cron job on the host is a two-line change.

Symptom, layer, first thing to try

The order I actually work in

Speed work goes wrong when it starts at the bottom of this list. Top to bottom, stopping at the first real improvement:

1. Measure TTFB, logged out, three times, and against a static file as a control.
2. PHP version and host limits — cheapest possible fix, biggest possible jump.
3. One page cache, with the admin and login paths excluded.
4. Images and fonts — dimensions before compression, and never lazy-load the top image.
5. Plugin audit on staging with Query Monitor in hand.
6. Database hygiene — autoloaded options, expired transients, a real cron.

Now the part that saves the most time: write the before number down. Every change feels faster, especially one you spent an hour on. A number on a note is the only thing that tells you whether the caching plugin did anything at all.

Today, do one thing: run that curl command against your homepage three times, logged out, and write the three TTFB numbers down. Under a second, and your next hour belongs to images and fonts. Over one and a half seconds on a cached page, and it belongs to hosting and PHP — no plugin in the directory will change that.

You can harden wp-login.php with things WordPress and your server already give you: a long unique password per admin, XML-RPC switched off, login attempts rate-limited at the CDN or firewall, and the public user list closed. A security plugin mostly packages those same steps and adds alerting and file scanning on top. Here’s the order I do it in, with the settings and the one snippet I actually use.

The short version

• Password first. A generated 20-character-plus password on every admin account, stored in a password manager, removes most of the value of an automated login attack.
• Take away what you don’t use: XML-RPC, incoming pingbacks, and the public list of usernames.
• Rate-limit wp-login.php at the edge — CDN, WAF, or host firewall — not inside PHP.
• Add a real second factor. WordPress core has none, and I won’t pretend otherwise; that step needs either a small plugin or an identity provider in front of the login.
• Put monitoring where you’ll see it. A blocked attack you never hear about is fine. A successful one you never hear about is not.

1. Fix the accounts before you touch the login page

Login hardening does nothing if there are five admin accounts and nobody remembers what two are for. Open Users → All Users, filter by Administrator, and be honest about each one:

• Delete or downgrade anything you don’t recognise. A dormant admin account is a back door with a password you never changed.
• One admin per human. Writers and editors don’t need Administrator — Editor can publish, and it can’t install plugins.
• Change any password that’s a word, a date, or used on another site. Let the password manager generate it; you should never need it in your head.
• Check the admin email while you’re in there — password resets land in that inbox, so it has to be one you read.

If you have WP-CLI, wp user list --role=administrator --fields=ID,user_login,user_email,user_registered gives you the same list in one line, which is faster on a site you inherited.

2. Turn off the parts of the API you’re not using

WordPress exposes more than the login form. Three things get abused over and over:

• XML-RPC. One request can carry hundreds of username/password pairs — the favourite amplifier for guessing — and it’s how incoming pingbacks arrive. If you don’t publish from a desktop app, you don’t need it.
• The REST user list. /wp-json/wp/v2/users answers with your authors’ usernames, which turns “guess a password” into “guess a password for a name I now know”.
• Author archives by ID. ?author=1 redirects to the author’s archive, and the slug in the URL is the login name.

Drop this into login-hardening.php inside wp-content/mu-plugins/, creating the folder if it isn’t there. Must-use plugins load automatically — no activation, and nobody can switch them off from the admin.

<?php
/*
Plugin Name: Login Hardening
Description: Disables XML-RPC, restricts the users endpoint, stops author-ID probing.
*/

// Incoming XML-RPC (and therefore pingbacks) off.
add_filter( 'xmlrpc_enabled', '__return_false' );

// /wp-json/wp/v2/users only answers for people who can list users.
add_filter( 'rest_endpoints', function ( $endpoints ) {
    $routes = array( '/wp/v2/users', '/wp/v2/users/(?P<id>[\d]+)' );
    foreach ( $routes as $route ) {
        if ( empty( $endpoints[ $route ] ) ) {
            continue;
        }
        foreach ( $endpoints[ $route ] as $i => $handler ) {
            $endpoints[ $route ][ $i ]['permission_callback'] = function () {
                return current_user_can( 'list_users' );
            };
        }
    }
    return $endpoints;
} );

// ?author=1 stops redirecting to a login name.
add_action( 'template_redirect', function () {
    if ( is_author() && isset( $_GET['author'] ) ) {
        wp_safe_redirect( home_url(), 301 );
        exit;
    }
} );

This restricts the users endpoint rather than deleting it, because the block editor calls that route to render the author dropdown. If something else breaks afterwards — a newsletter plugin that lists authors, a mobile app — remove the specific block, not the whole file.

3. Rate-limit at the edge, not in PHP

A limiter written in PHP still boots WordPress, loads plugins, and opens a database connection for every attempt — exactly the work an attacker wants. Push the limit out to whatever sits in front of the site:

• Behind a CDN (Cloudflare and similar): a rate-limiting rule where the URI path equals /wp-login.php, a handful of requests per minute per IP, action block for an hour — or challenge, if you’d rather not hard-block shared IPs.
• No CDN: ask your host whether login rate limiting and fail2ban are already on. Most cPanel and Plesk stacks can block an IP after repeated failed logins, and the IP Blocker tool handles repeat offenders by hand.
• Apache with mod_security: a rule scoped to POST requests on wp-login.php costs nothing and never touches your theme.

Keep the threshold generous: five attempts a minute per IP stops a script and lets a person who mistyped three times through. And never block /wp-admin/ as a whole — admin-ajax.php lives there.

4. Hiding the login path is worth doing, but it isn’t a control

Moving wp-login.php to another URL cuts log noise, because generic bots only try the default path. It stops nobody who has decided to target you: they read your homepage and find the new link. Treat it as tidying, not security.

The version that is security: put a real authentication gate in front of the login. Cloudflare Access on /wp-login.php and /wp-admin/ means only the identities you list can see the form at all, and the WordPress password becomes the second lock rather than the only one. Without a CDN, the hosting panel’s “Password Protect Directories” does the same with one shared password — fine solo, wrong for a team.

Whichever you choose, test it the boring way: log out, open a private window, get back in, then confirm comments and contact forms still post.

5. What a plugin adds on top

I do run a security plugin on client sites, for concrete reasons: core has no two-factor login, no record of who tried to log in, and no way to tell you a file changed. Here’s how I split what needs code from what can be settings.

If you install one, install exactly one: two firewalls fighting over the same request is how a site locks its owner out of admin-ajax.php. And a plugin is code — update it, remove it the day you stop using it.

6. Watch the one log line that tells you it happened

Every login attempt reaches your web server before WordPress sees it, so the access log is the honest record. Look for POST requests to wp-login.php: a wall of them from one address is a guessing run, and a 200 in that column instead of a 302 means somebody got in. Compare yesterday’s count with today’s.

Whatever you set up, make sure a change leaves a trace you’ll read — a rate-limit block notification, a host alert, or a weekly glance at the log. Catching it early is the difference between changing a password and working through a full infection check. If you’re already past that point, the steps are in my write-up of cleaning a hacked site — and get a working copy before you edit files, per what to back up and how to test a restore.

Checklist

• Administrator list reviewed; unused admins deleted, writers moved to Editor
• Every admin password generated by a password manager, none reused
• Admin email is one you control and read
• login-hardening.php in mu-plugins; site and block editor still load
• Rate-limit rule on /wp-login.php at the CDN or host firewall
• Second factor added, or an access gate in front of /wp-admin/
• Login tested in a private window, plus one form that uses admin-ajax.php
• One place where failed logins and file changes will actually reach you

Do the first three today — twenty minutes, start to finish: change the admin password, add the rate-limit rule on /wp-login.php, and drop the mu-plugin in. Then log out, log back in, publish a test draft, delete it. If that works, the biggest hole on the site is closed without a new plugin.

Back up two things: the database and wp-content. Everything else on a WordPress install can be downloaded again. Back up daily if the site changes daily, keep at least one copy off the hosting account, and test a restore on a copy before you actually need one — an untested backup is a guess, not a backup.

I learned this the boring way. The one time a fix took a full day instead of ten minutes, the backup existed — it just would not restore, because nobody had ever opened it.

The short version

• Database first. Posts, pages, users, settings, plugin options, menus and widget assignments all live there.
• wp-content second. Uploads, themes, plugins, mu-plugins. Custom code lives here and cannot be re-downloaded.
• Frequency follows how much work you would redo — not a number someone told you.
• One copy must live off the server. A snapshot inside the same hosting account dies with the account.
• Schedule a restore drill. Quarterly is enough for a small site, and it takes about twenty minutes on a copy.

What actually needs to be in the backup

The database is small and changes constantly; the files are large and change rarely. Treat them separately, because that difference decides your schedule and your storage bill.

In the database, the tables that matter are wp_posts (posts, pages, revisions, and the rows that define menus), wp_postmeta (custom fields — page builders store their entire layout here, so a database-only restore brings the layout back but not the images it points to), wp_users and wp_usermeta (logins and capabilities), wp_options (site URL, active plugins, cron schedule, theme settings), and the term tables that hold categories and tags. Plugin tables use their own prefixes and are easy to forget — a shop’s orders may sit in tables a “posts only” export never touches.

In the files, wp-content/uploads is usually the bulk of it, and it is also the part people most often exclude by accident. wp-content/themes and wp-content/plugins can mostly be re-downloaded, except for the child theme you edited and the plugin you patched by hand — those are original work and belong in the backup. wp-content/mu-plugins must always be included; it loads automatically, which is exactly why malware likes to hide there. I covered that pattern in the five-minute infection check.

Two files outside wp-content are worth the extra ten seconds: wp-config.php (database name, user, password, table prefix, and the security salts — losing the salts logs every user out) and .htaccess (redirects and caching rules that a plugin or your host wrote for you). The wp-config constants are covered in the seven settings I change on every new site.

How often you should back up

Ask one question: if the site died right now, how much work would I be willing to redo? That answer is your interval. A blog that publishes twice a week does not need a database dump every hour, but it does need one before every plugin update, because that is when things actually break.

My default for a small site:

• Database: daily. It is small — usually a few megabytes — so there is no reason to be stingy.
• Files: weekly, plus a manual snapshot whenever I install something new or edit a theme file.
• Before anything risky: a manual backup with a name I will recognise, like before-woo-9-update. Updates, migrations, search-replace operations and malware cleanup all qualify.

Retention matters as much as frequency. I keep a rolling window — daily for a week, weekly for a month, one monthly kept a year — because some damage is silent. A hacked file can sit unnoticed for weeks, and by then every recent backup already contains it.

A hosting-provider snapshot is not the same as your own backup. Snapshots are fast and I use them, but they live in the same account — if the account is suspended or deleted, the snapshot goes with it. In my hacked-site recovery, the host’s copy was useful but not sufficient.

Where the backup should live

Keep three copies, on two different kinds of storage, with one of them off-site. That is the whole rule; everything else is detail.

Practically: one copy on the server for fast restores, one on your own machine, one in cloud storage you control. If the backup holds user data, encrypt it — a dump with email addresses and password hashes does not belong in a public bucket.

Two places a backup must never live: inside wp-content (a hack cleanup or a careless migration deletes that folder, and some server configurations will happily serve the archive to anyone who guesses the filename), and only in the same hosting account you are trying to protect yourself from.

There is also a boring test that catches more problems than any checklist: download a backup and open it. If pulling the file takes hours or the archive refuses to open, you do not have a backup. You have a file with a hopeful name.

Taking a backup you can actually restore

On shared hosting, use the host’s own backup tool first — it knows where the database is and it produces an archive you can download in one click. Then keep a second, independent copy through a plugin that ships to remote storage, or by hand if you have SSH access.

If you have WP-CLI, the whole job is three commands:

# 1) Database — dump every table, with DROP statements so it can overwrite cleanly
wp db export ~/backups/db-$(date +%F).sql --add-drop-table

# 2) Files — wp-content plus config, skipping caches and old archives
tar -czf ~/backups/files-$(date +%F).tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/updraft' \
  --exclude='wp-content/ai1wm-backups' \
  wp-content wp-config.php .htaccess

# 3) Pull both copies off the server
scp user@host:~/backups/*-$(date +%F).* ./backups/

Without SSH, the same result comes from cPanel’s Backup tool plus phpMyAdmin: export the database with the “Add DROP TABLE” option enabled, then zip wp-content in File Manager. It is slower, but it works, and slow beats absent.

Whatever route you take, check the excludes. The most common silent failure I have seen is a backup job that skipped wp-content/uploads to save space, so the restore brought back every post with a broken image. Back up uploads separately at a lower frequency instead.

Test the restore, not just the backup

A backup is only proven when it has been restored once. Do it on a copy — a subdomain, a spare folder, or a local install — never on the live site. Twenty minutes, once a quarter:

1. Create a clean target. New database, new directory, nothing shared with production.
2. Import the database dump and unpack the files into the new directory.
3. Point wp-config.php at the new database. If the domain differs, update the siteurl and home rows in wp_options, then run a serialised-safe search-replace so internal links stop pointing at the live domain. Do not do this with a plain text editor on a dump — serialised data breaks silently.
4. Open the site and log in. Check the homepage, one post with images, the media library, permalinks (resave them if 404s appear), and the one plugin the business depends on.
5. Write down the date and anything you had to fix. If the restore failed, you have just found out at the cheapest possible moment.

That drill is also how you discover that your backup excludes were wrong, your archive was truncated, or your plugin’s remote storage credentials expired months ago.

The checklist I actually use

• Database dumped daily, with DROP statements, all prefixed tables included.
• wp-content archived weekly, uploads and mu-plugins included.
• wp-config.php and .htaccess saved alongside it.
• No backup archives stored inside wp-content.
• At least one copy off the hosting account, encrypted if it holds user data.
• A manual snapshot before every update, migration or cleanup, with a dated name.
• A restore tested on a copy this quarter, with the result written down.

The next time you touch this site, take one manual backup first and time how long the download takes. If it is slower than you expected, or the archive will not open, you have found your real problem before it found you.

I install WordPress on a fresh domain a few times a year, and the first thirty minutes decide whether the site is easy to run or a slow pile of annoyances. These are the seven settings I change before I write a single post, in the order I change them. None of them needs a plugin, and all of them are reversible except permalinks — which is exactly why permalinks go first.

The short version

• Permalinks to /post-name/, set before any content exists.
• Time zone and admin email set to something you actually use.
• The “discourage search engines” box checked, then unchecked — and checked again after every migration.
• Comments closed on old posts, pingbacks and trackbacks off.
• File editor disabled and revisions capped in wp-config.php.

1. Permalinks: decide once, before you publish

Settings → Permalinks → Post name. A fresh install defaults to a date-based structure, which is fine for a diary and bad for everything else: the URL carries the month, the day, and no words anyone would search for.

The reason this is step one is that changing it after publishing is the only item here that breaks things: every old URL returns a 404 unless you redirect it, and every link you posted elsewhere stops pointing at the right page.

If the site is already live, change it deliberately: change the structure, then add a redirect from the old pattern. WordPress does that for slugs, not for a permalink change.

2. General: the time zone and the mailbox nobody reads

Settings → General. Three fields matter and two of them get ignored on nearly every install I look at.

• Timezone. Pick your city, not UTC. If you schedule posts, WordPress converts your publish time to UTC and back; a wrong zone means a 9am post goes out at 5pm, and you spend ten minutes convinced the scheduler is broken.
• Administration Email Address. This is where password resets, new-user notices and critical-error recovery links go. Use a mailbox on the domain that you check, not a personal address you set in 2019 and no longer open.
• Site title and tagline. The tagline is not decoration — most themes print it under the logo, and “Just another WordPress site” tells a visitor you did not finish setting up.

While you are here, set the date and time format to something unambiguous. 03/04/2026 means two different days depending on who is reading.

3. Reading: the checkbox that quietly costs you months

Settings → Reading → Search engine visibility. “Discourage search engines from indexing this site” should stay unchecked on production. On a staging copy or a site you are rebuilding, it should be checked.

The failure mode is always the same: you build on staging, launch, and forget. The site looks perfect from your browser because you are logged in and looking at it directly. Google sees a page that asks politely not to be indexed, and six weeks later you are writing forum posts about having zero impressions.

So I check it twice — once during setup, once after any DNS or host change. It takes ten seconds and it is the single most consequential checkbox in the admin.

4. Discussion: close the doors you are not watching

Settings → Discussion. Comments on a small site attract two kinds of traffic: real readers, and bots that found a 2019 post about nothing. The settings that help:

• Uncheck Allow link notifications from other blogs (pingbacks and trackbacks). They are almost entirely noise on a small site, and they are a known way to get junk anchors onto a page.
• Set Automatically close comments on posts older than 14 days. Old posts are where the spam lands, because nobody is reading the moderation queue for them.
• Tick Comment must be manually approved for first-time commenters, and untick nested comments beyond two levels deep if your theme handles them badly.

If you do not want comments at all, uncheck “Allow people to submit comments on new posts” — but do it in the same sitting, because that checkbox lives on this page and nowhere else.

5. Media: stop generating image sizes nobody will use

Settings → Media. Every upload generates several resized copies before you ever insert it. On a site that publishes screenshots and diagrams, that adds up quietly in disk space and in backup size.

My numbers: thumbnail at 300×300 cropped, medium maxed at 768, large maxed at 1200. Those cover a card, a body image, and a full-width image on the layouts I use. Anything larger I upload deliberately, and WordPress makes a “scaled” copy of very large images anyway.

Two habits that go with it: rename the file before uploading (wordpress-permalinks-settings.png, not screenshot-2026-10-23-at-11.04.12.png), because the filename becomes part of the URL and the default alt text; and compress before upload instead of relying on a plugin.

6. wp-config.php: four constants worth typing by hand

This is the only step that is not a screen in the admin. Edit wp-config.php over SFTP and add these above the line that says That’s all, stop editing:

define('DISALLOW_FILE_EDIT', true);   // no theme/plugin editor in the admin
define('WP_POST_REVISIONS', 10);      // cap revisions instead of unlimited
define('WP_DEBUG', false);            // never true on a live site
define('WP_DEBUG_LOG', false);        // no wp-content/debug.log on production

What each one buys you:

• DISALLOW_FILE_EDIT removes the editor from Appearance and Plugins. It also means a stolen admin session cannot turn into code execution by pasting PHP into a theme file. The trade-off is real: you now need SFTP to change anything in code, which is the point.
• WP_POST_REVISIONS stops WordPress storing a new row for every autosave. A long editing session on a single post can otherwise leave dozens of copies in the database forever.
• WP_DEBUG and WP_DEBUG_LOG off on production, because a debug log records file paths and errors you do not want sitting in a web-readable directory. Turn them on for an hour when chasing a fatal error, then off again — the log is what tells you why the site broke, and which log to open is a separate problem.

7. Users, plugins, and the sample content

The last pass is cleanup, and it is the pass people skip.

• Delete the sample post, the sample page, and the default comment. They are published, indexed, and linked from your menu otherwise.
• Delete Hello Dolly. Delete any plugin you cannot explain in one sentence, including the ones that came bundled with a theme.
• Create one admin account with a real display name and a password from a manager, and do not use admin as the username — it is the first guess in every brute-force script. If more than one person needs access, give them Editor, not Administrator.
• On the Plugins screen, turn on auto-updates for the plugins you trust. Core minor releases and security releases already install themselves; the plugin list is where the forgotten one lives.

If you inherited the site rather than built it, run the checks in how to check if your WordPress site is infected in 5 minutes before you touch settings — there is no point tidying a site that is already serving someone else’s links. And if yours has already been hit, the recovery sequence I wrote up in my WordPress site was hacked and serving Japanese spam covers the order to do things in.

The 15-minute checklist

Setting	Where	Value I use
Permalinks	Settings → Permalinks	Post name
Time zone	Settings → General	Your city, not UTC
Admin email	Settings → General	A mailbox you read daily
Visibility	Settings → Reading	Unchecked on live
Pingbacks	Settings → Discussion	Off
Comment ageing	Settings → Discussion	Close after 14 days
Image sizes	Settings → Media	300 / 768 / 1200
File editor	wp-config.php	DISALLOW_FILE_EDIT true
Revisions	wp-config.php	10
Debug	wp-config.php	false on production

Do this one now

If you only have two minutes, open Settings → Permalinks and set it to Post name while the site is still empty. Everything else on this list can be fixed later without breaking a link; that one cannot.

Then keep the list somewhere you will find it: the next time you stand up a staging copy, the checkbox in step three is exactly the one that gets left in the wrong position. Settings are cheap to change and expensive to forget.