How to Install & Set Up WordPress Properly

Choose the Right Hosting Infrastructure Before You Install Anything

The server your WordPress site runs on is the ceiling for every performance metric you’ll ever chase. You cannot optimize your way out of bad hosting. We run our clients on NameHero because it uses LiteSpeed web server technology, which handles WordPress traffic significantly faster than the Apache stacks that most budget hosts still use.

Here’s what the server needs to have before you touch WordPress:

• PHP 8.2 or higher. WordPress runs faster on 8.2, and PHP 8.0 hit end-of-life in 2023. Running anything older is a security liability.
• NVMe SSD storage. NVMe drives handle more I/O operations per second than standard SSDs. On a database-driven platform like WordPress, that matters on every page load.
• Server-level caching enabled. LiteSpeed Cache at the server level offloads work before PHP even starts. No plugin replicates this completely.
• A dedicated IP address if you’re on a shared plan. Sharing an IP with a spammy neighbor affects email deliverability and, occasionally, crawl trust.

A 2023 Kinsta study found that a 1-second delay in page load time reduces conversions by 7%. The hosting decision is the first conversion optimization decision you make.

How to Secure the WordPress Installation Itself

Automated bots scan for default WordPress installs within hours of a domain going live. They look for predictable patterns: the default database prefix, the admin username, the standard login URL. Change all three before the site ever sees real traffic.

Change the Database Table Prefix

When your host’s installer asks for a database table prefix, change it from the default wp_ to something unique — we use something like t218s_ for our own site. This prefix is included in every SQL injection attempt that targets the WordPress user table. Changing it costs you nothing and blocks thousands of automated attacks.

Important: this must be done at install time. Changing it after the fact requires a full database search-and-replace and is error-prone. Do it now.

Never Use “admin” as a Username

The default “admin” username is the first thing every brute-force script tries. Create a unique administrator username that isn’t your name, your business name, or anything publicly connected to you. Then create a separate Editor account for day-to-day publishing so your admin credentials never touch routine tasks.

Use a Strong, Unique Password and Enable 2FA Immediately

A 16-character random password and two-factor authentication (2FA) together make brute-force attacks computationally impractical. We configure 2FA using the Two Factor plugin maintained by the WordPress core team. It supports authenticator apps (Google Authenticator, Authy) and hardware keys.

Our WordPress Care Plan includes ongoing security monitoring, including failed login alerts and 2FA enforcement across all user roles.

Configure wp-config.php Before You Do Anything Else

The wp-config.php file is the most powerful configuration file in a WordPress install. Most tutorials skip it entirely. Here are the constants we add to every site we build:

Disable the File Editor

The WordPress admin panel includes a built-in file editor for themes and plugins. If an attacker gets admin access, this editor gives them direct code execution on your server. One line eliminates it:

define( 'DISALLOW_FILE_EDIT', true );

Set Memory Limits

WordPress’s default memory limit is often too low for modern themes and plugins. Set it explicitly:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Disable xmlrpc.php Access

xmlrpc.php is a legacy WordPress API endpoint that exists for backwards compatibility with old mobile apps and blogging clients. Almost nobody uses it. Attackers use it constantly for brute-force amplification attacks — one request can test hundreds of passwords. Disable it in your .htaccess:

# Disable xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Move wp-config.php Above the Web Root

WordPress will automatically find wp-config.php one directory above the web root. Moving it there means it’s never directly accessible via HTTP, even if your server misconfigures PHP handling on a specific file type.

Point Your Domain and Force HTTPS at the Server Level

HTTPS is not optional. Google has used it as a ranking signal since 2014, and browsers now actively flag HTTP sites as “Not Secure.” Every modern host provides free SSL certificates through Let’s Encrypt.

After installing your SSL certificate, force HTTPS at the server level — not just in WordPress. Add this to your .htaccess:

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Also update your WordPress Address (URL) and Site Address (URL) in Settings > General to use https://. Do this before you add content — changing it later requires updating every internal link and can break media URLs.

Configure WordPress Core Settings the Right Way

Fresh installs ship with defaults that make sense for a demo, not a production site. Go through these in order.

Settings > General

• Set your Site Title — this appears in the browser tab and schema markup.
• Set your Timezone to match your business location. This affects scheduled posts, security log timestamps, and any time-based automation.
• Confirm the Site Address (URL) uses https:// and your chosen www or non-www format. Pick one and stick to it. Both forms resolving to the same URL without a redirect creates duplicate content.

Settings > Reading

• Set your homepage to a static page, not “Latest Posts,” unless you’re running a pure blog.
• Uncheck “Discourage search engines.” This is checked by default on some installs. Forgetting to uncheck it is the single most common reason a new site doesn’t appear in Google.

Settings > Permalinks

Select “Post Name.” This is non-negotiable. The default “Plain” structure produces URLs like /?p=123, which tell search engines and readers nothing. Post Name produces /how-to-install-wordpress-properly/, which does both jobs.

Settings > Discussion

If you’re not actively moderating comments, disable them. Spam comments create index bloat and can introduce thin content issues. Uncheck “Allow people to submit comments on new posts” and set all existing comments to require manual approval.

Users > Your Profile

Set your Display Name to your full name — not your username. The username is what you log in with and should stay private. The Display Name is what appears publicly as the post author.

Build a Zero-Bloat Plugin Stack

