Hosting a WordPress site and launching one are different moments. Hosting means PHP, MySQL, and a preview URL that installs. Launch means the public can use the real domain without mixed content, ugly /?p=123 links, empty backups, or a homepage full of theme demo junk. This is the go-live checklist. For the first-install sequence (zip → DB → installer → domain last), use how to host a WordPress website.

Pre-launch: content and IA

  • Five real pages beat twenty demo sections: Home, About, Services/Product, Contact, Privacy.
  • Remove Hello World / sample comments / lorem modules.
  • Upload compressed images only — image-heavy.
  • Write a privacy-friendly contact path; configure SMTP (no email hosting on WPHost).

Themes and page builders are plugins/tools you chose — designers. Launch does not require a builder.

Permalinks before you advertise the URL

Settings → Permalinks → pick Post name (or another pretty structure) → Save once. Visiting with /?p=123 forever is optional pain. If pretty permalinks 404, re-save permalinks after deploys; do not panic-rewire DNS first.

HTTPS on the real name

  1. Site works on preview HTTPS.
  2. Attach custom domain; wait for certificate — custom domain.
  3. Set WordPress Address and Site Address both to https://your-domain.
  4. Check front and wp-admin for redirect loops.
  5. Fix mixed http:// assets with serialized-safe replace if needed — migrate techniques.

Launching on HTTP “for now” teaches browsers and users the wrong habit. Preview was already HTTPS; the public domain should be too.

Backup before you tell anyone

Install UpdraftPlus (or similar). Run a full backup to off-site storage. Deploy history restores files, not a scheduled WordPress DB backup — SSL and backups. If launch week includes a bad plugin, you want yesterday.

Security minimums at launch

  • Admin username is not admin
  • Password in a manager; 2FA plugin on
  • Unused themes/plugins deleted
  • DISALLOW_FILE_EDIT true on production — setup
  • Skim secure hosting

We do not auto-update. Calendar a post-launch update hour.

Performance: good enough to ship

  • One cache plugin if anonymous traffic matters; exclude logged-in/cart — fast
  • No three minifiers stacked the night before launch
  • Optional Cloudflare with sane rules (no built-in CDN here)
  • Test on phone network

On Pro+, rehearse cache on staging. Shipping without staging is acceptable for tiny brochure sites; less so for Woo — Woo.

SEO and analytics without yak shaving

  • Unique title/description on key pages (one SEO plugin max if you want help)
  • XML sitemap generated; robots not blocking production
  • Analytics only if you will read it
  • Submit the canonical https domain in Search Console after DNS settles

Do not delay launch six weeks polishing schema for a site with no content.

DNS cutover moment

Lower TTL ahead if you can. Flip web records only; leave MX — transfer. Keep old host until you verify. Announce publicly after you see the unique launch string on the custom domain from a network that is not your office Wi-Fi.

Post-launch week

Day 0: monitor forms, TLS, wp-admin login.

Day 1: check backups landed in cloud storage.

Day 3: read PHP/error logs for fatals from real traffic.

Day 7: first update pass on staging if available; production after backup.

Ongoing: cron on Pro+ if schedules matter — managed.

Launch anti-checklist (do not)

  • Do not launch with theme demo blogs still published.
  • Do not leave WP_DEBUG true on public.
  • Do not share admin credentials in chat unencrypted.
  • Do not cancel the old host the same hour as DNS.
  • Do not expect Softaculous, cPanel, nonprofit coupons, or multi-week free trials — plans are $9/$30/$65/$130 — pricing.
  • Do not confuse file deploy rollback with content restore.

Roles: who says “we are live”

For freelancers and agencies, define go-live in the SOW: domain, HTTPS, backup, form test, client UAT sign-off — freelancers, agencies. For solo bloggers, live means first real post on the custom domain — blog.

Beginners overview: beginners. Pillar map: WordPress hosting guide.

Soft launch versus hard launch

A soft launch puts the custom domain live without ads or press. Use it to catch SMTP failures and broken mobile menus with real DNS. A hard launch adds campaigns. Soft launch first whenever the site replaces an existing URL — you need time for caches and for Search Console to see HTTPS.

If you are replacing an old site, prepare redirects from legacy permalinks. Launching without redirects drops rankings and bookmarked /services-old paths. Redirect maps are content work; hosting only serves them once they exist in WordPress or at the edge you control.

Legal pages people forget

Ship Privacy Policy and, if you sell in regulated regions, appropriate terms/refunds — especially with Woo. Cookie banners are a product/legal choice; if you add one, confirm it does not block first paint absurdly. Hosting does not supply legal text.

Feature flags you should turn off

  • Coming Soon plugins left on after launch (it happens)
  • Default “discourage search engines” still checked in Reading settings
  • Test payment gateways still in sandbox mode
  • Staging URLs in marketing PDFs

Double-check Reading settings the morning you announce.

Rollback plan on launch day

Know how you will revert:

  • DNS back to old host (keep it billed), and/or
  • Deploy file rollback if a theme deploy broke CSS, and/or
  • Database restore from the morning’s UpdraftPlus

Write the order down. Panic is a bad runbook editor. File history ≠ DB restore — SSL and backups.

Tell the world once it works

Update Google Business, social bios, and printed QR codes only after soft launch checks pass. Changing every profile to a broken URL is reverse marketing. Keep a single canonical https link short enough to say on a podcast — blog.

Also confirm the favicon and social share image resolve over HTTPS before you blast the launch email.

Launch day is a checklist, not a vibe

  1. WordPress installed from zip on PHP 8.4; installer completed on HTTPS preview.
  2. Salts set; DISALLOW_FILE_EDIT on; debug off.
  3. Backup plugin connected off-site (DB + files).
  4. Only required plugins; 2FA for admins.
  5. Permalinks saved once; forms tested via SMTP (mail not included here).
  6. Custom domain verified; siteurl/home on HTTPS.
  7. Cache rules exclude carts/accounts if Woo/membership exists.
  8. On Pro+: staging DB copy practiced; real cron enabled.

Skip Softaculous nostalgia. Skip announcing the URL before the certificate exists. Deploy history is your file undo; it is not a full WordPress backup. Trial ~1 day proves the path; paying Starter ($9) or Pro ($30) keeps the origin online.

Soft launch versus hard launch

Share the preview with stakeholders first. Soft-launch the custom domain to a small list before ads. Hard launch when forms, payments (if any), and HTTPS are boring. Woo stores: remember there is no checkout SLA — Woo.

Print a one-page launch checklist for whoever is on call; verbal memory fails when DNS lags.

FAQ

Is launch the same as finishing the installer?

No. Installer creates the app. Launch makes the brand URL safe and presentable for the public.

Can I launch on the preview URL?

For private QA yes. For brand launch, use the custom domain with https siteurl/home.

Do I need staging to launch?

Not always. Highly recommended when using builders, Woo, or memberships.

What if permalinks break after launch?

Re-save permalinks. Confirm you are on a PHP site (not static). Check cache.

What is the one backup rule at launch?

Off-site files + database backup completed successfully before traffic and ads start.