Preinstalled.hosting guide

What a Proper WordPress Setup Really Takes, Hour by Hour

A secure, backed-up WordPress installation is roughly five hours and ten minutes of hands-on work for someone who has done it before — installing the software is the fast part; hardening it, wiring up SSL, backups and email deliverability, and surviving the one thing that inevitably breaks are what actually take the time. First-timers should budget closer to eleven hours once forum threads and false starts are counted in. Every one of those hours still has to happen somewhere — either before you place an order, or after.

Published 1 August 2026 · Panomity GmbH

The five-minute install is real. The five-hour setup is what comes after.

WordPress earned its "famous five-minute install" reputation honestly. Download the software, create a database, fill in wp-config.php, run the installer, and a working site appears. That part is genuinely fast, and it's the reason WordPress runs a large share of the web.

What that five minutes doesn't include is everything that makes a site safe to leave unattended: a certificate that renews itself, permissions that don't invite trouble, backups that actually restore, mail that reaches an inbox instead of a spam folder, and the hour you'll spend on whatever breaks the first time regardless. That's the other five hours, and skipping it is exactly how a WordPress site ends up defaced, unreachable after a renewal fails, or quietly not backed up for months.

The hour-by-hour breakdown

This is the same set of six jobs — and the same minute counts — used by the Setup Time Saved calculator on the homepage, at a done-it-before pace. Plug in your own experience level there to see how the total changes.

StepTypical timeWhat actually eats the time
Install & configure45 minDatabase creation, wp-config.php, the installer itself, then picking a theme, setting permalinks, timezone and the handful of settings a fresh install always gets wrong by default.
SSL & renewal25 minRequesting a certificate, pointing DNS, forcing HTTPS in wp-config.php and the server config, and setting up a renewal job so it doesn't quietly expire in 90 days.
Hardening60 minFile permissions, disabling directory listing and unused features, a security plugin or firewall rules, login rate limiting — turning off the defaults that make tutorials easy to write and installs easy to break into.
Backups40 minChoosing a backup method, scheduling it, storing a copy off the server, and — the step almost everyone skips — actually restoring one to prove it works.
Email deliverability50 minSPF, DKIM and DMARC records, plus an SMTP connection, so password resets and order notifications land in an inbox instead of nowhere.
The thing that breaks90 minAverage time lost to a plugin conflict after an update, a renewal that silently failed, or a backup job that was scheduled once and never actually ran.
Total, done-it-before pace310 minAbout 5h 10m. First time through, multiply by roughly 2.2× for forum threads and redone steps — near 11h 22m. Asking a friend runs about 1.6× — near 8h 16m of someone's time, including yours coordinating it.

What "hardened" concretely means

Hardening isn't one setting — it's a short list of specific, checkable things. On a properly hardened WordPress install, all of the following are true:

  • File and directory permissions are set correctly (typically 644 for files, 755 for directories), not left at whatever the upload tool defaulted to.
  • PHP execution is disabled inside the uploads folder, and directory listing is off site-wide.
  • Logins are rate-limited, and two-factor authentication is available for admin accounts — brute-force attempts are the single most common thing hitting a fresh WordPress site.
  • Unique authentication salts are set in wp-config.php, not left as placeholder text.
  • In-dashboard file editing is disabled (DISALLOW_FILE_EDIT), so a compromised admin login can't be used to edit theme or plugin code directly.
  • A web application firewall or a maintained security plugin is in place, and unused features like XML-RPC are switched off rather than left on by default.
  • Core, themes and plugins update automatically for security releases, so a known vulnerability doesn't sit open because nobody was watching the changelog.

None of this is exotic. It's a checklist, and every item on it is skippable in the five-minute installer — which is exactly why so many WordPress sites go live without it.

Do you need staging?

Not always, and it's honest to say so. A brochure site or a blog that changes rarely can usually be tested carefully on the live install, with a good backup as the safety net if something goes wrong. Staging adds its own maintenance job: someone has to keep it synced with the live database and uploads, or it becomes a stale copy that tests nothing real.

Staging starts earning its keep once real money or a real audience is on the line — a WooCommerce store where a broken checkout costs sales every hour it's down, custom code that needs a safe place to fail, or a site updated often enough that "just try it live" stops being a reasonable risk. If you're not sure which side you're on: if a broken homepage for an afternoon would be annoying, skip staging. If it would cost you customers, don't.