Plugin count is not the problem. Plugin quality and overlap are. We’ve seen 8-plugin sites that run faster than 3-plugin sites because the 8-plugin site was carefully chosen. The metric that matters is page weight and database query count — not the number in the Plugins menu.

Here’s the stack we deploy on every Team 218 build:

Notice SEO is handled in code, not a plugin. This is deliberate. RankMath and Yoast are capable tools, but they output markup we don’t fully control, add database overhead, and make it harder to implement custom schema. We handle all meta tags, canonical URLs, and structured data in functions.php directly. Cleaner output, zero plugin dependency, complete control.

Set Up a Child Theme Before You Build Anything

If you build your site directly in a parent theme and that theme updates, your customizations get overwritten. This is not a hypothetical edge case — it happens on every theme update cycle.

A child theme inherits everything from the parent and lets you make changes safely. In Divi, the child theme also separates your global CSS from the parent’s stylesheet, which makes long-term maintenance significantly cleaner.

Create the child theme directory, add a style.css with the correct Template: header pointing to the parent theme, create a minimal functions.php that enqueues both parent and child stylesheets, and activate it. Build everything from that point forward in the child theme.

We use the child theme’s functions.php as the home for all custom PHP — the SEO engine, schema output, performance cleanup, and viewport override. Nothing goes in the parent theme. Ever.

Final Hardening Steps Before Going Live

With hosting, installation, and configuration done, run through this checklist before you build a single page:

• Disable directory browsing. Add Options -Indexes to your .htaccess. Without this, anyone can browse your /wp-content/uploads/ folder directly.
• Protect wp-config.php in .htaccess. Add rules to deny direct HTTP access to wp-config.php and .htaccess itself.
• Set correct file permissions. Directories should be 755, files should be 644, and wp-config.php should be 440 or 400.
• Remove the WordPress version number from the head. It’s publicly discoverable and tells attackers which version-specific exploits to try. One line in functions.php removes it: remove_action('wp_head', 'wp_generator');
• Add security headers in .htaccess. At minimum: X-Content-Type-Options, X-Frame-Options, and Referrer-Policy.
• Delete unused themes. Inactive themes still have files on the server. If one has a vulnerability, it can be exploited even while deactivated. Delete everything except your active child theme and its parent.

Five WordPress Setup Mistakes That Will Cost You Later

After a decade of setups and a fair number of rescue projects, these are the ones we see most often:

1. Building on a Shared IP Without Checking the Neighborhood

Your shared hosting neighbors share your IP. If one of them is sending spam, your domain’s email reputation inherits that problem. Check your IP’s reputation at MXToolbox before launch. A dedicated IP costs a few dollars per month and eliminates this risk entirely.

2. Skipping the www vs. non-www Decision

Both https://domain.com and https://www.domain.com are separate URLs to Google. If both resolve without a redirect, you’re splitting your link equity between two versions of your site. Pick one, redirect the other, and set your canonical URLs accordingly from day one.

3. Installing a Page Builder Before Setting Up a Child Theme

We see this constantly. Someone installs Divi, builds 20 pages, then asks us why their customizations broke after a theme update. The child theme has to come first. There’s no clean way to retrofit it after a site is built.

4. Using an SEO Plugin to Handle Something functions.php Should Own

SEO plugins are designed for general use. They make decisions about your markup that may not match your specific situation. Custom schema, conditional canonical logic, and page-specific robots directives are cleaner in code. We’ve rebuilt sites from plugin-generated chaos that could have been avoided with 200 lines of PHP.

5. Treating the Install as the Setup

This is the big one. A one-click install gives you a WordPress application. It doesn’t give you a production site. Every step in this guide is the difference between the two.

Frequently Asked Questions About Installing WordPress Properly

Do I need managed WordPress hosting or is shared hosting fine?

Shared hosting is fine for a new site with low traffic, provided the host runs LiteSpeed and offers PHP 8.2+. Managed WordPress hosting is worth it once you’re past 10,000 monthly visitors or if you have no in-house technical team.

How long does a proper WordPress setup take?

For an experienced developer following a defined protocol, about 2 to 3 hours to complete everything before building any content. Shortcutting that time is how sites end up with problems that take 20 hours to fix later.

Is it safe to do a one-click install from my hosting control panel?

The one-click install is fine for getting the files in place. It’s not fine as a finished setup. Most hosting installers create a default database prefix, an “admin” username, and no security hardening. Use it to get WordPress installed, then immediately follow the steps in this guide.

Do I really need a child theme if I’m using Divi?

Yes, without exception. Divi updates its parent theme files periodically. Any PHP you add to the parent theme’s functions.php gets overwritten on the next update. The child theme is where all your customizations live.

What’s the minimum PHP version I should accept?

PHP 8.2 at minimum. PHP 8.0 and 8.1 are end-of-life and no longer receive security patches. PHP 7.x is critically outdated — if your host is still offering 7.4 as the default, that’s a signal about how current their infrastructure is overall.

Why do you handle SEO in code instead of using RankMath or Yoast?

Control and cleanliness. SEO plugins add database overhead, output markup we can’t fully customize without overriding them, and create plugin dependencies for something that should be built into the site. Our functions.php implementation produces exactly the meta tags we want, nothing more. We’ve written more about this approach in our Iowa SEO methodology.