A light walkthrough, if you're doing it yourself

Doing this yourself is a legitimate choice — it's the fastest way to actually understand how WordPress hosting works underneath the dashboard. Here's the real order of operations, not a marketing simplification of it:

  1. Provision a server with a current PHP version, MySQL or MariaDB, and a web server such as nginx, Apache or OpenLiteSpeed.
  2. Install WordPress core, then immediately set a strong, unique admin password rather than leaving the installer's suggestion in place.
  3. Point DNS at the server, request a certificate, and force HTTPS everywhere — including inside wp-config.php, not just the server configuration.
  4. Apply the hardening checklist above: permissions, disabled unused features, a firewall or security plugin, rate-limited logins.
  5. Set up scheduled backups stored off the server, and restore one before you trust the schedule to be real.
  6. Configure SPF, DKIM and DMARC records, and route outgoing mail through an SMTP connection instead of the server's default mail function.
  7. Decide whether you need staging using the test above — and if yes, set up the sync workflow now, before you need it under pressure.
  8. Turn on automatic updates and basic uptime monitoring, then leave it alone for a week and see what, if anything, needed attention.

What breaks most often after DIY setups

The failures that actually show up, in rough order of how often they do:

  • A certificate renewal cron that was set up once and silently stopped running, discovered only when a visitor sees a browser security warning.
  • A plugin that conflicts with a theme right after a core or PHP version update — usually the "thing that breaks" line in the table above.
  • A backup job pointed at a folder that got rotated or moved, so it's been "succeeding" against an empty directory for months.
  • Wrong file permissions after a migration or restore, producing a blank white screen with no error message.
  • DKIM records left unrotated after a mail provider changed its signing key, so contact-form and order emails start vanishing into nothing.

The honest price comparison

Managed WordPress elsewhere runs roughly €17–35 per month net at the entry tiers (Raidboxes, as of July 2026) or $35–50 per month for a single site (Kinsta Single plans, as of July 2026). A meaningful part of that is exactly the six hours above, done once, plus someone keeping watch afterward — which is also what pushes the price past a bare-server rate.

preinstalled.hosting's Starter tier is €9.90 per month net (excl. VAT) for one application, already installed, hardened, SSL-secured and backed up on the day you order. Studio covers three apps at €19.90, and Business covers ten at €44.90 — net prices, and the setup hours above are already spent before you log in.

Either way, the six jobs still happen. This page is the honest version of what "install WordPress" actually means. Do it yourself if you want to learn it — that's a real reason. Or skip straight to the part where you write your first post.

Log into a finished WordPress site instead

Order a WordPress instance and get it installed, hardened, SSL-secured, backed up and ready to log into — no five-hour detour. Still deciding which application actually fits what you're building? Choose your app walks through WordPress, WooCommerce, Moodle and Nextcloud in plain language.

Frequently asked

How long does a secure WordPress setup take?

About five hours and ten minutes for someone who has done it before, spread across installing and configuring the software, issuing and renewing SSL, hardening the server, setting up backups, wiring up email deliverability, and losing time to whatever inevitably breaks. First-timers should budget closer to eleven hours once forum threads, wrong turns and redone steps are counted in.

What does hardening include?

Correct file and directory permissions, disabling directory listing and unused features like XML-RPC, a web application firewall or security plugin, rate-limited logins with two-factor authentication, unique authentication salts, disabling in-dashboard file editing, restricting PHP execution inside the uploads folder, and keeping core, themes and plugins on automatic security updates.

Do I need staging?

Not always. A brochure site or a blog that changes rarely can usually be tested carefully on the live site with a good backup as the safety net. Once you are running WooCommerce, custom code, or frequent plugin and theme updates that could break checkout or a paying audience, a staging copy earns its keep — but only if someone actually keeps it in sync.

What breaks most often after DIY setups?

A certificate renewal cron that silently fails until the browser shows a warning; a plugin that conflicts with a theme after a core or PHP update; a backup job that was scheduled once and quietly stopped running months ago; wrong file permissions causing a blank white screen after a migration; and DKIM records that were never updated after a mail provider rotated its signing key, so form emails start vanishing into nothing.